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 Simulation PAT et pare-feu sans état 2 Exercice 1 (Lancement d une VM XP pour le simulateur) Exercice 2 (Tests d accessibilité) Exercice 3 (Simulation PAT) Exercice 4 (Simulation de serveurs et problème d accès) Exercice 5 (PAT statique pour accès aux serveurs) Pare-feu sans état Exercice 6 (PAT statique pour accès aux serveurs) Netfilter et iptables Introduction Utilisation d iptables Fonctionnalité de pare-feu Exercice 7 (chargement du lab) Exercice 8 (configuration firewall comme routeur) Exercice 9 (ajout de routes sur host1 et host2) Exercice 10 (activation du service HTTP (Web) sur srv1) Exercice 11 (visualisation du trafic vers srv1) Exercice 12 (blocage de tout le trafic avec srv1) Exercice 13 (autorisation du ping de srv1) Exercice 14 (autorisation du trafic pour le serveur Web de srv1) Exercice 15 (autorisation du trafic légitime pour srv1) Exercice 16 (sécurisation de srv2) /11/ C. Pain-Barre

2 UE31 - M3102 : Services Réseaux Enoncé du TP 4 2/16 1 Simulation PAT et pare-feu sans état Dans cette partie, nous allons travailler sur le PAT et sur les règles de filtrage d un firewall sans état à l aide du simulateur de Pierre Loisel (CERTA). Exercice 1 (Lancement d une VM XP pour le simulateur) 1. Ouvrir un terminal sur le poste de travail Linux et lancer une machine virtuelle XP en exécutant mkwxpnat.bash 2. Sur la VM XP, ouvrir un navigateur pour aller sur le site et télécharger le fichier reseau_depart.xml. 3. Lancer le simulateur de Pierre Loisel (icône sur le bureau) et charger le fichier téléchargé. La fenêtre du simulateur devrait apparaître ainsi : où, en bas à droite, deux vlans auxquels appartient st9 séparent les stations st10 à st14. D un point de vue IP, ce lab est constitué des réseaux IP suivants : Pas besoin de corrigé... en haut à gauche le réseau /24 contient st1 ( ) et st2 ( ) ; en bas à gauche, le réseau /24 contient st1 ( ), st3 ( ) et st4 ( ) ; st1 est un routeur qui interconnecte ces 2 réseaux. Le FAI qui le relie à Internet lui a attribué l adresse ; en haut à droite le réseau /24 constitué de st5 ( ), st6 ( ), st7 ( ) et st8 ( ). st5 est un routeur d accès à Internet auquel son FAI a attribué l adresse ; C. Pain-Barre - 30/11/2015

3 3/16 Enoncé du TP 4 UE31 - M3102 : Services Réseaux st2 st6 st st st8 liaison point à point / st liaison accès FAI / FAI1 Internet FAI2 liaison accès FAI / liaison accès FAI / st /24 st / / st /24 st3 st st14 st10 st12 FIGURE 1 Organisation IP du lab en bas à droite les switchs sw3 et sw4 séparent les stations en 2 vlans 1 donnant 2 réseaux IP : le vlan 5 forme le réseau /24 contenant st9 ( ), st11 ( ) et st13 ( ) le vlan 6 forme le réseau /24 contenant st9 ( ), st10 ( ), st12 ( ) et st14 ( ) st9 est un routeur qui interconnecte ces 2 réseaux. Le FAI qui le relie à Internet lui a attribué l adresse Tous les équipements sont déjà configurés, notamment les tables de routage de st1, st5 et st9. La figure 1 schématise l organisation IP de ce lab, où apparaissent aussi les réseaux des 2 FAI. Adressage public/privé dans le simulateur Les stations st1, st5 et st9 sont connectées aux FAI par des cartes d accès (modem) et ont obtenu des adresses publiques (commençant par ou par ), routables à travers l objet représentant Internet (qui contient les FAI ayant leur propres adresses publiques). Toutes les autres adresses du lab (commençant par ) sont privées : elles sont inconnues de ces FAI et ne sont pas routables à travers cet Internet. Exercice 2 (Tests d accessibilité) Dans le simulateur : 1. Passer en Mode IP et sélectionner Simulation ARP/IP : pas de démonstration 2. En effectuant un clic droit sur st6, envoyer un ping à st5 qui doit réussir (st5 renvoie l ECHO REPLY) 3. Depuis st3, envoyer un ping à st2. Cela doit fonctionner. 4. Depuis st1, envoyer un ping à st5. Cela doit fonctionner! 1. Ces vlans sont de niveau 2 (par MAC), ce qui n a pas vraiment d importance pour le sujet traité. 30/11/ C. Pain-Barre

