Hello,
 
  afin de comprendre les attaques de type TCP SYN FLOOD et mettre en place une solution de sécurité adéquate, j'utilise une commande (dont je terrai le nom) qui ne fait que des demande SYN sans envoyer de ACK.
  La question est comment contrôler sur la machine distante que j'ai recu des demande SYN ouverte en attente d'un ACK (la commande netstat -an ne montre que les SYN suivi d'un ACK ). Certaine doc parle de "table TCP"  
 
pour info voila la ligne tcpdump recu par la machine distante :  
09:00:24.950846 IP 192.168.0.105.2456 > 192.168.0.101.80: S 50674506:50674506(0) win 4096
 
on remarque bien la lettre S montrant une demande SYN
 
Merci pour toutes information.
 

Il y a deja l'option kernel syncookies pour limiter les degats d'un syn flood
 

 
http://fr.wikipedia.org/wiki/SYN_cookie .

ça arrête même complètement l'attaque

merci pour vos réponses,
 
oui j'avais lu la doc la dessus, mais j'aurais bien voulu voir la table TCP se remplir de connexion SYN (de la meme maniere qu'on peut voir les connexion LISTEN ou ESTABLISHED)
 
vais jeter un oeil dans /proc, il doit bien y avoir l'info qque part ...

ben si t'as des syn cookie normalement l'OS n'alloue pas les ressources avant d'avoir reçu le ack qui va bien, c'est donc normal que tu vois rien amha

Je n'ai bien sur pas activé syn cookie  
d'après ton hypothèse je devrai donc voir les demandes de SYN ....  

Question:
l'outils, que tu utilises, spoofe-t-il l'adresse IP source ?
 
Si non, il envoit un syn, la  pile TCP/IP "victime" lui renvoit un syn/ack et dans la foulée la pile de l'équipement "attaquant" va lui renvoyer un RST (vu qu'il n'a pas émis la demande de connexion) ce qui va détruire le contexte de l'équipement "victime" => la victime ne sera jamais remplie de connexion "half-open"

merci bcp o'gure tu m'a mis sur la bonne voie avec ta question.
 
j'ai d'abord mis mon ip source, et j'ai regardé si au moins je recevais un paquet d'ACK SYN de la machine que j'attaque. Et je recevais rien.
En effet la mac destination etait en broadcast (pas glop) et j'ai comparé une demande de SYN valide (envoyé par telnet) et une demande créer à la main et j'ai comparé les paquets, pour créer un paquet qui soit un peu mieux
 
J'ai ensuite fermé mon firewall  "iptables -A INPUT -p tcp --dport 20000:30000 -j DROP"   et j'ai envoyé la purée.
 
Résultat sur le serveur attaqué , netstat -anp | grep -i syn  

 
bien sur y'en avait beaucoup plus que ca. (beaucoup beaucoup plus)
 
et le temps que je post ce message les paquets n'ont pas disparu ....
 
bon je vais activer tcp_syncookies et comparer les résultats
 
je refait un post dans un instant
 
 
 
--
formation sécurité linux : http://formation.1g6.biz/securite- [...] linux.html
 

ouais ben je suis pas convaincu par le tcp_syncookies (echo 1 > /proc/sys/net/ipv4/tcp_syncookies)
 
il  faut plusieurs minutes pour que la table tcp se vide tout de meme.... peut etre par ce que c'est en réseau local, et que mon firewall est très permissif dans ce cas

pourquoi tu n'est pas convaincu par tcp_syncookies ? oO
Cette protection permet justement que le serveur ne garde pas en memoire les demande de connection tant qu'il n'as pas recut la confirmation ACK .

Et que tu sois en LAN n'y changeras rien .

Par contre je ne comprends pas comment tu peux fermer ton FW avec "iptables -A INPUT -p tcp --dport 20000:30000 -j DROP" oO

EDIT : le but d'un syn flood , c'est justement de ne pas retourner de confirmation ACK pour DOS le serveur qui auras alloué toute sa memoire dans des demandes de connections qui n'aboutirons jamais .

ACK et surtout RST
cette règle là, il la met sur l'attaquant pour ignorer les paquets syn/ack de la victime. Il doit émettre des syn sur ces ports là. C'est quoi le problème ?

ahhhh , je croyais qu'il voulait utiliser cette regle iptables sur le serveur victime , je voyais pas trop ou il voulait aller avec .