Réseau et services pour la plateforme informatique
Sommaire
- 1 Cahier des charges
- 2 Avancement du Stage
- 3 Fichiers Rendus
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 :
- 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
- 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
- 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
- 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
- trouver un dispositif de détection de MinM / Poisonning
- 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
L'étude des documentations de Xen,DNS et DNS sécurisé et réalisation d'un serveur virtuel
Xen
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.
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. Voici une image qui représente l’environnement du DNS
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.
DNS Sécurité
Pourquoi DNS Sécurisé
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...
- 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.
- 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.
- 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.
- 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.
- 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
2.Le DNS est maitre pour certaines zones
zone "plil.info"{
type master;
file "/etc/bind/plil.info.signed";
};
Principes de DNSSEC
Afin d'assurer l'authenticité et l'intégrité des réponses, DNSSEC est basé sur un modèle de cryptographie à clé publique. Un serveur d'autorité calcule un hash de la réponse puis le signe avec une clé privée (secrète) avant d'envoyer le paquet et son hash au résolveur. Celui-ci sera à même de vérifier l'authenticité et l'intégrité des données en vérifiant que le hash déchiffré à l'aide de la clé publique associée à la clé privée correspond bien au hash recalculé de la réponse.
Nouveaux Ressource Records
RR – Resource Record These are commonly referred to as "records." A record is the smallest unit of data inside a zone. For example, a single NS, SOA, or DNSKEY record.
DNSKEY
These records contain the public key for the zone. They come in two flavors, a Zone Signing Key (ZSK) and a Key Signing Key (KSK). Generally, the KSK signs only certain records within the zone, while the ZSK signs all of the records. You may have as many of each as required for key-rollover protocols or for your needs.
Principe de la signature des RRSIG
RRSIG – Resource Record Signature
These records hold the signatures for a specific record type. For instance, you will see an RRSIG for NS records, one for DNSKEY records, etc. One RRSIG record will be generated per ZSK, typically, and for certain records one for each KSK as well.Note that there is one signature per-key per-RRSET, not per RR.
Exemple de vérification de RR par un client DNSSEC
Chaque enregistrement est composé d'un type qui permet d'identifier les informations (A pour l'IPv4, AAAA pour l'IPv6, SOA pour le serveur autoritaire, ...).
Exemple pour la résolution de www.plil.info
Sécurisation de serveur DNS par DNSSEC
Pour entrer dans les détails, il faut effectuer les opération suivantes.
- Il faut ajouter l'option dnssec-enable yes; dans le fichier named.conf.options ;
- Il faut créer un répertoire de nom plil.info.dnssec pour y générer les clefs ;
- Il faut créer la clef asymétrique de signature de clefs de zone (pour accélérer la génération sur un système de test nous pouvons utiliser l'option -r /dev/urandom) ;
- Il faut créer la clef asymétrique de la zone pour signer les enregistrements (pour accélérer la génération sur un système de test nous pouvons utiliser l'option -r /dev/urandom) ;
- Il faut renommer 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) ; En conséquence, après tous ces étapes dans le répertoire plil.info.dnssec j'ai 5 fichiers:
- Il faut incluer les clefs publiques dans votre fichier de zone, incrémentez le numéro de version de la zone ;
- Il faut signer les enregistrements de la zone ;
- Il faut aussi modifier 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 plil.info-ksk.key) à votre registrar (par exemple gandi.net, regardez à "Manage DNSSEC" dans la section "DNS servers").
Chaîne de DNSSEC pour plil.info
Chaîne de DNSSEC pour congchen.fr
dnssec-keygen -r /dev/urandom -a RSASHA1 -b 2048 -f KSK -n ZONE plil.info
dnssec-keygen -r /dev/urandom -a RSASHA1 -b 1024 -n ZONE plil.info
$include /etc/bind/plil.info.dnssec/plil.info-ksk.key
$include /etc/bind/plil.info.dnssec/plil.info-zsk.key
dnssec-signzone -o plil.info -k plil.info-ksk ../plil.info plil.info-zsk
J'ai créé un autre nom de domaine congchen.fr ensuite j'ai refait toutes les étapes précédentes, donc dans mon répertoire bind j'ai des fichiers ci-dessous
Une fois le "Manage DNSSEC" est fait, je pouvait visualiser la chaîne de DNSSEC pour plil.info et congchen.fr
Sécurisation par DNSSEC-Tools
Présentation de DNSSEC-Tools projet
Le projet DNSSEC -Tools est une open-source désigné pour rendre DNSSEC facile. DNSSEC -Tools est une suite de logiciels d'open-source et libre, contenant une grande variété d'outils et de bibliothèques. Son organisation modulaire et le code de source libre permettent de personnaliser et de construire des propres outils de chacun.
Le diagramme de DNSSEC-Tools
Le DNSSEC-Tools a certains outils:
- End user
- Zone Administrators
- Application Authors
- Operational Debuggers
- Authoritative Server Administrators
- Recursive Server Administrators
- Management Station Operators
- Network Monitors
Procédure avec DNSSEC-Tools
Pour commencer, il faut d'abord installer le DNSSEC-Tools dans ma machine virtuelle cong-dns.
apt-get install DNSSEC-Tools
Ensuite je peux commencer à signer ma propre zone, pour cela j'ai besoin d'un fichier de mon domaine.
$TTL 3600 congchen.fr. 1000 IN SOA ns.congchen.fr. admin.congchen.fr.( 5 ; serial 7200 ; refresh(2 hours) 3600 ; retry(1 hour) 604800 ; expire(1 week) 600 ; minimum(10 minutes) ) 1000 NS ns.congchen.fr. 1000 NS ns6.gandi.net. ns 1000 IN A 5.23.44.83 www 1000 IN A 5.23.44.83
Afin de signer la zone,j'ai utilisé zonesigner. Pour la première fois, il faut ajouter option -genkeys pour dire que je veux générer une nouvelle clé pour la zone.
zonesigner -genkeys congchen.fr
Dans le répertoire dnssec-tools, j'ai des fichiers .key et .private automatiquement A ready to use signed zone file, 'zonefile.signed', is generated. Created along with it are the associated Zone and Key Signing Keys (ZSKs/KSKs), keyset files, dsset file, and a zonesigner configuration file for example.com. Note that these files are generated in the same directory as the zone file that is signed. The location of these files can be adjusted through command line arguments to zonesigner. (Even easier, if your zone file name matches the zone itself, e.g. example.com, simply running the command 'zonesigner -genkeys example.com' will generate example.com.signed.)
Zonesigner offers a large number of additional options to affect zone file signing. The key expiration times, file name and locations can all be adjusted from the command line. It will even do the various steps required for key rollovers, although it is much easier to use rollerd to execute the needed key-rolling steps automatically.
Le DNSSEC-Tools est plus pratique pour générer les clés puisque les fichiers sont faits automatiquement, j'ai pas besoin de les changer manuellement.
Rollerd
Rollerd automates key rollovers. That is, it automates the steps necessary to change over from one Zone Signing Key (ZSK) to the next using the Pre-Publish Method of key rollover. It can also automate the less frequent Key Signing Key (KSK) change over using the Double Signature Method of key rollover. See RFC 4641 for a descriptions of these key rollover methods.
Getting started with rollerd
Given the existing signed zone file, zonefile.signed, with associated keys and a zonesigner key-rec file, example.com.krf. Create a rollrec file using rollinit (a companion tool to rollerd)
rollinit congchen.fr -zone /etc/bind/dnssec-tools/congchen.fr.signed -keyrec /etc/bind/dnssec-tools/congchen.fr.krf -admin admin@congchen.fr > congchen.fr.rollrec
Semaine 3
L'intégration dans le système avec Makefile du serveur DNS
Pour faire moins de modifications sur les fichiers du DNS, j'ai utilisé un Makefile pour gérer tous fichiers. Afin d’arriver à mettre le DNSSEC dans ce Makefile, il faut bien étudier toutes les opérations du DNSSEC.
Les pratiques opérationnelles du DNSSEC
Il faut comprendre 4 termes relatifs à des périodes de temps.
- La période de validité de signature: La période qu'une signature est valable.
- La période de publication de signature: La période qu'une signature est publiée.
- La période d’efficacité de la clé: La période pendant laquelle on attend à ce qu'une paire clé soit efficace.
- Temps Maximal/Minimal de Zone pour Vivre (TTL): La valeur maximale ou minimale du TTLS de l'ensemble complet de RRS dans une zone, qui est utilisé par des valideurs ou des résolveurs.
Régles pour les temps de validité des KSK et ZSK par rapport au TTL.
For one kind of key pair the private key is used to sign just the zone's DNSKEY resource record (RR) set. Its public key is intended to be referenced by a DS RR at the parent or configured statically in a resolver. The private key of the other kind of key pair is used to sign the rest of the zone's data sets.The former key pair is called a key-signing key (KSK) and the latter is called a zone-signing key (ZSK).
Key Signing Key (KSK): An authentication key that corresponds to a private key used to sign one or more other authentication keys for a given zone. Typically, the private key corresponding to a key signing key will sign a zone signing key, which in turn has a corresponding private key that will sign other zone data. Local policy may require that the zone signing key be changed frequently, while the key signing key may have a longer validity period in order to provide a more stable secure entry point into the zone. Designating an authentication key as a key signing key is purely an operational issue: DNSSEC validation does not distinguish between key signing keys and other DNSSE authentication keys, and it is possible to use a single key as both a key signing key and a zone signing key. Key signing keys are discussed in more detail in [RFC3757].
Zone Signing Key (ZSK): An authentication key that corresponds to a private key used to sign a zone. Typically, a zone signing key will be part of the same DNSKEY RRset as the key signing key whose corresponding private key signs this DNSKEY RRset, but the zone signing key is used for a slightly different purpose and may differ from the key signing key in other ways, such as validity lifetime. Designating an authentication key as a zone signing key is purely an operational issue; DNSSEC validation does not distinguish between zone signing keys and other DNSSEC authentication keys, and it is possible to use a single key as both a key signing key and a zone signing key.
If the two functions are separated, then for almost any method of key management and zone signing, the KSK is used less frequently than the ZSK. Once a DNSKEY RRset is signed with the KSK, all the keys in the RRset can be used as ZSKs. If there has been an event that increases the risk that a ZSK is compromised, it can be simply replaced with a ZSK rollover. The new RRset is then re-signed with the KSK.
rolling a KSK with a parent is only done for two reasons: to test and verify the rolling system to prepare for an emergency, and in the case of (preventing) an actual emergency.
Rolling a KSK that is not a Trust Anchor: There are three schools of thought on rolling a KSK that is not a trust anchor:
1.It should be done frequently and regularly (possibly every few months), so that a key rollover remains an operational routine.
2.It should be done frequently but irregularly. "Frequently" means every few months, again based on the argument that a rollover is a practiced and common operational routine; "irregular" means with a large jitter, so that third parties do not start to rely on the key and will not be tempted to configure it a trust anchor.
3.It should only be done when it is known or strongly suspected that the key can be or has been compromised, or in conjunction with operator change policies and procedures, like when a new algorithm or key storage is required.
Rolling a KSK That Is a Trust Anchor:The same operational concerns apply to the rollover of KSKs that are used as trust anchors: If a trust anchor replacement is done incorrectly, the entire domain that the trust anchor covers will become Bogus until the trust anchor is corrected.
Key rollovers Regardless of whether a zone uses periodic key rollovers or only rolls keys in case of an irregular event, key rollovers are a fact of life when using DNSSEC. Zone administrators who are in the process of rolling their keys have to take into account the fact that data published in previous versions of their zone still lives in caches.When deploying DNSSEC, this becomes an important consideration;ignoring data that may be in caches may lead to loss of service for clients.
Zone Signing Key Rollovers If the choice for splitting ZSKs and KSKs has been made, then those two types of keys can be rolled separately, and ZSKs can be rolled without taking into account DS records from the parent or the configuration of such a key as the trust anchor.
For "Zone Signing Key rollovers", there are two ways to make sure that during the rollover data still cached can be verified with the new key sets or newly generated signatures can be verified with the keys still in caches.One scheme, described in Section 4.1.1.1, uses key pre-publication; the other uses double signatures, as described in Section 4.1.1.2. The pros and cons are described in Section 4.1.1.3.
Voici une image pour montrer le DNSSEC et l'opération du DNS
Le cadre de la validation du DNSSEC
Your recursive name server will treat the zones for which you con gured trust anchors as being secured.If the zones for which you have con gured trust anchors change their keys you will also have to recon gure your trust anchors.Failure to do so will result in the data in these zones, or any child, being marked as bogusand therefore becoming invisible to users.
Configuration d'un trust anchor
A trust anchor is a public key that is configured as the entry point for a chain of authority. In the ideal case where the root is signed and chains of trusts can be constructed through top-level domains to end-nodes, validating name servers would only need one of these trust anchors to be configured. During early deployment you will probably want to configure multiple trust anchors.
Zone-signing and key-signing key rollovers. There are two approaches for this. The "pre-publish" and the "double signature" rollover.
At t0 new data replaces data from a previous version of the zone ???. The data is published on the authoritative master (or primary server). It will take some time (which we refer to as zone synchronisation time) before the new version of the zone is picked up by all authoritative servers. In the worst case scenario, a change to a slave server will not be able to reach the master server and the zone will expire. So the maximum value of the zone synchronisation time will be the value of the SOA expiration parameter. Assume that at some time (t1) between publication of the new zone on the master server(t0) and the time the new zone is picked up by a slave server (t2) a query for the data is done by a recursive caching name server. That recursive server will return the old data to any of its clients for the time that is set by the TTL value on the old RRset. Only after t4, will the recursive server go back and query for new data picking up the new records.Note that the t4 does not only depend on t1+TTL but is also upper bound by the signature expiration time of the signature on the old RRset.
During a Zone-signing key (ZSK) rollover we use a "pre-publish" scheme.
During a key-signing key (KSK) rollover we use a "double signature" scheme.
initial: Initial version of the zone. The parental DS points to DNSKEY_K_1. Before the rollover starts, the child will have to verify what the TTL is of the DS RR that points to DNSKEY_K_1 --it is needed during the rollover, and we refer to the value as TTL_DS. new DNSKEY: During the "new DNSKEY" phase, the zone administrator generates a second KSK, DNSKEY_K_2. The key is provided to the parent, and the child will have to wait until a new DS RR has been generated that points to DNSKEY_K_2. After that DS RR has been published on all servers authoritative for the parent's zone, the zone administrator has to wait at least TTL_DS to make sure that the old DS RR has expired from caches. DS change: The parent replaces DS_K_1 with DS_K_2. DNSKEY removal: DNSKEY_K_1 has been removed.
