[IPTABLES] Comment lister les paquets rejetés ?

Philippe Gras

unread,

Jun 7, 2014, 5:30:02 AM6/7/14

to

Bonjour à toutes et à tous,

suite à une attaque, j'ai restreint les accès sur le port 80 de mon serveur avec Iptables :

===================================================================

~# iptables -L INPUT -nvx

Chain INPUT (policy DROP 7178 packets, 2268524 bytes)

pkts bytes target prot opt in out source destination

9 774 DROP tcp -- * * 0.0.0.0/0 XXX.XXX.XXX tcp dpt:80 STRING match "GET /w00tw00t.at." ALGO name bm TO 70

40 9636 DROP tcp -- * * 0.0.0.0/0 XXX.XXX.XXX tcp dpt:80 STRING match "Host: XXX.XXX.XXX" ALGO name bm TO 600

93193 37333670 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED

7530 566937 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0

330 26804 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0

0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED

4480 234832 tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80flags: 0x02/0x02 recent: SET name: web side: source

13 780 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80flags: 0x02/0x02 recent: UPDATE seconds: 5 hit_count: 10 name: web side: source

38 1992 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80flags: 0x02/0x02 limit: above 3/sec burst 7 mode srcip srcmask 28

4392 230136 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80flags: 0x02/0x02 limit: avg 7/sec burst 12

37 1924 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80flags: 0x02/0x02

===================================================================

Y a-t-il un moyen de lister les paquets rejetés pour vérifier que mes règles sont conformes

à ce que je souhaitais faire ?

D'autant plus que le serveur virtuel que j'utilise n'est pas Apache, mais NginX. J'ai peur que

les match string soient un peu différentes…

Je me suis servi de ressources sur le Web. Je peux vous les communiquer en cas de besoin.

D'avance, merci pour vos lumières…

Ph. Gras

nb

unread,

Jun 7, 2014, 7:30:02 AM6/7/14

to

Le Samedi 7 Juin 2014 11:22 CEST, Philippe Gras <ph....@worldonline.fr> a écrit:

> Bonjour à toutes et à tous,
>
> suite à une attaque, j'ai restreint les accès sur le port 80 de mon serveur avec Iptables :
> ===================================================================
> ~# iptables -L INPUT -nvx
> Chain INPUT (policy DROP 7178 packets, 2268524 bytes)
> pkts bytes target prot opt in out

> ===================================================================
> Y a-t-il un moyen de lister les paquets rejetés pour vérifier que mes
> règles sont conformes
> à ce que je souhaitais faire ?

Je pense que tu peux utiliser LOG avant DROP. Ca ira dans la log système

--
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-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Archive: https://lists.debian.org/7fd0-5392f600-3-46a5ca00@89467399

Jean-Michel OLTRA

unread,

Jun 7, 2014, 7:40:02 AM6/7/14

to

Bonjour,

Le samedi 07 juin 2014, Philippe Gras a écrit...

> Y a-t-il un moyen de lister les paquets rejetés pour vérifier que mes règles
> sont conformes
> à ce que je souhaitais faire ?

Tu peux loger les paquets qui correspondent à une règle. Il suffit de
mettre la règle « -j LOG » juste avant la règle qui jette, avec une
option --log-prefix parlante pour toi. Quand tu es bon sur la règle, tu
vires le logging.

--
jm

--
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-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org

Archive: https://lists.debian.org/20140607111203.GA7830@espinasse

Philippe Gras

unread,

Jun 7, 2014, 8:20:01 AM6/7/14

to

Le 7 juin 14 à 13:12, Jean-Michel OLTRA a écrit :

Bonjour,

Le samedi 07 juin 2014, Philippe Gras a écrit...

Y a-t-il un moyen de lister les paquets rejetés pour vérifier que mes règles
sont conformes
à ce que je souhaitais faire ?

Tu peux loger les paquets qui correspondent à une règle. Il suffit de
mettre la règle « -j LOG » juste avant la règle qui jette, avec une
option --log-prefix parlante pour toi. Quand tu es bon sur la règle, tu
vires le logging.

--
jm

OK et merci !

c'est une bonne idée, je vais plancher dessus :-)

Pendant que j'y suis, j'ai réussi à dropper le pirate pendant son action ! J'ai eu

l'impression que ça a eu un effet très déstabilisant.

C'était du brute force et non du ddos, donc son script n'avait de conséquences

que dans l'administration : 15.000 requêtes par jour et par action, sur la même

page, et tout le backend ramait comme pas possible !

Ça vous intéresse de savoir comment j'ai fait ?

Ph. Gras

andre_...@numericable.fr

unread,

Jun 7, 2014, 8:40:01 AM6/7/14

to

On Saturday 07 June 2014 14:18:23 Philippe Gras wrote:
> C'était du brute force et non du ddos, donc son script n'avait de
> conséquences que dans l'administration : 15.000 requêtes par jour
> et par action, sur la même page, et tout le backend ramait
> comme pas possible !

> Ça vous intéresse de savoir comment j'ai fait ?
> Ph. Gras

Oui,
car mon site reçoit des requêtes permanentes
sur des pages obsolètes et/ou sur des chemins qui
n'existent pas... etc :
400 Bad Request
403 Forbidden
404 Not Found
302 tentative d'attaques

André

--
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-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org

Archive: https://lists.debian.org/201406071431.29...@numericable.fr

Philippe Gras

unread,

Jun 7, 2014, 12:20:02 PM6/7/14

to

Le 7 juin 14 à 14:31, andre_...@numericable.fr a écrit :

On Saturday 07 June 2014 14:18:23 Philippe Gras wrote:

C'était du brute force et non du ddos, donc son script n'avait de
conséquences que dans l'administration : 15.000 requêtes par jour
et par action, sur la même page, et tout le backend ramait
comme pas possible !

Ça vous intéresse de savoir comment j'ai fait ?
Ph. Gras

Oui,
car mon site reçoit des requêtes permanentes
sur des pages obsolètes et/ou sur des chemins qui
n'existent pas... etc :
400 Bad Request
403 Forbidden
404 Not Found

Pour ce qui est des 400, de certaines 404 et 403, je pense que tu peux t'inspirer de ça:

http://spamcleaner.org/fr/misc/w00tw00t.html

Je vais d'ailleurs le faire moi-même, parce que j'ai plein de requêtes avec cette chaîne :

FCKeditor qui doit correspondre à un espace d'administration d'un CMS quelconque et

ça correspondrait à de l'exploit.

302 tentative d'attaques

Par contre, pour celles qui correspondent à ton, ou tes domaines et les redirections 302

tu ferais mieux de les laisser accessibles, pour ne pas cramer ton référencement naturel.

Mais ce que j'ai réussi à faire n'a rien à voir puisqu'il s'agissait de bannir le pirate en train

d'attaquer. Ça l'a stoppé net une première fois, il a changé de serveur et d'IP, mais j'ai pu

le remarquer, et recommencer. Il a abandonné cette nuit-là. Ça dure depuis lundi.

=====================================================================

# iptables -A INPUT -p tcp --dport 80 -s 72.44.248.136 -j DROP

# iptables -A INPUT -p tcp --dport 80 -s 66.23.229.10 -j DROP

# iptables -A INPUT -m state --state RELATED,ESTABLISHED -p tcp --dport 80 -s 72.44.248.136 -j DROP

# iptables -A INPUT -m state --state RELATED,ESTABLISHED -p tcp --dport 80 -s 66.23.229.10 -j DROP

=====================================================================

Dans mes logs, ça donne ça :

=====================================================================

72.44.248.136 - - [06/Jun/2014:00:55:58 +0200] "POST /wp-login.php HTTP/1.0" 403 168 "-" "-"

72.44.248.136 - - [06/Jun/2014:00:55:59 +0200] "POST /wp-login.php HTTP/1.0" 403 168 "-" "-"

66.23.229.10 - - [06/Jun/2014:00:56:05 +0200] "POST /wp-login.php HTTP/1.0" 403 168 "-" "-"

66.23.229.10 - - [06/Jun/2014:00:56:06 +0200] "POST /wp-login.php HTTP/1.0" 403 168 "-" "-"

=====================================================================

L'astuce, c'est après avoir rejeté l'IP en INPUT, on la rejette en RELATED,ESTABLISHED

également (parce que le bot est connecté). Ça le déconnecte, et il ne peut plus revenir se

connecter une nouvelle fois. Enjoy !

Francois Lafont

unread,

Jun 7, 2014, 1:40:02 PM6/7/14

to

Bonjour,

Le 07/06/2014 18:16, Philippe Gras a écrit :

> =====================================================================
> # iptables -A INPUT -p tcp --dport 80 -s 72.44.248.136 -j DROP
> # iptables -A INPUT -p tcp --dport 80 -s 66.23.229.10 -j DROP
> # iptables -A INPUT -m state --state RELATED,ESTABLISHED -p tcp --dport 80 -s 72.44.248.136 -j DROP
> # iptables -A INPUT -m state --state RELATED,ESTABLISHED -p tcp --dport 80 -s 66.23.229.10 -j DROP
> =====================================================================

Sauf erreur de ma part, les deux dernière règles ci-dessus
sont inutiles. Si ça matche pour l'une d'entre elles, ça
matchera de toute façon pour une des deux premières.

--
François Lafont

--
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-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org

Archive: https://lists.debian.org/53934DC3...@free.fr

Philippe Gras

unread,

Jun 7, 2014, 1:50:01 PM6/7/14

to

Le 7 juin 14 à 19:37, Francois Lafont a écrit :

Bonjour,

Le 07/06/2014 18:16, Philippe Gras a écrit :

=====================================================================
# iptables -A INPUT -p tcp --dport 80 -s 72.44.248.136 -j DROP
# iptables -A INPUT -p tcp --dport 80 -s 66.23.229.10 -j DROP
# iptables -A INPUT -m state --state RELATED,ESTABLISHED -p tcp --dport 80 -s 72.44.248.136 -j DROP
# iptables -A INPUT -m state --state RELATED,ESTABLISHED -p tcp --dport 80 -s 66.23.229.10 -j DROP
=====================================================================

Sauf erreur de ma part, les deux dernière règles ci-dessus
sont inutiles. Si ça matche pour l'une d'entre elles, ça
matchera de toute façon pour une des deux premières.

Non, en fait. Si le client est déjà connecté sur le serveur, INPUT ne matche pas.

C'était le cas pour moi. J'ai vu que ça ramait dans le backend, et je suis allé voir