4 UE31 - M3102 : Services Réseaux Enoncé du TP 4 4/16 5. Depuis st5, envoyer un ping à st9. Cela doit aussi fonctionner Depuis st6, envoyer un ping à st1. Cela échoue! Expliquer ce qu il se passe. Activation du PAT Exercice 3 (Simulation PAT) 1. Se placer en mode Transport. Effectuer un clic droit sur st5, sélectionner Configuration IP, puis : (a) cocher la case Nat/Pat qui active en réalité le PAT (b) et sélectionner l interface publique ppp qui devra servir à la traduction d adresse. 2. Faire un clic droit sur st6, sélectionner Envoyer un requête, et choisir ICMP pour envoyer une requête (ping) à st1. Durant la simulation, observer les adresses IP du datagramme et la traduction opérée par st5 (si besoin, mettre en pause ou cliquer sur bis pour refaire la simulation) qui remplace l adresse privée de st6 par sa propre adresse publique 3. Faire un clic droit sur st5, choisir Tables et sélectionner Table Nat/Pat. Son contenu devrait être similaire à : car la NATBox st5 doit garder trace de la traduction opérée. 4. Faire un clic droit sur st1 et choisir Répondre à une requête. La fenêtre qui s affiche devrait ressembler à : C. Pain-Barre - 30/11/2015

5 5/16 Enoncé du TP 4 UE31 - M3102 : Services Réseaux On peut à nouveau observer que pour st1, la requête provient de st5 et non de st6. Envoyer la réponse et observer la traduction inverse opérée par st5 quand il transmet le datagramme à st6. 5. Une fois la réponse reçue, afficher la Table Nat/Pat de st5 qui a dû être vidée. i Dans le simulateur, la réception de la réponse simule la fin d un dialogue. 6. Comme pour st5, activer aussi le PAT sur st1 et st9. 7. Envoyer (comme précédemment) des requêtes ICMP tout en observant les traductions : (a) de st2 vers st9 (b) de st11 vers st1 (c) de st14 vers st5 et observer les tables de traduction, notamment celle de st9 qui contient 2 entrées. 8. Faire répondre st9, st1 et st5. Les réponses doivent parvenir respectivement à st2, st11 et st14. Exercice 4 (Simulation de serveurs et problème d accès) 1. Nous allons maintenant simuler la présence de quelques serveurs. Toujours en Mode Transport : (a) Faire un clic droit sur st2 puis choisir Tables Ports écoutés et ajouter le port UDP 69 afin de simuler un serveur TFTP : (b) Sur st3 simuler un serveur SSH (port TCP 22) (c) Sur st8 simuler un serveur FTP (port TCP 21) (d) Sur st12 simuler un serveur HTTP (port TCP 80) 30/11/ C. Pain-Barre

6 UE31 - M3102 : Services Réseaux Enoncé du TP 4 6/16 (e) Sur st13 simuler un serveur DNS (port 53 UDP et TCP) (f) Sur st14 simuler un serveur SMTP (port TCP 25) et un serveur POP3 (port TCP 110) (g) Sur st1 simuler un serveur SSH (port TCP 22) 2. Tester l accès aux serveurs (envoi d une requête et de la réponse) : (a) depuis st3 vers TFTP de st2 (b) depuis st6 vers FTP de st8 (c) depuis st13 vers serveur Web (HTTP) de st12 (d) depuis st6 vers SSH de st1 (e) depuis st6 vers serveur Web (HTTP) de st12. Expliquer pourquoi cet accès ne fonctionne pas. Exercice 5 (PAT statique pour accès aux serveurs) Pour accéder aux serveurs depuis Internet, il est nécessaire de configurer des traductions de port statiques (ou redirections de ports) sur les NATBox st1, st5 et st9 : 1. Configurer st1 pour que l accès au serveur TFTP de st2 soit possible depuis Internet. Pour cela, en mode Transport, faire un clic droit sur st1 puis choisir Tables Table Nat/Pat et ajouter un entrée statique pour le serveur de st2 en renseignant cette nouvelle ligne de la table : le protocole de transport : TCP ou UDP l adresse IP privée du serveur : celle de st2 le port privé du serveur : celui sur lequel il est en écoute l adresse IP publique : celle de st1 le port public : éventuellement différent que le port privé 2. Vérifier que le serveur de st2 est joignable depuis st6 en émettant une requête et en renvoyant la réponse. i On rappelle que l envoi de la requête doit se faire vers l IP publique et le port public du serveur ; pas avec ses adresses privées... Observer les différentes traductions opérées par st5 (dynamique) et par st1 (statique). 3. Configurer st5 pour que l accès au serveur FTP de st8 soit possible depuis Internet. Vérifier son accessibilité depuis st3. 4. Configurer st9 pour que l accès aux serveurs de st12, st13 et st14 soit possible depuis Internet. Vérifier leur accessibilité depuis st2 et st8. 5. Configurer st1 pour que l accès au serveur de st3 soit possible tout en gardant l accès à son propre serveur SSH. C. Pain-Barre - 30/11/2015

