Les Forums

Les Forums

Les forums sont fermés. Ils restent présent pour consultation et archivage.
Vous pouvez désormais poser vos questions directement dans les commentaires en bas de chaque page du site.
Alors n'hésitez pas à participer

SYNFLOOD

SALUT TOUT LE MONDE
VOILA J 'ai '4 LIGNE ADSL J'ai pointé 3 LIGNE AVEC SYNFLOOD SUR L'adresse ip de la 4 LIGNE AVEC LA COMMANDE SUIVANTE "synflood -ip_destination 196.217.228.57 -PORT_destination 80 -loops 0 "
et j'ai monitorier la bande passante de la cible , a ma grande surprise j'ai constaté 0 octet entrant et sortant
je note aussi que j'ai utilise synflood en frontal c 'est a dire derriere aucun routeur (pas de nat) alors je me suis vraiment demandé est ce que synflood marche si qq peut m'aider je suis un passioné des reseaux j'ai fait 4 LIGNE ADSL JUSTE POUR TRANSFORMER MA MAISON EN LABO
QUAND J'ai lancé synflood j'ai aussi utilise la commande netstat -na et ethereal qui je nesais pour quel raison il m'indique @ distination comme adresse source
je serai ravi de votre aide
merci
SALUT
desolé , les ami c'etais une erreur de ma part, maintenant sa tourne bien mais j'ai constaté que l'efficacité de synflood reste a demontré sur les serveurs windows 2000 ET 2003 parceque j'ai fait le test avec windows 2000 SERVER avec 3 LIGNE qui pointent tous vers une seule adresse et durant plus de 5H LA BETE de windows 2000 SERVER tourne toujours sans problemes, je pense que la pile ip de ce serveur est telement puissante qu'il faut l'attaquer en rafal ...... je m'aprette ce soir a d'autre test je vous tiendrais au courant
merci et bravo pour le site
Lu SAAD,

Merci pour tes remontés d'infos. N'hésites surtout pas à continuer. Essai de spécifier le nombre de session en attente, le débits, l'impact proc ....

J'ai une question, avec ton derniers test, Est ce que ethereal et netstat -nao démontraient le bon fonctionnement ?

Sinon, je ne sais pas ce que tu utilises comme station pour executer Synflood, mais fait attention, car l'outil utilise la pile IP de ton OS et sera donc contraint au limite de ton windows. Limite en terme de session TCP.

Donc plusieurs solution, la première est de l'utiliser depuis plusieurs stations simultannées. L'autre est que je suis en train de refaire les outils en s'appuyant sur Pcap. Ainsi, il n'y aura plus de limite avec l'OS utilisé. (De plus, il n'y aura plus le problème du SP1 et SP2 d'XP).

@+

