1 (07:59:57) semainetech@reunion.auf.org: willy a changé le sujet pour: ☞ Le salon de la Semaine Tech ☜
2 Atelier "Iptables"
3 https://wiki.auf.org/wikiteki/Projet/SemaineTech/Ateliers/Iptables
4 (08:03:33) willy: --------------- DEBUT ATELIER : iptables --------------------------
5 (08:03:38) willy: bonjour, bonsoir
6 (08:03:59) willy: nous allons commencer sans les présentateurs :( mais en espérant qu'ils seront là rapidement
7 (08:04:16) willy:
8 je vous invite à ouvrir la page du premier atelier https://wiki.auf.org/wikiteki/Projet/SemaineTech/Ateliers/Iptables
9 (08:04:46) willy: en gros vous devez avoir les schémas de vos réseaux, de préférence des fichiers texte
10 (08:05:12) willy: connaitre l'ensemble des services que vous desservez (normal :) )
11 (08:05:22) willy: un poste sous squeeze
12 (08:05:53) willy: les outils qui seront manipulés: iptables, iptraf et tcpdump
13 (08:06:26) willy:
14 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
15 (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
16 (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
17 (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
18 (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
19 (08:18:25) progfou: donc, est-ce qu'il y a des questions sur les schémas déjà ?
20 (08:19:03) willy:
21 alexandre.domont: PETIT QUESTION : Est ce que Netfilter fonctionne de la même façon en IPV4 et en IPV6 ?
22 (08:19:17) progfou: oui, aux différences de protocole près
23 (08:19:24) progfou: c'est à dire que les commandes seront les mêmes
24 (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
25 (08:20:05) progfou: sinon les commandes et les paramètres sont quasi identiques
26 (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
27 (08:20:55) progfou: et ça veut aussi dire qu'on doit faire tous nos filtrages en double
28 (08:23:00) progfou: pas d'autre question ?
29 (08:23:14) willy:
30 alexandre.domont: QUESTION : Peux tu donner un exemple de "Local Process" et un exemple de "Forward Process" ?
31 (08:23:34) progfou: ok, ça tombe bien car c'est exactement ce qu'il faut expliquer ensuite :)
32 (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
33 (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
34 (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
35 (08:25:54) progfou: la distinction est importante
36 (08:26:36) progfou: quand on écrit : iptables -A INPUT -p tcp --dport 80 -j ACCEPT
37 on dit qu'on ouvre le port http en entrée sur la machine _locale_
38 (08:27:13) progfou: tandis que quand on écrit : iptables -A FORWARD -p tcp --dport 80 -j ACCEPT
39 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)
40 (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
41 (08:28:26) progfou: donc 2 cas à considérer : gestion local ou traversée
42 (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
43 (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
44 (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 :)
45 (08:31:19) progfou: alexandre.domont: QUESTION : Peut-on créer d'autres tables et dans quel but est ce utile ?
46 (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)
47 (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
48 (08:32:41) progfou: il y a 4 catégories, séparées dans netfilter en 4 tables : filter, nat, mangle et raw
49 (08:32:48) progfou: je vais les passer rapidement en revue une par une
50 (08:33:13) progfou: filter est la plus classique, celle que nous utilisons le plus souvent : elle sert à faire les filtrages sur les paquets
51 (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)
52 (08:34:15) progfou: le filtrage se fait aux 3 étapes principales : INPUT, OUTPUT et FORWARD
53 (08:34:39) progfou: normalement l'essentiel de vos règles concerneront cette table
54 (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
55 (08:35:09) progfou: ensuite, pour les autres tables, on commence à entrer dans les bidouilles...
56 (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)
57 (08:36:08) progfou: cette bidouille n'a été inventée que pour une seule raison : le manque d'adresses IP disponibles en IPv4
58 (08:36:25) progfou: c'est aussi la raison pour laquelle elle disparaît avec IPv6 (car on n'en manquera plus)
59 (08:36:52) progfou: toutes les docs qui vous disent que c'est pour protéger des machines, les cacher, etc, vous _mentent_ !
60 (08:37:11) progfou: protéger les machines ça se fait avec des filtrages, pas avec du NAT
61 (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
62 (08:38:22) progfou: on appelle ça le masquage d'adresse IP
63 (08:38:32) progfou: il existe 2 techniques avec netfilter : MASQUERADE ou SNAT
64 (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)
65 (08:39:23) progfou: tandis que le SNAT sera utilisé quand l'adresse IP routable est fixe
66 (08:39:42) progfou: la différence se situe au niveau des timeout de conservation de la liste des connexions en cours
67 (08:40:05) progfou: (ou en bon français, au niveau des délais d'expiration de la liste des connexions en cours)
68 (08:40:17) progfou: un exemple d'utilisation :
69 (08:40:29) progfou: iptables -t nat -o ppp0 -j MASQUERADE
70 (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)
71 (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
72 (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 :
73 (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
74 (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
75 (08:43:46) progfou: (j'ai mis un autre serveur, en 192.168.1.11 pour les courriels)
76 (08:44:00) progfou: j'explique un peu cette règle :
77 (08:46:04) progfou: iptables => on va gérer les netfilter en IPv4
78 -t nat => on s'occupe des altérations d'adresses IP
79 -A PREROUTING => ça se passe au moment de l'arrivée sur cette passerelle
80 ! -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 '!'
81 -p tcp => quand c'est une connexion TCP
82 -m multiport => on va utiliser ce module pour gérer plusieurs ports en une seule règle
83 --dports
84 -j DNAT => on va changer l'adresse de destination
85 --to-destination
86 (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 :
87 iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
88 (08:47:26) progfou: je passe vite fait sur mangle et raw avant les questions
89 (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
90 (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)
91 (08:48:50) progfou: des questions ?
92 (08:49:53) willy:
93 alexandre.domont: QUESTION : Peut-on créer des chaines personnalisées ?
94 (08:50:10) progfou: oui
95 (08:50:12) progfou: donc
96 (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
97 (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 !
98 (08:52:28) progfou: pour nous aider dans cette gestion, on a la possibilité de créer des chaînes de règles
99 (08:52:58) willy:
100 alexandre.domont: QUESTION : y-a-i-il un ordre à respecter pour déclarer les chaines ?
101 (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
102 (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)
103 (08:54:00) progfou: la seule contrainte pour déclarer ces chaînes est de le faire avant de les utiliser
104 (08:54:10) progfou: un exemple concret :
105 (08:54:32) progfou: on a un pare-feu qui gère 2 réseaux locaux, une DMZ et l'accès Internet
106 (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 ? ;-) )
107 (08:55:31) ***willy
108 (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
109 (08:55:44) progfou: (je termine vite-fait d'abord)
110 (08:57:06) progfou: donc on va créer les chaînes suivantes :
111 internet-dmz, internet-admin, internet-public, (les arrivées depuis Internet)
112 dmz-internet, dmz-admin, dmz-public, (les sorties des serveurs)
113 admin-internet, admin-dmz, admin-public, (les sorties depuis admin)
114 public-internet, public-dmz, public-admin
115 (08:57:18) progfou: alors évidement vous allez me dire que c'est dingue d'en créer autant...
116 (08:57:34) progfou: mais on ne va le faire qu'une seule fois !
117 (08:57:46) progfou: et dans chacune de ces chaînes la gestion sera très simple
118 (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
119 (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
120 (08:59:52) progfou: plutôt iptables -A internet-admin -j DROP (et même chose pour internet-public)
121 (09:00:04) progfou: ensuite comment on utiliserait ces règles ? c'est simple
122 (09:00:21) progfou: dans FORWARD, on va indiquer à quel moment on va sauter vers quelle règle
123 (09:00:35) progfou: ou plutôt vers quelle chaîne
124 (09:01:38) progfou: par exemple :
125 iptables -A FORWARD -i ppp0 -o eth0 -j internet-dmz
126 iptables -A FORWARD -i ppp0 -o eth1 -j internet-admin
127 iptables -A FORWARD -i ppp0 -o eth2 -j internet-public
128 iptables -A FORWARD -i eth0 -o ppp0 -j dmz-internet
129 iptables -A FORWARD -i eth0 -o eth1 -j dmz-admin
130 ...
131 etc
132 (09:01:41) progfou: questions ?
133 (09:02:00) willy:
134 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?
135 (09:02:55) progfou: la gestion des filtrages réseau nécessite bien sûr de comprendre le fonctionnement des connexions réseau
136 (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)
137 (09:03:43) progfou: il y a quelques protocoles pour lesquels c'est un peu particulier, comme FTP
138 (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
139 (09:04:22) progfou: toute la difficulté est d'ouvrir dynamiquement ce port de données
140 (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
141 (09:05:46) progfou: pour cela on doit ajouter une règle spéciale, au tout début de nos règles de filtrage :
142 iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
143 (09:06:05) progfou: c'est le RELATED ici qui veut dire : les connexions en relation avec celles déjà autorisées
144 (09:06:11) progfou: autre question ?
145 (09:06:21) progfou: (on dépasse déjà l'horaire là non ?)
146 (09:06:24) willy: QUESTION : moi j'ai pas encore bien compris ce qu'est une DMZ (zone démultarisée)
147 (09:06:25) willy: oui :)
148 (09:06:59) progfou: mets ta réponse et la réaction de Claudine aussi stp
149 (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) "
150 (09:07:20) willy:
151 claudine.mosozi: QUESTION : ok, donc obligatoirement ces serveurs doivent avoir des adresses publiques?
152 (09:07:36) progfou: pour la notion de DMZ, je vous renvoie sur wikipedia qui explique l'idée de DMZ
153 (09:08:00) progfou: en gros c'est une zone entre deux frontières
154 (09:08:12) progfou: les serveurs se trouvent entre l'Internet et les réseaux locaux
155 (09:08:29) progfou: il n'y a aucune obligation que cette DMZ soit en adresses IP routables (aussi appelées publiques)
156 (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
157 (09:09:17) progfou: (c'est un exemple classique, une recommandation, pas une obligation technique)
158 (09:09:30) progfou: et on devra alors faire du SNAT et DNAT pour les serveurs
159 (09:09:35) progfou: autre question ?
160 (09:09:53) willy: pas d'autres pour le moment :)
161 (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 ;-)
162 (09:10:33) willy: ah si.. une que j'ai sautée
163 (09:10:34) willy:
164 alexandre.domont: QUESTION : Peut-on créer des chaines personnalisées ?
165 (09:10:49) willy: mais on y a répondu ....
166 (09:11:12) progfou: créer une chaîne : iptables -N internet-dmz
167 (09:11:31) progfou: c'est bien sûr à faire avant de commencer à faire des iptables -A internet-dmz
168 (09:12:23) progfou: bon, dernière question de Claudine
169 (09:12:35) willy:
170 claudine.mosozi: QUESTION : quand met au début du script des activation de modules comme : modprobe ip_tables
171 modprobe iptable_filter
172 modprobe iptable_nat
173 modprobe ip_conntrack_ftp
174 à quoi ça aide? est-ce que les module par ex. iptable_nat, iptable_conntrack ne sont pas actifs par défaut?
175 (09:13:01) progfou: normalement avec Debian on ne met pas ça dans le script mais dans /etc/modules
176 (09:13:12) progfou: et plusieurs dans cette liste sont chargés automatiquement
177 (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)
178 (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)
179 (09:14:59) progfou: ___FIN___
180 (09:15:12) willy: --------------- FIN ATELIER : iptables --------------------------