¿Cómo endurecer un servidor SSH?

119

¿Qué medidas puedo / debo tomar para asegurarme de que la seguridad alrededor de mi servidor SSH sea absolutamente impermeable?

Esta será la wiki de la comunidad desde el principio, así que veamos qué hacen las personas para proteger sus servidores.

    
pregunta LassePoulsen 30.01.2015 - 17:27

13 respuestas

21

Hacer que el sshd bloquee las IP del cliente que no han podido proporcionar la información de inicio de sesión correcta " DenyHØsts " puede hacer este trabajo de manera bastante efectiva. Tengo esto instalado en todos mis cuadros de Linux que de alguna manera son accesibles desde el exterior.

Esto asegurará que los ataques de fuerza en el SSHD no sean efectivos, pero recuerda (!) de esta manera puedes terminar bloqueándote si olvidas tu contraseña. Esto puede ser un problema en un servidor remoto al que no tiene acceso.

    
respondido por el LassePoulsen 10.06.2016 - 23:17
100

Utilice pares de claves públicas / privadas para la autenticación en lugar de contraseñas.

  1. Genere una clave SSH protegida por contraseña para cada computadora que necesite acceder al servidor:

    ssh-keygen

  2. Permitir el acceso SSH de clave pública desde las computadoras permitidas:

    Copie los contenidos de ~/.ssh/id_rsa.pub de cada computadora en líneas individuales de ~/.ssh/authorized_keys en el servidor, o ejecute ssh-copy-id [server IP address] en cada computadora a la que otorgue acceso (deberá ingresar la contraseña del servidor en el prompt).

  3. Deshabilitar contraseña Acceso SSH:

    Abra /etc/ssh/sshd_config , busque la línea que dice #PasswordAuthentication yes y cámbiela a PasswordAuthentication no . Reinicie el daemon del servidor SSH para aplicar el cambio ( sudo service ssh restart ).

Ahora, la única forma posible de SSH en el servidor es usar una clave que coincida con una línea en ~/.ssh/authorized_keys . Usando este método, I no se preocupan por los ataques de fuerza bruta porque incluso si adivinan mi contraseña, será rechazada. Brute forzar un par de claves pública / privada es imposible con la tecnología actual.

    
respondido por el Evan Kroske 08.06.2016 - 02:31
67

Sugeriría:

  • Utilizando fail2ban para evitar intentos de inicio de sesión de fuerza bruta.

  • Deshabilitar el inicio de sesión como root a través de SSH. Esto significa que un atacante tuvo que descubrir el nombre de usuario y la contraseña, dificultando el ataque.

    Agregue PermitRootLogin no a su /etc/ssh/sshd_config .

  • Limitar a los usuarios que pueden SSH al servidor. Ya sea por grupo o solo usuarios específicos.

    Agregue AllowGroups group1 group2 o AllowUsers user1 user2 para limitar quién puede enviar SSH al servidor.

respondido por el Mark Davidson 08.06.2016 - 02:07
22

Otras respuestas brindan seguridad, pero hay una cosa que puede hacer para que sus registros sean más silenciosos y para que sea menos probable que se bloquee su cuenta:

Mueva el servidor del puerto 22 a otro. Ya sea en su puerta de enlace o en el servidor.

No aumenta la seguridad, pero significa que todos los escáneres aleatorios de Internet no saturarán sus archivos de registro.

    
respondido por el Douglas Leeder 08.06.2016 - 02:15
21

Habilite la autenticación de dos factores con HOTP o TOTP . Esto está disponible a partir de las 13.10 en adelante.

Esto incluye el uso de autenticación de clave pública sobre autenticación de contraseña como en otra respuesta aquí, pero también requiere que el usuario demuestre que tiene su dispositivo de segundo factor además de su clave privada.

