[firewall] iptables, le script parfait?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

xtz.info@gmail.com wrote:

Bonjours,

voilà, j'aimerai savoir si une personne avait fait un script iptables
pas mal? (parfait même)
qui bloque ce qu'il faut bloqué (SYN FLOOD, SCAN NULL....)
un peut comme iplog (qui enregistre les types d'attaque connues) mais
sans iplog...

je vous remerci d'avance

Bonsoir,

tu peux jeter un coup d'oeil sur :

http://smhteam.info/upload_wiki/firewall.tar.gz

tu y trouveras peut etre ton bonheur. Je l'ai mis au point avec l'aide
de la liste. Il ne correspondra pas forcement a tes besoins, mais tu
peux surement reprendre des idees.

- --
Franck Joncourt
http://www.debian.org
http://smhteam.info/wiki/
GPG server : pgpkeys.mit.edu
Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFwjcpxJBTTnXAif4RAkHKAJ9Q5nJE7WNBCy7tVso7XGVW8o+ftgCfYLTA
8JgV6Bb2dUzbkyIlSnRIgXw =JoEx
-----END PGP SIGNATURE-----


___________________________________________________________
The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

franck a écrit :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

xtz.info@gmail.com wrote:

Bonjours,

voilà, j'aimerai savoir si une personne avait fait un script iptables
pas mal? (parfait même)
qui bloque ce qu'il faut bloqué (SYN FLOOD, SCAN NULL....)
un peut comme iplog (qui enregistre les types d'attaque connues) mais
sans iplog...

je vous remerci d'avance

Bonsoir,

tu peux jeter un coup d'oeil sur :

http://smhteam.info/upload_wiki/firewall.tar.gz

tu y trouveras peut etre ton bonheur. Je l'ai mis au point avec l'aide
de la liste. Il ne correspondra pas forcement a tes besoins, mais tu
peux surement reprendre des idees.

merci :) ça répond parfaitement à mes besoins d'idées ;)

- --
Franck Joncourt
http://www.debian.org
http://smhteam.info/wiki/
GPG server : pgpkeys.mit.edu
Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFwjcpxJBTTnXAif4RAkHKAJ9Q5nJE7WNBCy7tVso7XGVW8o+ftgCfYLTA
8JgV6Bb2dUzbkyIlSnRIgXw > =JoEx
-----END PGP SIGNATURE-----


___________________________________________________________
The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gaëtan PERRIER wrote:

Le Thu, 01 Feb 2007 19:53:29 +0100
franck <joncourt_franck@yahoo.co.uk> a écrit:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

xtz.info@gmail.com wrote:

Bonjours,

voilà, j'aimerai savoir si une personne avait fait un script
iptables pas mal? (parfait même)
qui bloque ce qu'il faut bloqué (SYN FLOOD, SCAN NULL....)
un peut comme iplog (qui enregistre les types d'attaque connues)
mais sans iplog...

je vous remerci d'avance

Bonsoir,

tu peux jeter un coup d'oeil sur :

http://smhteam.info/upload_wiki/firewall.tar.gz

tu y trouveras peut etre ton bonheur. Je l'ai mis au point avec
l'aide de la liste. Il ne correspondra pas forcement a tes besoins,
mais tu peux surement reprendre des idees.

J'utilise le script en pièce jointe. Si vous pouviez donner votre avis dessus, ça m'intéresse...

Merci.

Gaëtan

Je regarde cela de plus pres demain soir et je te donnes mon avis.

- --
Franck Joncourt
http://www.debian.org
http://smhteam.info/wiki/
GPG server : pgpkeys.mit.edu
Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFwmBfxJBTTnXAif4RAr9MAJ9DbG2csftWXg4tSh9J1WwhubUsTQCdEvtZ
E5HF8aaA4nxAwfeWgbL/kL0 =PFJS
-----END PGP SIGNATURE-----




___________________________________________________________
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
http://uk.docs.yahoo.com/nowyoucan.html


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Le Thu, 01 Feb 2007 22:49:19 +0100
franck <joncourt_franck@yahoo.co.uk> a écrit:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gaëtan PERRIER wrote:
> Le Thu, 01 Feb 2007 19:53:29 +0100
> franck <joncourt_franck@yahoo.co.uk> a écrit:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> xtz.info@gmail.com wrote:
>>> Bonjours,
>>>
>>> voilà, j'aimerai savoir si une personne avait fait un script
>>> iptables pas mal? (parfait même)
>>> qui bloque ce qu'il faut bloqué (SYN FLOOD, SCAN NULL....)
>>> un peut comme iplog (qui enregistre les types d'attaque connues)
>>> mais sans iplog...
>>>
>>> je vous remerci d'avance
>>>
>>>
>> Bonsoir,
>>
>> tu peux jeter un coup d'oeil sur :
>>
>> http://smhteam.info/upload_wiki/firewall.tar.gz
>>
>> tu y trouveras peut etre ton bonheur. Je l'ai mis au point avec
>> l'aide de la liste. Il ne correspondra pas forcement a tes
>> besoins, mais tu peux surement reprendre des idees.
>
> J'utilise le script en pièce jointe. Si vous pouviez donner votre
> avis dessus, ça m'intéresse...
>
> Merci.
>
> Gaëtan
>

Je regarde cela de plus pres demain soir et je te donnes mon avis.

Merci.

Gaëtan


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Salut,

Gaëtan PERRIER a écrit :

J'utilise le script en pièce jointe. Si vous pouviez donner votre avis dessus, ça m'intéresse...

$ grep -c -- -N iptables-final-1-adsl.sh

0

Ça commence mal. Un jeu de règles sans chaînes utilisateur ne peut pas
être un bon jeu de règles. ;-)

# Paramètrage du réseau local (LAN = Local Area Network)
LAN_INTERFACE=lan ; # Interface réseau interne
LAN_IP2.168.10.1 ; # Adresse réseau interne
LAN_NETWORK2.168.10.0/24 ; # Réseau interne
LAN_BROADCAST2.168.10.255 ; # Adresse de broadcast interne

# Paramètrage de la connexion Internet (WAN = Wild Area Network = Réseau Large)
WAN_INTERFACE­sl ; # Interface réseau externe (Internet)
if [ -z "$@" ]; then
WAN_IP=`/sbin/ifconfig $WAN_INTERFACE | grep "inet adr" | sed "s/^[: a-z]*([.0-9]*).*/1/g"` ; # Récupère l'adresse réseau externe (Internet)
elif [ "$@" == "boot" ]; then
WAN_IP=$new_ip_address
fi

Où la variable $new_ip_address est-elle définie ? Que contient-elle ?

[...]

###############################################################################
# Règles de conexion au reseau local

"connexion".

# Tout est autorisé
###############################################################################

echo "+ Règles du réseau local ($LAN_INTERFACE - $LAN_IP - $LAN_NETWORK)"
# Connexions firewall <-> réseau
iptables -t filter -A OUTPUT -o $LAN_INTERFACE -s $LAN_IP -d $LAN_NETWORK -p all -j ACCEPT
iptables -t filter -A INPUT -i $LAN_INTERFACE -s $LAN_NETWORK -d $LAN_IP -p all -j ACCEPT

Ces règles oublient de prendre en compte les paquets émis (resp. reçus)
sur $LAN_INTERFACE avec l'adresse source (resp. destination) $WAN_IP,
qui sont pourtant parfaitement légitimes. Ne pas oublier qu'une adresse
IP appartient à une machine au moins autant qu'à une interface.

# Connexions firewall <-> broadcast réseau
iptables -t filter -A OUTPUT -o $LAN_INTERFACE -s $LAN_IP -d $LAN_BROADCAST -p all -j ACCEPT

Cette règle est redondante puisque l'adresse de broadcast dirigé
$LAN_BROADCAST est incluse dans le sous-réseau $LAN_NETWORK. Par contre
l'adresse de broadcast limité 255.255.255.255 n'est pas prise en compte.

iptables -t filter -A INPUT -i $LAN_INTERFACE -s $LAN_BROADCAST -d $LAN_IP -p all -j ACCEPT

Surtout pas ! L'adresse source ne peut être une adresse de broadcast.
Les réponses à un broadcast IP se font avec une adresse source d'hôte
(unicast).

###############################################################################
# Règles de connexion à Internet
# Seul les connexions initialisés par la machine sont autorisées
# C'est le suivit de connexion
###############################################################################

"suivi", sans "t".

# Chargement des modules pour le suivit de connexion
modprobe ip_conntrack
modprobe ip_conntrack_ftp
modprobe ip_conntrack_irc

echo "+ Règles pour Internet ($WAN_INTERFACE - $WAN_IP - $WAN_NETWORK)"
iptables -t filter -A OUTPUT -o $WAN_INTERFACE -s $WAN_IP -d $WAN_NETWORK -p all -m state --state ! INVALID -j ACCEPT
iptables -t filter -A INPUT -i $WAN_INTERFACE -s $WAN_NETWORK -d $WAN_IP -p tcp --tcp-flags ! ALL SYN -m state --state NEW,RELATED -j DROP #06/05/2006
iptables -t filter -A INPUT -i $WAN_INTERFACE -s $WAN_NETWORK -d $WAN_IP -p all -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t filter -A INPUT -i $WAN_INTERFACE -s $WAN_NETWORK -d $WAN_IP -p tcp --destination-port auth -j REJECT --reject-with tcp-reset #06/05/2006

La dernière règle ne serait pas nécessaire si toutes les connexions
indésirables étaient traitées par REJECT au lieu de DROP.

###############################################################################
# Règles pour le port forwarding
# Pour que le port forwarding soit activé, il faut la variable "$PF" soit à "1"
###############################################################################

if [ "$PF" == "1" ]; then
# Chargement des modules pour le port forwarding
modprobe iptable_nat

echo "+ Autorise le port forwardong de $WAN_IP:$PF_PORT -> $PF_IP:$PF_PORT"
iptables -t filter -A FORWARD -i $WAN_INTERFACE -o $LAN_INTERFACE -s $WAN_NETWORK -d $LAN_NETWORK -p $PF_PROTO --dport $PF_PORT -m state --state ! INVALID -j ACCEPT
iptables -t filter -A FORWARD -i $LAN_INTERFACE -o $WAN_INTERFACE -s $LAN_NETWORK -d $WAN_NETWORK -p $PF_PROTO --sport $PF_PORT -m state --state ESTABLISHED,RELATED -j ACCEPT

Il serait plus sûr de limiter l'adresse de destination à $PF_IP au lieu
de $LAN_NETWORK.

iptables -t nat -A PREROUTING -i $WAN_INTERFACE -s $WAN_NETWORK -d $WAN_IP -p $PF_PROTO --dport $PF_PORT -j DNAT --to-destination $PF_IP
iptables -t nat -A POSTROUTING -o $LAN_INTERFACE -s $WAN_NETWORK -d $PF_IP -p $PF_PROTO --dport $PF_PORT -j SNAT --to-source $LAN_IP

Quel est l'intérêt de cette règle SNAT dans nat/POSTROUTING ? Masquer
l'adresse source réelle de la connexion à la machine vers laquelle le
port est redirigé me paraît plutôt contre-productif.

echo 1 > /proc/sys/net/ipv4/ip_forward

else
echo "+ Le port forwarding N'est PAS autorisé"
if [ "$NAT" == "0" ]; then
echo 0 > /proc/sys/net/ipv4/ip_forward
fi
fi

Le test de la valeur de $NAT ne sert à rien puisque de toute façon
ip_forward est déjà à 0. Voir mon commentaire sur l'IP masquerading.

###############################################################################
# Règles pour l'IP masquerading
# Pour que le IP masquerading soit activé, il faut la variable "$NAT" soit à "1"
###############################################################################

if [ "$NAT" == "1" ]; then
# Chargement des modules pour l'IP masquerading
modprobe iptable_nat
modprobe ip_nat_ftp
modprobe ip_nat_irc

echo "+ Autorise l'IP masquerading de $LAN_NETWORK -> $WAN_NETWORK"
iptables -t filter -A FORWARD -i $LAN_INTERFACE -o $WAN_INTERFACE -s $LAN_NETWORK -d $WAN_NETWORK -p all -m state --state ! INVALID -j ACCEPT

Si on veut être puriste, "! INVALID" n'est pas approprié ici. En effet
cela équivaut à NEW,RELATED,ESTABLISHED,UNTRACKED. Or les paquets dans
l'état UNTRACKED, comme ceux dans l'état INVALID, sont ignorés par les
chaînes de la table 'nat'. Par conséquent un tel paquet serait
retransmis sur l'interface WAN avec son adresse source privée originale,
ce qui n'est pas souhaitable. Certes en l'absence de règles NOTRACK,
aucun paquet ne peut se retrouver dans l'état UNTRACKED.

iptables -t filter -A FORWARD -i $WAN_INTERFACE -o $LAN_INTERFACE -s $WAN_NETWORK -d $LAN_NETWORK -p all -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -t nat -A POSTROUTING -o $WAN_INTERFACE -s $LAN_NETWORK -d $WAN_NETWORK -p all -j MASQUERADE

echo 1 > /proc/sys/net/ipv4/ip_forward

else
echo "+ L'IP masquerading N'est PAS autorisé"
echo 0 > /proc/sys/net/ipv4/ip_forward
fi

Je crois qu'ici il y a un bug : si l'ip_forward avait était activé pour
le port forwarding ($PF=1), $NAT=0 le désactive ! Ne serait-il pas plus
simple de l'activer à un seul endroit si ($NAT=1 ou $PF=1) ?

[...]

###############################################################################
# Règles pour MSN
###############################################################################

Ces règles sont pour un client MSN Messenger ou un serveur hébergé sur
la machine ?

if [ "$MSN" == "1" ]; then
echo "+ Règles pour MSN"
iptables -A INPUT -i $WAN_INTERFACE -d $WAN_IP -p tcp --dport $MSN_TCP_PORT -m state --state ! INVALID -j ACCEPT

Cette règle est inutile pour un client MSN Messenger car il émet une
connexion sortante vers le port destination 1863.

iptables -A OUTPUT -o $WAN_INTERFACE -d $WAN_IP -p tcp --sport $MSN_TCP_PORT -m state --state RELATED,ESTABLISHED -j ACCEPT

Je soupçonne un oubli de modification de -d en -s après un copier/coller.
Même sans cette erreur, cette règle est redondante car une règle
précédente autorise déjà tout le trafic sortant non INVALID.
D'autre part, un paquet de réponse TCP ou UDP (--sport) ne peut pas
avoir l'état RELATED. Seul le premier paquet d'une connexion liée peut
avoir cet état.
Ces remarques sont aussi valables pour les autres règles OUTPUT et pour
les autres applications. J'ai pris le cas de MSN Messenger parce que je
le connais plus que les autres.

iptables -A INPUT -i $WAN_INTERFACE -d $WAN_IP -p udp --dport $MSN_UDP_PORT -m state --state ! INVALID -j ACCEPT
iptables -A OUTPUT -o $WAN_INTERFACE -d $WAN_IP -p udp --sport $MSN_UDP_PORT -m state --state RELATED,ESTABLISHED -j ACCEPT

Je ne crois pas que le port 1863 soit utilisé en UDP.

iptables -A INPUT -i $WAN_INTERFACE -d $WAN_IP -p tcp --dport $MSN_TRANSFERT_TCP_PORT -m state --state ! INVALID -j ACCEPT
iptables -A OUTPUT -o $WAN_INTERFACE -d $WAN_IP -p tcp --sport $MSN_TRANSFERT_TCP_PORT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i $WAN_INTERFACE -d $WAN_IP -p udp --dport $MSN_TRANSFERT_UDP_PORT -m state --state ! INVALID -j ACCEPT
iptables -A OUTPUT -o $WAN_INTERFACE -d $WAN_IP -p udp --sport $MSN_TRANSFERT_UDP_PORT -m state --state RELATED,ESTABLISHED -j ACCEPT

Je ne crois pas que le transfert de fichier utilise UDP.

iptables -A INPUT -i $WAN_INTERFACE -d $WAN_IP -p tcp --dport $MSN_VOIX_TCP_PORT -m state --state ! INVALID -j ACCEPT
iptables -A OUTPUT -o $WAN_INTERFACE -d $WAN_IP -p tcp --sport $MSN_VOIX_TCP_PORT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i $WAN_INTERFACE -d $WAN_IP -p udp --dport $MSN_VOIX_UDP_PORT -m state --state ! INVALID -j ACCEPT
iptables -A OUTPUT -o $WAN_INTERFACE -d $WAN_IP -p udp --sport $MSN_VOIX_UDP_PORT -m state --state RELATED,ESTABLISHED -j ACCEPT
fi

Je voudrais faire une remarque générale au sujet des nombreuses règles
acceptant des paquets dans l'état RELATED ou ESTABLISHED. Si le suivi de
connexion a classé un paquet dans un de ces états, c'est que le trafic
précédent auquel il est lié a déjà été vu et accepté (à l'exception des
paquets RST ou ICMP émis localement en réponse à un paquet rejeté). Par
conséquent il n'est pas utile de recréer ces règles pour chaque
interface, application, protocole, port... On peut se contenter d'une
unique règle acceptant tous les paquets dans l'état RELATED ou
ESTABLISHED en début de chaîne (pour l'efficacité, l'immense majorité
des paquets étant dans l'état ESTABLISHED) suivie de règles traitant les
paquets dans l'état NEW au cas par cas. Ça allège et simplifie
sensiblement le jeu de règles sans sacrifier à la sécurité. Beaucoup de
jeux de règles sont construits ainsi.

[...]

###############################################################################
# Règles pour le log
###############################################################################

Il n'y a rien de prévu pour le log des paquets dans FORWARD ?


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pascal Hambourg wrote:

Salut,

Gaëtan PERRIER a écrit :

J'utilise le script en pièce jointe. Si vous pouviez donner votre avis
dessus, ça m'intéresse...

$ grep -c -- -N iptables-final-1-adsl.sh
0

Ça commence mal. Un jeu de règles sans chaînes utilisateur ne peut pas
être un bon jeu de règles. ;-)

J'adore la methode de test :p!
Je suis d'accord. Depuis que j'ai commence avec les chaines
utilisateurs, je trouve que c'est difficile de s'en passer. A mon avis
ca reste incontournable pour obtenir un script facile a lire et flexible.

Il serait plus sûr de limiter l'adresse de destination à $PF_IP au lieu
de $LAN_NETWORK.

iptables -t nat -A PREROUTING -i $WAN_INTERFACE -s
$WAN_NETWORK -d $WAN_IP -p $PF_PROTO --dport $PF_PORT -j DNAT
--to-destination $PF_IP
iptables -t nat -A POSTROUTING -o $LAN_INTERFACE -s
$WAN_NETWORK -d $PF_IP -p $PF_PROTO --dport $PF_PORT -j SNAT
--to-source $LAN_IP

Quel est l'intérêt de cette règle SNAT dans nat/POSTROUTING ? Masquer
l'adresse source réelle de la connexion à la machine vers laquelle le
port est redirigé me paraît plutôt contre-productif.

La regle m'a bien interpelee aussi. Si j'ai bien compris ce que tu
tentes de faire, j'aurais, pour ma part, tout simplement ouvert le port
80 sur l'interface WAN.

echo 1 > /proc/sys/net/ipv4/ip_forward

else
echo "+ Le port forwarding N'est PAS autorisé"
if [ "$NAT" == "0" ]; then
echo 0 > /proc/sys/net/ipv4/ip_forward
fi
fi

Un test logique en debut de fichier en fonction des differentes
variables serait plus adapte a la gestion des quelques
"/proc/sys/net/ipv4/ip_forward" presents dans le script.

Je voudrais faire une remarque générale au sujet des nombreuses règles
acceptant des paquets dans l'état RELATED ou ESTABLISHED. Si le suivi de
connexion a classé un paquet dans un de ces états, c'est que le trafic
précédent auquel il est lié a déjà été vu et accepté (à l'exception des
paquets RST ou ICMP émis localement en réponse à un paquet rejeté). Par
conséquent il n'est pas utile de recréer ces règles pour chaque
interface, application, protocole, port... On peut se contenter d'une
unique règle acceptant tous les paquets dans l'état RELATED ou
ESTABLISHED en début de chaîne (pour l'efficacité, l'immense majorité
des paquets étant dans l'état ESTABLISHED) suivie de règles traitant les
paquets dans l'état NEW au cas par cas. Ça allège et simplifie
sensiblement le jeu de règles sans sacrifier à la sécurité. Beaucoup de
jeux de règles sont construits ainsi.

Je n'ai aucune chance de trouver quoi que ce soit de plus que Pasal,
bien qu'ayant parcouru le script en essayant de trouver les erreurs.
Mais bon, dans l'idee general, je dirais que j'ai eu des difficultes a
le lire du fait :
- du manque des chaines utilisateurs,
- de la presence importantes des differents etats de connexions,
- de la gestion sans fin des addresses

Autrement, pour epurer tu peux supprimer "-t filter", c'est la table par
defaut. Idem pour "- all", c'est l'option par defaut.

J'ai remarque que tu utilisais les variables pour stocker les ports
presents dans tes regles. Je serais plutot amene a les mettre dans mon
fichier /etc/services, mais ca n'engage que moi, et a les en extraire en
debut de script. Cela a l'avantage de les voir sous forme de nom quand
tu fais un iptables -L -v ou une commande netstat. C'est bien plus
explicite avec des noms.

Dernier chose, je n'ai pas vu de gestion explicite des types icmp, c'est
peut etre un point a considerer.

- --
Franck Joncourt
http://www.debian.org
http://smhteam.info/wiki/
GPG server : pgpkeys.mit.edu
Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFw5PuxJBTTnXAif4RAoEdAKCQSDJRufCCJf2YdNQ/5k3WQ1ulRgCfQuI3
kLQaBDzu5JGkoWx/GQv7dIA =tzlU
-----END PGP SIGNATURE-----


___________________________________________________________
Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Tout d'abord merci pour l'analyse!
Je vois que j'ai encore à apprendre (mais bon je m'y attendais!)
Réponses insérées:

Le Fri, 02 Feb 2007 16:03:20 +0100
Pascal Hambourg <pascal.mail@plouf.fr.eu.org> a écrit:

Salut,

Gaëtan PERRIER a écrit :
>
> J'utilise le script en pièce jointe. Si vous pouviez donner votre
> avis dessus, ça m'intéresse...

$ grep -c -- -N iptables-final-1-adsl.sh
0

Ça commence mal. Un jeu de règles sans chaînes utilisateur ne peut
pas être un bon jeu de règles. ;-)

Bon, je me pencherai sur la question des chaînes utilisateurs. Pour l'instant je ne sais pas ce que c'est...

> # Paramètrage du réseau local (LAN = Local Area Network)
> LAN_INTERFACE=lan ; # Interface réseau interne
> LAN_IP2.168.10.1 ; # Adresse réseau interne
> LAN_NETWORK2.168.10.0/24 ; # Réseau interne
> LAN_BROADCAST2.168.10.255 ; # Adresse de broadcast interne
>
> # Paramètrage de la connexion Internet (WAN = Wild Area Network > > # Réseau Large)
> WAN_INTERFACE­sl ; # Interface réseau externe
> (Internet) if [ -z "$@" ]; then
> WAN_IP=`/sbin/ifconfig $WAN_INTERFACE | grep "inet adr" |
> sed "s/^[: a-z]*([.0-9]*).*/1/g"` ; # Récupère l'adresse
> réseau externe (Internet) elif [ "$@" == "boot" ]; then WAN_IP > > $new_ip_address fi

Où la variable $new_ip_address est-elle définie ? Que
contient-elle ?

ça vient du client dhcp. Ce script est appelé à chaque attribution d'une adresse ip sur mon interface réseaux allant vers internet.

[...]
> ###############################################################################
> # Règles de conexion au reseau local

"connexion".

> # Tout est autorisé
> ###############################################################################
>
> echo "+ Règles du réseau local ($LAN_INTERFACE - $LAN_IP -
> $LAN_NETWORK)"
> # Connexions firewall <-> réseau
> iptables -t filter -A OUTPUT -o $LAN_INTERFACE -s $LAN_IP -d
> $LAN_NETWORK -p all -j ACCEPT iptables -t filter -A INPUT -i
> $LAN_INTERFACE -s $LAN_NETWORK -d $LAN_IP -p all -j ACCEPT

