Verificação de sanidade de arquitetura DNS

1

Estou projetando o serviço DNS para uma rede e tenho algumas questões de arquitetura. O livro O'Reilly / Cricket Liu DNS e o Guia de segurança NIST DNS não aborda essas questões, exceto de uma forma muito geral.

Aqui está a rede proposta, que tem segmentos internos (espaço RFC 1918) e DMZ (com vários servidores, não apenas servidores DNS), bem como servidores de e-mail e www em um local externo. Os servidores DNS são as caixas azuis:

Aqui estão os requisitos:

  • Suporte DNSSEC
  • Nas redes internas, delegação a zonas internas na RFC 1918 espaço
  • Servidores autoritativos e recursivos separados
  • Mestre oculto (primário oculto) permite transferências de zona para escravos, mas não resolve solicitações
  • Todos os servidores de nomes são executados chrooted (o padrão com Bind no FreeBSD)

Aqui estão minhas perguntas:

  1. Existe alguma coisa obviamente quebrada nesse design?

  2. Há algum elemento ausente ou estranho aqui?

  3. OK para executar o mestre oculto na mesma sub-rede que os servidores escravos internos?

  4. Dado o tráfego DNS relativamente leve (< 1 Mbps) nas redes interna e DMZ, há problemas de segurança na execução dos servidores somente de cache nas cadeias (fala BSD para VMs) nos servidores autoritativos? Ou deveriam estar em máquinas dedicadas?

Obrigado antecipadamente!

    
por user8162 26.09.2013 / 06:11

1 resposta

1

Here are my questions:

1) Is there anything obviously broken about this design?

Nada é Obviamente errado. .. Pelo menos isso eu posso ver.

2) Are there any missing or extraneous elements here?

Ausente : Você se sente à vontade para não ficar em estado de espera por seu mestre oculto? O sistema parece bastante engenheirado (não quero chamá-lo de engenharia sem ver seu caso de uso) para confiar em um único host primário. Está fora do escopo do seu diagrama, mas você tem um plano de contingência para quando [ não se] o mestre principal explodir?

Extraneous : Lembre-se de que todo servidor de DNS que você adiciona à mistura é outro servidor que deve ser gerenciado. Dado o seu uso, é essencial ter muitos servidores DNS?

3) OK to run the hidden master on the same subnet as the internal slave servers?

Eu esperaria que o mestre oculto e os escravos de DNS autoritários estivessem no dmz. Bloqueie o mestre adequadamente. Os escravos internos estão respondendo a pesquisas de autoridade para a sua zona da internet correta? Se os escravos internos só responderem às consultas da sua zona nos hosts internos, você precisará de uma zona HUGE , um número bobo de pesquisas internas para sua zona interna ( considere cache de servidores DNS no nível de host / estação de trabalho ), ou você deu muito poder a cavalo para o DNS interno. Se eles estão respondendo a consultas da internet, eu esperaria que eles estivessem na DMZ. Você é livre para rotulá-los como quiser.

Tanto quanto o mestre está na mesma sub-rede que os escravos - Bloqueie-o. Não deve ser um problema (e você economizará um pouco de overhead de roteamento no horário xfer da zona).

4) Given relatively light DNS traffic (< 1 Mbps) on the internal and DMZ networks, are there security issues to running the caching-only servers in jails (BSD-speak for VMs) on the authoritative servers? Or should they be on dedicated machines?

Sim. Sempre há problemas de segurança. Se apenas os servidores internos de armazenamento em cache estiverem bloqueados para aceitar somente tráfego de fontes internas, eles serão colocados em prisões, em um ambiente supostamente BSD, e atualizados e monitorados regularmente ... Um hacker tem muito trabalho a fazer para explorar o ambiente .

Seu maior risco (Veja: não um analista de risco profissional) é a chance de um hacker, por um golpe de milagre, ser a possibilidade de ter um de seus escravos de DNS autoritários sendo sequestrados . É provável que resulte em desfiguração parcial, ou se o invasor for realmente brilhante, algum "envenenamento" e roubo de informações (veja: SSL / TLS para colocar um exemplo sobre isso).

O próximo maior (Veja: não um analista de risco profissional) é a corrupção do SO escravo que requer a reinstalação / restauração.

Por fim:

É um projeto bastante sólido e sem uma visão da rede (que você não deve nos fornecer), é muito difícil encontrar falhas / defeitos no design. A única coisa que claramente se destaca é: há muitas peças, uma configuração complexa e muita engenharia aqui ... Certifique-se de que haja um negócio para isso.

Ex: Você pode executar o Bind9 como um escravo autoritativo, que faz buscas recursivas / de encaminhamento e armazena tudo em um daemon. (e salva multihoming / port forwarding / outra mágica de rede para obter dois daemons DNS respondendo na mesma caixa).

    
por 26.09.2013 / 08:58