SYN FLOOD - gestion du probleme dans Iptables

Support Debian
#1

Bonjour à tous,

j’ai un gros souci, je subis une attaques type SYN FLOOD, qui fait planter apache et donc tous mes sites sont morts,

mon serveur est un dédié chez OVH, le support me dis de me débrouiller, mais je n’y arrive pas tout seul

est ce que qq’un aurais une idée ? ou pourrais me le faire ? contre une petite rémunération ?

merci !

voici le log de apache avant de cracher

Srv PID Acc M CPU SS Req Conn Child Slot Client VHost Request
0-0 17975 0/11/11 W 0.00 4 0 0.0 0.12 0.12 178.20.55.18 xxxxxmonsitexxx.com POST /index.php?95984847925877 HTTP/1.1
1-0 17976 0/9/9 W 0.00 6 0 0.0 0.06 0.06 46.28.109.100 xxxxxmonsitexxx.com POST /index.php?48287712457553 HTTP/1.1
2-0 17977 0/9/9 W 0.00 5 0 0.0 0.14 0.14 88.191.192.25 xxxxxmonsitexxx.com POST /index.php?15089476663711 HTTP/1.1
3-0 17978 0/13/13 W 0.01 5 0 0.0 0.19 0.19 46.28.109.100 xxxxxmonsitexxx.com POST /index.php?88960076869794 HTTP/1.1
4-0 17979 0/12/12 W 0.13 5 0 0.0 0.16 0.16 95.130.9.190 xxxxxmonsitexxx.com POST /index.php?55047649091231 HTTP/1.1
5-0 17986 0/5/5 W 0.00 3 0 0.0 0.03 0.03 72.52.91.19 xxxxxmonsitexxx.com POST /index.php?28558619642573 HTTP/1.1
6-0 17996 0/0/0 W 0.00 4 0 0.0 0.00 0.00 89.207.132.76 xxxxxmonsitexxx.com POST /index.php?79460683421223 HTTP/1.1
7-0 17997 0/6/6 W 0.00 4 0 0.0 0.04 0.04 94.126.178.1 xxxxxmonsitexxx.com POST /index.php?84695062685682 HTTP/1.1
8-0 18003 0/0/0 W 0.00 3 0 0.0 0.00 0.00 89.207.132.76 xxxxxmonsitexxx.com POST /index.php?45323845685692 HTTP/1.1
9-0 18004 0/1/1 W 0.00 1 0 0.0 0.00 0.00 95.130.9.190 xxxxxmonsitexxx.com POST /index.php?29517342642688 HTTP/1.1
10-0 18005 0/1/1 W 0.00 3 0 0.0 0.00 0.00 141.212.108.13 xxxxxmonsitexxx.com POST /index.php?26629405561791 HTTP/1.1
11-0 18006 0/0/0 W 0.00 3 0 0.0 0.00 0.00 95.130.9.190 xxxxxmonsitexxx.com POST /index.php?92157000501708 HTTP/1.1
12-0 18023 0/1/1 W 0.00 2 0 0.0 0.00 0.00 95.130.9.190 xxxxxmonsitexxx.com POST /index.php?91229597547678 HTTP/1.1
13-0 18024 0/12/12 W 0.00 0 0 0.0 0.19 0.19 5.79.81.200 xxxxxmonsitexxx.com POST /index.php?16515258817615 HTTP/1.1
14-0 18025 0/0/0 W 0.00 2 0 0.0 0.00 0.00 31.171.244.49 xxxxxmonsitexxx.com POST /index.php?64263153692315 HTTP/1.1
15-0 18026 0/9/9 W 0.16 1 0 0.0 0.03 0.03 95.130.9.190 xxxxxmonsitexxx.com POST /index.php?51307834231730 HTTP/1.1
16-0 18027 0/0/0 W 0.00 2 0 0.0 0.00 0.00 37.218.244.212 xxxxxmonsitexxx.com POST /index.php?64361765775131 HTTP/1.1
17-0 18028 0/1/1 W 0.00 2 0 0.0 0.02 0.02 77.109.141.138 xxxxxmonsitexxx.com POST /index.php?4099503114727 HTTP/1.1
18-0 18029 0/0/0 W 0.00 2 0 0.0 0.00 0.00 213.61.149.100 xxxxxmonsitexxx.com POST /index.php?76597703687080 HTTP/1.1
20-0 18573 0/2/2 W 0.00 1 0 0.0 0.00 0.00 5.79.81.200 xxxxxmonsitexxx.com POST /index.php?73959037581705 HTTP/1.1
21-0 18574 0/3/3 W 0.00 1 0 0.0 0.02 0.02 95.130.9.190 xxxxxmonsitexxx.com POST /index.php?42453340230410 HTTP/1.1
22-0 18576 0/1/1 W 0.00 1 0 0.0 0.04 0.04 77.109.141.138 xxxxxmonsitexxx.com POST /index.php?84566608105393 HTTP/1.1
23-0 18577 0/0/0 W 0.00 1 0 0.0 0.00 0.00 31.171.244.49 xxxxxmonsitexxx.com POST /index.php?55146952358939 HTTP/1.1
24-0 18578 0/1/1 W 0.00 1 0 0.0 0.01 0.01 89.207.132.76 xxxxxmonsitexxx.com POST /index.php?13683654247650 HTTP/1.1
25-0 18580 0/2/2 W 0.00 1 0 0.0 0.02 0.02 88.191.192.25 xxxxxmonsitexxx.com POST /index.php?33300835908630 HTTP/1.1
26-0 18581 0/4/4 W 0.00 1 0 0.0 0.03 0.03 141.212.108.13 xxxxxmonsitexxx.com POST /index.php?7409203238507 HTTP/1.1
27-0 18582 0/0/0 W 0.00 1 0 0.0 0.00 0.00 37.218.244.212 xxxxxmonsitexxx.com POST /index.php?48405589461846 HTTP/1.1
28-0 18583 0/0/0 W 0.00 1 0 0.0 0.00 0.00 70.39.66.59 xxxxxmonsitexxx.com POST /index.php?22534769992523 HTTP/1.
30-0 18585 0/2/2 W 0.00 1 0 0.0 0.05 0.05 88.191.192.25 xxxxxmonsitexxx.com POST /index.php?91915152363113 HTTP/1.1
31-0 18586 0/4/4 W 0.00 1 0 0.0 0.05 0.05 89.207.132.76 xxxxxmonsitexxx.com POST /index.php?87956859469566 HTTP/1.1
32-0 18587 0/0/0 W 0.00 1 0 0.0 0.00 0.00 5.79.81.200 xxxxxmonsitexxx.com POST /index.php?20075815412196 HTTP/1.1
34-0 18589 0/4/4 W 0.00 1 0 0.0 0.04 0.04 192.241.230.170 xxxxxmonsitexxx.com POST /index.php?84099275334627 HTTP/1.1
35-0 18590 0/2/2 W 0.00 1 0 0.0 0.01 0.01 72.52.91.19 xxxxxmonsitexxx.com POST /index.php?89634409535862 HTTP/1.1
36-0 19062 0/3/3 W 0.00 0 0 0.0 0.06 0.06 109.163.234.9 xxxxxmonsitexxx.com POST /index.php?1259142890662 HTTP/1.1
37-0 19063 0/3/3 W 0.00 0 0 0.0 0.04 0.04 178.20.55.18 xxxxxmonsitexxx.com POST /index.php?26885567282942 HTTP/1.1
38-0 19064 0/1/1 W 0.00 0 0 0.0 0.02 0.02 95.130.9.190 xxxxxmonsitexxx.com POST /index.php?65524754431289 HTTP/1.1
39-0 19065 0/1/1 W 0.00 0 0 0.0 0.03 0.03 95.130.9.190 xxxxxmonsitexxx.com POST /index.php?47038567806480 HTTP/1.1
40-0 19066 0/0/0 W 0.00 0 0 0.0 0.00 0.00 213.61.149.100 xxxxxmonsitexxx.com POST /index.php?32579238991976 HTTP/1.1
41-0 19067 0/0/0 W 0.00 0 0 0.0 0.00 0.00 77.109.141.138 xxxxxmonsitexxx.com POST /index.php?64107681779587 HTTP/1.1
42-0 19068 0/0/0 W 0.00 0 0 0.0 0.00 0.00 94.126.178.1 xxxxxmonsitexxx.com POST /index.php?63809201956427 HTTP/1.1
43-0 19069 0/0/0 W 0.00 0 0 0.0 0.00 0.00 141.212.108.13 xxxxxmonsitexxx.com POST /index.php?60499409889371 HTTP/1.1
44-0 19070 0/3/3 R 0.00 0 112 0.0 0.04 0.04 ? ? …reading…
45-0 19071 0/4/4 R 0.00 0 88 0.0 0.05 0.05 ? ? …reading…
47-0 19073 0/6/6 W 0.00 0 0 0.0 0.06 0.06 192.241.230.170 xxxxxmonsitexxx.com POST /index.php?54970075198076 HTTP/1.1
48-0 19074 0/0/0 W 0.00 0 0 0.0 0.00 0.00 5.104.224.246 xxxxxmonsitexxx.com POST /index.php?22361574618393 HTTP/1.1
49-0 19075 0/1/1 W 0.00 0 0 0.0 0.01 0.01 213.61.149.100 xxxxxmonsitexxx.com POST /index.php?54537992973635 HTTP/1.1
50-0 19076 0/0/0 W 0.00 0 0 0.0 0.00 0.00 178.20.55.18 xxxxxmonsitexxx.com POST /index.php?38873381943209 HTTP/1.1
51-0 19078 0/0/0 W 0.00 0 0 0.0 0.00 0.00 37.218.244.212 xxxxxmonsitexxx.com POST /index.php?26223441260580 HTTP/1.1
65-0 19098 0/0/0 W 0.00 0 0 0.0 0.00 0.00 94.126.178.1 xxxxxmonsitexxx.com POST /index.php?51778956051531 HTTP/1.1
66-0 19099 0/1/1 W 0.00 0 0 0.0 0.01 0.01 95.130.9.190 xxxxxmonsitexxx.com POST /index.php?77193210257001 HTTP/1.1
67-0 19100 0/1/1 W 0.00 0 0 0.0 0.01 0.01 95.130.9.190 xxxxxmonsitexxx.com POST /index.php?69996765419243 HTTP/1.1

