SE4 IdO sécurité système/réseau

Création d'un conteneur

Le but de cette première manipulation est la création d'un conteneur pas à pas sous Linux.

Le système de fichiers

La première étape est de créer un système de fichiers isolé par rapport au système de la machine hébergeur :

• commencez par créer un fichier disk.img de 10Go sur la station de travail, pour cela vous utiliserez la commande dd, comme fichier source utilisez le générateur de zéro /dev/zero et les options bs (block size) et count ;
• en tant qu'administrateur créez un système de fichiers sur disk.img avec la commande mkfs (make filesystem), vous pouvez utilisez le système de fichiers ext4 ;
• toujours en tant qu'administrateur, montez le système de fichiers disk.img sur un répertoire vide (par exemple /tmp/disk que vous aurez préalablement créé) ;
• vous pouvez enfin installez un système de fichiers Linux minimal sur votre partition virtuelle par la commande debootstrap stable /dev/disk.

Lancement du conteneur

Lancez le conteneur avec la commande du cours. Dans un premier temps n'utilisez que les options -p -m. Vérifiez que les processus du conteneur sont bien isolés, de même pour les montages de systèmes de fichiers. Regardez les interfaces réseau du conteneur, conclusion ? Sortez du conteneur, relancez-le en ajoutant les options -n -u. Vérifiez à nouveau les interfaces réseau du conteneur, conclusion ?

Laissez le conteneur tourner dans son terminal de commande, n'en sortez plus.

Création d'une interface réseau

Créez un commutateur virtuel vide d'interfaces avec les commandes présentées en cours. Créez une interface Ethernet virtuelle avec les commandes présentées en cours. Trouvez le PID du processus unshare du conteneur et déplacez le pair de l'interface Ethernet virtuel dans l'espace de nom du conteneur.

Démarrez toutes les interfaces réseau avec la commande ip link set <IF> up, mettez une adresse IPv4 sur le commutateur virtuelle (e.g. 192.168.0.1/24) et sur le pair dans le conteneur (e.g. 192.168.0.2/24), vérifiez la connexion entre les deux interfaces virtuelles.

Sortie sur Internet

Utilisez les commandes vue en cours pour créer une mascarade sur la station de travail pour le réseau du conteneur. Vérifiez que le conteneur a bien accès aux même machines que la station de travail.

Préparation des travaux pratiques "migration"

Vous allez préparer le terrain pour les travaux pratiques de migration de machine virtuelles créées dans un environnement de type VMWare. Cette préparation doit se faire proprement en utilisant Ansible pour configurer les machines.

Schéma synthétique

Comme indiqué sur le schéma ci-dessous les travaux pratiques de migration se font en utilisant, par binôme, deux hyperviseurs et une machine de services fournissant , principalement, un service de stockage. Les deux hyperviseurs sont implantés sur deux stations de travail de même type via l'installation du système d'exploitation ESXi de VMWare.

Les machines d'administration doivent être réalisées à partir des anciennes stations de travail que vous devez renommer en NASXX et repérer avec les étiquettes données. Ces machines doivent avoir une adresse dans le réseau des salles projets de la forme 172.26.145.30+XX. Ces machines doivent être reliées au réseau des salles via deux commutateurs gigabit à installer en E304 et E306.

Pour réaliser le câblage du réseau de stockage votre NAS doit être à coté de vos hyperviseurs. Pour savoir où installer physiquement votre NAS la liste des postes de travail est donnée ci-dessous.

Poste de travail	Salle	Hyperviseur 1	Hyperviseur 2
Poste n°1	E302	zabeth26	zabeth27
Poste n°2	E304	zabeth02	zabeth03
Poste n°3	E304	zabeth04	zabeth05
Poste n°4	E304	zabeth06	zabeth07
Poste n°5	E304	zabeth08	zabeth10
Poste n°6	E304	zabeth09	zabeth11
Poste n°7	E304	zabeth12	zabeth28 (à rapatrier de la E302 à la E304)
Poste n°8	E306	zabeth13	zabeth17
Poste n°9	E306	zabeth14	zabeth16
Poste n°10	E306	zabeth18	zabeth19
Poste n°11	E306	zabeth20	zabeth21

Le numéro de la zabeth utilisée en premier hyperviseur est noté A et le numéro de la zabeth utilisée en second hyperviseur est noté B. Attention ces notations sont utilisées pour la description des rôles Ansible.

