Transcript UE31 - M3102 (Services Réseaux) : Enoncé TP 4

UE31 - M3102 : Services Réseaux
Enoncé du TP 4
NAT/PAT, Pare-Feu
IUT Aix-Marseille - INFO Aix
C. Pain-Barre
Table des matières
1
Simulateur : Nat/Pat et firewall
Exercice 1 (Simulation Nat/Pat et firewall) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
Netfilter et iptables
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Utilisation d’iptables . . . . . . . . . . . . . . . . . . . . . .
2.3 Fonctionnalité de pare-feu . . . . . . . . . . . . . . . . . . .
Exercice 2 (chargement du lab) . . . . . . . . . . . . . . . . .
Exercice 3 (configuration firewall comme routeur) . . . . . . .
Exercice 4 (ajout de routes sur host1 et host2) . . . . . . . . .
Exercice 5 (activation du service HTTP (Web) sur srv1) . . . .
Exercice 6 (visualisation du trafic vers srv1) . . . . . . . . . .
Exercice 7 (blocage de tout le trafic avec srv1) . . . . . . . . .
Exercice 8 (autorisation du ping de srv1) . . . . . . . . . . . .
Exercice 9 (autorisation du trafic pour le serveur Web de srv1)
Exercice 10 (autorisation du trafic légitime pour srv1) . . . . .
Exercice 11 (sécurisation de srv2) . . . . . . . . . . . . . . .
IUT Aix-Marseille - INFO Aix
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29/12/2014
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
2
5
5
6
8
8
9
10
10
11
12
12
13
13
13
- C. Pain-Barre
UE31 - M3102 : Services R´eseaux
1
Enonc´e du TP 4
2/13
Simulateur : Nat/Pat et firewall
Soit l’interconnexion de réseaux modélisée dans le simulateur de Pierre Loisel (CERTA) :
formée par les 5 réseaux suivants (plus Internet et les FAI) :
• le réseau 192.168.2.0/24 constitué des stations st1 et st2
• le réseau 192.168.0.0/24 constitué des stations st1, st3 et st4
• le réseau 192.168.1.0/24 constitué des stations st5, st6, st7 et st8
• le réseau 192.168.5.0/24 constitué des stations st9, st11 et st13 appartenant au vlan 5
• le réseau 192.168.6.0/24 constitué des stations st9, st10, st12 et st14 appartenant au vlan 6
i
Tous les vlans de l’exercice sont de niveau 2, ce qui n’a pas vraiment d’importance pour le sujet traité.
Les stations st1, st5 et st9 ont toutes des cartes d’accès distant les reliant à Internet et sont configurées pour
servir de routeurs. Cependant les autres stations appartiennent à des réseaux privés et ne peuvent pas encore
utiliser Internet.
Exercice 1 (Simulation Nat/Pat et firewall)
Ouvrir un terminal sur le poste de travail Linux, lancer une machine virtuelle XP en exécutant mkwxpnat.bash.
Une fois logé sur la VM XP :
1. Dans un navigateur, aller sur le site http://infodoc.aix.univ-amu.fr/~cpb et récupérer le fichier
reseau_depart.xml, puis le charger dans le simulateur de Pierre Loisel
2. En mode Transport, activer le Nat/Pat sur st1, st5 et st9. Pour cela, effectuer un clic droit sur la station,
choisir Configuration IP et cocher la case Nat/Pat puis sélectionner l’interface publique ppp (qui les relie
à Internet) :
C. Pain-Barre -
29/12/2014
IUT Aix-Marseille - INFO Aix
3/13
Enonc´e du TP 4
UE31 - M3102 : Services R´eseaux
3. Mise en place de serveurs :
(a) faire écouter par st2 son port UDP 69 (serveur TFTP). Pour cela, en mode Transport, faire un clic
droit sur st2 puis choisir Tables → Ports écoutés puis ajouter le port UDP 69 :
(b) faire écouter par st3 son port TCP 22 (serveur SSH)
(c) faire écouter par st8 son port TCP 21 (serveur FTP)
(d) faire écouter par st12 son port TCP 80 (serveur HTTP)
(e) faire écouter par st13 son port TCP 22 (serveur SSH)
(f) faire écouter par st14 son port TCP 21 (serveur FTP)
4. Configuration des redirections de port (traductions statiques) sur st1, st5 et st9 :
(a) configurer st1 pour que l’accès aux serveurs de st2 et st3 soit possible depuis Internet. Pour cela, en
mode Transport, faire un clic droit sur st1 puis choisir Tables → Table Nat/Pat et ajouter les entrées
pour les serveurs de st2 et st3. Pour chaque serveur, il faut remplir une ligne de la table :
en spécifiant :
• le protocole de transport TCP ou UDP
• l’adresse IP privée du serveur (ici de st2 ou st3)
• le port privé du serveur (celui sur lequel il est en écoute)
• l’adresse IP publique (donc ici de st1)
• le port public (ici on peut prendre le même que le port du serveur)
IUT Aix-Marseille - INFO Aix
29/12/2014
- C. Pain-Barre
UE31 - M3102 : Services R´eseaux
Enonc´e du TP 4
4/13
(b) configurer st5 pour que l’accès au serveur de st8 soit possible depuis Internet
(c) configurer st9 pour que l’accès aux serveurs de st12, st13 et st14 soit possible depuis Internet
5. Vérifier l’accessibilité des serveurs depuis n’importe quelle station (d’un réseau différent) en émettant une
requête destinée à ces serveurs et en les faisant répondre (en mode Transport, clic-droit sur une station
puis envoyer une requête/répondre à une requête). Pendant la simulation, observer les traductions PAT
(adresses et ports) lors de la traversée éventuelle des NATBox st1, st5 et st9.
i
On rappelle que l’envoi de la requête doit se faire vers l’IP publique et le port public du serveur ;
pas vers les adresses privées. . .
6. Configuration d’un pare-feu sans état (règles de filtrage ou access lists).
-
Un pare-feu sans état est un pare-feu qui traite les paquets indépendamment les uns des autres.
Dans ce type de pare-feu, pour permettre l’accès à un serveur, il faut autoriser les paquets à
destination de ce serveur, mais aussi autoriser les paquets en retour, ce qui n’est pas très simple
ou sécurisé. . .
Les règles de filtrage sont entrées sur une station/routeur en mode Transport en effectuant un clic droit sur la
station/routeur puis choisir Tables → Règles de filtrage. Chaque règle dicte comment traiter un datagramme
UDP ou segment TCP ou message ICMP reçu, et il faut remplir une ligne de la table :
en spécifiant pour quels datagrammes elle doit être appliquée :
• sur quelle carte en entrée (* pour toutes)
• sur quelle carte en sortie (* pour toutes)
• pour quel protocole parmi UDP, TCP ou ICMP (* pour tous)
• pour quel bloc d’adresses IP source, indiqué par une adresse et un préfixe (* pour toutes)
• pour quel port source (* pour tous)
• pour quel bloc d’adresses IP destination, indiqué par une adresse et un préfixe (* pour toutes)
• pour quel port destination (* pour tous)
• que faire du datagramme qui correspond à ces critères : Accepter ou Bloquer.
-
Pour un datagramme donné, la première règle qui correspond est celle appliquée.
Configurer les règles de st9 pour que :
(a) tout le monde extérieur puisse atteindre les serveurs de la DMZ (serveur Web sur st12 et serveur FTP
sur st14)
(b) seul st1 (ce qui inclut les stations st2, st3 et st4) puisse atteindre le serveur SSH (de st13)
C. Pain-Barre -
29/12/2014
IUT Aix-Marseille - INFO Aix
5/13
Enonc´e du TP 4
UE31 - M3102 : Services R´eseaux
(c) laisser passer en entrée tout le trafic ICMP extérieur
(d) bloquer tout autre type de trafic entrant
(e) laisser le trafic sortant passer
7. Vérifier que ces règles fonctionnent en tentant d’envoyer des requêtes à ces serveurs et en les faisant répondre lorsqu’elles arrivent.
[Corrigé]
2
Netfilter et iptables
2.1
Introduction
Netfilter est la partie du noyau Linux qui peut contrôler, modifier, filtrer et suivre le trafic réseau. Ses fonctionnalités sont potentiellement très nombreuses. Nous nous limiterons à celles de pare-feu avec états et de
NatBox. iptables est la commande fournie par défaut pour configurer le module Netfilter.
i
Notons que plusieurs logiciels ont été développés pour faciliter la configuration de Netfilter, offrant
des interfaces et des modes de configuration plus ou moins simplifiés.
Les éléments de base de Netfilter sont les règles, les actions, les chaînes et les tables, auxquels on peut ajouter
la notion d’état :
• une règle définit une action à réaliser pour un paquet respectant les critères qu’elle précise. Une règle est
liée à une table et à une chaîne.
• une action déclenchée par une règle peut être :
ACCEPT : le paquet traverse la chaîne avec succès
DROP : le paquet est supprimé silencieusement
REJECT : le paquet est supprimé et un message d’erreur est transmis à l’expéditeur
MASQUERADE : le paquet doit subir une traduction d’adresse
SNAT : traduction de l’adresse source du paquet
DNAT : traduction de l’adresse destination du paquet
LOG : ajouter une ligne dans le fichier de trace du noyau /var/log/messages pour signaler le
traitement du paquet
i
MASQUERADE est principalement utilisée pour les NATBox qui ont une IP publique dynamique. Son mode de fonctionnement rend cette action plus lente que SNAT et DNAT qu’il est
préférable d’utiliser si l’IP publique est fixe.
• une chaîne est une phase de traitement de paquets à un moment clé de leur "parcours" dans l’hôte. Elle
est constituée d’un ensemble de règles qui sont évaluées dans l’ordre. Les chaînes préexistantes sont :
PREROUTING : traitement des paquets entrants, avant qu’il ne soit décidé s’ils sont destinés à l’hôte
local, ou s’ils doivent être retransmis
INPUT : traitement des paquets entrants destinés à l’hôte
FORWARD : traitement des paquets qui doivent être réexpédiés (routés)
IUT Aix-Marseille - INFO Aix
29/12/2014
- C. Pain-Barre
UE31 - M3102 : Services R´eseaux
Enonc´e du TP 4
6/13
FORWARD
PREROUTING
Routage
POSTROUTING
INPUT
OUTPUT
Processus local
F IGURE 1 – Chaînes de Netfilter
OUTPUT : traitement des paquets qui émanent de l’hôte
POSTROUTING : traitement des paquets juste avant d’être émis
Plusieurs chaînes se succèdent dans le temps, mais les paquets ne passent pas par toutes les chaînes. Cela
dépend de leur origine et de leur destination. La figure 1 illustre le parcours d’un paquet sur l’hôte et les
chaînes de traitement qu’il peut subir :
réception d’un paquet : un paquet reçu sur une interface réseau passe d’abord par la chaîne
PREROUTING. Une décision de routage est ensuite prise pour savoir s’ils est vraiment destiné à
l’hôte ou s’il doit être réexpédié (fonction de routeur de l’hôte) :
◦ s’il est destiné à l’hôte, il passe alors par la chaîne INPUT avant d’être remis au processus local
destinataire
◦ s’il doit être réexpédié, il passe alors par la chaîne FORWARD, puis par la chaîne POSTROUTING
avant d’être effectivement émis
envoi d’un paquet par un processus local : le paquet passe d’abord par la chaîne OUTPUT, puis par la
chaîne POSTROUTING avant d’être effectivement émis.
Dans toutes les chaînes, les règles peuvent modifier ou supprimer le paquet, mais certaines chaînes sont
plus propices que d’autres selon les opérations envisagées.
• une table sert pour assurer des fonctions spécifiques et est constituée d’un ensemble de chaînes. Nous ne
manipulerons que les tables filter et nat :
filter est la table servant au filtrage de paquets (fonction pare-feu). Elle est constituée des chaînes
INPUT, FORWARD et OUTPUT
nat est la seule table où sont permises les actions de traduction d’adresse (fonction NATBox). Elle
est constituée des chaînes PREROUTING, OUTPUT et POSTROUTING
2.2
Utilisation d’iptables
La commande iptables permet de gérer les tables, les chaînes et les règles qu’elles contiennent. Par défaut,
iptables travaille sur la table filter. Dans la description qui suit l’option -t permet de préciser la table sur
laquelle opérer :
• Afficher les règles courantes d’une table :
iptables [-t table] -L
C. Pain-Barre -
29/12/2014
IUT Aix-Marseille - INFO Aix
7/13
Enonc´e du TP 4
UE31 - M3102 : Services R´eseaux
• Effacer toutes les règles d’une table :
iptables [-t table] -F
• Spécifier une action par défaut pour une chaˆıne d’une table :
iptables [-t table] -P chaˆıne action
La politique par défaut des chaînes est ACCEPT, ce qui signifie que si aucune règle ne s’applique à un
paquet d’une chaîne, le paquet est accepté (passe la chaîne). Cette commande permet de spécifier une
politique différente pour une chaˆıne donnée, par exemple DROP, auquel cas un paquet non explicitement
autorisé ne passera pas cette chaîne
• Ajout d’une règle à la fin d’une chaˆıne d’une table :
iptables [-t table] -A chaˆıne crit`eres -j action
où les crit`eres peuvent être très variés et dépendent des protocoles présents dans le paquet, ainsi que de
son état. Comme crit`eres, on peut former une combinaison de :
-p protocole : où protocole peut être tcp, udp, icmp. . .
-s adresse : pour identifier la source du paquet, et où adresse est de la forme ip[/masque] et masque
peut être un masque ou un préfixe CIDR
-d adresse : pour identifier la destination d’un paquet
-i interface : pour identifier l’interface qui a reçu le paquet
-o interface : pour identifier l’interface de sortie du paquet
--sport ports : pour identifier le port source du paquet, où ports est de la forme port[:port] permettant de spécifier un intervalle
--dport ports : pour identifier le port destination du paquet
--icmp-type type : pour identifier le type de paquet ICMP
-m state --state ´etats : pour identifier l’état de la "connexion" d’où émane le paquet, où ´etats est une
liste de termes séparés par des virgules parmi :
◦ INVALID : le paquet n’est associé à aucun flux ni connexion, et peut contenir des informations
erronées
◦ ESTABLISHED : la paquet appartient à une connexion déjà établie (des paquets ont été échangés
dans les 2 sens)
◦ NEW : le paquet appartient à une connexion en cours d’établissement
◦ RELATED : le paquet démarre une nouvelle "connexion", qui est liée à une connexion déjà établie.
C’est le cas de la connexion de données d’un transfert par FTP, ou d’un message d’erreur ICMP
relatif à une connexion non encore établie
i
C’est ce critère qui fait de Netfilter un pare-feu avec états !
• Suppression d’une règle d’une chaˆıne d’une table :
iptables [-t table] -D chaˆıne crit`eres -j action
iptables [-t table] -D chaˆıne num´ero
où dans la première forme, il faut que la règle corresponde exactement à celle devant être supprimée, alors
que dans la deuxième forme on indique juste le num´ero de la règle à supprimer (la première règle d’une
chaîne porte le numéro 1).
IUT Aix-Marseille - INFO Aix
29/12/2014
- C. Pain-Barre
UE31 - M3102 : Services R´eseaux
Enonc´e du TP 4
8/13
• insertion d’une règle dans une chaˆıne d’une table :
iptables [-t table] -I chaˆıne position crit`eres -j action
où la règle sera insérée en position position.
-
Notons que dans ces crit`eres, on peut utiliser le caractère ! pour exprimer la négation. Par exemple, on
peut écrire -p ! tcp pour dire tous les protocoles sauf TCP. . .
Exemple 1
• Interdire à l’hôte d’initier un dialogue avec l’extérieur :
iptables -A OUTPUT -m state --state NEW -j DROP
• Interdire l’accès au serveur Web de l’hôte à la station 1.1.1.1 :
iptables -A INPUT -s 1.1.1.1/32 -p tcp --dport 80 -j REJECT
ê
2.3
On a utilisé ici REJECT pour l’exemple, qui renvoie un message d’erreur ce qui n’est pas
toujours souhaitable. . .
Fonctionnalité de pare-feu
Ainsi qu’il a été dit précédemment, la fonctionnalité de pare-feu se configure à travers la table filter qui
contient 3 chaînes INPUT, FORWARD et OUTPUT :
• INPUT sert à filtrer le trafic à destination du pare-feu
• OUTPUT sert à filtrer le trafic généré par le pare-feu
• FORWARD sert à filtrer le trafic passant par le pare-feu
Dans ce qui suit, nous n’utiliserons que la table FORWARD afin de configurer un pare-feu pour filtrer des flux qui
transiterons par lui.
Exercice 2 (chargement du lab)
Sur le PC, télécharger le fichier m3102_tp4_lab1.mar, l’ouvrir dans Marionnet et cliquer sur Tout Démarrer. Comme le montre la figure 2, ce lab est constitué de 3 réseaux et de 8 hôtes :
• le réseau 10.0.2.0/24 est constitué des postes srv1 (10.0.2.1), srv2 (10.0.2.2) et de firewall
(10.0.2.250) :
• le réseau 10.0.1.0/24 est constitué des postes pt1 (10.0.1.1), pt2 (10.0.1.2), pt3 (non configuré) et de firewall (10.0.1.250)
• le réseau 10.10.10.0/24 va représenter le côté Internet. Il est constitué des postes host1
(10.10.10.11), host2 (10.10.10.12), firewall (10.10.10.250) ainsi que de la passerelle d’accès
à Internet G1 d’adresse 10.10.10.2
Parmi ces machines, certaines vont jouer un rôle particulier :
• srv1 hébergera un serveur Web public (accessible par tous)
• srv2 hébergera un serveur FTP et un serveur TFTP publics
C. Pain-Barre -
29/12/2014
IUT Aix-Marseille - INFO Aix
9/13
Enonc´e du TP 4
srv2
UE31 - M3102 : Services R´eseaux
srv1
G1
[4]
10.10.10.2/24
[0]
[0]
d2
d1
S2
[1]
[2]
d11
S1
[2]
S3
[4]
[4]
[3]
d5
d6
[1]
d8
[3]
[1]
d3
d4
[2]
[3]
d7
d10
d9
[0]
pt1
pt2
firewall
pt3
host2
host1
[1]
[0]
[0]
[2]
[0]
[0]
[0]
Windows XP (10.0.1.3)
F IGURE 2 – Présentation du lab Marionnet pour le pare-feu
La machine firewall va permettre de filtrer les flux en provenance d’Internet afin de protéger srv1, srv2, pt1, pt2
(et pt3). Toutes les stations sont configurées (adresses, tables de routage, DNS) sauf firewall.
Pas besoin de corrigé. . .
Exercice 3 (configuration firewall comme routeur)
Se loger sur firewall, et :
1. configurer ses interfaces réseau :
• eth0 pour le réseau 10.0.2.0/24
• eth1 pour le réseau 10.0.1.0/24
• eth2 pour le réseau 10.10.10.0/24
2. vérifier que ces interfaces ont été correctement configurées en pingant les stations srv1, pt1, host1 et G1
3. ajouter la route par défaut vers G1 dans sa table de routage
4. modifier son fichier /etc/resolv.conf pour contenir :
domain aix.univ-amu.fr
search aix.univ-amu.fr univ-amu.fr
nameserver 139.124.182.8
nameserver 139.124.1.2
5. vérifier que la résolution de noms est bien opérationnelle en tapant :
# host infodoc
qui doit nous fournir l’IP d’infodoc
6. vérifier que l’accès Internet est opérationnel avec :
# lynx infodoc/~cpb
qui devrait afficher la page du site
IUT Aix-Marseille - INFO Aix
29/12/2014
- C. Pain-Barre
UE31 - M3102 : Services R´eseaux
Enonc´e du TP 4
10/13
7. activer sa fonction de routage en tapant :
# echo 1 > /proc/sys/net/ipv4/ip_forward
8. vérifier que pt1 peut pinguer srv1 et que srv2 peut pinguer pt2
[Corrigé]
Exercice 4 (ajout de routes sur host1 et host2)
Pour le moment, host1 et host2 ne connaissent pas les réseaux 10.0.1.0/24 et 10.0.2.0/24. Ils utilisent G1
comme routeur par défaut qui ne connaît pas non plus ces réseaux (et qu’on ne peut pas configurer). On va ajouter
les routes vers ces réseaux sur host1 et host2 :
1. afficher les tables de routage de host1 et de host2
2. vérifier que host1 ne peut pas pinguer srv1
3. ajouter dans leur table les routes pour les réseaux 10.0.1.0/24 et 10.0.2.0/24
4. vérifier que host1 peut maintenant pinguer srv1 et pt1
5. de même, vérifier que host2 peut pinguer srv1 et pt1
[Corrigé]
Exercice 5 (activation du service HTTP (Web) sur srv1)
Dans cet exercice, on va démarrer le serveur Web de srv1 et s’assurer qu’il fonctionne :
1. Sur srv1 :
(a) éditer le fichier /etc/apache2/ports.conf, et préciser 0.0.0.0 comme adresse d’écoute des
directives Listen pour obtenir :
Listen 0.0.0.0:80
...
Listen 0.0.0.0:443
...
-
L’adresse 0.0.0.0 veut dire any : le serveur écoute sur toutes les adresses IP de l’hôte.
Dit autrement, un client peut utiliser n’importe quelle IP du serveur pour s’y connecter. Il
n’était pas nécessaire de la préciser, à ceci près que cela force le serveur à utiliser IPv4 et
non IPv6, ce qui aurait pu amener un peu de confusion. . .
(b) démarrer le serveur Web en tapant :
# /etc/init.d/apache2 start
(c) Utiliser netstat pour s’assurer que le serveur Web est bien démarré et en écoute sur le port 80
2. Sur pt1, tester l’accès à ce serveur avec lynx qui doit être possible :
# lynx 10.0.2.1
3. Faire de même depuis host1
[Corrigé]
C. Pain-Barre -
29/12/2014
IUT Aix-Marseille - INFO Aix
11/13
Enonc´e du TP 4
UE31 - M3102 : Services R´eseaux
Exercice 6 (visualisation du trafic vers srv1)
Avant de procéder au paramétrage de firewall, il peut être utile de visualiser le traffic sur srv1 et sur firewall :
1. Depuis le PC (!), ouvrir un terminal :
(a) taper :
$ ssh -X [email protected]
afin de se loger sur srv1 par une porte dérobée ;-)
i
On ne maîtrise pas vraiment la gestion des adresses des portes dérobées par Marionnet.
Aussi, il est possible qu’elles ne soient pas les mêmes d’un poste à l’autre. Si c’est le cas,
une manière de les obtenir et de faire l’opération inverse : se connecter depuis la machine
virtuelle au serveur SSH (en écoute sur le port 22222) du PC hôte qui a pour adresse
dérobée 172.23.0.254 puis utiliser netstat pour voir cette connexion et en déduire
l’adresse de la VM. . .
(b) une fois logé sur srv1, taper :
$ wireshark &
et démarrer une capture sur l’interface eth0
2. Depuis le PC, ouvrir un autre terminal et taper :
$ ssh -X [email protected] 'wireshark'
afin de lancer wireshark sur firewall, puis démarrer une capture sur l’interface eth2
3. Sur host1, tester l’accès au serveur Web de srv1 avec lynx :
# lynx 10.0.2.1
On devrait voir les paquets apparaître dans les wireshark. . .
4. Sur pt1, tester l’accès au serveur Web de srv1 avec lynx :
# lynx 10.0.2.1
On devrait voir les paquets apparaître dans wireshark de srv1 uniquement, car wireshark de firewall ne
capture pas sur l’interface eth1
Pas besoin de corrigé. . .
C’est maintenant que les choses se corsent un peu ! On veut utiliser firewall pour sécuriser l’accès à srv1 :
• toutes les stations d’Internet, sauf host1, doivent avoir accès à son serveur Web
• pt1 a aussi accès à son serveur SSH
• srv1 doit pouvoir envoyer et recevoir des messages d’erreur ICMP relatifs à des dialogues en cours
• srv1 doit pouvoir répondre aux pings
• aucun autre service ne doit être accessible
• interdiction pour srv1 d’initier un dialogue, à part pour contacter un serveur DNS
IUT Aix-Marseille - INFO Aix
29/12/2014
- C. Pain-Barre
UE31 - M3102 : Services R´eseaux
Enonc´e du TP 4
12/13
Exercice 7 (blocage de tout le trafic avec srv1)
Une façon de procéder est de commencer par bloquer, sur firewall, tout le trafic en provenance ou à destination
de srv1. La chaîne concernée par ce trafic est la chaîne FORWARD, par laquelle passent les paquets routés. On
insérera ensuite des règles dans cette chaîne pour autoriser au fur et à mesure le trafic que nous souhaitons.
1. Sur firewall :
(a) commencer par faire afficher la table filter en tapant :
# iptables -L
où l’on devrait voir que les chaînes sont vides et sont en politique ACCEPT par défaut
(b) taper ensuite les commandes suivantes :
# iptables -A FORWARD -s 10.0.2.1 -j DROP
# iptables -A FORWARD -d 10.0.2.1 -j DROP
qui bloquent tout le trafic de/vers srv1
(c) et visualiser à nouveau la table filter
2. Sur host1, tester l’accès au serveur Web de srv1 avec lynx :
# lynx 10.0.2.1
Cette fois, on devrait voir des paquets arriver sur firewall mais ils n’atteignent pas srv1. . .
3. De même, sur srv1 tenter un ping de host1 et observer que le trafic ne passe pas
[Corrigé]
Nous allons maintenant ouvrir peu à peu les "tuyaux" sur firewall de manière à fournir les services désirés pour
srv1.
Exercice 8 (autorisation du ping de srv1)
Un première étape consiste à autoriser le ping de srv1 par les autres stations, sans pour autant autoriser srv1 à
initier les pings. Pour cela il faut jouer sur les types des messages ICMP :
1. Insérer, avant ces règles de blocage, successivement des règles dans la chaîne FORWARD pour permettre ce
trafic :
• une règle qui autorise les requêtes d’écho (type echo-request) à parvenir à srv1
• une règle qui autorise les réponses d’écho (type echo-reply) à être émises par srv1
2. Vérifier l’état de la table filter
3. Vérifier que le ping depuis pt1 vers srv1 est possible
4. Vérifier que le ping depuis host1 vers srv1 fonctionne aussi
5. Vérifier que le ping depuis srv1 vers host1 échoue
[Corrigé]
C. Pain-Barre -
29/12/2014
IUT Aix-Marseille - INFO Aix
13/13
Enonc´e du TP 4
UE31 - M3102 : Services R´eseaux
Exercice 9 (autorisation du trafic pour le serveur Web de srv1)
Insérer, avant ces règles de blocage, successivement des règles dans la chaîne FORWARD pour permettre le
trafic légitime pour le serveur Web, en testant à chaque fois les accès à srv1 et en vérifiant le trafic capturé :
1. une règle qui dit que tout le monde sauf host1 peut initier une connexion TCP sur le port 80 de srv1, tout
en autorisant les paquets d’une connexion telle connexion déjà établie. Ici, on peut utiliser 2 règles ou une
seule. On a toutefois besoin d’utiliser la notion d’état avec -m state --state NEW,ESTABLISHED
qui n’est vraie que si un paquet est un début de connexion ou fait partie d’une connexion établie
2. une règle qui autorise les paquets en provenance de srv1 faisant partie d’une connexion déjà établie
3. une autre qui autorise les paquets ICMP relatifs à un dialogue établi
[Corrigé]
Exercice 10 (autorisation du trafic légitime pour srv1)
Terminer le paramétrage de firewall de manière à ce que ce soit conforme aux besoins exprimés. Il manque
notamment :
• l’accès au serveur SSH de srv1 pour pt1. À tester , bien évidemment
• l’accès aux serveurs DNS pour srv1 (bien que ce dernier cas ne peut être vérifié car G1 n’a pas la possibilité
de router les réponses DNS vers srv1 mais au moins on pourra voir passer ses requêtes), sachant qu’une
réponse d’un message UDP a pour état ESTABLISHED
[Corrigé]
Exercice 11 (sécurisation de srv2)
srv2 héberge un serveur FTP qu’il faut démarrer et tester, par exemple depuis srv1. Un utilisateur toto (mot
de passe toto) a été créé sur srv2 pour faciliter les choses. Paramétrer firewall pour faire en sorte que seul ce
service FTP soit accessible et qu’il puisse fonctionner aussi bien en mode actif que passif. Penser à effectuer des
captures comme précédemment pour vérifier les flux. srv2 devrait avoir pour adresse "fantôme" 172.23.0.2.
[Corrigé]
IUT Aix-Marseille - INFO Aix
29/12/2014
- C. Pain-Barre