Ces règles oublient de prendre en compte les paquets émis (resp.
reçus) sur $LAN_INTERFACE avec l'adresse source (resp. destination)
$WAN_IP, qui sont pourtant parfaitement légitimes. Ne pas oublier
qu'une adresse IP appartient à une machine au moins autant qu'à une
interface.

Je n'ai pas bien compris comment ça peu arriver?

> # Connexions firewall <-> broadcast réseau
> iptables -t filter -A OUTPUT -o $LAN_INTERFACE -s $LAN_IP -d
> $LAN_BROADCAST -p all -j ACCEPT

Cette règle est redondante puisque l'adresse de broadcast dirigé
$LAN_BROADCAST est incluse dans le sous-réseau $LAN_NETWORK. Par
contre l'adresse de broadcast limité 255.255.255.255 n'est pas
prise en compte.

> iptables -t filter -A INPUT -i $LAN_INTERFACE -s $LAN_BROADCAST
> -d $LAN_IP -p all -j ACCEPT

Surtout pas ! L'adresse source ne peut être une adresse de
broadcast. Les réponses à un broadcast IP se font avec une adresse
source d'hôte (unicast).

> ###############################################################################
> # Règles de connexion à Internet
> # Seul les connexions initialisés par la machine sont autorisées
> # C'est le suivit de connexion
> ###############################################################################