les logs, et c'est là que j'ai remarqué le manège… J'ai d'abord établi la première

règle, mais il était toujours là à taper dans le mur.

Il faut d'abord le dropper en RELATED ou ESTABLISHED, et ensuite, il n'a plus

la possibilité de revenir, à cause du drop en INPUT.

Après avoir rejeté la première IP, le gars est revenu avec une deuxième.

J'ai établi une deuxième série de 2 règles, et il a laissé tomber. Il était déjà tard.

Ph. Gras

Christophe

unread,

Jun 7, 2014, 2:10:02 PM6/7/14

to

Bonsoir,

Le 07/06/2014 19:37, Francois Lafont a écrit :
>
>> =====================================================================
>> # iptables -A INPUT -p tcp --dport 80 -s 72.44.248.136 -j DROP
>> # iptables -A INPUT -p tcp --dport 80 -s 66.23.229.10 -j DROP
>> # iptables -A INPUT -m state --state RELATED,ESTABLISHED -p tcp --dport 80 -s 72.44.248.136 -j DROP
>> # iptables -A INPUT -m state --state RELATED,ESTABLISHED -p tcp --dport 80 -s 66.23.229.10 -j DROP
>> =====================================================================
>
> Sauf erreur de ma part, les deux dernière règles ci-dessus
> sont inutiles. Si ça matche pour l'une d'entre elles, ça
> matchera de toute façon pour une des deux premières.
>

J'aurais tendance à être d'accord avec ca : les deux premières règles
doivent matcher , quelque soit l'état de la connexion.

@+
Christophe.

--
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-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org

Archive: https://lists.debian.org/5393543F...@stuxnet.org

Christophe

unread,

Jun 7, 2014, 2:40:01 PM6/7/14

to

Bonsoir,

Le 07/06/2014 20:31, Philippe Gras a écrit :
> Non, justement pas quel que soit l'état de la connexion, et c'est logique.
>
> On n'aurait pas de règle pour les connexions établies, sinon ;-)
>

Euh ...

-m précise un module complémentaire à ta règle .

en l'occurrence -m state

S'il n'est pas précisé , ta règle matche quelque soit le 'state' .
Qu'il soit NEW, ESTABLISHED, RELATED, INVALID, ...

@+
Christophe.

--
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-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org

Archive: https://lists.debian.org/53935B96...@stuxnet.org

Philippe Gras

unread,

Jun 7, 2014, 2:40:01 PM6/7/14

to

Le 7 juin 14 à 20:04, Christophe a écrit :

> Bonsoir,
>
> Le 07/06/2014 19:37, Francois Lafont a écrit :
>>
>>> ====================================================================
>>> =
>>> # iptables -A INPUT -p tcp --dport 80 -s 72.44.248.136 -j DROP
>>> # iptables -A INPUT -p tcp --dport 80 -s 66.23.229.10 -j DROP
>>> # iptables -A INPUT -m state --state RELATED,ESTABLISHED -p tcp --
>>> dport 80 -s 72.44.248.136 -j DROP
>>> # iptables -A INPUT -m state --state RELATED,ESTABLISHED -p tcp --
>>> dport 80 -s 66.23.229.10 -j DROP

>>> ====================================================================

>>> =
>>
>> Sauf erreur de ma part, les deux dernière règles ci-dessus
>> sont inutiles. Si ça matche pour l'une d'entre elles, ça
>> matchera de toute façon pour une des deux premières.
>>
>
> J'aurais tendance à être d'accord avec ca : les deux premières règles
> doivent matcher , quelque soit l'état de la connexion.

Non, justement pas quel que soit l'état de la connexion, et c'est
logique.

On n'aurait pas de règle pour les connexions établies, sinon ;-)

>

> @+
> Christophe.
>
> --
> 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-f...@lists.debian.org
> En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
> Archive: https://lists.debian.org/5393543F...@stuxnet.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 debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org

Archive: https://lists.debian.org/6B7FC62A-8CF6-469B...@worldonline.fr

Philippe Gras

unread,

Jun 7, 2014, 2:50:01 PM6/7/14

to

Le 7 juin 14 à 20:36, Christophe a écrit :

> Bonsoir,
>
> Le 07/06/2014 20:31, Philippe Gras a écrit :
>> Non, justement pas quel que soit l'état de la connexion, et c'est
>> logique.
>>
>> On n'aurait pas de règle pour les connexions établies, sinon ;-)
>>
>
> Euh ...
>
> -m précise un module complémentaire à ta règle .
>
> en l'occurrence -m state
>
> S'il n'est pas précisé , ta règle matche quelque soit le 'state' .
> Qu'il soit NEW, ESTABLISHED, RELATED, INVALID, ...

J'en ai fait l'expérience jeudi, et je me souviens que ça n'a pas
marché.

>
> @+
> Christophe.
>
> --
> 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-f...@lists.debian.org
> En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
> Archive: https://lists.debian.org/53935B96...@stuxnet.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 debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org

Archive: https://lists.debian.org/27F7BD1E-2B9A-4F47...@worldonline.fr

nb

unread,

Jun 7, 2014, 5:10:02 PM6/7/14

to

Le Samedi 7 Juin 2014 20:36 CEST, Christophe <te...@stuxnet.org> a écrit:

> Bonsoir,
>
> Le 07/06/2014 20:31, Philippe Gras a écrit :
> > Non, justement pas quel que soit l'état de la connexion, et c'est logique.
> >
> > On n'aurait pas de règle pour les connexions établies, sinon ;-)

Philippe a raison.
INPUT ne sert pas pour une connexion déjà établie, seulement pour l'établissement d'une connexion (paquet tcp syn)

Mais tout ceci n'est pas très Debian...

--
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-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org

Archive: https://lists.debian.org/7fd0-53937e80-7-46a5ca00@89467401

Philippe Gras

unread,

Jun 7, 2014, 5:20:01 PM6/7/14

to

> INPUT ne sert pas pour une connexion déjà établie, seulement pour
> l'établissement d'une connexion (paquet tcp syn)

Merci de venir à mon secours :-) Autre chose que je n'ai pas bien
capté : la différence entre -A (add) et -I (insert).

>
> Mais tout ceci n'est pas très Debian...

C'est vrai, mais ça rentre bien à l'intérieur. Je n'ai pas vu de
forum spécifique à iptables, alors je tente ma chance.

>
> --
> 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-f...@lists.debian.org
> En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
> Archive: https://lists.debian.org/7fd0-53937e80-7-46a5ca00@89467401
>

--
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-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org

Archive: https://lists.debian.org/588F56AD-4FE5-40A3...@worldonline.fr

nb

unread,

Jun 7, 2014, 5:30:02 PM6/7/14

to

Le Samedi 7 Juin 2014 23:12 CEST, Philippe Gras <ph....@worldonline.fr> a écrit:

> > INPUT ne sert pas pour une connexion déjà établie, seulement pour
> > l'établissement d'une connexion (paquet tcp syn)
>
> Merci de venir à mon secours :-) Autre chose que je n'ai pas bien
> capté : la différence entre -A (add) et -I (insert).

Il faut voir "A" comme append. Ajout en fin de liste de règles.
"I", c'est un insert au début.

Cooncernant tes règles "ESTABLISHED" il serait judicieux de les taper en interactif. Elles n'ont pas trop leur place dans un script après les règles INPUT.

Bonne nuit

--
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-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org

Archive: https://lists.debian.org/7fd0-53938280-b-46a5ca00@89467403

Christophe

unread,

Jun 7, 2014, 6:30:01 PM6/7/14

to

Bonjour,

Le 07/06/2014 23:21, nb a écrit :
>
> Le Samedi 7 Juin 2014 23:12 CEST, Philippe Gras <ph....@worldonline.fr> a écrit:
>
>>> INPUT ne sert pas pour une connexion déjà établie, seulement pour
>>> l'établissement d'une connexion (paquet tcp syn)

Pas tout à fait d'accord avec ça, mais rien à voir avec Debian, comme tu
l'as précédemment précisé ...
(c'est du noyau linux dont il est question ici).

>>
>> Merci de venir à mon secours :-) Autre chose que je n'ai pas bien
>> capté : la différence entre -A (add) et -I (insert).
>
> Il faut voir "A" comme append. Ajout en fin de liste de règles.
> "I", c'est un insert au début.

J'approuve.

>
> Cooncernant tes règles "ESTABLISHED" il serait judicieux de les taper en interactif. Elles n'ont pas trop leur place dans un script après les règles INPUT.

La, il va falloir que tu éclaires quelques lanternes ... ;)

@+
Christophe.

--
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-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org

Archive: https://lists.debian.org/53939237...@stuxnet.org

r...@rootshell.tk

unread,

Jun 7, 2014, 7:00:02 PM6/7/14

to

Le 08/06/2014 00:29, Christophe a écrit :
>> >Cooncernant tes règles "ESTABLISHED" il serait judicieux de les taper en interactif. Elles n'ont pas trop leur place dans un script après les règles INPUT.
> La, il va falloir que tu éclaires quelques lanternes ...;)

Je suis également curieux d'entendre nb à ce sujet.

--
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-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org

Archive: https://lists.debian.org/539397AC...@rootshell.tk

Philippe Gras

unread,

Jun 7, 2014, 7:00:02 PM6/7/14

to

Le 8 juin 14 à 00:29, Christophe a écrit :

> Bonjour,
>
> Le 07/06/2014 23:21, nb a écrit :
>>
>> Le Samedi 7 Juin 2014 23:12 CEST, Philippe Gras
>> <ph....@worldonline.fr> a écrit:
>>
>>>> INPUT ne sert pas pour une connexion déjà établie, seulement pour
>>>> l'établissement d'une connexion (paquet tcp syn)
>
> Pas tout à fait d'accord avec ça, mais rien à voir avec Debian,
> comme tu
> l'as précédemment précisé ...
> (c'est du noyau linux dont il est question ici).
>
>>>
>>> Merci de venir à mon secours :-) Autre chose que je n'ai pas bien
>>> capté : la différence entre -A (add) et -I (insert).
>>
>> Il faut voir "A" comme append. Ajout en fin de liste de règles.
>> "I", c'est un insert au début.
>
> J'approuve.

J'ai l'impression que ça sert surtout en ligne de commande. Rectifiez-
moi si je me trompe !
Parce que la subtilité m'échappe. Moi, j'ai un script avec des -P au
début pour définir toute
la police, et ensuite, je n'ai que des -A. Mais si ça se trouve, ça
devrait être des -N partout ?

