Différences

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

--- 130netfilter:20-iptables [le 31/03/2025 à 17:32] – [Depuis 192.168.61.0/24 vers l'internet] prof
+++ 130netfilter:20-iptables [le 04/04/2025 à 07:00] (Version actuelle) – [Synthèse] prof
@@ Ligne 86: / Ligne 86: @@
 Il n'y a à priori plus rien à faire en fonction du cahier des charges initial
 ===== Vérifications =====
-==== Depuis 192.168.61.0/24 vers l'internet ====
+==== Pour IPv4 ====
 Lors du démarrage d'un client du LAN vert, Nous pouvons vérifier sa configuration IPv4:
@@ Ligne 122: / Ligne 122: @@
 Trying 192.168.61.1...
 ...
-<span class="hly">telnet: Unable to connect to remote host: Connexion terminée par expiration du délai d'attente</span>
+<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.
@@ Ligne 156: / Ligne 156: @@
 Nmap n'a rien trouvé d'ouvert, ni en TCP ni en UDP. Réconfortant.
-Voyons maintenant avec IPv6. D'abord la configuration du client:
+==== Et pour IPv6 ====
 <html><pre class="code">
 <b>ip -6 addr ls</b>
@@ Ligne 196: / Ligne 197: @@
 <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 class="hly">tcp6       0      <b>0 :::22</b>     :::*      <b>LISTEN</b>      0   16587      <b>561/sshd: /usr/sbin</b></span>
-</html></pre>
+</pre></html>
+Le port 22 est bien ouvert à l'écoute
 <html><pre class="code">
-<b><b>ssh 2a01:e0a:875:b1d2:5054:ff:feb7:6681</b>
+<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: Connection refused</span>
+<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.
@@ Ligne 209: / Ligne 211: @@
 <html><pre class="code">
 <b>ssh 2a01:e0a:875:b1d0:5054:ff:fe74:45f2</b>
-<span class="hly">ssh: connect to host 2a01:e0a:875:b1d0:5054:ff:fe74:45f2 port 22: <b>Connection timed out</b></span>
+<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.