#2

(Je ne suis pas spécialiste en sécurité, ceci n’est que mon avis.)

Une méthode simple et efficace pour lutter contre un SYN flood est d’activer les “SYN cookies”.
[mono]sysctl -w net.ipv4.tcp_syncookies=1[/mono]
Cependant d’après ta description je ne suis pas convaincu qu’il s’agit d’un SYN flood. Un SYN flood affecte le système entier (par consommation de ressources allouée par le noyau aux connexions semi-ouvertes), pas un service particulier comme Apache. En effet comme l’attaquant ne renvoie pas les ACK pour finaliser l’établissement de la connexion, la couche TCP du noyau ne transmet pas la connexion au processus en écoute sur le port visé. Un SYN flood ne se voit pas dans les logs d’apache.

Les logs postés sont-ils des requêtes légitimes ou du flood ? Il n’y a pas de datation, on ne peut pas voir leur fréquence. Si c’est du flood, alors ce n’est pas un simple SYN flood mais de vraies connexions HTTP, contre lesquelles les SYN cookies seront inefficaces. Dans ce cas, si l’attaque est distribuée en provenance de nombreuses adresses sources qu’on ne peut pas toutes filtrer, c’est au niveau de la configuration d’apache qu’il faut poser des limitations au volume de connexions/requêtes traitées.

