SSH. Lo sabemos. Lo amamos. Debemos usarlo.
Lo guiaré a través de ocho pasos para ayudarlo mejor a proteger el servicio SSH en su red. Creo que todos apreciamos la importancia de SSH. Nos permite conectarnos hacia y desde dispositivos Linux, servidores Unix, dispositivos de red y, a veces, incluso cajas de Windows. No voy a tratar de venderle la frecuencia con la que se usa SSH o la importancia que tiene. Voy a proporcionar una lista de verificación sólida que puede usar para asegurarse de que los servicios SSH en su entorno estén bloqueados.
1. Copia de seguridad del archivo de configuración
Primero, haga una copia de seguridad del archivo de configuración antes de realizar cambios importantes. Este es un consejo común, pero es real. Es fácil, toma solo un momento y lo protege en caso de un error al editar el archivo. ¿Y quién no se ha equivocado en Vim?
# cp /etc/ssh/sshd_config ~/sshd_config_original Ves, eso no es tan malo.
Desafío:¿realiza copias de seguridad de los archivos de configuración antes de realizar modificaciones importantes?
2. Establecer un mensaje de banner
Es cierto que se trata tanto de requisitos legales como de cualquier otra cosa, pero nuevamente, esta configuración solo toma un momento. En realidad, también puede proporcionar información bastante buena en los mensajes de banner. Primero, escribiremos el mensaje de banner en el /etc/issue.net archivo usando Vim. Luego abriremos el sshd_config y dígale que use el contenido de issue.net como el estandarte.
# vim /etc/issue.net
Warning! Authorized use only.
This server is the property of MyCompanyName.com [ También te puede interesar: Automatización de contraseñas SSH en Linux con sshpass ]
Obviamente, querrá pensar en algo específico para su organización. Elimina cualquier información que ya esté en issue.net archivo.
Luego, dígale a SSH que use el mensaje de banner. Abra el sshd_config archivo en Vim y busque la línea que dice Banner . ¿Recuerda que puede usar el carácter de barra diagonal en el modo Comando de Vim para buscar palabras clave en un archivo, verdad? Por ejemplo, /banner
# vim /etc/ssh/sshd_config Busque la línea que dice # sin ruta de banner predeterminada y luego elimine el comentario de la siguiente línea (dice Banner ).
# no default banner path
Banner /etc/issue.net Guarda tus cambios en Vim con :wq y luego reinicie el servicio SSH:
# systemctl restart sshd Nota:No voy a recordarte que reinicies SSH a partir de este momento. Cada vez que realice un cambio en el archivo de configuración, debe reiniciar el servicio.
Desafío:¿el mensaje del banner es coherente en todos los dispositivos SSH de su red?
3. Evitar contraseñas vacías
Esto parece una obviedad, pero las contraseñas vacías son claramente una mala idea. Es posible que tenga otras utilidades, como Módulos de autenticación conectables (PAM), que regulan sus contraseñas regulares, pero también es una buena idea asegurarse de que SSH también aplique configuraciones de seguridad responsables.
Abra el /etc/ssh/sshd_config archivo en Vim y luego busque la línea que dice PermitEmptyPasswords . Descoméntelo y reemplace el sí valor con no .
PermitEmptyPasswords no Eso es todo.
4. Evite que el usuario raíz cruce la red a través de SSH
La idea aquí es bastante sencilla. Envíe credenciales de usuario estándar a través de la red en lugar de credenciales raíz. Una vez que haya establecido su conexión SSH usando una cuenta de usuario estándar, use su o sudo para elevar sus privilegios.
Abra el archivo de configuración de SSH y luego elimine los comentarios de PermitRootLogin. línea. Edite la configuración de sí a no .
PermitRootLogin no
Desafío:su organización ha adoptado sudo , ¿verdad?
5. Lista blanca de cuentas de usuario específicas
Si ya está impidiendo el uso de la cuenta de usuario raíz a través de SSH, ¿por qué no da un paso más e indica explícitamente qué usuarios pueden conectarse al servidor? Tal vez tenga una cuenta de administrador normal que no sea root que use o una que ya esté configurada con sudo privilegios.
En el archivo de configuración de SSH, agregue la siguiente línea (no está allí de manera predeterminada):
AllowUsers user1 Lo pondría cerca del PermitRootLogin no ajuste.
Por cierto, puedes filtrar con todas las siguientes configuraciones:Permitir usuarios , Denegar usuarios , Permitir grupos , Denegar grupos . Los escribí en ese orden a propósito, ese es el orden en el que se procesan. Puede descubrir más información en la página del manual para sshd_config .
Desafío:ten cuidado con quién está autorizado exactamente.
Nota:también puede limitar las conexiones a través de iptables.
6. No más puerto 22
Otro cambio común es configurar SSH para escuchar en un puerto diferente al estándar 22/tcp que todos hemos memorizado. Ya hay una entrada en el sshd_config archivo.
Puede comentar la configuración del puerto predeterminado y agregar otra línea, como he hecho a continuación:
#Run SSH on a non-standard port
#Port 22
Port 2222 Sospecho que muchas personas usan 2222 como el número de puerto de reemplazo, por lo que es posible que desee estandarizar algo un poco más exclusivo.
Debe recordar agregar el nuevo número de puerto no estándar a sus intentos de conexión SSH a partir de este momento. Por ejemplo:
# ssh -p 2222 [email protected] Desafío:¿tiene el mismo número de puerto no estándar configurado para todos sus destinos SSH? La consistencia te hará la vida mucho más fácil.
7. ¡Se acabó el tiempo!
El siguiente consejo trata sobre el tiempo de espera de las conexiones. El ClientAliveInterval gestiona las conexiones SSH inactivas. El servidor envía un mensaje al cliente y espera una respuesta. El ClientAliveInterval es el espacio de tiempo entre los mensajes. El ClientAliveCountMax define cuántas veces el servidor hará esto antes de decidir que el cliente ya no está allí. En ese momento, la conexión se interrumpe.
Aquí hay una configuración de ejemplo que verifica cada 60 segundos y lo hará tres veces:
ClientAliveInterval 60
ClientAliveCountMax 3 Edite estos valores a algo que tenga sentido para su entorno.
Nota:si está utilizando SSH para hacer un túnel para otras conexiones, es posible que deba asegurarse de que el intervalo sea lo suficientemente largo para admitir correctamente cualquier otra aplicación que lo esté utilizando.
Hay un ServerAliveInterval valor que también puede configurar en el lado del cliente. Esto permite a los clientes interrumpir las conexiones a servidores SSH que no responden.
8. Aquí está la clave
Una de las configuraciones de seguridad más comunes para SSH en estos días es la autenticación basada en claves. A lo largo de los años que he enseñado Linux, este método de autenticación se ha vuelto cada vez más común. De hecho, no intentaría un examen de administrador de Red Hat sin sentirme seguro en este proceso. Afortunadamente, no es difícil.
Hagamos una revisión rápida. La autenticación basada en claves utiliza criptografía asimétrica. Eso significa que hay dos claves, diferentes pero matemáticamente relacionadas entre sí. Uno es privado y nunca se envía a través de la red. El otro es público y puede transferirse a través de la red. Debido a que las claves están relacionadas, se pueden usar para confirmar identidades, identidades como los intentos de autenticación SSH.
Deberá generar el par de claves en la computadora del cliente SSH local y luego transferir la clave pública a través de la red al servidor SSH de destino. En otras palabras, las claves lo identificarán en su estación de trabajo de administración. Una vez que esta configuración esté en su lugar, ya no se le pedirá una contraseña cuando establezca una conexión SSH.
El proceso solo requiere unos pocos pasos.
Primero, genera el par de claves:
# ssh-keygen
Las claves se almacenan en su directorio de inicio en un directorio oculto llamado .ssh , y los nombres de clave predeterminados son id_rsa (clave privada) y id_rsa.pub (clave pública).
A continuación, envíe la clave pública del usuario1 a través de la red al servidor SSH de destino ubicado en 10.1.0.42:
# ssh-copy-id [email protected] Finalmente, prueba la conexión:
# ssh [email protected] Tenga en cuenta que no se le solicita una contraseña.
Dado que ahora ha adoptado la autenticación basada en claves, puede editar el sshd_config archivo para evitar cualquier inicio de sesión basado en contraseñas. Una vez que configure esta configuración, solo se aceptará la autenticación basada en claves.
Edite estas dos líneas en el archivo:
PasswordAuthentication no
PublicKeyAuthentication yes [ ¿Quiere obtener más información sobre seguridad? Consulte la lista de verificación de cumplimiento y seguridad de TI. ]
Resumir
He enumerado varias configuraciones SSH comunes pero efectivas para ayudarlo a proteger mejor su entorno. Recuerde, con la seguridad, es probable que ninguna configuración proteja sus dispositivos. El objetivo son las capas de seguridad, cuya combinación ayuda a mitigar las amenazas a la seguridad. Le sugiero enfáticamente que organice cuidadosamente sus claves si implementa la autenticación basada en claves. También podría considerar usar un /etc/ssh/sshd_config centralizado archivo para mantener configuraciones de seguridad consistentes en sus servidores SSH. No olvide reiniciar SSH cada vez que cambie el archivo de configuración.