Table des matières

1. Objectifs

iptables -A INPUT -s 192.168.0.4 -j DROP Nous allons, dans le cadre des TP, étudier un petit réseau d’entreprise simplifié et construire progressivement les différents services qu’il propose à ses clients.

Il s’agit du réseau interne de l’entreprise WoodyToys.  Dans un souci de simplification, ce réseau sera simplement modélisé par un subnet sur lequel seront connectés à la fois les clients et les serveurs.  Vous avez déjà vu ou verrez que ce n’est pas une infrastructure utilisable dans un réseau réel, puisqu’il faut une isolation entre les différents types de machines.  

Dans ce premier TP, nous allons permettre aux PCs des employés (ici, le directeur et l’atelier)  d’obtenir une connectivité Internet via la configuration d’un service DHCP et d’une résolution DNS.  Cela se fera via les logiciels dhcpd et bind9. 

Il comporte 3 étapes : 

  1. Observation et découverte du labo GNS3
  2. Configuration du service DHCP
  3. Mise en place d’un résolveur Bind 

A la fin de ce TP, vous devrez : 

  • Savoir utiliser Wireshark et dig à bon escient pour observer le fonctionnement (correct ou non) d’un service de résolution DNS
  • Avoir compris le rôle du DHCP dans un réseau
  • Avoir compris le rôle du DHCP dans la mise en place d’un résolveur DNS
  • Savoir retrouver les fichiers de configuration principaux de dhcpd et bind, pouvoir les modifier, recharger le service et vérifier le bon fonctionnement du service modifié
  • Avoir compris la différence entre requête itérative et récursive, et comprendre le rôle du résolveur.
  • Etre à l’aise avec les directives principales de dhcpd
  • Etre à l’aise avec les directives principales de bind en mode résolveur
  • Pouvoir expliquer les opérations réalisées par bind lorsqu’il effectue de la résolution DNS, et les informations qu’il utilise pour ça (serveurs racines notamment).

2. Démarrage et observation du réseau GNS3

Pour simuler le réseau interne simplifié de l’entreprise WoodyToys , nous allons utiliser la machine virtuelle GNS3-Admin-I-2024, que vous pouvez télécharger ici.  Démarrez-là, puis lancez le labo “Labo-Admin-I-2024-base” dans GNS3. Le mot de passe pour le compte GNS3 est “user123”.   

Découverte GNS3

Prenez d’abord un peu le temps d’examiner l’interface GNS3 : le labo est un ensemble de machines (clients ou serveurs) connectées ensemble via un switch.  

reseau-woodytoys.png

Les machines sont séparées en deux zones : à gauche, deux machines représentent des postes clients, tandis qu’à droites ont regroupés les machines qui joueront le rôle de serveur. Chaque machine est dédiée à un unique service. Les machines ont une potentielle connectivité Internet via un routeur connecté vers l’extérieur.

Dans chaque machine, vous pouvez : 

  • Examiner et modifier la configuration réseau via un clic-droit => Edit config. 
    • Les clients doivent être configurés en dhcp
    • Les serveurs doivent avoir une IP fixe. 
  • Lancer une console (clic-droit => Console, ou Console auxiliaire si la principale ne répond pas) 
  • Utiliser les différents outils de diagnostic : ping, traceroute, netstat, nmap, ifconfig, dig, nslookup, …

Les clients possèdent en outre tout ce qu’il faut pour tester chaque service en ligne de commande : Un client dhcp, un client dns (dig), un client web (links) et un client mail (mutt).

Il est également possible de lancer une capture Wireshark depuis chacun des liens du réseau. Pour cela, cliquez-droit dessus et choisissez “start capture”.  Wireshark s’ouvre et affiche les paquets qui sont circulent sur ce lien spécifique.  

Vous n’avez normalement pas à modifier le labo en lui-même (ajout de machines ou de liens), mais notez que vous pouvez le faire facilement via la barre verticale d’icônes sur votre gauche/

Observation du réseau

Démarrez la simulation, et examiner la configuration des différentes machines ou utilisez Wireshark pour répondre aux questions suivantes : 

  1. Y a-t’il des adresses IP attribuées?  A qui, et quelles sont-elles?  Qu’en est-il de la connectivité Internet (ex : ping 1.1.1.1)?
  2. Est-ce que la résolution DNS fonctionne (ex : ping www.google.com)?

3. Configuration du DHCP

Vous avez pu l’observer, les postes clients dans notre réseau n’ont pas d’adresse IP.  Nous pourrions leur en attribuer une de manière statique, mais cela n’est pas pratique pour les postes utilisateurs, qui ne sont pas en permanence dans le réseau comme les serveurs.  A la place, le DHCP permet de faire une attribution dynamique d’adresses IP.  

