Réseau et services pour la plateforme informatique

Cahier des charges

Objectif du stage

L'objectif du stage est d'abord de créer un réseau informatique pour la plateforme informatique de Polytech'Lille. Pour l'instant la plateforme utilise le réseau de production. Il convient d'isoler les deux réseaux pour éviter un impact négatif lors des manipulations des élèves. Dans un second temps il sera possible d'adapter les TP systèmes et réseau IMA5 à cette nouvelle architecture.

Description du stage

Les tâches à effectuer pour la création du réseau de la plateforme et dédiées au stagiaire sont :

1. Sécuriser le serveur DNS de la plateforme (DNSSEC)

 - terminer le serveur DNS de la plateforme (zones ilot.org, plil.fr et plil.info)
 - utiliser les outils dnssec-tools (zonesigner pour signer les zones et rollerd pour gérer les clefs)
 - la modification doit s'intégrer dans le système avec Makefile du serveur DNS

2. Créer un système de génération de conteneurs à la demande

 - installer une machine avec un support pour les conteneurs docker
 - tester des applications Web de gestion de conteneurs (comme panamax)
 - établir une procédure pour créer/détruire un site Web le plus simplement possible

3. Préparer les TP d'architecture réseau IMA5 (SSE et apprentissage)

 - passer les nouvelles fibres entre la E306 et la E304
 - fixer les montants sur la pile de matériel de la E304
 - installer les cisco 4331
 - vérifier que le câblage simultané des deux bancs de TP est possible

4. Préparer les TP de sécurité réseau IMA5 (SSE et apprentissage)

 - permettre l'interception de mots de passe même avec l'utilsation de HSTS
   + implanter la méthode ARP poisonning + Proxy Web + Redirection Web + Modification de l'URL action
   + tenter avec DNS poisonning + Site HTTPS + log des identifiants
 - trouver un dispositif de détection de MinM / Poisonning

5. Implanter un pot de miel

 - créer une machine virtuelle totalement exposée sur Internet
 - détecter et enregistrer les attaques sur différents services
 - sonder les attaquants (au minimum lancer un nmap)

Avancement du Stage

Semaine 1

Présentation de Xen

Xen est un logiciel libre de virtualisation, plus précisément un hyperviseur de machine virtuelle.

Xen permet d'exécuter plusieurs systèmes d'exploitation (et leurs applications) de manière isolée sur une même machine physique sur plate-forme x86, x86-64, IA-64 et PowerPC, ARM Cortex-A7 et Cortex-A151 (bientôt sur SPARC). Les systèmes d'exploitation invités partagent ainsi les ressources de la machine hôte.

Xen est un « paravirtualiseur » ou un « hyperviseur » de machines virtuelles. Les systèmes d'exploitation invités ont « conscience » du Xen sous-jacent, ils ont besoin d'être « portés » (adaptés) pour fonctionner sur Xen. Linux, NetBSD, FreeBSD, Plan 9 et GNU Hurd peuvent d'ores et déjà fonctionner sur Xen.

Xen 3 peut également exécuter des systèmes non modifiés comme Windows sur des processeurs supportant les technologies VT d'Intel ou AMD-V (nom de projet: Pacifica) de AMD2.

Les architectures x86, x64, IA-64, PowerPC et ARM et SPARC sont supportées. Le multiprocesseur (SMP) et partiellement l’Hyper-Threading sont supportés.

Architecture de Xen

Chaque système d'exploitation invité tourne dans un « domaine ». Xen est une fine couche fonctionnant directement sur le matériel.

Architecture de Xen

Réalisation d'un serveur virtuel à l'aide de Xen

La création des machines virtuelles fera par la commande xen-create-image. Il faut préciser à cet utilitaire le nom de votre machine (option --hostname), la configuration réseau (option --dhcp dans un premier temps) et le répertoire où les disques virtuels doivent être créés (option --dir), c'est-à-dire /usr/local/xen. Une fois la machine créée, modifiez son fichier /etc/network/interfaces pour y implanter la configuration réseau correcte. Il faut aussi installer des serveurs ssh et Web (paquetages openssh-server et apache2) dans le serveur.

La commande de la création du serveur virtuel est:

xen-create-image --hostname=cong.dns --ip=5.23.44.83 --netmask=255.255.255.248 --dist=jessie --gateway=5.23.44.81 --dir=/usr/local/

DNS

Présentation du DNS

Le Domain Name System (ou DNS, système de noms de domaine) est un service permettant de traduire un nom de domaine en informations de plusieurs types qui y sont associées, notamment en adresses IP de la machine portant ce nom.

Hiérarchie du DNS

Le système des noms de domaines consiste en une hiérarchie dont le sommet est appelé la racine. On représente cette dernière par un point. Dans un domaine, on peut créer un ou plusieurs sous-domaines ainsi qu'une délégation pour ceux-ci, c'est-à-dire une indication que les informations relatives à ce sous-domaine sont enregistrées sur un autre serveur. Ces sous-domaines peuvent à leur tour déléguer des sous-domaines vers d'autres serveurs.