En tout cas iptables n’est pas un outil très efficace pour lutter contre un SYN flood distribué ou avec spoofing semblant provenir de nombreuses adresses sources différentes. Au mieux il peut servir à limiter les SYN entrants pour protéger les ressources du serveur et l’empêcher de planter, mais ce sera inévitablement au détriment du service fourni car en cas de dépassement de la limite le serveur ne répondra qu’à une partie des requêtes légitimes.

#3

Merci pour votre réponse si rapide !

j 'avais déjà activé syncookies etc … j avais suivi au moins 10 methodes sur le net,

OVH on eux aussi regardé cela,

le log d’apache est sur 1 ou 2 secondes … et toutes ces requêtes sont du flood …

le serveur tourne, c est apache qui plante en 2 a 5 secondes après son redémarrage.

On a essayé de faire une interception pat htaccess des POST/xxxxxxxx , ca marche, j’envois sur une page d’erreur pour que Fail2ban bloque tout ca … mais ca marche pas , comme il y a trop d’IP …

je suis désespéré

Merci

#4

Donc ce n’est pas un SYN flood, les SYN cookies seront sans effet.
Je ne suis pas du tout connaisseur des mesures de sécurisation d’apache.
Tu peux limiter le nombre de connexions HTTP par seconde avec iptables à une valeur que tu juges acceptable pour protéger le serveur

