SSH, o Secure SHell, reemplazó a Telnet en algún momento de la década de 1990 como el protocolo de acceso remoto elegido, y por una buena razón. SSH permite a los administradores, o usuarios, acceder a un shell remoto a través de un túnel seguro, conectando su cliente SSH a un servidor SSH. SSH también puede manejar transferencias de archivos, lo que debería reemplazar a FTP, aunque hay una cantidad sorprendente de situaciones que aún dependen del antiguo y buen FTP de texto claro.
¿Por qué? Uf.
Por las razones anteriores, los sistemas Linux modernos se administran a través de SSH. A los administradores de sistemas más experimentados les encanta el acceso directo y la potencia que obtienen al conectarse de forma segura al shell de su sistema con relativa facilidad. En este artículo, hablaré específicamente sobre el demonio del servidor OpenSSH, sshd . Cubriremos algunos de los problemas de seguridad con los que puede encontrarse y cómo mitigarlos, o resolverlos por completo.
Por qué necesitamos SSH
Como mencioné, SSH es una herramienta poderosa. A través de una sesión SSH, puede conectar un terminal virtual directamente a su sistema de destino. En las manos equivocadas, esta habilidad puede ser problemática, entonces, ¿por qué dejamos ese poder accesible? Bueno, el poder de SSH implica un delicado equilibrio. En cuestión de minutos, un administrador puede tener una sesión segura abierta en su servidor para responder a un incidente. La sencillez es elegante.
SSH también está en el centro de las herramientas de automatización como Ansible. Ansible puede aplicar cambios a un sistema a través de SSH sin necesidad de un agente. Todos los cambios se realizan, en cambio, utilizando SSH y Python.
SSH también se puede usar, como mencioné, para transferencias seguras de archivos. Por ejemplo, rsync túneles a través de SSH para la sincronización segura de datos. SSH también se puede usar para hacer un túnel a través de un sistema para llegar a otro, lo cual es excelente para solucionar problemas, pero también para un atacante.
Si los párrafos anteriores no lo han convencido, lo diré nuevamente:SSH es una herramienta poderosa y, como cualquier herramienta poderosa, se puede abusar de ella. Si un atacante puede obtener un shell seguro en su sistema, se acabó el juego. Y los atacantes lo saben, por lo que buscan constantemente sistemas con SSH abiertos al mundo para poder atacar.
Bloquear SSH
El ataque más común contra SSH es la fuerza bruta. En mis sistemas, personalmente nunca he tenido éxito en un ataque de fuerza bruta contra SSH. Sin embargo, antes de que comenzara a seguir reglas simples de bloqueo, puedo decirles que ciertamente lo intentaron.
Una búsqueda rápida en Shodan, un motor de búsqueda que apunta a dispositivos conectados a Internet, muestra 20,984,090 sistemas con SSH abiertos al mundo. ¿Es necesario configurarlos de esta manera? Casi puedo garantizarte que todos y cada uno de esos sistemas reciben varios ataques de fuerza bruta SSH por segundo. Mientras escribía este artículo, comencé un droplet en Digital Ocean, dejé SSH abierto al mundo y seguí /var/log/secure . En unos 20 minutos, vi la primera sonda SSH. En una hora, comenzó la avalancha de ataques de fuerza bruta.
Jun 23 01:35:33 centos-s-1vcpu-1gb-sgp1-01 sshd[10926]: Did not
receive identification string from 81.22.45.137 port 61000
Jun 23 01:37:47 centos-s-1vcpu-1gb-sgp1-01 sshd[10928]: Invalid
user fake from 104.248.132.25 port 36050
Jun 23 01:37:47 centos-s-1vcpu-1gb-sgp1-01 sshd[10928]:
input_userauth_request: invalid user fake [preauth]
Jun 23 01:37:47 centos-s-1vcpu-1gb-sgp1-01 sshd[10928]: Received
disconnect from 104.248.132.25 port 36050:11: Bye Bye [preauth]
En resumen, una contraseña incorrecta en un sshd predeterminado la instalación podría ser todo lo que se interponga entre los malos y su sistema. Si bien la configuración predeterminada para OpenSSH es decentemente segura, puede soportar que se endurezca. Por suerte para ti, tengo sugerencias.
Restringir el acceso al puerto 22
Comience por verificar si el puerto SSH predeterminado (puerto 22) está abierto al mundo. Puede hacer esto ejecutando Nmap, que sondeará su red de acuerdo con sus especificaciones:
Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-22 20:56 EDT
Nmap scan report for 167.71.200.117
Host is up (0.26s latency).
Not shown: 995 closed ports
PORT STATE SERVICE
22/tcp open ssh Limitar quién puede acceder al puerto 22 es lo más básico que puede hacer para proteger su sistema. Me doy cuenta de que esta táctica puede no funcionar para todos los escenarios. Tal vez esté ejecutando un sistema de uso público, o tal vez el CIO viaja mucho y puede acceder a los sistemas desde muchos lugares diferentes (hablaremos sobre las VPN en un momento). Mi punto es que usted puede tener una razón válida por la que SSH absolutamente necesita estar abierto al público en general. Piensa muy Sin embargo, es difícil evitar esa configuración. Lo he hecho, pero sobre todo por pereza. Por lo general, hay una mejor manera.
Si está utilizando un proveedor de nube, configure un grupo de seguridad para que solo acepte tráfico SSH de la red desde la que está trabajando. Esta tarea debería ser simple si accede a este proveedor desde un entorno empresarial. Probablemente tenga su propio rango de direcciones IP, lo que significa que puede incluirlo en la lista blanca y bloquear todo lo demás. Sin embargo, si está accediendo al proveedor de la nube desde su hogar, es posible que deba realizar algunos trucos para incluir en la lista blanca el bloque de IP asignado dinámicamente de su ISP. El uso de un grupo de seguridad debería permitirle cambiar el rango de direcciones IP a través del portal de autoservicio de su proveedor de nube si es necesario.
Si está alojando un sistema que no está detrás de un firewall, use el firewall basado en host para bloquear el puerto 22 desde cualquier lugar que no sea su rango de direcciones IP, usando los mismos métodos que acabo de describir. El problema allí, por supuesto, es que si está bloqueado porque su dirección IP cambió, tendrá más dificultades para realizar los cambios necesarios.
Y no olvide que hay beneficios para un entorno empresarial. Si su servidor está en una red empresarial, es muy probable que haya un firewall de red que pueda usar para bloquear el acceso SSH, así que aproveche ese hecho. Defensa en profundidad amigos, ¡es una cosa!
Requerir una VPN para acceso remoto
Bien, hablemos de ese CIO itinerante que absolutamente necesita acceso a ssh desde una habitación de hotel. La solución parece obvia para aquellos de nosotros que hemos estado alrededor del bloque, pero si está considerando abrir el acceso SSH a todo el mundo, tal vez necesite escuchar esto:una VPN, o red privada virtual, le permite construir un túnel encriptado desde un punto final, como la computadora portátil de su CIO en ese hotel en Maui, de regreso a su red empresarial en Seattle. Esta conexión está protegida a su manera y encriptada.
Sin embargo, sus docenas de servidores que no son accesibles para el mundo podrían volverse accesibles a través de este único punto. Sí, esta práctica cambia el objetivo del ataque a la VPN, pero eso significa que hay un obstáculo más para que los malos lo superen.
Denegar acceso raíz
Ahora estamos llegando al sshd real. configuración. El demonio OpenSSH tiene una opción llamada PermitRootLogin . De forma predeterminada, esta opción está establecida en Yes , ya que cuando instalas algunos sistemas, solo existe root al principio. Cuando ocurre esta situación, necesita la cuenta raíz para acceder al sistema y realizar la configuración inicial.
Recomiendo agregar un usuario durante el proceso de instalación, o como parte de su imagen dorada, y desactivar los inicios de sesión de raíz desde el primer momento. No hay ninguna razón para iniciar sesión como root y, ciertamente, no hay ninguna razón para iniciar sesión como root a través de SSH. Entonces, cambia la línea de configuración a:
PermitRootLogin no Implementar la autenticación basada en claves
Inicialmente, usé la autenticación basada en claves por conveniencia. Generé una clave privada, agregué la clave pública a mis authorized_keys archivo en los servidores que administré, y luego pude conectarme de manera segura a mis sistemas sin una contraseña. Hacer esto ahorró tiempo e hizo posible la automatización. ¡GANAR! No fue hasta más tarde que descubrí que la autenticación basada en clave SSH se puede aprovechar para eliminar los intentos de fuerza bruta de contraseña.
Para generar una clave, ejecute ssh-keygen en una caja Mac o Linux. Tal vez ustedes, la gente de Windows, puedan hacer esto de forma nativa ahora, pero en las máquinas con Windows, siempre he usado PuTTYGen (y luego usé la clave con el cliente PuTTY). Se le pedirá un tipo de clave y una longitud. Últimamente he estado creando claves RSA de 4096 bits. Cuantos más bits, más difícil es descifrar la clave. Entonces, ¿por qué no?
[gangrif@meliodas ~]$ ssh-keygen -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/gangrif/.ssh/id_rsa): ./test-key
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in ./test-key.
Your public key has been saved in ./test-key.pub.
The key fingerprint is:
SHA256:xfHOf4t3V3CCkJ+3FbEnQusAjBwOjBXfOa9WdGXBMqc [email protected]
The key's randomart image is:
+---[RSA 4096]----+
| ++o.+. ....+o.|
| . .+o..+o+o+o..|
| o + =o=B..o|
| = *E.+.+|
| S o +. * |
| o .. .|
| o . o|
| . .o+|
| ...o|
+----[SHA256]-----+
Lo que luego termina es un nuevo archivo llamado test-key (en este caso) y test-key.pub . La clave en test-key es mi clave privada y test-key.pub contiene la clave pública. Protege la clave privada con tu vida. Sin embargo, puedes dejar la clave pública donde quieras, ya que es inútil sin la clave privada.
[gangrif@meliodas ~]$ cat test-key.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDAQxmjoHO6i4Kkq8vp49KtqAsMcw+ptgvd+PGjxVYkDPGdzRZpJhq0c3BDstFs86ENlojs61zZaP3MihLR0BlDdIyM3jh9TmVvmOPiylhu4X9QliAca/ODxyVp76OpTKm+QcgBi/7i/JNiJdEgcSy8izB0Oil7LZjIhS6wCs3mQFVbkPXPfe1lmHQIcuMDOKO0RuyecY/lrKodcr/YbEE4GsM/P11QdDPZ78lq83G3H5vqLqMrxVKkLw7Z4//+PZPFFxi/N1EBwBp/uPEo4MfD1IwSmnKromRlkYTdOYlbiCNosdvEobtMARySdqjv7RDn0Iwb3JxioUW6jQdAXfl8d01LvX/0Yb1tq5hF44ahwvI6TyoB4z3DRs+3cFiMPWQR7LK8/qQOvHk5I2NMBAV9KuSN2ML0d7xeB8tglw38PYjhZsXl/t2rAWT4n8PU0o6+Hrrli+WEfvk8QWpLesmBBmzG0sLjH0mXBU/xN4UBLLJNlrsUQ/TzEsdknntMhh7leOzechlU3PiTNuUitweT9NqLJwCP+CHbeSJn2M5qzb090CPnCGpnr2GOfm2dL+RfHQi2R1Cf04nBDq3WuhAPJY5SoEw2llfSgA2GlOdhcY9N9Bl9rLUBPgQ6ttBd7qZJ6E3BkiPlHnU+kSSpYr8Gkw1oDGbtd2UUjExZqvz4rQ== [email protected]
En las máquinas a las que desea conectarse sin usar una contraseña, copie la clave pública en .ssh/authorized_keys (o hacer que el usuario lo haga, dependiendo de la situación). Ahora, digo sin contraseña, pero aún necesita desbloquear la clave privada con la contraseña que estableció durante la generación. Estableciste una contraseña, ¿verdad?
También puede copiar esta clave de forma remota a un servidor usando ssh-copy-id .
Deshabilitar la autenticación basada en contraseña
¿Recuerdas cuando dije que la autenticación basada en claves te abre la posibilidad de bloquear completamente los intentos de fuerza bruta de SSH? Bueno, así es como. Con sus claves privadas y públicas en su lugar, SSH ya no le solicita una contraseña, ¿verdad? Entonces, ¿por qué dejar abierta esa vía como vector de ataque?
En cada servidor Linux que ejecuto, agrego mi clave pública como parte de nuestra instalación básica y desactivo la autenticación de contraseña SSH incluso antes de que el sistema llegue a la red. Esta es una configuración en sshd archivo de configuración de . Nuevamente, la configuración predeterminada permite la autenticación de contraseña, porque esa función tiene que funcionar para la configuración. Sin embargo, una vez que tenga las llaves en su lugar, apáguelas.
PasswordAuthentication no Felicitaciones, ahora es inmune a los ataques de fuerza bruta de contraseñas.
Cárcel de usuario SSH, con chroot
El chroot El comando, generalmente pronunciado como "chi-root" o "ch-root", es una herramienta ordenada. Le permite cambiar el directorio raíz visto por un proceso y sus hijos, de ahí el nombre. Es excelente para solucionar problemas de un sistema en el que puede acceder al disco, pero no arranca. Simplemente monte su disco y haga chroot en /mnt/lo que sea.
Esta es también una buena herramienta de seguridad para algo así como un servidor shell. Puede chrootear a un usuario al iniciar sesión, por lo que literalmente no puede ver el resto del sistema de archivos. No hago esto a menudo, pero es una cárcel muy viable para los usuarios. Encontré lo que parece ser un artículo decente aquí.
Rotación
Vale la pena considerar la rotación de contraseñas y claves ssh. Intentaré resumir lo bueno y lo malo aquí.
Política y rotación de contraseñas
Agruparé la política de contraseñas con la rotación de contraseñas porque están relacionadas. Las políticas de contraseñas que imponen la complejidad son una excelente manera de hacer que sus usuarios elijan una contraseña "fuerte". Sin embargo, esto tiene algunas advertencias, especialmente cuando se combina con el vencimiento arbitrario (es decir, cronometrado) de la contraseña. Podría escribir un artículo completo sobre cómo me siento acerca de la política de contraseñas y la rotación, pero trataré de ser breve aquí.
El año pasado, NIST hizo algo así como un cambio radical en sus pautas de contraseña, cambiando algunas de sus sugerencias que habían estado arraigadas en la mayoría de nuestras mentes durante la mayor parte de nuestras carreras. La comunidad de Infosec (en la que incursiono) ha estado sugiriendo durante años, contraseñas aleatorias de 8 caracteres, o una longitud mínima de 8 caracteres con reglas estrictas de complejidad, estaban haciendo más para la higiene de contraseñas de HARM que para ayudarla. Combine reglas estrictas de complejidad con una política de rotación de contraseñas de 3 a 6 meses, y está configurando a sus usuarios para la frustración. Esa frustración conduce a la reutilización de contraseñas y otros malos hábitos. Así que piensa bien si quieres imponer esto a tus usuarios. Las nuevas recomendaciones se inclinan hacia la caducidad solo cuando se sospecha una infracción o un compromiso, y una política que lleva a los usuarios a utilizar frases de paso seguras en lugar de contraseñas. "Este es mi p@ssw0rd 2019". es mucho más difícil de adivinar y descifrar que "W1nt3r2019". Lo cual, por cierto, es un recurso común tanto para quienes establecen contraseñas como para los miembros del equipo rojo. Sin embargo, tenga en cuenta que si les pide a los administradores inteligentes que cambien sus contraseñas, es posible que no tenga este problema (porque entienden POR QUÉ lo están haciendo y cuán importante es). Pero para sus usuarios en general, la caducidad arbitraria y las "contraseñas" complejas se están convirtiendo en algo del pasado.
Rotación de clave privada SSH
Como cualquier identificador que se pueda generar, sería bueno considerar rotar su clave privada periódicamente. Su clave privada no es tan fácil de robar o adivinar como podría ser una contraseña, pero es posible que alguien haya robado su clave sin su conocimiento. Esto entra en el territorio de "cuán paranoico te gustaría ser". Sin embargo, cambiar la contraseña de su clave privada no es suficiente. Esa contraseña desbloquea esa clave, si deslizo su clave hoy y usted cambia su contraseña mañana, la copia si su clave que tengo todavía tiene su contraseña anterior. Si va a hacer esto bien, necesita generar una clave completamente nueva. Ahora es un buen momento para aumentar la longitud de la clave si el estándar ha subido desde la última vez que generó una clave. Tal vez genere una nueva clave cada vez que su empleador le entregue una computadora portátil nueva, tal vez lo haga una vez al año en su aniversario de trabajo. Sin embargo, no he encontrado una solución que se encargue de esto.
Tenga en cuenta que generar una nueva clave significa que todas las claves públicas que tiene en el mundo ya no son válidas. O al menos no son válidos con tu nueva clave. Es probable que deba usar su clave anterior para colocar su nueva clave pública.
MFA
La autenticación multifactor se está convirtiendo en la norma. Algunas personas han tratado de afirmar que las claves SSH son una forma de MFA, pero no lo son. Especialmente si ha deshabilitado la autenticación de contraseña. Sin embargo, puede integrar mfa como TOTP o YubiKey en la configuración PAM de su sistema. Las soluciones de autenticación central como FreeIPA facilitan esta tarea.
Conclusión
Ahí lo tiene, espero que tome esta información y la aplique a sus sistemas para mejorar su seguridad. No seas uno de esos 21 millones de sistemas con SSH abiertos al mundo. Simplemente no hay razón para ello.
¡Gracias por leer!
Este artículo se publicó originalmente en Undrground.org. Republicado con permiso.