Nous allons fournir un serveur DHCP pour notre réseau. Il s’agit de la machine appelée dhcp.  Le logiciel dhcpd (dhcp daemon) y a été installé, nous allons donc le configurer. 

Ouvrez un terminal sur la machine dhcp, et allez dans le répertoire /etc/dhcp/.  Vous y trouverez un fichier dhcpd.conf, qui est un exemple de configuration par défaut.  Vous pouvez l’examiner et essayer de comprendre les exemples qui sont fournis.  

Vous trouverez de la documentation concernant la configuration dhcpd ici : 

Vous allez à présent créer votre propre configuration.  Commencez par backuper le fichier de config par défaut en le copiant par exemple vers /etc/dhcp/dhcpd.conf.backup.  

Créez à présent un fichier /etc/dhcp/dhcpd.conf vierge.  Mettez-y les directives ci-dessous : 

authoritative;  
default-lease-time 7200;  
max-lease-time 7200;  
subnet 192.168.0.0 netmask 255.255.255.0 {  
	option routers 192.168.0.254;  
	option subnet-mask 255.255.255.0;  
	range 192.168.0.10 192.168.0.100;  
        option domain-name "woodytoys.lab";  
}

Ajoutez un commentaire (signalé par un dièse #) à la fin de chaque directive, pour expliquer à quoi elle sert.  

A présent, démarrez votre serveur DHCP.  Vous pouvez le faire manuellement en tapant la ligne suivante : 

dhcpd -cf /etc/dhcp/dhcpd.conf

Vérifiez si le serveur DHCP fonctionne bien : 

  • Lancez un ps -A sur le serveur pour vérifier la présence du processus dhcpd
  • Lancez un netstat -nltpu pour vérifier si le serveur dhcpd écoute sur les bons ports
  • Lancez une capture Wireshark sur le lien entre le switch et le poste du directeur
  • Relancez une demande de bail DHCP sur le poste du directeur avec les commandes :  
    • dhclient -r (release du bail DHCP déjà reçu)
    • dhclient" (demande d’un nouveau bail DHCP)
  • Vérifiez si vous voyez l’échange DHCP DORA correspondant dans la trace Wireshark 
  • Vérifiez si votre client a une adresse ip (ifconfig eth0) et s’il sait joindre 8.8.8.8 (ping).

Soyez sûrs de bien maitriser la commande netstat et ses différents paramètres :

  • -n: Utilise les ports numériques (80 au lieu de http)
  • -l: Affiche les sockets à l’écoute, reliés à un serveur qui attend pour traiter les requêtes reçues sur le port concerné.
  • -t: Affiche les sockets TCP
  • -u: Affiche les sockets UDP
  • -p: Affiche le pid du processus lié au socket

4. Résolution DNS

ATTENTION : En fonction de la configuration du firewall de l’Ephec, l’implémentation du résolveur sur le réseau filaire de l’Ephec pourrait ne pas fonctinoner.  Dans ce cas, il est donc recommandé d’utiliser un ordinateur portable sur Eduroam pour faire tourner la VM du labo. 

Configuration du résolveur

Grâce au serveur DHCP, nos clients ont une adresse IP et peuvent joindre l’extérieur. Néanmoins, nos clients ne bénéficient pas encore pour autant d’un service DNS pour joindre l’Internet.  Pour cela, nous allons mettre en place un résolveur à base du logiciel Bind9, sur la machine appelée resolver.  

Pour tester notre résolveur, vous pourrez utiliser un poste client (directeur ou atelier).  Cette machine (comme les autres) possède l’utilitaire dig que nous avons vu lors du TP précédent, et qui nous permettra de faire des requêtes DNS manuelles.  Il est également possible d’utiliser nslookup pour cela.

A présent, ouvrez une console sur la machine resolver, puis ouvrez le fichier /etc/bind/named.conf.  
1. Parcourez-le rapidement : dans son état actuel, il inclut trois autres fichiers de configuration.  Examinez-les rapidement pour comprendre à quoi chacun d’eux sert.  Il est intéressant de séparer sa configuration en plusieurs fichiers indépendants lorsqu’on travaille sur des configurations complexes.  Ce ne sera pas notre cas dans ce cours, donc nous centraliserons tout dans le fichier principal named.conf, contrairement à ce qui est proposé par défaut sur Ubuntu.   2. Backupez puis effacez le contenu existant du fichier named.conf.    

Configuration des options

La première étape de la configuration consiste à indiquer les options générales du serveur DNS. Editez le fichier named.conf avec nano, et copiez-collez-y ceci :

options {
	directory "/var/cache/bind";
	allow-recursion {
			192.168.0.0/24;
			127.0.0.1/32;
	};
	// Configure the IPs to listen on here.
	listen-on { any; };
	listen-on-v6 { none; };
	pid-file "/var/run/named/named.pid";
	allow-transfer { none; };
};

Examinez soigneusement les directives suivantes :   

  • La directive allow-recursion, qui indique les adresses IP pour lesquelles vous acceptez la récursion.  Pour des raisons de sécurité, il est important de limiter les machines autorisées à demander la récursion (voir l’avertissement en tête du fichier).  Nous allons ici étendre cette autorisation à notre subnet 192.168.0.0/24 : nous souhaitons fournir de la résolution DNS aux machines de notre réseau local.
  • La directive listen-on définit les interfaces sur lesquelles on accepte de répondre aux requêtes DNS.  Nous indiquons la valeur any pour écouter sur toutes les interfaces.  Nous aurions pu nous limiter à l’interface eth0, ou à l’interface localhost.

Configuration des zones

Un serveur DNS travaille par zone. Pour chaque zone, il faut définir le rôle qu’il va jouer :

  • Soit il est autoritaire pour cette zone (rôle de “serveur de noms autoritaire”). La directive correspondante est type master. Le serveur a alors besoin d’un fichier de zone contenant les resources records correspondant.
  • Soit il est forwarder, et il fait le relais des requêtes vers un autre serveur. La directive correspondante est type forward. Il faut lui spécifier l’IP du serveur vers lequel relayer les requêtes.
  • Soit il est résolveur : il accepte les requêtes récursives et y répond en faisant lui-même les requêtes itératives dans l’ensemble du DNS. La directive correspondante est type hint. Dans ce cas, il faut lui indiquer la liste des serveurs racines vers lesquels initier la recherche itérative.

Voici les trois zones à configurer. Copiez-coller les directives ci-dessous à la suite des options dans le fichier named.conf. A quoi correspond chaque zone ? Quel rôle joue le serveur dans chaque cas?

zone "." IN {
    type hint;
    file "/usr/share/dns/root.hints";
};

zone "localhost" IN {
	type master;
	file "db.local";
	allow-update { none; };
	notify no;
};

zone "127.in-addr.arpa" IN {
	type master;
	file "db.127";
	allow-update { none; };
	notify no;
};

Logs

La journalisation est un élément de configuration essentiel pour l’administration des réseaux : c’est dans les journaux / logs que l’on pourra trouver l’historique des événements qui se sont passés sur un serveur. La configuration des logs doit donc être soigneusement réfléchie. Dans ce cours, nous les configurerons serveur par serveur, mais dans une infrastructure d’entreprise, des systèmes de centralisation sont utilisés.

Voici ci-dessous les directives à ajouter dans le fichier named.confpour la configuration des logs. Deux fichiers de logs seront utilisés.

  • Lesquels sont-ils?
  • A quoi sert chacun d’eux?
  • En quoi diffèrent-ils?
  • Quels sont leurs paramètres de configuration?
logging {
        channel "misc" {
            file "/var/log/named/misc.log" versions 4 size 4m;
            print-time YES;
            print-severity YES;
            print-category YES;
        };
        channel "query" {
            file "/var/log/named/query.log" versions 4 size 4m;
            print-time YES;
            print-severity NO;
            print-category NO;
        };
        category default {
            "misc";
        };
        category queries {
            "query";
        };
};

Validation de la configuration

  • Démarrez le serveur bind via la commande named. Si vous le souhaitez, vous pouvez ajouter l’option -g : le serveur démarrera en avant-plan et les logs s’afficheront dans la console au lieu de s’afficher dans les fichiers prévus.  
  • Lancez ensuite Wireshark, puis testez votre résolveur depuis un client avec :  dig @192.168.0.2 www.google.com.  Le résolveur fait-il effectivement une requête récursive? Que voyez-vous dans les logs? Soyez sûrs de pouvoir expliquer les échanges observés!

Ajout du résolveur dans les annonces DHCP

Si votre résolveur fonctionne, configurez à présent dhcpd pour annoncer le résolveur aux clients, en ajoutant la ligne suivante dans le subnet 192.168.0.0/24 : 

option domain-name-servers 192.168.0.2;

Chaque fois que vous changez une configuration, n’oubliez pas de redémarrer le serveur pour que celui-ci charge la dernière version en mémoire!  

Juste avant de redémarrer le serveur, lancez une trace Wireshark. Vérifiez le contenu des messages DHCP envoyés aux clients : vous devriez y voir figurer l’IP du résolveur.

Vérifiez à présent si vos clients possèdent un résolveur et s’ils savent faire un ping www.google.com.

Vous avez à présent terminé la première étape du labo : donner une connectivité Internet à vos postes clients!