iptables -A INPUT -p tcp --dport 80 --syn -m limit --limit x/s -j ACCEPT iptables -A INPUT -p tcp --dport 80 --syn -j DROP
mais comme je l’ai écrit plus haut, cela dégradera la qualité de service du serveur web.

#5

Ok,

Merci !

je vais essayé mais , si qqun d’autre aurait une idée ça sera la bienvenu

cordialement

#6

Mouais, je suis plus que mitigé par rapport aux syncookies, je pense vraiment que c’est le genre d’option à ne pas activer, au vu des problèmes engendrés;

M’enfin, je rejoins Pascal : il n’y a aucun rapport avec les SYNflood, entendu que la couche 7 obtient des informations (la session est donc montée)

Au vu de tes logs, j’ai du mal à comprendre comment ton serveur peut mourrir : il faut vraiment un gros volume pour tuer apache comme ça, sauf si ta machine est relativement sous-dimensionnée, ou que ton code est merdique (faut-il couper un arbre pour faire fonctionner ton index.php ?)

En fonction de ton site, tu devrais pouvoir rapidement ejecter les requêtes incorrectes (comme par exemple les index.php?MAGICNUMBER), avec un certain code d’erreur peut-être, tu pourrais brancher fail2ban derrière pour ban les gens (avec des filtres pas trop restrictif)

#7

On est bien d’accord qu’ils ne seraient d’aucun secours dans le cas présent, mais que leur reproches-tu concrètement ? Certes leur utilisation peut dégrader les performances des connexions TCP, mais le noyau Linux ne les utilise qu’en cas de besoin (syn flood ou situation équivalente) ; si on a le choix entre pas de connexion (sans syncookies) et des connexions plus ou moins dégradées (avec syncookies), la dernière situation n’est-elle pas malgré tout préférable ?

#8

[quote=“haleth”]Mouais, je suis plus que mitigé par rapport aux syncookies, je pense vraiment que c’est le genre d’option à ne pas activer, au vu des problèmes engendrés;

M’enfin, je rejoins Pascal : il n’y a aucun rapport avec les SYNflood, entendu que la couche 7 obtient des informations (la session est donc montée)

Au vu de tes logs, j’ai du mal à comprendre comment ton serveur peut mourrir : il faut vraiment un gros volume pour tuer apache comme ça, sauf si ta machine est relativement sous-dimensionnée, ou que ton code est merdique (faut-il couper un arbre pour faire fonctionner ton index.php ?)

En fonction de ton site, tu devrais pouvoir rapidement ejecter les requêtes incorrectes (comme par exemple les index.php?MAGICNUMBER), avec un certain code d’erreur peut-être, tu pourrais brancher fail2ban derrière pour ban les gens (avec des filtres pas trop restrictif)[/quote]

Processor #1
Vendor
GenuineIntel
Name
Intel® Core™2 Duo CPU E7400 @ 2.80GHz
Speed
2793.000 MHz
Cache
3072 KB
Processor #2
Vendor
GenuineIntel
Name
Intel® Core™2 Duo CPU E7400 @ 2.80GHz
Speed
2793.000 MHz
Cache
3072 KB

