-----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 -- 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