Installation de la distribution Devuan

Tous les binômes doivent installer une distribution Linux Devuan daedalus sur les machines d'administration, i.e. les anciennes stations de travail. Pour ce faire vous devez récupérer la bonne version de l'image ISO du DVD d'installation netinst, vous devez installer cette image sur une clef USB et vous devez démarrer la station de travail en amorçant sur la clef. Le plus simple pour copier l'image sur la clef est d'utiliser l'utilitaire dd avec comme "input file" (if) l'image ISO et comme "output file" (of) le périphérique bloc correspondant à la clef. Pour récupérer le périphérique bloc de la clef utilisez l'utilitaire lsblk.

Tâches supplémentaires

Câblage des anciennes stations

Un binôme s'occupe de la mise en place des commutateurs gigabit, un sur une table en E304, un autre dans la baie serveurs en E306. Les commutateurs doivent avoir tous leurs ports configurés dans le VLAN 50. Le même binôme effectue les câblages en utilisant des câbles de longueur adaptée et en utilisant le chemin de câble de la E306. Le câblage doit pouvoir rester en place jusqu'aux travaux pratiques de migration sans entraver le moins du monde le fonctionnement des salles.

Installation de disques

Un binôme se charge d'ajouter un second disque dans les stations de travail optiplex 7060 qui vont être utilisée comme hyperviseur et qui ne possédent qu'un disque.

Configuration d'un serveur Ansible

Le serveur Ansible doit être installé sur la zabeth15 qui n'est pas utilisée comme hyperviseur. Vous commencez par créer une clef asymétrique comme montré en cours et vous diffusez la partie publique par courriel à l'ensemble de la promotion. Charge aux divers binômes d'installer la clef publique dans le fichier /root/.ssh/authorized_keys de leur NAS.

Le binôme en charge de la configuration du serveur Ansible doit aussi :

• créer le fichier d'inventaire des machines d'administration ;
• créer le "jeu" (playbook) appliquant les rôles réalisés par les autres binômes à l'ensemble des machines d'administration ;
• tester la bonne exécution de la commande uname -a sur l'ensemble des machines d'administration.

C'est à la charge des autres binôme de s'assurer que tous les rôles s'exécutent bien sur leur propre machine d'administration et aux binôme chargés des rôles que ceux-ci sont fonctionnels.

Configuration des rôles Ansible

Les rôles Ansible ci-dessous doivent être créés sur le serveur Ansible. Un seul binôme se charge des deux premiers rôles triviaux.

• un rôle de propagation de fichiers systèmes généraux :
  • /etc/network/interfaces ne contenant que la définition de l'interface loopback,
  • /etc/default/ntpdate contenant la référence au serveur NTP de la plateforme ntp.plil.info,
  • /etc/apt/sources.list contenant les lignes pour les dépots Devuan daedalus, regardez les fichiers sur les zabeth pour référence,
  • et tout autre fichier nécessaire au bon fonctionnement des travaux pratiques de migration ;
• un rôle d'installation des paquetages nécessaires pour les divers autres rôles :
  • paquetage bind9 pour le serveur DNS,
  • paquetage nfs-kernel-server pour le serveur NFS,
  • paquetage bridge-utils pour la création de commutateurs virtuels,
  • paquetage ntp et ntpdate pour la mise à l'heure,
  • et tout autre paquetage demandé par un autre groupe ;
