|
1.
|
Quelle est la syntaxe de la commande iptables sur la politique par
défaut à appliquer sur les chaînes de la table netfilter pour respecter le premier principe de
filtrage énoncé ci-dessus ?
De façon très classique, on consulte les pages de manuels de la
commande iptables et
on recherche le mot clé policy. La
stratégie retenue suppose que l'on implante règles d'autorisation
des flux réseaux valides et que tout autre trafic soit éliminé. La
politique par défaut à appliquer sur les trois chaînes est donc :
DROP.
La section «9.3. Commandes» du
Tutoriel iptables donne aussi la
syntaxe de configuration de cible par
défaut pour les chaînes élémentaires : INPUT, FORWARD et
OUTPUT.
|
|
# 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 INPUT et
OUTPUT ?
La recherche de la correspondance state dans les pages de manuel de la commande
iptables permet de
sélectionner les états ESTABLISHED et
RELATED à appliquer sur les
chaînes.
La section «7.3. États de l'espace
utilisateur» du Tutoriel iptables décrit les
correspondances entre les états et les flux réseau.
|
|
# 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. Ces programmes présentent un grand intérêt dans
la mesure où l'affichage des règles de filtrage est plus
condensé.
# iptables-save >/var/lib/iptables/active
# vim /var/lib/iptables/active
# iptables-restore </var/lib/iptables/active
# grep -v '^# ' /var/lib/iptables/active
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
#~~~~~~~~~~~~~~~~~~~~~:: INPUT
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
#~~~~~~~~~~~~~~~~~~~~~:: OUTPUT
-A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
COMMIT
La commande iptables-restore doit être
utilisée après chaque édition du fichier /var/lib/iptables/active.
|
|
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 ?
Faire des tests ICMP,
DNS et HTTP. Conclure et justifier.
|
|
La réponse est non. La politique par défaut sur les chaînes
INPUT et OUTPUT étant positionnée à DROP, tout nouveau paquet entrant ou sortant est
rejeté. Pour qu'une communication soit possible, il faudrait avoir
enregistré un flux réseau dans la machine d'état avant d'appliquer
ce jeu de règles de filtrage.
|
|
4.
|
Quelle est la syntaxe de la commande iptables qui autorise le trafic
réseau depuis (chaîne OUTPUT) et vers
(chaîne INPUT) l'interface de boucle
locale de l'équipement ?
Pour que les processus locaux au système puissent communiquer
entre eux via la pile de protocole TCP/IP, il est essentiel d'autoriser le trafic sur
l'interface de boucle locale lo. La
recherche de la correspondance state
dans les pages de manuel de la commande iptables permet de sélectionner
l'état NEW pour autoriser le premier
paquet depuis et vers cette interface. Tous les autres paquets
devront correspondre aux règles déjà écrites ci-dessus.
|
|
On ajoute deux nouvelles règles sur les chaînes INPUT et OUTPUT qui
admettent respectivement tous les paquets entrant et sortant par
l'interface de lo dans la table de
suivi des communications.
# grep -v '^# ' /var/lib/iptables/active
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
#~~~~~~~~~~~~~~~~~~~~~:: INPUT
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -i lo -m state --state NEW -j ACCEPT
#~~~~~~~~~~~~~~~~~~~~~:: OUTPUT
-A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -o lo -m state --state NEW -j ACCEPT
COMMIT
À partir de ce jeu de règles, on peut lancer un test
ICMP : # ping -c 4 127.0.0.1.
|
|
5.
|
Quelle est la syntaxe de la commande iptables qui autorise le trafic
sortant sur l'interface LAN en
sortie du système ?
Comme pour la question précédente, les processus locaux au
système doivent pouvoir émettre du trafic via la pile de protocole
TCP/IP. Il est donc préférable d'autoriser le trafic sortant sur
l'interface LAN. On utilise à
nouveau l'état NEW pour autoriser le
premier paquet depuis l'interface. Tous les autres paquets devront
correspondre aux communications déjà enregistrées dans les tables
de suivi.
|
|
On ajoute une règle sur la chaîne OUTPUT qui admet, dans la table de suivi des
communications, les paquets sortant par l'interface eth0.
# grep -v '^# ' /var/lib/iptables/active
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
#~~~~~~~~~~~~~~~~~~~~~:: INPUT
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -i lo -m state --state NEW -j ACCEPT
#~~~~~~~~~~~~~~~~~~~~~:: OUTPUT
-A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -o lo -m state --state NEW -j ACCEPT
-A OUTPUT -o eth0 -m state --state NEW -j ACCEPT
COMMIT
|
|
6.
|
Quelle est la syntaxe de la commande iptables qui autorise le trafic
ICMP en entrée du système en
limitant le nombre des nouvelles requêtes à 5 par minute
?
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 des commandes ping et hping3 à partir d'un hôte
distant.
|
|
La recherche de la correspondance limit dans les pages de manuel de la commande
iptables permet de
compléter la syntaxe de la règle d'autorisation du trafic
ICMP avec l'état NEW pour le suivi de communication.
# grep -v '^# ' /var/lib/iptables/active
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
#~~~~~~~~~~~~~~~~~~~~~:: INPUT
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -m limit --limit 5/min -m state --state NEW -j ACCEPT
-A INPUT -i lo -m state --state NEW -j ACCEPT
#~~~~~~~~~~~~~~~~~~~~~:: OUTPUT
-A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -o lo -m state --state NEW -j ACCEPT
-A OUTPUT -o eth0 -m state --state NEW -j ACCEPT
COMMIT
Les tests de qualification de la nouvelle règle utilisent la
commande usuelle ping
puis un outil beaucoup moins classique qui offre de nombreuses
«possibilités», hping3.
# ping -n -c 3 192.0.2.3
PING 192.0.2.3 (192.0.2.3) 56(84) bytes of data.
64 bytes from 192.0.2.3: icmp_req=1 ttl=64 time=0.958 ms
64 bytes from 192.0.2.3: icmp_req=2 ttl=64 time=0.746 ms
64 bytes from 192.0.2.3: icmp_req=3 ttl=64 time=0.803 ms
--- 192.0.2.3 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.746/0.835/0.958/0.095 ms
# hping3 -1 --rand-source --fast -c 10 192.0.2.3
HPING 192.0.2.3 (tap0 192.0.2.3): icmp mode set, 28 headers + 0 data bytes
len=28 ip=192.0.2.3 ttl=64 xml:id=5204 icmp_seq=0 rtt=1.0 ms
len=28 ip=192.0.2.3 ttl=64 xml:id=9948 icmp_seq=1 rtt=0.5 ms
len=28 ip=192.0.2.3 ttl=64 xml:id=31892 icmp_seq=2 rtt=0.6 ms
len=28 ip=192.0.2.3 ttl=64 xml:id=48870 icmp_seq=3 rtt=0.6 ms
len=28 ip=192.0.2.3 ttl=64 xml:id=40501 icmp_seq=4 rtt=0.7 ms
--- 192.0.2.3 hping statistic ---
10 packets transmitted, 5 packets received, 50% packet loss
On constate que le premier test ne produit aucune erreur alors
que la tentative de spoofing rapide des
adresses IP source entraîne des
pertes de paquets ICMP dès que
la limite fixée dans la règle de filtrage est atteinte.
|
