Aller au contenu

Confidentialite

Le DNS interne est classe Interne dans le modèle de classification. Cependant, il merite une attention particulière : les enregistrements DNS constituent une carte détaillée de l'infrastructure.

Risques spécifiques au DNS

Les enregistrements révèlent la topologie

Un attaquant ayant accès au DNS interne peut decouvrir :

Information exposee Exemple Risque
Noms des services vault.mgmt.internal Identification des cibles de valeur
Adresses IP internes 10.30.2.10 Cartographie du réseau
Architecture db-master, db-replica Comprehension de l'infra
Technologies utilisees redis, rabbit, keycloak Identification des vecteurs d'attaque
Zones de déploiement production.internal, build.internal Comprehension des perimetres

Vecteurs d'attaque DNS

Attaque Description Impact
DNS énumération Transfert de zone (AXFR) non restreint Cartographie complète
DNS spoofing Réponses DNS falsifiees Redirection de trafic
DNS tunneling Exfiltration de données via requêtes DNS Fuite de données
DNS amplification Utilisation du serveur comme relais DDoS Deni de service
Cache poisoning Injection d'enregistrements dans le cache Redirection de trafic

Mesures de protection

Restriction des transferts de zone

Les transferts de zone (AXFR) ne doivent etre autorises qu'entre les serveurs DNS legitimes :

# Corefile — restreindre les transferts de zone
production.internal.company.io {
    file /etc/coredns/zones/db.production.internal {
        # Autoriser le transfert uniquement vers les serveurs secondaires
        transfer to 10.30.2.11 10.30.2.12
    }
    # Pas de "transfer to *" !
    log
    errors
    cache 300
}

DNS-over-TLS entre zones

Le trafic DNS entre les resolvers et les serveurs autoritatifs doit etre chiffre pour empecher l'écoute passive :

# Corefile — ecouter en DNS-over-TLS
tls://production.internal.company.io {
    tls /etc/coredns/tls/server.crt /etc/coredns/tls/server.key /etc/coredns/tls/ca.crt
    file /etc/coredns/zones/db.production.internal
    log
    errors
}

# Corefile du resolver — forward en DoT vers l'autoritatif
production.internal.company.io {
    forward . tls://10.30.2.20 tls://10.30.2.21 {
        tls_servername auth-dns.internal.company.io
        health_check 30s
    }
    cache 300
}

Génération des certificats TLS pour CoreDNS

# Generer une cle privee et un CSR pour le serveur DNS
openssl req -newkey rsa:4096 -nodes \
  -keyout /etc/coredns/tls/server.key \
  -out /etc/coredns/tls/server.csr \
  -subj "/CN=auth-dns.internal.company.io" \
  -addext "subjectAltName=DNS:auth-dns.internal.company.io,IP:10.30.2.20"

# Signer avec la CA interne (ou Vault PKI)
# vault write pki/sign/dns-server csr=@server.csr

Vault PKI pour les certificats DNS

Utiliser Vault PKI pour générer et renouveler automatiquement les certificats TLS des serveurs DNS. Cela simplifie la rotation et centralise la gestion des certificats.

DNSSEC pour l'intégrité

DNSSEC signe cryptographiquement les enregistrements DNS pour garantir leur authenticite :

# Corefile — activer DNSSEC
production.internal.company.io {
    file /etc/coredns/zones/db.production.internal
    dnssec {
        key file /etc/coredns/dnssec/Kproduction.internal.company.io
    }
    log
    errors
}

# Generer les cles DNSSEC
# KSK (Key Signing Key)
dnssec-keygen -a ECDSAP256SHA256 -f KSK production.internal.company.io

# ZSK (Zone Signing Key)
dnssec-keygen -a ECDSAP256SHA256 production.internal.company.io
Composant Fonction Rotation
ZSK (Zone Signing Key) Signe les enregistrements de la zone Tous les 3 mois
KSK (Key Signing Key) Signe la ZSK, ancre de confiance Tous les 1-2 ans

DNSSEC en interne : coût vs benefice

DNSSEC ajoute de la complexité operationnelle (gestion des cles, rotation, rollover). Pour un DNS purement interne sur un réseau contrôle, DNS-over-TLS entre zones offre une protection suffisante contre l'écoute et la falsification. DNSSEC est surtout utile si le DNS interne interagit avec des zones publiques ou si le réseau interne n'est pas totalement maîtrise.

Detection d'exfiltration DNS

Le DNS tunneling est une technique d'exfiltration ou un attaquant encode des données dans les requêtes DNS (sous-domaines longs, requêtes TXT inhabituelles). La journalisation et l'analyse des requêtes DNS permettent de détecter ces comportements.

Journalisation des requêtes

# Corefile — journaliser toutes les requetes
. {
    log . {
        class all
    }
    forward . 1.1.1.1 8.8.8.8
    cache 600
}

Les logs CoreDNS au format structure :

[INFO] 10.30.1.42:54321 - 12345 "A IN app-api.production.internal.company.io. udp 52 false 512" NOERROR qr,aa,rd 82 0.001234s

Indicateurs d'exfiltration

Indicateur Seuil d'alerte Technique de detection
Longueur du sous-domaine > 50 caractères Regex sur les logs
Entropie du sous-domaine > 3.5 bits/caractère Analyse statistique
Volume de requêtes TXT > 100/min depuis un client Compteur par IP source
Requêtes vers des domaines inhabituels Domaines non vus precedemment Baseline + deviation
Taille des réponses TXT > 255 octets fréquemment Analyse des réponses

Regles d'alerte (Grafana / Loki)

# Alerte : sous-domaine anormalement long (potentiel tunneling)
groups:
  - name: dns-security
    rules:
      - alert: DNSLongSubdomain
        expr: |
          count by (client_ip) (
            {job="coredns"}
            | regexp `"(?P<qtype>\w+) IN (?P<qname>[^ ]+)`
            | qname =~ `.{60,}`
          ) > 50
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Requetes DNS avec sous-domaines longs depuis {{ $labels.client_ip }}"

      - alert: DNSHighTXTRate
        expr: |
          rate(
            coredns_dns_requests_total{type="TXT"}[5m]
          ) > 10
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Taux eleve de requetes TXT — potentiel DNS tunneling"

Contre-mesures

Mesure Implementation
Limiter la longueur des requêtes Firewall DNS (Response Policy Zone)
Bloquer les domaines suspects Plugin rewrite ou template CoreDNS
Rate limiting par client Plugin ratelimit CoreDNS
Analyse comportementale Export vers SIEM, correlation avec d'autres indicateurs 
# Corefile — rate limiting
. {
    ratelimit 100   # Maximum 100 requetes/seconde par IP source
    forward . 1.1.1.1
    log
}

Politique d'accès au DNS

Qui Accès Justification
Tous les services Résolution (port 53) Fonctionnement normal
Équipe plateforme Administration (Corefile, zones) Opération du service
Équipe sécurité Logs DNS (lecture seule) Detection d'anomalies
Personne d'autre Transfert de zone (AXFR) Aucune raison legitime

Ne jamais exposer le DNS interne sur Internet

Le DNS interne ne doit jamais etre accessible depuis l'extérieur. Les resolvers internes ne doivent accepter de requêtes que depuis les réseaux internes (10.0.0.0/8). Utiliser des ACL dans CoreDNS ou des regles firewall pour garantir cet isolement.

# Corefile — restreindre les sources autorisees
production.internal.company.io {
    acl {
        allow net 10.0.0.0/8
        block
    }
    file /etc/coredns/zones/db.production.internal
    log
    errors
}