"suivi", sans "t".

> # Chargement des modules pour le suivit de connexion
> modprobe ip_conntrack
> modprobe ip_conntrack_ftp
> modprobe ip_conntrack_irc
>
> echo "+ Règles pour Internet ($WAN_INTERFACE - $WAN_IP -
> $WAN_NETWORK)" iptables -t filter -A OUTPUT -o $WAN_INTERFACE -s
> $WAN_IP -d $WAN_NETWORK -p all -m state --state !
> INVALID -j ACCEPT iptables -t filter -A INPUT -i
> $WAN_INTERFACE -s $WAN_NETWORK -d $WAN_IP -p tcp --tcp-flags !
> ALL SYN -m state --state NEW,RELATED -j DROP #06/05/2006 iptables
> -t filter -A INPUT -i $WAN_INTERFACE -s $WAN_NETWORK -d $WAN_IP
> -p all -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -t
> filter -A INPUT -i $WAN_INTERFACE -s $WAN_NETWORK -d $WAN_IP -p
> tcp --destination-port auth -j REJECT --reject-with tcp-reset
> #06/05/2006

La dernière règle ne serait pas nécessaire si toutes les connexions
indésirables étaient traitées par REJECT au lieu de DROP.

Peux-tu m'expliquer pourquoi?
Initialement je n'avais pas les lignes finissant par #06/05/2006, sont-elles nécessaires?

