¿Cómo (más) garantizar la seguridad SSH?

Haz tantas mitigaciones como puedas.

Su objetivo es obligar a una amplia variedad de atacantes potenciales a gastar más esfuerzo, recursos, tiempo de computadora (y, por lo tanto, factura de electricidad) y, más especialmente, horas-persona "calificadas" (escasas o escasas y, por lo tanto, valiosas). Ninguna protección funciona contra todas las amenazas. No se puede proteger contra todas las amenazas mientras se permanece en Internet.

Sin embargo, una gran cantidad de amenazas (secuestros de secuencias de comandos y atacantes poco calificados o con pocos recursos) se pueden derrotar casi todo el tiempo si se cuenta con una defensa en profundidad:muchas capas de seguridad buena y sólida, cada una de las cuales, en teoría, debería ser suficiente para vencer muchas amenazas por su cuenta. Por lo tanto, cuando las reglas de iptables de su sistema dejan entrar a alguien por accidente, la autenticación del certificado SSHD los mantiene fuera. Cuando su servicio SSHD tiene una falla, su VPN evita que nadie lo vea. Cuando tanto su VPN como su SSHD tienen una falla al mismo tiempo, las reglas de su firewall evitan que la mayoría de las direcciones IP del mundo lo intenten, dejando solo a los locales y grandes redes de bots para que puedan intentar explotar las vulnerabilidades, que parchea como lo antes posible.

Por lo tanto, repito, pongan tantas mitigaciones en tantos niveles como sea posible. No puede saber de antemano cuáles tienen vulnerabilidades no descubiertas y en qué orden serán explotadas.

• Asegúrese de permitir solo SSH v2

  • sshd_config

    • Protocolo 2

• Manténgase parcheado

• Use sus iptables para permitir SOLO las direcciones IP o los rangos que realmente usa

• Configure su SSH para permitir el acceso SOLAMENTE por certificado, no por nombre de usuario/contraseña, según el sitio de ayuda de Ubuntu SSH/OpenSSH/página de configuración

  • sshd_config

    • PubkeyAuthentication sí

    • ContraseñaAutenticación no

  • Si usa un directorio de inicio encriptado

    • Archivo de claves autorizadas /etc/ssh/%u/authorized_keys

  • Si no, la configuración normal para los directorios de inicio puede funcionar

    • AuthorizedKeysFile %h/.ssh/authorized_keys

    • Asegúrese de que no haya permisos excesivos.

      • chmod 700 ~/.ssh

      • chmod 600 ~/.ssh/autorizadas_claves

      • chmod ir-w ~

  • Y configure un certificado tan sólido como pueda. La generación de claves está cubierta en la página SSH/OpenSSH/Keys del sitio de ayuda de Ubuntu

    • Comenzaría con una clave RSA de 4096 bits o una clave ed25519 con una frase de contraseña larga y segura. Asegúrese de generarlo localmente, escriba una frase de contraseña larga y segura cuando se le solicite, use -o para garantizar el nuevo formato de clave OpenSSH 6.5 y asegúrese de que el servidor nunca tenga nada más que la clave pública.

      • ssh-keygen -o -t ed25519 -f ~/.ssh/id_ed25519

      • ssh-keygen -o -b 4096 -t rsa -f ~/.ssh/id_rsa

      • Para verificar la longitud de una clave existente, use ssh-keygen -e -f mykeyfile

  • Si puede, restrinja las claves en el archivo authorized_keys a una dirección IP específica o un conjunto de nombres de host

    • from="192.168.1.2" ssh-rsa ABCDE...012 [email protected]

    • from="*.test.test,!BadPC.test.test" ssh-ed25519ABCDE...012 [email protected]

  • Si tiene OpenSSH 6.8 o superior, también puede restringir las claves autorizadas a ciertos tipos en sshd_config

    • PubkeyAcceptedKeyTypes ssh-ed25519*,ssh-rsa*

• Use fail2ban para hacer que los intentos de fuerza bruta requieran más esfuerzo (es decir, haga que usen una botnet en lugar de una sola máquina, o que tomen mucho tiempo)

  • Configurar certificados (claves) es mejor si pregunta cuál hacer primero

• Reduzca su tiempo de gracia de inicio de sesión

  • Si está usando certificados, tiene la opción de reducirlo MUCHO a menos que use conexiones muy, muy lentas

    • Iniciar sesiónGraceTime 8

  • De lo contrario, bueno, ¿qué tan rápido escribes?

    • Iniciar sesiónGraceTime 20

