OVH Cloud OVH Cloud

iptables desobeissant

7 réponses
Avatar
Rakotomandimby (R12y) Mihamina
Bonjour,

J'ai un souci avec mes règles iptables, que je n'arrive pas à résoudre.
En fait je n'arrive pas à vraiment tout flusher je crois. (je crois...)
Je vous donne les règles, puis la sortie de iptables-save qui en résulte.
Elle est louche...

Voici les règles:
-----------------

iptables -F
iptables -X

iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT

iptables -A INPUT -s 195.140.140.100 -j ACCEPT
iptables -A INPUT -p tcp --syn -m limit --limit 5/s -j ACCEPT
iptables -A INPUT -p tcp --syn -j LOG --log-level debug --log-prefix 'syn-flood_: '
iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 2/s -j ACCEPT
iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN,RST RST -j LOG --log-level debug --log-prefix 'p_scan_: '

iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j LOG --log-level debug --log-prefix 'p_o_d: '

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

for TCPALLW in 20 21 22 25 80;
{
iptables -A INPUT -p tcp --dport $TCPALLW -j ACCEPT;
}
iptables -A INPUT -j REJECT

Voici iptables-save:
--------------------


# Generated by iptables-save v1.2.11 on Sun Mar 6 20:18:34 2005
*raw
:PREROUTING ACCEPT [19009640:10797875830]
:OUTPUT ACCEPT [21598304:14358170338]
COMMIT
# Completed on Sun Mar 6 20:18:34 2005
# Generated by iptables-save v1.2.11 on Sun Mar 6 20:18:34 2005
*nat
:PREROUTING ACCEPT [187956:18442567]
:POSTROUTING ACCEPT [163954:10355184]
:OUTPUT ACCEPT [0:0]
COMMIT
# Completed on Sun Mar 6 20:18:34 2005
# Generated by iptables-save v1.2.11 on Sun Mar 6 20:18:34 2005
*mangle
:PREROUTING ACCEPT [19008995:10797159494]
:INPUT ACCEPT [18928030:10787965564]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [21597670:14357986359]
:POSTROUTING ACCEPT [21597670:14357986359]
COMMIT
# Completed on Sun Mar 6 20:18:34 2005
# Generated by iptables-save v1.2.11 on Sun Mar 6 20:18:34 2005
*filter
:INPUT DROP [2:580]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [19354:13097523]
-A INPUT -s 195.140.140.100 -j ACCEPT
-A INPUT -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -m limit --limit 5/sec -j ACCEPT
-A INPUT -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -j LOG --log-prefix "syn-flood_: " --log-level 7
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 2/sec -j ACCEPT
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -j LOG --log-prefix "p_scan_: " --log-level 7
-A INPUT -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j LOG --log-prefix "p_o_d: " --log-level 7
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 20 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-port-unreachable
-A OUTPUT -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
COMMIT
# Completed on Sun Mar 6 20:18:34 2005



Voilà. Je n'ai ni prerouting ni nat actif, j'ai impression qu'il cumule
et cumule encore des règles malgré de flush initial...

Ce qui me fait penser ça c'est qu'en fait je fais tourner des services
sur le 8000 et d'autre ports non explicitements autorisés et j'y accède
quand même. Donc il y a problème... mais je vois pas comment initialiser
mieux que -F et -X, d'autant plus que ces règles dans le même ordre sont
en vigueur sur une autre machine (jumelle de celle là) et se comporte
pourtant bien...

Une idée ?
C'est sur une debian testing avec la version 1.2.11 d'iptables.
--
L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses
activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance)
Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)

7 réponses

Avatar
Rakotomandimby (R12y) Mihamina
( Sun, 06 Mar 2005 20:22:30 +0100 ) Rakotomandimby (R12y) Mihamina :
[...]
Une idée ?


Ouh làlà ... je m'inquiète là.. Tichou et l'indien sont passé sans
avoir d'idée. Si Nicolas passe et n'a pas d'idée non plus, je suis bon
pour la casse ;-)

