L'internet rapide et permanent

Outils pour utilisateurs

Outils du site

Vous êtes ici : L'internet rapide et permanent » Netfilter, Iptables, Nftables » IPtables

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision		Révision précédente
130netfilter:20-iptables [le 31/03/2025 à 12:43] – [Concernant la délégation 2a01:e0a:875:b1d2::/64] prof130netfilter:20-iptables [le 04/04/2025 à 07:00] (Version actuelle) – [Synthèse] prof
Ligne 65: Ligne 65:
   ip6tables -A INPUT -i enp1s0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT   ip6tables -A INPUT -i enp1s0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
 Cependant, il faut ajouter icmp pour les annonces et découvertes des voisins, aussi bien du côté orange que du côté vert: Cependant, il faut ajouter icmp pour les annonces et découvertes des voisins, aussi bien du côté orange que du côté vert:
-  ip6tables -A INPUT -p icmp -j ACCEPT+  ip6tables -A INPUT -p ipv6-icmp -j ACCEPT
 En ce qui concerne les adresses de lien local, nous n'allons pas être paranoïaques au point de suspecter l'entourage immédiat du serveur: En ce qui concerne les adresses de lien local, nous n'allons pas être paranoïaques au point de suspecter l'entourage immédiat du serveur:
   ip6tables -A INPUT -s fe80::/64 -j ACCEPT   ip6tables -A INPUT -s fe80::/64 -j ACCEPT
Ligne 80: Ligne 80:
   ip6tables -A FORWARD -i enp1s0 -m conntrack --ctstate NEW -j REJECT   ip6tables -A FORWARD -i enp1s0 -m conntrack --ctstate NEW -j REJECT
   ip6tables -A FORWARD -i enp1s0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT   ip6tables -A FORWARD -i enp1s0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-Ainsi comme pour IPv4 seules les connexions initiées depuis l'intérieur de la délégation ouvriront le pare-feu pour laisser passer les réponses, mais il faut également penser à bloquer les nouvelles explicitement+Ainsi comme pour IPv4 seules les connexions initiées depuis l'intérieur de la délégation ouvriront le pare-feu pour laisser passer les réponses.
  
 Ici en revanche, il n'est pas nécessaire de faire du marquage d'adresse puisque les adresses lien-global IPv6 dans la délégation sont routables et que le routeur de la Freebox sait y accéder. Ici en revanche, il n'est pas nécessaire de faire du marquage d'adresse puisque les adresses lien-global IPv6 dans la délégation sont routables et que le routeur de la Freebox sait y accéder.
  
 Il n'y a à priori plus rien à faire en fonction du cahier des charges initial Il n'y a à priori plus rien à faire en fonction du cahier des charges initial
-===== Synthèse ===== +===== Vérifications ===== 
-Nous venons de voir les règles les plus souvent utilisées. Nous en verrons d'autres exemples plus loin. Reste à savoir si ça fonctionne bien comme prévu.+==== Pour IPv4 ====
  
