Re: Hacker de la red, ¿quien esta enviando/reciviendo paquetes en mi PC?
Cesar Rincon escribiu:
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?
Si un Windows XP, que esta apagado.
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).
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.
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.
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.
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).
"wanadoo por RTB" es algo así como France Telecom por linea telefonica
basica, un modem 56k, que es lo único que tenemos aquí
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).
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.
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).
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.
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.
Creo que ya lo he apagado.
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#
Reply to: