PIRATAGE: Possible SYN flooding

Support Debian
#1

Hello à tous!

Sur mon serveur “maison”, logcheck m’informe de la chose suivante

[quote]> System Events

21 =-=-=-=-=-=-=
22 Nov 5 23:33:12 matrix kernel: [3821641.107125] TCP: Possible SYN flooding on port 8118. Sending cookies. Check SNMP counters

[/quote]

Effectivement, je constate cela avec la commande netstat -ant | grep SYN_RECV

[quote]tcp 0 0 192.168.0.16:8118 61.147.96.160:25428 SYN_RECV
tcp 0 0 192.168.0.16:8118 117.21.191.152:8564 SYN_RECV
tcp 0 0 192.168.0.16:8118 218.2.22.92:7199 SYN_RECV
tcp 0 0 192.168.0.16:8118 218.2.22.92:37022 SYN_RECV
tcp 0 0 192.168.0.16:8118 31.134.231.131:49213 SYN_RECV
tcp 0 0 192.168.0.16:8118 63.143.33.2:1589 SYN_RECV
tcp 0 0 192.168.0.16:8118 64.31.18.123:1237 SYN_RECV
tcp 0 0 192.168.0.16:8118 204.152.201.200:4397 SYN_RECV
tcp 0 0 192.168.0.16:8118 216.244.78.121:3222 SYN_RECV
tcp 0 0 192.168.0.16:8118 107.152.252.82:1676 SYN_RECV
tcp 0 0 192.168.0.16:8118 61.176.221.21:4405 SYN_RECV
tcp 0 0 192.168.0.16:8118 192.155.96.105:2808 SYN_RECV
tcp 0 0 192.168.0.16:8118 61.147.96.163:49308 SYN_RECV
tcp 0 0 192.168.0.16:8118 216.244.76.85:2669 SYN_RECV
tcp 0 0 192.168.0.16:8118 192.151.152.243:3719 SYN_RECV
tcp 0 0 192.168.0.16:8118 174.139.25.18:1966 SYN_RECV
tcp 0 0 192.168.0.16:8118 198.20.175.133:4249 SYN_RECV
tcp 0 0 192.168.0.16:8118 162.211.126.236:1451 SYN_RECV
tcp 0 0 192.168.0.16:8118 63.143.52.210:2850 SYN_RECV
tcp 0 0 192.168.0.16:8118 192.155.106.109:4257 SYN_RECV
tcp 0 0 192.168.0.16:8118 182.236.163.20:11709 SYN_RECV
tcp 0 0 192.168.0.16:8118 192.187.124.108:2746 SYN_RECV
tcp 0 0 192.168.0.16:8118 61.176.221.21:4358 SYN_RECV
tcp 0 0 192.168.0.16:8118 174.139.25.18:3562 SYN_RECV
tcp 0 0 192.168.0.16:8118 216.244.76.88:3993 SYN_RECV
tcp 0 0 192.168.0.16:8118 198.204.253.248:2676 SYN_RECV
tcp 0 0 192.168.0.16:8118 62.173.154.209:51658 SYN_RECV
tcp 0 0 192.168.0.16:8118 192.241.70.76:2501 SYN_RECV
tcp 0 0 192.168.0.16:8118 208.115.125.74:1816 SYN_RECV
tcp 0 0 192.168.0.16:8118 208.115.125.120:1778 SYN_RECV
tcp 0 0 192.168.0.16:8118 174.139.16.26:4375 SYN_RECV
tcp 0 0 192.168.0.16:8118 107.167.44.160:1238 SYN_RECV
tcp 0 0 192.168.0.16:8118 218.2.22.92:49602 SYN_RECV
tcp 0 0 192.168.0.16:8118 41.140.171.250:49784 SYN_RECV
tcp 0 0 192.168.0.16:8118 162.211.125.76:3945 SYN_RECV
[/quote]

Je ne vais pas “flooder” à mon tour, cette liste est donc non exhaustive, avec un [quote]wc -l[/quote] je constate jusque 115 connexions sur le serveur.

Il s’agit bien d’une indication d’une attaque par déni de service?

J’ai trouvé cette contre-attaque :

http://www.debian.org/doc/manuals/securing-debian-howto/ch11.fr.html section 11.2.5

Qu’en pensez vous?

Je dois dire que je suis un peu juste en termes de connaissances sur la sécurité…en installation un p’tit serveur maison, je ne me doutais pas de me prendre autant d’attaque, pourquoi attaquer mon serveur par Ddos?

Merci pour vos aides, remarques, réconforts ( :smiley: )

#2

En suivant les indications ici http://www.tux-planet.fr/contrer-une-attaque-ddos-de-type-syn-flood-sous-linux/

Les attaques sont toujours présentes mais moindre en nombre, une dizaine de flood SYN, par contre cela consomme presque à 100% le CPU…

Je vais regarder du côté de http://floodmon.sourceforge.net/

En attendant, je coupe le serveur!

#3

Tu as Fail2ban d’installé ?

#4

Si c’est du DDOS il les fait a la main :laughing:
Non 115 c’est un chiffre ridiculement bas, quand tu auras un résultat avec 4 ou 5 chiffre on en reparle.
Je verrais plus un snif de port ou tout du moins quelque chose de bien plus ciblé.