-Un client d'adresse 192.168.61.101 fait un ping sur 194.177.211.216 (www.debian.org)+Lors du démarrage d'un client du LAN vert, Nous pouvons vérifier sa configuration IPv4: 
 +<html><pre class="code"> 
 +<b>ip -4 addr</b> 
 +1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 
 +    inet 127.0.0.1/8 scope host lo 
 +       valid_lft forever preferred_lft forever 
 +2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 
 +    inet <span class="bhly">192.168.61.102/24 brd 192.168.61.255 scope global dynamic enp1s0</span> 
 +       valid_lft 2799sec preferred_lft 2799sec 
 + 
 +<b>ip -4 route </b> 
 +<span class="bhly">default via 192.168.61.1 dev enp1s0 </span> 
 +192.168.61.0/24 dev enp1s0 proto kernel scope link src 192.168.61.102  
 +</pre></html> 
 +La configuration est correcte, preuve que le dialogue avec DHCP se passe bien. 
 +<html><pre class="code"> 
 +<b>host www.debian.org 192.168.61.1</b> 
 + 
 +<span class="hly">Using domain server: 
 +<b>Name: 192.168.61.1</b> 
 +Address: 192.168.61.1#53</span> 
 +Aliases:  
 + 
 +<span class="bhly">www.debian.org has address 194.177.211.216 
 +www.debian.org has address 130.89.148.77 
 +www.debian.org has IPv6 address 2001:648:2ffc:deb:216:61ff:fe2b:6138 
 +www.debian.org has IPv6 address 2001:67c:2564:a119::77</span> 
 +</pre></html> 
 + 
 +Le client peut interroger le DNS 192.168.61.1 et recevoir la réponse. 
 +<html><pre class="code"> 
 +<b>telnet 192.168.61.1</b> 
 +Trying 192.168.61.1... 
 +... 
 +<span class="bhly">telnet: Unable to connect to remote host: Connexion terminée par expiration du délai d'attente</span> 
 +</pre></html> 
 +Car la cible DROP réagit ainsi: Elle jette le paquet dans un puits sans fond, sans renvoyer de notification à la source. Telnet n'est donc pas accessible à cette station. 
 + 
 +Un client d'adresse 192.168.61.101 fait un ping sur 194.177.211.216
 <html><pre class="code"> <html><pre class="code">
 <b>ping -c1 194.177.211.216</b> <b>ping -c1 194.177.211.216</b>
Ligne 99: Ligne 137:
 rtt min/avg/max/mdev = 65.622/65.622/65.622/0.000 ms rtt min/avg/max/mdev = 65.622/65.622/65.622/0.000 ms
 </pre></html> </pre></html>