> ###############################################################################
> # Règles pour le port forwarding
> # Pour que le port forwarding soit activé, il faut la variable
> # "$PF" soit à "1"
> ###############################################################################
>
> if [ "$PF" == "1" ]; then
> # Chargement des modules pour le port forwarding
> modprobe iptable_nat
>
> echo "+ Autorise le port forwardong de $WAN_IP:$PF_PORT ->
> $PF_IP:$PF_PORT" iptables -t filter -A FORWARD -i $WAN_INTERFACE
> -o $LAN_INTERFACE -s $WAN_NETWORK -d $LAN_NETWORK -p $PF_PROTO
> --dport $PF_PORT -m state --state ! INVALID -j ACCEPT
> iptables -t filter -A FORWARD -i $LAN_INTERFACE -o $WAN_INTERFACE
> -s $LAN_NETWORK -d $WAN_NETWORK -p $PF_PROTO --sport $PF_PORT -m
> state --state ESTABLISHED,RELATED -j ACCEPT

Il serait plus sûr de limiter l'adresse de destination à $PF_IP au
lieu de $LAN_NETWORK.

Comme c'est un script que j'ai repris et que je ne fais de port forwarding je n'ai pas regardé cette partie.

> iptables -t nat -A PREROUTING -i
> $WAN_INTERFACE -s $WAN_NETWORK -d $WAN_IP -p $PF_PROTO
> --dport $PF_PORT -j DNAT --to-destination $PF_IP iptables -t
> nat -A POSTROUTING -o $LAN_INTERFACE -s
> $WAN_NETWORK -d $PF_IP -p $PF_PROTO --dport $PF_PORT -j
> SNAT --to-source $LAN_IP

Quel est l'intérêt de cette règle SNAT dans nat/POSTROUTING ?
Masquer l'adresse source réelle de la connexion à la machine vers
laquelle le port est redirigé me paraît plutôt contre-productif.

> echo 1 > /proc/sys/net/ipv4/ip_forward
>
> else
> echo "+ Le port forwarding N'est PAS autorisé"
> if [ "$NAT" == "0" ]; then
> echo 0 > /proc/sys/net/ipv4/ip_forward
> fi
> fi

Le test de la valeur de $NAT ne sert à rien puisque de toute façon
ip_forward est déjà à 0. Voir mon commentaire sur l'IP masquerading.

Oui ce n'est pas faux! Mais bon le port forwarding n'est pas utilisé, donc pas grave. :-)

> ###############################################################################
> # Règles pour l'IP masquerading
> # Pour que le IP masquerading soit activé, il faut la variable
> # "$NAT" soit à "1"
> ###############################################################################
>
> if [ "$NAT" == "1" ]; then
> # Chargement des modules pour l'IP masquerading
> modprobe iptable_nat
> modprobe ip_nat_ftp
> modprobe ip_nat_irc
>
> echo "+ Autorise l'IP masquerading de $LAN_NETWORK ->
> $WAN_NETWORK" iptables -t filter -A FORWARD -i $LAN_INTERFACE -o
> $WAN_INTERFACE -s $LAN_NETWORK -d $WAN_NETWORK -p all -m state
> --state ! INVALID -j ACCEPT

Si on veut être puriste, "! INVALID" n'est pas approprié ici. En
effet cela équivaut à NEW,RELATED,ESTABLISHED,UNTRACKED. Or les
paquets dans l'état UNTRACKED, comme ceux dans l'état INVALID, sont
ignorés par les chaînes de la table 'nat'. Par conséquent un tel
paquet serait retransmis sur l'interface WAN avec son adresse
source privée originale, ce qui n'est pas souhaitable. Certes en
l'absence de règles NOTRACK, aucun paquet ne peut se retrouver dans
l'état UNTRACKED.

Donc il faudrait remplacer !INVALID par NEW,RELATED,ESTABLISHED ?

> iptables -t filter -A FORWARD -i $WAN_INTERFACE -o
> $LAN_INTERFACE -s $WAN_NETWORK -d $LAN_NETWORK -p all -m state
> --state ESTABLISHED,RELATED -j ACCEPT
>
> iptables -t nat -A POSTROUTING -o
> $WAN_INTERFACE -s $LAN_NETWORK -d $WAN_NETWORK -p all -j
> MASQUERADE
>
> echo 1 > /proc/sys/net/ipv4/ip_forward
>
> else
> echo "+ L'IP masquerading N'est PAS autorisé"
> echo 0 > /proc/sys/net/ipv4/ip_forward
> fi

Je crois qu'ici il y a un bug : si l'ip_forward avait était activé
pour le port forwarding ($PF=1), $NAT=0 le désactive ! Ne serait-il
pas plus simple de l'activer à un seul endroit si ($NAT=1 ou
$PF=1) ?

Oui!

[...]
> ###############################################################################
> # Règles pour MSN
> ###############################################################################

Ces règles sont pour un client MSN Messenger ou un serveur hébergé
sur la machine ?

Pour un client. Et j'ai mis un peu au pif!

> if [ "$MSN" == "1" ]; then
> echo "+ Règles pour MSN"
> iptables -A INPUT -i $WAN_INTERFACE -d $WAN_IP -p tcp --dport
> $MSN_TCP_PORT -m state --state ! INVALID -j ACCEPT

Cette règle est inutile pour un client MSN Messenger car il émet
une connexion sortante vers le port destination 1863.

> iptables -A OUTPUT -o $WAN_INTERFACE -d $WAN_IP -p tcp --sport
> $MSN_TCP_PORT -m state --state RELATED,ESTABLISHED -j ACCEPT

Je soupçonne un oubli de modification de -d en -s après un

Oui c'est bien possible!

copier/coller. Même sans cette erreur, cette règle est redondante
car une règle précédente autorise déjà tout le trafic sortant non
INVALID.

C'est vrai! Donc toutes mes règles OUTPUT pour jabber, xmule, msn, mp9 sont inutiles, c'est ça?

D'autre part, un paquet de réponse TCP ou UDP (--sport) ne
peut pas avoir l'état RELATED. Seul le premier paquet d'une
connexion liée peut avoir cet état.

RELATED c'est une nouvelle connexion en relation avec une existante, c'est ça?
On ne peut pas avoir de RELATED en sortie?

Ces remarques sont aussi valables pour les autres règles OUTPUT et
pour les autres applications. J'ai pris le cas de MSN Messenger
parce que je le connais plus que les autres.

> iptables -A INPUT -i $WAN_INTERFACE -d $WAN_IP -p udp --dport
> $MSN_UDP_PORT -m state --state ! INVALID -j ACCEPT
> iptables -A OUTPUT -o $WAN_INTERFACE -d $WAN_IP -p udp --sport
> $MSN_UDP_PORT -m state --state RELATED,ESTABLISHED -j ACCEPT

Je ne crois pas que le port 1863 soit utilisé en UDP.

Ok je supprime.

> iptables -A INPUT -i $WAN_INTERFACE -d $WAN_IP -p tcp --dport
> $MSN_TRANSFERT_TCP_PORT -m state --state ! INVALID -j
> ACCEPT iptables -A OUTPUT -o $WAN_INTERFACE -d $WAN_IP -p tcp
> --sport $MSN_TRANSFERT_TCP_PORT -m state --state
> RELATED,ESTABLISHED -j ACCEPT iptables -A INPUT -i
> $WAN_INTERFACE -d $WAN_IP -p udp --dport $MSN_TRANSFERT_UDP_PORT
> -m state --state ! INVALID -j ACCEPT iptables -A OUTPUT
> -o $WAN_INTERFACE -d $WAN_IP -p udp --sport
> $MSN_TRANSFERT_UDP_PORT -m state --state RELATED,ESTABLISHED -j
> ACCEPT

Je ne crois pas que le transfert de fichier utilise UDP.

Ok je supprime!

> iptables -A INPUT -i $WAN_INTERFACE -d $WAN_IP -p tcp --dport
> $MSN_VOIX_TCP_PORT -m state --state ! INVALID -j ACCEPT
> iptables -A OUTPUT -o $WAN_INTERFACE -d $WAN_IP -p tcp --sport
> $MSN_VOIX_TCP_PORT -m state --state RELATED,ESTABLISHED -j ACCEPT
> iptables -A INPUT -i $WAN_INTERFACE -d $WAN_IP -p udp --dport
> $MSN_VOIX_UDP_PORT -m state --state ! INVALID -j ACCEPT
> iptables -A OUTPUT -o $WAN_INTERFACE -d $WAN_IP -p udp --sport
> $MSN_VOIX_UDP_PORT -m state --state RELATED,ESTABLISHED -j ACCEPT
> fi