Resumen:

  1. sudo apt-get install libpam-google-authenticator

  2. Haga que cada usuario ejecute el comando google-authenticator , que genera ~/.google-authenticator y los ayuda a configurar sus dispositivos de dos factores (por ejemplo, la aplicación Google Authenticator para Android).

  3. Editar /etc/ssh/sshd_config y establecer:

    ChallengeResponseAuthentication yes
    PasswordAuthentication no
    AuthenticationMethods publickey,keyboard-interactive
    
  4. Ejecute sudo service ssh reload para recoger sus cambios en /etc/ssh/sshd_config .

  5. Editar /etc/pam.d/sshd y reemplazar la línea:

    @include common-auth
    

    con:

    auth required pam_google_authenticator.so
    

Más detalles sobre las diferentes opciones de configuración son mi publicación del blog del año pasado: Mejor autenticación ssh de dos factores en Ubuntu .

    
respondido por el Robie Basak 23.05.2017 - 00:29
19

Aquí hay una cosa fácil de hacer: instalar ufw (el "cortafuegos sin complicaciones") y usarlo para limitar las conexiones entrantes.

Desde el símbolo del sistema, escriba:

$ sudo ufw limit OpenSSH 

Si ufw no está instalado, hazlo y vuelve a intentarlo:

$ sudo aptitude install ufw 

Muchos atacantes intentarán usar su servidor SSH con contraseñas de fuerza bruta. Esto solo permitirá 6 conexiones cada 30 segundos desde la misma dirección IP.

    
respondido por el mpontillo 15.08.2010 - 00:45
12

Si quiero tener algo de seguridad adicional o necesito acceder a los servidores SSH en el interior de alguna red corporativa, configuro un oculto servicio mediante el uso del software de anonimización Tor .

  1. Instale Tor y configure el servidor SSH en sí.
  2. Asegúrese de que sshd solo escuche en localhost .
  3. Abrir /etc/tor/torrc . Establecer HiddenServiceDir /var/lib/tor/ssh y HiddenServicePort 22 127.0.0.1:22 .
  4. Mira var/lib/tor/ssh/hostname . Hay un nombre como d6frsudqtx123vxf.onion . Esta es la dirección del servicio oculto.
  5. Abra $HOME/.ssh/config y agregue algunas líneas:

    Host myhost
    HostName d6frsudqtx123vxf.onion
    ProxyCommand socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050
    

Además necesito Tor en mi host local. Si está instalado, puedo ingresar ssh myhost y SSH abre una conexión a través de Tor. El servidor SSH en el otro lado abre su puerto solo en localhost. Entonces nadie puede conectarlo a través de "Internet normal".

    
respondido por el qbi 08.06.2016 - 02:10
8

Hay un artículo de la Administración Debian sobre este tema. Cubre la configuración básica del servidor SSH y también las reglas del firewall. Esto también podría ser de interés para reforzar un servidor SSH.

Ver el artículo: Mantener el acceso SSH seguro .

    
respondido por el Huygens 12.10.2010 - 00:35
6

