Analyse sécurité SOA DNS - MachiganMC/Woodytoys GitHub Wiki

Analyse de sécurité SOA-DNS

1. Identification des biens à protéger

Il faut donc protéger :

les logiciels des serveurs DNS et SOA [1]
les fichiers de zones contenants les records DNS [1]
les stations de travail des employés [1]
et vérifier le traffic DNS [1]
la réputation de l'entreprise Woodytoys [1]
le nom de domaine [2]
le registar [2]

2. Identification des menaces / failles

L'ID Spoofing [1] : le hacker va essayer de s'insérer entre le client et son résolveur en renvoyant une réponse à la requête du client: en envoyer une fausse réponse DNS, cela permettra à l'attaquant de rediriger le client vers des adresses IP malveillantes au lieu de la machine initialement visée. C'est le champ ID de l'en-tête DNS qui sera utilisée. En effet, l'entête des requêtes DNS possède un champ "ID", unique sur le client afin que celui puisse associer une réponse à sa requête.
le Cache Poisoning [1] : le but recherché est cette fois d'injecter de mauvaises informations sur le résolveur afin de toucher plusieurs clients simultanément.
Le déni de service ou DDoS [1] : les services vont être rendus indisponibles par les hackeurs. Pour cela, ces derniers enverront une grosse charge de traffic sur le serveur depuis plusieurs sources (on parle alors de déni de service distribué, ou DDoS en anglais) afin de le saturer.
Le Tunnelling DNS [1]: Il peut aider à contourner les firewalls : en effet, comme le traffic DNS ne transporte pas de donnéee, il est très souvent autorisé à traverser les firewaulls. Les attaquants peuvent donc utiliser ce trafic afin d'infiltrer des clients situées derrières les firewaulls et les infecter.
Attaques zero-day [2] : Une attaque zero-day va exploiter un défaut ou un bug inconnus jusqu'à ce qu'il soit utilisé par les attaquants. "Une attaque zero-day s’effectue habituellement à l’aide d’un logiciel gratuit en open source qui permet aux cybercriminels d’examiner en détail comment fonctionne le logiciel ciblé, afin de trouver des failles à exploiter."[2]
Les Malwares [2] regroupent différentes menaces de sécurités tels que les virus, les logiciels espions (« spyware »), les vers, les chevaux de Troie, et les ransomwares. Ils sont utilisés afin de dérober des données sensibles sur une machine sans que l'utilisateur s'en rende compte. Il peut aussi permettre de mettre au tapis des systèmes informatique et crypter des informations qui ne seront déverrouillées qu'en échange d'une rançon.
Mauvaise gestion des certificats numériques [2] : si un certificat n'est pas renouvelé à temps, un site peut devenir momentanément inaccessible avec un message d'alerte lorsqu'un client essaye d'atteindre le site web. Cela peut nuire à la réputation de l'organisation et faciliter les vols de données.

3. Prioritisation des risques (impact * probabilité)

Menaces	Probabilité	impact	estimation du risque	Contre-mesure
ID Spoofing	Élevé	Fort	Élevé	ID non prédictible, DNSSEC
Cache Poisoning	Élevé	Fort	Élevé	MAJ du logiciel serveur, DNSSEC
Le déni de service	Moyen	Fort	Moyen	Bons pare-feu
Le Tunnelling DNS	Moyen	Fort	Moyen	Bons Pare-feu, surveillance traffic DNS
Attaques zero-day	Faible	Moyen	Faible	MAJ des logiciels
Les Malwares	Moyen	Moyen	Moyen	Bon pare-feu, antivirus
Mauvaise gestion des certificats numériques	Faible	Moyen	Faible	Surveillance date de validité.

4. Identification et sélection des contre-mesures

DNSSEC: Le plus souvent, ce sont des données modifiées qui posent des problèmes de sécurité au niveau du DNS. Afin de limiter ces problèmes, des méthodes d'identification peuvent être mis en place en créant des extensions au protocole DNS afin de rajouter des signatures cryptographiques aux record DNS. Ces extensions sont aussi appelées DNSSEC.

Le DNSSEC repose sur le principe de la cryptographie asymétrique. Il s'agit d'une technique cryptographie permettant à la fois le chiffrement et la signature, grâce à une paire de clés : Une clé, appelée clé publique, est partagée publiquement, tandis que l'autre clé est conservée de manière sécurisée. Un message chiffré avec la clé publique ne peut être déchiffré qu'avec la clé privée, et inversement : un message chiffré avec la clé privée ne peut être déchiffré qu'avec la clé publique.[1]

Mettre à jour les serveurs: Mettre à jour le serveur permet de d'éviter de prévoir les numéro d'identification.

Mise en place de Firevault: La mise en place de bon pare-feu permet de filtrer correctement le trafiuc DNS et ainsi bloquer plusieurs types de menaces.

Mise en place de Proxy: En mettant en place des proxy, on peut surveiller efficacement le traffic et ainsi éviter du Tunneling.

5. Documentation des éléments de configuration des contre-mesures

Il faudrait configurer le DNSSEC à 2 niveau pour protéger le SOA et et le résolveur :

Le résolveur doit gérer la validation des records reçus et refuser ceux qui ont une validation qui n'ont pas aboutit.
Pour ce qui est du SOA:
- Générer les clés KSK et ZSK
- Faire signer le hash de la KSK par l'autorité parente (ce dernier publie alors le hash signé sous forme de RR DS dans sa zone).
- Chiffrer les RRs de la zone en utilisant la ZKS, et ajouter les signatures (RRSIG) dans la zone.
- Chiffrer la ZSK publique avec la KSK privée, et publier la ZSK signée ainsi que la KSK publique dans la zone, sous forme de RRs DNSKEY. Pour voir en détail la mise en place du DNSSEC, vous pouvez suivre ce tutoriel