Je voudrais faire une remarque générale au sujet des nombreuses
règles acceptant des paquets dans l'état RELATED ou ESTABLISHED. Si
le suivi de connexion a classé un paquet dans un de ces états,
c'est que le trafic précédent auquel il est lié a déjà été vu et
accepté (à l'exception des paquets RST ou ICMP émis localement en
réponse à un paquet rejeté). Par conséquent il n'est pas utile de
recréer ces règles pour chaque interface, application, protocole,
port... On peut se contenter d'une unique règle acceptant tous les
paquets dans l'état RELATED ou ESTABLISHED en début de chaîne (pour
l'efficacité, l'immense majorité des paquets étant dans l'état
ESTABLISHED) suivie de règles traitant les paquets dans l'état NEW
au cas par cas. Ça allège et simplifie sensiblement le jeu de
règles sans sacrifier à la sécurité. Beaucoup de jeux de règles
sont construits ainsi.

Bon là je ne suis pas sur d'avoir compris:
on a vu que mes règles OUTPUT étaient superflues car redondantes avec cette règle (si j'ai bien compris):
iptables -t filter -A INPUT -i $WAN_INTERFACE -s $WAN_NETWORK -d $WAN_IP -p all -m state --state RELATED,ESTABLISHED -j ACCEPT
Donc je vire tous mes OUTPUT avec RELATED,ESTABLISHED
Les paquets NEW je ne les traite pas car je n'ai pas de serveurs sur machine, et si j'en avais je n'aurais à les traiter qu'en INPUT sur les ports des serveurs. C'est ça?

[...]
> ###############################################################################
> # Règles pour le log
> ###############################################################################

Il n'y a rien de prévu pour le log des paquets dans FORWARD ?

Euh, je ne sais pas...
Tu mettrais quoi?

Bon, j'ai mais 1 heure 30 à lire et essayer de comprendre ta réponse!
J'espère avoir compris quelques trucs...

En tout cas, merci!

Gaëtan


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gaëtan PERRIER wrote:

Tout d'abord merci pour l'analyse!
Je vois que j'ai encore à apprendre (mais bon je m'y attendais!)
Réponses insérées:

Ça commence mal. Un jeu de règles sans chaînes utilisateur ne peut
pas être un bon jeu de règles. ;-)

Bon, je me pencherai sur la question des chaînes utilisateurs. Pour l'instant je ne sais pas ce que c'est...

# Creer les chaines utilisateurs lan_inputs et wan_inputs
iptables -N lan_inputs
iptables -N wan_inputs

# Rediriger le flux d'entree dans les chaines utilisateurs en fonction
de leur provenance et dropper le reste.
iptables -A INPUT -i $lan_iface -j lan_inputs
iptables -A INPUT -i $wan_iface -j wan_inputs
iptables -A INPUT DROP

# Effectuer le traitement du flux en provenance de lan
iptables -A lan_inputs ...

# Effectuer le traitement du flux en provenence de wan
iptables -A wan_inputs ...

C'est un exemple d'utilisation, pour montrer le principe. Il n'a rien de
fonctionnel.

# Paramètrage de la connexion Internet (WAN = Wild Area Network >>> # Réseau Large)
WAN_INTERFACE­sl ; # Interface réseau externe
(Internet) if [ -z "$@" ]; then
WAN_IP=`/sbin/ifconfig $WAN_INTERFACE | grep "inet adr" |
sed "s/^[: a-z]*([.0-9]*).*/1/g"` ; # Récupère l'adresse
réseau externe (Internet) elif [ "$@" == "boot" ]; then WAN_IP >>> $new_ip_address fi

Où la variable $new_ip_address est-elle définie ? Que
contient-elle ?

ça vient du client dhcp. Ce script est appelé à chaque attribution d'une adresse ip sur mon interface réseaux allant vers internet.

Tu la considere comme variable d'environnement, alors ? Si c'est le cas
moi je la mettrais en majuscule.

[...]

###############################################################################
# Règles de conexion au reseau local

"connexion".

# Tout est autorisé
###############################################################################

echo "+ Règles du réseau local ($LAN_INTERFACE - $LAN_IP -
$LAN_NETWORK)"
# Connexions firewall <-> réseau
iptables -t filter -A OUTPUT -o $LAN_INTERFACE -s $LAN_IP -d
$LAN_NETWORK -p all -j ACCEPT iptables -t filter -A INPUT -i
$LAN_INTERFACE -s $LAN_NETWORK -d $LAN_IP -p all -j ACCEPT

Ces règles oublient de prendre en compte les paquets émis (resp.
reçus) sur $LAN_INTERFACE avec l'adresse source (resp. destination)
$WAN_IP, qui sont pourtant parfaitement légitimes. Ne pas oublier
qu'une adresse IP appartient à une machine au moins autant qu'à une
interface.

Je n'ai pas bien compris comment ça peu arriver?

Je ne suis pas certain de ce que j'avance mais, a mon avis, c'est la
table de routage qui se charge de verifier la concordance entre ip et
interface comme tu l'entends, et comme je l'entendais avant :p!

echo "+ Règles pour Internet ($WAN_INTERFACE - $WAN_IP -
$WAN_NETWORK)" iptables -t filter -A OUTPUT -o $WAN_INTERFACE -s
$WAN_IP -d $WAN_NETWORK -p all -m state --state !
INVALID -j ACCEPT iptables -t filter -A INPUT -i
$WAN_INTERFACE -s $WAN_NETWORK -d $WAN_IP -p tcp --tcp-flags !
ALL SYN -m state --state NEW,RELATED -j DROP #06/05/2006 iptables
-t filter -A INPUT -i $WAN_INTERFACE -s $WAN_NETWORK -d $WAN_IP
-p all -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -t
filter -A INPUT -i $WAN_INTERFACE -s $WAN_NETWORK -d $WAN_IP -p
tcp --destination-port auth -j REJECT --reject-with tcp-reset
#06/05/2006

La dernière règle ne serait pas nécessaire si toutes les connexions
indésirables étaient traitées par REJECT au lieu de DROP.

Peux-tu m'expliquer pourquoi?
Initialement je n'avais pas les lignes finissant par #06/05/2006, sont-elles nécessaires?

J'ai jamais procede de cette facon donc je ne sais pas trop.

echo 1 > /proc/sys/net/ipv4/ip_forward

else
echo "+ Le port forwarding N'est PAS autorisé"
if [ "$NAT" == "0" ]; then
echo 0 > /proc/sys/net/ipv4/ip_forward
fi
fi

Le test de la valeur de $NAT ne sert à rien puisque de toute façon
ip_forward est déjà à 0. Voir mon commentaire sur l'IP masquerading.

Oui ce n'est pas faux! Mais bon le port forwarding n'est pas utilisé, donc pas grave. :-)

Le mieux serait donc de les supprimer, a moins que tu utilises le script
sur une autre machine en ayant l'utilite.

echo "+ Autorise l'IP masquerading de $LAN_NETWORK ->
$WAN_NETWORK" iptables -t filter -A FORWARD -i $LAN_INTERFACE -o
$WAN_INTERFACE -s $LAN_NETWORK -d $WAN_NETWORK -p all -m state
--state ! INVALID -j ACCEPT

Si on veut être puriste, "! INVALID" n'est pas approprié ici. En
effet cela équivaut à NEW,RELATED,ESTABLISHED,UNTRACKED. Or les
paquets dans l'état UNTRACKED, comme ceux dans l'état INVALID, sont
ignorés par les chaînes de la table 'nat'. Par conséquent un tel
paquet serait retransmis sur l'interface WAN avec son adresse
source privée originale, ce qui n'est pas souhaitable. Certes en
l'absence de règles NOTRACK, aucun paquet ne peut se retrouver dans
l'état UNTRACKED.

Donc il faudrait remplacer !INVALID par NEW,RELATED,ESTABLISHED ?

Oui.

>> [...]

###############################################################################
# Règles pour MSN
###############################################################################

Ces règles sont pour un client MSN Messenger ou un serveur hébergé
sur la machine ?

Pour un client. Et j'ai mis un peu au pif!

if [ "$MSN" == "1" ]; then
echo "+ Règles pour MSN"
iptables -A INPUT -i $WAN_INTERFACE -d $WAN_IP -p tcp --dport
$MSN_TCP_PORT -m state --state ! INVALID -j ACCEPT

Cette règle est inutile pour un client MSN Messenger car il émet
une connexion sortante vers le port destination 1863.

iptables -A OUTPUT -o $WAN_INTERFACE -d $WAN_IP -p tcp --sport
$MSN_TCP_PORT -m state --state RELATED,ESTABLISHED -j ACCEPT

Je soupçonne un oubli de modification de -d en -s après un

Oui c'est bien possible!