>
>>
>> Cooncernant tes règles "ESTABLISHED" il serait judicieux de les
>> taper en interactif. Elles n'ont pas trop leur place dans un
>> script après les règles INPUT.
>
> La, il va falloir que tu éclaires quelques lanternes ... ;)

Oui, pourquoi ?

Sinon, j'ai bien mes journaux dans /var/log/messages (c'est Debian,
ça °0°) :
========================================================================
Jun 7 23:59:01 XXXXXX kernel: iptables hashlimitIN=eth0 OUT=
MAC=00:22:4d:87:b4:27:10:8c:cf:28:fe:40:08:00 SRC=108.162.229.108
DST=XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=59 ID=37922 DF
PROTO=TCP SPT=38185 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0
Jun 7 23:59:01 XXXXXX kernel: iptables hashlimitIN=eth0 OUT=
MAC=00:22:4d:87:b4:27:10:8c:cf:28:fe:40:08:00 SRC=108.162.229.111
DST=XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=59 ID=30464 DF
PROTO=TCP SPT=38193 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0
Jun 7 23:59:01 XXXXXX kernel: iptables hashlimitIN=eth0 OUT=
MAC=00:22:4d:87:b4:27:10:8c:cf:28:fe:40:08:00 SRC=108.162.229.107
DST=XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=59 ID=8650 DF PROTO=TCP
SPT=11132 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0
Jun 7 23:59:02 XXXXXX kernel: iptables hashlimitIN=eth0 OUT=
MAC=00:22:4d:87:b4:27:10:8c:cf:28:fe:40:08:00 SRC=108.162.229.108
DST=XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=59 ID=37923 DF
PROTO=TCP SPT=38185 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0
Jun 7 23:59:02 XXXXXX kernel: iptables hashlimitIN=eth0 OUT=
MAC=00:22:4d:87:b4:27:10:8c:cf:28:fe:40:08:00 SRC=108.162.229.111
DST=XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=59 ID=30465 DF
PROTO=TCP SPT=38193 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0
Jun 7 23:59:02 XXXXXX kernel: iptables hashlimitIN=eth0 OUT=
MAC=00:22:4d:87:b4:27:10:8c:cf:28:fe:40:08:00 SRC=108.162.229.107
DST=XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=59 ID=8651 DF PROTO=TCP
SPT=11132 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0
========================================================================
=
Ça correspond à :
210 11112 LOG tcp -- * *

0.0.0.0/0 0.0.0.0/0 tcp dpt:80flags: 0x02/0x02

limit: above 3/sec burst 7 mode srcip srcmask 28 LOG flags 0 level 4
prefix "iptables hashlimit"
========================================================================
==
C'est parfait, merci Jean-Michel ! Les IP correspondent à celles de
Cloudflare, il va falloir que je
me renseigne pour les convertir, si possible…

>
> @+
> Christophe.
>
>
>
> --
> 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-f...@lists.debian.org
> En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
> Archive: https://lists.debian.org/53939237...@stuxnet.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 debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org

Archive: https://lists.debian.org/627183CD-C732-4E9C...@worldonline.fr

nb

unread,

Jun 8, 2014, 3:20:02 AM6/8/14

to

Bonjour

Le Dimanche 8 Juin 2014 00:59 CEST, Philippe Gras <ph....@worldonline.fr> a écrit:

> Le 8 juin 14 à 00:29, Christophe a écrit :
>
> > Bonjour,
> >
> > Le 07/06/2014 23:21, nb a écrit :
> >>
> >> Le Samedi 7 Juin 2014 23:12 CEST, Philippe Gras
> >> <ph....@worldonline.fr> a écrit:
> >>
> >>>> INPUT ne sert pas pour une connexion déjà établie, seulement pour
> >>>> l'établissement d'une connexion (paquet tcp syn)
> >
> > Pas tout à fait d'accord avec ça, mais rien à voir avec Debian, > comme tu
> > l'as précédemment précisé ...
> > (c'est du noyau linux dont il est question ici).
> >

[...]

> J'ai l'impression que ça sert surtout en ligne de commande. Rectifiez- moi si je me trompe !
> Parce que la subtilité m'échappe. Moi, j'ai un script avec des -P au
> début pour définir toute
> la police, et ensuite, je n'ai que des -A. Mais si ça se trouve, ça devrait être des -N partout ?
> >
> >>

> >> Concernant tes règles "ESTABLISHED" il serait judicieux de les

> >> taper en interactif. Elles n'ont pas trop leur place dans un
> >> script après les règles INPUT.
> >
> > La, il va falloir que tu éclaires quelques lanternes ... ;)
>
> Oui, pourquoi ?

Ce que je voulais dire, c'est que quand un script est appliqué avec les règles de DROP sur INPUT au début, il n'est pas nécessaire de faire en plus à la fin du script un DROP sur des connexions établies de même type. Puisque par définition, elles ne peuvent pas l'être car interdites.

Dans le cas qui nous occupe ici, la connexion a été établie de manière antérieure au script. Du coup malgré les INPUT, la connexion restait présente. Le DROP sur ESTABLISHED devenait indispensable.
Mais uniquement de manière ponctuelle. C'est pourquoi je disais qu'il fallait le faire en intéractif.

Je pards bien sur du fait qu'un script a pour vocation à être re-joué plusieurs fois.
L'incompréhension vient peut-être de là. J'opposais intéractif à script.

Par ailleurs, même en intéractif après un '-A' ou '-I' pour la règle d'INPUT, il faut faire ensuite un '-D'. Car il n'est pas nécessaire de conserver des règles devenues inutiles.

Bon dimanche

--
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-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org

Archive: https://lists.debian.org/7fd3-53940d00-7-656c5100@207004352

Jean-Michel OLTRA

unread,

Jun 8, 2014, 6:10:02 AM6/8/14

to

Bonjour,

Le dimanche 08 juin 2014, Philippe Gras a écrit...

> J'ai l'impression que ça sert surtout en ligne de commande. Rectifiez-moi si

> je me trompe !
> Parce que la subtilité m'échappe. Moi, j'ai un script avec des -P au début
> pour définir toute
> la police, et ensuite, je n'ai que des -A. Mais si ça se trouve, ça devrait
> être des -N partout ?

Lorsque tu écris un script, tu écris en séquence. Donc -A, c'est logique
(-N pour créer), car tu ajoutes à la règle précédente.

Lorsque tu es en interactif (après un iptables -L --line-numbers par
exemple), tu ajoutes avec un "-I <index>" pour insérer là où tu veux
(puis un -D <index> pour supprimer ce que tu veux).

> Sinon, j'ai bien mes journaux dans /var/log/messages (c'est Debian, ça °0°)

Perso, j'utilise rsyslogd avec ses possibilités de filtrage pour envoyer
mes chaines préfixées avec --log-prefix dans /var/log/firewall.log (qui
fait l'objet d'une rotation journalière via une entrée dans
/etc/logrotate.d)

--
jm

--
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-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org

Archive: https://lists.debian.org/20140608094711.GA6890@espinasse

Francois Lafont

unread,

Jun 8, 2014, 6:30:02 AM6/8/14

to

Bonjour à tous,

Le 07/06/2014 23:05, nb a écrit :

>> Le 07/06/2014 20:31, Philippe Gras a écrit :
>>> Non, justement pas quel que soit l'état de la connexion, et c'est logique.
>>>
>>> On n'aurait pas de règle pour les connexions établies, sinon ;-)
>
> Philippe a raison.
> INPUT ne sert pas pour une connexion déjà établie, seulement pour l'établissement d'une connexion (paquet tcp syn)

Loin de moi l'idée de vouloir vous embêter avec tout ça (j'essaye
vraiment d'être constructif dans ma démarche) mais il me semble
sincèrement que Philippe et toi nb vous trompez sur ce point.
J'essaye de donner une explication ci-dessous qui tend à le prouver.
Certes, ça n'a pas de rapport direct avec Debian mais je trouve que
le sujet n'est pas inintéressant en soi. Et dans le pire des cas,
si on me montre que j'ai tort (ce qui est tout à fait envisageable
;)), j'en serais le premier content car j'aurais appris quelque
chose (et je pense que je ne serai pas le seul).

J'ai une petite Debian Wheezy toute simple sur laquelle j'ai un
petit apache2 qui tourne (avec la fameuse page « It works »). Je
n'ai fait à la base aucune modification iptables (et donc par
défaut tout passe etc). Cette machine a pour IP 172.31.0.1/16.

Je crée alors ces deux règles :

iptables -A INPUT -p tcp --dport 80 -s 172.31.100.144 -j LOG --log-prefix "BASIC INPUT "
iptables -A INPUT -p tcp --dport 80 -s 172.31.100.144 -m state --state RELATED,ESTABLISHED -j LOG --log-prefix "STATE INPUT "

J'ai juste repris le même type de règle que Philippe (dans son message
du 7 juin à 18h16) sauf que :

* j'ai pris une autre IP source (qui correspond à l'IP d'une VM sur
mon réseau local 172.31.0.0/16)

* j'ai changé l'action. Au lieu de faire un DROP comme Philippe, je me
contente simplement de journaliser les paquets qui matchent les
règles avec un préfixe différent pour les différencier dans le log.

Une fois que tout ça est en place, je me rends sur la machine
dont l'IP est 172.31.100.144 et je me contente de visiter une fois
la page http://172.31.0.1 qui m'affiche « It works ». Au même
moment je regarde le fichier de log /var/log/kern.log du serveur
apache2 et voici toutes les lignes que j'obtiens au moment de
la visite de la page web :