--
L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses
activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance)
Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)

Avatar
Kevin Denis
On 2005-03-06, Rakotomandimby (R12y) Mihamina wrote:

J'ai un souci avec mes règles iptables, que je n'arrive pas à résoudre.
En fait je n'arrive pas à vraiment tout flusher je crois. (je crois...)


qu'est ce qui te fait penser ca (le "je crois") ?

Je vous donne les règles, puis la sortie de iptables-save qui en résulte.
Elle est louche...

en quoi?


Voici les règles:
-----------------

iptables -F
iptables -X

iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT

iptables -A INPUT -s 195.140.140.100 -j ACCEPT


gni?

iptables -A INPUT -p tcp --syn -m limit --limit 5/s -j ACCEPT


ah bah en plus n'importe qui qui t'envoie un syn se fait accepter. Et comme
tu as un -m state ESTABLISHED derriere, autant dire que tu n'as pas de fw
en tcp sur ta machine.

iptables -A INPUT -p tcp --syn -j LOG --log-level debug --log-prefix
'syn-flood_: '


tu as les tcpsyncookies contre les syn floods.

iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit
--limit 2/s -j ACCEPT
iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN,RST RST -j LOG
--log-level debug --log-prefix 'p_scan_: '

Ca me rappelle une doc, ca.


iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit
1/s -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type echo-request -m limit --limit 1/s
-j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j LOG --log-level
debug --log-prefix 'p_o_d: '

p_o_d? ping of death? Le ping of death, ce n'est pas ca. la, ca te

protege (hem) contre un flood de ping.
Le ping of death, c'etait grace aux fragments de paquets d'envoyer un
paquet icmp plus gros que ce que le buffer de reception pouvait accepter
en face: et la boum, l'OS en face part en vrille.
La, ce n'est que du log lorsqu'on t'envoie pleins de pings d'affilee.

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

for TCPALLW in 20 21 22 25 80;
{
iptables -A INPUT -p tcp --dport $TCPALLW -j ACCEPT;
}
iptables -A INPUT -j REJECT


Voilà. Je n'ai ni prerouting ni nat actif, j'ai impression qu'il cumule
et cumule encore des règles malgré de flush initial...

bah le -F ca vire tout normalement. Tu peux lancer un iptables -L -n pour

voir, mais normalement, il n'y a plus rien.

Ce qui me fait penser ça c'est qu'en fait je fais tourner des services
sur le 8000 et d'autre ports non explicitements autorisés et j'y accède
quand même. Donc il y a problème... mais je vois pas comment initialiser
mieux que -F et -X, d'autant plus que ces règles dans le même ordre sont
en vigueur sur une autre machine (jumelle de celle là) et se comporte
pourtant bien...

c'est la ou ca me surprend. Le fait que tu acceptes les syn en premiere

regle le fait rentrer dans le conntrack et le -m state les acceptes
ensuite.

--
Kevin

Avatar
Rakotomandimby (R12y) Mihamina
( Mon, 07 Mar 2005 09:00:58 +0000 ) Kevin Denis :

qu'est ce qui te fait penser ca (le "je crois") ?


Parceque j'ai une liste de services qui tournent sur différents ports.
(la liste des ports à ouvrir sont dans la boucle for plus bas)
Si j'en supprime un, sans killer le service et bien les nouvelles
connexions sont toujours acceptées.

en quoi?


je vois "prerouting", "nat", "forward" et que je vois des ACCEPT et comme
je ne sais pas interpréter çame fais flipper. man iptables-save
n'étant pas d'une grande aide pour interpréter.


iptables -A INPUT -s 195.140.140.100 -j ACCEPT
gni?



Oui, c'est celui de l'hébergeur du serveur. Ils sont sur place et on a
convenu de leur laisser cette "liberté"