• un rôle de configuration de l'interface réseau de la carte mère des anciennes stations, placez un fichier de configuration dans /etc/network/interfaces.d créé à partir d'un modèle et d'une variable de type dictionnaire, l'interface doit avoir son adresse dans le réseau des salles de projets (VLAN 50) comme adresse IPv4 principale et son adresse dans le réseau d'administration des travaux pratiques de migration comme adresse secondaire, soit 10.10.A.4/24;
• un rôle de configuration du commutateur virtuel de stockage englobant les deux interfaces réseau PCI express, placez le fichier de configuration dans /etc/network/interfaces.d, crééz-le à partir d'un modèle et d'une variable de type dictionnaire, le commutateur doit avoir comme adresse IPv4, son adresse dans le réseau de stockage, soit 10.10.B.4/24 ;
• un rôle de configuration pour utiliser le serveur NTP de l'école ntp.plil.info ;
• un rôle pour configurer le DNS, en particulier pour envoyer le fichier statique named.conf.local mais aussi le fichier à adapter db.pifou.lan pour lequel vous utiliserez un modèle et une variable de type dictionnaire, le fichier à adapter est présent dans l'archive des travaux pratiques sur la zabeth15 et le fichier statique est dans le sujet des travaux pratiques disponible dans la même archive ;
• un rôle pour configurer le serveur NFS, à savoir pour propager le fichier /etc/exports mais aussi pour créer le répertoire concerné ;
• un rôle pour installer une mascarade sur les machines d'administration concernant leur réseau d'administration pour pouvoir contacter le réseau de l'école, les règles iptables doivent être rendues permanentes avec le paquetage iptables-persistent ;
• un rôle pour recopier de l'archive des travaux pratiques de migration à partir d'un original sur la zabeth15, la recopie doit être lancée par rsync et en tâche de fond pour ne pas bloquer la propagation des configuration par Ansible, il est conseillé de regarder [1] pour écrire correctement ce rôle.

Annexes

Fichier source schéma architecture des travaux pratiques "Migration" : Media:2023_Architecture_TP_Migration.svg

Atelier système et réseau, les machines virtuelles

Vous devez installer le système d'exploitation des machines virtuelles destinées à héberger vos services.

Création des machines virtuelles

Comme hyperviseur pour la gestion des machines virtuelles nous utilisons le système Xen. Chaque élève configure sa propre machine virtuelle pour installer ses services.

Du au nombre limité d'adresses IPv4 disponibles pour l'atelier, il est nécessaire de créer des machines virtuelles mandataires gérant une adresse IPv4 pour plusieurs machines virtuelles. Partez sur un machine mandataire par binôme.

Les machines de services peuvent contacter Internet et être contactées directement d'Internet via leurs adresses IPv6. Pour contacter Internet en IPv4 les machines de service passent par une mascarade installée sur leur machine mandataire. Pour être contactée d'Internet en IPv4 les machines de services se reposent sur leur machine mandataire qui reçoit les requêtes et qui les redirigent vers la bonne machine de services par des mécanismes dépendant du service accédé (e.g. mécanisme de mandaire inverse pour un service Web).

La connexion IPv4 entre machine de services et machine mandataire se fait par un réseau privé. Chaque type de machine possède donc deux interfaces réseau, une interface dans le réseau routé de la promotion et une interface dans le réseau privé de la machine mandataire. Lisez bien, il doit y avoir un réseau privé par machine mandataire.

Les machines virtuelles sont créées sur le Dom0 capbreton.plil.info.

Pour la création des commutateurs virtuels du réseau routé de la promotion et des réseaux privés vous pouvez :

• modifier le fichier /etc/network/interfaces du Dom0 pour décrire le commutateur du réseau routé, ce réseau est effectivement à caractère semi-permanent ;
• créer un fichier dans le répertoire /etc/network/interfaces.d du Dom0 aux noms du binôme concerné, ce réseau est lui plus transitoire et n'est utilisé qu'un semestre.

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), une méthode de configuration IP (prenez DHCP dans un premier temps, vous configurerez le fichier /etc/network/interfaces ensuite), le commutateur virtuel sur lesquel accrocher l'interface réseau et le répertoire où les disques virtuels doivent être créés (imposez /usr/local/xen). Il n'est pas inutile de préciser la taille du disque virtuel (autour de 10G). Laissez le script créer un mot de passe fort. Si vous oubliez le mot de passe vous pourrez le retrouver dans le fichier de contrôle au nom de votre machine situé dans le répertoire /var/log/xen-tools/. Installez la dernière version de la distribution Devuan.

Configuration de la machine de services

Dans un second temps, créez deux partitions LVM de 10G pour votre machine virtuelle (rappelez le nom de la machine dans le nom des partitions) et modifiez le fichier de configuration de la machine virtuelle de services pour faire en sorte que les répertoires /var et /home de la machine virtuelle soient implantés sur ces partitions LVM. Attention à bien transférer le contenu du répertoire /var dans la nouvelle partition destinée à être montée sous /var. Pour un montage permanent des deux partitions, voyez le fichier des montages /etc/fstab.