_SebF
_SebF - Sébastien FONTAINE
SALUT LES AMIS
ENCOR ,une autre fois désolé je dois avoué que durant mes premiers tests j'etais pas dans mon assiette , j'ai testé synflood en local sa marche a merveille plus que ça j'etais etonné de son efficacité// VOICI LES PREMIERS RESULTAS DE MON 1 ER TEST QUI A ETE FAIT EN LOCAL
il faut que la 3 phase de la connexion n' aie pas lieu pour laisser la connexion en attente ET epuiser ainsi les resources
j'ai pris comme adresse ip de la source une adresse existante dans mon reseau et j'ai suivi de tres pres ce qui se deroule sur un serveur web (la cible) sous windows 2000 ADVANCED SERVER ayant a l'ecoute le port 80 ET 79 j'ai constaté que le serveur se surcharge un peu mais il arrive toujours a mettre fin à la connexion en attente et libérerait ainsi les ressources .l'attaque n'a pas lieu
2// j'ai refais la meme attaque en mettant comme adresse ip source une adresse inexistante dans mon lan l'attaque a ete spectaculaire pas plus de 15 S ET la page web demandé devient impossible de s'afficher il ya eu un debordement au niveau DE ???
3// lors de la verification du dernier attaque j'ai constaté que le serveur arrete de repondre uniquement sur le port specifie DANS l'attaque 80 ALORS QUE CELUI DE 79 CONTINUE TOUJOURS DE FOURNIR SON SERVICE ET LORSQUE J'inverse le scenario les resultants S'INVERSENT donc pour ce test c'est clair qu'on deborde avec synflood le port attaqué et non pas la pile entiere j'ai refais le test plus que 30 FOIS ET LES RESULTATS SONT TOUJOURS LES MEMES
4// JE RELANCE TOUJOURS L'attaque avec deux batch l'un sur 80 l'autre sur 79 LE RESULTANT EST CLAIRE LES 2 PORT SONT MUET DANS MOINS DE 10 S """"
MA QUISTION EST CE QUE SYNFLOOD VA CONSERVER SON EFFICACITE MEME A DISTANCE..........? EN TOUS LES CAS JE FERAI LE TEST
SALUT
A PROPOS DE ETHEREAL IL INDIQUE EXACTEMENT LES SYN ET SYN_ack
et pour la 3 PHASE SELON L'ip choisi si il existe sur le reseau ou non
encor une autre remarque il faut faire attention avec le NAT MEME SI ON CHOISI UNE IP SOURCE QU'on sait qu'il n'existe pas sur le reseau local de la cible nous aurons le SYN_ack QUI REVIENT VERS IP PUBLIQUE DU ROUTEUR QUI A ENCAPSULE LA TRAME INITIAL AVEC SON IP DONC IL YA UN RST-ack et l'ATTAQUE NE SERA PAS CONCLUANTE . IL FAUT ATTAQUER EN FRONTAL .POUR LE MOMENT JE FAIS DES TESTS SUR MES SERVEURS DISTANTS JE VOUS TIENDRAI AU COURANT JE PENSE POUVOIR MEME VOUS PROPOSER UN RAPPORT DETAILLE DE TOUS MES TEST ET ENCOR BRAVO A FRAMEIP.COM

+@
SAAD
Lu SAAD,

Tu parles de NAT et de trame retour. Même si tu spécifies une IP source qui n'existe pas sur ton LAN, le routeur effectuera une translation. Cependant, au retour, la translation existant, le routeur saura (d'un point de vue L3) router le paquet. Par contre, je me pose une question et je crois bien qu'a ce moment, ton routeur émettra une requête ARP pour trouver l'adresse MAC de 'IP source qui n'existe pas. Donc le paquet sera alors non routé. La suite dépend de ton routeur et de son paramétrage : Va t il informer le destinataire Internet avec un datagramme ICMP ? Si oui alors ça te gène, si non, alors cool.

Une autre chose à bien avoir conscience que ce soit en LAN ou WAN. Si tu spécifies ta propres IP source, l'échange sera : SYN | SYN-ACK | RST. Synflood en Socket Raw, agis directement en couche 3 sans passer par TCP, donc la pile IP de ton Windows n'a pas connaissance de la demande d'ouverture de session. Ainsi quand ton Windows reçoit le SYN-ACK, il n'a pas vu le SYN et ne comprend donc pas, Il réagis alors en envoyant un RST.

Comment éviter d'envoyer des RST :
1 - Spécifier une adresse source non utilisée (et être sur que les routeurs ne le diront pas)
2 - Activer un service Firewall (sur ton Win32, routeur, ...) empêchant la récupération du SYN-ACK

@+
_SebF - Sébastien FONTAINE
SVP
MAINTENANT ,JE SAIS COMMENT SYNFLOOD AGIT MAIS JE VOUDRAIS QUAND MEME SAVOIR UNE CHOSE QUAND ON INNONDE UNE CIBLE NORMALEMENT LE SERVEUR ARRETE DE REPONDRE UNIQUEMENT SUR LE PORT SPECIFIE COMME DISTINATION ,LES AUTRES PORTS RESTENT EN SERVICE( voir mon message 4 PARA 4 ET 5 ). AUTRE CHOSE J'aimerai savoir est ce que toutes les piles tcp/ip sont vulnerables et est ce qu'Il existe un mécanisme d'expiration permettant de rejeter les paquets au bout d'un certain délai pour liberer la file d'attente des connexion semi-ouvertes? parceque selon mes tests ca marche merveillesement pour qq serveurs web mais ça marche pas pour d'autres?

