Si un Windows XP, que esta apagado.On Fri, 2003-01-31 at 20:42, Borxa Varela wrote:xuvenka:/home/borxa# tcpdump -nxX -i ppp0 tcpdump: listening on ppp0 03:39:37.110504 195.242.103.231.2727 > 80.103.153.85.4662: S 3344191268:3344191268(0) win 16384 <mss 1420,nop,nop,sackOK> (DF) 0x0000 4500 0030 eec0 4000 7206 0471 c3f2 67e7...Hum... Ese log que enviaste está positivamente extraño. Exáctamente ¿cómo es la configuración de tu red? ¿Tienes más de una PC conectada a través de xuvenka?
Posiblemente si, mi asignacion de ip es dinamica, pero si puede ser una y encuanto a denominador común, no lo hay, ya he mirardo muchos logs del a conexión.El log que enviaste (una pena que el protocolo no sea reconocible; posiblemente capturaste sólo segmentos de datos binarios en medio de una transmisión ya establecida... sería interesante tener un SYN y cuatro o cinco paquetes subsecuentes) muestra interacciones entre las siguientes máquinas: 195.242.103.231 > 80.103.153.85 80.103.153.45 > 80.103.153.85 80.129.23.87 > 80.103.153.194 80.103.153.45 > 80.103.153.194 213.161.66.179 > 80.103.153.45 80.103.153.45 > 213.161.66.17 62.83.42.23 > 80.103.153.45 80.103.153.45 > 62.83.42.23 217.127.81.42 > 80.103.153.47 80.103.153.45 > 80.103.153.47 81.172.51.235 > 80.103.153.45 80.103.153.45 > 81.172.51.235 ¿Alguna de éstas es tuya? El segmento 80.103.153.0/24 parece ser el denominador común, pero el punto es que estás viendo interacciones entre varias máquinas. Y son conexiones establecidas, no intentos de conexión rechazados (no se ven resets).
Me inclino por la 2? No puede ser que otros usuarios a los que se le asignó la ip que me asignan a mi ahora, usasen el mldondkey (u otros), y ahora me llegan a mi los paquetes que en teoría serían para su conexión... aunque la cosa dura siempre, y supongo que si tengo el mldondkey apagado, con el paso del tiempo ya no tedría más.Lo único que se me ocurre es que (1) realmente eres parte de un LAN, y no nos lo habías dicho, y estás ruteando ese LAN a través de tu conexión PPP o algo así (en cuyo caso mi recomendación del netstat aplicaría para todas las máquinas del LAN). O (2), tu proveedor de acceso te está enviando tráfico que no es para ti.
"wanadoo por RTB" es algo así como France Telecom por linea telefonica basica, un modem 56k, que es lo único que tenemos aquíSobre este último caso, la única vez que he visto tal marranada es con proveedores de acceso por cable: los más sucios tienden a conectar toda una colonia en un LAN, usando el cable como una especie de ethernet, de forma que puedes esnifear el tráfico de tu vecino. De forma que ¿qué clase de conexión estás usando? (y disculpa, es que "wanadoo por RTB" no le dice nada a un güey de este lado del charco).
No, porque eschuco con tcpdump -i ppp0 'port 53 or port 80' y no llegan paquetes, para la opción demand si funciona el filtro, pero para la idle no, lo cual es otro misterio para mi.Si en efecto tienes ese problema, quizá la razón por la que tu pppd no parece caerse a pesar de tu "active-filter" es porque estás recibiendo los queries de DNS de otras máquinas. Quizá deberías meter la restricción adicional de que el emisor sea tu propia máquina (lo cual requerirá un poquito de hackeo, si tu IP es dinámica).
Si, no sabía que el kernel tuviese una opción especifica para REJECT, la he compilado y ahora funciona, solo veo los paquetes que tienen como destino mi puerto 4662, pero aun así no he encotrado un filtro que funcione.Y el netstat -pA inet:Nada interesante. Puedes usar -up, para ver por UDP. Pero me suena a que no es por ahí la cosa. Sobre bloquear el puerto, y la recomendación que te dieron por ahí, y el error que posteaste... ¿qué kernel estás usando? Si es un 2.2, usa ipchains(8) en vez de iptables. Si es un 2.4, asegúrate de tener el paquete iptables, y soporte en el kernel (los kerneles "oficiales" de Debian tienen todo lo necesario --sólo me preocuparía por eso si estuvieras usando un kernel hecho en casa).
Creo que ya lo he apagado.También puedes querer bloquear más que sólo TCP (¿ese donkey no usa UDP?). Que te sea leve. -CR P.D. ¿Sería mucho problema apagar el HTML en tu cliente de correo? El mío se hace camotes al citar tus mensajes cuando los respondo.
Referente al apagado, como suelen decir "es mejor hacerlo tu que pedir que te lo hagan", he hecho un programa que si funciona, estoy en proceso de optimizado... pero me gustaría que lo hiciesen los programas que vienen con la distribución, por lo de mantener un poco de orden en el sistema.
xuvenka:/home/borxa# cat idle.c
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>
main(int argc, char *argv[]){
int i,pid,pid_tcpdump,df1,copiadf1,df2,copiadf2,lineas_agora=1,lineas_antes=-1;
char *lectura1,*lectura_final;
char *param[5];
lectura1=malloc(20);
if(pid_tcpdump=fork()==0){
df1=open("/var/log/dump.log",O_WRONLY|O_CREAT,0600);
close(1);
dup(df1);
for(i=0; i<5; i++)
param[i]=malloc(8);
param[0]="tcpdump";
param[1]="-i";
param[2]="ppp0";
param[3]="port 53 or port 80";
param[4]=NULL;
execv("/usr/sbin/tcpdump",¶m[0]);
}
else{
while(1){
if(pid=fork()==0){
df1=open("/var/log/dump.log",O_RDONLY);
df2=open("/var/log/dump.cont",O_WRONLY|O_CREAT,0600);
close(0);
dup(df1);
close(1);
dup(df2);
for(i=0; i<5; i++)
param[i]=malloc(8);
param[0]="wc";
param[1]="-l";
param[2]=NULL;
execv("/usr/bin/wc",¶m[0]);
exit(1);
}
else{
waitpid(pid,NULL,NULL);
df1=open("/var/log/dump.cont",O_RDONLY);
read(df1,lectura1,10);
lectura_final=(void *)strtok(lectura1," ");
lineas_agora=atoi(lectura_final);
printf("lineas_agora: %d lineas_antes %d\n",lineas_agora,lineas_antes);
if(lineas_agora == lineas_antes){
if(fork()==0){
sleep(3);
if(system("/usr/bin/pon")== -1)
printf("Non hai collons\n");
else{
system("/usr/local/bin/idle");
printf("Listo\n");
}
}
else{
system("/usr/bin/killall pppd");
system("/bin/rm /var/log/dump.log /var/log/dump.cont");
// kill(pid_tcpdump,9);
}
exit(1);
}
lineas_antes=lineas_agora;
sleep(atoi(argv[1]));
}
}
}
}
xuvenka:/home/borxa#
