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...
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)
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)
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)
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)
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...
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.
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
On 2005-03-06, Rakotomandimby (R12y) Mihamina <mihamina@mail.rktmb.org> 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...
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.
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.
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.
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
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.
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)
( 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.
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)
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.
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)
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
On 2005-03-07, Rakotomandimby (R12y) Mihamina <mihamina@mail.rktmb.org> 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 :)
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
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)
( 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)
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)
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.
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 :
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 :
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.
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 :
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 : boite-a-spam@plouf.fr.eu.org
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.
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 :
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 :
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)
( Mon, 07 Mar 2005 13:17:53 +0100 ) Pascal@plouf :
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)
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)