[ 3082.346423] BASIC INPUT IN=eth1 SRC=172.31.100.144 DST=172.31.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=60953 DF PROTO=TCP SPT=58402 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0·
[ 3082.346697] BASIC INPUT IN=eth1 SRC=172.31.100.144 DST=172.31.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=60954 DF PROTO=TCP SPT=58402 DPT=80 WINDOW=913 RES=0x00 ACK URGP=0·
[ 3082.346704] STATE INPUT IN=eth1 SRC=172.31.100.144 DST=172.31.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=60954 DF PROTO=TCP SPT=58402 DPT=80 WINDOW=913 RES=0x00 ACK URGP=0·
[ 3082.357986] BASIC INPUT IN=eth1 SRC=172.31.100.144 DST=172.31.0.1 LEN=372 TOS=0x00 PREC=0x00 TTL=64 ID=60955 DF PROTO=TCP SPT=58402 DPT=80 WINDOW=913 RES=0x00 ACK PSH URGP=0·
[ 3082.357994] STATE INPUT IN=eth1 SRC=172.31.100.144 DST=172.31.0.1 LEN=372 TOS=0x00 PREC=0x00 TTL=64 ID=60955 DF PROTO=TCP SPT=58402 DPT=80 WINDOW=913 RES=0x00 ACK PSH URGP=0·
[ 3082.358973] BASIC INPUT IN=eth1 SRC=172.31.100.144 DST=172.31.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=60956 DF PROTO=TCP SPT=58402 DPT=80 WINDOW=980 RES=0x00 ACK URGP=0·
[ 3082.358980] STATE INPUT IN=eth1 SRC=172.31.100.144 DST=172.31.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=60956 DF PROTO=TCP SPT=58402 DPT=80 WINDOW=980 RES=0x00 ACK URGP=0·
[ 3087.360441] BASIC INPUT IN=eth1 SRC=172.31.100.144 DST=172.31.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=60957 DF PROTO=TCP SPT=58402 DPT=80 WINDOW=980 RES=0x00 ACK FIN URGP=0·
[ 3087.360448] STATE INPUT IN=eth1 SRC=172.31.100.144 DST=172.31.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=60957 DF PROTO=TCP SPT=58402 DPT=80 WINDOW=980 RES=0x00 ACK FIN URGP=0·
[ 3087.360968] BASIC INPUT IN=eth1 SRC=172.31.100.144 DST=172.31.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=60958 DF PROTO=TCP SPT=58402 DPT=80 WINDOW=980 RES=0x00 ACK URGP=0·
[ 3087.360975] STATE INPUT IN=eth1 SRC=172.31.100.144 DST=172.31.0.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=60958 DF PROTO=TCP SPT=58402 DPT=80 WINDOW=980 RES=0x00 ACK URGP=0·

J'ai juste enlevé quelques champs (comme le champ MAC par exemple)
pour écourter un peu les lignes. En regardant le champ ID des
paquets et en regardant le préfixe ("BASIC INPUT" ou "STATE INPUT"),
on peut constater que tout paquet qui a été matché par la règle
« STATE INPUT » (la règle 2) l'a été également avec la règle « BASIC
INPUT » (la règle 1). Pour moi, cela confirme bien le fait que la
règle :

iptables -A INPUT -p tcp --dport 80 -s 172.31.100.144 -j DROP

va faire un DROP sur tous les paquets destinés à un processus
local (correspondant à du tcp, dont le port de destination vaut 80 et
l'IP source est 172.31.100.144) et cela quel que soit l'état de la
connexion indiqué dans l'entête tcp (donc même pour des paquets
correspondant à une connexion déjà établie).

Voilà. Si je me suis planté, alors toutes mes excuses, je lirais avec
grand intérêt les explications qu'on me donnera.

Bon dimanche à tous.

--
François Lafont

--
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-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org

Archive: https://lists.debian.org/539439E3...@free.fr

Philippe Gras

unread,

Jun 8, 2014, 8:00:02 AM6/8/14

to

Le 8 juin 14 à 12:24, Francois Lafont a écrit :

Bonjour à tous,

Le 07/06/2014 23:05, nb a écrit :

Le 07/06/2014 20:31, Philippe Gras a écrit :

Non, justement pas quel que soit l'état de la connexion, et c'est logique.

On n'aurait pas de règle pour les connexions établies, sinon ;-)

Philippe a raison.
INPUT ne sert pas pour une connexion déjà établie, seulement pour l'établissement d'une connexion (paquet tcp syn)

Loin de moi l'idée de vouloir vous embêter avec tout ça (j'essaye
vraiment d'être constructif dans ma démarche) mais il me semble
sincèrement que Philippe et toi nb vous trompez sur ce point.
J'essaye de donner une explication ci-dessous qui tend à le prouver.
Certes, ça n'a pas de rapport direct avec Debian mais je trouve que
le sujet n'est pas inintéressant en soi. Et dans le pire des cas,
si on me montre que j'ai tort (ce qui est tout à fait envisageable
;)), j'en serais le premier content car j'aurais appris quelque
chose (et je pense que je ne serai pas le seul).

OK, ce n'est pas Debian, mais Iptables. Mais on peut l'installer sur une Debian.

Je n'ai pas vu de forum ou de liste dédiée à Iptables, alors je pose ma question

ici même.

J'ai une petite Debian Wheezy toute simple sur laquelle j'ai un
petit apache2 qui tourne (avec la fameuse page « It works »). Je
n'ai fait à la base aucune modification iptables (et donc par
défaut tout passe etc). Cette machine a pour IP 172.31.0.1/16.

OK pour cette démonstration, mais le cas que j'ai évoqué est différent, dans la

mesure où j'ai dû établir ma règle pendant l'attaque, je ne l'ai pas écrite avant.

Je crois qu'il y a une explication à cet état de choses ici :

http://www.bortzmeyer.org/rate-limiting-dos.html

=============================================================

Ici, on met les adresses IP dans une table nommée Web. On peut afficher son contenu avec cat /proc/net/xt_recent/Web pour surveiller le bon fonctionnement. On ne teste que les paquets TCP de type SYN, ceux envoyés pour créer une nouvelle connexion (on aurait pu remplacer --tcp-flags SYN SYN par -m state --state NEW mais cette commande est à état, ce qui est toujours déconseillé face à une DoS).

=============================================================

Il existe apparemment une différence dans le traitement des paquets par iptables

selon leur état.

Philippe Gras

unread,

Jun 8, 2014, 8:10:02 AM6/8/14

to

Le 8 juin 14 à 11:47, Jean-Michel OLTRA a écrit :

>
> Bonjour,
>

>> Sinon, j'ai bien mes journaux dans /var/log/messages (c'est
>> Debian, ça °0°)
>
> Perso, j'utilise rsyslogd avec ses possibilités de filtrage pour
> envoyer
> mes chaines préfixées avec --log-prefix dans /var/log/firewall.log
> (qui
> fait l'objet d'une rotation journalière via une entrée dans
> /etc/logrotate.d)
>

C'est un peu ça que j'aimerais arriver à faire chez moi :
Lister les IP qui envoient une requête "Get wp-login.php"
Selon la fréquence de ces requêtes dans le temps, ACCEPT ou DROP.

> --
> jm
>
> --
> 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-f...@lists.debian.org
> En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
> Archive: https://lists.debian.org/20140608094711.GA6890@espinasse
>

--
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-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org

Archive: https://lists.debian.org/6598E822-87E3-451F...@worldonline.fr

Denis Mugnier

unread,

Jun 8, 2014, 10:00:01 AM6/8/14

to

Bonjour,

Le 08/06/2014 14:02, Philippe Gras a écrit :
> Le 8 juin 14 à 11:47, Jean-Michel OLTRA a écrit :
>
>>
>>
>>

> C'est un peu ça que j'aimerais arriver à faire chez moi :
> Lister les IP qui envoient une requête "Get wp-login.php"
> Selon la fréquence de ces requêtes dans le temps, ACCEPT ou DROP.
>
>> --

Je pense que pour avoir des regles en fonction de la fréquence, il faut
regarder du coté du module limit d'iptables

A+

Denis

--
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-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org

Archive: https://lists.debian.org/53946ADB...@orange.fr

Francois Lafont

unread,

Jun 8, 2014, 11:00:01 AM6/8/14

to

Le 08/06/2014 13:58, Philippe Gras a écrit :

> OK, ce n'est pas Debian, mais Iptables. Mais on peut l'installer sur une Debian.
>
> Je n'ai pas vu de forum ou de liste dédiée à Iptables, alors je pose ma question
> ici même.

Personnellement, ça ne me dérange absolument que le sujet
soit abordé ici.

> OK pour cette démonstration, mais le cas que j'ai évoqué est différent, dans la
> mesure où j'ai dû établir ma règle pendant l'attaque, je ne l'ai pas écrite avant.

Certes, mais très honnêtement je pense que ça ne change rien
au fait qu'avec les règles que tu indiquais :

1. iptables -A INPUT -p tcp --dport 80 -s 72.44.248.136 -j DROP
2. iptables -A INPUT -p tcp --dport 80 -s 66.23.229.10 -j DROP
3. iptables -A INPUT -m state --state RELATED,ESTABLISHED -p tcp --dport 80 -s 72.44.248.136 -j DROP
4. iptables -A INPUT -m state --state RELATED,ESTABLISHED -p tcp --dport 80 -s 66.23.229.10 -j DROP

les règles 3 et 4 sont inutiles car si un paquet matche la 3, de
toute façon il matchera la 1 avant et sera « dropé » et si un
paquet matche la 4 il sera « dropé » de toute façon par la 2 avant.
Mais au final, ce n'est pas très grave, il y a juste une sorte
de redondance. Rien de bien méchant donc.

> Je crois qu'il y a une explication à cet état de choses ici :
> http://www.bortzmeyer.org/rate-limiting-dos.html
> =============================================================
> Ici, on met les adresses IP dans une table nommée Web. On peut afficher son contenu avec cat /proc/net/xt_recent/Web pour surveiller le bon fonctionnement. On ne teste que les paquets TCP de type SYN, ceux envoyés pour créer une nouvelle connexion (on aurait pu remplacer --tcp-flags SYN SYN par -m state --state NEW mais cette commande est à état, ce qui est toujours déconseillé face à une DoS).
> =============================================================

Merci bien Philippe pour ce lien qui est très intéressant. Perso,
j'y est appris pas mal de trucs. En revanche, je n'y ai pas trop
vu le rapport avec la question soulevée ici.

> Il existe apparemment une différence dans le traitement des paquets par iptables
> selon leur état.

Vraiment je ne crois pas. Si, dans la définition d'une règle via
iptables, tu ne précises rien quant à l'état de la connexion tcp,
alors la règle ne dépendra pas de cet état, tout simplement.

Dans le lien précédent en l'occurrence, les règles indiquées dépendent
explicitement de l'état de la connexion car l'auteur cherche à attraper
les paquets IP qui contiennent des segments tcp qui correspondent à des
demandes de connexion d'où l'option « --tcp-flags SYN SYN » clairement
spécifiée quasiment à chaque fois.

--
François Lafont

--
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-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org

Archive: https://lists.debian.org/539477FB...@free.fr

Francois Lafont

unread,

Jun 8, 2014, 12:00:02 PM6/8/14

