Tout d’abord un rectificatif : j’ai été injuste, le vrai gruyère n’a pas de trous.
Pourquoi ignorer tous les ICMP echo requests (ping) ? C’est se priver d’un outil qui peut être bien utile pour diagnostiquer des problèmes.
[code]# Nous faisons de meme avec toutes les autres tables,
a savoir “nat” et “mangle”,[/code]
Je ne vois pas les commandes de réinitialisations de la table “mangle”.
[code]######################################################################
G E S T I O N M A C H I N E L O C A L E
######################################################################
[…]
iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 -j DNAT --to-destination 192.168.1.100:80[/code]
Que vient faire cette règle de redirection de port dans cette section ?
#on permet toutes les liaisons firewall-LAN
#iptables -A INPUT -i eth0 -m state --state ESTABLISHED -j ACCEPT
#iptables -A OUTPUT -o eth0 -m state --state NEW,ESTABLISHED -j ACCEPT
Je croyais que eth0 était l’interface internet ?
#On permet l'utilisation de VNC
iptables -A INPUT -i eth0 -p tcp --sport 5900 -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --dport 5900 -m state --state NEW,ESTABLISHED -j ACCEPT
Ces règles sont redondantes avec les précédentes.
Le commentaire devrait préciser qu’il s’agit de VNC sortant.
# Resolution DNS pour le firewall
iptables -A INPUT -i eth0 --protocol udp --source-port 53 -j ACCEPT
iptables -A OUTPUT -o eth0 --protocol udp --destination-port 53 -j ACCEPT
iptables -A INPUT -i eth0 --protocol tcp --source-port 53 -j ACCEPT
iptables -A OUTPUT -o eth0 --protocol tcp --destination-port 53 -j ACCEPT
Question pratique : que se passe-t-il si j’envoie un paquet TCP ou UDP vers n’importe quel port destination depuis le port source 53 ? Gagné, ces règles l’acceptent sans rechigner ainsi que la réponse que va gentiment faire ta machine. Pour l’empêcher, il faut utiliser le suivi de connexion comme dans les autres règles.
Ceci s’applique également aux règles relatives à la résolution DNS du LAN.
[code]# On permet toutes les connexions sur le LAN depuis le firewall
iptables -A INPUT -i eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o eth1 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
On permet toutes les connexions sur le firewall depuis le LAN
iptables -A INPUT -i eth1 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT[/code]
Il y a de la redondance, on peut obtenir le même résultat en deux règles.
# connexions Firewall-Internet (www)
iptables -A OUTPUT -p tcp --dport 80 -o eth0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 443 -o eth0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --sport 80 -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --sport 443 -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
L’état RELATED n’existe pas pour les protocoles “simples” (du point de vue des flux) comme HTTP, POP, IMAP, SMTP… Il n’existe que pour les messages d’erreur ICMP et les flux de données séparés de protocoles “complexes” comme FTP, TFTP, SIP, H.323…
On peut combiner les deux ports dans une seule règle avec la correspondance “-m multiport --{d,s}ports 80,443” au lieu de --{d,s}port.
Cette remarque s’applique aussi aux règles relatives aux connexions web LAN-internet.
# connexions LAN-Internet (ftp)
iptables -A FORWARD -p tcp --dport 21 -i eth1 -o eth0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p tcp --sport 21 -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p tcp --sport 20 -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p tcp --dport 20 -i eth1 -o eth0 -m state --state ESTABLISHED -j ACCEPT
L’état RELATED n’existe pas pour un paquet d’une connexion de commande FTP (port 21). Il n’existe que pour le premier paquet de la connexion de données, si le module de suivi de connexion FTP est chargé (ip_conntrack_ftp ou nf_conntrack_ftp).
Ces règles n’autorisent que les connexions de données en mode actif, pas celle en mode passif contrairement aux règles plus bas.
# Ouverture pour le ftp (actif)
[...]
iptables -A INPUT -i eth0 -p tcp --sport 1024:65535 --dport 1024:65535 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 1024:65535 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT
Contrairement à ce qu’indique le commentaire, ces règles acceptent aussi les connexions de données FTP en mode passif. Bonne gestion des états.
# Ouverture pour le serveur ssh
iptables -A OUTPUT -o eth0 -p tcp --sport 22 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT
Il manque la gestion des états. Sans cela ces règles permettent théoriquement d’établir des connexions TCP vers n’importe où à partir du port local 22 (certes pour cela il faudrait la complicité du démon SSH).
Autres remarques :
- Utiliser des variables avec des noms explicites dans les règles plutôt que les noms des interfaces améliore la lisibilité et la maintenabilité du script.
LAN=eth1
NET=eth0
iptables -A FORWARD -i $LAN -o $NET ...
-
Il serait préférable d’autoriser les messages d’erreur ICMP qui sont dans l’état RELATED, les bloquer peut causer des problèmes de connectivité.
-
Tu gères le suivi de connexion séparément pour chaque type de flux avec des règles spécifiques. Ce n’est pas nécessaire et alourdit inutilement le script. Le plus souvent on se contente d’une règle générique en début de chaîne acceptant les paquets ESTABLISHED et RELATED car un paquet ne peut être dans ces états que si le paquet NEW correspondant a été accepté. Ainsi les autres règles n’ont plus qu’à s’occuper des paquets NEW. Et en bonus ça s’occupe tout seul des messages d’erreur ICMP. Voici un petit exemple où j’en profite pour montrer comment on peut “factoriser” des critères de correspondances communs à plusieurs règles grâce à des chaînes utilisateur afin d’alléger les règles.
# suivi de connexion
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# chaîne utilisateur des connexions sortantes vers internet
iptables -N out_net
iptables -A OUTPUT -o $NET -m state --state NEW -j out_net
# requêtes DNS sortantes
iptables -A out_net -p udp --dport 53 -j ACCEPT
iptables -A out_net -p tcp --dport 53 -j ACCEPT
# chaîne utilisateur des connexions entrantes depuis internet
iptables -N in_net
iptables -A INPUT -i $NET -m state --state NEW -j in_net
# connexions SSH entrantes
iptables -A in_net -p tcp --dport 22 -j ACCEPT
# connexions de commande FTP entrantes (le suivi de connexion s'occupe du reste)
iptables -A in_net -p tcp --dport 21 -j ACCEPT
Tu peux éventuellement continuer à gérer l’état RELATED au cas par cas (types ICMP, connexions FTP en mode actif et passif…)
- Il ne manquerait pas du masquerading (NAT source) pour les connexions du LAN vers internet si le LAN est en adressage privé ? Ou bien le modem-routeur fait déjà le NAT et a une route de retour vers le bloc d’adresses du LAN ?
