Forums Linux Autres OS Linux Debian

[IPTABLES] Comment lister les paquets rejetés ?

Le samedi 07 Juin 2014 à 11:30

Philippe Gras

--Apple-Mail-1-771487715
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=WINDOWS-1252;
delsp=yes;
format=flowed

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

--Apple-Mail-1-771487715
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=WINDOWS-1252

<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">Bonjour � toutes et � =
tous,<div><br></div><div>suite � une attaque, j'ai restreint les acc�s=
sur le port 80 de mon serveur avec Iptables =
:</div><div>=
==
</div><div>=
<div>~# iptables -L INPUT -nvx</div><div>Chain INPUT (policy DROP 7178 =
packets, 2268524 bytes)</div><div>    pkts     =
 bytes target     prot opt in     out   =
  source               =
destination         </div><div>   =
    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</div><div>      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</div><div>   93193 37333670 ACCEPT     all =
 --  *      *       0.0.0.0/0 =
           0.0.0.0/0       =
     state RELATED,ESTABLISHED</div><div>   =
 7530   566937 ACCEPT     all  --  lo =
    *       0.0.0.0/0       =
     0.0.0.0/0         =
  </div><div>     330    26804 ACCEPT =
    icmp --  *      *       =
0.0.0.0/0            0.0.0.0/0   =
        </div><div>       0 =
       0 ACCEPT     all  --  * =
     *       0.0.0.0/0     =
       0.0.0.0/0           =
 state RELATED,ESTABLISHED</div><div>    4480   =
234832            tcp  --  * =
     *       0.0.0.0/0     =
       0.0.0.0/0           =
 tcp dpt:80flags: 0x02/0x02 recent: SET name: web side: =
source</div><div>      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</div><div>      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</div><div>    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</div><div>      37     1924 =
DROP       tcp  --  *      * =
      0.0.0.0/0           =
 0.0.0.0/0            tcp =
dpt:80flags: =
0x02/0x02</div></div><div><div>=
==
==
==</div><div>Y a-t-il un moyen de <b>lister les paquets rejet�s</b> =
pour v�rifier que mes r�gles sont conformes</div><div>� ce que je =
souhaitais faire ?</div><div><br></div><div>D'autant plus que le serveur =
virtuel que j'utilise n'est pas Apache, mais NginX. J'ai peur =
que</div><div>les <i>match string</i> soient un peu =
diff�rentes�</div><div><br></div><div>Je me suis servi de ressources =
sur le Web. Je peux vous les communiquer en cas de =
besoin.</div><div><br></div><div>D'avance, merci pour vos =
lumi�res�</div><div><br></div><div>Ph. =
Gras</div><div></div></div></body></html>=

--Apple-Mail-1-771487715--

--
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/044BBF08-BF8D-4561-A542-6776A3607D5C@worldonline.fr

Partager ce contenu :

Vos réponses Page 1 / 2

Trier par : date / pertinence

Le 07/06/2014 à 13:30 #26182342

Le Samedi 7 Juin 2014 11:22 CEST, Philippe Gras

Bonjour Ã toutes et Ã tous,

suite Ã une attaque, j'ai restreint les accÃ¨s sur le port 8 0 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Ã©rifi er 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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/

-1 Répondre en citant

Jean-Michel OLTRA

Le 07/06/2014 à 13:40 #26182352

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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/

-1 Répondre en citant

Philippe Gras

Le 07/06/2014 à 14:20 #26182502

--Apple-Mail-1-782025544
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=ISO-8859-1;
delsp=yes;
format=flowed

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

--
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/

--Apple-Mail-1-782025544
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=ISO-8859-1

<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
--Apple-Mail-1-782025544--

--
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 Répondre en citant

andre_debian

Le 07/06/2014 à 14:40 #26182602

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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/

-1 Répondre en citant

Philippe Gras

Le 07/06/2014 à 18:20 #26182932

--Apple-Mail-1-796325193
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=ISO-8859-1;
delsp=yes;
format=flowed

Le 7 juin 14 à 14:31, 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 "-" "-"
72.44.248.136 - - [06/Jun/2014:00:55:59 +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:05 +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 !

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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/

--Apple-Mail-1-796325193
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=ISO-8859-1

--Apple-Mail-1-796325193--

--
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 Répondre en citant

Francois Lafont

Le 07/06/2014 à 19:40 #26183092

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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/

-1 Répondre en citant

Philippe Gras

Le 07/06/2014 à 19:50 #26183122

--Apple-Mail-2-801736851
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=WINDOWS-1252;
delsp=yes;
format=flowed

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

--
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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/

--Apple-Mail-2-801736851
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=WINDOWS-1252

--Apple-Mail-2-801736851--

--
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 Répondre en citant

Christophe

Le 07/06/2014 à 20:10 #26183152

======================== ========================= ====================
# 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 --dpor t 80 -s 72.44.248.136 -j DROP
# iptables -A INPUT -m state --state RELATED,ESTABLISHED -p tcp --dpor t 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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/

-1 Répondre en citant

Christophe

Le 07/06/2014 à 20:40 #26183252

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 log ique.

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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/

-1 Répondre en citant

Philippe Gras

Le 07/06/2014 à 20:40 #26183262

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
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 Répondre en citant

Poster une réponse