to

Juste pour conclure, je voulais ajouter ceci. Juste après un :

iptables -A INPUT -p tcp --dport 80 -s 72.44.248.136 -j DROP

iptables -A INPUT -p tcp --dport 80 -s 66.23.229.10 -j DROP

*pendant* l'attaque, il est tout à fait possible que ton serveur
apache soit encore dans les choux. En effet, avant la mise en
place des règles ci-dessus, des requêtes http étaient sûrement
en cours et celles-là ton apache souhaite les honorer. Du coup,
ton apache envoie tant bien que mal ses réponses aux méchants
hôtes 72.44.248.136 et 66.23.229.10. Normalement, les 2 méchants
sont censés envoyer un paquet d'acquittement comme quoi ils ont
bien reçu la réponse du serveur. Mais ces paquets d'acquittement
ne peuvent plus arriver car les 2 règles ci-dessus l'empêchent.
Du coup, apache2 cherche à renvoyer à nouveau ses réponses etc.
Et du coup, il continue à être dans les choux pendant un certain
temps.

En revanche, avec un truc du genre :

1. invoke-rc.d apache2 stop # on arrête toutes les connexions en cours.

2.
iptables -A INPUT -p tcp --dport 80 -s 72.44.248.136 -j DROP

iptables -A INPUT -p tcp --dport 80 -s 66.23.229.10 -j DROP

3.

invoke-rc.d apache2 start

il me semble que ton apache2 est serein aussitôt après et
les 2 méchants hôtes ne peuvent plus l'embêter.

--
François Lafont

--
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-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org

Archive: https://lists.debian.org/539487E...@free.fr

Philippe Gras

unread,

Jun 8, 2014, 12:40:01 PM6/8/14

to

Le 8 juin 14 à 17:57, Francois Lafont a écrit :

> Juste pour conclure, je voulais ajouter ceci. Juste après un :
>
> iptables -A INPUT -p tcp --dport 80 -s 72.44.248.136 -j DROP
> iptables -A INPUT -p tcp --dport 80 -s 66.23.229.10 -j DROP
>
> *pendant* l'attaque, il est tout à fait possible que ton serveur
> apache soit encore dans les choux. En effet, avant la mise en
> place des règles ci-dessus, des requêtes http étaient sûrement
> en cours et celles-là ton apache souhaite les honorer. Du coup,
> ton apache envoie tant bien que mal ses réponses aux méchants
> hôtes 72.44.248.136 et 66.23.229.10. Normalement, les 2 méchants
> sont censés envoyer un paquet d'acquittement comme quoi ils ont
> bien reçu la réponse du serveur. Mais ces paquets d'acquittement
> ne peuvent plus arriver car les 2 règles ci-dessus l'empêchent.
> Du coup, apache2 cherche à renvoyer à nouveau ses réponses etc.
> Et du coup, il continue à être dans les choux pendant un certain
> temps.

Oui, c'est très possible. J'ai pensé à autre chose aussi, par rapport
à ce
que François réfute, c'est que j'ai aussi une règle dans mon firewall
qui
empêche les connexions établies d'être cassées. Il serait possible que
je sois obligé de demander expressément de casser celles-là, et l'une
après l'autre. Car l'attaquant n'en utilisait qu'une seule à la fois.

>
> En revanche, avec un truc du genre :
>
> 1. invoke-rc.d apache2 stop # on arrête toutes les connexions en
> cours.
>

Oui, mais je marche avec NginX d'une part, et comme j'étais dessus
aussi,
je n'avais pas envie de me bannir moi-même.

Ceci dit, j'avais installé précédemment un module limiteur qui existe
sur le
serveur NginX, mais ça n'a pas vraiment gêné le mec pour attaquer.

> 2.
> iptables -A INPUT -p tcp --dport 80 -s 72.44.248.136 -j DROP
> iptables -A INPUT -p tcp --dport 80 -s 66.23.229.10 -j DROP
>
> 3.
> invoke-rc.d apache2 start
>
> il me semble que ton apache2 est serein aussitôt après et
> les 2 méchants hôtes ne peuvent plus l'embêter.

J'ai l'impression qu'on était tous les 2 chacun de notre côté à
contrer l'autre,
et après que je l'ai eu droppé une première fois, il est revenu avec
l'autre IP.

>
> --
> François Lafont
>
> --
> 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-f...@lists.debian.org
> En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
> Archive: https://lists.debian.org/539487E...@free.fr
>

--
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-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org

Archive: https://lists.debian.org/CBA8D913-C375-4617...@worldonline.fr

Philippe Gras

unread,

Jun 8, 2014, 12:40:01 PM6/8/14

to

Le 8 juin 14 à 15:53, Denis Mugnier a écrit :

Bonjour,

Le 08/06/2014 14:02, Philippe Gras a écrit :

Le 8 juin 14 à 11:47, Jean-Michel OLTRA a écrit :

C'est un peu ça que j'aimerais arriver à faire chez moi :
Lister les IP qui envoient une requête "Get wp-login.php"
Selon la fréquence de ces requêtes dans le temps, ACCEPT ou DROP.

--

Je pense que pour avoir des regles en fonction de la fréquence, il faut regarder du coté du module limit d'iptables

Ce n'est pas ce que j'ai lu ici:

http://www.bortzmeyer.org/rate-limiting-dos.html

================================================

Malheureusement, il ne semble pas que le module recent permette d'utiliser des préfixes (par exemple de longueur 26 ou 28) mais seulement des adresses IP

================================================

Mais c'est effectivement ce que je souhaitais faire au départ…

Philippe Gras

unread,

Jun 8, 2014, 1:00:01 PM6/8/14

to

Je m'ai trompé de ligne :

Le 8 juin 14 à 18:33, Philippe Gras a écrit :

Le 8 juin 14 à 15:53, Denis Mugnier a écrit :

Bonjour,

Le 08/06/2014 14:02, Philippe Gras a écrit :

Le 8 juin 14 à 11:47, Jean-Michel OLTRA a écrit :

C'est un peu ça que j'aimerais arriver à faire chez moi :
Lister les IP qui envoient une requête "Get wp-login.php"
Selon la fréquence de ces requêtes dans le temps, ACCEPT ou DROP.

--

Je pense que pour avoir des regles en fonction de la fréquence, il faut regarder du coté du module limit d'iptables

Ce n'est pas ce que j'ai lu ici:
http://www.bortzmeyer.org/rate-limiting-dos.html
================================================
Malheureusement, il ne semble pas que le module recent permette d'utiliser des préfixes (par exemple de longueur 26 ou 28) mais seulement des adresses IP

[…]

Ce module est très simple. Mais le module limit, comme recent, ne permet pas de travailler par préfixe IP.

Jean-Michel OLTRA

unread,

Jun 8, 2014, 7:40:02 PM6/8/14

to

Bonjour,

Le dimanche 08 juin 2014, Philippe Gras a écrit...

> C'est un peu ça que j'aimerais arriver à faire chez moi :
> Lister les IP qui envoient une requête "Get wp-login.php"
> Selon la fréquence de ces requêtes dans le temps, ACCEPT ou DROP.

Un hids comme Ossec te permet de créer une règle perso, pour extraire ce
genre de schéma, et y appliquer le remède que tu choisis (drop,
bannissement) dans le cadre de sa réponse active. Ossec utilise un
paramètre timeframe qui donne à l'administrateur toute latitude pour
définir le nombre de correspondances autorisées dans un laps de temps
donné.

www.ossec.net

--
jm

--
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-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org

Archive: https://lists.debian.org/20140608232026.GC6890@espinasse

Philippe Gras

unread,

Jun 9, 2014, 4:10:02 AM6/9/14

to

C'est un peu ça que j'aimerais arriver à faire chez moi :
Lister les IP qui envoient une requête "Get wp-login.php"
Selon la fréquence de ces requêtes dans le temps, ACCEPT ou DROP.

Un hids comme Ossec te permet de créer une règle perso, pour extraire ce
genre de schéma, et y appliquer le remède que tu choisis (drop,
bannissement) dans le cadre de sa réponse active. Ossec utilise un
paramètre timeframe qui donne à l'administrateur toute latitude pour
définir le nombre de correspondances autorisées dans un laps de temps
donné.

www.ossec.net

Ça me prend un peu la tête d'installer encore un truc, mais celui-ci fait tout

de même l'effort de se mettre à la portée de mon cerveau lent :

http://youtu.be/lUMs1uqwRX0

Merci pour l'info !

Jean-Michel OLTRA

unread,

Jun 9, 2014, 4:40:02 AM6/9/14

to

Bonjour,

Le lundi 09 juin 2014, Philippe Gras a écrit...

> Ça me prend un peu la tête d'installer encore un truc, mais celui-ci fait
> tout
> de même l'effort de se mettre à la portée de mon cerveau lent :
> http://youtu.be/lUMs1uqwRX0

> Merci pour l'info !

Pas de quoi. J'aime beaucoup cette application, qui fait beaucoup pour
la surveillance des serveurs. J'ai vu que la dernière version était
packagée Debian, quoique la compilation et l'installation des sources ne
pose vraiment aucun problème (testée sur Wheezy et Jessie, et versions
précédentes).

Il est possible de l'utiliser en mode clients/serveur, c'est très
fonctionnel.

--
jm

--
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-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org

Archive: https://lists.debian.org/20140609082306.GA30914@espinasse

Philippe Gras

unread,

Jun 9, 2014, 5:50:02 AM6/9/14

to

J'ai déjà quelques résultats sympa au niveau des accès illégitimes :
=======================================================================
pkts bytes target prot opt in out
source destination
48 4128 LOG tcp -- * *
0.0.0.0/0 XXX.XXX.XXX tcp dpt:80 STRING match
"GET /w00tw00t.at." ALGO name bm TO 70 LOG flags 0 level 4 prefix
"iptables w00tw00t"
0 0 LOG tcp -- * *
0.0.0.0/0 XXX.XXX.XXX tcp dpt:80 STRING match
"GET /FCKeditor" ALGO name bm TO 70 LOG flags 0 level 4 prefix
"iptables FCKeditor"
207 54873 LOG tcp -- * *
0.0.0.0/0 XXX.XXX.XXX tcp dpt:80 STRING match
"Host: XXX.XXX.XXX" ALGO name bm TO 70 LOG flags 0 level 4 prefix
"iptables IP requests"
48 4128 DROP tcp -- * *
0.0.0.0/0 XXX.XXX.XXX tcp dpt:80 STRING match
"GET /w00tw00t.at." ALGO name bm TO 70
0 0 DROP tcp -- * *
0.0.0.0/0 XXX.XXX.XXX tcp dpt:80 STRING match
"GET /FCKeditor" ALGO name bm TO 70
207 54873 DROP tcp -- * *
0.0.0.0/0 XXX.XXX.XXX tcp dpt:80 STRING match
"Host: XXX.XXX.XXX" ALGO name bm TO 70
========================================================================
48 DFINDs rejetés
207 scans rejetés dimanche.

