Re: [firewall] iptables, le script parfait?
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=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.
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
Reply to: