La mise en place du filtrage réseau sur les équipements doit répondre à deux principes.
Comme les équipements d'interconnexion mis en œuvre dans ces travaux pratiques délimitent des périmètres de faible dimension, on a une connaissance exhaustive des flux réseaux sur le système. On adopte donc la règle : tout trafic réseau non autorisé est interdit.
Pour exploiter au mieux les fonctionnalités offertes par le noyau Linux, on s'appuie sur le suivi de communication (stateful inspection) pour obtenir un filtrage réseau le plus efficace possible. On cherche donc à suivre la règle d'or d'écriture des règles de filtrage qui consiste à décrire le plus précisément possible le premier paquet qui doit être enregistré dans la table de suivi de communication. Cette règle de description du premier paquet doit toujours être placée après celle(s) qui laisse(nt) passer les flux réseau déjà enregistrés dans la machine d'état de suivi de communication.
|
1. |
Quelle est la syntaxe de la commande iptables
sur la politique par défaut à appliquer sur les chaînes de la table
|
|
De façon très classique, on consulte les pages de manuels de la
commande iptables et on recherche le mot clé
# iptables -P INPUT DROP # iptables -P FORWARD DROP # iptables -P OUTPUT DROP # iptables -vL Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination |
|
|
2. |
Quelle est la syntaxe de la commande iptables qui
autorise le trafic réseau déjà enregistré dans la machine d'état de suivi
de communication sur les chaînes |
|
La recherche de la correspondance # iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# iptables -vL
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT 0 -- any any anywhere anywhere state RELATED,ESTABLISHED
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT 0 -- any any anywhere anywhere state RELATED,ESTABLISHED
À partir de cette étape, on utilise les programmes iptables-save et iptables-restore pour optimiser les manipulations. Autre intérêt, l'affichage est plus condensé. # iptables-save > iptables.common # cat iptables.common *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # I N P U T #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # O U T P U T #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT COMMIT |
|
|
3. |
À partir des règles de filtrage précédentes, est-il possible d'émettre ou de recevoir du trafic réseau non enregistré dans la machine d'état de suivi de communication ? |
|
Non. La politique par défaut sur les chaînes |
|
|
4. |
Quelle est la syntaxe de la commande iptables qui
autorise le trafic réseau depuis (chaîne |
|
Pour que les processus locaux au système puissent communiquer entre
eux via la pile de protocole TCP/IP, il est préférable d'autoriser le
trafic sur l'interface de boucle locale # cat iptables.common *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # I N P U T #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i lo -m state --state NEW -j ACCEPT #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # O U T P U T #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A OUTPUT -i lo -m state --state NEW -j ACCEPT COMMIT # iptables-restore <iptables.common À partir de ce jeu de règles, il est possible de communiquer avec
l'interface de boucle locale |
|
|
5. |
Quelle est la syntaxe de la commande iptables qui autorise le trafic ICMP en entrée et en sortie du système en limitant le nombre des nouvelles requêtes à 5 par seconde ? |
|
La recherche de la correspondance # cat iptables.common *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # I N P U T #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p ICMP -m limit --limit 5/s -m state --state NEW -j ACCEPT -A INPUT -i lo -m state --state NEW -j ACCEPT #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # O U T P U T #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A OUTPUT -p ICMP -m limit --limit 5/s -m state --state NEW -j ACCEPT -A OUTPUT -o lo -m state --state NEW -j ACCEPT COMMIT # iptables-restore <iptables.common Interdire tout trafic ICMP est une très mauvaise idée du point de vue administration réseau. Pour autant, il est très facile de se prémunir contre les tentatives de saturation du trafic sur les interfaces en limitant le nombre de requêtes simultanées en entrée sur toutes les interfaces. Dans un premier temps on se contente de cette règle unique très simple même s'il est judicieux de valider les types et les codes des messages ICMP. Dans un deuxième temps, on distinguera les types de messages ; voir Section 7.1, « Protocole ICMP ». On peut qualifier le fonctionnement de la limitation de trafic à l'aide de la commande ping sur un hôte distant. # ping -n -c 3 192.168.1.7 PING 192.168.1.7: 56 data bytes 64 bytes from 192.168.1.7: icmp_seq=0 ttl=64 time=1.8 ms 64 bytes from 192.168.1.7: icmp_seq=1 ttl=64 time=1.5 ms 64 bytes from 192.168.1.7: icmp_seq=2 ttl=64 time=1.6 ms --- topaze.linux.home ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 1.5/1.6/1.8 ms # ping -f -n -c 10 192.168.1.7 PING 192.168.1.7: 56 data bytes .............................................................................. --- topaze.linux.home ping statistics --- 106 packets transmitted, 10 packets received, 90% packet loss round-trip min/avg/max = 1.3/1.7/2.7 ms On constate que le premier test ne produit aucune erreur (ie. l'administration réseau est correcte) alors que la tentative élémentaire de saturation engendre des pertes de paquets ICMP. |
Une fois ces règles basiques en place, on peut aborder les filtrages réseau spécifiques à la topologie de travaux pratiques.
Vous êtes ici :