:-)

Le 9 juin 14 à 10:23, Jean-Michel OLTRA a écrit :

Archive: https://lists.debian.org/718A54DD-ED6A-47D1...@worldonline.fr

Florian Blanc

unread,

Jun 9, 2014, 6:30:03 AM6/9/14

to

Bonjour,

Tout d’abord je trouve ce topic plutôt sympa :)

Je viens juste ajouter ma petite expérience sur l’administration de serveurs DISTANTS.

Premièrement il ne faut laisser d’accessible que le strict minimum !

Dans le cas d’un service web (http) il ne faut donc que le 80 et peut-être le 443 en fonction des cas .. (pour le public).

Le backend web je le met accessible uniquement sur le port 2222 par exemple (avec SSL!).

Deux solutions, avoir un vpn dédié ou une IP fixe ou utiliser un service de DNS dynamique.

(préférer le dns dynamique que l’ip fixe car il aura les memes avantages que le vpn, c’est à dire utilisable meme si vous n’êtes pas chez vous).

J’ai préféré le DNS car je n’ai pas besoin de gérer les attaques sur le vpn :)

Donc à partir de là, dans mes règles iptables je n’autorise que mon dyndns sur le 22 et le 2222 (backend web ssl).

Comment je fais pour actualiser mon dyndns ?

dans mon crontab j’ai : */40 * * * * /etc/init.d/firewall-update-dynamics >/dev/null

Le fichier firewall-update-dynamics va être exécuté toute les 40 minutes.

et dans ce fichier on trouvera par exemple …

/sbin/iptables -F INDYNAMIC

/sbin/iptables -A INDYNAMIC -m tcp -p tcp --src MON-NO-IP.BIDULE --dport 22 -j ACCEPT

/sbin/iptables -A INDYNAMIC -m tcp -p tcp --src MON-NO-IP.BIDULE --dport 2222 -j ACCEPT

Je suis preneur de toutes remarques.

Cordialement à tous et bon repos :)

Daniel Caillibaud

unread,

Jun 9, 2014, 7:40:01 AM6/9/14

to

Le 07/06/14 à 18:16, Philippe Gras <ph....@worldonline.fr> a écrit :
PG> Pour ce qui est des 400, de certaines 404 et 403, je pense que tu
PG> peux t'inspirer de ça:
PG> http://spamcleaner.org/fr/misc/w00tw00t.html
PG>
PG> Je vais d'ailleurs le faire moi-même, parce que j'ai plein de
PG> requêtes avec cette chaîne :

En quoi c'est gênant ?

Répondre à ce genre de requete avec une 404 coûtera bcp moins de ressources qu'une règle
iptables qui va analyser tous les paquets http.

Si vraiment ça dérange, ajouter une règle nginx (location ~ w00tw00t) pour écrire l'ip dans un
fichier tmp (sans passer par du php, avec echo dans nginx) et une tâche cron qui récupère les
listes pour les blacklister avec iptables et les recopier ailleurs pour les enlever au prochain
passage me parait plus efficace, mais j'ai jamais pris la peine de le faire malgré des milliers
de requetes comme ça par jour.

Même chose pour la dernière règle de la page, lancer une regex plus un algo pour les
paquets qui match me parait un gaspillage important, mieux vaudrait créer un vhost par défaut
qui va prendre les requetes directes sur l'ip (http://xxx.xxx.xxx.xxx/) pour bannir tout le
monde qui arrive là (faudrait être sûr que les googlebot & co lancent jamais ces requetes, pas
étudié la question car me sens pas concerné avec un varnish en frontal).

J'ai l'impression que ce genre de "protection" ne protège que des scripts kiddies assez
inoffensifs, les vrais méchants sont pas assez stupides pour se faire repérer avec des attaques
aussi connues.

--
Daniel

On croit mourir pour la patrie; on meurt pour des industriels.
Anatole France

--
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-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org

Archive: https://lists.debian.org/20140609133...@quad.lairdutemps.org

Philippe Gras

unread,

Jun 9, 2014, 8:40:01 AM6/9/14

to

Le 9 juin 14 à 13:32, Daniel Caillibaud a écrit :

Le 07/06/14 à 18:16, Philippe Gras <ph....@worldonline.fr> a écrit :
PG> Pour ce qui est des 400, de certaines 404 et 403, je pense que tu
PG> peux t'inspirer de ça:
PG> http://spamcleaner.org/fr/misc/w00tw00t.html
PG>
PG> Je vais d'ailleurs le faire moi-même, parce que j'ai plein de
PG> requêtes avec cette chaîne :

En quoi c'est gênant ?

Répondre à ce genre de requete avec une 404 coûtera bcp moins de ressources qu'une règle
iptables qui va analyser tous les paquets http.

Ah, bon ? Je veux bien le croire, mais ça demande à être confirmé. Parce que si ce n'est pas

iptables qui analyse les paquets, c'est le serveur virtuel qui va le faire ensuite, non ? Donc le

résultat serait identique au niveau du temps d'attente, non ?

Si vraiment ça dérange, ajouter une règle nginx (location ~ w00tw00t) pour écrire l'ip dans un
fichier tmp (sans passer par du php, avec echo dans nginx) et une tâche cron qui récupère les
listes pour les blacklister avec iptables et les recopier ailleurs pour les enlever au prochain
passage me parait plus efficace, mais j'ai jamais pris la peine de le faire malgré des milliers
de requetes comme ça par jour.

Oui, ça me parait une bonne idée. Comment comparer la vitesse d'exécution des 2 règles ?

Même chose pour la dernière règle de la page, lancer une regex plus un algo pour les
paquets qui match me parait un gaspillage important, mieux vaudrait créer un vhost par défaut
qui va prendre les requetes directes sur l'ip (http://xxx.xxx.xxx.xxx/) pour bannir tout le
monde qui arrive là (faudrait être sûr que les googlebot & co lancent jamais ces requetes, pas
étudié la question car me sens pas concerné avec un varnish en frontal).

C'est déjà le cas chez moi. Je ne crois pas que les crawlers s'intéressent aux IP, je ne l'ai jamais

remarqué. Mais ça pourrait venir, on ne sait jamais…

J'ai l'impression que ce genre de "protection" ne protège que des scripts kiddies assez
inoffensifs, les vrais méchants sont pas assez stupides pour se faire repérer avec des attaques
aussi connues.

Je suis complètement d'accord avec cette assertion. Le problème, c'est que les script kiddies sont

très gourmands, et vraiment très envahissants.

J'aimerais bien réserver l'accès de mon serveur à des utilisateurs légitimes, car il est tout petit, pas

très costaud, donc le compromis est difficile à trouver entre une certaine tolérance avec les bots, et

une discrimination rigoureuse…

Ph. Gras

Florian

unread,

Jun 9, 2014, 11:20:02 AM6/9/14

to

Et vis à vis des règles, toujours pour un service web, je serais plus d'avis à répondre par un bon 404 pour une requête demandant une ressource incorrecte simplement. Ensuite ça dépend ... Si tu n'as aucune page de login accessible en front, est-ce que le fait de répondre par un 404 simplement te coûte plus que de rejeter un packet filtré ? (Sachant que online et ovh fournissent la partie ddos).

Ensuite oui, si tu as une page de connexion tu va obligatoirement "logger" et blacklister la source.

(À savoir que ton backend n'a pas à être accessible par tout le monde).

Attention aux réglages trop sophistiqués, au risque de laisser des trous dans votre muraille ou de perdre en efficacité.

Cordialement.

--
Florian

Philippe Gras

unread,

Jun 9, 2014, 12:10:04 PM6/9/14

to

Le 9 juin 14 à 17:15, Florian a écrit :

Et vis à vis des règles, toujours pour un service web, je serais plus d'avis à répondre par un bon 404 pour une requête demandant une ressource incorrecte simplement. Ensuite ça dépend ... Si tu n'as aucune page de login accessible en front, est-ce que le fait de répondre par un 404 simplement te coûte plus que de rejeter un packet filtré ? (Sachant que online et ovh fournissent la partie ddos).
Ensuite oui, si tu as une page de connexion tu va obligatoirement "logger" et blacklister la source.
(À savoir que ton backend n'a pas à être accessible par tout le monde).

Justement oui, j'ai un login sur le site qui a été attaqué la semaine dernière, et qui a motivé

mon intervention sur le serveur, l'édition des règles Iptables, et ma demande d'aide à cette

liste. J'ai un login et ça m'a coûté de laisser le bot attaquer la page de login parce que je ne

pouvais pratiquement plus naviguer sur le tableau de bord de l'administration de mon site.

Parce que là, on n'est plus dans le cas où le robot reçoit une 40X et passe son chemin !

Comme c'est la 2ème fois que cela m'arrive, ceci sans compter les fois où ça ramait de façon

anormale sans que je sache où aller chercher la bonne réponse, j'ai décidé de faire en sorte

que ça n'arrive pas une 3ème fois.

Je fais un peu de rédaction sur un blog qui est continuellement surchargé en backend. Je me

demande maintenant si mon cas est tellement isolé que ça ;-)

Attention aux réglages trop sophistiqués, au risque de laisser des trous dans votre muraille ou de perdre en efficacité.
Cordialement.

Là dessus, complètement d'accord ! C'est ma politique également :-)

Bernard Schoenacker

unread,

Jun 9, 2014, 1:30:01 PM6/9/14

to

Le Sun, 8 Jun 2014 18:29:41 +0200,

Philippe Gras <ph....@worldonline.fr> a écrit :

bonjour,

serait-il possible d'indiquer la liste des paquets installés pour
se protéger des attaques en installant :

-a) denyhost
-b) portsentry

slt
bernard

--
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-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org

Archive: https://lists.debian.org/20140609192901.7ecc2d95@hamtaro

Florian

unread,

Jun 9, 2014, 3:30:03 PM6/9/14

to

Si je comprend bien, vous avez un serveur web avec un cms type blog et vous avez des attaques sur votre backend.

