[IPTABLES] Comment lister les paquets rejetés ?
Le
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
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
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/
Le samedi 07 juin 2014, Philippe Gras a écrit...
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/
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 :
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
--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/
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/
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 :
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.
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 !
--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/
Le 07/06/2014 18:16, Philippe Gras a écrit :
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/
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 :
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
--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/
Le 07/06/2014 19:37, Francois Lafont a écrit :
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/
Le 07/06/2014 20:31, Philippe Gras a écrit :
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/
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 ;-)
--
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/