copier/coller. Même sans cette erreur, cette règle est redondante
car une règle précédente autorise déjà tout le trafic sortant non
INVALID.

C'est vrai! Donc toutes mes règles OUTPUT pour jabber, xmule, msn, mp9 sont inutiles, c'est ça?

Je pense que le plus simple, c'est de ne pas s'occuper des ports de
destination/source pour les etats RELATED et ESTABLISHED (tu peux par
contre t'assurer que tu attaques des ports > 1024 pour RELATED). On cree
une ou plusieurs regles gerant les connexions de types RELATED et
ESTABLISHED en fonction du type de protocol, et c'est plus simple et
tout aussi efficace.

RELATED c'est une nouvelle connexion en relation avec une existante, c'est ça?
On ne peut pas avoir de RELATED en sortie?

C'est en anglais, mais je pense que c'est plus clair que ce que je
pourrais dire :

http://iptables-tutorial.frozentux.net/iptables-tutorial.html#USERLANDSTATES

Ces remarques sont aussi valables pour les autres règles OUTPUT et
pour les autres applications. J'ai pris le cas de MSN Messenger
parce que je le connais plus que les autres.

iptables -A INPUT -i $WAN_INTERFACE -d $WAN_IP -p udp --dport
$MSN_UDP_PORT -m state --state ! INVALID -j ACCEPT
iptables -A OUTPUT -o $WAN_INTERFACE -d $WAN_IP -p udp --sport
$MSN_UDP_PORT -m state --state RELATED,ESTABLISHED -j ACCEPT

Je ne crois pas que le port 1863 soit utilisé en UDP.

Ok je supprime.

iptables -A INPUT -i $WAN_INTERFACE -d $WAN_IP -p tcp --dport
$MSN_TRANSFERT_TCP_PORT -m state --state ! INVALID -j
ACCEPT iptables -A OUTPUT -o $WAN_INTERFACE -d $WAN_IP -p tcp
--sport $MSN_TRANSFERT_TCP_PORT -m state --state
RELATED,ESTABLISHED -j ACCEPT iptables -A INPUT -i
$WAN_INTERFACE -d $WAN_IP -p udp --dport $MSN_TRANSFERT_UDP_PORT
-m state --state ! INVALID -j ACCEPT iptables -A OUTPUT
-o $WAN_INTERFACE -d $WAN_IP -p udp --sport
$MSN_TRANSFERT_UDP_PORT -m state --state RELATED,ESTABLISHED -j
ACCEPT

Je ne crois pas que le transfert de fichier utilise UDP.

Ok je supprime!

Tu peux toujours utiliser wireshark ou tcpdump pour t'en assurer.
De toute facon, si tu les supprimes, tu verras tout de suite le resultat.

Je voudrais faire une remarque générale au sujet des nombreuses
règles acceptant des paquets dans l'état RELATED ou ESTABLISHED. Si
le suivi de connexion a classé un paquet dans un de ces états,
c'est que le trafic précédent auquel il est lié a déjà été vu et
accepté (à l'exception des paquets RST ou ICMP émis localement en
réponse à un paquet rejeté). Par conséquent il n'est pas utile de
recréer ces règles pour chaque interface, application, protocole,
port... On peut se contenter d'une unique règle acceptant tous les
paquets dans l'état RELATED ou ESTABLISHED en début de chaîne (pour
l'efficacité, l'immense majorité des paquets étant dans l'état
ESTABLISHED) suivie de règles traitant les paquets dans l'état NEW
au cas par cas. Ça allège et simplifie sensiblement le jeu de
règles sans sacrifier à la sécurité. Beaucoup de jeux de règles
sont construits ainsi.

Bon là je ne suis pas sur d'avoir compris:
on a vu que mes règles OUTPUT étaient superflues car redondantes avec cette règle (si j'ai bien compris):
iptables -t filter -A INPUT -i $WAN_INTERFACE -s $WAN_NETWORK -d $WAN_IP -p all -m state --state RELATED,ESTABLISHED -j ACCEPT
Donc je vire tous mes OUTPUT avec RELATED,ESTABLISHED
Les paquets NEW je ne les traite pas car je n'ai pas de serveurs sur machine, et si j'en avais je n'aurais à les traiter qu'en INPUT sur les ports des serveurs. C'est ça?

En gros, tu pourrais ecrire :

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

apres avoir mis en place la politique par defaut. Du coup, tu n'aurais
plus qu'a travailler sur les etats de connexion de type NEW pour les
chaines INPUT et OUTPUT, car les types UNTRACKED et INVALID seront
droppes (a cause de la politique par defaut que tu emploies).


- --
Franck Joncourt
http://www.debian.org
http://smhteam.info/wiki/
GPG server : pgpkeys.mit.edu
Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFxGpvxJBTTnXAif4RAiDoAJ9f4Yeq+xZBlguN/0yGCtnloqa8HQCfd3c7
2ACGjSI7LWx3dhSJHdPlDn4 -pH
-----END PGP SIGNATURE-----




___________________________________________________________
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
http://uk.docs.yahoo.com/nowyoucan.html


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Gaëtan PERRIER a écrit :

Ça commence mal. Un jeu de règles sans chaînes utilisateur ne peut
pas être un bon jeu de règles. ;-)

Bon, je me pencherai sur la question des chaînes utilisateurs. Pour
l'instant je ne sais pas ce que c'est...

