## page was renamed from Projet/SemaineTech2011/Ateliers/Iptables/Conversation
## page was renamed from Projet/SemaineTech/Ateliers/Iptables/Conversation
{{{#!highlight irc
(07:59:57) semainetech@reunion.auf.org: willy a changé le sujet pour: ☞ Le salon de la Semaine Tech ☜
Atelier "Iptables"
https://wiki.auf.org/wikiteki/Projet/SemaineTech/Ateliers/Iptables
(08:03:33) willy: --------------- DEBUT ATELIER : iptables --------------------------
(08:03:38) willy: bonjour, bonsoir
(08:03:59) willy: nous allons commencer sans les présentateurs :( mais en espérant qu'ils seront là rapidement
(08:04:16) willy: 
je vous invite à ouvrir la page du premier atelier https://wiki.auf.org/wikiteki/Projet/SemaineTech/Ateliers/Iptables
(08:04:46) willy: en gros vous devez avoir les schémas de vos réseaux, de préférence des fichiers texte
(08:05:12) willy: connaitre l'ensemble des services que vous desservez (normal :) )
(08:05:22) willy: un poste sous squeeze
(08:05:53) willy: les outils qui seront manipulés: iptables, iptraf et tcpdump
(08:06:26) willy: 
j'accorde à chacun quelques minutes de lecture de la page en question et aussi de celle-ci http://wiki.auf.org/wikiteki/ZAO/Projets/DocumentationFW
(08:07:07) willy: qui est une sorte de synthèse du manuel de iptables vu par Franck Kouyami, l'un des présentateurs du jour
(08:10:01) progfou: quand on « joue » avec les netfilter (le vrai nom, iptables n'est qu'une commande pour les configurer), je recommande de toujours garder en tête la circulation des paquets dans ces filtrages, éventuellement avec un schéma de ce type : http://upload.wikimedia.org/wikipedia/fr/3/3e/Netfilter_schema.png
(08:10:49) progfou: ou encore celui-ci, pour une vision plus linéaire des choses : http://www.ironflake.org/wp-content/uploads/2011/02/Linux_IptablesSchema.png
(08:13:22) progfou: netfilter (iptables, ip6tables, ebtables, ...) n'est pas vraiment compliqué à comprendre en soi, tout est dans la compréhension des étapes indiquées dans le schéma
(08:18:25) progfou: donc, est-ce qu'il y a des questions sur les schémas déjà ?
(08:19:03) willy: 
alexandre.domont: PETIT QUESTION : Est ce que Netfilter fonctionne de la même façon en IPV4 et en IPV6 ?
(08:19:17) progfou: oui, aux différences de protocole près
(08:19:24) progfou: c'est à dire que les commandes seront les mêmes
(08:19:42) progfou: mais, par exemple, il n'y a pas de table NAT avec ip6tables car il n'existe pas de NAT en IPv6
(08:20:05) progfou: sinon les commandes et les paramètres sont quasi identiques
(08:20:42) progfou: sauf bien sûr que pour la gestion des paquets IPv4 on utilise iptables et pour la gestion des paquets IPv6 on utilise ip6tables
(08:20:55) progfou: et ça veut aussi dire qu'on doit faire tous nos filtrages en double
(08:23:00) progfou: pas d'autre question ?
(08:23:14) willy: 
alexandre.domont: QUESTION : Peux tu donner un exemple de "Local Process" et un exemple de "Forward Process" ?
(08:23:34) progfou: ok, ça tombe bien car c'est exactement ce qu'il faut expliquer ensuite :)
(08:24:18) progfou: il faut distinguer les filtrages que l'on fait pour protéger la machine sur laquelle on se trouve, de ceux que l'on fait pour protéger un ou des réseaux derrière cette machine
(08:25:04) progfou: quand on veut protéger la machine sur laquelle on se trouve, on va s'occuper uniquement des entrées (INPUT) et des sorties (OUTPUT) de paquets
(08:25:46) progfou: tandis que quand on veut protéger un réseau derrière la machine actuelle, on va s'occuper surtout des traversées (FORWARD) de paquets
(08:25:54) progfou: la distinction est importante
(08:26:36) progfou: quand on écrit : iptables -A INPUT -p tcp --dport 80 -j ACCEPT
on dit qu'on ouvre le port http en entrée sur la machine _locale_
(08:27:13) progfou: tandis que quand on écrit : iptables -A FORWARD -p tcp --dport 80 -j ACCEPT
on dit qu'on ouvre le port http en traversée de la machine _locale_ pour aller joindre une machine derrière (on ne précise pas laquelle ici)
(08:27:52) progfou: et quand on veut être très sérieux niveau filtrage on va aussi filtrer les tentatives de sortie de la machine locale avec : iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
(08:28:26) progfou: donc 2 cas à considérer : gestion local ou traversée
(08:29:19) progfou: la définition d'une gestion locale est que l'une des adresses (source ou destination) est sur l'une des interfaces de la machine locale => le paquet part ou s'arrête ici
(08:29:47) progfou: la définition de la traversée est que le paquet arrive par une interface réseau pour ressortir par une autre, sans s'arrêter sur cette machine
(08:30:25) progfou: une fois qu'on a bien compris cette différence, on a déjà compris la moitié de la théorie :)
(08:31:19) progfou: alexandre.domont: QUESTION : Peut-on créer d'autres tables et dans quel but est ce utile ?
(08:31:45) progfou: il y a 4 tables (je vais expliquer lesquelles) et on ne peut pas créer d'autre (on crée des chaînes de règles)
(08:32:11) progfou: donc, la seconde partie de la théorie concerne les types de traitements que l'ont peut faire sur les paquets
(08:32:41) progfou: il y a 4 catégories, séparées dans netfilter en 4 tables : filter, nat, mangle et raw
(08:32:48) progfou: je vais les passer rapidement en revue une par une
(08:33:13) progfou: filter est la plus classique, celle que nous utilisons le plus souvent : elle sert à faire les filtrages sur les paquets
(08:33:44) progfou: on y indique si on laisse passer (ACCEPT), si on refuse (REJECT) ou si on jette le paquet sans le dire (DROP)
(08:34:15) progfou: le filtrage se fait aux 3 étapes principales : INPUT, OUTPUT et FORWARD
(08:34:39) progfou: normalement l'essentiel de vos règles concerneront cette table
(08:34:54) progfou: on l'indique avec le paramètre -t filter, mais vu que c'est la table par défaut il est optionnel
(08:35:09) progfou: ensuite, pour les autres tables, on commence à entrer dans les bidouilles...
(08:35:41) progfou: pour commencer, les bidouilles "tolérées", voir même communément acceptées, hélas : la translation d'adresses (NAT)
(08:36:08) progfou: cette bidouille n'a été inventée que pour une seule raison : le manque d'adresses IP disponibles en IPv4
(08:36:25) progfou: c'est aussi la raison pour laquelle elle disparaît avec IPv6 (car on n'en manquera plus)
(08:36:52) progfou: toutes les docs qui vous disent que c'est pour protéger des machines, les cacher, etc, vous _mentent_ !
(08:37:11) progfou: protéger les machines ça se fait avec des filtrages, pas avec du NAT
(08:38:06) progfou: donc le 1er usage du NAT est de permettre à des tas de machines sans adresse IP routable d'accéder quand même à Internet, en utilisant l'adresse IP routable d'une passerelle elle reliée directement à Internet
(08:38:22) progfou: on appelle ça le masquage d'adresse IP
(08:38:32) progfou: il existe 2 techniques avec netfilter : MASQUERADE ou SNAT
(08:39:12) progfou: le MASQUERADE est utilisé quand il s'agit d'une adresse routable temporaire (typiquement les adresses dynamiques données par les liaison modem comme ADSL)
(08:39:23) progfou: tandis que le SNAT sera utilisé quand l'adresse IP routable est fixe
(08:39:42) progfou: la différence se situe au niveau des timeout de conservation de la liste des connexions en cours
(08:40:05) progfou: (ou en bon français, au niveau des délais d'expiration de la liste des connexions en cours)
(08:40:17) progfou: un exemple d'utilisation :
(08:40:29) progfou: iptables -t nat -o ppp0 -j MASQUERADE
(08:40:55) progfou: cette simple règle suffit à permettre à tout un réseau de machines derrière celle en cours à accéder à Internet via une liaison PPP(oE)
(08:41:42) progfou: le deuxième usage du NAT est dans l'autre sens : quand on veut renvoyer un accès venant de l'extérieur vers des adresses internes, là aussi faute d'avoir suffisamment d'adresses externes (routables) disponibles
(08:42:33) progfou: typiquement, quand on a un serveur pour HTTP/HTTPS et un autre serveur pour SMTP/Submision/IMAPS, qu'on va supposer ici sur l'adresse IP 192.168.1.10, on va faire 2 règles telles que :
(08:43:15) progfou: iptables -t nat -A PREROUTING ! -i ppp0 -p tcp -m multiport --dports 80,443 -j DNAT --to-destination 192.168.1.10
(08:43:35) progfou: iptables -t nat -A PREROUTING ! -i ppp0 -p tcp -m multiport --dports 25,587,993 -j DNAT --to-destination 192.168.1.11
(08:43:46) progfou: (j'ai mis un autre serveur, en 192.168.1.11 pour les courriels)
(08:44:00) progfou: j'explique un peu cette règle :
(08:46:04) progfou: iptables => on va gérer les netfilter en IPv4
-t nat => on s'occupe des altérations d'adresses IP
-A PREROUTING => ça se passe au moment de l'arrivée sur cette passerelle
! -i ppp0 => on ne gère que le cas où ça ne vient pas d'Internet => là j'ai fait une erreur, il faut mettre -i ppp0 sans le '!'
-p tcp => quand c'est une connexion TCP
-m multiport => on va utiliser ce module pour gérer plusieurs ports en une seule règle
--dports 25,587,993 => la liste des ports TCP concernés
-j DNAT => on va changer l'adresse de destination
--to-destination 192.168.1.11 => on va sur le même port que celui demandé, mais sur cette machine
(08:47:03) progfou: j'ai aussi fait un petit oubli tout à l'heure pour le masquage, ça se met dans la chaîne concernant la sortie des paquets :
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
(08:47:26) progfou: je passe vite fait sur mangle et raw avant les questions
(08:48:09) progfou: mangle est une table servant à aller encore plus loin dans la bidouille en modifiant les informations directement au niveau contenu du paquet
(08:48:36) progfou: tandis que raw est le niveau de bidouille le pire : on peut carrément modifier la façon dont netfilter gère les paquets (et même passer outre)
(08:48:50) progfou: des questions ?
(08:49:53) willy: 
alexandre.domont: QUESTION : Peut-on créer des chaines personnalisées ?
(08:50:10) progfou: oui
(08:50:12) progfou: donc
(08:50:51) progfou: quand on gère ses filtrages sur une petite machine ou pour un petit réseau, on peut se contenter de faire une liste de règles tout d'un bout sans trop les classer, ça passe encore
(08:52:07) progfou: mais quand on commence à gérer un hôte de serveurs virtuels, donc avec des règles pour l'hôte et d'autres pour chaque serveur virtuel dessus, ou encore un pare-feu pour plusieurs réseaux derrière, dont une DMZ (réseau dédié à des serveurs servant à la fois l'Internet et les réseaux locaux), ça devient vite difficile de s'y retrouver !
(08:52:28) progfou: pour nous aider dans cette gestion, on a la possibilité de créer des chaînes de règles
(08:52:58) willy: 
alexandre.domont: QUESTION : y-a-i-il un ordre à respecter pour déclarer les chaines ?
(08:53:02) progfou: une chaîne de règle n'est rien d'autre qu'une suite de règles exécutées l'une après l'autre
(08:53:33) progfou: ensuite, on fera appel à ces chaîne dans les chaînes principales (qui sont par exemple INPUT, OUTPUT, FORWARD pour la table filter)
(08:54:00) progfou: la seule contrainte pour déclarer ces chaînes est de le faire avant de les utiliser
(08:54:10) progfou: un exemple concret :
(08:54:32) progfou: on a un pare-feu qui gère 2 réseaux locaux, une DMZ et l'accès Internet
(08:55:09) progfou: on peut considérer qu'on a donc 4 zones réseau : l'Internet, la DMZ, le réseau admin et le réseau public (ça vous dit quelque chose ? ;-) )
(08:55:31) ***willy a une question en attente
(08:55:34) progfou: une bonne façon de gérer les choses proprement est de faire des chaînes pour chaque flux réseau possible
(08:55:44) progfou: (je termine vite-fait d'abord)
(08:57:06) progfou: donc on va créer les chaînes suivantes :
internet-dmz, internet-admin, internet-public, (les arrivées depuis Internet)
dmz-internet, dmz-admin, dmz-public, (les sorties des serveurs)
admin-internet, admin-dmz, admin-public, (les sorties depuis admin)
public-internet, public-dmz, public-admin
(08:57:18) progfou: alors évidement vous allez me dire que c'est dingue d'en créer autant...
(08:57:34) progfou: mais on ne va le faire qu'une seule fois !
(08:57:46) progfou: et dans chacune de ces chaînes la gestion sera très simple
(08:58:10) progfou: par exemple, pour la chaîne internet-dmz, on va y mettre toutes les règles d'accès aux services sur les serveurs
(08:59:27) progfou: tandis que pour les chaînes internet-admin et internet-public la on ne mettra qu'une seule règle : iptables -j DROP
(08:59:52) progfou: plutôt iptables -A internet-admin -j DROP (et même chose pour internet-public)
(09:00:04) progfou: ensuite comment on utiliserait ces règles ? c'est simple
(09:00:21) progfou: dans FORWARD, on va indiquer à quel moment on va sauter vers quelle règle
(09:00:35) progfou: ou plutôt vers quelle chaîne
(09:01:38) progfou: par exemple :
iptables -A FORWARD -i ppp0 -o eth0 -j internet-dmz
iptables -A FORWARD -i ppp0 -o eth1 -j internet-admin
iptables -A FORWARD -i ppp0 -o eth2 -j internet-public
iptables -A FORWARD -i eth0 -o ppp0 -j dmz-internet
iptables -A FORWARD -i eth0 -o eth1 -j dmz-admin
...
etc
(09:01:41) progfou: questions ?
(09:02:00) willy: 
chanesakhone.chitsaya: : QUESTION: Quand on fait ensembles des règles sous un script par ex: firewall.sh, dans ce script on a mis tous les services de dans HTTP, FTP, SSH, SMTP, IMAP, etc..,  s'il y a eu quelque service qui ne peut pas sortir extérieur par ex: FTP de port 21, quelle commande pour vérifier qu'il a bloqué où? comment résoudre?
(09:02:55) progfou: la gestion des filtrages réseau nécessite bien sûr de comprendre le fonctionnement des connexions réseau
(09:03:28) progfou: pour étudier un problème de connexion, une fois les filtrages mis en place, le plus simple est de vérifier ce qui circule sur la passerelle, typiquement avec l'outil tcpdump (ou tshark)
(09:03:43) progfou: il y a quelques protocoles pour lesquels c'est un peu particulier, comme FTP
(09:04:09) progfou: ce protocole supporte mal le NAT car il utilise plusieurs ports, le 21 pour les commandes, et un port dynamique pour le transfert des données
(09:04:22) progfou: toute la difficulté est d'ouvrir dynamiquement ce port de données
(09:05:09) progfou: heureusement le protocole FTP est un standard ouvert et bien connu et il existe un module noyau (ip_nat_ftp) qui aide à gérer ce problème en analysant la demande de connexion et en trouvant et ouvrant le port dynamique
(09:05:46) progfou: pour cela on doit ajouter une règle spéciale, au tout début de nos règles de filtrage :
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
(09:06:05) progfou: c'est le RELATED ici qui veut dire : les connexions en relation avec celles déjà autorisées
(09:06:11) progfou: autre question ?
(09:06:21) progfou: (on dépasse déjà l'horaire là non ?)
(09:06:24) willy: QUESTION : moi j'ai pas encore bien compris ce qu'est une DMZ (zone démultarisée)
(09:06:25) willy: oui :)
(09:06:59) progfou: mets ta réponse et la réaction de Claudine aussi stp
(09:07:12) willy: claudine.mosozi:  jc l'a dit tout à l'heure; je reprends ici : "DMZ (réseau dédié à des serveurs servant à la fois l'Internet et les réseaux locaux) "
(09:07:20) willy: 
claudine.mosozi: QUESTION : ok, donc obligatoirement ces serveurs doivent avoir des adresses publiques?
(09:07:36) progfou: pour la notion de DMZ, je vous renvoie sur wikipedia qui explique l'idée de DMZ
(09:08:00) progfou: en gros c'est une zone entre deux frontières
(09:08:12) progfou: les serveurs se trouvent entre l'Internet et les réseaux locaux
(09:08:29) progfou: il n'y a aucune obligation que cette DMZ soit en adresses IP routables (aussi appelées publiques)
(09:09:00) progfou: classiquement, quand on ne dispose que d'une seule adresse IP sur la liaison Internet, on mettra la DMZ en 192.168.0.0/24
(09:09:17) progfou: (c'est un exemple classique, une recommandation, pas une obligation technique)
(09:09:30) progfou: et on devra alors faire du SNAT et DNAT pour les serveurs
(09:09:35) progfou: autre question ?
(09:09:53) willy: pas d'autres pour le moment :)
(09:10:21) progfou: ok, donc on passe à l'atelier suivant, et pour plus d'infos sur ce sujet vous reviendrez demander dans le salon tech ;-)
(09:10:33) willy: ah si.. une que j'ai sautée
(09:10:34) willy: 
alexandre.domont: QUESTION : Peut-on créer des chaines personnalisées ?
(09:10:49) willy: mais on y a répondu ....
(09:11:12) progfou: créer une chaîne : iptables -N internet-dmz
(09:11:31) progfou: c'est  bien sûr à faire avant de commencer à faire des iptables -A internet-dmz
(09:12:23) progfou: bon, dernière question de Claudine
(09:12:35) willy: 
claudine.mosozi: QUESTION : quand met au début du script des activation de modules comme : modprobe ip_tables
modprobe iptable_filter
modprobe iptable_nat
modprobe ip_conntrack_ftp
à quoi ça aide? est-ce que les module par ex. iptable_nat, iptable_conntrack ne sont pas actifs par défaut?
(09:13:01) progfou: normalement avec Debian on ne met pas ça dans le script mais dans /etc/modules
(09:13:12) progfou: et plusieurs dans cette liste sont chargés automatiquement
(09:14:09) progfou: seul ip_nat_ftp, ip_nat_irc, ip_nat_h323, ip_nat_sip pourraient être mis dans /etc/modules, le reste est chargé automatiquement par dépendances inter-modules (ip_nat_ftp dépend de ip_conntrack_ftp qui dépend de iptables_nat)
(09:14:55) progfou: (ou plutôt ip_nat_ftp dépend de iptables_nat et ip_conntrack_ftp qui dépendent lui de ip_conntrack)
(09:14:59) progfou: ___FIN___
(09:15:12) willy: --------------- FIN ATELIER : iptables --------------------------
}}}