Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Linux Autres OS Linux Debian [HS] Syn flood, comment s'en débarrasser ?

[HS] Syn flood, comment s'en débarrasser ?

25 réponses
Avatar
Philippe Gras
Bonjour,

=E7a fait un mois environ que j=92ai des trucs comme =E7a avec netstat =
-antp :
=
--------------------------------------------------------------------------=
---------------------------------
tcp 0 0 X.XXX.XXX.XX:3306 174.36.59.12:36852 =
SYN_RECV - =20
tcp 0 0 X.XXX.XXX.XX:3306 174.36.59.12:53921 =
SYN_RECV - =20
tcp 0 0 X.XXX.XXX.XX:3306 174.36.59.12:56058 =
SYN_RECV - =20
tcp 0 0 X.XXX.XXX.XX:3306 174.36.59.12:16231 =
SYN_RECV - =20
tcp 0 0 X.XXX.XXX.XX:3306 174.36.59.12:30945 =
SYN_RECV - =20
tcp 0 0 X.XXX.XXX.XX:3306 186.2.161.165:1675 =
SYN_RECV - =20
tcp 0 0 X.XXX.XXX.XX:3306 174.36.59.12:58255 =
SYN_RECV - =20
=
--------------------------------------------------------------------------=
---------------------------------

D=92apr=E8s ce que je comprends, la requ=EAte aboutit sur un port lambda =
et demande
quelque chose sur celui de MySQL. Le service tourne sur un socket, il =
n=92y a rien
dans la colonne du PID.

Normalement, ma policy est DROP sur Netfilter.

1=B0 Je ne comprends pas comment des requ=EAtes peuvent =EAtre =
trait=E9es sur des
ports ferm=E9s.
2=B0 J=92ai ajout=E9 un module pour loguer les IP et les paquets, =
mais apparemment
rien n=92aboutit.
3=B0 Dois-je m=92inqui=E9ter de cet =E9tat de choses ?=

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/2B0C09E9-A3CD-496A-8BE9-7B463ADCF473@worldonline.fr
Signaler un problème avec ce contenu

5 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3
Avatar
Pascal Hambourg
Samuel a écrit :

C'est un peu large comme accès, je mettrais plutôt du genre (exemple sur
une chaine FORWARD à compléter selon besoins ):

iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED
--icmp-type source-quench -j ACCEPT



Ce type ICMP est obsolète est considéré comme dangereux car il peut
facilement être détourné pour provoquer un déni de service.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Avatar
Samuel
Le 21/06/2015 16:26, Pascal Hambourg a écrit :
Samuel a écrit :
C'est un peu large comme accès, je mettrais plutôt du genre (exemple sur
une chaine FORWARD à compléter selon besoins ):

iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED
--icmp-type source-quench -j ACCEPT


Ce type ICMP est obsolète est considéré comme dangereux car il peut
facilement être détourné pour provoquer un déni de service.



Merci pour l'information.

Hop, retiré du script.

Samuel.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Avatar
Philippe Gras
Le 21 juin 2015 à 16:18, Pascal Hambourg a écrit :

Philippe Gras a écrit :

ça fait un mois environ que j'ai des trucs comme ça avec netstat -antp :
-------------------------------------------------------------------------- ---------------------------------
tcp 0 0 X.XXX.XXX.XX:3306 174.36.59.12:36852 SYN_RECV -
tcp 0 0 X.XXX.XXX.XX:3306 174.36.59.12:53921 SYN_RECV -
tcp 0 0 X.XXX.XXX.XX:3306 174.36.59.12:56058 SYN_RECV -
tcp 0 0 X.XXX.XXX.XX:3306 174.36.59.12:16231 SYN_RECV -
tcp 0 0 X.XXX.XXX.XX:3306 174.36.59.12:30945 SYN_RECV -
tcp 0 0 X.XXX.XXX.XX:3306 186.2.161.165:1675 SYN_RECV -
tcp 0 0 X.XXX.XXX.XX:3306 174.36.59.12:58255 SYN_RECV -
-------------------------------------------------------------------------- ---------------------------------

D'après ce que je comprends, la requête aboutit sur un port lambda
et demande quelque chose sur celui de MySQL.



