Ocho formas de proteger el acceso SSH en su sistema

SSH. Lo sabemos. Nos gusta. Tenemos que 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 lo importante que es. Le proporcionaré una lista de verificación sólida que puede usar para asegurarse de que los servicios SSH de su entorno estén bloqueados.

Índice

1. Guarde el 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 simple, toma solo un momento y lo protege en caso de que se produzca un error al editar el archivo. ¿Y quién no se equivocó en Vim?

# cp /etc/ssh/sshd_config ~/sshd_config_original

Mira, no es tan malo.

Desafío: ¿siempre realiza una copia de seguridad de los archivos de configuración antes de realizar cambios importantes?

2. Defina un mensaje de banner

Por supuesto, estos son tanto requisitos legales como cualquier otra cosa, pero nuevamente, esta afinación solo toma un momento. También puede proporcionar información realmente buena en las publicaciones de banner. Primero, escribiremos el mensaje del 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 pancarta.

# vim /etc/issue.net
Warning! Authorized use only.
This server is the property of MyCompanyName.com

Obviamente, querrá pensar en algo específico para su organización. Elimine toda la información ya presente en el issue.net archivar.

Luego dígale a SSH que use el mensaje de banner. Abre el sshd_config archivo en Vim, y busque la línea que dice Bandera. ¿Recuerdas que puedes usar el carácter de barra en el modo Comando de Vim para buscar un archivo por palabra clave, verdad? Por ejemplo, /banner

# vim /etc/ssh/sshd_config

Encuentra la línea que dice # sin ruta de banner predeterminada, luego descomente la siguiente línea (dice Bandera).


# no default banner path
Banner /etc/issue.net

Guarde sus cambios en Vim con : wq luego reinicie el servicio SSH:

# systemctl restart sshd

Nota: No te recordaré que reinicies SSH a partir de este momento. Cada vez que modifique 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. Evite contraseñas vacías

Parece obvio, pero las contraseñas en blanco son claramente una mala idea. Puede tener otras utilidades, como módulos de autenticación conectables (PAM), que regulan sus contraseñas habituales, pero también es una buena idea asegurarse de que SSH también aplique configuraciones de seguridad responsables.

Abre el /etc/ssh/sshd_config archivo en Vim, luego busque la línea que dice contraseñas. Descoméntalo y reemplázalo. valor con No.

PermitEmptyPasswords no

Eso es.

4. Evite que el usuario root cruce la red a través de SSH

La idea aquí es bastante simple. Envíe las credenciales de usuario estándar a través de la red en lugar de las credenciales raíz. Una vez que haya establecido su conexión SSH usando una cuenta de usuario estándar, use su Donde sudo para elevar sus privilegios.

Abra el archivo de configuración de SSH, luego descomente el PermitRootLogin línea. Cambiar la configuración de en No.

PermitRootLogin no

Desafío: su organización ha adoptado sudo, ¿a la derecha?

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 dar un paso más e indicar explícitamente qué usuarios se están conectando al servidor? Tal vez tenga una cuenta de administrador normal que no sea root que use o una cuenta ya configurada con sudo privilegios

En el archivo de configuración de SSH, agregue la siguiente línea (no se incluye por defecto):

AllowUsers user1

yo lo pondria cerca del PermitRootLogin no ajuste.

Por cierto, puedes filtrar con todos los siguientes parámetros: Autorizar usuarios, Denegar usuarios, Permitir grupos, Denegar grupos. Los escribí en ese orden a propósito, ese es el orden en que se tratan. Puede encontrar más información en la página man de sshd_config.

Desafío: preste atención exactamente a quién está permitido.

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 archivar.

Puede comentar la configuración del puerto predeterminado y agregar otra línea, como hice a continuación:

#Run SSH on a non-standard port
#Port 22
Port 2222

Sospecho que mucha gente está usando 2222 como su 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 la conexión. el Intervalo de ClientAlive gestiona las conexiones SSH inactivas. El servidor envía un mensaje al cliente y espera una respuesta. el Intervalo de ClientAlive es la cantidad de tiempo entre mensajes. el ClientAliveCountMax define cuántas veces el servidor hará esto antes de decidir que el cliente ya no está allí. En este punto, la conexión se termina.

Aquí hay una configuración de muestra que verifica cada 60 segundos y lo hará tres veces:

ClientAliveInterval 60
ClientAliveCountMax 3

Cambia estos valores por algo que tenga sentido para tu entorno.

Nota: si usa SSH para tunelizar otras conexiones, es posible que deba asegurarse de que el intervalo sea lo suficientemente largo para admitir correctamente otras aplicaciones que lo usan.

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

La autenticación de clave es una de las configuraciones de seguridad más comunes para SSH en estos días. 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 el proceso. Afortunadamente, no es difícil.

Hagamos una revisión rápida. La autenticación de clave utiliza criptografía asimétrica. Esto quiere decir 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 se puede transferir a través de la red. Debido a que las claves están vinculadas, se pueden usar para confirmar identidades, como los intentos de autenticación SSH.

Deberá generar el par de claves en el ordenador 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 posición de administrador. Una vez realizada esta configuración, ya no se le solicitará una contraseña al establecer 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 con nombre .ssh, y los nombres de clave predeterminados son id_rsa (clave privada) y id_rsa.pub (Llave pública).

Luego, envíe la clave pública user1 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 de clave, puede cambiar la sshd_config archivo para evitar el inicio de sesión basado en contraseñas. Una vez configurado este parámetro, solo se aceptará la autenticación de claves.

Edite estas dos líneas en el archivo:

PasswordAuthentication no
PublicKeyAuthentication yes

Conclusión

He enumerado varias configuraciones SSH comunes pero efectivas para ayudarlo a proteger mejor su entorno. Recuerde que con la seguridad, no hay configuraciones que puedan proteger sus dispositivos. El objetivo es tener capas de seguridad, cuya combinación ayude a mitigar las amenazas de seguridad. Le sugiero encarecidamente que organice sus claves con cuidado si está implementando la autenticación de clave. También puede considerar usar un /etc/ssh/sshd_config archivo para mantener configuraciones de seguridad consistentes en sus servidores SSH. Recuerde reiniciar SSH cada vez que modifique el archivo de configuración.

Artículos de interés

Subir

Si continuas utilizando este sitio aceptas el uso de cookies. Más información