Re: [firewall] iptables, le script parfait?
-----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=adsl ; # 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=
=2dpH
-----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
Reply to: