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 à 15:42] – [Depuis 192.168.61.0/24 vers l'internet] 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 86: Ligne 86:
 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
 ===== Vérifications ===== ===== 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: 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... 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> </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. 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. Nmap n'a rien trouvé d'ouvert, ni en TCP ni en UDP. Réconfortant.
  
-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+==== 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 à 15:42 par prof