La primera hora: una superficie de ataque más pequeña.

Verifique y preserve el acceso

Confirma la identidad del servidor mediante un canal de confianza y añade tu clave pública SSH. Crea un usuario administrativo con nombre. Mantén abierta la sesión original mientras pruebas la nueva y registra el método de recuperación antes de cambiar la autenticación.

Aplique parches y reduzca la exposición

Instale las actualizaciones de seguridad compatibles y reinicie si es necesario. Revise los servicios en escucha y permita solo los puertos necesarios en el cortafuegos, incluido IPv6. Elimine los demonios no utilizados y evite abrir una base de datos públicamente solo para facilitar la configuración.

Separa usuarios y secretos

Ejecute las aplicaciones con sus propias cuentas. Coloque la configuración privada fuera del directorio web público y exclúyala del control de versiones. Use privilegios de base de datos limitados y credenciales separadas para producción y experimentos.

Deja una ruta de recuperación funcional

Configura la rotación de registros, las alertas de disco y una copia de seguridad independiente. Reinicia una vez para verificar que la aplicación arranca correctamente. Registra lo que cambió para poder reconstruir la configuración sobre una imagen limpia.

Comprueba antes de cerrar la sesión

Abre una segunda conexión con la nueva cuenta, verifica la elevación administrativa y prueba el cortafuegos desde otro cliente. Confirma que el servicio vuelve tras el reinicio. Mantén documentada la ruta de recuperación del proveedor para que una regla de red equivocada no exija una recuperación improvisada.

Una lista de verificación del primer día

Revisa los sockets abiertos, los eventos de autenticación recientes, el estado de las actualizaciones, la antigüedad de las copias de seguridad y el uso del disco. Comprueba que la configuración privada y los metadatos de control de versiones no puedan obtenerse a través de HTTP. Usa el conjunto más pequeño de herramientas instaladas que soporte la carga de trabajo real.

ss -lntup
df -h
free -h
systemctl --failed

Realiza los cambios de acceso en un orden reversible

Primero confirma la ruta de consola o de rescate y verifica la clave de host de SSH a través de un canal de proveedor de confianza. Instala la clave pública para un administrador con nombre, luego abre una segunda conexión y prueba la elevación de privilegios. Valida la sintaxis de configuración de SSH antes de recargar el servicio. Aplica los cambios de firewall solo después de que la ruta de SSH prevista esté permitida. Desactiva un método de autenticación antiguo después de que el sustituto funcione desde una sesión nueva, incluido cualquier flujo de segundo factor requerido.

• Inspeccione la configuración efectiva y los fragmentos incluidos; un ajuste en un archivo puede no ser la política final.
• Revisa tanto la autenticación por contraseña como la política de teclado interactivo al evaluar un diseño de inicio de sesión basado en claves.
• Un puerto SSH no predeterminado puede reducir el ruido de fondo, pero no sustituye a las claves verificadas, los límites de acceso ni las actualizaciones.
• Usa el nombre del servicio y el procedimiento de recarga de tu distribución. Mantén la sesión original hasta que la nueva política esté probada.

# Validate before applying a changed SSH configuration.
sudo /usr/sbin/sshd -t
# Read effective settings; adapt user, host and client address to the test.
sudo /usr/sbin/sshd -T -C user=admin,host=server.example,addr=198.51.100.10

Documentación oficial: OpenSSH: manual de configuración del servidor

Demuestra el firewall desde fuera del host

Revisa el cortafuegos de la red del proveedor y el cortafuegos del invitado como controles separados. Prueba el servicio previsto sobre IPv4 y IPv6 desde otra máquina autorizada. Una conexión local solo demuestra que un proceso está escuchando. No deniegues a ciegas todos los paquetes ICMP: el funcionamiento normal de la red también necesita tráfico de control adecuado. Comprueba los puertos publicados por el contenedor frente a las reglas reales, porque la exposición de la aplicación puede no coincidir con la política que creías que aplicaba un front end de cortafuegos.

• Si SSH falla, inspeccione las restricciones de dirección de origen, la interfaz de escucha y el firewall del proveedor antes de cambiar las claves repetidamente.
• Si HTTPS falla, comprueba DNS, el proceso a la escucha y el firewall local/proxy, en ese orden.
• Antes del primer conjunto de datos de producción, verifica el estado de las actualizaciones, un reinicio limpio, las alertas de disco y una copia de seguridad restaurable de forma independiente.
• Establezca una zona horaria documentada y verifique la sincronización horaria. No añada ajustes arbitrarios de swap o registro sin comprobar las necesidades de memoria y retención de la carga de trabajo.

Documentación oficial: Ubuntu Servidor: administración del firewall