Modifiez le fichier de configuration /etc/network/interfaces pour faire en sorte que votre machine de services obtienne automatiquement une adresse IPv6 routée et pour fixer une adresse IPv4 sur le réseau privé de la machine mandataire.

Installez les paquetages nécessaires pour ssh, le serveur Web apache2 et le serveur DNS bind (voir la partie services).

Configuration de la machine mandataire

Modifiez le fichier de configuration /etc/network/interfaces pour faire en sorte que votre machine de services obtienne automatiquement une adresse IPv6 routée et pour fixer une adresse IPv4 dans le réseau routé de la promotion.

Installez les paquetages nécessaires pour ssh, le serveur Web apache2 et le serveur DNS bind pour pouvoir mettre en place les mécanismes de redirection évoqués plus haut.

Mettez en place la mascarade et les redirections de ports.

Annexes

Fichier source schéma architecture machines virtuelles : Media:2023_Architecture_MV.svg

Architecture réseau, première approche

Cette section détaille la maquette du réseau que vous devez réaliser rapidement pour que les machines virtuelles puissent être connectées à Internet.

Architecture de base

Vous construirez votre première maquette de réseau autour du routeur C9200. Ce routeur doit rester le routeur principal.

Un premier réseau virtuel

Nous disposons d'un réseau IPv4 routé et ouvert : 193.48.57.160/27 (dans le VLAN 110 de l’école soit TP-NET1).

Le routage de site (IPv4)

Routez votre VLAN sur votre routeur. Comme vous le savez, la configuration des routeurs doit initialement se faire via leurs ports série ; utilisez minicom sur un ordinateur Linux pour y accéder.

Le routage de site (IPv6)

Configurez votre routeur pour permettre à vos machines de se construire des adresses IPv6. Utilisez les préfixes IPv6 de Polytech’Lille prévus à cet effet (2001:660:4401:60a0::/60 et 2001:660:4401:60b0::/60). 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.

Interconnexion avec Internet (IPv4)

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/28. 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. Le routage par OSPF se déclare par un bloc du type ci-dessous où @IPv4 est la plus petite adresse IPv4 du routeur :

router ospf 1                                                                 
 router-id @IPv4
!

Dans ce bloc vous devez ajouter une directive redistribute pour indiquer quel type d'entrées de routage vous souhaitez propager par OSPF et avec quelle métrique. Vous devez aussi ajouter une directive network pour indiquer par quel réseau IPv4 vous passez pour propager et recevoir les annonces, ici c'est le réseau IPv4 du VLAN 530.

Attention ! Le masque pour network est inversé.

Attention ! Il faut aussi que l'area corresponde à celle du pair OSPF. Le routeur de la plateforme utilise area 10.

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
  ...
!

Interconnexion avec Internet (IPv6)

Les VLAN d’interconnexion pour IPv6 sont les mêmes que pour IPv4. Le réseau IPv6 utilisé sur INTERCO-4A est le réseau local IPv6 standard FE80::0/10. Le routeur de la plateforme utilise la première adresse disponible.

Pour interconnecter votre routeur, 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 tpse
 redistribute connected metric 1
 redistribute rip 1 metric 1
 redistribute static metric 1
!

N’oubliez pas d’activer le protocole RIPv6 sur l’interface interconnexion avec une commande du style ipv6 rip tpse enable.

Testez votre connectivité IPv6 en utilisant les serveurs de google.com.

Services Internet

Le but est ici de configurer sur votre machine des services fonctionnels et sécurisés. Les accès IPv6 doivent être directement gérés par la machine virtuelle de services. Les accès IPv4 doivent être gérés par la machine mandataire.

Serveur SSH

Votre machine virtuelle Xen de services doit être accessible par SSH. Autorisez les accès par l'utilisateur root via le fichier de configuration /etc/ssh/sshd_config et l'option PermitRootLogin.

Pour l'accès avec l'adresse IPv4, effectuez une rediction de ports vers vos machines de services. Vous pouvez utiliser le port 2201 pour la première machine de services et 2202 pour la seconde. La redirection de ports s'effectue en utilisant iptables/nftables.

Serveur DNS

