paquet (syn/ack) arreté par le firewall [Résolu]

paquet (syn/ack) arreté par le firewall [Résolu] - réseaux et sécurité - Linux et OS Alternatifs

Marsh Posté le 01-09-2004 à 23:24:40    

Bonjour,  
J'ai un problème très curieux.
 
Je suis sous linux 2.6.8.1/ gentoo
J'utilise le navigateur firefox 0.9.3
J'utilise firestarter 0.9.2 comme firewall
 
Je surfe sans probleme sur tous les sites sauf sur www.hardware.fr
 
Lorsque que j'essaye d'acceder au site www.hardware.fr avec mon navigateur (quelque soit le navigateur), la page ne s'affiche pas.
 
Si je regarde ce qui se passe au niveau des paquets TCP (avec ethereal)
 
Je vois que j'initialise la connection
Mon client envoie un paquet SYN au server (port local machine 55849 => port serveur 80)
Le server me renvoie un paquet SYN/ACK (du port 80 => 55849)
 
Ce paquet se fait bloquer au niveau du firewall sur le port 55849. Je n'affiche donc pas la page. (pas d'ack envoyé, pas de get http etc..)
 
Ce qui est curieux c'est que si j'accede à un autre site, le même paquet syn/ack sur un port local du même ordre (> 55000) ne se fait pas bloquer et evidement la page s'affiche.
 
Si je met le site www.hardware.fr en trust au niveau de mon firewall ça marche (forcément :D)
 
Si j'ouvre le port local qui servira a firefox (55849) au niveau du firewall, mon client receptionne bien le packet syn/ack et renvoie un paquet ack => ça marche aussi (sauf qu'il faut savoir quels ports locaux  seront ouverts)
 
Comment expliquer que le firewall bloque ces paquets ? (non www.hardware.fr n'est pas mis dans ma block list :D)
 
Si quelqu'un a une idée d'où ça peut venir cela m'intéresse.
 
PS : J'accede au site forum.hardware.fr sans problème. Ouf..
 
@+


Message édité par supagweg le 02-09-2004 à 21:48:46
Reply

Marsh Posté le 01-09-2004 à 23:24:40   

Reply

Marsh Posté le 02-09-2004 à 00:36:37    

Pourrait tu etre plus précis quand aux regles utilisées ?
aux modules chargés, a la règles qui bloque le syn/ack
 
Ton probleme est etrange. Netfilter est statefull et devrait laisser passer le syn/ack. il est possible que tu es une regle qui est matchée avant et qui cause le drop. Du genre une regle qui vérifie les flags TCP, fragmentations...
 
Essaye d'isoler précisément la regle qui le drop
Rajoute des logs juste avant cette regle
Si c'est la regle par default.. c'est pas normal

Reply

Marsh Posté le 02-09-2004 à 01:56:00    

supagweg a écrit :

Bonjour,  
J'ai un problème très curieux.
 
Je suis sous linux 2.6.8.1/ gentoo
J'utilise le navigateur firefox 0.9.3
J'utilise firestarter 0.9.2 comme firewall
 
Je surfe sans probleme sur tous les sites sauf sur www.hardware.fr
 
Lorsque que j'essaye d'acceder au site www.hardware.fr avec mon navigateur (quelque soit le navigateur), la page ne s'affiche pas.
 
Si je regarde ce qui se passe au niveau des paquets TCP (avec ethereal)
 
Je vois que j'initialise la connection
Mon client envoie un paquet SYN au server (port local machine 55849 => port serveur 80)
Le server me renvoie un paquet SYN/ACK (du port 80 => 55849)
 
Ce paquet se fait bloquer au niveau du firewall sur le port 55849. Je n'affiche donc pas la page. (pas d'ack envoyé, pas de get http etc..)
 
Ce qui est curieux c'est que si j'accede à un autre site, le même paquet syn/ack sur un port local du même ordre (> 55000) ne se fait pas bloquer et evidement la page s'affiche.
 
Si je met le site www.hardware.fr en trust au niveau de mon firewall ça marche (forcément :D)
 
Si j'ouvre le port local qui servira a firefox (55849) au niveau du firewall, mon client receptionne bien le packet syn/ack et renvoie un paquet ack => ça marche aussi (sauf qu'il faut savoir quels ports locaux  seront ouverts)
 