• Controle sus opciones de conjunto de cifrado con información de Mozilla.org Security/Guidelines/OpenSSH

  • Dado que es su servidor, y solo usted está ingresando, puede seleccionar una agrupación muy, muy estrecha, de modo que solo se permitan los clientes más modernos. Quizás

  • HostKey /etc/ssh/ssh_host_rsa_key

    • sudo ssh-keygen -o -N '' -b 4096 -t rsa -f /etc/ssh/ssh_host_rsa_key

      • o

      • HostKey /etc/ssh/ssh_host_ed25519_key

      • sudo ssh-keygen -o -N '' -t ed25519 -f /etc/ssh/ssh_host_ed25519_key

    • ¡Obviamente, haga coincidir exactamente los nombres de archivo de su HostKey!

      • o ambos (el más preferido primero)

      • elimine todas las claves dsa por completo; están fijados en unos patéticos 1024 bits para SSH

  • Use las directivas ssh -Q para determinar qué admite su sistema para las opciones del conjunto de cifrado

  • KexAlgorithms [email protected]

  • Cifrados [email protected],[email protected],[email protected]

  • Ejemplo de [email protected]

  • O cualquier elección específica que te haga sentir más seguro

  • Y mantenerse al día con la literatura; cuando haya una falla en algo que hayas elegido, elige algo que no tenga fallas conocidas en ese momento.

• Use sus iptables (o firewall) con listas de bloqueo de I-blocklist

• Use sus iptables (o firewall) con listas de IP geográficas o basadas en ISP; una de esas fuentes de listas geográficas es maxmind.com

• Cambie a un puerto en el rango de puerto dinámico (efímero) de 49152 a 65535 por RFC6335

  • Y solo enlace a las direcciones IP requeridas

• Bloquee todos los demás puertos en ese servidor a través de iptables; lo más probable es que estés siendo golpeado por MUCHOS ataques

  • Especialmente endurezca su base de datos MySQL, si la hay. Veo MUCHOS ataques de MySQL (y SQL Server) en mi IDS, y nunca he ejecutado ninguno ni he tenido ninguno de los dos puertos abiertos. Configúrelos en direcciones IP locales no enrutables, etc., contraseñas largas, deshabilítelos, etc.

  • Deshabilite especialmente cualquier servidor web, configúrelo solo como IP local no enrutable, etc.

• Utilice la activación de puertos según el sitio de ayuda de Ubuntu o un artículo de DigitalOcean

• Límite de tasa de nuevos intentos de conexión, según esta respuesta a la pregunta de ServerFault "Cientos de inicios de sesión ssh fallidos"

iptables -A INPUT -p tcp --dport 22 -m reciente --actualización --segundos 60 --hitcount 5 --name SSH --rsource -j DROP

iptables -A INPUT -p tcp --dport 22 -m reciente --set --name SSH --rsource -j ACEPTAR

• Considere usar chroot según la documentación de Debian "OpenSSH SFTP chroot() con ChrootDirectory"

• Asegúrese de que rhosts esté deshabilitado con la opción sshd_config

  • IgnorarRhosts sí

  • RhostsRSAAuthentication no

  • RhostsAutenticación no

• Agregar más restricciones al proceso sin privilegios de autenticación previa

  • Zona de pruebas UsePrivilegeSeparation

• Si no está utilizando reenvío o tunelización, desactívelo en sshd_config

  • X11Reenvío no

  • AllowTcpForwarding no

  • GatewayPorts no

  • PermitTunnel no

• Evite otras configuraciones inseguras en directorios o permisos

  • Modos estrictos sí

  • Y luego revise sus permisos y configuraciones hasta que vuelva a funcionar :)

• Deshabilitar autenticación basada en host

  • Autenticación basada en host no

• Tenga en cuenta que según la respuesta de This Serverfault a "OpenSSH daemon ignora la directiva ServerKeyBits", la antigua directiva ServerKeyBits sshd_config ya no es aplicable, ya que no permite SSH v1 en primer lugar.

• No permitir root en sshd_config

  • PermitRootLogin no

• No permita que diferentes usuarios, tal vez usuarios de servicio en algún paquete que instale, tengan otras opciones

  • PermitUserEnvironment no

• Instale un cortafuegos completo separado como pfSense o un Ubiquiti Edgerouter Lite entre esa máquina y el mundo exterior.

  • Y luego use la VPN integrada ADEMÁS DE su inicio de sesión SSH reforzado

  • También con inicios de sesión basados ​​en certificados, no inicios de sesión basados ​​en nombre de usuario/contraseña

  • Si usa OpenVPN

    • Asegúrese de usar también una clave precompartida --tls-auth "ta.key"

    • Y elige mejores cifrados que los predeterminados

  • Y use las listas de bloqueo mencionadas anteriormente en este nivel también

Como mencionó DeerHunter, cambiar ssh y/o iptables y/u otras configuraciones de firewall sin ninguna otra forma puede resultar en una falta de capacidad para SSH.

Aquí tienes:

• Genera claves SSH + protégelas con contraseña
• Permitir que solo un usuario específico inicie sesión (AllowUsers)
• Permitir desde una IP específica [email protected]
• Cambiar puerto predeterminado
• Crear reglas de cortafuegos
• y lo último es instalar fail2ban.