iptables -A INPUT -p tcp --syn -m limit --limit 5/s -j ACCEPT
ah bah en plus n'importe qui qui t'envoie un syn se fait accepter. Et

comme tu as un -m state ESTABLISHED derriere, autant dire que tu n'as
pas de fw en tcp sur ta machine.


Donc je supprime ça.

iptables -A INPUT -p tcp --syn -j LOG --log-level debug --log-prefix
'syn-flood_: '


tu as les tcpsyncookies contre les syn floods.


Ok.

iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit
--limit 2/s -j ACCEPT
iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN,RST RST -j LOG
--log-level debug --log-prefix 'p_scan_: '

Ca me rappelle une doc, ca.



Oui. Exact. Mes règles iptables sont un patchwork...:-)

p_o_d? ping of death? Le ping of death, ce n'est pas ca. la, ca te
protege (hem) contre un flood de ping.


Merci

c'est la ou ca me surprend. Le fait que tu acceptes les syn en premiere
regle le fait rentrer dans le conntrack et le -m state les acceptes
ensuite.



--
L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses
activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance)
Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)


Avatar
Kevin Denis
On 2005-03-07, Rakotomandimby (R12y) Mihamina wrote:

qu'est ce qui te fait penser ca (le "je crois") ?


Parceque j'ai une liste de services qui tournent sur différents ports.
(la liste des ports à ouvrir sont dans la boucle for plus bas)
Si j'en supprime un, sans killer le service et bien les nouvelles
connexions sont toujours acceptées.

Ca vient du syn accept des premieres lignes. Mais si tu as des doutes

sur ton firewall, balance un nmap depuis l'exterieur et tu verras ce
qu'il en sort.

en quoi?


je vois "prerouting", "nat", "forward" et que je vois des ACCEPT et comme
je ne sais pas interpréter çame fais flipper. man iptables-save
n'étant pas d'une grande aide pour interpréter.

iptables n'est pas qu'un firewall. C'est un outil de manipulation des

flux reseaux.
On a la table -t filter (celle par defaut quand on n'en precise aucune)
qui sert a filtrer (et donc est un firewall!)
la table -t nat qui sert donc a .. faire du nat (surprise!)
et la table -t mangle qui marque les paquets (afin de decider de leur sort
plus tard)

On filtre donc uniquement sur la table -t filter (les -P DROP) les autres,
on peut laisser en -P ACCEPT

iptables -A INPUT -s 195.140.140.100 -j ACCEPT
gni?



Oui, c'est celui de l'hébergeur du serveur. Ils sont sur place et on a
convenu de leur laisser cette "liberté"

groumpf:

iptables -A INPUT -p tcp --dport 22 -j ACCEPT
epissetout! Non mais. ;)

iptables -A INPUT -p tcp --syn -m limit --limit 5/s -j ACCEPT
ah bah en plus n'importe qui qui t'envoie un syn se fait accepter. Et

comme tu as un -m state ESTABLISHED derriere, autant dire que tu n'as
pas de fw en tcp sur ta machine.


Donc je supprime ça.

Tu verras, ca arrangera deja vachement tes problemes d'acces :)

--
Kevin



Avatar
Rakotomandimby (R12y) Mihamina
( Mon, 07 Mar 2005 10:32:55 +0000 ) Kevin Denis :

Tu verras, ca arrangera deja vachement tes problemes d'acces :)


Le problème c'est qu'il n'y avait aucun problème d'accès tu sais ? ;-P
C'est ce qui m'inquiétait...
Mais oui j'ai fait et c'est effectivement ça. Bon ben... cete règle
était l'une des plus vieilles règles de mon patchwork, c'est à dire
qu'elle date de l'époque ou... l'écriture a été inventée et que je
savais pas lire (surtout les regles iptables). Voilà.

--
L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses
activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance)
Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)

Avatar
Pascal
Salut,