Voir la documentation de Netfilter/iptables. Comme son nom l'indique,
une chaîne utilisateur est une chaîne créée par l'utilisateur avec
iptables -N. On peut on peut y créer des règles avec iptables -A et on
peut l'appeler à partir d'une règle comme une cible avec l'option -j.
C'est une sorte de sous-programme pour iptables. Une chaîne utilisateur
peut être appelée depuis plusieurs endroits, y compris plusieurs chaînes
de base. Elle permet notamment de "factoriser" des critères de
correspondance communs à plusieurs règles (ex: regrouper toutes les
règles relatives à un interface d'entrée ou un état) ou de faire les
mêmes tests à plusieurs endroits sans dupliquer les règles (ex: même
vérification d'adresse/port dans INPUT et FORWARD). Pour info, mon jeu
de règles contient une cinquantaine de chaînes utilisateur.

Où la variable $new_ip_address est-elle définie ? Que
contient-elle ?

ça vient du client dhcp. Ce script est appelé à chaque attribution
d'une adresse ip sur mon interface réseaux allant vers internet.

Justement, je voulais en parler dans ma réponse précédente. Il n'est pas
nécessaire de réinitialiser toutes les règles. Il suffirait d'effacer et
recréer uniquement les règles liées à l'adresse susceptible de changer.
Et pour limiter le nombre de règles impliquées, les chaînes utilisateur
sont d'une grande aide. C'est ce que je fais pour mes interfaces PPP.

###############################################################################
# Règles de conexion au reseau local
# Tout est autorisé
###############################################################################

echo "+ Règles du réseau local ($LAN_INTERFACE - $LAN_IP -
$LAN_NETWORK)"
# Connexions firewall <-> réseau
iptables -t filter -A OUTPUT -o $LAN_INTERFACE -s $LAN_IP -d
$LAN_NETWORK -p all -j ACCEPT iptables -t filter -A INPUT -i
$LAN_INTERFACE -s $LAN_NETWORK -d $LAN_IP -p all -j ACCEPT

Ces règles oublient de prendre en compte les paquets émis (resp.
reçus) sur $LAN_INTERFACE avec l'adresse source (resp. destination)
$WAN_IP, qui sont pourtant parfaitement légitimes.

Je n'ai pas bien compris comment ça peu arriver?

Si tu veux établir une communication (par exemple un simple ping) vers
l'adresse WAN de la passerelle depuis un poste du LAN. C'est
parfaitement légal, et pourtant tes règles la bloqueraient, ainsi que la
réponse. Un point souvent mal compris est qu'une adresse IP ne doit pas
être considérée comme identifiant l'interface qui la porte mais la
machine tout entière. Opérationnellement, il n'y a pas de lien entre les
interfaces et les adresses locales et on peut utiliser n'importe quelle
adresse locale avec n'importe quelle interface. Ce n'est que dans
certains cas particulier qu'il peut être souhaitable d'interdire les
communications avec une adresse donnée sur une interface particulière ;
par exemple interdire l'adresse privée sur l'interface WAN parce qu'une
adresse privée ne devrait jamais apparaître sur l'internet public.

echo "+ Règles pour Internet ($WAN_INTERFACE - $WAN_IP - $WAN_NETWORK)"
iptables -t filter -A OUTPUT -o $WAN_INTERFACE -s $WAN_IP -d $WAN_NETWORK -p all -m state --state ! INVALID -j ACCEPT
iptables -t filter -A INPUT -i $WAN_INTERFACE -s $WAN_NETWORK -d $WAN_IP -p tcp --tcp-flags ! ALL SYN -m state --state NEW,RELATED -j DROP #06/05/2006
iptables -t filter -A INPUT -i $WAN_INTERFACE -s $WAN_NETWORK -d $WAN_IP -p all -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t filter -A INPUT -i $WAN_INTERFACE -s $WAN_NETWORK -d $WAN_IP -p tcp --destination-port auth -j REJECT --reject-with tcp-reset #06/05/2006

La dernière règle ne serait pas nécessaire si toutes les connexions
indésirables étaient traitées par REJECT au lieu de DROP.

Peux-tu m'expliquer pourquoi?
Initialement je n'avais pas les lignes finissant par #06/05/2006, sont-elles nécessaires?

La première, qui bloque les paquets TCP dans l'état NEW ou RELATED
autres que SYN n'est pas franchement indispensable puisque soit c'est le
suivi de connexion TCP lui-même qui va classer le paquet INVALID soit
c'est la pile TCP/IP qui va le rejeter.

La seconde, qui répond "fermé" aux requêtes IDENT notamment des serveurs
IRC ou SMTP pour éviter un délai d'attente ou carrément de se faire
jeter par le serveur à cause de l'absence de réponse n'est utile que
parce que ton traitement par défaut des requêtes entrantes est DROP. Si
le traitement pour toutes les requêtes indésirables était REJECT, tu
n'aurais pas besoin d'une exception pour les requêtes IDENT.

echo "+ Autorise l'IP masquerading de $LAN_NETWORK -> $WAN_NETWORK"
iptables -t filter -A FORWARD -i $LAN_INTERFACE -o $WAN_INTERFACE -s $LAN_NETWORK -d $WAN_NETWORK -p all -m state --state ! INVALID -j ACCEPT

Si on veut être puriste, "! INVALID" n'est pas approprié ici. En
effet cela équivaut à NEW,RELATED,ESTABLISHED,UNTRACKED. Or les
paquets dans l'état UNTRACKED, comme ceux dans l'état INVALID, sont
ignorés par les chaînes de la table 'nat'. Par conséquent un tel
paquet serait retransmis sur l'interface WAN avec son adresse
source privée originale, ce qui n'est pas souhaitable. Certes en
l'absence de règles NOTRACK, aucun paquet ne peut se retrouver dans
l'état UNTRACKED.

Donc il faudrait remplacer !INVALID par NEW,RELATED,ESTABLISHED ?

Oui.

[...]

C'est vrai! Donc toutes mes règles OUTPUT pour jabber, xmule, msn, mp9
sont inutiles, c'est ça?

Oui. Et pareil pour les règles INPUT avec ESTABLISHED,RELATED.

D'autre part, un paquet de réponse TCP ou UDP (--sport) ne
peut pas avoir l'état RELATED. Seul le premier paquet d'une
connexion liée peut avoir cet état.

RELATED c'est une nouvelle connexion en relation avec une existante, c'est ça?

En gros, oui. Ici "connexion" et "existante" sont à prendre au sens
large car cela peut être un message d'erreur ICMP - qui n'est pas
vraiment une connexion - émis pour rejeter une requête dont la
"connexion" aura été éphémère.

Pour compléter la réponse de Franck, il existe une version française du
tutorial iptables d'O. Andreasson, dont la page décrivant les états de
connexion se trouve ici :
http://iptables-tutorial.frozentux.net/fr/x1329.html

On ne peut pas avoir de RELATED en sortie?

Si, bien sûr. L'état ne dépend pas du sens de transmission par rapport à
la machine mais par rapport à la connexion elle-même. On définit la
direction "originale" comme la direction du premier paquet qui a créé la
connexion et la direction "retour" comme la direction opposée, celles
des paquets de réponse. Dans une connexion TCP ou UDP liée à une
connexion existante (ex: connexion de données FTP ou TFTP) l'état
RELATED remplace l'état NEW et donc ne peut exister que dans la
direction originale de la connexion liée.

De toute évidence, la règle qui a motivé ma remarque était prévue pour
le trafic dans le sens retour (généralement "--sport xx" = réponse à une
connexion sur le port xx), ce qui est incompatible avec l'état RELATED.

[...]

Je voudrais faire une remarque générale au sujet des nombreuses
règles acceptant des paquets dans l'état RELATED ou ESTABLISHED. Si
le suivi de connexion a classé un paquet dans un de ces états,
c'est que le trafic précédent auquel il est lié a déjà été vu et
accepté (à l'exception des paquets RST ou ICMP émis localement en
réponse à un paquet rejeté). Par conséquent il n'est pas utile de
recréer ces règles pour chaque interface, application, protocole,
port... On peut se contenter d'une unique règle acceptant tous les
paquets dans l'état RELATED ou ESTABLISHED en début de chaîne (pour
l'efficacité, l'immense majorité des paquets étant dans l'état
ESTABLISHED) suivie de règles traitant les paquets dans l'état NEW
au cas par cas. Ça allège et simplifie sensiblement le jeu de
règles sans sacrifier à la sécurité. Beaucoup de jeux de règles
sont construits ainsi.

Bon là je ne suis pas sur d'avoir compris:
on a vu que mes règles OUTPUT étaient superflues car redondantes avec
cette règle (si j'ai bien compris):
iptables -t filter -A INPUT -i $WAN_INTERFACE -s $WAN_NETWORK -d $WAN_IP -p all -m state --state RELATED,ESTABLISHED -j ACCEPT

Non, avec la règle OUTPUT juste à côté. :-)

Donc je vire tous mes OUTPUT avec RELATED,ESTABLISHED

Oui.

Les paquets NEW je ne les traite pas car je n'ai pas de serveurs sur
machine, et si j'en avais je n'aurais à les traiter qu'en INPUT sur
les ports des serveurs. C'est ça?

Tu peux avoir des serveurs sans le savoir. Ainsi les transferts de
fichiers par MSN dans un certain sens (je ne sais plus si c'est en
émission ou réception) s'effectuent normalement en pair-à-pair et
impliquent que ton client MSN devient serveur sur un des ports TCP de la
plage $MSN_TRANSFERT_TCP_PORT (sinon ça peut passer par le serveur MSN
mais ça va moins vite). Si tu as un module de suivi de connexion pour le
protocole MSN, il identifiera le premier paquet comme RELATED et sera
pris en charge par la règle générale. Mais dans le cas contraire, le
premier paquet sera classé NEW et il faudra l'accepter explicitement
avec une règle :

iptables -A INPUT -i $WAN_INTERFACE -d $WAN_IP -p tcp
--dport $MSN_TRANSFERT_TCP_PORT -m state --state NEW -j ACCEPT

Même chose pour les communications vocales, j'imagine.

[...]

###############################################################################
# Règles pour le log
###############################################################################

Il n'y a rien de prévu pour le log des paquets dans FORWARD ?

Euh, je ne sais pas...
Tu mettrais quoi?

La même chose qu'en entrée et/ou sortie mais dans la chaîne FORWARD.


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Le Sat, 03 Feb 2007 11:56:47 +0100
franck <joncourt_franck@yahoo.co.uk> a écrit:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gaëtan PERRIER wrote:
> Tout d'abord merci pour l'analyse!
> Je vois que j'ai encore à apprendre (mais bon je m'y attendais!)
> Réponses insérées:
>

>> Ça commence mal. Un jeu de règles sans chaînes utilisateur ne
>> peut pas être un bon jeu de règles. ;-)
>
> Bon, je me pencherai sur la question des chaînes utilisateurs.
> Pour l'instant je ne sais pas ce que c'est...
>

# Creer les chaines utilisateurs lan_inputs et wan_inputs
iptables -N lan_inputs
iptables -N wan_inputs

# Rediriger le flux d'entree dans les chaines utilisateurs en
# fonction
de leur provenance et dropper le reste.
iptables -A INPUT -i $lan_iface -j lan_inputs
iptables -A INPUT -i $wan_iface -j wan_inputs
iptables -A INPUT DROP

# Effectuer le traitement du flux en provenance de lan
iptables -A lan_inputs ...

# Effectuer le traitement du flux en provenence de wan
iptables -A wan_inputs ...

C'est un exemple d'utilisation, pour montrer le principe. Il n'a
rien de fonctionnel.

Merci, va falloir que je regarde de plus prêt tout ça. Pour l'instant je manque de temps.

>>> # Paramètrage de la connexion Internet (WAN = Wild Area Network
>>> # = Réseau Large)
>>> WAN_INTERFACE­sl ; # Interface réseau externe
>>> (Internet) if [ -z "$@" ]; then
>>> WAN_IP=`/sbin/ifconfig $WAN_INTERFACE | grep "inet adr"
>>> | sed "s/^[: a-z]*([.0-9]*).*/1/g"` ; # Récupère l'adresse
>>> réseau externe (Internet) elif [ "$@" == "boot" ]; then WAN_IP > >>> $new_ip_address fi
>> Où la variable $new_ip_address est-elle définie ? Que
>> contient-elle ?
>
> ça vient du client dhcp. Ce script est appelé à chaque
> attribution d'une adresse ip sur mon interface réseaux allant
> vers internet.
>

