¿Cuál es el punto de la opción sshd "UseDNS"?

79

Sé lo que hace, pero no sé por qué . ¿Qué ataque (s) previene?

¿Es relevante para todo tipo de métodos de autenticación? (basado en host, contraseña, clave pública, teclado interactivo ...)

— usuario368507
fuente

2

También agregué uno a CoreOS aquí: github.com/coreos/bugs/issues/92

66

La UseDNSopción es en su mayoría inútil. Si las máquinas cliente están disponibles en Internet, existe una gran posibilidad de que no tengan ningún DNS inverso, su DNS inverso no se resuelva, o su DNS no proporcione ninguna información que no sea "pertenece a esto ISP ”, que la dirección IP ya le indica.

En configuraciones típicas, el DNS solo se usa para iniciar sesión. Se puede usar para la autenticación, pero solo si IgnoreRhosts nose especifica en sshd_config. Esto es para la compatibilidad con antiguas instalaciones que utilizan rsh, donde se puede decir que “el usuario llamado boben la máquina llamada darkstarpuede iniciar sesión como alicesin mostrar ninguna credencial” (escribiendo darkstar boben ~alice/.rhosts). Solo es seguro si confía en todas las máquinas que posiblemente se estén conectando al servidor ssh. En otras palabras, esto es muy raramente utilizable de manera segura.

Dado que la búsqueda de DNS no proporciona ninguna información útil, excepto en circunstancias muy peculiares, debe desactivarse. Por lo que puedo decir, la única razón por la que está activada de forma predeterminada es que es técnicamente más seguro (si le preocupa la autenticación, no la disponibilidad), aunque eso solo se aplica a un pequeño conjunto de circunstancias.

Otro argumento para desactivar esta función es que cada función superflua es un riesgo de seguridad innecesario .

— Gilles
fuente

Entonces, ¿UseDNS es relevante solo para la autenticación basada en host? Si no uso la autenticación basada en host y no me importa si el nombre de host o la IP aparecen en los registros, ¿UseDNS no hace ninguna diferencia?

— user368507

55

@ user368507 Sí, eso es todo. UseDNSni siquiera es útil si usa autenticación de host basada en clave , solo si usa autenticación de host basada en nombre de host (es decir, autenticación extremadamente débil).

— Gilles

3

@Gilles, por supuesto, si usa autenticación basada en clave y en nombre de host, UseDNSes muy útil y crítico. Autentica un usuario basado en la clave y el servidor basado en el nombre de host, asignado a una dirección MAC.

— kara deniz

38

Agregué a un informe de error (antiguo pero aún actual) en Ubuntu sobre esto.

https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/424371

Propuse cambiar el valor predeterminado a No y agregar documentación más reciente:

# UseDNS - Determines whether IP Address to Hostname lookup and comparison is performed
# Default value is No which avoids login delays when the remote client's DNS cannot be resolved
# Value of No implies that the usage of "from=" in authorized_keys will not support DNS host names but only IP addresses.
# Value of Yes supports host names in "from=" for authorized_keys. Additionally if the remote client's IP address does not match the resolved DNS host name (or could not be reverse lookup resolved) then a warning is logged.

— Rodney
fuente

2

Up up upvote ... esto es más útil, porque contiene una información que estaba buscando.

— 0xC0000022L

1

Del mismo modo, si UseDNS es no, los nombres de host no pueden coincidir en las reglas de pam_access y, en su lugar, deben usarse IP.

— ColinM

1

Voté esta respuesta hace un par de años, pero solo hoy me di cuenta de que el valor predeterminado se cambió a "UseDNS no" en OpenSSH 6.8p1, que se encuentra en Ubuntu 15.10 y versiones posteriores .

— Anthony G - justicia para Monica

RedHat (en RHEL7) recientemente también cambió el valor predeterminado a No, lo que rompe los controles de acceso basados en el nombre de host (que son útiles como controles de asesoramiento en su mayoría en una intranet, obviamente no como el único mecanismo de control de acceso).

— dannysauer

8

De la página de manual de sshd_config(5):

 UseDNS  Specifies whether sshd(8) should look up the remote host name and
         check that the resolved host name for the remote IP address maps
         back to the very same IP address.  The default is “yes”.

Al habilitar esto, el acceso desde una ubicación sin DNS adecuado (hacia adelante y hacia atrás) genera una advertencia en los registros.

Por lo tanto, esto no evita ningún ataque, excepto que necesitaría alguna dirección remota calificada del cliente para no registrar ninguna advertencia. Tal advertencia puede ayudarlo a localizar al atacante solo si ese registro PTR tiene algún sentido.

^{editar: actualizado según el comentario de Andrey Voitenkov .}

— gertvdijk
fuente

Entonces, ¿es un filtro sobre quién puede conectarse según lo que haya en el servidor DNS?

— user368507

2

¿Por qué haría imposible el acceso? sshd solo genera una advertencia si los registros DNS A / PTR no coinciden. La secuencia de inicio de sesión será lenta en caso de resolver problemas.

— Andrey Voitenkov

Esto impide el acceso si la clave autorizada se ha visto comprometida siempre que el atacante no pueda falsificar los valores en el from=campo antes de la clave autorizada en cuestión (si se utiliza).

— Alecz

7

Es necesario cuando usa la opción FROM en un archivo autorizado_keys y desea filtrar por nombres y no solo por IP.

La opción FROM en una línea de un archivo autorizado_keys le permite limitar los hosts que pueden usar una clave específica.
Esto aumenta la capacidad de administrar múltiples servidores que tienen acceso entre sí sin permitir que los clones de una máquina se hagan pasar por su origen, generalmente sin querer (restos de crontabs, error humano).

— Didi Kohen
fuente

3

Me gustaría añadir que en CentOS 7 (07/01/1503) y por lo tanto de Red Hat Enterprise Linux 7, yo era incapaz de iniciar sesión con la configuración predeterminada de yespara UseDNS. Después de descomentarlo y configurarlo no, pude iniciar sesión. Por lo tanto, parece que se le puede negar el servicio si DNS no funciona correctamente. ¡En CentOS 6, parece que el valor predeterminado es noy, por lo tanto, puedo entrar sshsin DNS funcional!

Me gustaría agregar que mi experimentación fue en contenedores LXC y no en máquinas físicas, ¡en caso de que eso marque la diferencia!

— AnthonyK
fuente