Um hidden primary e o dnsdist. Hardening do DNS autoritativo

O DNS autoritativo é um amplificador para atacantes e um alvo frequente de floods. Duas decisões de desenho fazem a maior parte do trabalho de o tornar resiliente: manter o primary escondido, e colocar um load balancer que entende DNS à frente de cada servidor público. Eis como, com as regras que consideramos o mínimo.

Esconda o primary

O servidor onde as zonas são editadas, onde vivem as chaves e onde está a cópia principal dos dados nunca deve responder à internet. Em vez disso, replica para secondaries públicos através de uma rede exclusivamente interna, e só os secondaries aparecem nos registos NS.

Isso dá três coisas. O servidor mais valioso não fica exposto a floods nem a exploits. Os servidores públicos tornam-se descartáveis: se um for atacado ou falhar, os restantes continuam e esse pode ser reconstruído a partir do primary. E pode espalhar os secondaries por redes, sites e plataformas diferentes, para que nenhum domínio de falha isolado derrube o domínio.

Quer a replicação seja AXFR e NOTIFY clássicos ou replicação de base de dados por baixo do PowerDNS, a propriedade a proteger é a mesma: o endereço do primary nunca deve aparecer num registo NS ou SOA público. Verifique:

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

Porque um load balancer genérico não chega

Um load balancer TCP ou UDP consegue distribuir as queries, mas não consegue lê-las. Quase todas as defesas DNS úteis dependem de compreender a query: o seu tipo, a zona sobre a qual pergunta, se é um UPDATE, quantas falhas uma origem está a gerar. O dnsdist, do projeto PowerDNS, fica à frente do nameserver, detém a porta pública e toma essas decisões antes de a query chegar ao backend. O próprio servidor autoritativo passa então a escutar apenas em localhost.

As regras dnsdist que consideramos o mínimo

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

O que cada regra lhe dá:

• Recusar ANY remove a query clássica de amplificação.
• Recusar UPDATE e NOTIFY vindos de fora fecha os caminhos pelos quais o conteúdo das zonas ou a replicação poderiam ser influenciados a partir da internet.
• Recusar zonas que não serve antes de o backend as ver mantém o lixo aleatório e as sondas de reflexão totalmente longe do nameserver.
• Defina limites de ritmo por origem a partir do seu tráfego real, com generosidade suficiente para resolvers grandes.
• Os bloqueios dinâmicos por taxa de falhas apanham ataques de subdomínios aleatórios, que geram floods de respostas NXDOMAIN a partir de muitas origens, sem bloquear um resolver por um minuto mau.

Acrescente response rate limiting no backend ou no dnsdist, para que nem respostas de aspeto legítimo possam ser transformadas num flood em direção a um endereço forjado.

DNSSEC sem baralhar chaves

Se os seus secondaries assinam eles próprios as zonas, cada um deles precisa das chaves, e distribuir chaves é onde as implementações de DNSSEC correm mal. Quando as chaves vivem na mesma base de dados que replica para os secondaries, todos os servidores assinam de forma idêntica por construção. Quando mover um domínio assinado entre fornecedores, faça-o por ordem: remova o DS antigo no registo, espere que as caches expirem, assine nos novos servidores e só depois publique o novo DS. A validação nunca quebra.

O reverse DNS faz parte do trabalho

Trate o reverse DNS como regra: todos os endereços atribuídos a uma interface, serviço ou host recebem um PTR na mesma alteração, e todas as zonas reverse são delegadas a todos os seus nameservers. Verifique os dois sentidos e a delegação do pai:

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

Os nomes forward e reverse devem coincidir, e o conjunto NS da zona reverse deve corresponder ao que o registo regional tem em ficheiro.

Observe as respostas, não só os servidores

Um nameserver que está ativo mas serve uma zona desatualizada é pior do que um que está em baixo, porque nada dispara um alarme. Monitorize o que importa: compare o SOA serial de cada zona em todos os servidores, compare contagens de registos, observe o atraso de replicação, e alerte se o hidden primary alguma vez aparecer em dados públicos. Verificar a partir de alguns pontos externos que todos os servidores públicos respondem de forma autoritativa fecha o ciclo.

A sua lista de verificação

• O seu primary está escondido, e ausente de NS e SOA?
• Os servidores públicos estão atrás de um front end que entende DNS e recusa ANY, UPDATE e NOTIFY externos, e zonas desconhecidas?
• Existem limites por origem e bloqueios dinâmicos para floods de falhas?
• Todos os servidores assinam de forma idêntica, e o procedimento de DS rollover está escrito?
• Todos os endereços atribuídos têm um PTR correspondente?
• Alerta quando há divergência de serial entre servidores?

Operamos o nosso DNS autoritativo em PowerDNS exatamente assim, e construímos clusters dedicados para clientes que querem o seu. Se quiser uma revisão do seu DNS, teremos todo o gosto em ajudar.

Fale com um engenheiro

Related

Relacionados: Authoritative DNS e reverse DNS, operados como infraestrutura · DNS autoritativo e recursivo em PowerDNS · IPv6, nativo e dual-stack