7 7/16 Enoncé du TP 4 UE31 - M3102 : Services Réseaux 1.1 Pare-feu sans état Exercice 6 (PAT statique pour accès aux serveurs) 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. 1. Configurer les règles de st9 pour que : (a) tout le monde extérieur puisse atteindre le serveur DNS de st13 et le serveur SMTP de st14 (b) seul st1 (ce qui inclut les stations st2, st3 et st4) puisse atteindre le serveur POP (de st14) (c) seul st5 et les stations de /24 sauf st11 puisse atteindre le serveur HTTP de st12 (d) laisser passer en entrée tout le trafic ICMP extérieur (e) laisser le trafic sortant passer (f) bloquer tout trafic entrant en direction de serveurs mais laisser passer le trafic pour les clients des réseau /24 et /24. Le simulateur ne permettant pas d utiliser des intervalles de ports, on supposera que ces clients n utilisent que les services SSH et HTTP sur Internet. 2. 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 et en vérifiant que les clients internes puissent accéder aux services d Internet. 30/11/ C. Pain-Barre

8 UE31 - M3102 : Services Réseaux Enoncé du TP 4 8/16 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) 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 2 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) : C. Pain-Barre - 30/11/2015

9 9/16 Enoncé du TP 4 UE31 - M3102 : Services Réseaux FORWARD PREROUTING Routage POSTROUTING INPUT OUTPUT Processus local FIGURE 2 Chaînes de Netfilter 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 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 30/11/ C. Pain-Barre

10 UE31 - M3102 : Services Réseaux Enoncé du TP 4 10/16 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). 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... C. Pain-Barre - 30/11/2015

11 11/16 Enoncé du TP 4 UE31 - M3102 : Services Réseaux srv2 srv1 G1 [4] /24 [0] d2 [0] d1 d11 [2] [1] S2 [4] [3] [2] S1 [4] S3 [1] d5 d6 d8 d4 [3] [1] d3 d7 [2] [3] d10 d9 [0] pt1 pt2 pt3 firewall host2 host1 [0] [0] WindowsXP ( ) [1] [0] [2] [0] [0] FIGURE 3 Présentation du lab Marionnet pour le pare-feu 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 chaîne FORWARD afin de configurer un pare-feu pour filtrer des flux qui transiteront par lui. Exercice 7 (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 3, ce lab est constitué de 3 réseaux et de 8 hôtes : 30/11/ C. Pain-Barre

12 UE31 - M3102 : Services Réseaux Enoncé du TP 4 12/16 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 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 8 (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 C. Pain-Barre - 30/11/2015

13 13/16 Enoncé du TP 4 UE31 - M3102 : Services Réseaux 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 9 (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 10 (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 30/11/ C. Pain-Barre

14 UE31 - M3102 : Services Réseaux Enoncé du TP 4 14/16 Exercice 11 (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 la porte dérobée ;-) i On rappelle qu on ne maîtrise pas vraiment la gestion des adresses des portes dérobées par Marionnet. Si cette adresse ne mène pas à srv1, sur un terminal de srv1 taper : m1# unghostify eth42 afin de rendre "visible" son interface eth42 puis utiliser ifconfig pour connaître la bonne IP. (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 C. Pain-Barre - 30/11/2015

15 15/16 Enoncé du TP 4 UE31 - M3102 : Services Réseaux Exercice 12 (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 13 (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 30/11/ C. Pain-Barre

16 UE31 - M3102 : Services Réseaux Enoncé du TP 4 16/16 Exercice 14 (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 15 (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 16 (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" C. Pain-Barre - 30/11/2015