floure.ARCHIVO / Tecnologías de la información
← Volver a la colección5 MIN DE LECTURA

Tecnologías de la información

Hardening Linux

Sistemas Operativos / Linux

Hardening es reducir exposición conservando una forma de administrar y recuperar el equipo. Antes de reiniciar SSH, conviene validar configuración y mantener una sesión de recuperación. No queremos sellar la puerta con nosotros afuera. (；￣Д￣)

Vamos a realizar un hardening básico de servidor en Ubuntu. Si bien esto nos ayudará a tenerlo más controlado, es sólo una primera capa de defensa.

Índice

  1. Remover root
  2. Certificación SSH
  3. Deshabilitar contraseña para SSH
  4. Cambiar puerto de conexión por defecto
  5. Pruebas de conexión con certificado
  6. Recomendaciones de hardening adicionales
  7. Conclusiones

Remover root

Pros

  • Evita el acceso directo a Super Usuario
  • Obliga a usar un usuario menos privilegiado
  • Reduce el riesgo de daños en caso de que la cuenta sea comprometida Cons
  • Puede llegar a ser menos conveniente si es que necesitamos acceder como root directamente

Debemos primero editar el archivo de configuración SSH sudo nano /etc/ssh/sshd_config

Buscar la linea PermitRootLogin y cambiarla a no (nota: eliminar el # del comentario)

Guardar y reiniciar el servicio sudo service ssh restart

Certificación SSH

Pros

  • Más seguro que usar contraseñas
  • Claves virtualmente imposible de adivinar por fuerza bruta
  • Simplifica inicio de sesión al no necesitar gestionar la contraseña nosotros mismos Cons
  • Si se expone la clave privada de alguna forma, vulneramos nuestra conexión
  • Configuración inicial no es tan sencilla para usuarios comunes

Crear un par de claves SSH (privada y pública) ssh-keygen -t rsa -b 4096 -C "correo@example.com" Para la ubicación lo ideal es por defecto para facilitar su búsqueda pero también se puede considerar una medida de seguridad dejarla en otro sitio.

La pública se guarda en ~/.ssh/id_rsa.pub La privada en ~/.ssh/id_rsa

Deshabilitar contraseña para SSH

Pros

  • Elimina el método de contraseña si la configuración efectiva lo desactiva; siguen existiendo otros ataques
  • Facilita el acceso automático en procesos (o scripts)

Cons

  • Si se expone la clave privada, el acceso total está comprometido
  • Dificulta la recuperación en caso de olvido o pérdida de la clave privada

Asegurarnos de copiar la clave pública (en este caso será local) ssh-copy-id nombreUsuario@localhost

Editamos el archivo de configuración SSH nuevamente sudo nano /etc/ssh/sshd_config Esta vez cambiamos lo siguiente:

PasswordAuthentication no
ChallengeResponseAuthentication no

(nota: eliminar el # del comentario)

Reiniciamos nuevamente el servicio

Cambiar puerto de conexión por defecto

Pros

  • Disminuye los riesgos de ataques automáticos dirigidos al puerto por defecto (22)
  • Puede reducir ruido de bots que solo prueban 22; el nuevo puerto sigue siendo escaneable Cons
  • Administradores deben gestionar el nuevo puerto
  • No es una protección sólida, solo es una medida disuasiva

En el mismo archivo de configuración SSH buscamos la línea Port 22 y la cambiamos por otro número que nos convenga y no haga conflicto, por ejemplo el 2222

Reiniciamos el servicio

Pruebas de conexión con certificado

Pros

  • Asegurarse de que la configuración es correcta antes de su implementación en producción Cons
  • Si no las realizamos de manera correcta, puede generar una falsa sensación de seguridad

Primero una prueba ssh directa como root: ssh -p 2222 root@localhost Se nos niega el acceso.

Luego, una prueba de ingreso sin certificación: ssh otroUsuario@localhost -p 2222

Y ahora una prueba con el certificado explícito

Desde windows, podemos utilizar este comando para copiar la clave pública directamente:

type $env:USERPROFILE\.ssh\id_rsa.pub | ssh floure@localhost -p 2222 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Esto muestra el procedimiento relatado, no una validación completa de seguridad.

Recomendaciones de hardening adicionales

Desactivar el acceso de usuarios no autorizados

  • Menos usuarios con acceso = menos posibilidades de acceso no autorizado

Limitar intentos de conexión fallidos (fail2ban)

  • Protege contra fuerza bruta limitando la cantidad de intentos fallidos permitidos

Usar VPN para acceder

  • Encripta el tráfico y mejora la privacidad, restringe acceso a solo aquellos en la red privada

Configurar 2FA

  • Requiere algo que el atacante no puede obtener fácilmente

Parches de seguridad Quizás suena redundante pero es uno de los más importantes y dificultosos. Requiere de tiempo, pruebas adicionales y afinar detalles diversos. Parchar la seguridad es como arreglar un bote con agujeros constantemente. Cada vez que tapas un agujero, encuentras otro. Es una tarea de nunca acabar. Realizar estos parches es necesario y siempre ayuda, sin embargo un parche mal aplicado (o incluso de manera apresurada), puede provocar problemas de compatibilidad o fallos no previstos.

Conclusiones

El hardening es una práctica que DEBE realizarse, mejorarse y monitorear constantemente. Si bien es una barrera de defensa importante, no debemos quedarnos con sólo una. La defensa debe realizarse en capas, como los ogros.

Un hardening incorrecto puede también traernos diversos problemas, es así como siempre debemos balancear las ventajas y desventajas de los mismos. Podríamos llegar a interrumpir sistemas, causar conflictos con nuestras propias herramientas, levantar falsos positivos constantemente, etc.

En Windows, el proceso es muy similar, si no igual, con algunas cosas distintas que podemos realizar.

Véase también

  • Jaula Chroot — Restricciones adicionales del entorno de usuario mediante chroot.

Precisión: OpenSSH. Aquí «certificación/certificado» se usa informalmente: el ejercicio crea un par de claves y authorized_keys, no un certificado SSH firmado por una CA. PermitRootLogin no elimina root ni reduce automáticamente privilegios sudo. Probar con clave antes de cerrar contraseñas, conservar acceso de recuperación, verificar sshd -t y opciones efectivas (Include, Match, keyboard-interactive). localhost en Windows apunta al equipo Windows, salvo un reenvío explícito; usar la IP de la VM cuando corresponda. Los permisos de ~/.ssh y authorized_keys importan. VPN solo restringe el acceso si las rutas/firewall lo imponen. MFA/fail2ban ayudan bajo su alcance y no garantizan impedir compromiso. Laboratorio no reproducido; capturas no inspeccionadas.

+----------------------------------------+
| Floure &                               |
| Tachibana's guild                      |
| [Hikari · Nozomi · Vesper]             |
| SEAL: sha256/12: 9a532450cd17          |
| STATUS: LITURGY_IN_PROGRESS            |
+----------------------------------------+

Conexiones

Abrir red completa ↗
✳

Fin del apunte

Seguir explorando ↗