Endereço IP privado no DNS público

Question

Temos um servidor de e-mail SMTP somente atrás de um firewall que terá um registro público de e-mail. . A única maneira de acessar esse servidor de e-mail é de outro servidor atrás do mesmo firewall. Nós não rodamos nosso próprio servidor DNS privado.

É uma boa idéia usar o endereço IP privado como um registro A em um servidor DNS público - ou é melhor manter esses registros do servidor em cada arquivo de hosts local de servidores?

    

Answer 1

Algumas pessoas dirão que nenhum registro de DNS público deve divulgar endereços IP privados ... com o pensamento de que você está dando aos invasores em potencial uma vantagem sobre algumas informações que podem ser necessárias para explorar sistemas privados.

Pessoalmente, acho que a ofuscação é uma forma inadequada de segurança, especialmente quando estamos falando de endereços IP porque, em geral, eles são fáceis de adivinhar de qualquer maneira, então não vejo isso como um compromisso realista de segurança.

A consideração maior aqui é garantir que seus usuários públicos não capturem esse registro DNS como parte dos serviços públicos normais do seu aplicativo hospedado. Ex: pesquisas de DNS externos de alguma forma começam a resolver para um endereço que eles não conseguem acessar.

Além disso, não vejo nenhuma razão fundamental para colocar os registros de endereços privados A no espaço público, o que é um problema ... especialmente quando você não tem um servidor DNS alternativo para hospedá-los.

Se você decidir colocar esse registro no espaço DNS público, poderá considerar criar uma zona separada no mesmo servidor para armazenar todos os registros "privados". Isso tornará mais claro que eles devem ser privados ... no entanto, para apenas um registro A, eu provavelmente não me incomodaria.

    

Answer 2

Eu tive uma longa discussão sobre esse assunto na lista NANOG há um tempo atrás. Embora eu sempre achasse que era uma má ideia, acontece que não é uma idéia tão ruim na prática. As dificuldades vêm principalmente de pesquisas de rDNS (que para endereços privados Just Don't Work no mundo externo), e quando você está fornecendo acesso aos endereços através de uma VPN ou similar, é importante garantir que os clientes VPN estejam protegidos adequadamente de "vazando" o tráfego quando a VPN está inoperante.

Eu digo, vá em frente. Se um invasor conseguir que algo significativo seja capaz de resolver nomes para endereços internos, você terá maiores problemas de segurança.

    

Answer 3

Em geral, a introdução de endereços RFC1918 no DNS público causará confusão, se não um problema real, em algum momento no futuro. Use IPs, registros de host ou uma exibição de DNS privado de sua zona para usar os endereços RFC1918 por trás do firewall, mas não os inclua na exibição pública.

Para esclarecer minha resposta com base na outra resposta enviada, acho que introduzir os endereços RFC1918 no DNS público é um engano falso, não um problema de segurança. Se alguém me chamar para resolver um problema e eu me deparo com endereços RFC1918 em seu DNS, começo a falar muito devagar e pergunto se eles foram reinicializados recentemente. Talvez seja esnobismo da minha parte, não sei. Mas como eu disse, não é uma coisa necessária para fazer e é provável que cause confusão e falta de comunicação (humana, não computador) em algum momento. Por que arriscar?

    

Answer 4

Não, não coloque seus endereços IP privados no DNS público.

Em primeiro lugar, vaza informações, embora seja um problema relativamente pequeno.

O problema pior se os seus registros MX apontarem para essa entrada de host específica é que qualquer um que tentar enviar uma mensagem para ela receberá, na melhor das hipóteses, tempos limite de entrega de e-mail.

Dependendo do software de email do remetente, eles podem receber rejeições.

Ainda pior, se você estiver usando o espaço de endereçamento RFC1918 (que deve dentro da sua rede) e o remetente também, há toda chance de que eles tentem e entreguem o e-mail em sua própria rede.

Por exemplo:

• a rede tem servidor de e-mail interno, mas nenhum DNS dividido
O
• admin, portanto, coloca endereços IP públicos e internos no DNS
• e os registros MX apontam para ambos:

 $ORIGIN example.com
 @        IN   MX    mail.example.com
 mail     IN   A     192.168.1.2
          IN   A     some_public_IP

• alguém que vê isso pode tentar se conectar a 192.168.1.2
• melhor caso, ele salta, porque eles não têm rota
• mas se eles também tiverem um servidor usando 192.168.1.2, o email irá para o lugar errado

Sim, é uma configuração quebrada, mas eu vi isso (e pior) acontecer.

Não, não é culpa do DNS, é apenas fazer o que é dito.

    

Answer 5

Suas duas opções são / etc / hosts e colocar um endereço IP privado em sua zona pública. Eu recomendo o primeiro. Se isso representa um grande número de hosts, você deve considerar executar seu próprio resolvedor internamente, não é tão difícil.

    

Answer 6

Embora a possibilidade seja remota, acho que você pode estar se preparando para um ataque MITM.

Minha preocupação seria essa. Digamos que um de seus usuários com um cliente de e-mail configurado para apontar para esse servidor de e-mail leve seu laptop para outra rede. O que acontece se essa outra rede também tiver o mesmo RFC1918 em uso. Esse laptop pode tentar fazer login no servidor SMTP e oferecer as credenciais do usuário a um servidor que não deveria tê-lo. Isto seria particularmente verdadeiro desde que você disse SMTP e não mencionou que você requer SSL.

    

Answer 7

É melhor mantê-lo no arquivo hosts. Se apenas uma máquina supostamente se conectar a ela de qualquer maneira, o que você ganha colocando-a no DNS público?

    

Answer 8

Se por particular você quer dizer 10.0.0.0/8, 192.168.0.0/16 ou 172.16.0.0/12, então não . A maioria dos roteadores de internet a reconhecem pelo que é - um endereço privado que deve nunca ser roteado para a internet pública de uma forma direta , que é o que ajudou a popularidade do NAT. Qualquer pessoa que tente entrar em contato com seu servidor DNS público irá recuperar o endereço IP privado do DNS, apenas para enviar um pacote para ... em nenhum lugar. À medida que a conexão deles tenta atravessar a Internet para o seu endereço particular, alguns roteadores (configurados de maneira adequada) ao longo do caminho simplesmente comerão o pacote com vida.

Se você quiser que o e-mail do "externo" entre "dentro", em algum momento, o pacote terá que atravessar o seu firewall. Eu sugeriria configurar um endereço DMZ para lidar com isso - um único endereço IP público que é rigidamente controlado por qualquer roteador / firewall que você tenha instalado. A configuração existente que você descreve parece que faz exatamente isso.

EDIT: esclarecimento de intenção ... (veja os comentários abaixo). Se isso não fizer sentido, vou votar para remover meu próprio post.

    

Answer 9

Pode haver problemas sutis com isso. Uma é que as soluções comuns para o DNS Rebindir ataques filtram as entradas DNS locais resolvidas de servidores DNS públicos. Então você se abre para revincular ataques, ou endereços locais não funcionam, ou requer uma configuração mais sofisticada (se o seu software / roteador permitir isso).