Tous les sous-domaines ne sont pas nécessairement délégués. Les délégations créent des zones, c'est-à-dire des ensembles de domaines et leurs sous-domaines non délégués qui sont configurés sur un serveur déterminé. Les zones sont souvent confondues avec les domaines.

Les domaines se trouvant immédiatement sous la racine sont appelés domaine de premier niveau (TLD : Top Level Domain). Les noms de domaines ne correspondant pas à une extension de pays sont appelés des domaines génériques (gTLD), par exemple .org ou .com. S'ils correspondent à des codes de pays (fr, be, ch…), on les appelle ccTLD (country code TLD).

On représente un nom de domaine en indiquant les domaines successifs séparés par un point, les noms de domaines supérieurs se trouvant à droite. Par exemple, le domaine org. est un TLD, sous-domaine de la racine. Le domaine wikipedia.org. est un sous-domaine de .org. Cette délégation est accomplie en indiquant la liste des serveurs DNS associée au sous-domaine dans le domaine de niveau supérieur.

Les noms de domaines sont donc résolus en parcourant la hiérarchie depuis le sommet et en suivant les délégations successives, c'est-à-dire en parcourant le nom de domaine de droite à gauche.

Pour qu'il fonctionne normalement, un nom de domaine doit avoir fait l'objet d'une délégation correcte dans le domaine de niveau supérieur.

Hiérarchie du DNS

DNS Sécurité

Pourquoi DNS Sécurité

Il y a des attaques visant directement le DNS.Les atteintes aux infrastructures DNS sont essentiellement d’ordre technique, faisant appel à des stratégies d’attaques massives ou de corruption des informations échangées entre les ré-solveurs et les serveurs DNS.

Les principales techniques de sécurisation

Chaque acteur présent sur Internet est un maillon d’une chaîne de valeur où tous sont interdépendants. Les conseils suivants ne sont donc pas destinés à une catégorie d’acteurs en particulier mais à tous ceux qui participent du fonctionnement du DNS : gestionnaires de domaines de premier niveau (registre), bureaux d’enregistrement, entreprises, fournisseurs d’accès...

1.assurer la meilleure redondance possible, de manière à ce qu’un serveur affecté par une attaque puisse être remplacé en toute transparence par d’autres serveurs disposant des mêmes informations mais situés sur d’autres réseaux. C’est la raison pour laquelle les registres de noms de domaine, tel l’AFNIC, exigent toujours que chaque nom de domaine soit installé sur au moins deux serveurs de noms. D’autres techniques plus élaborées, comme le recours à des nuages anycast, permettent d’augmenter encore plus la redondance avec à la clé des gains notables en termes de sécurisation et de performances.

2.veiller à utiliser des versions à jour des logiciels DNS, notamment de BIND, corrigées par les « patchs » appropriés, afin de ne pas être vulnérable à des attaques portant sur des failles de sécurité déjà bien identifiées.

3.assurer une surveillance régulière de ses serveurs et de leur configuration, de préférence depuis plusieurs points de l’Internet. Il est souvent arrivé, en raison de la robustesse du DNS, que la panne de serveurs ne soit détectée que lorsque le dernier d’entre eux tombe en panne. Pour vérifier la configuration, il existe des logiciels libres comme ZoneCheck. Pour assurer la surveillance depuis l’extérieur, l’organisation qui ne souhaite pas déployer une infrastructure spécifique peut faire appel à des services commerciaux ou communautaires existants.

4.envisager de déployer DNSSEC, protocole de sécurisation du DNS par l’authentification des serveurs, ce système limitant notamment les attaques par empoisonnement. La perception de l’intérêt de DNSSEC a été fortement accrue par la révélation de la faille Kaminsky qui a montré comment exploiter efficacement des vulnérabilités déjà connues au plan théorique.

5.définir un « Plan de continuité d’activité » permettant à la victime d’une attaque de poursuivre, ou de reprendre en cas d’incident grave, ses activités avec un minimum d’indisponibilité de ses services. Cette précaution est particulièrement essentielle pour tous ceux qui dépendent d’Internet – et donc du DNS – pour leur chiffre d’affaires, notamment ceux qui proposent des services en ligne à leurs clients.

Semaine 2

Serveur DNS

Au départ j'ai réservé un nom de domaine plil.info pour associer un nom DNS à mon adresses IP 5.23.44.83 (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 mon nom de domaine reservé, j'ai configuré bind (paquetage bind9) sur mon serveur virtuel Xen cong-dns pour donner les adresses correspondant à mon nom de réseau IP, au nom de mon interface de routeur, au nom de ma machine et au nom de l'adresse de diffusion de mon réseau IP. J'ai utilisé l'interface web de mon fournisseur pour paramétrer ma machine comme serveur DNS maître et une machine de mon fournisseur comme DNS esclave.

1.Fichier d'adresses

   $TTL 259200
   @ IN SOA ns.plil.info. postmaster.plil.info. (
        3      	  ; Version
        7200             ; Refresh (2h)
        3600             ; Retry   (1h)
        1209600          ; Expire (14j)
        259200 )         ; Minimum TTL (3j)
	 IN NS ns.plil.info.
	 IN NS ns6.gandi.net.
   www       IN A       5.23.44.83

ns IN A 5.23.44.83