Car dans ce cas là, ma solution était de mettre votre répertoire d'administration en deny pour tous port 80 dans la conf de votre apache/nginx ou autre..

Vu que pour un système de blog les lecteurs n'ont pas besoin de SSL, vous pouvez vous le réserver.

Parfait alors vous mettez également votre serveur web en écoute sur le port 443.

Maintenant je trouve assez sympa le principe de louer un NOIP pour que je puisse avoir un moyen de me faire identifier ..

Car maintenant ma règle est simple et efficace ... Je flush ma table "dynamique" créer exprès. J'ai donc ma regle iptables qui vient ajouter le lookup de mon NOIP toute les 40 minutes pour le port 443.

Et je laisse mon client NOIP ouvert. Sinon je sais que au pire si je tombe à un mauvais moment, il faudra que j'attende 40 minutes ce qui n'est pas bien grave comparé ce dont je me débarrasse.

J'espère avoir bien compris votre situation :/

Cordialement

--
Florian

Philippe Gras

unread,

Jun 9, 2014, 5:30:03 PM6/9/14

to

Le 9 juin 14 à 21:26, Florian a écrit :

Si je comprend bien, vous avez un serveur web avec un cms type blog et vous avez des attaques sur votre backend.

Oui, ce sont plusieurs sites montés sous Wordpress, sur un Kimsufi OVH.

Car dans ce cas là, ma solution était de mettre votre répertoire d'administration en deny pour tous port 80 dans la conf de votre apache/nginx ou autre..

C'est fait pour certains, mais d'autres sont participatifs… Là, je ne peux pas.

Dans 90% les attaques par brute force s'arrêtent au bout d'une dizaine de requêtes,

vu qu'elles tombent toutes en 403. Mais la semaine dernière, ça a pris une autre tournure.

J'ai déjà eu le même problème au mois de mars, venant sans doute de l'APL. Je suppose

donc que ça va recommencer d'ici quelque temps.

Vu que pour un système de blog les lecteurs n'ont pas besoin de SSL, vous pouvez vous le réserver.
Parfait alors vous mettez également votre serveur web en écoute sur le port 443.

Le port 433 est en DROP, sauf pour les IP qui viennent chercher mon backup.

Le serveur virtuel par défaut est fermé, sauf pour mon IP pour que j'accède à la BDD.

La BDD elle même est planquée, inaccessible aux intrus :

=================================================================

403 Forbidden

/wp-login.php: 8686 Time(s)

/: 34 Time(s)

/wp-login.php?action=register: 14 Time(s)

/wp-comments-post.php: 13 Time(s)

/myadmin/scripts/setup.php: 1 Time(s)

/phpMyAdmin/scripts/setup.php: 1 Time(s)

/phpmyadmin/scripts/setup.php: 1 Time(s)

/pma/scripts/setup.php: 1 Time(s)

[…]

==================================================================

Ceci est un extrait du rapport de Logwatch du samedi 7 juin,

il montre bien où se trouve mon problème à l'heure actuelle.

S'il ne s'agissait que de la quinzaine de requêtes illégitimes

à traiter, je ne me prendrais pas la tête.

Mais pendant que j'y suis, je me fais la main dessus avec iptables :-)

Maintenant je trouve assez sympa le principe de louer un NOIP pour que je puisse avoir un moyen de me faire identifier ..
Car maintenant ma règle est simple et efficace ... Je flush ma table "dynamique" créer exprès. J'ai donc ma regle iptables qui vient ajouter le lookup de mon NOIP toute les 40 minutes pour le port 443.
Et je laisse mon client NOIP ouvert. Sinon je sais que au pire si je tombe à un mauvais moment, il faudra que j'attende 40 minutes ce qui n'est pas bien grave comparé ce dont je me débarrasse.

C'est moi qui ne comprends pas tout, LOL. Mais je ne pense pas qu'il

me soit nécessaire d'en arriver à louer un autre serveur pour gérer le

premier correctement.

J'ai bien aimé le concept de Daniel, en recherchant les requêtes dans

le vhost (… ou les logs) avec une regex, puis de relever les IP pour les

rejeter ensuite dans iptables.

C'est une solution qui me paraît plus légère et sympa à coder, et on peut

aussi rechercher plein de chaînes de caractères différentes.

Un autre truc aussi qui pose problème dans mon installation, c'est que je

joue à cache-cache avec GG, donc j'ai planqué des sites chez Cloudflare.

Je récupère les vraies IP des internautes avec NginX, mais pas plus avant.

Il ne faudrait pas que je rejette des IP de Cloudflare avec iptables non plus.

Philippe Gras

unread,

Jun 9, 2014, 6:50:01 PM6/9/14

to

Le 9 juin 14 à 19:29, Bernard Schoenacker a écrit :

>
> bonjour,
>
> serait-il possible d'indiquer la liste des paquets installés pour
> se protéger des attaques en installant :
>
> -a) denyhost

Ça pourrait être une solution, mais pas en l'espèce.

J'administre des sites en PHP qui sont publics sur le port 80, et
les visiteurs sont invités à s'inscrire pour produire du contenu.

La gestion des utilisateurs légitimes (ou pas) est faite avec PHP
donc très en aval.

> -b) portsentry

Mon problème n'est pas une question de ports ouverts à fermer,
là on parle du port 80, qui doit rester accessible à tout le monde
sauf les casse-pieds.

>
> slt
> bernard
>
> --
> 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-f...@lists.debian.org
> En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
> Archive: https://lists.debian.org/20140609192901.7ecc2d95@hamtaro
>

--
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-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org

Archive: https://lists.debian.org/CC4B382A-8828-48B8...@worldonline.fr

Daniel Caillibaud

unread,

Jun 9, 2014, 6:50:01 PM6/9/14

to

Le 09/06/14 ï¿½ 14:38, Philippe Gras <ph....@worldonline.fr> a ï¿½crit :

PG>
PG> Le 9 juin 14 ï¿½ 13:32, Daniel Caillibaud a ï¿½crit :
PG>
PG> > Le 07/06/14 ï¿½ 18:16, Philippe Gras <ph....@worldonline.fr> a ï¿½crit :
PG> > PG> Pour ce qui est des 400, de certaines 404 et 403, je pense que tu
PG> > PG> peux t'inspirer de ï¿½a:
PG> > PG> http://spamcleaner.org/fr/misc/w00tw00t.html
PG> > PG>
PG> > PG> Je vais d'ailleurs le faire moi-mï¿½me, parce que j'ai plein de
PG> > PG> requï¿½tes avec cette chaï¿½ne :
PG> >
PG> > En quoi c'est gï¿½nant ?
PG> >
PG> > Rï¿½pondre ï¿½ ce genre de requete avec une 404 coï¿½tera bcp moins de
PG> > ressources qu'une rï¿½gle
PG> > iptables qui va analyser tous les paquets http.
PG>
PG> Ah, bon ? Je veux bien le croire, mais ï¿½a demande ï¿½ ï¿½tre confirmï¿½.
PG> Parce que si ce n'est pas
PG> iptables qui analyse les paquets, c'est le serveur virtuel qui va le
PG> faire ensuite, non ? Donc le
PG> rï¿½sultat serait identique au niveau du temps d'attente, non ?

Je pense pas, le serveur web n'aura que les urls ï¿½ pbs ï¿½ traiter, alors que iptable va
traiter tous les paquets tcp du port 80.
(chez moi les scripts kiddies c'est qq centaines de requetes, milliers quand ils s'excitent, sur
pas mal de millions, j'ai jamais vu d'impact sur les temps de rï¿½ponse des utilisateurs
lï¿½gitimes)

PG> > Si vraiment ï¿½a dï¿½range, ajouter une rï¿½gle nginx (location ~
PG> > w00tw00t) pour ï¿½crire l'ip dans un
PG> > fichier tmp (sans passer par du php, avec echo dans nginx) et une
PG> > tï¿½che cron qui rï¿½cupï¿½re les
PG> > listes pour les blacklister avec iptables et les recopier ailleurs
PG> > pour les enlever au prochain
PG> > passage me parait plus efficace, mais j'ai jamais pris la peine de
PG> > le faire malgrï¿½ des milliers
PG> > de requetes comme ï¿½a par jour.
PG>
PG> Oui, ï¿½a me parait une bonne idï¿½e. Comment comparer la vitesse
PG> d'exï¿½cution des 2 rï¿½gles ?

La mesurer...
Mais amha c'est de l'ï¿½nergie gaspillï¿½e, sauf si tu veux ï¿½tudier ce cas en dï¿½tails...

PG> > Mï¿½me chose pour la derniï¿½re rï¿½gle de la page, lancer une regex plus
PG> > un algo pour les
PG> > paquets qui match me parait un gaspillage important, mieux vaudrait
PG> > crï¿½er un vhost par dï¿½faut
PG> > qui va prendre les requetes directes sur l'ip (http://
PG> > xxx.xxx.xxx.xxx/) pour bannir tout le
PG> > monde qui arrive lï¿½ (faudrait ï¿½tre sï¿½r que les googlebot & co
PG> > lancent jamais ces requetes, pas
PG> > ï¿½tudiï¿½ la question car me sens pas concernï¿½ avec un varnish en
PG> > frontal).
PG>
PG> C'est dï¿½jï¿½ le cas chez moi. Je ne crois pas que les crawlers
PG> s'intï¿½ressent aux IP, je ne l'ai jamais
PG> remarquï¿½. Mais ï¿½a pourrait venir, on ne sait jamaisï¿½
PG> >
PG> > J'ai l'impression que ce genre de "protection" ne protï¿½ge que des
PG> > scripts kiddies assez
PG> > inoffensifs, les vrais mï¿½chants sont pas assez stupides pour se
PG> > faire repï¿½rer avec des attaques
PG> > aussi connues.
PG>
PG> Je suis complï¿½tement d'accord avec cette assertion. Le problï¿½me,
PG> c'est que les script kiddies sont
PG> trï¿½s gourmands, et vraiment trï¿½s envahissants.

C'est lï¿½ que j'ai du mal ï¿½ suivre, si qq milliers de requetes sur une 404 ralentissent ton
appli c'est l'appli qui a un pb.
(c'est vrai que certains cms envoient toutes les 404 au controleur principal, qui doit charger
toute l'appli pour rï¿½pondre ï¿½ la fin 404, si c'est du php utiliser apc doit pas mal rï¿½duire la
charge en gï¿½nï¿½ral, et notamment dans ces cas lï¿½).

