1.5. Cómo hacer que OpenSSH sea más seguro


Los siguientes consejos le ayudarán a aumentar la seguridad cuando utilice OpenSSH. Tenga en cuenta que los cambios en el archivo de configuración de /etc/ssh/sshd_config OpenSSH requieren la recarga del demonio sshd para que surtan efecto:

# systemctl reload sshd
Importante

La mayoría de los cambios en la configuración del refuerzo de la seguridad reducen la compatibilidad con los clientes que no admiten algoritmos o conjuntos de cifrado actualizados.

Desactivación de los protocolos de conexión inseguros

  • Para que SSH sea realmente eficaz, hay que evitar el uso de protocolos de conexión inseguros que sean sustituidos por el conjunto OpenSSH. De lo contrario, la contraseña de un usuario podría estar protegida usando SSH para una sesión sólo para ser capturada más tarde cuando se conecte usando Telnet. Por esta razón, considere deshabilitar los protocolos inseguros, como telnet, rsh, rlogin y ftp.

Activación de la autenticación basada en clave y desactivación de la autenticación basada en contraseña

  • Desactivar las contraseñas para la autenticación y permitir sólo los pares de claves reduce la superficie de ataque y también podría ahorrar tiempo a los usuarios. En los clientes, genere pares de claves utilizando la herramienta ssh-keygen y utilice la utilidad ssh-copy-id para copiar las claves públicas de los clientes en el servidor OpenSSH. Para desactivar la autenticación basada en contraseña en su servidor OpenSSH, edite /etc/ssh/sshd_config y cambie la opción PasswordAuthentication por no:

    PasswordAuthentication no

Tipos de claves

  • Aunque el comando ssh-keygen genera un par de claves RSA por defecto, puedes indicarle que genere claves ECDSA o Ed25519 utilizando la opción -t. El ECDSA (Algoritmo de Firma Digital de Curva Elíptica) ofrece un mejor rendimiento que el RSA con una fuerza de clave simétrica equivalente. También genera claves más cortas. El algoritmo de clave pública Ed25519 es una implementación de curvas de Edwards retorcidas que es más segura y también más rápida que RSA, DSA y ECDSA.

    OpenSSH crea automáticamente las claves de host del servidor RSA, ECDSA y Ed25519 si no las tiene. Para configurar la creación de claves de host en RHEL 8, utilice el servicio instanciado sshd-keygen@.service. Por ejemplo, para desactivar la creación automática del tipo de clave RSA:

    # systemctl mask sshd-keygen@rsa.service
  • Para excluir determinados tipos de claves para las conexiones SSH, comente las líneas correspondientes en /etc/ssh/sshd_config y vuelva a cargar el servicio sshd. Por ejemplo, para permitir sólo las claves de host Ed25519:
# HostKey /etc/ssh/ssh_host_rsa_key
# HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Puerto no predeterminado

  • Por defecto, el demonio sshd escucha en el puerto TCP 22. Cambiar el puerto reduce la exposición del sistema a ataques basados en el escaneo automático de la red y, por tanto, aumenta la seguridad a través de la oscuridad. Puede especificar el puerto utilizando la directiva Port en el archivo de configuración /etc/ssh/sshd_config.

    También tienes que actualizar la política por defecto de SELinux para permitir el uso de un puerto no predeterminado. Para ello, utilice la herramienta semanage del paquete policycoreutils-python-utils:

    # semanage port -a -t ssh_port_t -p tcp port_number

    Además, actualice la configuración de firewalld:

    # firewall-cmd --add-port port_number/tcp
    # firewall-cmd --runtime-to-permanent

    En los comandos anteriores, sustituya port_number por el nuevo número de puerto especificado mediante la directiva Port.

No hay acceso a la raíz

  • Si su caso de uso particular no requiere la posibilidad de iniciar sesión como usuario root, debería considerar establecer la directiva de configuración PermitRootLogin a no en el archivo /etc/ssh/sshd_config. Al deshabilitar la posibilidad de iniciar sesión como usuario root, el administrador puede auditar qué usuarios ejecutan qué comandos privilegiados después de iniciar sesión como usuarios normales y luego obtener derechos de root.

    Como alternativa, configure PermitRootLogin en prohibit-password:

    PermitRootLogin prohibir-contraseña

    Esto refuerza el uso de la autenticación basada en claves en lugar del uso de contraseñas para iniciar la sesión como root y reduce los riesgos al evitar los ataques de fuerza bruta.

Uso de la extensión X Security

  • El servidor X en los clientes de Red Hat Enterprise Linux no proporciona la extensión X Security. Por lo tanto, los clientes no pueden solicitar otra capa de seguridad cuando se conectan a servidores SSH no confiables con el reenvío X11. La mayoría de las aplicaciones no pueden ejecutarse con esta extensión habilitada de todos modos.

    Por defecto, la opción ForwardX11Trusted en el archivo /etc/ssh/ssh_config.d/05-redhat.conf se establece en yes, y no hay diferencia entre el comando ssh -X remote_machine (host no confiable) y ssh -Y remote_machine (host confiable).

    Si su escenario no requiere la función de reenvío de X11 en absoluto, establezca la directiva X11Forwarding en el archivo de configuración /etc/ssh/sshd_config a no.

Restringir el acceso a usuarios, grupos o dominios específicos

  • Las directivas AllowUsers y AllowGroups en el archivo de configuración del servidor /etc/ssh/sshd_config le permiten permitir sólo a ciertos usuarios, dominios o grupos conectarse a su servidor OpenSSH. Puede combinar AllowUsers y AllowGroups para restringir el acceso con mayor precisión, por ejemplo:

    AllowUsers *@192.168.1.*,*@10.0.0.*,!*@192.168.1.2
    AllowGroups example-group

    Las líneas de configuración anteriores aceptan conexiones de todos los usuarios de los sistemas de las subredes 192.168.1.* y 10.0.0.*, excepto del sistema con la dirección 192.168.1.2. Todos los usuarios deben estar en el grupo example-group. El servidor OpenSSH rechaza todas las demás conexiones.

    Tenga en cuenta que el uso de listas de permitidos (directivas que empiezan por Allow) es más seguro que el uso de listas de bloqueados (opciones que empiezan por Deny) porque las listas de permitidos bloquean también a nuevos usuarios o grupos no autorizados.

Cambiar las políticas criptográficas de todo el sistema

  • OpenSSH utiliza las políticas criptográficas de todo el sistema RHEL, y el nivel de política criptográfica por defecto de todo el sistema ofrece una configuración segura para los modelos de amenazas actuales. Para que la configuración criptográfica sea más estricta, cambie el nivel de política actual:

    # update-crypto-policies --set FUTURE
    Setting system policy to FUTURE
  • Para optar por las políticas de criptografía de todo el sistema para su servidor OpenSSH, descomente la línea con la variable CRYPTO_POLICY= en el archivo /etc/sysconfig/sshd. Después de este cambio, los valores que especifique en las secciones Ciphers, MACs, KexAlgoritms, y GSSAPIKexAlgorithms en el archivo /etc/ssh/sshd_config no serán anulados. Tenga en cuenta que esta tarea requiere una gran experiencia en la configuración de opciones criptográficas.
  • Consulte Uso de políticas criptográficas en todo el sistema en el título de endurecimiento de la seguridad de RHEL 8 para obtener más información.

Recursos adicionales

  • sshd_config(5), ssh-keygen(1), crypto-policies(7), y update-crypto-policies(8) páginas de manual
Red Hat logoGithubRedditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

© 2024 Red Hat, Inc.