Travaux pratiques protocoles avancés |
Cet atelier consiste en la réalisation d’une maquette de réseau permettant de manipuler les protocoles de redondance réseau ainsi que le protocole réseau IPv6. D’un point de vue système vous aurez à installer une machine virtuelle Xen et à y configurer des services. Enfin la mise en place d’un réseau WiFi sécurisé et d’un site web sécurisé vous permettent de mettre en pratiques vos connaissances en la matière.
Vous devez installer le système de votre machine virtuelle. Le client WiFi vient avec un système installé, il vous faudra simplement configurer une clef USB/WiFi.
Créez une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info (mot de passe administrateur habituel). Pour la création de la machine virtuelle utilisez la commande xen-create-image. Il vous faut préciser à cet utilitaire le nom de votre machine (choisissez un thème commun), son adresse IP (dans le réseau IP 193.48.57.160/27), l’adresse du routeur et le répertoire où les disques virtuels doivent être créés (imposez /usr/local/xen). Ca marche mieux en indiquant comme miroir Debian celui de l’école et comme distribution la distribution stable courante. Vous modifierez le fichier de configuration de la machine virtuelle pour faire en sorte que les répertoires var et home de la machine virtuelle soient sur des partitions LVM de l’hôte. Installez les paquetages nécessaires pour SSH, le serveur Web apache2 et le serveur DNS bind (voir la partie services).
Cette section détaille la maquette du réseau que vous devez réaliser.
Votre réseau doit être redondant. Pour cela vous utiliserez trois routeurs/commutateurs et deux points d’accès WiFi. Les deux premiers routeurs implantent le réseau local et permettent d’accèder au fournisseur d’accès à Internet principal. Le troisième routeur permet d’accèder au fournisseur d’accès à Internet secondaire. Les points d’accès WiFi sont connectés sur les deux premiers routeurs. Sur ces deux routeurs, l’un est présent pour assurer la continuation de service si le premier tombe.
Le serveur de virtualisation doit être connecté aux deux premiers commutateurs.
Vous avez à votre disposition un réseau IPv4 routé : 193.48.57.160/27 (dans le VLAN 110 de l’école soit TP-NET1). Vous allez découper ce réseau en deux sous-réseaux. Un pour vos machines virtuelles des IMA5/SE5 sous statut étudiant, un pour les machines virtuelles des IMA5/SE5 par apprentissage. Vous utiliserez aussi un réseau IPv4 non routé, par exemple 10.60.0.0/16). Chaque binôme doit recevoir un sous-réseau de ce réseau privé dans lesquels il pourra connecter son client WiFi. Il est demandé d’établir un tableau listant tous les VLAN de votre réseau avec les adresses IPv4 et IPv6 utilisées par les routeurs dans chaque VLAN.
Routez vos VLANs locaux à l’aide des Cisco 6509E et Cisco 9200 (comme matériel de secours). Utilisez le Cisco ISR 4331 pour accèder aux fournisseurs d’accès secondaires. La configuration des routeurs doit initialement se faire leurs ports série ; utilisez minicom sur un ordinateur Linux pour y accéder. Vérifiez que vous avez une connexion entre les différents types de machines.
Configurez votre routeur pour permettre à vos machines de se construire des adresses IPv6. Utilisez les préfixes IPv6 de Polytech’Lille non encore en service (2001:660:4401:60a0::/60 pour une promotion et 2001:660:4401:60b0::/60 pour l’autre). Pour vous aider, voici un extrait de configuration IPv6 sur une interface du routeur de la plateforme maths/info :
interface ... ... ipv6 enable ipv6 address 2001:660:4401:60A0::/64 eui-64 ipv6 nd prefix 2001:660:4401:60A0::/64 1000 900 ipv6 nd router-preference high ... !
En ce qui concerne la configuration globale un simple
ipv6 unicast-routing
va faire l’affaire.
Interconnectez votre routeur de site avec celui de la plateforme. Vous utiliserez comme VLAN d’interconnexion, le VLAN 530 (INTERCO-4A) associé au réseau IPv4 192.168.222.64/29 ou le VLAN 531 (INTERCO-5A) associé au réseau IPv4 192.168.222.72/29. Choisissez suivant votre promotion. Le routeur de la plateforme utilise la première adresse disponible.
Faites en sorte que les deux routeurs s’échangent leurs routes par le protocole de routage OSPF. Pour vous donner une base de départ voici la configuration OSPF du routeur de la plateforme :
router ospf 1 router-id 192.168.222.4 summary-address 192.168.0.0 255.255.0.0 summary-address 193.48.57.160 255.255.255.224 redistribute connected subnets ! subnets allowed redistribute static subnets route-map ospf ! subnets allowed network 192.168.222.64 0.0.0.7 area 10 network 192.168.222.72 0.0.0.7 area 20 default-information originate !
Attention vos réseaux locaux ne doivent pas sortir par OSPF, rajoutez donc un filtre dans le bloc OSPF, par exemple :
router ospf 1 ... summary-address 10.0.0.0 255.0.0.0 not-advertise ... !
Jouez sur l’option metric de la commande redistribute pour faire en sorte que le 6509E soit l’élément IPv4 prioritaire de votre réseau.
Les VLAN d’interconnexion pour IPv6 sont les mêmes que pour IPv4. Les réseaux IPv6 utilisés sur INTERCO-4A et INTERCO-5A sont le réseau local IPv6 standard FE80::0/10. Le routeur de la plateforme utilise la première adresse disponible.
Pour interconnecter votre routeur avec celui de l’école, en ce qui concerne IPv6 cette fois, vous utiliserez RIPv6. Pour vous donner une base de départ voici la configuration RIPv6 du routeur de la plateforme concernant votre réseau de travaux pratiques :
ipv6 router rip tpima5sc redistribute connected metric 1 redistribute rip 1 metric 1 redistribute static metric 1 !
Il existe le même bloc avec le nom tpima2a5.
N’oubliez pas d’activer le protocole RIPv6 sur l’interface interconnexion avec une commande du style ipv6 rip tpima5sc enable.
Testez votre connectivité IPv6 en utilisant google.
Jouez sur l’option metric de la commande redistribute pour faire en sorte que le 6509E soit l’élément IPv6 prioritaire de votre réseau.
Pour rendre votre réseau plus robuste, faites en sorte que les machines utilisent un routeur actif en implantant le protocole VRRP sur vos routeurs. Pour vous donner une idée de départ voici une configuration VRRP typique :
RTR-A(config)# int fa0/1 RTR-A(config-if)# ip address 10.10.10.1 255.255.255.0 RTR-A(config-if)# vrrp 1 ip 10.10.10.3 RTR-A(config-if)# vrrp 1 preempt RTR-A(config-if)# vrrp 1 priority 110 RTR-B(config)# int fa0/1 RTR-B(config-if)# ip address 10.10.10.2 255.255.255.0 RTR-B(config-if)# vrrp 1 ip 10.10.10.3 RTR-B(config-if)# vrrp 1 preempt RTR-B(config-if)# vrrp 1 priority 100
Sous IOS XE, la syntaxe diffère en ce qu’il existe un mode de configuration vrrp et que le mot clef ip devient address mais vous devez pouvoir vous adapter.
Comment le routeur de la plateforme connaitra le routeur à utiliser pour contacter vos machines ?
Pour certains matériels cisco les commandes ci-dessous peuvent aider :
license boot level network-advantage fhrp version vrrp v3
Proposez un schéma pour que le flux IPv4 puisse passer par la liaison SDSL.
Les réseaux d’interconnexion avec le routeur de la liaison SDSL sont sur les VLAN 532 (INTERCO-1B) et VLAN 533 (INTERCO-2B). Les réseaux IPv4 sur ces VLAN sont 192.168.222.80/29 et 192.168.222.88/29. Le routeur de la plateforme utilise les plus basses adresses IPv4 utilisables sur ces réseau.
Si vous n’avez pas d’inspiration, une méthode est suggérée mais il en existe certainement d’autres :
Proposez un schéma pour que le flux IPv6 puisse passer par la liaison SDSL de secours.
Les réseaux d’interconnexion avec le routeur de la liaison SDSL sur sur les mêmes VLAN qu’en IPv4. Sur ces VLAN, le routeur SDSL a l’adresse IPv6 FE80::1. Les réseaux IPv6 2001:7A8:116E:60A0::/60 et 2001:7A8:116E:60B0::/60 sont routés vers les deux VLAN d’interconnexion.
Pour IPv6, l’idée est faire en sorte que chaque machine virtuelle ait une adresse IPv6 statique dans les réseaux sus-cités. L’ISR4331 se contente de faire un routage statique vers le routeur SDSL. Par contre sur la machine virtuelle, il faut une politique de routage par la source (voir la commande ip rule) pour utiliser l’ISR4331 comme routeur.
Autre difficulté : les adresses IPv6 délivrées par les routeurs principaux seront encore actives. Une solution est d’insérer avec le mécanisme SLA une route pour les adresses IPv6 RENATER vers l’ISR4331 et de mettre en place un vrai NAT sur l’ISR4331 entre le préfixe IPv6 RENATER et le le préfixe IPv6 SDSL.
Il vous est demandé de sécuriser des services réseau.
Votre machine virtuelle Xen et votre eeePC doivent être accessible par SSH.
Vous allez réserver votre nom de domaine pour associer un nom DNS à chacune de vos adresses IP (les zones inverses doivent, elles aussi, être gérées). Il est suggéré d’utiliser le registrar Gandi (http://www.gandi.net). Une fois le nom de domaine reservé, configurez bind (paquetage bind9) sur votre serveur virtuel Xen pour donner les adresses IPv4 et IPv6 correspondant à vos noms de machines. Utilisez l’interface web de votre fournisseur pour paramétrer votre machine comme serveur DNS principal. Créez une machine virtuelle EC2 d’amazon pour servir de serveur DNS secondaire. Vous pouvez utiliser ns6.gandi.net comme autre serveur secondaire.
Par la suite mettez en place vos zones inverses qui permettent de trouver vos noms en fonction de vos adresses IP. Pour l’instant ce n’est possible que pour les adresses IPv6 de la connexion SDSL secondaire. Demander aux encadrants pour réaliser les délégations vers vos serveurs DNS.
Sur la machine virtuelle, configurez apache2 (paquetage du même nom) en mode sécurisé à l’aide d’une clef asymétrique et d’un certificat signé par une autorité de certification (CA). Comme CA, il est conseillé d’utiliser aussi Gandi. Le CA signe un CSR (Certificate Signing Request), vous allez créer vos clefs et le CSR en utilisant openssl (vous pouvez vous aider du Wiki de Gandi). Une fois le CSR signé par le CA et donc transformé en un certificat vous pourrez configurer apache2 pour gérer du HTTPS sur le port 443. Dans la définition du serveur virtuel pour ce port, il faut insérer la ligne de configuration SSLEngine on. Il faut aussi préciser où se trouve la clef privée du serveur via le mot clef SSLCertificateKeyFile et où se trouve le certificat via le mot clef SSLCertificateFile. Il est aussi conseillé de définir la chaîne de certification avec SSLCertificateChainFile.
Sécurisez votre serveur DNS en signant la zone correspondant à votre nom de domaine. Vous pouvez vous appuyer sur le document http://www.bortzmeyer.org/jres-dnssec-2009.html pour réaliser la sécurisation. Testez votre configuration avec l’option DNSSEC de l’outil http://www.zonecheck.fr.
Pour entrer dans les détails, vous allez devoir effectuer les opération suivantes.
dnssec-keygen -a RSASHA256 -b 2048 -f KSK -n ZONE <nom_de_zone>
dnssec-keygen -a RSASHA256 -b 1024 -n ZONE <nom_de_zone>
$include /etc/bind/<nom_de_zone>.dnssec/<nom_de_zone>-ksk.key $include /etc/bind/<nom_de_zone>.dnssec/<nom_de_zone>-zsk.key
dnssec-signzone -o <nom_de_zone> -k <nom_de_zone>-ksk ../<nom_de_zone> <nom_de_zone>-zsk
Vérifiez dans les fichiers de contrôle de votre machine virtuelle que le port ssh est bien sujet à des attaques par force brute.
Installez un système pour bannir les machines sources des attaques les plus patentes (avec l’utilitaire fail2ban par exemple).
Traitez aussi les attaques sur votre serveur DNS (via le protocole TCP uniquement).
Installez un conteneur contenant un serveur minecraft classique. Pour cela utilisez un conteneur docker déjà configuré.
Personnalisez votre serveur avec un mécanisme en "red stone" implantant soit un incrémenteur de pas 1, soit un décalage à gauche avec repliement, les deux sur 8 bits.
Vous allez testez dans cette section les méthodes de sécurisation du WiFi.
Récupérez des programmes d’exploitation de failles dans le système Linux. Essayez ces programmes sur votre eeePC en tant qu’utilisateur pifou. Si votre noyau n’est pas concerné par ces failles, installez un noyau plus ancien.
Repérez le nom du réseau sans fil correspondant à votre binôme (réseau diffusé par le point d’accès Cisco présent dans la salle). Installez le paquetage aircrack-ng et utilisez-le pour trouver la clef WEP associée à votre réseau. Il faudra commencer par trouver le point d’accès (canal, nom des réseaux) puis écouter les trames WiFi avec airodump-ng (la carte WiFi étant passée en mode monitor à l’aide de l’utilitaire airmon-ng). Eventuellement vous pouvez simuler une association entre votre eeePC et le point d’accès (utilisez aireplay-ng). Cela vous permettra de rejouer des trames WiFi pour augmenter le trafic avec le point d’accès (toujours avec aireplay-ng). Une fois suffisament de trames échangées, lancez l’algorithme de craquage de la clef Wep (aircrack-ng).
Utilisez les outils du paquetage aircrack-ng pour lancer une recherche sur le mot de passe de l’identification par WPA-PSK. Repérez le nom du réseau sans fil correspondant à votre binôme (réseau diffusé par le point d’accès Cisco présent dans la salle). Capturez des dialogues d’identification WPA avec airodump-ng. Attention pour capturer ces paquets d’identification vous devez être à bonne distance du point d’accès et des interfaces WiFi de l’eeePC du banc d’essai. L’utilitaire indique en haut de son affichage si de telles trames sont capturées. Une fois chose faite, lancez aircrack-ng pour tenter de craquer la clef WPA. Le craquage doit se faire avec l’aide d’un dictionnaire. On va donc supposer que la clef WPA est un nombre sur 8 chiffres. En conséquence, créez un dictionnaire de toutes les clefs de ce format et lancez aircrack-ng.
Installez le paquetage dsniff sur votre eeePC. Transformez votre eeePC en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1. Insérez votre eeePC entre la machine fixe d’un autre binome et le routeur utilisé par cette machine fixe en utilisant la commande arpspoof. Lancez le sniffeur réseau wireshark sur l’eeePC pendant que l’autre binôme se connecte sur un site web HTTP avec des formulaires HTML. Que constatez-vous ? Essayez aussi de relever les paquets réseau pendant que l’autre binôme utilise un logiciel de conversation instantanée.
Créez une autre machine virtuelle uniquement accessible sur le réseau des stations de projet.
Concevez et réalisez une application Web sur cette machine en utilisant le serveur Web de votre choix, les briques logicielles de votre choix et le langage de votre choix.
La fonctionnalité de l’application est aussi laissée à votre choix mais elle doit respecter les contraintes suivantes :
Une fois votre application réalisée trouvez d’éventuelles failles dans les applications des autres binômes pour arriver à les pirater. Les failles seront classées suivant l’échelle ci-dessous :
Concevez et réalisez un programme C de type coffre-fort de mots de passe. Chaque enregistrement du coffre-fort est un triplé comprenant le descriptif de l’entrée, l’identifiant et le mot de passe correspondant. Ces enregistrements ne doivent pas être stockés de façon externe mais dans le segment de données de votre programme. Le programme ne fait qu’afficher les enregistrements pour peu qu’un mot de passe global soit correctement tapé par l’utilisateur.
Le but du binôme est de réaliser le programme le plus robuste et sécurisé possible. Le but des autres binôme est de casser le programme et d’accéder aux enregistrements. Chaque binôme est tenu de distribuer, sur sa page Wiki, son exécutable mais aussi la source du programme C avec le mot de passe global laissé vide (chaîne vide) et la liste des enregistrements elle aussi vide.
Dans cette dernière section vous devez réaliser des infrastructures réseau.
Pour votre serveur Xen créez trois partitions LVM de 1Go avec des noms liés à celui de votre serveur. Ajoutez ces partitions à la définition de votre machine virtuelle, relancez la et créez un RAID5 logiciel avec les trois partitions obtenues (utilisez le paquetage mdadm). Copiez des données sur le RAID5, arrêtez la machine virtuelle, retirez lui une des trois partitions, relancez la. Essayez de remonter votre RAID5, que constatez-vous ?
Sur votre eeePC installez les paquetages lvm2 et cryptsetup. Faites en sorte de créer une unique partition sur la carte SD de l’eeePC. Sécurisez la partition en utilisant l’utilitaire cryptsetup, créez un système de fichier au dessus de la partition sécurisée (faite un tour dans /dev/mapper pour trouver le périphérique correspondant) et montez le. Ajoutez des données sur ce système de fichiers, démontez-le, échangez votre carte SD avec celle d’un autre binôme et tentez de lire le contenu.
Isolez des machines sensibles pour éviter une attaque de type "homme au milieu" par usurpation ARP. L’idée est de configurer des ports d’un élément de sécurité Cisco (ASA 5506) en mode commutateur et d’activer l’inspection ARP entre les ports commutés. Vérifiez la bonne configuration en répétant l’attaque. Lisez les fichiers de contrôle pour vous assurer que l’attaque a été repérée.
Le but est de faire en sorte que l’accès à la borne WiFi soit controlé par WPA2-EAP. L’identification va se faire en utilisant le même serveur FreeRadius que pour la sécurisation filaire. En résumé vous devez :
aaa new-model aaa authentication login eap_group1 group radius_group1 radius-server host <ip_group1> auth-port 1812 acct-port 1813 key secret_group1 aaa group server radius radius_group1 server <ip_group1> auth-port 1812 acct-port 1813 ! aaa authentication login eap_group2 group radius_group2 radius-server host <ip_group2> auth-port 1812 acct-port 1813 key secret_group2 aaa group server radius radius_group2 server <ip_group2> auth-port 1812 acct-port 1813 ! ... dot11 ssid SSID_GROUP1 vlan 101 authentication open eap eap_group1 authentication network-eap eap_group1 authentication key-management wpa ! dot11 ssid SSID_GROUP2 vlan 102 authentication open eap eap_group2 authentication network-eap eap_group2 authentication key-management wpa ! ... interface Dot11Radio0 encryption vlan 101 mode ciphers aes-ccm tkip encryption vlan 102 mode ciphers aes-ccm tkip ... ! ...
(Cisco Controller) config sysname WLC1 (Cisco Controller) config prompt WLC1 (WLC1) config interface create vlang1 101 (WLC1) config interface port vlang1 1 (WLC1) config interface address dynamic-interface vlang1 10.60.1.10 255.255.255.0 10.60.1.1 (WLC1) config wlan create 1 "SSID G1" SSID_G1 (WLC1) config wlan interface 1 vlang1 (WLC1) show wlan summary (WLC1) config radius auth add 1 193.48.57.164 1812 ascii <secret_group1> (WLC1) config wlan radius_server auth add 1 1 (WLC1) config wlan aaa-override enable 1 (WLC1) config wlan security wpa enable 1 (WLC1) config wlan security wpa wpa2 enable 1 (WLC1) config wlan security wpa wpa1 disable 1 (WLC1) config wlan security wpa wpa2 ciphers aes enable 1 (WLC1) config wlan security wpa wpa2 ciphers tkip disable 1 (WLC1) config wlan security wpa akm 802.1x enable 1 (WLC1) config wlan broadcast-ssid enable 1 (WLC1) config wlan enable 1 (WLC1) save config
Il vous est demandé d’implanter une architecture d’équilibrage de charge pour un site Web.
Chaque binôme doit installer une seconde machine virtuelle Xen qui hébergera un serveur Web par binôme. Ainsi chaque binôme pourra disposer de plusieurs serveurs Web proposant exactement le même site sur plusieurs machines différentes. Ces serveurs Web ne seront pas directement disponibles d’Internet mais au travers d’un équilibreur de charge tournant sur leur machine virtuelle principale.
Pour la connexion internes entre les machines virtuelles utilisez le VLAN des machines de projet. Sur les serveurs capbreton et chassiron ce VLAN est accessible via le commutateur virtuel bridgeStudents. Utilisez un réseau IPv4 quelconque sur ce VLAN, pourquoi pas 192.168.42.0/24 ? Pensez à ajouter simplement une seconde interface sur le VLAN interne à vos machines virtuelles principales.
Mettez aussi une mascarade en place sur votre machine principale pour permettre à votre machine secondaire d’avoir un accès à Internet.
Vous allez configurer vos serveurs Web internes avec le système ansible à partir de votre machine virtuelle principale. Commencez donc par installer ansible sur cette machine. Générez vos clefs et propagez la clef publique sur l’ensemble des serveurs Web internes (sans supprimer celles des autres groupes). Créez un inventaire dans /etc/ansible/hosts en séparant l’ensemble des serveurs internes et le votre propre. Testez votre configuration en lançant la commande lsb_release -d avec l’utilitaire ansible sur toutes les machines de l’inventaire.
Créez un rôle ansible maison pour configurer /etc/motd et la configuration NTP complète (installation des paquetages et copie des fichiers de configuration) sur votre machine secondaire. Le serveur NTP de la plateforme informatique est ntp.plil.info.
Il est demandé d’implanter les serveurs Web sur les machines virtuelles de la ferme de serveurs Web sous la forme de conteneurs docker.
Il vous est demandé d’effectuer cette installation du système docker en utilisant le système ansible à partir de votre machine virtuelle principale. N’hésistez pas à chercher un rôle adapté déjà existant :
Votre "playbook" ne doit installer docker que sur votre propre machine virtuelle secondaire.
En utilisant un dockerfile vous allez créer un conteneur basé sur le conteneur httpd. Votre conteneur doit intégrer tous les fichiers de votre site Web et démarrer apache2 automatiquement sur le port HTTP 80 classique.
Il est conseillé de créer ce conteneur sur votre machine virtuelle principale après installation de docker. Il est recommandé une installation manuelle à base de wget ou de curl sur l’URL get.docker.com.
Déployez un dépôt docker local sur votre machine secondaire en construisant un rôle ansible sur votre serveur principal.
Ajoutez votre conteneur à votre dépot local. Vous aurez à autoriser l’utilisation d’un dépot non sécurisé (HTTP et non HTTPS).
Créez un nouveau rôle ansible pour déployer votre conteneur Web sur tous les serveurs Web internes. Lors du lancement des conteneurs, utilisez un numéro de port alloué à votre binôme pour exposer le port 80 de votre conteneur.
Chacun des serveurs internes devra pouvoir utiliser un dépôt docker non sécurisé. Ajoutez à votre rôle la copie du fichier de configuration qui permet cela. En fin de tâche de copie déclenchez un gestionnaire (handler) pour relancer le service docker.
Ajoutez un serveur Web virtuel sur votre machine virtuelle principale. Vous devez donc ajouter un nouvel enregistrement de type CNAME dans votre DNS. Le second site Web doit se comporter à la fois comme un serveur mandataire inverse (reverse proxy) et comme un équilibreur de charge (load balancer).
Pour la fonction mandataire inverse, activez les modules Apache proxy et proxy_http. Dans le fichier de configuration du site vous devez ajouter des directives ProxyPass et ProxyPassReverse.
Pour la fonction équilibrage de charge, il faut activer les modules proxy_balancer et lbmethod_byrequests. Dans le fichier de configuration du site il faudra ajouter une balise Proxy listant les différents serveurs Web internes et lier cette balise aux directives de redirection (mandataire inverse).
Vous testerez le bon fonctionnement de votre architecture en utilisant le gestionnaire de répartition qui peut être intégré au serveur de redirection (module mod_status).
Ce document a été traduit de LATEX par HEVEA