Tenemos un único servidor de correo SMTP detrás de un firewall que tendrá un registro público de correo. . La única forma de acceder a este servidor de correo es desde otro servidor detrás del mismo firewall. No ejecutamos nuestro propio servidor DNS privado.
¿Es una buena idea usar la dirección IP privada como un registro A en un servidor DNS público, o es mejor mantener estos registros del servidor en el archivo de host local de cada servidor?
Respuestas:
Algunas personas dirán que ningún registro DNS público debería revelar direcciones IP privadas ... con la idea de que estás dando a los posibles atacantes una ventaja sobre alguna información que pueda ser necesaria para explotar sistemas privados.
Personalmente, creo que la ofuscación es una forma pobre de seguridad, especialmente cuando hablamos de direcciones IP porque en general son fáciles de adivinar de todos modos, por lo que no veo esto como un compromiso de seguridad realista.
La consideración más importante aquí es asegurarse de que sus usuarios públicos no recojan este registro DNS como parte de los servicios públicos normales de su aplicación alojada. es decir: las búsquedas de DNS externo de alguna manera comienzan a resolverse en una dirección a la que no pueden acceder.
Aparte de eso, no veo una razón fundamental por la cual poner registros de la dirección privada A en el espacio público es un problema ... especialmente cuando no tienes un servidor DNS alternativo para alojarlos.
Si decide colocar este registro en el espacio DNS público, puede considerar crear una zona separada en el mismo servidor para contener todos los registros "privados". Esto hará más claro que están destinados a ser privados ... sin embargo, para un solo registro A, probablemente no me molestaría.
Tuve una larga discusión sobre este tema en la lista NANOG hace un tiempo. Aunque siempre pensé que era una mala idea, resulta que no es tan mala en la práctica. Las dificultades provienen principalmente de las búsquedas de rDNS (que para direcciones privadas simplemente no funcionan en el mundo exterior), y cuando proporciona acceso a las direcciones a través de una VPN o similar, es importante asegurarse de que los clientes VPN estén protegidos adecuadamente de Tráfico de "fuga" cuando la VPN está inactiva.
Yo digo ve por ello. Si un atacante puede obtener algo significativo de poder resolver nombres en direcciones internas, tiene mayores problemas de seguridad.
En general, la introducción de direcciones RFC1918 en el DNS público causará confusión, si no un problema real, en algún momento en el futuro. Use direcciones IP, registros de host o una vista de DNS privada de su zona para usar las direcciones RFC1918 detrás de su firewall, pero no las incluya en la vista pública.
Para aclarar mi respuesta basada en la otra respuesta presentada, creo que introducir las direcciones RFC1918 en el DNS público es un paso en falso, no un problema de seguridad. Si alguien me llama para solucionar un problema y me encuentro con direcciones RFC1918 en su DNS, empiezo a hablar muy lentamente y les pregunto si se han reiniciado recientemente. Tal vez eso es esnobismo de mi parte, no lo sé. Pero como dije, no es algo necesario y es probable que cause confusión y falta de comunicación (humana, no informática) en algún momento. ¿Por qué arriesgarse?
No, no coloque sus direcciones IP privadas en el DNS público.
En primer lugar, filtra información, aunque es un problema relativamente menor.
El peor problema si sus registros MX apuntan a esa entrada de host en particular es que cualquier persona que intente enviarle correo recibirá, en el mejor de los casos, tiempos de espera de entrega de correo.
Dependiendo del software de correo del remitente, pueden obtener rebotes.
Peor aún, si está utilizando el espacio de direcciones RFC1918 (que debería, dentro de su red) y el remitente también lo está, hay muchas posibilidades de que intenten enviar el correo a su propia red.
Por ejemplo:
$ORIGIN example.com
@ IN MX mail.example.com
mail IN A 192.168.1.2
IN A some_public_IP
Sí, es una configuración rota, pero he visto esto (y peor) suceder.
No, no es culpa de DNS, solo está haciendo lo que se le dice.
Aunque la posibilidad es remota, creo que puede estar preparándose para algunos ataques MITM.
Mi preocupación sería esta. Digamos que uno de sus usuarios con un cliente de correo configurado para apuntar a ese servidor de correo lleva su computadora portátil a otra red. ¿Qué sucede si esa otra red también tiene el mismo RFC1918 en uso? Esa computadora portátil puede intentar iniciar sesión en el servidor smtp y ofrecer las credenciales del usuario a un servidor que no debería tenerla. Esto sería particularmente cierto ya que dijiste SMTP y no mencionaste que estabas requiriendo SSL.
Sus dos opciones son / etc / hosts y poner una dirección IP privada en su zona pública. Yo recomendaría lo primero. Si esto representa una gran cantidad de hosts, debería considerar ejecutar su propio resolutor internamente, no es tan difícil.
Puede haber problemas sutiles con él. Una de ellas es que las soluciones comunes a los ataques DNS Rebind filtran las entradas DNS locales resueltas de los servidores DNS públicos. Por lo tanto, puede abrirse para volver a vincular los ataques, o las direcciones locales no funcionan o requieren una configuración más sofisticada (si su software / enrutador lo permite).
Es mejor mantenerlo en el archivo de hosts. Si se supone que solo una máquina se conecta a ella de todos modos, ¿qué gana al ponerla en un DNS público?
/etc/hostsarchivo porque las 2,000 máquinas necesitan administrar estos pares de IP / nombre ...
Si por privado te refieres a 10.0.0.0/8, 192.168.0.0/16 o 172.16.0.0/12, entonces no lo hagas . La mayoría de los enrutadores de Internet lo reconocen por lo que es: una dirección privada que nunca debe enrutarse a Internet pública de manera directa , que es lo que ayudó a la popularidad de NAT. Cualquiera que intente ponerse en contacto con su servidor DNS público recuperará la dirección IP privada del DNS, solo para enviar un paquete a ... en ninguna parte. A medida que su conexión intenta atravesar Internet hacia su dirección privada, algunos enrutadores (configurados de manera sensata) en el camino simplemente se comerán el paquete con vida.
Si desea recibir un correo electrónico del "exterior" para entrar "dentro", en algún momento, el paquete debe cruzar su firewall. Sugeriría configurar una dirección DMZ para manejar esto: una única dirección IP pública que esté estrictamente controlada por cualquier enrutador / firewall que tenga instalado. La configuración existente que describe suena como si fuera exactamente eso.
EDITAR: aclaración de intenciones ... (ver comentarios a continuación). Si esto no tiene sentido, votaré para eliminar mi propia publicación.
Llegué aquí porque estaba buscando información similar y me sorprendió que muchos digan que está bien filtrar sus direcciones IP privadas. Supongo que en términos de hackeo, no hace una gran diferencia si estás en una red segura. Sin embargo, DigitalOcean ha tenido todo el tráfico de la red local en exactamente los mismos cables y todos realmente tienen acceso al tráfico de todos los demás (probablemente factible con un ataque Man in the Middle). Si solo tuviera una computadora en el mismo centro de datos, tener eso la información ciertamente te da un paso más cerca de piratear mi tráfico. (Ahora cada cliente tiene su propia red privada reservada, como con otros servicios en la nube, como AWS).
Dicho esto, con su propio servicio BIND9, puede definir fácilmente sus IP públicas y privadas. Esto se hace usando la viewfunción, que incluye un condicional. Esto le permite consultar un DNS y obtener una respuesta sobre las IP internas solo si está preguntando desde su propia dirección IP interna.
La configuración requiere dos zonas. La selección utiliza el match-clients. Aquí hay un ejemplo de configuración desde un servidor DNS dos en uno con BIND9 :
acl slaves {
195.234.42.0/24; // XName
193.218.105.144/28; // XName
193.24.212.232/29; // XName
};
acl internals {
127.0.0.0/8;
10.0.0.0/24;
};
view "internal" {
match-clients { internals; };
recursion yes;
zone "example.com" {
type master;
file "/etc/bind/internals/db.example.com";
};
};
view "external" {
match-clients { any; };
recursion no;
zone "example.com" {
type master;
file "/etc/bind/externals/db.example.com";
allow-transfer { slaves; };
};
};
Aquí está la zona externa y podemos ver que las IP no son privadas
; example.com
$TTL 604800
@ IN SOA ns1.example.com. root.example.com. (
2006020201 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800); Negative Cache TTL
;
@ IN NS ns1
IN MX 10 mail
IN A 192.0.2.1
ns1 IN A 192.0.2.1
mail IN A 192.0.2.128 ; We have our mail server somewhere else.
www IN A 192.0.2.1
client1 IN A 192.0.2.201 ; We connect to client1 very often.
En cuanto a la zona interna, primero incluimos la zona externa, que es cómo funciona. es decir, si usted es una computadora interna, solo accede a la zona interna, por lo que aún necesita las definiciones de zona externa, de ahí el $includecomando:
$include "/etc/bind/external/db.example.com"
@ IN A 10.0.0.1
boss IN A 10.0.0.100
printer IN A 10.0.0.101
scrtry IN A 10.0.0.102
sip01 IN A 10.0.0.201
lab IN A 10.0.0.103
Finalmente, debe asegurarse de que todas sus computadoras ahora utilicen ese DNS y sus esclavos. Suponiendo una red estática, significaría editar su /etc/network/interfacesarchivo y usar sus IP de DNS en la nameserveropción. Algo como esto:
iface eth0 inet static
...
nameserver 10.0.0.1 10.0.0.103 ...
Ahora deberías estar listo.