Guide de configuration Netfilter-iptables
Certification de Scurit Premier Niveau de Netfilter-iptables
REFERENCE: OPPIDA/DOC/2009/AUA/534/1.4
N 200210510
OPPIDA/DOC/2009/AUA/534/1.4
Guide de configuration Netfilter-iptables - Version du 10 Juin 2009 Page 2/31 Ce document est la proprit de la socit OPPIDA et ne peut tre communiqu ou reproduit sans autorisation
ETAT DES VALIDATIONS Rdacteur Vrificateur Nom Etienne Grain Christophe BLAD
Fonction Consultant Resp. Technique CESTI Date du visa 12/02/2009 12/02/2009 Visa
SUIVI DE VERSION Version Date NOTES
1.0 08/01/2009 Cration du document 1.1 12/02/2009 Prise en compte des remarques de la DCSSI 1.3 11/05/2009 Corrections derreur 1.4 10/06/2009 Ajout des timers de connexion
OPPIDA/DOC/2009/AUA/534/1.4
Guide de configuration Netfilter-iptables - Version du 10 Juin 2009 Page 3/31 Ce document est la proprit de la socit OPPIDA et ne peut tre communiqu ou reproduit sans autorisation
SOMMAIRE ******
1. Prsentation............................................................................................................................ 4 1.1. Objet du document ......................................................................................................... 4 1.2. Pr-requis........................................................................................................................ 4 1.3. Architecture cible ........................................................................................................... 4
2. Fonctionnement de Netfilter-iptables................................................................................... 5 2.1. Fonctionnalits ............................................................................................................... 5 2.2. Traitement des paquets ................................................................................................... 5 2.3. Cibles et sauts................................................................................................................. 8 2.4. Oprations importantes................................................................................................... 9 2.5. Utilisation de chanes dfinies par les utilisateurs.......................................................... 11
3. Configuration ......................................................................................................................... 13 3.1. Principe de base.............................................................................................................. 13 3.2. Configuration des options du noyau............................................................................... 13 3.3. Chargement des modules................................................................................................ 13 3.4. Activation des mcanismes de protection du systme dexploitation............................ 14 3.5. Paramtrage fin des timers ............................................................................................. 15 3.6. Suivi des connexions ...................................................................................................... 16 3.7. Journalisation et scurisation du journal daudit ............................................................ 16
4. Exemples ................................................................................................................................. 18 4.1. Exemples utiles............................................................................................................... 18 4.2. Exemple de script complet ............................................................................................. 21
5. Annexe 1 : Suivi des modes de connexion............................................................................ 27 5.1. Prsentation .................................................................................................................... 27 5.2. Fonctionnement .............................................................................................................. 27
OPPIDA/DOC/2009/AUA/534/1.4
Guide de configuration Netfilter-iptables - Version du 10 Juin 2009 Page 4/31 Ce document est la proprit de la socit OPPIDA et ne peut tre communiqu ou reproduit sans autorisation
1. Prsentation 1.1. Objet du document
Ce document prsente un guide de configuration du pare-feu Netfilter-iptables, et plus spcifiquement comment paramtrer les fonctions de scurit suivantes :
Application de la politique de filtrage (filtrage non contextuel et filtrage contextuel) ; Journalisation/Audit des flux ; Scurit du journal daudit (directive LIMIT permettant de limiter la frquence de
journalisation) ; Rvocation des droits (permet de supprimer dynamiquement une rgle).
Ce document a pour vocation de servir de support pour lvaluation de scurit CSPN du logiciel libre Netfilter-iptables.
1.2. Pr-requis Les logiciels cibles sont :
Noyau Linux 32 bits version 2.6.27 tlcharg du site kernel.org ; Iptables tlcharg version 1.4.2 tlcharg du site netfilter.org.
1.3. Architecture cible Larchitecture cible est celle dune passerelle filtrante avec les fonctionnalits de suivi des connexions, NAT, LOG, etc. Elle est reprsente dans la figure ci-dessous.
Figure 1: Exemple de l'architecture Netfilter
OPPIDA/DOC/2009/AUA/534/1.4
Guide de configuration Netfilter-iptables - Version du 10 Juin 2009 Page 5/31 Ce document est la proprit de la socit OPPIDA et ne peut tre communiqu ou reproduit sans autorisation
2. Fonctionnement de Netfilter-iptables 2.1. Fonctionnalits
A lorigine, le plus populaire des pare-feux fonctionnant sur Linux tait ipchains, mais celui-ci possdait de nombreuses lacunes. Pour remdier cela, lquipe de Netfilter a dcid de crer un nouveau produit appel Netfilter, qui fournit un certain nombre damliorations, dont les suivantes :
Une meilleure intgration avec le noyau Linux, avec la capacit de chargement de modules Netfilter spcifiques, conue pour amliorer la rapidit et la fiabilit de traitement.
Linspection par tat. Cela signifie que le pare-feu garde la trace de chaque connexion qui le traverse et, dans certains cas voit le contenu des flux afin dessayer danticiper la prochaine action de certains protocoles. Cest un lment important dans le support du FTP en mode actif, et du DNS, ainsi que pour dautres services rseaux.
Le filtrage des paquets en se basant sur une adresse MAC et les valeurs de champs (flags) dans len-tte TCP. Ceci est utile dans la prvention des attaques utilisant des paquets malforms et en limitant laccs local partir de serveurs distants.
La journalisation systme, qui fournit une option pour ajuster le niveau de dtail des rapports.
Une meilleure traduction des adresses rseau (NAT). Un support lintgration transparent de serveurs mandataires Web, comme Squid. Une fonctionnalit de limitation des flux qui aide Netfilter bloquer quelques types
dattaques par dni de service (DoS). La diffrence entre Netfilter et iptables est la suivante :
Netfilter est un module, et fonctionne en mode Noyau. Cest lui qui intercepte et manipule les paquets IP avant et aprs le routage.
iptables est la commande qui permet de configurer Netfilter en espace Utilisateur.
2.2. Traitement des paquets Tous les paquets inspects par Netfilter passent travers des tables de traitement prdfinies (queues). Chacune de ces files dattente est ddie un type particulier dactivit et est contrl par une chane associe, qui a pour rle de transformer ou de filtrer le paquet. Il y a trois tables au total. La premire est la table mangle, qui permet deffectuer des modifications sur les paquets. La seconde table est la file dattente filter, qui est responsable du filtrage des paquets. Elle possde trois chaines prdfinies dans lesquelles on place les rgles de filtrage du pare-feu. Elles sont les suivantes :
Chane FORWARD (transfert) : Filtre les paquets destination dquipements rseau situs derrire le pare-feu. Ces paquets doivent donc traverser le pare-feu.
Chane INPUT (entre) : Filtre les paquets destins au pare-feu. Chane OUTPUT (sortie) : Filtre les paquets qui ont pour origine le pare-feu.
OPPIDA/DOC/2009/AUA/534/1.4
Guide de configuration Netfilter-iptables - Version du 10 Juin 2009 Page 6/31 Ce document est la proprit de la socit OPPIDA et ne peut tre communiqu ou reproduit sans autorisation
La troisime table est la file dattente nat, qui est responsable de la traduction dadresse rseau (NAT). Elle possde trois chanes prdfinies, qui sont :
Chane PREROUTING (pr-routage): Habituellement utilise pour faire de la traduction dadresse en destination (DNAT). Elle permet de traiter les paquets avant leur routage.
Chane POSTROUTING (post-routage): Traduit les paquets quand ladresse source doit tre change.
Le tableau ci-dessous rcapitule les diffrentes files dattente et chanes. File dattente
Fonction de la file dattente
Transformation de paquet dans la chane
Fonction de la chane
filter Filtrage de paquet FORWARD Filtre les paquets destins des serveurs accessibles par une autre carte rseau sur le pare-feu.
INPUT Filtre les paquets destins au pare-feu.
OUTPUT Filtre les paquets mis par le pare-feu.
nat Traduction dadresse rseau PREROUTING Habituellement utilise pour traduire les adresses avant le routage. La principale utilisation est le destination NAT (DNAT).
POSTROUTING Habituellement utilise pour traduire les adresses aprs le routage. La principale utilisation est le source NAT (SNAT).
OUTPUT Traduction dadresse rseau pour les paquets gnrs par le pare-feu.
mangle Modification des paquets PREROUTING
POSTROUTING
OUTPUT
INPUT
FORWARD
Modification du paquet IP.
Figure 2: Traitement des paquets par iptables
Il est ncessaire de spcifier la table et la chane pour chaque rgle dfinie. Il y a cependant une exception : la plupart des rgles sont relatives au filtrage ; ainsi, toute chane qui est dfinie sans table associe fera partie de la table filter. La table filter est donc la table par dfaut. Pour mieux comprendre, il suffit de se rfrer la figure ci-dessous. Dans cette figure, un paquet TCP venant dInternet arrive sur linterface rseau du pare-feu via le rseau A pour crer une connexion.
OPPIDA/DOC/2009/AUA/534/1.4
Guide de configuration Netfilter-iptables - Version du 10 Juin 2009 Page 7/31 Ce document est la proprit de la socit OPPIDA et ne peut tre communiqu ou reproduit sans autorisation
Rseau B
Table nat
Chane POSTROUTING
Table mangle
Chane POSTROUTING
Table filter
Chane OUTPUT
Table mangle
Chane PREROUTING
Table nat
Chane PREROUTING
Routage
Table mangle
Chane INPUT
Table mangle
Chane FORWARD
Table filter
Chane FORWARD
Table mangle
Chane POSTROUTING
Table nat
Chane POSTROUTING
Table nat
Chane OUTPUT
Table mangle
Chane OUTPUT
Routage
Traitement local de la
donne
Table filter
Chane INPUT
La donne est-elle
destination du pare-feu ?
Rseau A
Entre du paquet
Sortie du paquet
Rponse du
pare-feu
Oui Non
Figure 3: Diagramme de traitement des paquets dans iptables
Le paquet est dabord examin par les rgles de la chane PREROUTING de la table mangle. Il est ensuite inspect par les rgles de la chane PREROUTING de la table nat pour voir si ladresse de destination du paquet ncessite dtre traduite (DNAT). Il est ensuite rout. Si le paquet est destin un autre rseau (rseau B sur le schma), il est alors filtr par les rgles de la chane FORWARD de la table filter, et, si ncessaire, ladresse IP source est traduite (SNAT) dans la chane POSTROUTING avant darriver dans le rseau B. Lorsque le service de destination dcide de rpondre, le paquet subit la mme squence de traitement. Les chanes
OPPIDA/DOC/2009/AUA/534/1.4
Guide de configuration Netfilter-iptables - Version du 10 Juin 2009 Page 8/31 Ce document est la proprit de la socit OPPIDA et ne peut tre communiqu ou reproduit sans autorisation
FORWARD et POSTROUTING peuvent tre configures pour mettre en uvre des fonctionnalits de qualit de service dans leurs tables mangle. Si le paquet est destin au pare-feu lui-mme, il passe alors travers la table mangle de la chane INPUT, si elle est configure, avant dtre filtre par les rgles de la table filter de la chane INPUT. Si le paquet passe avec succs ces tests, il est alors trait pour par lapplication concerne. A cette tape, le pare-feu doit mettre une rponse. Cette rponse est route et inspecte par les rgles la table mangle de la chane OUTPUT. Ensuite, les rgle de la table nat de la chane OUTPUT dterminent si DNAT est requit et les rgles de la table filter de la chane OUTPUT sont ensuite appele pour aider bloquer les paquets non autoriss. Enfin, avant que le paquet soit renvoy sur Internet, La SNAT et la QOS sont effectus, si besoin, par les tables mangle et nat de la chane POSTROUTING.
2.3. Cibles et sauts Chaque rgle du pare-feu inspecte chaque paquet IP et puis tente de lidentifier afin de dterminer quelle opration est effectuer dessus. Une fois la cible identifie, le paquet est mis en attente pour un traitement ultrieur. Le tableau ci-dessous liste les utilisations des cibles prdfinies. Cible Description Options les plus utilises ACCEPT iptables stoppe le traitement
Le paquet est autoris passer
N/A
DROP iptables stoppe le traitement
Le paquet est bloqu
N/A
LOG Linformation sur le paquet est envoye au dmon syslog pour journalisation
iptables continue le traitement avec la rgle suivante dans la table
Comme il nest pas possible de journaliser et de bloquer en mme temps, il est dusage davoir deux rgles similaires la suite. La premire enregistre le paquet, la seconde le bloque.
--log-prefix "string"
Indique iptables de prfixer tous les messages de journalisation avec un chane de caractre dfinie par lutilisateur. Frquemment utilis pour indiquer pourquoi le paquet a t bloqu.
--log-level niveau
Indique iptables et syslog le niveau de journalisation utiliser. Les niveaux sont
debug,info,notice,warning,err,crit,alert,emerg.
REJECT Fonctionne comme la cible DROP, mais retourne en plus un message lmetteur du paquet indiquant que le paquet a t bloqu.
--reject-with raison
La raison indique quel type de message est retourn. Les raisons peuvent tre les suivantes :
icmp-port-unreachable (default)
icmp-net-unreachable
icmp-host-unreachable
icmp-proto-unreachable
icmp-net-prohibited
icmp-host-prohibited
tcp-reset
echo-reply
OPPIDA/DOC/2009/AUA/534/1.4
Guide de configuration Netfilter-iptables - Version du 10 Juin 2009 Page 9/31 Ce document est la proprit de la socit OPPIDA et ne peut tre communiqu ou reproduit sans autorisation
DNAT Utilis pour faire une traduction de ladresse rseau de destination, cest--dire une rcriture de ladresse IP de destination du paquet.
--to-destination [-][:[-]]
Indique iptables ce que l(les)adresse(s) IP et le(s) port(s) de destination doivent tre.
SNAT Utilis pour faire une traduction de ladresse rseau source, c'est--dire une rcriture de ladresse IP source du paquet.
Ladresse IP source est dfinie par lutilisateur.
--to-source [-][:-]
Spcifie ladresse IP source et les ports utiliser par SNAT.
MASQUERADE Utilis pour faire une traduction dadresse rseau source.
Par dfaut, ladresse IP source est la mme que celle utilise par linterface du pare-feu.
Cette option doit tre utilise lorsque lIP de linterface est susceptible de changer, par exemple dans le cas dune connexion PPP.
[--to-ports [-]]
Spcifie la plage de ports source laquelle le port source peut tre mapp.
Figure 4 : Description des cibles les plus utilises
Les cibles SNAT et MASQUERADE sont quasiment similaires, mais il existe des diffrences subtiles : la cible MASQUERADE est une forme spcialise de SNAT. Utilise de faon basique comme la cible SNAT, elle ne ncessite aucune option --to-source, car a t spcialement cre pour fonctionner avec des adresses IP dynamiques. Si un systme utilise uniquement des adresses IP statiques, il est prfrable d'utiliser la cible SNAT. Il est toujours possible d'utiliser la cible MASQUERADE au lieu de SNAT, mais au dtriment de l'efficacit, car MASQUERADE doit vrifier chaque fois l'adresse IP source.
2.4. Oprations importantes Chaque ligne dun script iptables a non seulement un saut, mais elle a aussi un certain nombre doptions en ligne de commande qui sont utilises pour ajouter des rgles aux chanes qui correspondent aux caractristiques du paquet, comme ladresse IP source ou le port TCP. Il y a aussi des options qui peuvent tre utilises pour purger une chane. Le tableau ci-dessous liste la plupart des options couramment utilises. Commande Description -t Si la table nest pas spcifie, alors la table choisie par dfaut est filter. Les tables
prdfinies sont : filter, nat, mangle.
-j Saute la cible spcifie lorsque le paquet correspond la rgle. -A Ajoute la rgle la fin de la chane. -F Flush. Supprime toutes les rgles de la table slectionne.
-p < type-protocole> Protocole surveiller. Le type inclut icmp, tcp, udp, etc.
-s < addresse-ip> Adresse IP source surveiller.
-d < addresse-ip > Adresse IP destination surveiller.
-i Interface dentre surveiller (le paquet entre par cette interface). -o < nom-interface > Interface de sortie surveiller (le paquet sort par cette interface).
Figure 5: Critres gnraux de slection
OPPIDA/DOC/2009/AUA/534/1.4
Guide de configuration Netfilter-iptables - Version du 10 Juin 2009 Page 10/31 Ce document est la proprit de la socit OPPIDA et ne peut tre communiqu ou reproduit sans autorisation
Dans cet exemple : iptables -A INPUT -i eth2 -d 172.16.42.1 -p TCP -j ACCEPT
iptables est configur pour autoriser le pare-feu accepter les paquets TCP venant sur son interface eth2, partir de nimporte quelle adresse IP, et destine au pare-feu, qui a ladresse IP 172.16.42.1.
Commande Description -p tcp --sport Port TCP source. Peut tre une valeur unique ou une plage dans ce format : numro-port-
de-dpart:numro-port-fin.
-p tcp --dport Port TCP destination. Peut tre une valeur unique ou une plage dans ce format : numro-port-de-dpart:numro-port-fin.
-p tcp --syn Utilis pour identifier une nouvelle demande de connexion TCP. ! syn indique tout sauf une nouvelle requte de connexion .
-p udp --sport Port UDP source. Peut tre une valeur unique ou une plage dans ce format : numro-port-de-dpart:numro-port-fin.
-p udp --dport Port UDP destination. Peut tre une valeur unique ou une plage dans ce format : numro-port-de-dpart:numro-port-fin.
Figure 6: Critres de slection tcp et udp
Dans cet exemple: iptables -A FORWARD -i eth0 -d 192.168.42.51 -o eth1 -p TCP \
--sport 1024:65535 --dport 80 -j ACCEPT
iptables est configur pour autoriser le pare-feu accepter les paquets TCP pour le routage lorsquils entrent sur linterface eth0, partir de nimporte quelle adresse, sils sont destins ladresse IP 192.168.42.51 qui est joignable via linterface eth1. Le port source doit tre dans la plage des ports non privilgis, cest dire compris entre 1024 65535, et le port destination est le port 80 (gnralement www/http).
Correspondance Description --icmp-type Les types les plus couramment utiliss sont echo-reply et echo-request
Figure 7 : Critre de slection ICMP (ping) Dans cet exemple :
iptables -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
iptables est configur pour autoriser le pare-feu pour envoyer des requtes ICMP echo-requests (pings) et en retour, accepter les rponses (ICMP echo-reply). Considrons un autre exemple :
iptables -A INPUT -p icmp --icmp-type echo-request \
-m limit --limit 1/s -i eth0 -j ACCEPT
La fonction limit prcise ici le nombre maximum de correspondance autoriser par seconde. Il est possible de spcifier des intervalles de temps dans le format /seconde, /minute, /heure, ou /jour, ou dutiliser des abrviations comme 3/s ou 3/second . Dans cet exemple, la rponse ICMP est restreinte au maximum dune par seconde. Lors quelle est configure correctement, cette fonctionnalit autorise le filtrage des volumes importants de trafic qui correspondent des attaques par dni de service ou par ver.
OPPIDA/DOC/2009/AUA/534/1.4
Guide de configuration Netfilter-iptables - Version du 10 Juin 2009 Page 11/31 Ce document est la proprit de la socit OPPIDA et ne peut tre communiqu ou reproduit sans autorisation
iptables -A INPUT -p tcp --syn -m limit --limit 5/s -i eth0 -j ACCEPT
Il est possible dutiliser la fonction limit pour rduire la vulnrabilit du systme certains types dattaques par dni de service. Ici, la dfense contre des attaques par SYN flood a t mise en place en limitant le nombre de segments TCP avec le bit SYN fix un nombre maximal de cinq par seconde. Commande Description -m multiport --sport Une varit de ports source TCP/UDP, spars par des virgules.
-m multiport --dport Une varit de ports destination TCP/UDP, spars par des virgules.
-m multiport --port Une varit de ports TCP/UDP, spars par des virgules. Les ports source et destination sont supposs tre les mmes.
-m --state Les tats les plus utiliss sont les suivants :
ESTABLISHED: Le paquet est une partie dune connexion o il y a eu un change bilatral.
NEW: Le paquet est le dbut dune nouvelle connexion.
RELATED: Le paquet est le dbut dune nouvelle connexion secondaire. Cest une caractristique commune des protocoles comme le transfert des donnes FTP ou une erreur ICMP.
INVALID: Le paquet ne peut pas tre identifi. Peut tre en raison de linsuffisance des ressources du systme, ou des erreurs ICMP qui ne correspondent pas un flux de donne existant.
Lannexe 1 fournit des informations complmentaires sur les tats des connexions.
Figure 8: Critres tendus de slection
Voici une extension de lexemple prcdent : iptables -A FORWARD -i eth0 -d 192.168.42.51 -o eth1 -p TCP \
--sport 1024:65535 -m multiport --dport 80,443 -j ACCEPT
iptables -A FORWARD -o eth0 -s 192.168.42.51 -i eth1 -p TCP \
-m state --state ESTABLISHED -j ACCEPT
Ici iptables est configur pour autoriser le pare-feu accepter les paquets TCP tre routs quand ils entrent sur linterface eth0 partir de nimporte quelle adresse, et destin ladresse 192.168.42.58, qui est accessible via linterface eth1. Le port source est non privilgi, cest--dire dans la plage entre 1024 et 65535 et les ports de destination sont le port 80 (www/http) et 443 (https). Les paquets retour venant de 192.168.42.58 sont autoriss aussi. Cet exemple montre un filtrage nutilisant pas les capacits de suivi des tats de netfilter, au lieu dindiquer la source et la destination des ports, il est prfrable dautoriser les paquets lis des connexions tablies ou lies en utilisant les options m state et state ESTABLISHED.
2.5. Utilisation de chanes dfinies par les utilisateurs
Aussi, il est possible de configurer iptables avec des chanes dfinies par lutilisateur. Cette fonctionnalit est frquemment utilise pour aider rationaliser le traitement des paquets. Par exemple, au lieu dutiliser une seule chane prdfinie pour tous les protocoles, il est possible dutiliser la chane pour dterminer le type de protocole pour le paquet et ensuite de renvoyer le traitement rel une chane dfinie par lutilisateur, une chane spcifique chaque protocole, dfinie dans la table filter.
OPPIDA/DOC/2009/AUA/534/1.4
Guide de configuration Netfilter-iptables - Version du 10 Juin 2009 Page 12/31 Ce document est la proprit de la socit OPPIDA et ne peut tre communiqu ou reproduit sans autorisation
Par exemple : iptables -A INPUT -i eth0 -d 192.168.42.51 -j fast-input-queue iptables -A OUTPUT -o eth0 -s 192.168.42.51 -j fast-output-queue
iptables -A fast-input-queue -p icmp -j icmp-queue-in iptables -A fast-output-queue -p icmp -j icmp-queue-out
iptables -A icmp-queue-out -p icmp --icmp-type echo-request \ -m state --state NEW -j ACCEPT
iptables -A icmp-queue-in -p icmp --icmp-type echo-reply -j ACCEPT
Voici six files dattente permettant damliorer la vitesse de traitement. Le tableau ci-dessous rsume la fonction de chaque chane. Chaine Description INPUT La chane standard INPUT prdfinie
OUTPUT La chane standard OUTPUT prdfinie
fast-input-queue Chane dentre ddie identifier les protocoles spcifiques et trier les paquets dans les chanes spcifiques chaque protocole.
fast-output-queue Chane de sortie ddie identifier les protocoles spcifiques et trier les paquets dans les chanes spcifiques chaque protocole.
icmp-queue-out File dattente de sortie ddie ICMP.
icmp-queue-in File dattente dentre ddie ICMP.
Figure 9: Exemple de listes de queues personnalises
OPPIDA/DOC/2009/AUA/534/1.4
Guide de configuration Netfilter-iptables - Version du 10 Juin 2009 Page 13/31 Ce document est la proprit de la socit OPPIDA et ne peut tre communiqu ou reproduit sans autorisation
3. Configuration 3.1. Principe de base
En principe, il est recommand de configurer un pare-feu en bloquant tout par dfaut, puis en ouvrant uniquement quand cela est ncessaire. C'est habituellement paraphras par tout ce qui n'est pas spcifiquement autoris est dfendu .
3.2. Configuration des options du noyau Les options de configuration retenues pour le noyau Linux en vue de l'valuation des fonctionnalits essentielles de Netfilter sont les suivantes :
CONFIG_NETFILTER (Indispensable pour activer Netfilter)
CONFIG_NF_CONNTRACK (Suivi de connexion)
CONFIG_NF_CONNTRACK_FTP (Suivi de connexion du protocole de niveau 7 : FTP)
CONFIG_NETFILTER_XTABLES (Obligatoire pour le matching)
CONFIG_NETFILTER_XT_MATCH_CONNLIMIT (Rate limiting, utile contre les DoS)
CONFIG_NETFILTER_XT_MATCH_STATE (Filtrage stateful)
CONFIG_NETFILTER_XT_MATCH_LIMIT (Principalement utilis pour la journalisation) CONFIG_NF_CONNTRACK_IPV4 (Obligatoire pour le NAT)
CONFIG_IP_NF_IPTABLES (Interface avec iptables)
CONFIG_IP_NF_FILTER (Filtrage, fonctionnalit de base)
CONFIG_IP_NF_TARGET_LOG (Pour la journalisation) CONFIG_NF_NAT (Fonctionnalits de la traduction dadresse)
Les patchs et les autres matchs ne sont pas retenus.
3.3. Chargement des modules Selon les besoins, il peut tre ncessaire de charger les modules suivants.
modprobe ip_tables
modprobe iptable_filter
modprobe iptable_mangle
Par exemple, le module ip_conntrack_ftp permet de faire du FTP passif aussi bien que du FTP actif. Lapplication diptables requiert le chargement de certains modules noyaux pour activer les fonctionnalits ncessaire. Lorsque tout type de NAT est requis, le module iptable_nat a besoin dtre charg. Le module ip_conntrack_ftp est ncessaire pour le support FTP et doit toujours tre charg avec le module ip_conntrack qui trace les tats des connexions TCP. Le module ip_nat_ftp est ncessaire lorsquil y a des serveurs FTP derrire le pare-feu NAT.
# Module pour suivre ltat des connexions
modprobe ip_conntrack
# Module pour suivre les connexions FTP actives (ncessite ip_conntrack)
modprobe ip_conntrack_ftp
# Module pour raliser la traduction dadresse (NAT)
modprobe iptable_nat
OPPIDA/DOC/2009/AUA/534/1.4
Guide de configuration Netfilter-iptables - Version du 10 Juin 2009 Page 14/31 Ce document est la proprit de la socit OPPIDA et ne peut tre communiqu ou reproduit sans autorisation
# Module requis pour un serveur FTP utilisant la NAT
modprobe ip_nat_ftp
3.4. Activation des mcanismes de protection du systme dexploitation Afin damliorer la capacit de rsistance du pare-feu aux attaques rseau, le systme dexploitation Linux offre un certain nombre de mcanismes de protection prdfinis. Ces mcanismes doivent tre activ en modifiant des paramtres du noyau dans le systme de fichier /proc. Suivant la distribution utilise, ces modifications seffectuent soit en ditant le fichier /etc/sysctl.conf, soit par lignes de commande. Voici un exemple du fichier /etc/sysctl.conf :
# Fichier : /etc/sysctl.conf
# Protection contre lusurpation dadresse IP
net/ipv4/conf/all/rp_filter = 1
# Autoriser la journalisation des paquets ayant une adresse IP mal forme net/ipv4/conf/all/log_martians = 1
# Interdire les redirections
net/ipv4/conf/all/send_redirects = 0
# Interdire les paquets dont la source a t route
net/ipv4/conf/all/accept_source_route = 0
# Interdire les redirections ICMP
net/ipv4/conf/all/accept_redirects = 0
# Activer la protection contre les dnis de service
net/ipv4/tcp_syncookies = 1
# Interdire les rponses au ping broadcast
net/ipv4/icmp_echo_ignore_broadcasts = 1
# Autoriser le routage IP (requis pour faire de la NAT)
net/ipv4/ip_forward = 1
Ou pour toutes les interfaces existantes ou futures, en ligne de commande : for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
echo 1 > $f done
# Interdire les rponses au ping broacast
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
# Activer la protection contre les mauvais messages derreur
OPPIDA/DOC/2009/AUA/534/1.4
Guide de configuration Netfilter-iptables - Version du 10 Juin 2009 Page 15/31 Ce document est la proprit de la socit OPPIDA et ne peut tre communiqu ou reproduit sans autorisation
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
# Interdire les redirections ICMP
for f in /proc/sys/net/ipv4/conf/*/accept_redirects; do
echo 0 > $f done
for f in /proc/sys/net/ipv4/conf/*/send_redirects; do
echo 0 > $f done
# Interdire les paquets dont la source a t route
for f in /proc/sys/net/ipv4/conf/*/accept_source_route; do
echo 0 > $f done
# Journaliser les paquets usurps, les paquets dont la source a t route, les paquets
# redirigs
for f in /proc/sys/net/ipv4/conf/*/log_martians; do
echo 1 > $f done
3.5. Paramtrage fin des timers Voici les valeurs par dfaut des timers de connexion pour les protocoles UDP et ICMP :
nf_ct_udp_timeout = 30 secondes; Ce timer correspond au timeout dune connexion UDP tablie
nf_ct_udp_timeout_stream = 180 secondes; Ce timer correspond au timeout dune connexion UDP en cours dtablissement
nf_ct_icmp_timeout = 30 secondes. Ce timer correspond au timeout dune connexion ICMP tablie
Voici les valeurs par dfaut des timers de connexion pour le protocole TCP : TCP_CONNTRACK_SYN_SENT = 2 MINS, TCP_CONNTRACK_SYN_RECV = 60 SECS, TCP_CONNTRACK_ESTABLISHED = 5 DAYS, TCP_CONNTRACK_FIN_WAIT = 2 MINS, TCP_CONNTRACK_CLOSE_WAIT = 60 SECS, TCP_CONNTRACK_LAST_ACK = 30 SECS,
TCP_CONNTRACK_TIME_WAIT = 2 MINS, TCP_CONNTRACK_CLOSE = 10 SECS,
OPPIDA/DOC/2009/AUA/534/1.4
Guide de configuration Netfilter-iptables - Version du 10 Juin 2009 Page 16/31 Ce document est la proprit de la socit OPPIDA et ne peut tre communiqu ou reproduit sans autorisation
Il est pertinent pour des raisons de scurit de modifier ces timers, notamment TCP_CONNTRACK_ESTABLISHED qui indique la dure quune session tablie sans activit va rester dans la table des connexions avant dtre dtruite et qui est gal 5 jours par dfaut..
Pour modifier ces timers, il est possible dajouter certaines entres dans le fichier /etc/sysctl.conf :
net/netfilter/nf_conntrack_tcp_timeout_established = 3600 net/netfilter/nf_conntrack_udp_timeout = 10 net/netfilter/nf_conntrack_udp_timeout_stream = 30 net/netfilter/nf_conntrack_icmp_timeout = 10
Il est aussi possible de modifier les autres timers via les informations de configuration suivantes. Certains de ces timers sont modifier avec prcaution et doivent tre tests afin de ne pas dgrader les services du protocole TCP.
net/netfilter/nf_conntrack_generic_timeout = Valeur en seconde net/netfilter/nf_conntrack_tcp_timeout_fin_wait = Valeur en seconde net/netfilter/nf_conntrack_tcp_timeout_close_wait = Valeur en seconde net/netfilter/nf_conntrack_tcp_timeout_last_ack = Valeur en seconde net/netfilter/nf_conntrack_tcp_timeout_time_wait = Valeur en seconde net/netfilter/nf_conntrack_tcp_timeout_close = Valeur en seconde
3.6. Suivi des connexions Il est fortement recommand dactiver le suivi de connexions : il introduit un peu plus de charge, puisque toutes les connexions sont suivies, mais est trs utile pour contrler l'accs aux rseaux. Pour cela, il faut charger le module ip_conntrack.ko si le noyau ne charges pas les modules automatiquement, et qu'il n'est pas compil dans le noyau. Pour suivre convenablement des protocoles complexes, il faudra charger le module de suivi appropri (par exemple : ip_conntrack_ftp.ko). Pour plus de dtails sur le suivi des connexions, se rfrer lannexe 1.
3.7. Journalisation et scurisation du journal daudit La journalisation est ncessaire sur un pare-feu, afin de pouvoir auditer en cas de problme, soit fonctionnel, soit de scurit. Cependant, afin de ne pas surcharger les journaux et crer un dni de service sur le systme, la journalisation doit tre effectue avec la concordance limit. Lexemple du script suivant peut tre utilis pour dterminer quels sont les ports TCP/UDP qui ont besoin dtre ouverts. Les messages sont enregistrs dans le fichier /var/log/messages.
# Enregistre et bloque tous les paquets dans /var/log/messages
iptables -A OUTPUT -j LOG iptables -A INPUT -j LOG
OPPIDA/DOC/2009/AUA/534/1.4
Guide de configuration Netfilter-iptables - Version du 10 Juin 2009 Page 17/31 Ce document est la proprit de la socit OPPIDA et ne peut tre communiqu ou reproduit sans autorisation
iptables -A FORWARD -j LOG
iptables -A OUTPUT -j DROP iptables -A INPUT -j DROP iptables -A FORWARD -j DROP
OPPIDA/DOC/2009/AUA/534/1.4
Guide de configuration Netfilter-iptables - Version du 10 Juin 2009 Page 18/31 Ce document est la proprit de la socit OPPIDA et ne peut tre communiqu ou reproduit sans autorisation
4. Exemples 4.1. Exemples utiles
Afin de donner des exemples concrets, nous avons repris linfrastructure donne en figure 1 :
Figure 10 : Architecture d'exemple
Le pare feu Netfilter possde quatre interfaces rseaux : Linterface ETH0 est connecte au rseau non fiable : 172.17.0.1 Linterface ETH1 est connecte au rseau DMZ hbergeant les services publier:
192.168.0.1 Linterface ETH2 est connecte au rseau dadministration : 192.168.1.1 Linterface ETH3 est connecte au rseau interne dit de confiance : 192.168.2.1
Ladministration du pare feu Netfilter est ralise via le protocole SSH partir de la zone dadministration.
Quatre services sont protgs par le par feu et situs en DMZ : Le service Web (HTTP/HTTPS) dIP interne 192.168.0.2 et dIP NAT 172.17.0.2 Le service FTP dIP interne 192.168.0.3 et dIP NAT 172.17.0.3 Le service de messagerie (SMTP) dIP interne 192.168.0.4 et dIP NAT 172.17.0.4 Le service DNS dIP interne 192.168.0.5 et dIP NAT 172.17.0.5
OPPIDA/DOC/2009/AUA/534/1.4
Guide de configuration Netfilter-iptables - Version du 10 Juin 2009 Page 19/31 Ce document est la proprit de la socit OPPIDA et ne peut tre communiqu ou reproduit sans autorisation
La zone dadministration comporte : La station dadministration scurit dIP 192.168.1.2 La station de supervision dIP 192.168.1.3
4.1.1. Rgles de filtrage des flux vers la DMZ.
4.1.1.1. Protocole HTTP/HTTPS Ces lignes de commande permettent daccepter les connexions HTTP et HTTPS des clients externes vers le serveur Web. Le serveur Web coute en local les ports 8000 et 4443.
Filtrage:
iptables t filter -A FORWARD p tcp d 192.168.0.3 -dport 8000,4443 m state -state -j ACCEPT
Translation dadresse:
iptables t nat A PREROUTING p tcp d 172.17.0.3 -dport 80 j DNAT -to-destination 192.168.1.3:8000
iptables t nat A PREROUTING p tcp d 172.17.0.3 -dport 443 j DNAT -to-destination 192.168.1.3:4443
4.1.1.2. Protocole SMTP Ces lignes de commande permettent daccepter les connexions SMTP vers le relai SMTP sur le port 25 et les connexions sortantes du relai vers les serveurs SMTP externes.
Filtrage:
iptables t filter -A FORWARD p tcp d 192.168.0.4 -dport 25 m state -state NEW -j ACCEPT
iptables t filter -A FORWARD p tcp s 172.17.0.4 -dport 25 m state -state NEW -j ACCEPT
Translation dadresse:
iptables t nat A PREROUTING p tcp d 172.17.0.4 -dport 25 j DNAT -to-destination 192.168.1.4
iptables t nat A POSTROUTING o eth0 p tcp s 172.17.0.4 -dport 25 j SNAT -to-source 192.168.1.4
4.1.1.3. DNS Ces lignes de commande permettent daccepter les flux DNS vers le serveur DNS sur le port 53.
Filtrage:
iptables t filter -A FORWARD p udp d 192.168.0.2 -dport 53 m state -state NEW -j ACCEPT
Translation dadresse:
iptables t nat A PREROUTING p udp d 172.17.0.2 -dport 53 j DNAT -to-destination 192.168.1.2
4.1.1.4. Protocole FTP Ces lignes de commande permettent daccepter les connexions FTP (passive) vers le serveur FTP sur le port 21.
OPPIDA/DOC/2009/AUA/534/1.4
Guide de configuration Netfilter-iptables - Version du 10 Juin 2009 Page 20/31 Ce document est la proprit de la socit OPPIDA et ne peut tre communiqu ou reproduit sans autorisation
Filtrage:
iptables t filter -A FORWARD p tcp d 192.168.0.2 -dport 21 m state -state NEW -j ACCEPT
iptables t filter -A FORWARD p tcp d 192.168.0.2 -dport 1024: m state -state NEW -j ACCEPT
Translation dadresse:
iptables t nat A PREROUTING p tcp d 172.17.0.2 -dport 21 j DNAT -to-destination 192.168.1.2:21
iptables t nat A PREROUTING p tcp d 172.17.0.2 -dport 1024: j DNAT -to- destination 192.168.1.2
Pour cette connexion, il faut donc charger le module conntrack_ftp (voir annexe 1), ainsi que le module ip_nat_ftp dans le cas o le serveur FTP est NAT.
4.1.1.5. Protocole ICMP Cette ligne de commande permet dautoriser le ping vers les serveurs en DMZ :
Filtrage:
iptables t filter -A FORWARD -p icmp -icmp-type 8 d 192.168.0.2 m state -state NEW -j ACCEPT
iptables t filter -A FORWARD -p icmp -icmp-type 8 d 192.168.0.3 m state -state NEW -j ACCEPT
iptables t filter -A FORWARD -p icmp -icmp-type 8 d 192.168.0.4 m state -state NEW -j ACCEPT
iptables t filter -A FORWARD -p icmp -icmp-type 8 d 192.168.0.5 m state -state NEW -j ACCEPT
Translation dadresse:
iptables t nat A PREROUTING p icmp d 172.17.0.2 j DNAT -to-destination 192.168.1.2 iptables t nat A PREROUTING p icmp d 172.17.0.3 j DNAT -to-destination 192.168.1.3 iptables t nat A PREROUTING p icmp d 172.17.0.4 j DNAT -to-destination 192.168.1.4 iptables t nat A PREROUTING p icmp d 172.17.0.5 j DNAT -to-destination 192.168.1.5
Ces lignes de commande permettent dautoriser le ping, mais dans la limite de 2 pings par seconde (- limit 2/s) sur le serveur FTP.
iptables t filter -A FORWARD -p icmp -icmp-type 8 d 192.168.0.2 m state -state NEW -j ACCEPT
iptables t filter -A FORWARD -p icmp -m limit --limit 2/s -j ACCEPT
4.1.1. Flux dadministration
4.1.1.1. Protocole SSH Cette ligne de commande permet daccepter les connexions SSH sur le pare-feu de la station dadministration scurit:
iptables t filter -A INPUT i eth2 -p tcp --dport 22 s 192.168.1.2 m state -state NEW -j ACCEPT
4.1.1.2. Protocole ICMP Cette ligne de commande permet dautoriser le ping de la station de supervision vers le pare feu :
iptables t filter -A INPUT i eth2 -p icmp -icmp-type 8 s 192.168.1.3 m state -state NEW -j ACCEPT
OPPIDA/DOC/2009/AUA/534/1.4
Guide de configuration Netfilter-iptables - Version du 10 Juin 2009 Page 21/31 Ce document est la proprit de la socit OPPIDA et ne peut tre communiqu ou reproduit sans autorisation
4.1.2. Rgles de suivi de connexions Ici, nous allons accepter tous les paquets correspondant une session existante :
iptables t filter -A INPUT i eth2 m state -state ESTABLISHED,RELATED j ACCEPT iptables t filter A FORWARD m state -state ESTABLISHED,RELATED j ACCEPT
Ici, nous allons dtruire les paquets nappartenant pas une session valide : iptables t filter -A INPUT m state -state INVALID j DROP iptables t filter A FORWARD m state -state INVALID j DROP
4.1.3. Protections contre des attaques spcifiques
4.1.3.1. Rgles danti-spoofing Ces lignes permettent de se prmunir contre les attaques de spoofing IP sur linterface externe eth0:
iptables t filter A FORWARD i eth0 s 192.168.0.0/24 m state -state NEW j DROP iptables t filter A FORWARD i eth0 s 192.168.1.0/24 m state -state NEW j DROP iptables t filter A FORWARD i eth0 s 192.168.2.0/24 m state -state NEW j DROP
4.1.3.2. Protection contre les scans de port Cette ligne de commande permet de se protger des serveurs distants contre des scans de port :
iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT
4.1.3.3. Protection contre le ping de la mort Cette ligne de commande permet de protger les serveurs distants contre une attaque de ping de la mort :
iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
4.1.4. Optimisation de la taille des paquets Cette ligne de commande permet doptimiser la taille des paquets :
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS -o eth0 --clamp-mss-to-pmtu
4.2. Exemple de script complet Le script ci-dessous est un exemple dun script pouvant tre lanc sur un pare-feu faisant coupure entre trois rseaux : rseau externe, rseau interne (zone de confiance), rseau dadministration (exploitation et supervision).
#!/bin/sh
# Script iptables pour le noyau Linux 2.6
echo -e "\n\nMontage du pare-feu "
###############################
# Configuration des variables #
###############################
# Variables configurer pour chaque pare-feu
EXTIF="eth0" # Nom de linterface externe (zone non fiable)
OPPIDA/DOC/2009/AUA/534/1.4
Guide de configuration Netfilter-iptables - Version du 10 Juin 2009 Page 22/31 Ce document est la proprit de la socit OPPIDA et ne peut tre communiqu ou reproduit sans autorisation
EXTNET="172.17.0.0/24 " # Adresse rseau sur linterface externe
EXTIP="172.17.0.1" # Adresse IP de linterface externe
DMZIF="eth1" # Nom de linterface DMZ
DMZNET="192.168.0.0/24" # Adresse rseau sur linterface DMZ
DMZIP="192.168.0.1" # Adresse IP de linterface DMZ
ADMIF="eth2" # Nom de linterface dadministration
ADMNET="192.168.1.0/24" # Adresse rseau sur linterface dadministration
ADMIP="192.168.1.1/24" # Adresse IP de linterface dadministration
INTIF="eth4" # Nom de linterface interne (zone de confiance)
INTNET="192.168.2.0/24" # Adresse rseau sur linterface interne
INTIP="192.168.2.1/24" # Adresse IP de linterface interne
# Variables priori ne pas modifier
UNIVERS="0.0.0.0/0" # Ensemble des adresses rseau
IPT="/sbin/iptables" # Emplacement et nom de la commande iptables
##################
# Initialisation #
##################
echo "Montage des modules requis"
/sbin/depmod -a
/sbin/modprobe ip_tables
/sbin/modprobe ip_conntrack
/sbin/modprobe ip_conntrack_ftp
/sbin/modprobe iptable_nat
/sbin/modprobe ip_nat_ftp
# Activation de la combinaison des tcp-wrappers, vrification de route et filtrage
# de paquets, sur toutes les interfaces existantes ou futures
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
echo 1 > $f done
# Interdire les rponses au ping broacast
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
# Activer la protection contre les mauvais messages derreur
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
# Interdire les redirections ICMP
for f in /proc/sys/net/ipv4/conf/*/accept_redirects; do
OPPIDA/DOC/2009/AUA/534/1.4
Guide de configuration Netfilter-iptables - Version du 10 Juin 2009 Page 23/31 Ce document est la proprit de la socit OPPIDA et ne peut tre communiqu ou reproduit sans autorisation
echo 0 > $f done for f in /proc/sys/net/ipv4/conf/*/send_redirects; do
echo 0 > $f done
# Interdire les paquets dont la source a t route
for f in /proc/sys/net/ipv4/conf/*/accept_source_route; do
echo 0 > $f done
# Journaliser les paquets usurps, les paquets dont la source a t route, les paquets
# redirigs
for f in /proc/sys/net/ipv4/conf/*/log_martians; do
echo 1 > $f done
echo " Autorisation du forwarding IP"
echo "1" > /proc/sys/net/ipv4/ip_forward
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
# Suppression des rgles existantes et configuration de la politique par dfaut (DROP)
$IPT -P INPUT DROP $IPT -F INPUT $IPT -P OUTPUT DROP $IPT -F OUTPUT $IPT -P FORWARD DROP $IPT -F FORWARD $IPT -F -t nat
# Vidage de la table utilisateur, si elle existe
if [ "`$IPT -L | grep drop-and-log-it`" ]; then $IPT -F drop-and-log-it fi
# Suppression de toutes les chanes spcifies par lutilisateur
$IPT -X
# Remise zro de tous les compteurs
$IPT -Z
# Cration de la chane drop-and-log_it (DROP avec enregistrement dans le journal dvnement)
$IPT -N drop-and-log-it $IPT -A drop-and-log-it -j LOG --log-level info $IPT -A drop-and-log-it -j REJECT
# Autorise tout trafic entrant dj tabli
OPPIDA/DOC/2009/AUA/534/1.4
Guide de configuration Netfilter-iptables - Version du 10 Juin 2009 Page 24/31 Ce document est la proprit de la socit OPPIDA et ne peut tre communiqu ou reproduit sans autorisation
$IPT -A FORWARD -i $EXTIF -s $UNIVERS -d $DMZIP -m state --state ESTABLISHED,RELATED -j ACCEPT
# Autorise tout trafic sortant dj tabli $IPT -A INPUT -i $DMZIF -s $EXTIP -d $UNIVERS -m state --state ESTABLISHED,RELATED -j ACCEPT
# Autorise tout trafic dj tabli de la zone dadministration vers le firewall $IPT -A INPUT i eth2 s $ADMNET m state -state ESTABLISHED,RELATED j ACCEPT
# Tous les autres paquets hors session sont refuss.
$IPT -A INPUT m state -state INVALID j DROP $IPT A FORWARD m state -state INVALID j DROP
# Protection contre les scans de port
$IPT -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT
# Protection contre le ping de la mort
iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
#######################
# Configuration INPUT #
#######################
echo -e " - Lecture des rgles INPUT"
# Un flux sur linterface loopback est considr comme valide.
$IPT -A INPUT -i lo -s $UNIVERS -d $UNIVERS -j ACCEPT
# Acceptation des flux dadministration
$IPT -A INPUT i eth2 -p tcp --dport 22 s 192.168.1.2 m state -state NEW -j ACCEPT
# Acceptation des ICMP venant de la zone dadministration
$IPT -A INPUT i eth2 -p icmp -icmp-type 8 s 192.168.1.3 m state -state NEW -j ACCEPT
########################
# Configuration OUTPUT #
########################
echo -e " - Lecture des rgles OUTPUT"
#########################
# Configuration FORWARD #
#########################
echo -e " - Lecture des rgles FORWARD"
OPPIDA/DOC/2009/AUA/534/1.4
Guide de configuration Netfilter-iptables - Version du 10 Juin 2009 Page 25/31 Ce document est la proprit de la socit OPPIDA et ne peut tre communiqu ou reproduit sans autorisation
# Acceptation des flux HTTP/HTTPS vers le serveur Web
$IPT -A FORWARD p tcp d 192.168.0.3 -dport 8000,4443 m state -state -j ACCEPT $IPT t nat A PREROUTING p tcp d 172.17.0.3 -dport 80 j DNAT -to-destination 192.168.1.3:8000
$IPT t nat A PREROUTING p tcp d 172.17.0.3 -dport 443 j DNAT -to-destination 192.168.1.3:4443
# Acceptation des flux entrants et sortants SMTP (messagerie)
$IPT -A FORWARD p tcp d 192.168.0.4 -dport 25 m state -state NEW -j ACCEPT $IPT -A FORWARD p tcp s 172.17.0.4 -dport 25 m state -state NEW -j ACCEPT $IPT t nat A PREROUTING p tcp d 172.17.0.4 -dport 25 j DNAT -to-destination 192.168.1.4
$IPT t nat A POSTROUTING o eth0 p tcp s 172.17.0.4 -dport 25 j SNAT -to-source 192.168.1.4
# Acceptation des flux DNS vers le serveur DNS
$IPT -A FORWARD p udp d 192.168.0.2 -dport 53 m state -state NEW -j ACCEPT $IPT t nat A PREROUTING p udp d 172.17.0.2 -dport 53 j DNAT -to-destination 192.168.1.2
# Acceptation des flux FTP vers le serveur FTP
$IPT -A FORWARD p tcp d 192.168.0.2 -dport 21 m state -state NEW -j ACCEPT $IPT -A FORWARD p tcp d 192.168.0.2 -dport 1024: m state -state NEW -j ACCEPT $IPT t nat A PREROUTING p tcp d 172.17.0.2 -dport 21 j DNAT -to-destination 192.168.1.2:21
$IPT t nat A PREROUTING p tcp d 172.17.0.2 -dport 1024: j DNAT -to- destination 192.168.1.2
echo -e " Le pare-feu est mont.\n\n"
OPPIDA/DOC/2009/AUA/534/1.4
Guide de configuration Netfilter-iptables - Version du 10 Juin 2009 Page 26/31 Ce document est la proprit de la socit OPPIDA et ne peut tre communiqu ou reproduit sans autorisation
Annexes
OPPIDA/DOC/2009/AUA/534/1.4
Guide de configuration Netfilter-iptables - Version du 10 Juin 2009 Page 27/31 Ce document est la proprit de la socit OPPIDA et ne peut tre communiqu ou reproduit sans autorisation
5. Annexe 1 : Suivi des modes de connexion 5.1. Prsentation
La fonctionnalit de suivi des connexions se rfre la capacit de maintenir les informations dune connexion, comme ladresse IP source et destination, les numros de ports, les types de protocole, ltat et la dure de la connexion. Les pare-feux qui sont capables de raliser cela sappelle stateful ( tat ). Le filtrage tat est intrinsquement plus sr que le filtrage sans tat. Le suivi de connexion est accompli en utilisant loption state diptables. La page de manuel indique :
State
Ce module, lorsquil est combin avec le suivi de connexion, permet laccs au suivi de ltat de connexion pour ce paquet.
--state tat
Largument tat est une liste, spare par une virgule, dtats de connexion correspondre. Les tats possibles sont : INVALID, qui signifie que le paquet est associ aucune connexion connue ; ESTABLISHED, qui signifie que le paquet est associ une connexion qui a vu les paquet dans les deux sens ; NEW, qui signifie que le paquet est une nouvelle connexion, ou bien quil est associ une connexion qui na pas envoy de paquet dans les deux sens ; et RELATED, qui signifie que le paquet est une nouvelle connexion, mais quil est associ une connexion existante, comme un transfert de donnes FTP ou une erreur ICMP.
Le suivi de connexion se fait soit dans la chane PREROUTING, soit dans la chane OUTPUT pour les paquets gnrs localement. Le suivi de connexion dfragmente tous les paquets avant le traitement de suivi de leur tat. La table dtat pour des connexions UDP et TCP est mis jour dans /proc/net/ipconntrack. Le nombre maximum de connexions que la table dtat peut contenir est stock dans /proc/sys/net/ipv4/ip_conntrack_max. Cette valeur est dtermine dabord par la quantit de mmoire physique du pare-feu.
5.2. Fonctionnement
5.2.1. Description rapide Pour un paquet transfr, la squence de la ngociation sera ainsi :
1) Le paquet passe par la chane PREROUTING pour tre DNAT si ncessaire. Ensuite, le paquet passe par la table mangle. Alors, le suivi de connexion dfragmente et suit le paquet dune certaine manire :
Si le paquet correspond une entre dans la table state, il fait partie dune connexion ESTABLISHED. Si ce paquet correspond du trafic ICMP, il peut tre RELATED, correspondant une connexion UDP/TCP dj existante dans la table state. Le paquet peut tre une connexion NEW, ou il peut tre li aucune connexion, et dans ce cas il est considr comme INVALID.
2) Le paquet passe par la chane FORWARD. Le pare-feu compare ltat du paquet au jeu de rgle de la table filter, jusqu la premire correspondance, ou jusqu ce que le comportement par dfaut de la chane soit excut.
3) Le paquet pass par la chane POSTROUTING, pour tre SNAT si ncessaire. Il faut noter que tous les paquets sont compars aux rgles de la table filter.
OPPIDA/DOC/2009/AUA/534/1.4
Guide de configuration Netfilter-iptables - Version du 10 Juin 2009 Page 28/31 Ce document est la proprit de la socit OPPIDA et ne peut tre communiqu ou reproduit sans autorisation
5.2.2. Description dtaille Dans cette section seront examin chacun des trois protocoles, UDP, TCP, et ICMP.
UDP Parce quil na pas de numro de squence, UDP est identifi comme un protocole sans tat. Cependant, cela ne signifie pas quil nest pas possible de suivre les connexions UDP. Il y a encore dautres informations utiles qui peuvent tre exploites. Voici un exemple de table dtat pour une nouvelle connexion UDP :
udp 17 19 src=10.0.42.12 dst=192.168.42.51 sport=1032 dport=53 [UNREPLIED] src=192.168.42.51 dst=10.0.42.12 sport=53 dport=1032 use=1
Cette table ne peut tre faite que sil existe une rgle de filtrage spcifique aux connexions NEW, quelque chose comme le jeu de rgles suivant, qui autorise les nouvelles connexions sortantes uniquement :
iptables -A INPUT -p udp -m state --state ESTABLISHED -j ACCEPT iptables -A OUTPUT -p udp -m state --state NEW,ESTABLISHED -j ACCEPT
Voici ce qui peut tre indiqu par rapport la table dtat : Le protocole est UDP (le numro de protocole IP est 17). La table dtat dispose 19 secondes avant son expiration. Les adresses IP source et destination et les ports de la requte dorigine. Les adresses IP source et destination et les ports de la rponse attendue. La connexion est
marque UNREPLIED, ce qui signifie quelle na par t encore reue.
TCP Une connexion TCP est initie par le biais dune poigne de main trois voies ( three-way handshake ) comportant une demande de synchronisation du client, une synchronisation et un accus de rception partir du serveur, et enfin un accus de rception par le client. Ensuite, le trafic circulant entre le serveur et le client est reconnu par les deux parties. La squence ressemble cela :
Figure 11: Poigne de main TCP
OPPIDA/DOC/2009/AUA/534/1.4
Guide de configuration Netfilter-iptables - Version du 10 Juin 2009 Page 29/31 Ce document est la proprit de la socit OPPIDA et ne peut tre communiqu ou reproduit sans autorisation
SYN et ACK se rfrent des drapeaux fixs dans len-tte TCP. Pour obtenir le suivi de connexion pour une connexion TCP, il suffit de mettre en place un jeu de rgles comme ceci :
iptables -A INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT
Etude pas--pas Cette section dtaille pas--pas ltude de la table dtat dune connexion TCP normale.
1) Une fois que le premier SYN est envoy la chane OUTPUT, et est accept par une rgle qui autorise une connexion NEW, la table des connexions peut ressembler cela : tcp 6 119 SYN_SENT src=10.0.42.12 dst=192.168.42.51 sport=1412 dport=80 [UNREPLIED] src=192.168.42.51 dst=10.0.42.12 sport=80 dport=1412 use=1
Ltat de la connexion TCP est SYN_SENT et la connexion est marque UNREPLIED. 2) La connexion est maintenant en attente dun paquet SYN+ACK. Lorsquil arrive, ltat de
connexion change SYN_RECV et la marque UNREPLIED disparat : tcp 6 57 SYN_RECV src=10.0.42.12 dst=192.168.42.51 sport=1412 dport=80 src=192.168.42.51 dst=10.0.42.12 sport=80 dport=1412 use=1
3) La connexion est maintenant en attente de la dernire partie de la poigne de main, un paquet ACK. Lorsquil arrive, la connexion TCP change son tat en ESTABLISHED et la table dtat est marque ASSURED. Voici la connexion tablie : tcp 6 431995 ESTABLISHED src=10.0.42.12 dst192.168.42.51 sport=1412 dport=80 src=192.168.42.51 dst=10.0.42.12 sport=80 dport=1412 [ASSURED] use=1
ICMP Dans le jargon iptables, il y a quatre types de paquets ICMP, qui peuvent tre catgoriss en tat NEW ou ESTABLISHED :
1) Requte Echo (ping, 8) et rponse (pong, 0). 2) Requte Timestamp (13) et rponse (14). 3) Requte Information (15) et rponse (16). 4) Requte Address mask (17) et rponse (18).
La requte, dans chaque cas, est classifie en tat NEW, et la rponse en tat ESTABLISHED. Les autre types de paquet ICMP ne sont pas bass sur un modle requte-rponse et peuvent seulement tre lis dautres connexions (RELATED). Voici par exemple un jeu de rgles, et quelques exemples de ce quil est possible de faire si ce jeu est appliqu :
iptables -A OUTPUT -p icmp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -p icmp -m state --state ESTABLISHED,RELATED -j ACCEPT
1) Une requte ICMP echo est en tat NEW, et est autorise dans la chane OUTPUT. 2) Une rponse ICMP echo, fournie en rponse une requte echo, est en tat
ESTABLISHED, et est autorise dans la chane INPUT. Une rponse echo ne peut pas tre autorise dans la chane OUTPUT parce quil ny a pas de rgles avec ltat NEW dans la chane INPUT qui autorise les requtes echo, alors quune rponse doit ncessairement rpondre une requte.
OPPIDA/DOC/2009/AUA/534/1.4
Guide de configuration Netfilter-iptables - Version du 10 Juin 2009 Page 30/31 Ce document est la proprit de la socit OPPIDA et ne peut tre communiqu ou reproduit sans autorisation
3) Une redirection ICMP, parce quelle nest pas base sur le modle requte-rponse, est dans ltat RELATED, et elle ne peut tre autorise dans la chane INPUT ou dans la chane OUTPUT seulement sil existe dj une connexion TCP ou UDP dans la table dtat avec laquelle la redirection peut tre compare.
5.2.3. Suivi de connexion FTP Tout dabord, pour effectuer un suivi de connexion FTP, il faut charger le module ip_conntrack_ftp module. Un simple jeu de rgles pour permette une connexion FTP peut tre le suivant :
iptables -A INPUT -p tcp --sport 21 -m state --state ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT
Ce nest pas tout. Une connexion FTP a galement besoin dun canal de transmission des donnes, qui peut tre assur de deux manires : FTP actif ou FTP passif.
1) FTP actif Le client FTP envoie un numro de port sur le serveur FTP via le canal de commande PORT au serveur FTP. Le serveur FTP se connecte alors partir du port 20 ce port pour envoyer les donnes, comme un fichier, ou la sortie de la commande ls. La connexion ftp-data est dans se sens oppos de la connexion FTP dorigine. Pour autoriser une connexion FTP active sans connatre le numro de port qui a t envoy, iptables a besoin dune rgle gnrale qui autorise les connexion partir du port 20 du serveur distant aux ports non privilgis (numro du port suprieur 1023) du client FTP. Cette rgle est trop laxiste pour assurer une scurit correcte. Cest dans cette situation que le module ip_conntrack_ftp est utile. Le module est capable de reconnatre la commande PORT et de rcuprer le numro du port. Ainsi, la connexion ftp-data peut tre class en tant que RELATED, lie la connexion sortante dorigine, vers le port 21. Il ny a donc plus besoin dajouter une rgle NEW dans la chane INPUT. Les rgles suivantes permettent de rpondre ce besoin :
iptables -A INPUT -p tcp --sport 20 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -p tcp --dport 20 -m state --state ESTABLISHED -j ACCEPT
2) FTP passif Une commande PORT est nouveau ralise, mais cette fois, partir du serveur vers le client. Le client se connecte au serveur pour le transfert de donnes. Puisque la connexion est dans le mme sens que la connexion FTP dorigine, le FTP passif est intrinsquement plus sr que le FTP actif. Toutefois, les numros de ports ne sont pas connus, et le lien entre une connexion et les numros de port est presque arbitraire. Cest aussi dans cette situation que le module ip_conntrack_ftp est utile. Encore une fois, le module est capable de reconnatre la commande PORT et de rcuprer le numro de port. Au lieu dun tat NEW dans la chane OUTPUT, cest donc un tat RELATED qui est identifi. Les rgles suivantes rpondent alors au besoin :
iptables -A INPUT -p tcp --sport 1024: --dport 1024: -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --sport 1024: --dport 1024: -m state --state ESTABLISHED,RELATED -j ACCEPT