Ένας hidden primary και το dnsdist. Θωράκιση του authoritative DNS

Το authoritative DNS είναι ενισχυτής για επιτιθέμενους και συχνός στόχος floods. Δύο σχεδιαστικές αποφάσεις κάνουν το μεγαλύτερο μέρος της δουλειάς για να γίνει ανθεκτικό: κρατήστε τον primary κρυφό, και βάλτε έναν load balancer που καταλαβαίνει DNS μπροστά από κάθε δημόσιο server. Να πώς, με τους κανόνες που θεωρούμε ελάχιστους.

Κρύψτε τον primary

Ο server όπου επεξεργάζονται οι ζώνες, ζουν τα κλειδιά και βρίσκεται το κύριο αντίγραφο των δεδομένων δεν πρέπει ποτέ να απαντά στο internet. Αντίθετα, κάνει replication σε δημόσιους secondaries μέσω ενός αποκλειστικά εσωτερικού δικτύου, και μόνο οι secondaries εμφανίζονται στις εγγραφές NS.

Αυτό σας δίνει τρία πράγματα. Ο πιο πολύτιμος server δεν εκτίθεται σε floods ή exploits. Οι δημόσιοι servers γίνονται αναλώσιμοι: αν ένας δεχτεί επίθεση ή αποτύχει, οι υπόλοιποι συνεχίζουν και αυτός ξαναχτίζεται από τον primary. Και μπορείτε να απλώσετε τους secondaries σε διαφορετικά δίκτυα, sites και πλατφόρμες, ώστε κανένα μεμονωμένο failure domain να μη ρίχνει το domain.

Είτε το replication είναι κλασικό AXFR και NOTIFY είτε database replication κάτω από το PowerDNS, η ιδιότητα που πρέπει να προστατεύσετε είναι η ίδια: η διεύθυνση του primary δεν πρέπει ποτέ να εμφανίζεται σε δημόσια εγγραφή NS ή SOA. Ελέγξτε το:

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

Γιατί ένας γενικός load balancer δεν αρκεί

Ένας load balancer TCP ή UDP μπορεί να μοιράσει τα queries, αλλά δεν μπορεί να τα διαβάσει. Σχεδόν κάθε χρήσιμη άμυνα DNS εξαρτάται από την κατανόηση του query: τον τύπο του, τη ζώνη για την οποία ρωτά, αν είναι UPDATE, πόσες αποτυχίες παράγει μια πηγή. Το dnsdist, από το project PowerDNS, κάθεται μπροστά από τον nameserver, κρατά τη δημόσια θύρα και παίρνει αυτές τις αποφάσεις πριν το query φτάσει στο backend. Ο ίδιος ο authoritative server ακούει τότε μόνο στο localhost.

Οι κανόνες dnsdist που θεωρούμε ελάχιστους

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

Τι σας δίνει κάθε κανόνας:

• Η απόρριψη του ANY αφαιρεί το κλασικό query ενίσχυσης.
• Η απόρριψη UPDATE και NOTIFY από έξω κλείνει τις διαδρομές από τις οποίες το περιεχόμενο ζώνης ή το replication θα μπορούσε να επηρεαστεί από το internet.
• Η απόρριψη ζωνών που δεν εξυπηρετείτε πριν τις δει το backend κρατά τα τυχαία σκουπίδια και τα reflection probes εντελώς μακριά από τον nameserver.
• Ορίστε όρια ρυθμού ανά πηγή με βάση την πραγματική σας κίνηση, αρκετά γενναιόδωρα για μεγάλους resolvers.
• Τα δυναμικά blocks στους ρυθμούς αποτυχίας πιάνουν επιθέσεις τυχαίων subdomains, που παράγουν floods απαντήσεων NXDOMAIN από πολλές πηγές, χωρίς να μπλοκάρουν έναν resolver για ένα κακό λεπτό.

Προσθέστε response rate limiting στο backend ή στο dnsdist, ώστε ακόμα και απαντήσεις που μοιάζουν νόμιμες να μην μπορούν να μετατραπούν σε flood προς μια πλαστογραφημένη διεύθυνση.

DNSSEC χωρίς ανακάτεμα κλειδιών

Αν οι secondaries σας υπογράφουν οι ίδιοι τις ζώνες, καθένας τους χρειάζεται τα κλειδιά, και η διανομή κλειδιών είναι εκεί όπου πάνε στραβά τα deployments DNSSEC. Όταν τα κλειδιά ζουν στην ίδια βάση δεδομένων που κάνει replication στους secondaries, κάθε server υπογράφει πανομοιότυπα εκ κατασκευής. Όταν μεταφέρετε ένα υπογεγραμμένο domain μεταξύ παρόχων, κάντε το με σειρά: αφαιρέστε την παλιά εγγραφή DS στο μητρώο, περιμένετε να λήξουν οι caches, υπογράψτε στους νέους servers, και μετά δημοσιεύστε τη νέα DS. Η επικύρωση δεν σπάει ποτέ.

Το reverse DNS είναι μέρος της δουλειάς

Αντιμετωπίστε το reverse DNS ως κανόνα: κάθε διεύθυνση που ανατίθεται σε interface, υπηρεσία ή host παίρνει PTR στην ίδια αλλαγή, και κάθε reverse ζώνη ανατίθεται σε όλους τους nameservers σας. Ελέγξτε και τις δύο κατευθύνσεις και την ανάθεση από τον γονέα:

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

Τα ονόματα forward και reverse πρέπει να συμφωνούν, και το σύνολο NS της reverse ζώνης πρέπει να ταιριάζει με αυτό που έχει καταχωρημένο το περιφερειακό μητρώο.

Παρακολουθήστε τις απαντήσεις, όχι μόνο τους servers

Ένας nameserver που είναι πάνω αλλά εξυπηρετεί μια παλιά ζώνη είναι χειρότερος από έναν που είναι κάτω, γιατί τίποτα δεν χτυπάει συναγερμό. Παρακολουθήστε αυτό που μετράει: συγκρίνετε το SOA serial κάθε ζώνης σε κάθε server, συγκρίνετε πλήθη εγγραφών, παρακολουθήστε την καθυστέρηση replication, και ειδοποιήστε αν ο hidden primary εμφανιστεί ποτέ σε δημόσια δεδομένα. Ο έλεγχος από μερικά εξωτερικά σημεία ότι κάθε δημόσιος server απαντά authoritatively κλείνει τον κύκλο.

Η λίστα ελέγχου σας

• Είναι ο primary σας κρυφός, και απών από NS και SOA;
• Είναι οι δημόσιοι servers πίσω από ένα front end που καταλαβαίνει DNS και απορρίπτει ANY, εξωτερικά UPDATE και NOTIFY, και άγνωστες ζώνες;
• Υπάρχουν όρια ανά πηγή και δυναμικά blocks για floods αποτυχιών;
• Υπογράφουν όλοι οι servers πανομοιότυπα, και είναι γραμμένη η διαδικασία DS rollover;
• Έχει κάθε ανατεθειμένη διεύθυνση αντίστοιχο PTR;
• Ειδοποιείστε σε ασυμφωνία serial μεταξύ servers;

Λειτουργούμε το authoritative DNS μας σε PowerDNS ακριβώς έτσι, και χτίζουμε αποκλειστικά clusters για πελάτες που θέλουν δικό τους. Αν θέλετε μια αξιολόγηση του DNS σας, θα χαρούμε να βοηθήσουμε.

Μιλήστε με έναν μηχανικό

Related

Σχετικά: Authoritative DNS και reverse DNS, ως υποδομή · Authoritative και recursive DNS σε PowerDNS · IPv6, native και dual-stack