Comment expliquer que le firewall bloque ces paquets ? (non www.hardware.fr n'est pas mis dans ma block list :D)
 
Si quelqu'un a une idée d'où ça peut venir cela m'intéresse.
 
PS : J'accede au site forum.hardware.fr sans problème. Ouf..
 
@+


un petit iptables -L -n bien senti permettrait d'en savoir un peu  plus ... :D

Reply

Marsh Posté le 02-09-2004 à 08:16:30    

Zzozo a écrit :

un petit iptables -L -n bien senti permettrait d'en savoir un peu  plus ... :D


 
voila la trace au niveau firewall.
 
Time: Sep  2 08:14:57 Source: 83.243.20.80 Destination: 81.57.15.74 In IF: eth0 Out IF:  Port: 46289 Length: 44 ToS: 0x00 Protocol: tcp Service: unknown
 
/var/log/messages:Sep  2 08:15:10 zeus IN=eth0 OUT= MAC=00:0e:a6:6c:71:9f:00:07:cb:01:0a:81:08:00 SRC=83.243.20.80 DST=81.57.15.74 LEN=44 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=80 DPT=46289 WINDOW=5840 RES=0x00 ACK SYN URGP=0
 
[#f0000e]J'ai retiré le resultat du iptables car je me suis rendu compte d'une règle pas top :D
 
Je vais determiner quelle règle drop et je vous la file
 
Merci de votre aide


Message édité par supagweg le 02-09-2004 à 11:58:32
Reply

Marsh Posté le 02-09-2004 à 08:30:34    

freyr a écrit :

Pourrait tu etre plus précis quand aux regles utilisées ?
aux modules chargés, a la règles qui bloque le syn/ack
 
Ton probleme est etrange. Netfilter est statefull et devrait laisser passer le syn/ack. il est possible que tu es une regle qui est matchée avant et qui cause le drop. Du genre une regle qui vérifie les flags TCP, fragmentations...
 
Essaye d'isoler précisément la regle qui le drop
Rajoute des logs juste avant cette regle
Si c'est la regle par default.. c'est pas normal


 
je vais RTFM pour savoir comment faire et j'essaye d'isoler la règle :D
 
Merci pour ces infos

Reply

Marsh Posté le 02-09-2004 à 09:26:05    

Avant chaque regle tu rajoute une regle pour logguer. Tu mets Exactement les memes match. La seule chose qui doit etre modifiée c'est la cible.  Dans les infos de log tu précise le numéro de regle ou autre chose qui puisse te permettre de l'identifier.

Reply

Marsh Posté le 02-09-2004 à 17:48:27    

supagweg a écrit :

voila la trace au niveau firewall.
 
Time: Sep  2 08:14:57 Source: 83.243.20.80 Destination: 81.57.15.74 In IF: eth0 Out IF:  Port: 46289 Length: 44 ToS: 0x00 Protocol: tcp Service: unknown
 
/var/log/messages:Sep  2 08:15:10 zeus IN=eth0 OUT= MAC=00:0e:a6:6c:71:9f:00:07:cb:01:0a:81:08:00 SRC=83.243.20.80 DST=81.57.15.74 LEN=44 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=80 DPT=46289 WINDOW=5840 RES=0x00 ACK SYN URGP=0
 
[#f0000e]J'ai retiré le resultat du iptables car je me suis rendu compte d'une règle pas top :D
 
Je vais determiner quelle règle drop et je vous la file
 
Merci de votre aide


Euh ... comment dire ... ton post n'apporte quasiment rien d'infos là ... :D
Si j'ai demandé le iptables -L -n c'est pour une bonne raison ... m'enfin c'est toi qui vois après tout ... :D

Reply

Marsh Posté le 02-09-2004 à 21:10:03    

Zzozo a écrit :

Euh ... comment dire ... ton post n'apporte quasiment rien d'infos là ... :D
Si j'ai demandé le iptables -L -n c'est pour une bonne raison ... m'enfin c'est toi qui vois après tout ... :D


 
Excuse Zzozo, j'ai eu peur en voyant le resultat du iptables -L -n
En fait l'adresse suspecte etait celle de mon DNS :D. Dès fois je deviens psycho ...
 
La règle sur laquelle le packet syn/ack se fait bloquer est celle là :
 
LD         all  --  83.0.0.0/8           81.57.15.0/24      
 
En effet l'ip de www.hardware.fr est 83.243.20.80. C kon qd même ..
Dsl de vous avoir dérangé.
 
Vu que le pb est trouvé je vous épargne le iptables de 3 pages :D
 
Merci pour votre aide
 
Au fait pour trouver quelle règle est utilisée, plutot que rajouter des logs, il suffit de faire  
1) iptables -L -v -n > avant.txt
2) executer la manip qui bloque rapidement
3) iptables -L -v -n > apres.txt
4) diff avant.txt apres.txt
 
@+

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed