Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
2808 connectés 

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

Table des SYN TCP

n°1040206
PierreC
Posté le 07-05-2008 à 09:16:06  profilanswer
 

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.
 


---------------
Du tofu en Alsace : www.tofuhong.com
mood
Publicité
Posté le 07-05-2008 à 09:16:06  profilanswer
 

n°1040661
ipnoz
Sapé comme jamais !
Posté le 08-05-2008 à 03:27:49  profilanswer
 

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


echo 1 > /proc/sys/net/ipv4/tcp_syncookies


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

n°1040662
dreamer18
CDLM
Posté le 08-05-2008 à 04:16:02  profilanswer
 

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


---------------
"Parceque toi tu fracasses du migrant à la batte de baseball, c'est ça ?" - Backbone-
n°1040663
PierreC
Posté le 08-05-2008 à 09:13:08  profilanswer
 

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 ...


---------------
Du tofu en Alsace : www.tofuhong.com
n°1040665
dreamer18
CDLM
Posté le 08-05-2008 à 09:51:29  profilanswer
 

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


---------------
"Parceque toi tu fracasses du migrant à la batte de baseball, c'est ça ?" - Backbone-
n°1040671
PierreC
Posté le 08-05-2008 à 10:19:48  profilanswer
 

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


---------------
Du tofu en Alsace : www.tofuhong.com
n°1040674
o'gure
Modérateur
Multi grognon de B_L
Posté le 08-05-2008 à 10:29:48  profilanswer
 

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"


---------------
Relax. Take a deep breath !
n°1040681
PierreC
Posté le 08-05-2008 à 11:13:29  profilanswer
 

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  


tcp        0      0 192.168.0.101:80        192.168.0.105:20097     SYN_RECV   -
tcp        0      0 192.168.0.101:80        192.168.0.105:20175     SYN_RECV   -
tcp        0      0 192.168.0.101:80        192.168.0.105:20172     SYN_RECV   -
tcp        0      0 192.168.0.101:80        192.168.0.105:20237     SYN_RECV   -
tcp        0      0 192.168.0.101:80        192.168.0.105:20213     SYN_RECV   -
tcp        0      0 192.168.0.101:80        192.168.0.105:20146     SYN_RECV   -
tcp        0      0 192.168.0.101:80        192.168.0.105:20044     SYN_RECV   -
tcp        0      0 192.168.0.101:80        192.168.0.105:20145     SYN_RECV   -
tcp        0      0 192.168.0.101:80        192.168.0.105:20009     SYN_RECV   -
tcp        0      0 192.168.0.101:80        192.168.0.105:20034     SYN_RECV   -
tcp        0      0 192.168.0.101:80        192.168.0.105:20230     SYN_RECV   -
tcp        0      0 192.168.0.101:80        192.168.0.105:20199     SYN_RECV   -
tcp        0      0 192.168.0.101:80        192.168.0.105:20123     SYN_RECV   -


 
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
 

n°1040686
PierreC
Posté le 08-05-2008 à 11:25:17  profilanswer
 

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


---------------
Du tofu en Alsace : www.tofuhong.com
n°1040704
ipnoz
Sapé comme jamais !
Posté le 08-05-2008 à 13:30:32  profilanswer
 

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 .


Message édité par ipnoz le 08-05-2008 à 13:34:56
mood
Publicité
Posté le 08-05-2008 à 13:30:32  profilanswer
 

n°1040745
o'gure
Modérateur
Multi grognon de B_L
Posté le 08-05-2008 à 16:32:12  profilanswer
 

ACK et surtout RST [:aloy]
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 ?


Message édité par o'gure le 08-05-2008 à 16:57:14

---------------
Relax. Take a deep breath !
n°1040747
ipnoz
Sapé comme jamais !
Posté le 08-05-2008 à 16:47:40  profilanswer
 

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


Aller à :
Ajouter une réponse
 

Sujets relatifs
SquidGuard qui boucle sur l'init des tableTable de mixage DJ sur linux
Reset d'une connexion TCPTaille de la fenêtre TCP, faut-il vraiment s'en occuper ?
Table de partition, et partition cassé suite à un plantage de mysqldfirewall / x table
Tcp proxy , kernel linux.Logiciel graphique pour visualiser en direct des flux TCP
Vérouiller une table MySQL par script BashComment cacher les ports TCP 0 (?) et 1 ?
Plus de sujets relatifs à : Table des SYN TCP


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR