UE31 - M3102 : Services Réseaux

Transcription

1 UE31 - M3102 : Services Réseaux Enoncé du TP 4 NAT/PAT, Pare-Feu C. Pain-Barre Table des matières 1 Simulateur : Nat/Pat et firewall 2 Exercice 1 (Simulation Nat/Pat et firewall) Netfilter et iptables Introduction Utilisation d iptables 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)

2 UE31 - M3102 : Services Réseaux Enoncé du TP 4 2/13 1 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 /24 constitué des stations st1 et st2 le réseau /24 constitué des stations st1, st3 et st4 le réseau /24 constitué des stations st5, st6, st7 et st8 le réseau /24 constitué des stations st9, st11 et st13 appartenant au vlan 5 le réseau /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 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

3 3/13 Enoncé du TP 4 UE31 - M3102 : Services Réseaux 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)

4 UE31 - M3102 : Services Réseaux Enoncé 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 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

5 5/13 Enoncé du TP 4 UE31 - M3102 : Services Réseaux (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. 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)

6 UE31 - M3102 : Services Réseaux Enoncé du TP 4 6/13 FORWARD PREROUTING Routage POSTROUTING INPUT OUTPUT Processus local FIGURE 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

7 7/13 Enoncé du TP 4 UE31 - M3102 : Services Réseaux 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ères -j action où les critères peuvent être très variés et dépendent des protocoles présents dans le paquet, ainsi que de son état. Comme critères, 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 états : pour identifier l état de la "connexion" d où émane le paquet, où états 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ères -j action iptables [-t table] -D chaîne numéro 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éro de la règle à supprimer (la première règle d une chaîne porte le numéro 1).

8 UE31 - M3102 : Services Réseaux Enoncé 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ères -j action où la règle sera insérée en position position. Notons que dans ces critères, 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 : iptables -A INPUT -s /32 -p tcp --dport 80 -j REJECT 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 /24 est constitué des postes srv1 ( ), srv2 ( ) et de firewall ( ) : le réseau /24 est constitué des postes pt1 ( ), pt2 ( ), pt3 (non configuré) et de firewall ( ) le réseau /24 va représenter le côté Internet. Il est constitué des postes host1 ( ), host2 ( ), firewall ( ) ainsi que de la passerelle d accès à Internet G1 d adresse 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

9 9/13 Enoncé du TP 4 UE31 - M3102 : Services Réseaux srv2 srv1 G1 [4] /24 d2 d1 d11 [2] [1] S2 [4] [3] [2] S1 [4] S3 [1] d5 d6 d8 d4 [3] [1] d3 d7 [2] [3] d10 d9 pt1 pt2 pt3 firewall host2 host1 WindowsXP ( ) [1] [2] FIGURE 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 /24 eth1 pour le réseau /24 eth2 pour le réseau /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 nameserver 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

10 UE31 - M3102 : Services Réseaux Enoncé 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 Exercice 4 (ajout de routes sur host1 et host2) Pour le moment, host1 et host2 ne connaissent pas les réseaux /24 et /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 /24 et /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 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 comme adresse d écoute des directives Listen pour obtenir : Listen : Listen :443 L adresse 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 Sur pt1, tester l accès à ce serveur avec lynx qui doit être possible : # lynx Faire de même depuis host1 C. Pain-Barre - 29/12/2014

11 11/13 Enoncé du TP 4 UE31 - M3102 : Services Réseaux 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 root@ 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 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 root@ '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 On devrait voir les paquets apparaître dans les wireshark Sur pt1, tester l accès au serveur Web de srv1 avec lynx : # lynx 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

12 UE31 - M3102 : Services Réseaux Enoncé 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 j DROP # iptables -A FORWARD -d 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 Cette fois, on devrait voir des paquets arriver sur firewall mais ils n atteignent pas srv De même, sur srv1 tenter un ping de host1 et observer que le trafic ne passe pas 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 C. Pain-Barre - 29/12/2014

13 13/13 Enoncé du TP 4 UE31 - M3102 : Services Réseaux 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 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 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"