PG> J'aimerais bien rï¿½server l'accï¿½s de mon serveur ï¿½ des utilisateurs
PG> lï¿½gitimes, car il est tout petit, pas
PG> trï¿½s costaud, donc le compromis est difficile ï¿½ trouver entre une
PG> certaine tolï¿½rance avec les bots, et
PG> une discrimination rigoureuseï¿½

Si c'est trop compliquï¿½ de modifier l'appli faut ajouter qq location pour ces urls ï¿½ pb, mï¿½me
avec qq milliers d'appels sur une petite machine, c'est pas ï¿½a qui va fatiguer ton nginx.

--
Daniel

Pour atteindre le bonheur il y a deux rï¿½gles :
1. Contentez vous de ce que vous avez.
2. Essayez d'en avoir un maximum.

--
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-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org

Archive: https://lists.debian.org/20140610004...@quad.lairdutemps.org

Philippe Gras

unread,

Jun 9, 2014, 7:20:03 PM6/9/14

to

Le 10 juin 14 à 00:44, Daniel Caillibaud a écrit :

Le 09/06/14 à 14:38, Philippe Gras <ph....@worldonline.fr> a écrit :

PG>
PG> Le 9 juin 14 à 13:32, Daniel Caillibaud a écrit :
PG>
PG> > Le 07/06/14 à 18:16, Philippe Gras <ph....@worldonline.fr> a écrit :

PG> > PG> Pour ce qui est des 400, de certaines 404 et 403, je pense que tu

PG> > PG> peux t'inspirer de ça:

PG> > PG> http://spamcleaner.org/fr/misc/w00tw00t.html
PG> > PG>

PG> > PG> Je vais d'ailleurs le faire moi-même, parce que j'ai plein de
PG> > PG> requêtes avec cette chaîne :
PG> >
PG> > En quoi c'est gênant ?
PG> >
PG> > Répondre à ce genre de requete avec une 404 coûtera bcp moins de
PG> > ressources qu'une règle

PG> > iptables qui va analyser tous les paquets http.
PG>

PG> Ah, bon ? Je veux bien le croire, mais ça demande à être confirmé.

PG> Parce que si ce n'est pas
PG> iptables qui analyse les paquets, c'est le serveur virtuel qui va le
PG> faire ensuite, non ? Donc le

PG> résultat serait identique au niveau du temps d'attente, non ?

Je pense pas, le serveur web n'aura que les urls à pbs à traiter, alors que iptable va

traiter tous les paquets tcp du port 80.

Pas faux :-D

(chez moi les scripts kiddies c'est qq centaines de requetes, milliers quand ils s'excitent, sur

pas mal de millions, j'ai jamais vu d'impact sur les temps de réponse des utilisateurs
légitimes)

J'ai quand même remarqué un impact sur le chargement des pages sur le frontend, mais pas

limitant pour l'utilisateur lambda. Comme ce sont mes sites, mon œil est exercé et exigeant :-)

PG> > Si vraiment ça dérange, ajouter une règle nginx (location ~
PG> > w00tw00t) pour écrire l'ip dans un

PG> > fichier tmp (sans passer par du php, avec echo dans nginx) et une

PG> > tâche cron qui récupère les

PG> > listes pour les blacklister avec iptables et les recopier ailleurs
PG> > pour les enlever au prochain
PG> > passage me parait plus efficace, mais j'ai jamais pris la peine de

PG> > le faire malgré des milliers
PG> > de requetes comme ça par jour.
PG>
PG> Oui, ça me parait une bonne idée. Comment comparer la vitesse
PG> d'exécution des 2 règles ?

La mesurer...
Mais amha c'est de l'énergie gaspillée, sauf si tu veux étudier ce cas en détails...

Pendant que j'y suis… Sur PHP.net, j'ai vu un type mesurer "elseif" et "else if", alors

je n'aurai pas peur du ridicule en vous présentant les résultats !

PG> > Même chose pour la dernière règle de la page, lancer une regex plus

PG> > un algo pour les
PG> > paquets qui match me parait un gaspillage important, mieux vaudrait

PG> > créer un vhost par défaut

PG> > qui va prendre les requetes directes sur l'ip (http://
PG> > xxx.xxx.xxx.xxx/) pour bannir tout le

PG> > monde qui arrive là (faudrait être sûr que les googlebot & co

PG> > lancent jamais ces requetes, pas

PG> > étudié la question car me sens pas concerné avec un varnish en
PG> > frontal).
PG>
PG> C'est déjà le cas chez moi. Je ne crois pas que les crawlers
PG> s'intéressent aux IP, je ne l'ai jamais
PG> remarqué. Mais ça pourrait venir, on ne sait jamais…
PG> >
PG> > J'ai l'impression que ce genre de "protection" ne protège que des
PG> > scripts kiddies assez
PG> > inoffensifs, les vrais méchants sont pas assez stupides pour se
PG> > faire repérer avec des attaques
PG> > aussi connues.
PG>
PG> Je suis complètement d'accord avec cette assertion. Le problème,

PG> c'est que les script kiddies sont

PG> très gourmands, et vraiment très envahissants.

C'est là que j'ai du mal à suivre, si qq milliers de requetes sur une 404 ralentissent ton

appli c'est l'appli qui a un pb.

C'est du Wordpress, donc ce n'est déjà pas très performant à la base… Mais ce ne sont pas

des erreurs 404 dont il s'agit, mais 403 (Forbidden).

(c'est vrai que certains cms envoient toutes les 404 au controleur principal, qui doit charger

toute l'appli pour répondre à la fin 404, si c'est du php utiliser apc doit pas mal réduire la
charge en général, et notamment dans ces cas là).

J'utilise Memcached + Xcache (équivalent à APC, 1 poil moins performant, mais très fiable).

PG> J'aimerais bien réserver l'accès de mon serveur à des utilisateurs
PG> légitimes, car il est tout petit, pas
PG> très costaud, donc le compromis est difficile à trouver entre une
PG> certaine tolérance avec les bots, et
PG> une discrimination rigoureuse…

Si c'est trop compliqué de modifier l'appli faut ajouter qq location pour ces urls à pb, même
avec qq milliers d'appels sur une petite machine, c'est pas ça qui va fatiguer ton nginx.

Je crois que NginX s'en fout, il bloque l'accès sans se poser de question. C'est moi qui fatigue.

L'idée que tu as exposée, j'y ai réfléchi cet après-midi, et je la trouve super.

De plus, elle irait bien avec un anti-spam que j'ai développé en PHP, mais que je souhaiterais

améliorer pour le faire bosser plus vite. Coupler les 2 serait tout simplement mortel :-)

--
Daniel

Pour atteindre le bonheur il y a deux règles :

Philippe Gras

unread,

Jun 10, 2014, 5:40:02 AM6/10/14

to

Aperçu ce matin :

=======================================================

LONDRES (Reuters) - La cyber-criminalité coûte environ 445 milliards de dollars (327 milliards d'euros) par an à l'économie mondiale en termes de croissance, d'innovation et de compétitivité, selon un rapport publié lundi par le Center for Strategic and International Studies (CSIS).

=======================================================

http://fr.reuters.com/article/technologyNews/idFRKBN0EK1A620140609

valentin OVD

unread,

Jun 10, 2014, 6:10:01 AM6/10/14

to

Quelle belle source McAfee... No Comment

De plus, ils confondent hackeurs et pirates...

------------------------------
ovd <valent...@live.fr>

De : Philippe Gras
Envoyé : ‎10/‎06/‎2014 11:33
À : Debian Users (Liste en Français)
Objet : Re: [IPTABLES] [HS] Comment lister les paquets rejetés ?

Pascal Hambourg

unread,

Jun 14, 2014, 7:20:02 AM6/14/14

to

Philippe Gras a ï¿œcrit :
>
>> Le 07/06/2014 23:05, nb a ï¿œcrit :
>>
>>> INPUT ne sert pas pour une connexion dï¿œjï¿œ ï¿œtablie, seulement pour
>>> l'ï¿œtablissement d'une connexion (paquet tcp syn)

Non. INPUT voit passer *tous* les paquets IP reï¿œus destinï¿œs ï¿œ la machine
qui n'ont pas ï¿œtï¿œ bloquï¿œs avant.

> Je n'ai pas vu de forum ou de liste dï¿œdiï¿œe ï¿œ Iptables

En anglais :
Liste Debian : debian-...@lists.debian.org
Liste du noyau : netf...@vger.kernel.org

> Il existe apparemment une diffï¿œrence dans le traitement des paquets
> par iptable selon leur ï¿œtat.

Non. Toute diffï¿œrence de traitement selon l'ï¿œtat du paquet ne peut
provenir que des rï¿œgles mises en place. La seule exception, c'est le
fonctionnement de la table 'nat'. Si iptables ne fait pas ce que tu
veux, alors c'est que ton jeu de rï¿œgles est ï¿œ revoir.

--
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-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org

Archive: https://lists.debian.org/539C2BD2...@plouf.fr.eu.org

Philippe Gras

unread,

Jun 15, 2014, 4:50:01 AM6/15/14

to

Le 14 juin 14 à 13:02, Pascal Hambourg a écrit :

> Philippe Gras a écrit :
>>
>>> Le 07/06/2014 23:05, nb a écrit :
>>>
>>>> INPUT ne sert pas pour une connexion déjà établie, seulement pour
>>>> l'établissement d'une connexion (paquet tcp syn)
>
> Non. INPUT voit passer *tous* les paquets IP reçus destinés à la
> machine
> qui n'ont pas été bloqués avant.
>
>> Je n'ai pas vu de forum ou de liste dédiée à Iptables

>
> En anglais :
> Liste Debian : debian-...@lists.debian.org
> Liste du noyau : netf...@vger.kernel.org

Merci :-)
>
>> Il existe apparemment une différence dans le traitement des paquets
>> par iptable selon leur état.
>
> Non. Toute différence de traitement selon l'état du paquet ne peut
> provenir que des règles mises en place. La seule exception, c'est le

> fonctionnement de la table 'nat'. Si iptables ne fait pas ce que tu

> veux, alors c'est que ton jeu de règles est à revoir.

J'ai compris.

>
> --
> 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-f...@lists.debian.org
> En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
> Archive: https://lists.debian.org/539C2BD2...@plouf.fr.eu.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 debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org

Archive: https://lists.debian.org/DF4E6241-44BD-4434...@worldonline.fr