-Donc le routage masqué fonctionne et les clients verts (192.168.61.0/24) accèdent bien à l'internet.+Le routage masqué fonctionne et les clients verts accèdent bien à l'internet. 
 + 
 +Pour tester la solidité du serveur depuis l'extérieur, c'est-à-dire depuis le LAN orange, nous n'allons pas prendre des gants, mais plutôt l'outil «Nmap» **__Qui ne doit JAMAIS être utilisé en dehors des réseaux dont on a la charge!!!__** C'est un outil de vérification à l'usage des administrateurs de réseaux. 
 + 
 +Voici le résultat: 
 +<html><pre class="code"> 
 +<b>nmap -sT -sU 192.168.60.200</b> 
 + 
 +Starting Nmap 7.93 ( https://nmap.org ) at 2025-03-31 15:14 CEST 
 +Nmap scan report for 192.168.60.200 
 +Host is up (0.00017s latency). 
 +<span class="hly">All 2000 scanned ports on 192.168.60.200 are in ignored states.</span> 
 +<span class="bhlo">Not shown: 1000 filtered tcp ports (no-response), 1000 open|filtered udp ports (no-response)</span> 
 +MAC Address: 52:54:00:74:45:F2 (QEMU virtual NIC) 
 + 
 +Nmap done: 1 IP address (1 host up) scanned in 42.29 seconds 
 +</pre></html> 
 +Nmap n'a rien trouvé d'ouvert, ni en TCP ni en UDP. Réconfortant. 
 + 
 +==== Et pour IPv6 ==== 
 + 
 +<html><pre class="code"> 
 +<b>ip -6 addr ls</b> 
 +1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000 
 +    inet6 ::1/128 scope host noprefixroute  
 +       valid_lft forever preferred_lft forever 
 +2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000 
 +    inet6 <span class="bhly">2a01:e0a:875:b1d2:5054:ff:feb7:6681/64 scope global</span> dynamic mngtmpaddr  
 +       valid_lft 86379sec preferred_lft 14379sec 
 +    inet6 <span class="bhly">fe80::5054:ff:feb7:6681/64 scope link</span> 
 +       valid_lft forever preferred_lft forever 
 +        
 +<b>ip -6 route ls</b> 
 +2a01:e0a:875:b1d2::/64 dev enp1s0 proto kernel metric 256 expires 86371sec pref medium 
 +fe80::/64 dev enp1s0 proto kernel metric 256 pref medium 
 +<span class="bhly">default via fe80::5054:ff:fe78:2d7e dev enp1s0</span> proto ra metric 1024 expires 151sec hoplimit 64 pref medium 
 +</pre></html> 
 +Les adresses sont correctes, la route par défaut est correcte aussi. 
 + 
 +Depuis la station dans le LAN vert il faut vérifier qu'une nouvelle connexion IPv6 peut en sortir et que les réponses peuvent entrer en chargeant par exemple la page html par défaut de [2001:41d0:305:2100::2cd5]: 
 +<html><pre class="code"> 
 +<b>wget http://[2001:41d0:305:2100::2cd5]/index.html</b> 
 + 
 +--2025-03-31 18:54:54--http://[2001:41d0:305:2100::2cd5]/index.html 
 +Connexion à [2001:41d0:305:2100::2cd5]:80… connecté. 
 +requête HTTP transmise, en attente de la réponse… 200 OK 
 +Taille : 16 [text/html] 
 +Sauvegarde en : « index.html » 
 + 
 +index.html                       100%[==========================================================>]      16  --.-KB/s    ds 0s       
 + 
 +<span class="bhly">2025-03-31 18:54:54 (682 KB/s) — « index.html » sauvegardé [16/16]</span> 
 +</pre></html> 
 +Tout va bien mais n'essayez pas de faire la même chose avec la même adresse. Moi je peux mais pas vous 8-) 
 + 
 + 
 +Essayons maintenant d'ouvrir une connexion ssh (port 22)  depuis justement 2001:41d0:305:2100::2cd5 vers le client 2a01:e0a:875:b1d2:5054:ff:feb7:6681:. Le serveur sshd y est bien installé pour les besoins de la manip: 
 +<html><pre class="code"> 
 +<b>netstat -lapten | grep tcp6</b> 
 + 
 +<span class="hly">tcp6       0      <b>0 :::22</b>     :::*      <b>LISTEN</b>      0   16587      <b>561/sshd: /usr/sbin</b></span> 
 +</pre></html> 
 + 
 +Le port 22 est bien ouvert à l'écoute 
 +<html><pre class="code"> 
 +<b>ssh 2a01:e0a:875:b1d2:5054:ff:feb7:6681</b> 
 + 
 +<span class="bhly">ssh: connect to host 2a01:e0a:875:b1d2:5054:ff:feb7:6681 port 22: <b>Connection refused</b></span> 
 +</pre></html> 
 +Comme c'était prévu.  
 + 
 +Enfin, nous pouvons essayer la même chose sur le serveur qui a, rappelons-le, l'adresse 2a01:e0a:875:b1d0:5054:ff:fe74:45f2 dans le LAN orange: 
 +<html><pre class="code"> 
 +<b>ssh 2a01:e0a:875:b1d0:5054:ff:fe74:45f2</b> 
 +<span class="bhly">ssh: connect to host 2a01:e0a:875:b1d0:5054:ff:fe74:45f2 port 22: Connection timed out</span> 
 +</pre></html> 
 +Ici, c'est le coup du DROP par défaut qui jette sans l’annoncer. 
 + 
 +Le contrat est donc rempli, les protections demandées sont opérationnelles. 
 +===== Synthèse ===== 
 +La syntaxe Iptables, une fois un peu rodée, devient assez facile à lire et même à écrire du moment que l'on sait exactement ce que l'on veut faire avec. 
 + 
 +Pour que ces règles persistent au prochain redémarrage, il faut penser à les sauvegarder. Le moyen le plus simple est d'installer le paquet ''iptables-persistent''. Il est également possible de créer un script reproduisant la suite de commandes et de le faire exécuter avec systemd en écrivant un script approprié dans ''/etc/systemd/system''. La première solution semble tout de même plus simple, d'autant plus que les fichiers créés dans ''/etc/iptables/rules.v*'' sont faits avec les commandes ''iptables-save'' et ''ip6tables-save''. Nous avons après toutes ces manips: 
 +<html><pre class="code"> 
 +<b>cat /etc/iptables/rules.v4</b> 
 +# Generated by iptables-save v1.8.9 (nf_tables) on Mon Mar 31 19:57:09 2025 
 +*filter 
 +:INPUT DROP [32857:1853027] 
 +:FORWARD ACCEPT [63:4124] 
 +:OUTPUT ACCEPT [17257:1075270] 
 +-A INPUT -i enp7s0 -p udp -m multiport --dports 53,67 -j ACCEPT 
 +-A INPUT -s 192.168.61.254/32 -i enp7s0 -p tcp -m tcp --dport 23 -j ACCEPT 
 +-A INPUT -i enp1s0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT 
 +-A INPUT -p icmp -j ACCEPT 
 +-A FORWARD -i enp1s0 -o enp7s0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT 
 +COMMIT 
 +# Completed on Mon Mar 31 19:57:09 2025 
 +# Generated by iptables-save v1.8.9 (nf_tables) on Mon Mar 31 19:57:09 2025 
 +*nat 
 +:PREROUTING ACCEPT [21308:1584088] 
 +:INPUT ACCEPT [95:14789] 
 +:OUTPUT ACCEPT [4298:258839] 
 +:POSTROUTING ACCEPT [4244:254640] 
 +-A POSTROUTING -o enp1s0 -j MASQUERADE 
 +COMMIT 
 +# Completed on Mon Mar 31 19:57:09 2025 
 + 
 +<b>cat /etc/iptables/rules.v6</b> 
 +# Generated by ip6tables-save v1.8.9 (nf_tables) on Mon Mar 31 19:57:26 2025 
 +*filter 
 +:INPUT DROP [17:1416] 
 +:FORWARD ACCEPT [659:68419] 
 +:OUTPUT ACCEPT [2064:215299] 
 +-A INPUT -p icmp -j ACCEPT 
 +-A INPUT -p ipv6-icmp -j ACCEPT 
 +-A INPUT -i enp1s0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT 
 +-A INPUT -s fe80::/64 -j ACCEPT 
 +-A INPUT -p udp -m udp --dport 53 -j ACCEPT 
 +-A FORWARD -i enp1s0 -m conntrack --ctstate NEW -j REJECT --reject-with icmp6-port-unreachable 
 +-A FORWARD -i enp1s0 -m conntrack --ctstate NEW -j REJECT --reject-with icmp6-port-unreachable 
 +-A FORWARD -i enp1s0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT 
 +COMMIT 
 +# Completed on Mon Mar 31 19:57:26 2025 
 +</pre></html> 
 +<note important>Il faut bien noter que les règles sont testées **dans l'ordre où elles sont classées**. Le premier rejet fait que les règles suivantes ne sont plus testées!</note> 
 +===== Conclusion ===== 
 +Nous n'avons pas vu, loin de là, toutes les subtilités des commandes ''iptables'' et ''ip6tables'' mais nous avons dégrossi l'essentiel. 
 + 
 +Il faut savoir que ce qui est fait au niveau IP peut se faire aussi au niveau Ethernet avec les outils ''ebtables'' pour gérer les «bridges» car si le kernel sait faire du routage  (niveau IP) entre deux interfaces, il sait également faire du pontage (niveau Ethernet) entre deux interfaces et il est possible de filtrer avec Netfilter à ce niveau-là. 
 + 
 +Et pour finir de donner le vertige, il existe enfin l'outil ''arptables'' qui permet de créer des règles pour limiter les immenses failles de sécurité dur protocole ARP mais l'étude de ces outils n'est pas au programme ici. 
IPtables: Dernière modification le: 31/03/2025 à 12:43 par prof