Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Xavier Roche
Nicolas DEFFAYET wrote:
Je pose cette question en rapport à: http://lists.freebsd.org/pipermail/freebsd-net/2003-October/001684.html
Cela peut être un simple synflood (la queue TCP v4 est pleine dans ce cas - que dit un netstat -an), ou une appli qui ne ferme pas correctement les ports (ou de même un client qui n'envoie pas le dernier FIN) Que répond la machine suite au premier SYN?
Autre test: faire un ifdown/ifup - j'ai une carte gigabit qui a parfois des vapeurs (plus aucune réponse, autonégo dans l'espace..), et un simple ifdown/ifup la remet sur les rails (!)
Bref sans plus détails ca sent plus le problème soft/hard AMHA que'un pb de sécurité - j'ai aussi vu des realtek qui, au bout d'un certain temps (une vingtaine d'heures) se mettaient à partir dans l'espace - le ifdown/ifup réglait là aussi le problème (!) sur un Linux/2.2.18
Nicolas DEFFAYET wrote:
Je pose cette question en rapport à:
http://lists.freebsd.org/pipermail/freebsd-net/2003-October/001684.html
Cela peut être un simple synflood (la queue TCP v4 est pleine dans ce
cas - que dit un netstat -an), ou une appli qui ne ferme pas
correctement les ports (ou de même un client qui n'envoie pas le dernier
FIN)
Que répond la machine suite au premier SYN?
Autre test: faire un ifdown/ifup - j'ai une carte gigabit qui a parfois
des vapeurs (plus aucune réponse, autonégo dans l'espace..), et un
simple ifdown/ifup la remet sur les rails (!)
Bref sans plus détails ca sent plus le problème soft/hard AMHA que'un pb
de sécurité - j'ai aussi vu des realtek qui, au bout d'un certain temps
(une vingtaine d'heures) se mettaient à partir dans l'espace - le
ifdown/ifup réglait là aussi le problème (!) sur un Linux/2.2.18
Je pose cette question en rapport à: http://lists.freebsd.org/pipermail/freebsd-net/2003-October/001684.html
Cela peut être un simple synflood (la queue TCP v4 est pleine dans ce cas - que dit un netstat -an), ou une appli qui ne ferme pas correctement les ports (ou de même un client qui n'envoie pas le dernier FIN) Que répond la machine suite au premier SYN?
Autre test: faire un ifdown/ifup - j'ai une carte gigabit qui a parfois des vapeurs (plus aucune réponse, autonégo dans l'espace..), et un simple ifdown/ifup la remet sur les rails (!)
Bref sans plus détails ca sent plus le problème soft/hard AMHA que'un pb de sécurité - j'ai aussi vu des realtek qui, au bout d'un certain temps (une vingtaine d'heures) se mettaient à partir dans l'espace - le ifdown/ifup réglait là aussi le problème (!) sur un Linux/2.2.18
Nicolas DEFFAYET
Xavier Roche wrote:
Salut Xavier,
Nicolas DEFFAYET wrote:
Je pose cette question en rapport à: http://lists.freebsd.org/pipermail/freebsd-net/2003-October/001684.html
Cela peut être un simple synflood (la queue TCP v4 est pleine dans ce cas - que dit un netstat -an), ou une appli qui ne ferme pas correctement les ports (ou de même un client qui n'envoie pas le dernier FIN) Que répond la machine suite au premier SYN?
Autre test: faire un ifdown/ifup - j'ai une carte gigabit qui a parfois des vapeurs (plus aucune réponse, autonégo dans l'espace..), et un simple ifdown/ifup la remet sur les rails (!)
Bref sans plus détails ca sent plus le problème soft/hard AMHA que'un pb de sécurité - j'ai aussi vu des realtek qui, au bout d'un certain temps (une vingtaine d'heures) se mettaient à partir dans l'espace - le ifdown/ifup réglait là aussi le problème (!) sur un Linux/2.2.18
Le TCP IPv6 et le ICMP IPv4/IPv6 marche correctement lors du problème, uniquement le TCP IPv4 est impacté. Ce n'est pas un problème hardware car avec le hardware d'une machine qui marche j'ai le meme problème.
Le problème semble avoir disparu depuis que j'ai filtrer tout le traffic tcp avec ipfw comme on me la conseillé.
Je vait essayer à la place du firewall, la variable: net.inet.tcp.blackhole=2
Merci
-- Nicolas DEFFAYET
Xavier Roche wrote:
Salut Xavier,
Nicolas DEFFAYET wrote:
Je pose cette question en rapport à:
http://lists.freebsd.org/pipermail/freebsd-net/2003-October/001684.html
Cela peut être un simple synflood (la queue TCP v4 est pleine dans ce
cas - que dit un netstat -an), ou une appli qui ne ferme pas
correctement les ports (ou de même un client qui n'envoie pas le dernier
FIN)
Que répond la machine suite au premier SYN?
Autre test: faire un ifdown/ifup - j'ai une carte gigabit qui a parfois
des vapeurs (plus aucune réponse, autonégo dans l'espace..), et un
simple ifdown/ifup la remet sur les rails (!)
Bref sans plus détails ca sent plus le problème soft/hard AMHA que'un pb
de sécurité - j'ai aussi vu des realtek qui, au bout d'un certain temps
(une vingtaine d'heures) se mettaient à partir dans l'espace - le
ifdown/ifup réglait là aussi le problème (!) sur un Linux/2.2.18
Le TCP IPv6 et le ICMP IPv4/IPv6 marche correctement lors du problème,
uniquement le TCP IPv4 est impacté.
Ce n'est pas un problème hardware car avec le hardware d'une machine qui
marche j'ai le meme problème.
Le problème semble avoir disparu depuis que j'ai filtrer tout le traffic tcp
avec ipfw comme on me la conseillé.
Je vait essayer à la place du firewall, la variable:
net.inet.tcp.blackhole=2
Je pose cette question en rapport à: http://lists.freebsd.org/pipermail/freebsd-net/2003-October/001684.html
Cela peut être un simple synflood (la queue TCP v4 est pleine dans ce cas - que dit un netstat -an), ou une appli qui ne ferme pas correctement les ports (ou de même un client qui n'envoie pas le dernier FIN) Que répond la machine suite au premier SYN?
Autre test: faire un ifdown/ifup - j'ai une carte gigabit qui a parfois des vapeurs (plus aucune réponse, autonégo dans l'espace..), et un simple ifdown/ifup la remet sur les rails (!)
Bref sans plus détails ca sent plus le problème soft/hard AMHA que'un pb de sécurité - j'ai aussi vu des realtek qui, au bout d'un certain temps (une vingtaine d'heures) se mettaient à partir dans l'espace - le ifdown/ifup réglait là aussi le problème (!) sur un Linux/2.2.18
Le TCP IPv6 et le ICMP IPv4/IPv6 marche correctement lors du problème, uniquement le TCP IPv4 est impacté. Ce n'est pas un problème hardware car avec le hardware d'une machine qui marche j'ai le meme problème.
Le problème semble avoir disparu depuis que j'ai filtrer tout le traffic tcp avec ipfw comme on me la conseillé.
Je vait essayer à la place du firewall, la variable: net.inet.tcp.blackhole=2
Merci
-- Nicolas DEFFAYET
Pierre BETOUIN
Xavier Roche wrote: Le TCP IPv6 et le ICMP IPv4/IPv6 marche correctement lors du problème, uniquement le TCP IPv4 est impacté. Ce n'est pas un problème hardware car avec le hardware d'une machine qui marche j'ai le meme problème. Ça pourrait bien être un synflood alors, car IPv6 est censé prévenir
ce genre d'attaques grâce aux en-têtes IP contenant les hashs. Cf header d'un paquet ipsec, puisque ipsec est implémenté "de série" dans IPv6.
Le problème semble avoir disparu depuis que j'ai filtrer tout le traffic tcp avec ipfw comme on me la conseillé. Je vait essayer à la place du firewall, la variable: net.inet.tcp.blackhole=2 Essaie un "netstat -ntp" comme te l'a dit Xavier, tu pourras en savoir
plus.
-- °°°°°°°°°----------------°°°°°°°°° Pierre BETOUIN
°°°°°°°°°----------------°°°°°°°°°
Xavier Roche wrote:
Le TCP IPv6 et le ICMP IPv4/IPv6 marche correctement lors du problème,
uniquement le TCP IPv4 est impacté.
Ce n'est pas un problème hardware car avec le hardware d'une machine qui
marche j'ai le meme problème.
Ça pourrait bien être un synflood alors, car IPv6 est censé prévenir
ce genre d'attaques grâce aux en-têtes IP contenant les hashs.
Cf header d'un paquet ipsec, puisque ipsec est implémenté "de série"
dans IPv6.
Le problème semble avoir disparu depuis que j'ai filtrer tout le
traffic tcp avec ipfw comme on me la conseillé.
Je vait essayer à la place du firewall, la variable:
net.inet.tcp.blackhole=2
Essaie un "netstat -ntp" comme te l'a dit Xavier, tu pourras en savoir
plus.
--
°°°°°°°°°----------------°°°°°°°°°
Pierre BETOUIN
soulrider@unsigned.ath.cx
°°°°°°°°°----------------°°°°°°°°°
Xavier Roche wrote: Le TCP IPv6 et le ICMP IPv4/IPv6 marche correctement lors du problème, uniquement le TCP IPv4 est impacté. Ce n'est pas un problème hardware car avec le hardware d'une machine qui marche j'ai le meme problème. Ça pourrait bien être un synflood alors, car IPv6 est censé prévenir
ce genre d'attaques grâce aux en-têtes IP contenant les hashs. Cf header d'un paquet ipsec, puisque ipsec est implémenté "de série" dans IPv6.
Le problème semble avoir disparu depuis que j'ai filtrer tout le traffic tcp avec ipfw comme on me la conseillé. Je vait essayer à la place du firewall, la variable: net.inet.tcp.blackhole=2 Essaie un "netstat -ntp" comme te l'a dit Xavier, tu pourras en savoir
plus.
-- °°°°°°°°°----------------°°°°°°°°° Pierre BETOUIN