saad
Lu SAAD,

Normelement, c'est la pile IP qui impacté et donc tous les ports TCP en écoutent. Cependant, tous cela dépend de comment tu utilise l'exe et surtout, comment est développer la pile IP. (Ca dépend aussi du réseau traversé : routeur, firewall, IDS et autres ...)

De base chaque pile IP gère l'expiration des requêtes SYN, mais chacune le paramètre différement.

Je suis content de voir que tu es emmerveillé par cet exe. Parcontre, rasseures moi, quand tu parles de serveurs WEB, tu l'utilises en test sur une maquette ? Car ce n'est pas fait pour embêter le monde, les outils FrameIP sont developpé et mise à disposition pour la pédagogie et formation.

@+
_SebF - Sébastien FONTAINE
SALUT
OUI...CHER RASSUREZ VOUS QUE MES TESTS SONT SOIT FAITES SUR UNE MAQUETTE , SOIT SUR DES SERVEURS QUI NOUS APPARTIENTS ... ET ENCOUR MERCI POUR LE PARTAGE DE CE SAVOIR
@+
SALUT
J'ai remarqué que sur les serveurs windows 2003 . SYNFLOOD aneanté le serveur a 90 % , C'est a dire sur 10 demandes seul une est +, les 9 autres demandes C'est "" IMPOSSIBLE D'AFFICHER LA PAGE"" peut-tu svp m'expliquer de quel facteur depend ce pourcentage
merci
Lu SAAD,

Maintenant que tu manipules bien le produit, tes questions sont plus pointus et plus technique. Dons ce cadre, essai d'être plus précis (phrase), de fournir tes commandes (synflood -ip_source ...) et les résultats (CPU =N%, netstat -nao ...)

Je ne suis pas certain d'avoir compris la question, mais je te répondrait cela :


Je pense qu'en faite, tu ne sature pas le processeur, mais le nombre de session en cours maximum autorisé sur le Windows (un netstat -na nous apporterait la confirmation). Dans ce cadre, il ne faut pas oublié le status de "session en cours" n'est pas infinie, le serveur va donc les nettoyer au furent et à mesure.

X étant le temps que windows met pour supprimer sa session en cours après avoir recu ton SYN.

Conclusion, après N (le premier SYN), ton serveur va en permenance libérer des sessions et donc permettre de nouvelle session a ce connecter. Là, pourquoi plus ton Synflood que ton IE qui demande une session aussi ?

En fait, cela se fera à celui qui demande le plus. Donc plus tu enverras de Syn, plus tu auras de chance de chopper la place de la session qui vient de se libérer avant que l'IE la prenne.

90%, nous pouvons peux être en déduire que tu émets telement de SYN, que 1 sur 20 seulement ne sont acceptées. cela signifirait que tu emet 10 SYN quand le windows libère une session.

@+
_SebF - Sébastien FONTAINE
merci pour ta reponse aussi vite
en effet j'ai suivi le meme raisonement ,j'ai aussi essayer de ralentir l'envoi des SYN et logiquement le pourcentage de saturation de session deminue , mais ce que je ne comprends pas c'est que je relance l'attaque avec 3 ATTAQUANT ( donc il y aura 3x le nombre syn ) ET JE ME DIS si j'arrive avec un seul attaquant a saturer le serveur a 90% avec 3 ATTAQUANT je devrais le saturer a +100% MAIS HELAS NON ET SUR CHAQUE 10 DEMANDE DE SYN IL Y AURA TOUJOURS UNE QUI EST ACCEPTER PAR MON IE . ces tests ont ete faites en lan et wan et toujours les memes resultats
la commande utilisé est la suivante /
SYNFLOOD -ip_source 10.1.0.111 -ip_destination 10.1.0.254 -PORT_destination 80 -loops 0
AVEC 10.1.0.111 QUI N'existe pas sur le reseau LAN
POUR LE WAN J'utilise une @ que je deconnecte du reseau .
@+
SAAD
Lu SAAD,