au niveau des requetes, c est environ 1000 / second …

le code de mon site … et bien meme si je ferme le site : le supense dans Cpanel, apach plante …

#9

Faudrait peut être voir pour la mise en place d’un système de cache (varnish, apache mod reverse proxy, squid reverse proxy,xcache ce dernier est un module php) &/ou un CDN pour délivrer ton contenu statique et mettre en cache ton php ?

Edit : je sais que jréponds pas a ta question de départ hein, jte suggère juste des pistes.
Pour sécuriser apache tu peux voir du côté de mod_security

#10

[quote=“Kristy”]Faudrait peut être voir pour la mise en place d’un système de cache (varnish, apache mod reverse proxy, squid reverse proxy,xcache ce dernier est un module php) &/ou un CDN pour délivrer ton contenu statique et mettre en cache ton php ?

Edit : je sais que jréponds pas a ta question de départ hein, jte suggère juste des pistes.
Pour sécuriser apache tu peux voir du côté de mod_security[/quote]

J ai pris le CDN OVH pendant la premiere semaine ( ca va faire 3 semaien en tout )

et rien n’y fait,

j ai pris un VPS ou j ai install Squid3 en reverse proxy … pareil …

#11

Oki , je suppose que t’as regardé les :
guides.ovh.com/MachineSurchargeeApache2
guides.ovh.com/MachineSurchargeeApache1
guides.ovh.com/MachineSurchargeeApache3

??

Sinon vas y , le conseil du keep-alive qui doit etre mis à ON…
On dirait que ca ressemble à ta situation, t’es sur que ton cache fonctionne ? Ca à réduit la charge d’apache ou non ?
Ton cdn tourne fort ? :s
Ton site il buzz vraiment ou t’as l’impression plutot que c’est du flood ?

#12

[quote=“Kristy”]Oki , je suppose que t’as regardé les :
guides.ovh.com/MachineSurchargeeApache2
guides.ovh.com/MachineSurchargeeApache1
guides.ovh.com/MachineSurchargeeApache3

??

Sinon vas y , le conseil du keep-alive qui doit etre mis à ON…
On dirait que ca ressemble à ta situation, t’es sur que ton cache fonctionne ? Ca à réduit la charge d’apache ou non ?
Ton cdn tourne fort ? :s
Ton site il buzz vraiment ou t’as l’impression plutot que c’est du flood ?[/quote]

Le site a 7 ans, il tournai tres bien

OVH a confirmé l’attaque Flood , le CDN ca ne marche pas , car le site plante en 3 secondes apres redemarrage de apache

#13

Ah mais attend, t’as règle fail2ban elle fonctionnait non?
Elle devait juste “buggé” de temps en temps, pck s’il ban trop d’ip il faut ajouter un sleep dans le binaire non?
Pck ca me semble en faites la meilleur chose à faire :S.
Tu fais une règle fail2ban sur les requêtes index.php?XXXYZY.

#14

[quote=“Kristy”]Ah mais attend, t’as règle fail2ban elle fonctionnait non?
Elle devait juste “buggé” de temps en temps, pck s’il ban trop d’ip il faut ajouter un sleep dans le binaire non?
Pck ca me semble en faites la meilleur chose à faire :S.
Tu fais une règle fail2ban sur les requêtes index.php?XXXYZY.[/quote]

Non j ai pas reussi a faire fonctionné fail2ban …

#15

[quote=“jjm”]
Le site a 7 ans, il tournai tres bien

OVH a confirmé l’attaque Flood , le CDN ca ne marche pas , car le site plante en 3 secondes apres redemarrage de apache[/quote]
Oui, il tournait bien…
Mais ce n’est peut être plus le cas aujourd’hui :
-Tu as peut être été chanceux pendant 7 ans et pas eu ce genre de flood qui révèle peut être que ton site est une “usine à gaz”. On peut pas le savoir. Du coup, faudrait nous donner des détails, par exemple connaître le temps d’execution de ta page.
Je crois que pour MySQL tu as aussi Slow_queries, qui permet de te donner le nombre de requêtes qui ont dépassés le temps permis (ca pourrait déjà donner des indications si tu as des requêtes qui pompent).
-Si tu mets ton PHP à jour (enfin même si ce n’est pas le cas), actives les messages d’erreurs (config Apache), et tous … et là tu pourras te rendre compte > des éventuelles failles, des problèmes, et ainsi voir si cela vient du site ou pas.