Tu la considere comme variable d'environnement, alors ? Si c'est le
cas moi je la mettrais en majuscule.

Je ne peux pas car ce n'est pas moi qui la définit c'est une variable de dhcp client...

>> [...]
>>> ###############################################################################
>>> # Règles de conexion au reseau local
>> "connexion".
>>
>>> # Tout est autorisé
>>> ###############################################################################
>>>
>>> echo "+ Règles du réseau local ($LAN_INTERFACE - $LAN_IP -
>>> $LAN_NETWORK)"
>>> # Connexions firewall <-> réseau
>>> iptables -t filter -A OUTPUT -o $LAN_INTERFACE -s $LAN_IP -d
>>> $LAN_NETWORK -p all -j ACCEPT iptables -t filter -A INPUT -i
>>> $LAN_INTERFACE -s $LAN_NETWORK -d $LAN_IP -p all -j ACCEPT
>> Ces règles oublient de prendre en compte les paquets émis (resp.
>> reçus) sur $LAN_INTERFACE avec l'adresse source (resp.
>> destination) $WAN_IP, qui sont pourtant parfaitement légitimes.
>> Ne pas oublier qu'une adresse IP appartient à une machine au
>> moins autant qu'à une interface.
>
> Je n'ai pas bien compris comment ça peu arriver?

Je ne suis pas certain de ce que j'avance mais, a mon avis, c'est la
table de routage qui se charge de verifier la concordance entre ip
et interface comme tu l'entends, et comme je l'entendais avant :p!

>>> echo "+ Règles pour Internet ($WAN_INTERFACE - $WAN_IP -
>>> $WAN_NETWORK)" iptables -t filter -A OUTPUT -o $WAN_INTERFACE -s
>>> $WAN_IP -d $WAN_NETWORK -p all -m state --state !
>>> INVALID -j ACCEPT iptables -t filter -A INPUT -i
>>> $WAN_INTERFACE -s $WAN_NETWORK -d $WAN_IP -p tcp --tcp-flags !
>>> ALL SYN -m state --state NEW,RELATED -j DROP #06/05/2006
>>> iptables -t filter -A INPUT -i $WAN_INTERFACE -s $WAN_NETWORK
>>> -d $WAN_IP -p all -m state --state RELATED,ESTABLISHED -j
>>> ACCEPT iptables -t filter -A INPUT -i $WAN_INTERFACE -s
>>> $WAN_NETWORK -d $WAN_IP -p tcp --destination-port auth -j
>>> REJECT --reject-with tcp-reset
>>> #06/05/2006
>> La dernière règle ne serait pas nécessaire si toutes les
>> connexions indésirables étaient traitées par REJECT au lieu de
>> DROP.
>
> Peux-tu m'expliquer pourquoi?
> Initialement je n'avais pas les lignes finissant par #06/05/2006,
> sont-elles nécessaires?
>

J'ai jamais procede de cette facon donc je ne sais pas trop.

>>> echo 1 > /proc/sys/net/ipv4/ip_forward
>>>
>>> else
>>> echo "+ Le port forwarding N'est PAS autorisé"
>>> if [ "$NAT" == "0" ]; then
>>> echo 0 > /proc/sys/net/ipv4/ip_forward
>>> fi
>>> fi
>> Le test de la valeur de $NAT ne sert à rien puisque de toute
>> façon ip_forward est déjà à 0. Voir mon commentaire sur l'IP
>> masquerading.
>
> Oui ce n'est pas faux! Mais bon le port forwarding n'est pas
> utilisé, donc pas grave. :-)

Le mieux serait donc de les supprimer, a moins que tu utilises le
script sur une autre machine en ayant l'utilite.

C'est fait j'ai supprimé.

>>> echo "+ Autorise l'IP masquerading de $LAN_NETWORK ->
>>> $WAN_NETWORK" iptables -t filter -A FORWARD -i $LAN_INTERFACE -o
>>> $WAN_INTERFACE -s $LAN_NETWORK -d $WAN_NETWORK -p all -m state
>>> --state ! INVALID -j ACCEPT
>> Si on veut être puriste, "! INVALID" n'est pas approprié ici. En
>> effet cela équivaut à NEW,RELATED,ESTABLISHED,UNTRACKED. Or les
>> paquets dans l'état UNTRACKED, comme ceux dans l'état INVALID,
>> sont ignorés par les chaînes de la table 'nat'. Par conséquent
>> un tel paquet serait retransmis sur l'interface WAN avec son
>> adresse source privée originale, ce qui n'est pas souhaitable.
>> Certes en l'absence de règles NOTRACK, aucun paquet ne peut se
>> retrouver dans l'état UNTRACKED.
>
> Donc il faudrait remplacer !INVALID par NEW,RELATED,ESTABLISHED ?

Oui.

>
>> [...]
>>> ###############################################################################
>>> # Règles pour MSN
>>> ###############################################################################
>> Ces règles sont pour un client MSN Messenger ou un serveur
>> hébergé sur la machine ?
>
> Pour un client. Et j'ai mis un peu au pif!
>
>>> if [ "$MSN" == "1" ]; then
>>> echo "+ Règles pour MSN"
>>> iptables -A INPUT -i $WAN_INTERFACE -d $WAN_IP -p tcp --dport
>>> $MSN_TCP_PORT -m state --state ! INVALID -j ACCEPT
>> Cette règle est inutile pour un client MSN Messenger car il émet
>> une connexion sortante vers le port destination 1863.
>>
>>> iptables -A OUTPUT -o $WAN_INTERFACE -d $WAN_IP -p tcp --sport
>>> $MSN_TCP_PORT -m state --state RELATED,ESTABLISHED -j ACCEPT
>> Je soupçonne un oubli de modification de -d en -s après un
>
> Oui c'est bien possible!
>
>> copier/coller. Même sans cette erreur, cette règle est redondante
>> car une règle précédente autorise déjà tout le trafic sortant non
>> INVALID.
>
> C'est vrai! Donc toutes mes règles OUTPUT pour jabber, xmule,
> msn, mp9 sont inutiles, c'est ça?

Je pense que le plus simple, c'est de ne pas s'occuper des ports de
destination/source pour les etats RELATED et ESTABLISHED (tu peux
par contre t'assurer que tu attaques des ports > 1024 pour
RELATED). On cree une ou plusieurs regles gerant les connexions de
types RELATED et ESTABLISHED en fonction du type de protocol, et
c'est plus simple et tout aussi efficace.

>
> RELATED c'est une nouvelle connexion en relation avec une
> existante, c'est ça? On ne peut pas avoir de RELATED en sortie?

C'est en anglais, mais je pense que c'est plus clair que ce que je
pourrais dire :

http://iptables-tutorial.frozentux.net/iptables-tutorial.html#USERLANDSTATES

Merci.

>> Je voudrais faire une remarque générale au sujet des nombreuses
>> règles acceptant des paquets dans l'état RELATED ou ESTABLISHED.
>> Si le suivi de connexion a classé un paquet dans un de ces états,
>> c'est que le trafic précédent auquel il est lié a déjà été vu et
>> accepté (à l'exception des paquets RST ou ICMP émis localement en
>> réponse à un paquet rejeté). Par conséquent il n'est pas utile de
>> recréer ces règles pour chaque interface, application, protocole,
>> port... On peut se contenter d'une unique règle acceptant tous
>> les paquets dans l'état RELATED ou ESTABLISHED en début de
>> chaîne (pour l'efficacité, l'immense majorité des paquets étant
>> dans l'état ESTABLISHED) suivie de règles traitant les paquets
>> dans l'état NEW au cas par cas. Ça allège et simplifie
>> sensiblement le jeu de règles sans sacrifier à la sécurité.
>> Beaucoup de jeux de règles sont construits ainsi.
>
> Bon là je ne suis pas sur d'avoir compris:
> on a vu que mes règles OUTPUT étaient superflues car redondantes
> avec cette règle (si j'ai bien compris): iptables -t filter -A
> INPUT -i $WAN_INTERFACE -s $WAN_NETWORK -d $WAN_IP -p all -m
> state --state RELATED,ESTABLISHED -j ACCEPT Donc je vire tous mes
> OUTPUT avec RELATED,ESTABLISHED Les paquets NEW je ne les traite
> pas car je n'ai pas de serveurs sur machine, et si j'en avais je
> n'aurais à les traiter qu'en INPUT sur les ports des serveurs.
> C'est ça?
>

En gros, tu pourrais ecrire :

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

apres avoir mis en place la politique par defaut. Du coup, tu
n'aurais plus qu'a travailler sur les etats de connexion de type
NEW pour les chaines INPUT et OUTPUT, car les types UNTRACKED et
INVALID seront droppes (a cause de la politique par defaut que tu
emploies).

Tu mettrais ça juste avant mes règles pour XMULE, MSN, etc. et tu virerais mes règles pour juste en mettre sur les NEW en INPUT (vu que les OUTPUT sont déjà autorisées par défaut)?

Gaëtan


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org