Bonjour à toutes et à tous !

Alors j'ai un petit serveur derrière une livebox à la maison.. Donc rien de bien méchant une tour de récup et un routeur quoi

Donc pour m'amuser et comprendre un peu mieux le fonctionnement des attaques DOS je me suis permis de m'attaquer moi-même via un serveur loué "à l'heure" sur le quelle il me restait un peu de temps avant qu'il n'arrive à expiration... (32 coeurs, connexion 5Gbps) Donc scénario unique sur lequel je ne paierais pas un serveur (à l'heure je dois avouer que c'est peu cher, mais bon, presque 1€/h tout de même lol) juste pour reproduire le scénario.

Donc mon routeur à les ports 443,80,113(?) et 51000 et quelques (serveur torrent) d'ouvert qui redirige le trafic sur les mêmes ports du serveur maison.

Une fois sur le serveur loué, je lance la commande de flood :

hping3 -S adresseIp -p 80 -i u1000 -d 65495 (en gros envoie 100 requêtes par secondes à l'adresse Ip sur le port 80 avec le flag SYN et en data 65495 bytes, le parametre i change en fonction des os ou j'ai pu l'installer ... donc bon la c'était comme ça )

Bon... résultat serveur local injoignable de l’extérieur et la j'arrive tout doucement sur ma question.

mon serveur local n'a presque aucune charge cpu en plus durant le scénario ... (de l'ordre de 2% et bon il y a pas mal de services dessus donc l'impact est nul à ce niveau) pareil pour la charge ram.

mon serveur local est en wifi (oui je sais ... bon c'est du wifi5 et j'ai de la chance par chez moi j'ai la fibre (quoique ça commence à être commun maintenant) donc je monte à 30mo/s normal sans forcer )

Une requete à 65535bytes : fait bien 8Ko ?

Si mon excellent calcul est bon :ironie:, 100 requetes/s à 8Ko ça fait bien 800Ko/s ?

Et c'est la ou je débarque avec toutes mes questions :

Premièrement, pourquoi le serveur local encaissait 3Mo/s alors que le serveur loué est censé envoyer 800Ko/s de requêtes ? (noté avec nethogs)

Ensuite le serveur local comme expliqué précédemment n'as eu aucune charge en plus au niveau cpu/ram, c'est normal ?

Puis le site héberger sur mon serveur local était injoignable, alors que cpu/ram/réseau pouvait encaisser plus : la faute à la livebox ? -> Si c'est le cas 50 requêtes bien chargé en SYN suffise à mettre une livebox 5 fibré à 400mbits KO ?


Voila, pour l'instant je n'ai plus de question, en attendant de vous lire !

Cordialement,

Bonjour,

serakoc a écrit:

hping3 -S adresseIp -p 80 -i u1000 -d 65495 (en gros envoie 100 requêtes par secondes à l'adresse Ip sur le port 80 avec le flag SYN et en data 65495 bytes, le parametre i change en fonction des os ou j'ai pu l'installer ... donc bon la c'était comme ça )

Tu es sûr que u1000 équivaut à 10ms? Pour moi 1000u (micro) = 1ms donc 1000 par secondes.

«a byte» c'est un octet, donc 65495 bytes valent 65495 octets soit 65Ko environ. Multiplié par milles, on obtient 65Mo/s.

Le problème, c'est qu'entre ton serveur distant et ta box internet, c'est un peu une boite noire. Donc difficile de savoir si tu reçois bien tous les paquets envoyés par le serveur distant sur la box. Et si la box arrive correctement à rediriger tout le flux.

Quand tu fais ton DOS, d'autres services hébergés en local et atteignable depuis internet sont disponibles? Ou seulement le serveur web est affecté?

Si tu es limité par le débit possible en WiFi, alors de toute manière, je doute que tu puisses vraiment pousser à bout les ressources matériels comme le CPU ou la RAM.

Ton DOS, il consiste surtout à placer un maximum de socket TCP dans un état SYN-RECEIVED (on dit que la connexion est half-open) jusqu'à ce que le serveur en ait trop. En fait, ton serveur a un backlog TCP, c'est-à-dire une queue d'une taille maximum pour toute nouvelle connexion. Quand la queue est remplie, aucune nouvelle connexion n'est traitée par le serveur. Sur Linux (si par hasard c'est l'OS du serveur local ), tu peux voir la taille du backlog TCP dans le fichier /proc/sys/net/ipv4/tcp_max_syn_backlog (tu peux aussi la modifier bien sûr). Tout ça pour dire, que tu fais du SYN flood, et que ça n'a pas pour but d'épuiser le CPU ou la RAM.

D'accord je comprend mieux !
Tout-d'abord merci de ta réponse

Et bien concernant le paramètre de délai entre chaque requete, j'ai tester sur un serveur c'était en en micro-seconde et sur l'autre il fallait rajouter un zéro ...

Donc c'est pour ça que ça ne répondait (plus) par intermittence ! Ok j'ai compris ...

-i --interval
    Wait the specified number of seconds or micro seconds between sending each packet. --interval X set 
wait to X seconds, --interval uX set wait to X micro seconds. The default is to wait one second between 

each packet. Using hping3 to transfer files tune this option is really important in order to increase transfer
 rate. Even using hping3 to perform idle/spoofing scanning you should tune this option, see HPING3-HOWTO for

more information. 

--fast

Alias for -i u10000. Hping will send 10 packets for second.
--faster
    Alias for -i u1. Faster then --fast  (but not as fast as your computer can send packets due to the signal-driven design). 
--flood
    Sent packets as fast as possible, without taking care to show incoming replies. This is ways faster than to specify the -i u0 option

Et bien j'ai plusieurs serveur qui tourne dessus, soit site internet, soit service local sur les quelle le proxy redirige les requêtes en fonction du servername(torrent.mondomaine.fr -> reverse proxy sur localhost:9091), au niveau des sites internet -> impossible de se connecter pendant l'attaque mais je comprend mieux pourquoi ...

La prochaine fois je testerais avec le client torrent (paquet udp) pour voir s'il transmet ...

Par rapport au wifi je me suis dit que c'est le nombre de requête qui ferait au moins travailler un peu le cpu, mais au final non pas du tout lol et cela encore une fois c'est surement lié au nombre de nouvelles connexion qui sont limités (à 256 pour moi), donc au final ça fonctionne par intermittence...

Après j'ai encore beaucoup de questions mais ça sortirait du sujet et j'ai juste as cherché (un peu toutes les bases du tcp finalement ...)

Je te remercie