connexion bizare etablie

par **Dark_Tux** » 23 Juin 2003 13:49

Salut a tous voila j'utillise ipcop 1.3 fix1-2 en fait dans la section "informations/connexions" j'ai une connexion etrange ça donne ça: tcp (6) 398043 ESTABLISHED 81.53.50.116:32972 216.239.51.99:80 216.239.51.99:80 81.53.50.116:32972 [ASSURED]1 ce qu'il faut savoir que tout se passe sur une interface rouge ,que la premiere adresse ip n'est pas la mienne (ou peut-etre une ancienne) et que la 2nd adresse est vraisemblablement un serveur de google.com avez vous la meme connexion et savez vous ce que c'est ??? merci d'avance @+

par **grosbedos** » 23 Juin 2003 13:54

moi sa mets deja arrivé, tout de suite on pense a du spoofing (et oui du red vers le red??) mais en fait regarde tes logs, le 81.... est une adresse que ton fai ta donné avant. par contre pourquoi google demande d'etablir des connexions pendant aussi lontemps..je peu pas te dire!!

par **Dark_Tux** » 23 Juin 2003 13:57

oui c'est clair que c'est une de mes anciennes adresses mais y'a une connexion permanante et quand je fais un netstat -an y'a rien je ne comprends pas

par **tomtom** » 23 Juin 2003 14:39

C'est normal car ce n'est pas le resultat d'un netstat que tu vois là. Il faut savoir que iptables utilise des "conntracks" pour ouvrir dynamiquement des ports (ce que l'on appelle un firewall statefull". EN clair, supposons que tu etablisse une session tcp avec google pour prendre une page. Tu auras tout d'abbord un paquet : ip source : ton_ip_publique port source : 2000 (par exemple) ip destination : ip_google port destination : 80 flags : syn quand netfilter va voir passer ce paquet, il va creer ce que l'on appelle un conntrack. En gros, c'est une table qui dit quels paquets sont attendus et doivent donc pouvoir passer le firewall. Les paquets qui coorespondent à une entrée de cette table sont marqués avec le state "ESTABLISHED" ou "RELATED" (si ftp par exemple). Et comme les paquets ESTABLISHED et RELATED sont autorisés à traverser le firewall, la reponse pourra passer. Avec l'exemple precedent, on aurrait un conntrack comme ceci : ipsource : ip_google port source : 80 ip destination : ton_ip_publique port destination : 2000 state : ESTABLISHED et quand ce fameux paquet va arriver, il pourra traverser le firewall et la communication pourra s'etablir. Ensuite, tous les paquets emis par google sur ce port seront autorisés, soit jusqu'à la fin de la session tcp, soit jusqu'à expiration du timeout. Le timeout n'est pas specifié par google maios par toi. Le conntrack suit en effet le timeout tcp de ta session, qui est de 5 jours par defaut ! En clair, si ton browser plante sans avoir le temps de fermer la session tcp proprement, le conntrack peut rester valide 5 jours ! Pour pouvoir modififier le timeout par defaut, il faut avoir le patch tcp-window-tracking (que l'on trouve dans tous les bons patch-o-matics <IMG SRC="images/smiles/icon_lol.gif"> ). Si c'est le cas sur IPCop, alors il faut modifier la variable /proc/sys/net/ipv4/netfilter/ip_ct_tcp_timeout_established pour modifier tout ça..... Voila, ce n'est pas une grosse faille de securité vu qu'il faut pouvoir hijacker le numero de port, le numero de sequence TCP et encore avoir quelquechose à l'ecoute sur le port aléatoire pour pouvoir exmploiter ça... en clair, no souci... Pour info, la page des connexions dans IPCop reprnd juste les infos du fichier /proc/net/ip_conntrack qui est le fichier de suivi de connexions Netfilter. Thomas

par **Dark_Tux** » 23 Juin 2003 15:26

Merci tomtom pour ta reponse plus que complette toute fois je tiens a preciser que le fichier dont tu fais reference n'existe pas sur ma machine ?????? de plus je reprecise que l'adresse source (la 81.etc) n'est pas la mienne et que certaines fois la connexion s'interomp et elle reprends peut-etre que le probleme viens de ce fichier manquant ( qui ne specifierait pas de time-out) qu'en pense tu ??? merci encore

par **Dark_Tux** » 23 Juin 2003 15:28

errata ....... en fait c'est le repertoire netfilter qui est inexistant ???? @+

par **Dark_Tux** » 23 Juin 2003 15:33

re .........et le fichier ip_contract est vide , y'a un truc qui m'echappe là !!!

par **tomtom** » 23 Juin 2003 15:34

Les fichiers peuvent être à la racine de ipv4 Il se peut aussi que le fichier n'existe pas parceque tu as le module... Dans tous les cas, si cette connexion t'ennuie, vire la ligne coorespondant dans /proc/net/ip_conntrack A mon avis la connexion est restée en l'etat car ton browser a du crasher quand tu avais cette ip et elle reste dans le fichier, jusqu'a expiration du timeout (ca peut durer 5 jours ! ) bien que en fait la veritable connexion tcp soit terminée depuis longtemps ! T.

par **Dark_Tux** » 23 Juin 2003 15:47

c'est clair que c'est un bug mais le fait que le repertoire netfilter n'existe pas et que le fichier ip_contract est vide , ça m'inquiete unpeu ( je precise que j'ai installé ipcop depuis 3 jours et que -contrairement a smoothwall 2b4 , je n'ai rien modifié) merci encore tomtom !!!

par **tomtom** » 23 Juin 2003 15:48

Moi non plus je n'ai pas le rep netfilter, les fichiers sont direct dans ipv4, je ne pesne pas que ce soit un bug, il doit y avoir des variations avec les verions de netfilter... T.

par **Dark_Tux** » 23 Juin 2003 15:52

ah tu me rassure , mais allors ou est le fichier ip_ct_tcp_timeout_established ou une de ses variantes , et pourquoi mon fichier ip_contract est vide

par **tomtom** » 23 Juin 2003 16:05

Si tu n'as pas le fichier /proc/sys/net/ipv4/ip_ct_tcp_timeout_established, c'est probablement que le module n'est pas compilé dans IPCop. Ce n'est pas très grave... Je suis etonné que le fichier /proc/net/ip_conntrack soit vide, surtout si tu surfes en ce moment. C'est ce fichier qu'utilise IPCop pour t'afficher les connexions en cours... T.

par **Dark_Tux** » 23 Juin 2003 16:19

mea culpa je ne sais pas ce que j'ai fait tout a l'heure mais le fichier ip_contract n'est pas vide , par contre je ne sais pas si pour des raisons de securite il n'est pas possible de le modifier (car il ne se sauvegarde pas ) / tu connais un truc ???

par **tomtom** » 23 Juin 2003 16:25

Oui il est dangereux de le modifier car il change tout le temps.... pour le faire en toute securité : 1- se connecter directement sur la box ipcop. 2- arreter le reseau (la je ne connais pas, n'ayant pas ipcop). Chez moi ca donne : /etc/init.d/networking stop 3- editer le fameux fichier. Faire :wq! pour forcer le read only. 4- redemarrer le reseau. T.

par **Dark_Tux** » 23 Juin 2003 16:39

Re Apres un reeboot c'est bon y'a plus cette connexion ça devait etre un bug Merci encore pour ton cours de netfilter mais je voudrais changer le time_whait il est apparement de 120sec comment faire ??

connexion bizare etablie

Qui est en ligne ?