Non. Les demandes de connexion TCP (SYN) sont en provenance d'un port
distant quelconque (comme souvent) et à destination du port local 3306
(mysql).

Le service tourne sur un socket



Cette phrase ne veut rien dire.

il n'y a rien dans la colonne du PID.



La connexion n'est pas encore établie, donc il n'y a pas lieu de
l'associer à un processus.



Merci pour ces rectifications et précisions. Ça me permet de mieux comprendre
ce qui se passe :-)

Ph. Gras

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/




--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Avatar
Philippe Gras
Le 20 juin 2015 à 22:00, Jean-Michel OLTRA a écrit :

Le samedi 20 juin 2015, Philippe Gras a écrit...



Whouah ! Génial. Donc, je peux dropper tout le monde à l’exception de
l’IP de mon serveur, de son IP locale (127.0.0.1) et de la plage IP
sur laquelle mon FAI m’envoie ?



Je ne comprends pas trop ce que tu veux dire. Mais :

- Si le serveur sql et le serveur ouèbe (Nginx) sont sur la même
machine, tu mets le bind-address de mysql sur 127.0.0.1, et tu donnes
les grant de tes utilisateurs de tes sites ouèbe sur
Et tu peux dropper tout le monde. Ce qui ne devrait même pas, en
théorie, être nécessaire puisque l'accès n'est pas autorisé. Mais qui
va soulager le serveur sql.





Avant:
========================= ========================= =========
Connexions Internet actives (serveurs et établies)
Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Program name
tcp 0 0 0.0.0.0:17500 0.0.0.0:* LISTEN 12075/dropbox
tcp 0 0 127.0.0.1:17600 0.0.0.0:* LISTEN 12075/dropbox
tcp 0 0 127.0.0.1:17603 0.0.0.0:* LISTEN 12075/dropbox
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:53026 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:32338 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:45444 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:215 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 91.226.11.137:24940 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:24263 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:31851 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:23060 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 91.213.175.247:64786 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 91.213.175.247:57477 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 91.226.11.137:45752 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:49368 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 91.226.11.137:62817 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 91.226.11.137:53576 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:58913 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:50822 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:14773 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 91.213.175.247:5103 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:14316 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:60768 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:5372 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 91.226.11.137:63273 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:10811 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 91.226.11.137:62129 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 91.213.175.247:9430 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:23597 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:61150 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:39552 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 91.226.11.137:61192 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 91.226.11.137:58577 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:13750 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:44279 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:47996 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:37056 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:33076 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:47987 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:55933 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 91.213.175.247:23570 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:64358 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 91.226.11.137:59809 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 91.226.11.137:42917 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 91.226.11.137:6310 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:37447 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 91.213.175.247:45322 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:59556 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 91.226.11.137:57497 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:65501 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:33033 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:27291 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 91.226.11.137:11142 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:51702 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 91.226.11.137:50690 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:20311 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 91.213.175.247:57683 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:58525 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 91.226.11.137:21925 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:6103 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:42661 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:37353 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 91.226.11.137:52953 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 91.226.11.137:25283 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:24478 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:41997 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 91.226.11.137:20757 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:26290 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 91.213.175.247:45632 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 91.213.175.247:32520 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:31246 SYN_RECV -
tcp 0 0 x.xxx.xxx.xx:3306 104.223.215.4:14002 SYN_RECV -
tcp 0 0 127.0.0.1:11211 0.0.0.0:* LISTEN 31573/memcached
tcp 0 0 0.0.0.0:22220 0.0.0.0:* LISTEN 17140/sshd
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 8532/nginx
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 1042/proftpd: (acce
tcp 0 0 x.xxx.xxx.xx:53 0.0.0.0:* LISTEN 16528/named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 16528/named
tcp 0 0 0.0.0.0:4598 0.0.0.0:* LISTEN 5294/monit
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 15593/master
tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 16528/named

# Autoriser mysqld
iptables -t filter -A INPUT -p tcp -s localhost --dport 3306 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp -s localhost --dport 3306 -j ACCEPT
echo "MySqld OK »

Je suis allé vérifier sur un site, ça ne perturbe (évidemment) pas la visite :-)