Mi enfoque para el endurecimiento de SSH es ... complejo. Los siguientes elementos están en términos de cómo lo hago, desde el borde más periférico de mi (s) red (es) hasta el servidor en sí.

  1. Filtrado de tráfico a nivel de frontera a través de IDS / IPS con escáneres de servicio conocidos y firmas en la lista de bloqueo. Logré esto con Snort a través de mi firewall de frontera (este es mi enfoque, un pfSense aparato). A veces, no puedo hacer esto, como con mis VPSes.

  2. Firewall / Filtrado de red de los puertos SSH. Dejo explícitamente que ciertos sistemas solo lleguen a mis servidores SSH. Esto se realiza a través de un firewall de pfSense en el límite de mi red o de los servidores de seguridad de cada servidor que se configuran explícitamente. Sin embargo, hay casos en los que no puedo hacer esto (que casi nunca es el caso, excepto en laboratorios privados de prueba de bolígrafo o pruebas de seguridad donde los firewalls no ayudan a probar cosas).

  3. Junto con mi pfSense, o un firewall de frontera NAT-ing la red interna y la separación de Internet y los sistemas, Acceso a servidores VPN-only . Tengo que hacer una VPN en mis redes para acceder a los servidores, porque no hay puertos con acceso a Internet como tales. Esto definitivamente no funciona para todos mis VPSes, pero junto con el # 2, puedo hacer que un VPS sea la 'puerta de enlace' mediante VPNing en ese servidor, y luego permitir su IP a los otros cuadros. De esa forma, sé exactamente qué puede o no puede hacer SSH, mi única casilla que es la VPN. (O, en mi red doméstica detrás de pfSense, mi conexión VPN, y soy el único con acceso VPN).

  4. Donde # 3 no es factible, fail2ban, configurado para bloquear después de 4 intentos fallidos y bloquear las direcciones IP durante una hora o más es una protección decente contra personas atacando constantemente con fuerza bruta, solo bloquear em en el firewall de forma automática con fail2ban y meh. La configuración de fail2ban es una pena ...

  5. Ofuscación de puerto al cambiar el puerto SSH. Sin embargo, esta NO es una buena idea sin medidas de seguridad adicionales - el mantra de " La seguridad a través de la oscuridad "ya ha sido refutada y cuestionada en muchos casos. Lo he hecho junto con IDS / IPS y el filtrado de red, pero aún es MUY pobre lo que hay que hacer solo.

  6. Autenticación OBLIGATORIA de dos factores, a través de Soluciones de autenticación de dos factores de Duo Security . Todos y cada uno de mis servidores SSH tiene configurado Duo, de modo que, incluso para entrar, suceden mensajes 2FA, y tengo que confirmar cada acceso. (Esta es la última función útil, porque incluso si alguien tiene mi frase de contraseña o se rompe, no pueden pasar los complementos de Duo PAM). Esta es una de las mayores protecciones en mis servidores SSH frente al acceso no autorizado: cada inicio de sesión de usuario DEBE vincularse con un usuario configurado en Duo, y como tengo un conjunto restrictivo, no se pueden registrar nuevos usuarios en el sistema.

Mis dos centavos para asegurar SSH. O, al menos, mis pensamientos sobre el enfoque.

    
respondido por el Thomas W. 10.06.2016 - 23:14
1

Es posible que desee consultar la aplicación FreeOTP de RedHat en lugar de usar Google Authenticator. A veces, al actualizar la aplicación, ¡te bloquean! ; -)

Si desea utilizar otros tokens de hardware como Yubikey o eToken PASS o NG, o si tiene muchos usuarios o muchos servidores, es posible que desee utilizar un backend de autenticación de dos factores de código abierto.

Últimamente escribí una información sobre esto .

    
respondido por el cornelinux 08.06.2016 - 02:12
0

Escribí un pequeño tutorial sobre cómo hacer esto recientemente. Básicamente, debe usar PKI y mi tutorial también muestra cómo usar la Autenticación de dos factores para una mayor seguridad. Incluso si no utiliza ninguna de esas cosas, también hay algunas cositas sobre cómo proteger el servidor mediante la eliminación de conjuntos de cifrado débiles y otros conceptos básicos. enlace

    
respondido por el 01000101 19.05.2015 - 15:52
0

Para una gran cantidad de usuarios / certificados, considere la integración de LDAP. Las grandes organizaciones usan LDAP como repositorio de credenciales de usuario y certificados almacenados en tarjetas o llaveros, ya sea que los certificados se utilicen para la autenticación o la firma de correos electrónicos. Los ejemplos incluyen openLDAP, openDJ, Active Directory, Oracle Universal Directory, IBM Directory Server, snareWorks ...

Las computadoras y los grupos también se pueden administrar en LDAP para administrar las credenciales centrales. De esta forma, los departamentos de ayuda pueden tener una ventanilla única para tratar con grandes poblaciones.

Aquí hay un enlace a la integración de centOS: enlace

    
respondido por el weller1 29.04.2016 - 15:50
0

También puede bloquear según el país de origen utilizando la base de datos geoIP.

Básicamente, si vives en los EE. UU., entonces no hay ninguna razón para que alguien en Rusia se conecte a tu SSH, por lo que se bloqueará automáticamente.

El script se puede encontrar aquí: enlace

También puede agregar comandos de iptables (lo hice para mis gotitas) para eliminar automáticamente todo el tráfico a / desde esas direcciones IP.

    
respondido por el Michael A Mike 10.08.2017 - 07:09

Lea otras preguntas en las etiquetas