Réseau et services pour la plateforme informatique : Différence entre versions

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

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

2.Le DNS est maitre pour certaines zones

   zone "plil.info"{
     type master;
     file "/etc/bind/plil.info.signed";
   };

Sécurisation de serveur DNS par DNSSEC

Pour entrer dans les détails, il faut effectuer les opération suivantes.

1. Il faut ajouter l'option dnssec-enable yes; dans le fichier named.conf.options ;
2. Il faut créer un répertoire de nom plil.info.dnssec pour y générer les clefs ;
3. 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) ;

   dnssec-keygen -r /dev/urandom -a RSASHA1 -b 2048 -f KSK -n ZONE plil.info

4. 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) ;

   dnssec-keygen -r /dev/urandom -a RSASHA1 -b 1024 -n ZONE plil.info

5. 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:

5 fichiers dans le répertoire plil.info.dnssec
6. Il faut incluer les clefs publiques dans votre fichier de zone, incrémentez le numéro de version de la zone ;

    $include /etc/bind/plil.info.dnssec/plil.info-ksk.key
    $include /etc/bind/plil.info.dnssec/plil.info-zsk.key

7. Il faut signer les enregistrements de la zone ;

    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


Les fichiers dans le répertoire bind
8. Il faut aussi modifier le fichier named.conf.local pour utiliser la zone signée de suffixe .signed ;
9. 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").

Une fois le "Manage DNSSEC" est fait, je pouvait visualiser la chaîne de DNSSEC pour plil.info et congchen.fr

• 

  Chaîne de DNSSEC pour plil.info

• 

  Chaîne de DNSSEC pour 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 digramme de DNSSEC-Tools

Le DNSSEC-Tools a certains outils:

1. End user
2. Zone Administrators
3. Application Authors
4. Operational Debuggers
5. Authoritative Server Administrators
6. Recursive Server Administrators
7. Management Station Operators
8. Network Monitors

Procédure avec DNSSEC-Tools

Pour commencer, il faut d'abord installer le DNSSEC-Tools dans le PC.

 apt-get install DNSSEC-Tools

Ensuite je peux commencer à signer ma propre zone mais j'ai besoin d'un fichier pour ma 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 le fichier de la zone,j'ai utilisé zonesigner. Pour la première fois, il faut ajouter -genkeys option pour dire au zonesigner que je veux générer une nouvelle clé pour la zone.

  zonesigner -genkeys congchen.fr 

Génération de la clé

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 digramme de DNSSEC-Tools

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

Le fichier de 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 rerésolveurs.

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 DNSSEC et l'opération du DNS

Le cadre de la validation du DNSSEC

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.

Trust anchor in the DNS tree

Chain of trust

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.

DNS data propagation

During a Zone-signing key (ZSK) rollover we use a "pre-publish" scheme.

Pre-publish schématique

During a key-signing key (KSK) rollover we use a "double signature" scheme.

Double siggnature schématique

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.