Après:
========================= ========================= =========
Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Program name
tcp 0 0 0.0.0.0:17500 0.0.0.0:* LISTEN 12075/dropbox
tcp 0 0 127.0.0.1:17600 0.0.0.0:* LISTEN 12075/dropbox
tcp 0 0 127.0.0.1:17603 0.0.0.0:* LISTEN 12075/dropbox
tcp 0 0 127.0.0.1:11211 0.0.0.0:* LISTEN 31573/memcached
tcp 0 0 0.0.0.0:22220 0.0.0.0:* LISTEN 17140/sshd
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 8532/nginx
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 1042/proftpd: (acce
tcp 0 0 x.xxx.xxx.xx:53 0.0.0.0:* LISTEN 16528/named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 16528/named
tcp 0 0 0.0.0.0:4598 0.0.0.0:* LISTEN 5294/monit
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 15593/master
tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 16528/named

Merci à tous pour vos précieuses lumières :-) !!!!!

Maintenant, j’ai tout le reste à vérifier et éventuellement à réécrire au propre…

J’aimerais bien savoir si je peux appliquer le même traitement à Named ou Memcached, par exemple.

Ph. Gras

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
Avatar
Philippe Gras
Le 21 juin 2015 à 16:26, Pascal Hambourg a écrit :

Samuel a écrit :

C'est un peu large comme accès, je mettrais plutôt du genre (exemple sur
une chaine FORWARD à compléter selon besoins ):

iptables -A FORWARD -i $fai -o $lan -p icmp -m state --state RELATED
--icmp-type source-quench -j ACCEPT



Ce type ICMP est obsolète est considéré comme dangereux car il peut
facilement être détourné pour provoquer un déni de service.



Oui, j'ai compris pourquoi :-) Quand le serveur a instruction de DROP, il n'écoute pas.
Il ignore. Quand il a instruction de REJECT, il écoute et prend sa décision ensuite.

De ce fait, REJECT est pratiquement inopérant contre les attaques en masse.

Par contre, c'est vraiment très bien contre les spammeurs, qui règlent leur bot afin de
visiter une masse de site, puis de reprendre la liste du début.

À ce sujet, je viens de comprendre et d'apprendre autre chose.

Comme vous le savez maintenant, je mets mes règles de base dans un script.

Maintenant, j'affine mes règles en ligne de commande, ce qui me fait 2 couches pour
Netfilter (+ 1 autre encore avec fail2ban).

Le problème avec fail2ban, c'est qu'à chaque fois que je modifiais mon script de base
je devais recharger (reload) fail2ban pour qu'il réécrive par-dessus.

C'est pourquoi je préfère maintenant écrire des règles circonstancielles à la volée. Le
problème, c'est qu'il n'est pas facile de s'y retrouver. Mais on peut quand même mettre
un commentaire à sa règle :
https://major.io/2010/07/26/adding-comments-to-iptables-rules/

Ce qui nous donne par exemple :
# iptables -t filter -I INPUT -p tcp --dport 80 -s 121.205.238.186 -j REJECT --reject-with icmp-port-unreachable -m comment --comment "spamco soldat"
# iptables -n -v -L
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 REJECT tcp -- * * 121.205.238.186 0.0.0.0/0 tcp dpt:80 /* spamco soldat */

L'autre truc que j'ai compris, c'est la différence entre -I (insert) et -A (append).

Quand on met ses règles dans un script, on le fait avec -A et toutes s'exécutent dans
l'ordre du script. Par contre, si on fait pareil à la volée, cette règle qu'on ajoute ainsi a
l'inconvénient de s'exécuter tout à la fin de la table (INPUT par ex.).

Ce qui a pour conséquence de ne rien changer du tout !

Ce qu'il faut faire, c'est le mettre en -I insertion pour que la nouvelle règle se place au
dessus des autres.

Avant de comprendre cela (j'ai le cerveau lent) j'ai fait plein d'erreurs. On peut corriger
facilement, car les lignes sont numérotées :
# iptables -L --line-numbers

On supprime ensuite la ligne eronée :
# iptables -D INTPUT X

où X est le numéro de la ligne à effacer :-)

Par contre, est-ce que je peux effacer une ligne eronnée qui se trouve dans mon script
sans toucher à mon script ?


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/




--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
1 2 3