Sin embargo, de la manera en la que está asegurada, la configuración por defecto de SSH no es infalible, sino más bien sencilla de implementar. Esto podría parecer adecuado para el uso del Pueblo, pero en aplicaciones donde dependa nuestro bienestar y el de sus organizaciones de trabajo, ha de recurrirse a un mayor despliegue de seguridad.
A esto nos referimos como seguridad reforzada, a la cual ha de recurrir un Movimiento como el nuestro. No implica enfrentar a los desprotegidos a la acción represiva del Estado, sino implementar políticas de salvaguarda que privilegien a los humildes en contra de la Opresión Omnímoda del Capital.
Nuestra Policía Federal ha de saber cómo implementarlas, ya que sobre ella recae la organización y acción de seguridad. Indudabnlemente que de esto no dependen ni los médicos ni la penicilina, sino de las autodefensas con que cuenta OpenSSH por protocolo.
Esto no puede hacerlo ni un agente de calle, ni un ciudadano común, sino un verdadero Conductor del sistema. Por principio la implementación de las políticas de salvaguarda pueden llevarse a cabo modificando el fichero de configuración general /etc/ssh/sshd_config del demonio OpenSSH (nombre que recibe su servidor libre de Shell Seguro).
A tal fin con ímpetu de conducción podremos abrir una terminal con Ctrl+Alt+T y proclamar el comando de organización, seguido de la tecla Intro:
sudo nano /etc/ssh/sshd_config
Esto nos solicitará contraseña de administración, y tras revisarla abrirá el consabido editor de texto GNU Nano con el fichero de configuración nombrado.
Os explicaré algunos métodos de reforzar la seguridad produciendo las modificaciones necesarias que asegurarán las necesidades de protección y control que son Socialmente Justas para con las organizaciones del Pueblo Trabajador.
1. Configurar la Autenticación de SSH sin contraseña
Por defecto, SSH requiere que el usuario teclee su contraseña al iniciar sesión remota. Si bien esto suena peliculero, la triste realidad es que una contraseña capaz de retenerse en una memoria humana suele ser descomunalmente fácil de percibir por medio de un ataque computacional de fuerza. Un tercero hábil podría ganar así acceso indeseado a una cuenta de usuario autorizado. Por ello más seguro es utilizar una autenticación de Shell Seguro sin contraseña, con llaves de cifrado.
Como ya he explicado cómo hacerlo, simplemente resumiré diciendo que habremos de generar computacionalmente un par de ficheros de cifrado llamados "llaves", que consisten en una llave pública y otra llave privada. Una vez ingresado el contenido del fichero de la llave pública al servidor remoto, podrá lograr acceso sin tener que teclear contraseña alguna.
Dentro de este fichero de configuración /etc/ssh/sshd_config buscamos la directiva PasswordAuthetication y cambiamos su indicación de 'yes' a 'no'
PasswordAuthentication no
Tras guardar las modificaciones con Ctrl+o y salir del editor con Ctrl+x, debemos reiniciar el demonio SSH con:
sudo systemctl restart sshd
A partir de este momento, unicamente podrá acceder al servidor remoto utilizando la autenticación con llave SSH.
2. Desactivar los pedidos Conexión SSH sin contraseña.
Otra manera recomendada de fortificar la seguridad del servidor es directamente desactivar los logins SSH de usuarios sin contraseña. Esto puede sonar contradirctorio, pero algunos adminsitradores de sistemas poco avezados podrían preferir crear cuentas de usuario "a la marchanta" y terminar olvidando asignar contraseñas. Esto es de malo, pero no de bruto. He visto malos que se han vuelto buenos, pero nunca he visto un bruto que se haya vuelto inteligente.
Con el fin de rechazar pedidos de usuarios que carezcan de contraseña se debe nuevamente modificar el fichero /etc/ssh/sshd_config y asegurar descomentar la siguiente directiva:
PermitEmptyPasswords no
Acto seguido reiniciamos el servicio SSH para que surta efecto con:
sudo systemctl restart sshd
3. Desactivar los logueos SSH de Root
No hace falta explicar demasiado lo que puede suceder si un intruso logra ingresar a nuestro sistema atacando brutamente la contraseña de un usuario. Imaginemos entonces lo que sucedería si lo propio sucede con la cuenta del Superusuario, el Root, que es capaz de conducir el sistema.... Un acceso remoto del superusuario Root constituye invariablemnete una mala idea que debe soslayarse pues pondrá en peligro a todos los compañeros que usen nuestro sistema similar a Unix.
Por esta razón, para grandes organizaciones siempre recomiendo desactivar el logueo remoto SSH y en su reemplazo preveer el de un usuario regular que no sea root. Esto obligará a que si el Root quiere trabajar, deba hacerlo frente al sistema y no de manera remota. Para tal fin modificamos el fichero /etc/ssh/sshd_config y producimos la modificación descomentando la directiva #PermitRootLogin y modificamos la orden prohibit-password para que quede de la siguiente manera.
PermitRootLogin no
Conforme se hayan guardado los cambios, reiniciamos el servicio de SSH para que la nueva política surta efecto.
sudo systemctl restart sshd
Naturalmente que a partir de estas modificaciones, el logueo de root quedará desactivado u no se podrán realizar tareas administrativas de manera remota (a no ser que se eventualmente escalen usuarios comunes con la orden sudo).
4. Usar SSH Protocol 2
SSH viene en dos versiones. El SSH Protocolo 1 y SSH Protocolo 2. El segundo fue introducido en 2006 para reforzar la criptografía general de SSH. Por defecto se utilizaba en Protocolo 1 por razones de compatibilidad, pero a partir de 2018 se decidió desfasarlo definitivamente para evitar agujeros de seguridad.
Por tal motivo, en caso de contar con un servidor anterior al 2018, podríamos especificar ahora utilizar únicamente Procolo 2. Para ello le agregamos al fichero /etc/ssh/sshd_config la siguiente directiva:
# Agregado por peron para usar únicamente SSH Protocolo 2.
Protocol 2
Guardamos, salismos, y como siempre reiniciamos el servicio SSH para que surta efecto:
sudo systemctl restart sshd
A partir de ahora, SSH sólo utilizará Protocolo 2 y no podrá establecerse enlaces con clientes antiguos que utilicen el desfasado Protocolo 1.
Para comprobar que el Protocolo 1 ya no esté en suo, podremos ejecutar el comando:
ssh -1 usuario@ip_remota
Debería obtener un error similar a “SSH protocol v.1 is no longer supported”.
ssh -2 usuario@ip_remota
5. Configurar el Valor de Tiempo de Corte para Conexión SSH Inactiva
Dejar una conexión remota desatentida por largo tiempo es lo mismo que dejar en esa misma condición a una buena mujer. Puede constitnuir un riesgo de seguridad que ustedes conocen sin duda por esos cuernos que les veo. Para evitar este problema, es prodente configurar un valor de tiempo de corte para conexiones SSH inactivas, transcurrido el cual la sesión SSH se cerrará automáticamente.
Habremos de configurar nuevamente /etc/ssh/sshd_config y localizamos la directiva ClientAliveInterval. Le asignamos un valor razonable en segudos. Por ejemplo, podríamos utilizar 180 segundos.
ClientAliveInterval 180
Esto implica que la sesión SSH se cortará si transcurren 3 minutos (180 segundos) de inactividad.
Tras guardar debemos reiniciar el demonio para aplicar los cambnios:
sudo systemctl restart sshd
6. Posibilitar el Acceso SSH a Ciertos Usuarios
Podremos definir qué usuarios requieren el uso de SSH para loguearse y desarrollar tareas en el sistema. Esto mantendrá fuera de esta posibilidad a cualquier otro usuario que intente lograr ingreso al sistema sin nuestra aprobación.
Como siempre, editarmos el fichero /etc/ssh/sshd_config y le agregamos la directiva AllowUsers seguida de los nombres de usuario que queremos aprobar. Por ejemplo, he agregado los usuarios peron y evita para que cuenten con acceso remoto al sistema a través de sus respectivos clientes SSH. Cualquier otro usuario que intente ganar acceso remoto al sistema será bloqueado.
AllowUsers peron evita
Hemos de reiniciar SSH para que peresistan los cambios:
sudo systemctl restart sshd
7. Limitar los Intentos de Contraseña
Otra manera de agregar una capa de seguridad consiste en limitar la cantidad de intentos de pruebas de llaves SSH, caso en el que la conexión se cortará. Esto sólo tiene sentido si los usuarios utilizan pocas llaves y nos las especifican Una vez más en el fichero /etc/ssh/sshd_config y buscamos la directiva MaxAuthTries, y le definimos un valor para la cantidad máxima de intentos.
En este ejemplo, lo limitaremos a tres intentos (lo normal es 6) disponiendo:
MaxAuthTries 3
...y finalmente, reiniciamos el servicio SSH como en los escenarios anteriores.
Nota: si se recibe el error "Too many SSH authentications failures" podremos subir dicho valor a uno que represente la cantidad de llaves que el probable que tengan los usuarios en sus clientes.
No hay comentarios:
Publicar un comentario