Vous allez réserver un nom de domaine pour associer un nom DNS à chacune de vos adresses IP (les zones inverses devraient, elles aussi, être gérées mais nous n'avons pas la délégation pour ce faire). 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 de services pour donner les adresses IPv4 et IPv6 correspondant à vos noms de machines. Utilisez l’interface web de votre registrar pour paramétrer votre machine comme serveur DNS principal. Utilisez le serveur DNS de votre binôme comme serveur DNS secondaire.

Comme votre serveur DNS ne peut pas être contacté en IPv4 vous allez configurer la machine mandataire pour servir votre zone en tant que serveur DNS secondaire. Le serveur mandataire se met à jour via le réseau privé du mandataire. Du coup au niveau du registrar vous déclarerez un "glue record" avec l'adresse IPv4 du mandataire et l'adresse IPv6 de la machine de services.

Sécurisation de site Web par certificat

Sur la machine virtuelle de services , 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 l'utilitaire 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 faut aussi définir la chaîne de certification avec SSLCertificateChainFile.

Faites très attention à la clef privée générée avec openssl si vous la perdez, votre certificat devient inutile. Il est conseillé de la stocker de façon pérenne dans votre machine de services.

Là encore seuls les accès IPv6 peuvent se faire en direct sur votre machine de services. Pour IPv4 vous devez configurer apache2 comme mandataire inverse pour votre site. Pour la fonction mandataire inverse, activez les modules Apache proxy et proxy_http. Dans le fichier de configuration du site vous devez ajouter les directives SSLProxyEngine, ProxyPass et ProxyPassReverse (utilisez l'URL avec le nom de domaine dans les deux dernières directives).

Sécurisation de serveur DNS par DNSSEC

Sécurisez votre serveur DNS en signant la zone correspondant à votre nom de domaine.

Deux méthodes sont disponibles : la gestion manuelle des clefs de chiffrement ou la gestion automatique de ces clefs par bind.

Gestion manuelle des clefs

Vous pouvez vous appuyer sur le document [2] pour réaliser la sécurisation. Testez votre configuration avec l’outil [3].

Pour entrer dans les détails, vous allez devoir effectuer les opération suivantes.

• ajoutez l’option dnssec-enable yes; dans le fichier named.conf.options ;
• il est conseillé de créer un répertoire de nom <nom_de_zone>.dnssec pour y générer les clefs ;
• créez la clef asymétrique de signature de clefs de zone (pour accélerer la génération sur un système de test vous pouvez utiliser l’option -r /dev/urandom) ;

dnssec-keygen -a RSASHA256 -b 2048 -f KSK -n ZONE <nom_de_zone>

• créez la clef asymétrique de la zone pour signer les enregistrements (pour accélerer la génération sur un système de test vous pouvez utiliser l’option -r /dev/urandom) ;

dnssec-keygen -a RSASHA256 -b 1024 -n ZONE <nom_de_zone>

• renommez les deux paires de clefs obtenues en utilisant le nom de la zone comme préfixe puis en suffixant d’abord par la destination de la clef (-ksk pour la KSK ou -zsk pour la ZSK) puis par le type de clef (.key pour la clef publique ou .private pour la clef privée) ;
• incluez les clefs publiques dans votre fichier de zone, incrémentez le numéro de version de la 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

• signez les enregistrements de la zone ;

dnssec-signzone -o <nom_de_zone> -k <nom_de_zone>-ksk ../<nom_de_zone> <nom_de_zone>-zsk

• modifiez le fichier named.conf.local pour utiliser la zone signée de suffixe .signed ;
• il ne reste plus qu’à communiquer la partie publique de la KSK (présente dans le fichier <nom_de_zone>-ksk.key) à votre registrar (par exemple Gandi, regardez à "Manage DNSSEC" dans la section "DNS servers").

Gestion automatique des clefs

Rajoutez le bloc suivant dans la définition de vos zones :

 key-directory "/etc/bind/keys";
 dnssec-policy "dnspol";
 inline-signing yes;

La ligne dnssec-policy "dnspol"; fait référence au bloc global ci-dessous.

 dnssec-policy "dnspol" {
   keys {
       ksk key-directory lifetime unlimited algorithm 13;
       zsk key-directory lifetime unlimited algorithm 13;
   };
   nsec3param;
 };

Vous avez aussi à communiquer la partie publique de la KSK à votre registrar comme pour la gestion manuelle.

Filtrage des services

Vérifiez dans les fichiers de contrôle de vos 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).