Un primaire caché et dnsdist. Durcir le DNS autoritaire

Le DNS autoritaire est un amplificateur pour les attaquants et une cible fréquente de floods. Deux décisions de conception font l'essentiel du travail pour le rendre résilient : gardez le primaire caché, et placez un load balancer qui comprend le DNS devant chaque serveur public. Voici comment, avec les règles que nous considérons comme le minimum.

Cachez le primaire

Le serveur où les zones sont éditées, où vivent les clés et où se trouve la copie maîtresse des données ne doit jamais répondre à l'internet. À la place, il se réplique vers des secondaires publics par un réseau strictement interne, et seuls les secondaires apparaissent dans les enregistrements NS.

Cela vous apporte trois choses. Le serveur le plus précieux n'est pas exposé aux floods ni aux exploits. Les serveurs publics deviennent jetables : si l'un est attaqué ou tombe, ses pairs continuent et il est reconstruit depuis le primaire. Et vous pouvez répartir les secondaires sur des réseaux, des sites et des plateformes différents, pour qu'aucun domaine de défaillance unique ne fasse tomber le domaine.

Que la réplication soit un AXFR et NOTIFY classique ou une réplication de base de données sous PowerDNS, la propriété à protéger est la même : l'adresse du primaire ne doit jamais apparaître dans un enregistrement NS ou SOA public. Vérifiez-le :

dig +short NS example.com
dig +short SOA example.com      # the MNAME field should not be your hidden primary

Pourquoi un load balancer générique ne suffit pas

Un load balancer TCP ou UDP peut répartir les requêtes, mais il ne peut pas les lire. Presque toute défense DNS utile dépend de la compréhension de la requête : son type, la zone qu'elle interroge, s'il s'agit d'un UPDATE, combien d'échecs une source génère. dnsdist, du projet PowerDNS, se place devant le nameserver, tient le port public et prend ces décisions avant que la requête n'atteigne le backend. Le serveur autoritaire lui-même n'écoute alors que sur localhost.

Les règles dnsdist que nous considérons comme le minimum

-- backend listens on localhost only
newServer({address="127.0.0.1:5300", name="auth"})
setLocal("0.0.0.0:53")
addLocal("[::]:53")

trusted = newNMG(); trusted:addMask("10.0.0.0/8")   -- your internal replication network
ourZones = newSuffixMatchNode(); ourZones:add("example.com.")

-- ANY queries are an amplification tool; refuse them
addAction(QTypeRule(DNSQType.ANY), RCodeAction(DNSRCode.REFUSED))

-- no dynamic updates or notifies from the internet
addAction(AndRule({OpcodeRule(DNSOpcode.Update), NotRule(NetmaskGroupRule(trusted))}),
          RCodeAction(DNSRCode.REFUSED))
addAction(AndRule({OpcodeRule(DNSOpcode.Notify), NotRule(NetmaskGroupRule(trusted))}),
          RCodeAction(DNSRCode.REFUSED))

-- only answer for zones we actually serve
addAction(NotRule(SuffixMatchNodeRule(ourZones)), RCodeAction(DNSRCode.REFUSED))

-- cap queries per source address
addAction(MaxQPSIPRule(50), DropAction())

-- automatic temporary blocks for sources generating floods of failures
local dbr = dynBlockRulesGroup()
dbr:setRCodeRate(DNSRCode.NXDOMAIN, 50, 10, "NXDOMAIN flood", 60)
dbr:setRCodeRate(DNSRCode.REFUSED, 50, 10, "REFUSED flood", 60)
function maintenance() dbr:apply() end

Ce que chaque règle vous apporte :

• Refuser ANY supprime la requête d'amplification classique.
• Refuser UPDATE et NOTIFY depuis l'extérieur ferme les chemins par lesquels le contenu des zones ou la réplication pourrait être influencé depuis l'internet.
• Refuser les zones que vous ne servez pas avant que le backend ne les voie tient les déchets aléatoires et les sondes de réflexion entièrement à l'écart du nameserver.
• Fixez des plafonds de débit par source à partir de votre trafic réel, assez généreux pour les gros resolvers.
• Les blocages dynamiques sur les taux d'échec attrapent les attaques par sous-domaines aléatoires, qui génèrent des floods de réponses NXDOMAIN depuis de nombreuses sources, sans bloquer un resolver pour une mauvaise minute.

Ajoutez du response rate limiting sur le backend ou dans dnsdist, pour que même des réponses d'apparence légitime ne puissent pas être transformées en flood vers une adresse usurpée.

DNSSEC sans brassage de clés

Si vos secondaires signent eux-mêmes les zones, chacun d'eux a besoin des clés, et la distribution des clés est l'endroit où les déploiements DNSSEC tournent mal. Quand les clés vivent dans la même base de données qui se réplique vers les secondaires, chaque serveur signe à l'identique par construction. Quand vous déplacez un domaine signé entre fournisseurs, procédez dans l'ordre : retirez l'ancien enregistrement DS au registre, attendez l'expiration des caches, signez sur les nouveaux serveurs, puis publiez le nouveau DS. La validation ne casse jamais.

Le reverse DNS fait partie du travail

Traitez le reverse DNS comme une règle : chaque adresse attribuée à une interface, un service ou un hôte reçoit un PTR dans le même changement, et chaque zone inverse est déléguée à tous vos nameservers. Vérifiez les deux directions et la délégation parente :

dig +short -x 192.0.2.25
dig +short host.example.com A
dig +short NS 2.0.192.in-addr.arpa

Les noms directs et inverses doivent concorder, et l'ensemble NS de la zone inverse doit correspondre à ce que le registre régional a enregistré.

Surveillez les réponses, pas seulement les serveurs

Un nameserver qui est en ligne mais sert une zone périmée est pire qu'un nameserver hors ligne, parce que rien ne déclenche d'alarme. Supervisez ce qui compte : comparez le serial SOA de chaque zone sur chaque serveur, comparez les nombres d'enregistrements, surveillez le retard de réplication, et alertez si le primaire caché apparaît un jour dans des données publiques. Vérifier depuis quelques points d'observation externes que chaque serveur public répond de façon autoritaire boucle la boucle.

Votre checklist

• Votre primaire est-il caché, et absent des NS et du SOA ?
• Les serveurs publics sont-ils derrière un front-end qui comprend le DNS et refuse ANY, les UPDATE et NOTIFY externes, et les zones inconnues ?
• Existe-t-il des limites par source et des blocages dynamiques pour les floods d'échecs ?
• Tous les serveurs signent-ils à l'identique, et votre procédure de rotation DS est-elle écrite ?
• Chaque adresse attribuée a-t-elle un PTR correspondant ?
• Alertez-vous sur une divergence de serial entre serveurs ?

Nous exploitons notre DNS autoritaire sur PowerDNS exactement de cette façon, et nous construisons des clusters dédiés pour les clients qui veulent le leur. Si vous souhaitez une revue de votre DNS, nous serons heureux de vous aider.

Parler à un ingénieur

Related

Sur le même sujet : DNS autoritaire et reverse DNS, exploités comme une infrastructure · DNS autoritaire et récursif sur PowerDNS · IPv6, natif et en dual-stack