Pourrais tu essayer un ou deux tests. Ca pourrez nous éclairer.

Cas 1 :
1 - Nettoye la table de session du serveur
2 - essai -loops 1
3 - Vérifie que la session est en attente sur le serveur
4 - Attend quelle disparaisse
=> Combiens de temps entre l'étape 2 et 4 ?

Cas 2 :
1 - Tu refais tes tests habituels quisature le serveur
2 - Netstat -na
=> Combiens de session en cours pour que le serveur ne réponde plus ?


Juste une remarque dans ton calcul, Synflood envoi un seul SYN alors que IE en enverra plusieurs SYN (si il n'a pas de réponse).
_SebF - Sébastien FONTAINE
comme demandé,
[u:7e0e040703]:
1-table de session nettoye sur le serveur (windows 2000 SERVER)
2-un seul loops est envoyé
3- la session est en attente
4- SYN_received dure exactement 21s ( mesure a la chrono pendant 5X)
[u:7e0e040703]:
1- j'ai commencé a chercher le seuil du saturation du serveur progressivement et cela s'est manifesté NETTEMENT a partir de 60 LOOPS
tant que netstat -na indique des session en attente le serveur est saturé pas de reponse pour IE (+90%)
une fois on arrete le flooding il faut patienter pratiquement 20 S pour que le serveur redevient operationnelle a 100%
netstat -s nous indique un nombre de connexion non reussi tres proche du nombre de connexion passive
L'activité du cpu semble ne pas etre sensible au flooding il est constament au voisinage de 10%
LA COMMANDE UTILISEE EST LA SUIVANTE
SYNFLOOD -ip_source 192.168.0.123 -ip_destination 192.168.0.79 -PORT_destination 80 -loops 0
AVEC HOTE 123 INEXISTANTE SUR MON LAN
autre chose j'ai remarqué en fesant et en essayant de se rappeler du port du dernier syn_ received affiché en ligne de commande que le serveur arrive a se debarrasser au bout de 20s pratiquement le meme temps que dure un loops
+@
SAAD
Lu SAAD,

Très interressant tes résultats. Les 21s et le 60 loops.

Le 60 signifie donc que ton Windows ne supporte pas plus de 60 sessions en cours. Cela doit être modifiable dans la registerie je pense. Je vais regarder si je trouve.

Peux tu essayer encore un test ?
1 - tu monte 100 sessions TCP pleine avec par exemple un "telnet serveur 80" (utilise un batch pour monter les 100 sessions, tu auras des fenetre partout 😉
2 - tu refait le test pour connaitre à partir de combiens de SYN envoyé via Synflood avant que le serveur ne te refuse une future session.

=> Si tu retrouve à nouveau 60, c'est que la limite de ton Windows est bien de 60 sessions en cours et non pas 60 sessions.

Les 21 secondes doivent être paramétrable je penses aussi.

P.S. :
Fab, si tu n'es pas en vacances, qu'en penses tu ?
_SebF - Sébastien FONTAINE
Voila ce que j'ai trouvé sur la registerie :
http://support.microsoft.com/default.aspx?scid=kb;en-us;158474

Cela concerne Windows 2000, cela signifis que tu auras certainement les mêmes entrées (valeurs) mais pas avec les même chiffre

--------------------------------------------
100 me parrait faible pour un serveur, enfin ca dépend ce que tu en fait.
--------------------------------------------
MaxConnections = 32-bit number

Data Type: String

Specifies the maximum number of concurrent connections. The default is 100.

--------------------------------------------
C'est ce que je te parlais quand ton IE, contrairement au synflood, envoi 3 SYN en non 1 (pour ton calcul de 90%)
--------------------------------------------
MaxConnectRetries = Number

Data Type: String

Specifies the number of times a connection attempt (SYN) will be retransmitted before giving up. The initial retransmission timeout is 3 seconds, and it is doubled each time up to a maximum of 2 minutes. The default is 3.


--------------------------------------------
J'ai aussi trouvé ca qui a l'air très cool :
--------------------------------------------
Nom de la valeur : SynAttackProtect
Clé : Tcpip\Parameters
Type de valeur : REG_DWORD
Valeurs possibles : 0,1,2
Par défaut : 0

Cette valeur de registre force le protocole TCP à ajuster la retransmission de SYN-ACKS. Lorsque vous configurez cette valeur, le délai de réponse de connexion est dépassé plus rapidement en cas d'attaque SYN (un type d'attaque de refus d'accès aux services).

La liste suivante décrit les paramètres que vous pouvez utiliser avec cette valeur du registre : • 0 (valeur par défaut) : Définissez SynAttackProtect sur 0 pour une protection type face aux attaques SYN.
• 1 : Définissez SynAttackProtect sur 1 pour une meilleure protection face aux attaques SYN. Ce paramètre force le protocole TCP à ajuster la retransmission de SYN-ACKS. Lorsque vous définissez SynAttackProtect sur 1, le délai de réponse de connexion est dépassé plus rapidement s'il apparaît qu'une attaque SYN est en cours. Windows utilise les valeurs suivantes pour déterminer si une attaque est en cours : • TcpMaxPortsExhausted
• TCPMaxHalfOpen
• TCPMaxHalfOpenRetried


• 2 : Définissez SynAttackProtect sur 2 pour une protection optimale face aux attaques SYN. Cette valeur ajoute des délais supplémentaires aux indications de connexion, et le délai de connexion TCP s'écoule rapidement lorsqu'une attaque SYN est en cours. Ce paramètre est recommandé.

REMARQUE : les options de socket suivantes ne fonctionnent plus sur aucun socket lorsque vous définissez la valeur SynAttackProtect sur 2 : • Fenêtres évolutives
• Paramètres TCP configurés sur chaque carte (y compris RTT initial et la taille de la fenêtre
--------------------------------------------
_SebF - Sébastien FONTAINE
salut fab
pour les vacances : quand je suis devant mon ordi, je sens que je suis deja en plein vacances :
Pour les 60 sessions c'est modifiable a partir de la base de registre :
quant au batch j'ai deja fais le test c'est pratiquement la meme chose et j'ai deduis qu'il supporte 60 session en cours
les 21 s c'est la que tout ce joue c'est en modifiant ce 21 et les 60 sessions qu'on peut trouver un equilibre pour contrer les attaques synflood mais je pense que les firwalls savent deja faire ces choses , on parlera peut-etre un jour .....as-tu deja utiliser ? c'est interessant de jeter un coup d'oeil , demain je t'envoyerai un lien ...histoire de comparer notre synflood a leur hping...ceci etant dit je reste toujours a la recherche de: pourqoui synflood n'arrive pas a saturer a 100 % la file d'attente , j'ai meme penser que peut-etre ce 21 s est une valeur variable en fonction du nombre de session en attente c'est a dire une fois le nombre de session semi -ouverte arrive a un seuil critique le system diminue le temps d'attentes de 21 s pour eviter le crash total .ET c'est ainsi qu'il arrive a rester en vie ..et c'est la qu'on dois concentrer nos tests ....vous faites un grand effort il faut donc presenter un produit complet qui puissent cracher le serveur a 100% . je reste a votre disposition pour d'autres tests
@+
saad

je pense qu'au moment ou je vous ecrivait le dernier message ,je n'ai pas encour lu le votre , donc si tu peut le lire et dis moi ce que tu pense?
je reviens sur une chose que je ne comprends pas ,pourqoui synflood sature la cible a 90 % MAIS ne depasse jamais ce seuil meme si on attaque avec 2,3,4 c'st a dire que l'attaque soit faite par un seul attaquant ou plusieurs le seuil 90% NE PEUT ETRE DEPASSE . SI L'on ferme les yeux et on essaye d'imaginer ce qui se passe au sein de la dite file d'attente ... : le port est a l'ecoute la file d'attente est vierge soudain une serie de SYN arrive en rafal (+60 syn), la file d'attente est presque saturer elle est obligé de changer son comportement le delai d'attente 21s est diminué pour liberer au maximum mais l'innondation se continue ,le serveur pour echappé a la mort subit continue a diminue de plus en plus le seuil (il peut arrivé a 1 s).....donc il a diminué le temps d'attente de 21 fois , par contre si je veut l'aneantir completement je dois augmonter ma puissance de tire de 22 fois ....et la je suppose que ca devrais marché mais j'en suis pas absolument sur parceque il ya un autre facteur c'est l'interval que met synflood entre les demandes de connexion c'est on arrive a lui ajouter ce parametre en MICRO SECONDES , la je pense que ça devrais marcher....dans mon dernier message je t'ai parler de hping.exe je t'envoie ce lien :http://www.student.montefiore.ulg.ac.be/~bleuwart/
essaye de me dire ce que tu pense merci
Lu SAAD,

Me voila de retour de congés 🙂 Je suis en forme, mais j'ai un peu perdu le fil de notre discussion.

J'ai regarder ton lien et la documentation est vraiment très intérressante.

Je me remet dedans :
Si le serveur recois des Syn en permenance, il en libère aussi en permenance, donc il a toujours (en instant T) un peu de place.

Partons sur :
- N étant le nombre session TCP réussit (étalis par la bonne machine)
- X étant le nombre bon SYN demandé (envoyé par la bonne machine)
- Y étant le nombre de mauvais SYN (emis par la mauvaise machine : Synflood.exe)

Dans ce cas, il recoit beaucoup de demande, alors peut on dire :
"Dans le cas d'une saturation N = X/Y" ?

@+
_SebF - Sébastien FONTAINE
completement d'accord ,ce qui m'interesse c'est de faire tendre N=X/Y
vers 0(ZERO)ce qui peut se realiser uniquement par augmentation de Y avec x =100 " " mais tout cela en fonction du facteur temps .....donc c'est le nombre de syn que peut recevoir la file est limité , et comme cette file est domacratique , le 1er arrivée est le 1er servi ..... il y aura toujours de la place pour quelque X syn donc si tu vois ou je voudrais arrivé le tout se joue en fonction du temps ..... si cette file d'attente peut recevoir en une unité de temps t
W SYN (avec W=X+Y ) il faut que Y VOLE toute la place disponible sur la file d'attente et la il faut qu'il ya pas de pause entre les FAUX SYN envoyé(optimisation de la cadence du flooding) et avoir un ping vers la cible plus mailleur que celui des vrais SYN ......hping dont je t'ai parlé fixe le delai de pause entre les syn envoyé en micro secondes.....meme si l'on multiplie le nombre d'attaquant ....arrivée a un certains nombre d'attaquant on aura en une unité de temps t Y > W donc il y aura des syn Y qui seront ignoré ET X aura moins de chance d'aboutir mais il est toujours la et il a ces chances .....................
Lu SAAD,

OK on est d'accord. Y doit être massif. Juste un détail, peux expliquer de nouveau ta phrase incluant le ping, car je ne vois pas ce qu'il vient nous apporter.

La pause en microsonde entre l'envoi de chaque SYN est bidon. Cela ne permet pas d'accélérer l'envoi, mais de le ralentir. Synflood.exe n'a pas de pause et va au maximum qu'il peut. Si tu veux, je peux rajouter une temporisation en microsonde ...
Parcontre, je n'ai pas optimisé le code source pour gagner du temps. Je pourrais le faire. Maintenant, le meilleur moyen d'exploser la valeur de Y est de passer l'attaque en mode distribué.

En final, tu démontre que l'infinie n'existe pas et que le maximum que tu peux faire est de groisir énormement Y pour que N tende vers 0. Mais comme tu finalise, N sera toujours !=0

Il me vient aussi une idée, il nous faut définir une constante "C" qui définira la définition de quand un serveur est HS et donc de quand Synflood à réussit (n'oublions pas que N est exprimé en seconde) :
Pour cela Si N<C alors on a gagné.

Si tu positionne C==0, alors on revient à ton problème premier 🙂
Mais si tu définit une valeur tel que C==0,1, cela signifiant que le serveur cible n'arrive qu'a prendre une seule session TCP correctement toutes les 10 secondes, alors, on peux concidérer qu'il est gravement malade ....
_SebF - Sébastien FONTAINE
OK
concernant le ping OU plutot ping/2 (sous windows) le temps que met un SYN pour arrivé a la cible .theoriquement je me suis dis que peut importe le ping 20ms ou 200 ms il suffit que le 1er SYN arrive a la cible pour que les autre qui suivent arrivent avec un ecart de ß (avec ß comme temps de pause entre les synfloods ,il est infiniment petite mais reste toujours differente de zero ) donc un moment donné exactement apres 180 ms les SYN emisent par la cible ayant comme ping 20 ms ou 200 ms arriveront en rafal avec des ecart de ß donc les deux attaquants peut importe leur ping vers la cible , ils ont les memes chances ...... en pratique c'est peut-etre autre chose je me suis debrouillé pour avoir des pings differentes vers la meme cible et j'ai remarqué que une fois le ping a depassé une valeur de 200 ms synflood n'arrivent plus a mettre le serveur HS , MAIS IL SE PEUT QUE J'AI FAIT une mauvaise interpretation parceque il ya avais aussi des microcoupure avec mes 200 ms...... concernat la pause en microsocondes je suis completement d'accord ça va le ralentir( ca serais interesssant juste pour des statistique en labo)parcontre si tu peut optimiser le code pour gagner un peut de temps ca serai merveilleux ....et en se moment on peut estimé qu'il est temps de pase en
mode distribué.......je suis completement d'accord avec la constante C ,en effet moi je la definie commeça: je lance mon MERVEILLEUX synflood , je reprend une autre machine a partir d'un autre reseau distant je me met dans la peau d'un bon homme qui veut se connecter au serveur a tout prix et je lance 100 FOIS DES BONS CONNEXIONS et je note calmement le resultant .... ce que j'ai obtenu avec MON DERNIER test c'est sur 100 VRAIS SYN IL YA 5 POSITIVE et 95 NEGATIVE ET LA JE CONCLUE QUE SYNFLOOD EST GAGNANT A 95% ET PERDANT A 5% ..... JE PENSE QU'on mode distribué on doit approché les 100% ? Je vais refaire les tests en LAN et WAN .........EN ATTENDANT UNE OPTIMISATION DU CODE SERA TRES SOUHAITE ....BON COURAGE
SAAD
Lu SAAD,

D'accord avec toi sur les 10 premières lignes. Pour la pratique, la relation n'est pas "théoriquement" possible, car l'outil génère des trame en mode non connecté et donc l'outil ne se pose pas le question de l'acheminement pour emmetre le second SYN. La seule relation que je peux trouver serait que c'est l'interface Ethernet de ta machine qui génère le changement des 200ms ce qui impacterait le Synflood qui serait obliger d'attendre le driver de la carte pour emmetre le seond SYN ...

Pour le mode distribué, que l'on pourrait appeller DSynflood, c'est un autre concept très intérressant et trop simple à mettre en oeuvre. Par contre la protection est beaucoup plus difficile.

Dans le cas du mode distribué, quand tu as réussit à mettre en oeuvre le concept, tu n'a pas besoin de Synflood, mais un envoi de n'importe qu'elle trame suffira pour tuer ton hôte distant.

A valider, mais je ne pense pas que 5 sessions positives fasse 95% d'echec. Moi, mais tu confirmera en fonction des tests que tu a réelement réalisé, je compterais :
- Un echec Windows XP SP2 = 3 tentatives de SYN
Donc
- 95*3+5=98,27% gagnant au minimum
- 95*3+5*3=98,33% gagnant au maximum

Deux idées notés :
- Créer un exe qui génère N bonne connexion TCP (voir http://www.frameip.com/session ) qui mesure le nombre de bonne connexion.
- Optimiser le code de Synflood (c'est plus de l'expertise de developpement pure ce qui n'est pas mon cas)
_SebF - Sébastien FONTAINE
D'accord pour tout ce que tu dis , et merci pour la correction de mes calcul et le tuyeau de
a+
SAAD
salut les gars
j essaye de lancer le synfloyd il me met q u il manque un pacjet.dll
que faire?
Lu khalilghas,

Essai de réinstaller Winpcap, car la DLL packet.dll (avec un k) en fait partie.

@+
_SebF - Sébastien FONTAINE
Bonjour,

J'ai un problème avec SynFlood. Lorsque j'essaie d'envoyer une requête à mon routeur en modifiant l'adresse le programme me répond :"Error number 202.1 Unable to send Ethernet Frame".

Quelqu'un sait de quoi ça vient?

Merci d'avance.
Lu Taz666,

Cela vient surement du fait que tu n'as pas selectionné la bonne interface.

@+
_SebF - Sébastien FONTAINE
Merci pour votre annonce Saad merveilleux et de l'information vous nous avez fournis
Bonjour;
Merci pour ce forum
ca fait plus de 3jours que j essaye d'attaquer mon pc avc synflood ca ne veut pas marcher une fois par je ne sais combien de fois il maffiche impossible d'afficher la page
je travaille avec VMware je commence par attaquer dans un lan mon serveur web pat le port 80 voici la commande utilisée "synflood -ip_destination 192.168.10.60 -port_destination 80 -loops 0 -mac_destination (mac de mon serveur)
je n mets pas d'ip_source synflood envoi des adresses aléatoirement si j'ai bien compris le principe
avec ethereal je vois les [syn] [syn ack] la commande netstat -na maffiche les connexions établies en attente et fin d'attente
merci de me répondre je suis vraiment bloquée ca fait partie de mon projet de fin d'étude
Lu iman mimi,

Essai d'ajouter l'argument -view 0 qui dévrait accélerer.

@+
_SebF - Sébastien FONTAINE
Lu SebsF
je viens de l'essayer ca ne marche toujours pas
Lu SebsF

les paquets arrivent je viens de vérifier cela avec ethereal
j'ai lancé l'attaque a partir de 3 pcs contre le serveur web (windows server 2003) mais le port n'est toujours pas saturé 1fois sur 10 on m'affiche qu'il est impossible d'afficher la page.
aidez moi svp
et pourquoi les paquets n'arrivent pas quand je les lance derrière un routeur
c'est a dire par l'extérieur
merci
Bonsoir SebsF,
c'est bon ca marche mais après avoir mis 4 pcs contre le serveur.
maintenant j'aimerais faire l'attaque a partir d'un pc distant (derrière un ubuntu qui fait le routage) j'essaye d'envoyer les paquets mais ils n'arrivent pas je n'ai pas compris le problème la commande utilisée est la méme "synflood -ip_destination 192.168.10.60 -port_destination 80 -loops 0 -mac_destination -view 0 "
g essayé avec une adresse ip_source existante ca donne rien
merci de m'aider
Lu iman mimi,

J'ai pas ton contexte exacte, mais au feeling, essai de spécifier l'adresse MAC de ton routeur.

@+
_SebF - Sébastien FONTAINE
Lu SebsF
je travaille avec vmxare j'ai un reseau local une dmz(serveur web serveur dns) et internet(attaquant + client) tous reliés par une passerelle
je veux a partir de internet (attaquant ) attaquer le serveur web par synflood
g essayé avec ladress mac du routeur ca na rien changé
voila merci
Bonsoir,

Merci sebF pour votre aide j'ai trouvé le probleme
il fallait spécifier l'ip-source et donner une adresse avec le meme sous reseau de l'attaquant et soécifier l'adresse-mac du routeur aussi

iman