J'ai un souci avec mes règles iptables, que je n'arrive pas à résoudre.
En fait je n'arrive pas à vraiment tout flusher je crois. (je crois...)
Je vous donne les règles, puis la sortie de iptables-save qui en résulte.

Voici les règles:
-----------------

iptables -F
iptables -X

iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT

iptables -A INPUT -s 195.140.140.100 -j ACCEPT
iptables -A INPUT -p tcp --syn -m limit --limit 5/s -j ACCEPT


Je ne commenterai pas cette règle, Kevin l'a déjà fait.

iptables -A INPUT -p tcp --syn -j LOG --log-level debug --log-prefix 'syn-flood_: '
[...]

iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN,RST RST -j LOG --log-level debug --log-prefix 'p_scan_: '
iptables -A INPUT -p icmp --icmp-type echo-request -j LOG --log-level debug --log-prefix 'p_o_d: '
[...]


Avec tout ça, je sais comment flooder tes logs ;-)
Sérieux, tu devrais limiter l'écriture dans les logs avec -m limit.

Voici iptables-save:
--------------------

*raw
:PREROUTING ACCEPT [19009640:10797875830]
:OUTPUT ACCEPT [21598304:14358170338]
COMMIT
*nat
:PREROUTING ACCEPT [187956:18442567]
:POSTROUTING ACCEPT [163954:10355184]
:OUTPUT ACCEPT [0:0]
COMMIT
*mangle
:PREROUTING ACCEPT [19008995:10797159494]
:INPUT ACCEPT [18928030:10787965564]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [21597670:14357986359]
:POSTROUTING ACCEPT [21597670:14357986359]
COMMIT
*filter
[contenu correspondant aux règles précédentes]


Voilà. Je n'ai ni prerouting ni nat actif, j'ai impression qu'il cumule
et cumule encore des règles malgré de flush initial...


Deux remarques.
1) Si iptables-save affiche une table x, c'est que le module iptable_x
correspondant est chargé, qu'il y ait des règles dedans ou pas. Regarde
la sortie de lsmod, tu devrais y voir iptable_nat, iptable_mangle et
iptable_raw. Par contre tu vois bien que seule la table filter contient
des règles (lignes commençant par "-A"). Il est normal que les
politiques par défaut des chaînes des autres tables (lignes commençant
par ":") soient à ACCEPT, seule la table filter doit servir à faire du
filtrage. Si tu ne te sers pas des autres tables, tu peux décharger
leurs modules.

2) Les commandes -F et -X ne vident que la table spécifiée par l'option
-t. Par défaut, iptables agit sur la table filter. Donc tes deux
premières lignes ne vident que la table filter. Pour être sûr de vider
toutes les tables, il faut ajouter :

iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
...

En conclusion, la sortie de iptables-save est tout à fait normale et
conforme à tes règles, et le comportement observé aussi. iptables a
certainement encore des bugs, mais pas ici. A part ça, on pourrait
améliorer tes règles mais c'est un autre sujet.

Ouh làlà ... je m'inquiète là.. Tichou et l'indien sont passé sans
avoir d'idée. Si Nicolas passe et n'a pas d'idée non plus, je suis bon
pour la casse ;-)


C'est vachement sympa pour les autres, dis donc :-

--
Pascal
Vous pouvez me tutoyer.
Piège à spam :

Avatar
Rakotomandimby (R12y) Mihamina
( Mon, 07 Mar 2005 13:17:53 +0100 ) :

C'est vachement sympa pour les autres, dis donc


Ouh là là. Faut pas être susceptible à ce point quand même. :-)
Si je dois citer tout le monde, je ne m'en sortirai pas.
Je sais que j'aurais dû, dans ce cas, ne citer personne, mais bon... tu
sais, ça le fait pas d'être pris à la lettre comme ça.
Ca va tellement mieux quand on ne se prends pas chacun au pied de la
lettre...

En tout cas merci pour tes conseils.
--
L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses
activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance)
Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)