Personnellement j’ai certains sites qui date de plus de 12/13 ans. Je me suis amusé à remettre en ligne il n’y a pas longtemps un des sites que j’avais fermé il y a 10 ans environ :smiling_imp: et bien, je te fais pas dire les centaines d’erreurs sur le bordel … et oui, PHP ca évolue, beaucoup de fonctionnalités deviennent obsolètes. Je l’ai fait pour faire une “démonstration” à un ami qui code avec ses pieds.

Pour faire des tests, voir si c’est bien ta page qui déconne, vu que c’est une index.php, remplace là par une index.html vierge. Réupdate ta index.php avec un nom comme index97.php et fais les tests. Supprime ensuite la page. (si les floodeurs font un scan, ils vont trouver ta page en 2 secondes) tu sauras si les problèmes viennent de ta page ou non… ca sera un début, si la moyenne de chargement de ta page c’est 2 secondes, alors c’est que ton site est mal programmé, ou ta base de données mal conçue, sûrement les deux. (la moyenne, c’est la somme des temps de chargement de ta page, divisée par ton nombre d’essais, genre 20 ou 30, voire beaucoup plus si tu t’amuses à créer un script pour automatiser les essais) Si tout tourne bien, c’est que tu as un problème coté logiciel (mauvaise config, ou autre)

Personnellement sur mes serveurs, j’active les erreurs, toutes… Comme ca, si il y a un problème, je le sais, je peux le corriger…

EDIT : si je suis pas clair sur quelque chose dis le moi, j’ai du taper mon message un peu rapidement, je dois y aller j’ai un rdv

#16

Salut,

Je suppose que le CMS utilisé est commun, quel est-il ?

cert.ssi.gouv.fr/site/CERTA-2007-INF-002/

phpsec.org/projects/guide/

J’ajouterai …

Nul n’a fait référence à un fichier .htaccess : [mono]37K … /var/www/Domaine.com/.htaccess[/mono] bien ficelé … :016

#17

[quote=“BelZéButh”]Salut,

Je suppose que le CMS utilisé est commun, quel est-il ?

cert.ssi.gouv.fr/site/CERTA-2007-INF-002/

phpsec.org/projects/guide/

J’ajouterai …

Nul n’a fait référence à un fichier .htaccess : [mono]37K … /var/www/Domaine.com/.htaccess[/mono] bien ficelé … :016[/quote]

Non c est un CMS perso … fait a l epoque pour nous, et refais en 2010 ,

pour le Htaccess c est ce que j avais essayé

RewriteCond %{THE_REQUEST} ^POST.index.php [NC]
RewriteRule . lock.php [L]

et lock;php enregistre tout les IP , la , j’ai fait un regle fail2ban … mais ca ne banni pas …

j’ai lu que mocsecurity pouvais geré les HTTP flood … je vais l installer et voir la

#18

Quatre ans se sont écoulés et php à évoluer, lui aussi … :think:

[quote=“jjm”]pour le Htaccess c est ce que j avais essayé

RewriteCond %{THE_REQUEST} ^POST.index.php [NC]
RewriteRule . lock.php [L][/quote]

Plutôt léger le .htacess. :083

#19

Pour le site,

je prend conscience que je dois le refaire, c est clair

pour le Htaccess , c est juste la partie pour cette attaque,

tu vois d 'autre chose a faire ?

#20

Avant de poursuivre …

Tu n’as fait nul référence à la version Debian (et ce qu’il s’en suit …) en place chez ovh.

En espérant qu’il ne s’agisse pas de : Etch, Lenny, Squeeze où plus ancien, hein … :016

ps : des sauvegardes, bien sûr :083