#5

@ricardo: non, fail2ban n’est pas configuré, je le met en place très rapidement.

@mimoza: oui, je me doute que c’est un nombre très bas mais cela rend mon CPU occupé à 100%. c’est le port 8118 qui es visé, il est utilisé par privoxy sur mon serveur.

Pourquoi cibler ce port?

#6

Donc tu fais tourner courageusement un proxy anonymisant sur ta machine. Le “syn flood” détecté est probablement du aux machines qui connaissent ton proxy et qui vérifient régulièrement si le proxy est toujours en vie pour pouvoir mettre à jour leurs listes.

115 connections, c’est effectivement un chiffre modeste.

Si c’est bien un ou plusieurs processus de privoxy qui chargent le processeur du dit serveur à 100%, c’est très probablement à cause de l’emploi important d’expressions régulières (regex) appliquées aux documents web.
Dans la FAQ de privoxy, ils parlent de ce problème à plusieurs occasions.
Il te faudra désactiver le maximum de fonctionnalités du genre filtrage dans la configuration de privoxy jusqu’à que ce phénomène n’aie plus lieu.

–
AnonymousCoward

#7

Merci AnonymousCoward, c’est très clair; je consulte par ailleurs la FAQ de Privoxy

#8

Ah ? Et ils ont pour habitude de ne pas répondre au SYN/ACK du serveur pour confirmer leurs demandes de connexion ? Pour rappel, l’état SYN_RECEIVED signifie qu’un paquet SYN a été reçu mais non confirmé par un ACK. Normalement cet état doit durer très peu de temps, entre l’émission du SYN/ACK par le serveur et la réception de l’ACK émis en réponse par le client. Donc soit le serveur reçoit énormément de connexions régulières et ce qu’on voit est la petite fraction de celles-ci qui n’ont pas encore été confirmées (dans ce cas netstat devrait aussi montrer beaucoup de connexions dans l’état ESTABLISHED), soit il s’agit bel et bien d’un SYN flood.

#9

Oui. Par exemple nmap avec les droits root fait cela par défaut. Il envoie ensuite éventuellement un paquet avec le flag RST (ce qui n’est pas vraiment la manière normale de fermer une connexion TCP).

Il est possible que le serveur reçoive effectivement beaucoup de connexions. Mais du syn-flood, soyons sérieux… Cela fait depuis 1997 que cela ne fait plus quoi que ce soit aux systèmes Linux à part de prendre de la bande passante.

–
AnonymousCoward

#10

J’aurais dû écrire “Et ils ont pour habitude de ne pas répondre au SYN/ACK du serveur pour confirmer ou annuler leurs demandes de connexion ?” Un RST est une réponse qui termine la connexion et ne la laisse pas dans l’état SYN_SENT, à moins que les règles iptables du serveur bloquent indument les paquets RST.

#11

J’ai lu qu’une façon de se protéger d’un flood SYN est de passer des règles à iptables. (blog.jeremm.fr/?tag=syn-flood)

Pour ma part, celui-ci n’est pas configuré sur ma machine, je passe par un modem câble castlenet (numericable). assistance.numericable.fr/Presen … 100-M.html

Si je veux configurer iptables, je dois désactiver le mode pare-feu du modem?

#12

Bonjour,

Non tu n’es pas obligé de couper le FW de ta box, tu peux faire des règles de filtrage iptables qui concernent uniquement ta machine locale.

#13

Bonjour,

Après avoir passé un peu de temps à tester privoxy, il y a plusieurs petits problèmes avec ce logiciel.

Par exemple, n’ai jamais pu faire fonctionner correctement les directives de configuration [mono]permit-access[/mono] et [mono]deny-access[/mono]. Et donc, sans prendre de précaution particulière, le proxy donne accès libre à tous les serveurs web sur le LAN dont l’interface web du modem/routeur. (en passant par le proxy pour accéder à http://192.168.0.1/)

Pour ajouter la règle évitant cela avec iptables : [mono]iptables -t filter -A OUTPUT -m owner --uid-owner privoxy --dst 192.168.0.0/24 -j REJECT[/mono]

Tout cela ne me donne pas trop confiance dans le logiciel pour assurer un service de proxy public.

–
AnonymousCoward

#14

Salut,

[mono]sysctl.conf[/mono] te préservera les miches.

#15

C’est un peu court, je trouve. Peux-tu développer ?

#16

Un chiffre ridiculement bas ?

29% [robert:~]cat /proc/sys/net/ipv4/tcp_max_syn_backlog
128

115, c’est la quasi-saturation du backlog, ce qui empêche les nouvelles connexions TCP

Tu devrais pouvoir t’en débarrasser avec fail2ban.
Cependant, les paquets SYN peuvent être “forgé” très facilement, la mise en place d’un tel filtrage permettra à n’importe qui de ban n’importe qui. C’est donc une très mauvaise idée.

L’autre solution, qui est mieux, est d’activer les syncookies:

echo 1 | sudo tee /proc/sys/net/ipv4/tcp_syncookies

Au passage, je note que c’est la valeur par défaut sous Jessie