Hardening básico del servidor de tu pyme en 60 minutos

Un servidor recién instalado es una superficie de ataque enorme. Puertos abiertos que nadie necesita, usuarios por defecto que nadie ha eliminado, SSH accesible desde cualquier IP del mundo con autenticación por contraseña habilitada. Los bots empiezan a escanear IPs nuevas en cuestión de minutos: si el servidor tiene IP pública, el primer intento de login por fuerza bruta en SSH suele llegar antes de la primera hora. El hardening no es una tarea de días: con una hora y una lista clara se cierra el 80% del riesgo habitual en servidores de pyme. Esta es la lista y el orden en que hay que aplicarla.

1. Antes de empezar: consola de emergencia configurada

El único paso previo obligatorio antes de tocar cualquier configuración de acceso: verifica que tienes acceso a la consola de emergencia del servidor. En Hetzner es la Rescue Console, en OVHcloud el KVM, en AWS el Systems Manager Session Manager, en DigitalOcean la Recovery Console. Esta consola no depende de SSH y es tu red de seguridad si un error de configuración te deja fuera.

Si estás en un servidor físico en la oficina, necesitas acceso físico al teclado o iDRAC/iLO si el servidor lo soporta. Documenta cómo accedes a esta consola antes de tocar nada. En una empresa de logística de Sevilla con 15 empleados, un técnico junior que configuró fail2ban sin whitelist dejó sin acceso SSH a todo el equipo durante un fin de semana. La consola de emergencia del VPS resolvió el problema en 10 minutos. Sin ella, habrían necesitado escalar al datacenter.

2. Usuarios y accesos: lo primero que tocar

El usuario root no debería usarse para la operativa diaria. Crea un usuario con privilegios sudo, desactiva el login directo como root y elimina o bloquea cualquier cuenta de usuario creada por defecto durante la instalación del sistema o de las aplicaciones. En Ubuntu, el usuario ubuntu creado automáticamente en algunas imágenes de cloud tiene permisos sudo sin contraseña: revísalo.

Cambia las contraseñas por defecto de cualquier servicio instalado: base de datos (el usuario root de MySQL viene sin contraseña en algunas instalaciones por defecto), panel de control, consola web. Si el servicio permite autenticación por clave SSH, actívala. Las cuentas de sistema como postgres o www-data que tienen shell activa pero no deberían poder hacer login interactivo: establece su shell a /usr/sbin/nologin.

3. SSH: reducir la superficie de ataque más atacada

El puerto 22 recibe miles de intentos de fuerza bruta diarios en cualquier servidor con IP pública. La configuración correcta de SSH no es una sola medida sino varias en combinación:

Cambiar el puerto por defecto (22): no es seguridad real, pero elimina el ruido de los bots automatizados que escanean solo el puerto estándar. Usa cualquier puerto por encima del 1024 que no esté ocupado.
Desactivar login de root: PermitRootLogin no en /etc/ssh/sshd_config. El usuario root no puede conectar por SSH aunque tenga la contraseña correcta.
Autenticación solo por clave: PasswordAuthentication no una vez que tienes las claves SSH configuradas y verificadas. Genera un par de claves RSA de 4096 bits o Ed25519 en tu máquina local y añade la clave pública a ~/.ssh/authorized_keys en el servidor.
AllowUsers: lista blanca de usuarios que pueden conectar por SSH. Cualquier otro usuario del sistema no podrá aunque tenga contraseña válida.
Restricción por IP de origen: si el acceso SSH solo lo necesitas desde tu oficina o VPN, limítalo en el firewall. Esto es más robusto que restricciones en sshd_config.

Recuerda reiniciar el servicio SSH después de cada cambio de configuración (systemctl restart sshd) y verificar que puedes conectar en una nueva sesión antes de cerrar la sesión actual.

4. Firewall: cerrar todo lo que no se use

La regla base es denegar todo el tráfico entrante y abrir solo los puertos necesarios. En un servidor web típico: HTTP (80), HTTPS (443), SSH (el puerto que hayas elegido) y nada más. Si la base de datos no necesita exposición externa, que solo escuche en localhost: bind-address = 127.0.0.1 en MySQL o equivalent en PostgreSQL.

UFW en Ubuntu/Debian es suficiente para la mayoría de pymes por su simplicidad:

ufw default deny incoming — deniega todo el tráfico entrante por defecto.
ufw allow 443/tcp — abre HTTPS.
ufw allow 80/tcp — abre HTTP (para redirecciones a HTTPS).
ufw allow [tu-puerto-ssh]/tcp — abre tu puerto SSH personalizado.
ufw enable — activa el firewall.

Verifica el estado con ufw status verbose y asegúrate de que el firewall se activa automáticamente después de un reinicio. En RHEL/CentOS, firewalld es el equivalente y la lógica es similar.

5. Actualizaciones automáticas de seguridad

Configura las actualizaciones de seguridad para que se apliquen automáticamente. Solo actualizaciones de seguridad, no de versión mayor, para evitar roturas inesperadas en producción. Con notificación por correo cuando se aplica algo crítico.

En Debian/Ubuntu: instala el paquete unattended-upgrades y configura /etc/apt/apt.conf.d/50unattended-upgrades para activar solo los repositorios de seguridad. En RHEL/CentOS 8+: dnf-automatic con apply_type = security en el fichero de configuración.

La notificación por correo cuando se aplica un parche crítico es importante: quieres saber qué se ha actualizado para anticipar posibles incompatibilidades o para documentar el historial de parches. Consulta nuestro servicio de administración de servidores si no tienes capacidad interna para gestionar esto.

6. Logs y fail2ban: visibilidad y respuesta automática

Sin logs no hay visibilidad. Asegúrate de que el sistema está registrando accesos SSH, errores de autenticación y actividad del servidor web. journalctl -u ssh en sistemas con systemd muestra el historial de conexiones SSH. Si ves cientos de intentos fallidos desde las mismas IPs, fail2ban ya debería haberlas bloqueado.

fail2ban analiza los logs y bloquea automáticamente IPs que intentan fuerza bruta. Configúralo para SSH como mínimo: instala el paquete, copia el fichero jail.conf como jail.local y activa la jaula de SSH con un umbral de 5 intentos fallidos y un ban de 1 hora. Para aplicaciones web con panel de login, añade la jaula correspondiente (Nginx o Apache con expresiones regulares que detecten intentos de login fallidos).

Los logs deben tener una política de retención: cuántos días se guardan, con rotación automática vía logrotate. Si el entorno está regulado o si necesitas una auditoría de seguridad, considera enviar los logs a un sistema centralizado (rsyslog remoto o Graylog) para que no puedan ser alterados si el servidor se ve comprometido.

7. Verificación final: confiar pero verificar

Una vez aplicadas las medidas, verifica con un escáner externo que solo están abiertos los puertos que deben estar abiertos. nmap -sV [IP-del-servidor] desde otra máquina es suficiente para una comprobación básica y te muestra qué servicios están escuchando en cada puerto.

La lista de verificación final:

Login de root por SSH devuelve "Permission denied" aunque la contraseña sea correcta.
Autenticación por contraseña SSH devuelve "Permission denied (publickey)" desde una IP no autorizada.
Firewall activo y reglas correctas (ufw status verbose).
fail2ban activo y vigilando SSH (fail2ban-client status sshd).
Actualizaciones automáticas configuradas y con el primer run completado.
Solo los puertos necesarios visibles desde el exterior (verificado con nmap).

Puedes complementar este hardening con una auditoría de seguridad del servidor que revise configuraciones más avanzadas: AppArmor/SELinux, auditoría de procesos con auditd, configuración de sysctl para seguridad del kernel, y verificación de integridad de ficheros con AIDE.

Comparativa: coste de cada capa por tipo de protección

Medida	Tiempo implantación	Qué bloquea	Coste
Deshabilitar root SSH	5 min	Ataques directos a root	Cero
Clave SSH + sin contraseña	15 min	Fuerza bruta de contraseñas	Cero
UFW/firewalld	20 min	Acceso a puertos no necesarios	Cero
fail2ban	20 min	Fuerza bruta automatizada	Cero
Actualizaciones automáticas	15 min	Vulnerabilidades conocidas	Cero
Restricción SSH por IP	10 min	Acceso desde IPs no autorizadas	Cero (requiere IP fija)

Por dónde empezar mañana

Verifica que tienes acceso a la consola de emergencia de tu proveedor antes de tocar cualquier configuración.
Crea un usuario sudo y desactiva el root SSH. Son los primeros dos cambios, los más impactantes y los más seguros de aplicar.
Genera un par de claves SSH en tu máquina local, copia la pública al servidor, verifica que puedes conectar con la clave y entonces desactiva la autenticación por contraseña.
Activa UFW con solo los puertos necesarios e instala fail2ban con la configuración por defecto para SSH.

Si gestionas varios servidores para tu empresa o clientes, el servicio de infraestructura gestionada incluye el hardening inicial de cada servidor nuevo y la verificación periódica de la configuración de seguridad.

Preguntas frecuentes

¿El hardening elimina el riesgo de ser hackeado?

No lo elimina, pero sí cierra el 80-90% de los vectores de ataque habituales contra servidores de pyme. La mayoría de ataques exitosos explotan configuraciones por defecto o vulnerabilidades sin parchear, no técnicas avanzadas. Un servidor bien configurado deja de ser un objetivo rentable para los atacantes automatizados.

¿Es suficiente con UFW o necesito un firewall hardware?

Para la mayoría de pymes, UFW o firewalld bien configurados son suficientes como primera capa. Un firewall hardware añade capacidades de inspección de tráfico y gestión centralizada, pero no es indispensable si el servidor está bien hardenizado. La combinación ideal es ambas capas.

¿Cuánto tiempo lleva el hardening inicial de un servidor nuevo?

Con un checklist claro y el servidor accesible, los pasos descritos en este artículo llevan entre 45 minutos y 2 horas dependiendo de la distribución y la experiencia del técnico. La parte más lenta suele ser la configuración de SSH y la verificación final con nmap.

¿Qué pasa si pierdo el acceso SSH por un error de configuración?

Si estás en un VPS o servidor cloud, el proveedor ofrece acceso a la consola de emergencia que no depende de SSH. Por eso es importante tener esa consola configurada antes de tocar la configuración de SSH. En servidores físicos, necesitas acceso físico o iDRAC/iLO.

¿Con qué frecuencia hay que repetir el hardening?

El hardening inicial es un punto de partida, no un evento único. Las actualizaciones de seguridad deben ser continuas. Una revisión completa de la configuración cada 6-12 meses es razonable, además de verificar el estado del firewall y fail2ban después de cada actualización mayor del sistema.

¿Cambiar el puerto SSH de 22 realmente mejora la seguridad?

Mejora la seguridad práctica reduciendo el ruido de bots que escanean el puerto 22, pero no es seguridad real si un atacante hace un escaneo completo de puertos. La combinación correcta es cambiar el puerto Y desactivar autenticación por contraseña Y restringir por IP. Ninguna medida sola es suficiente.

¿fail2ban puede bloquear IPs legítimas?

Sí, si la configuración de IPs en whitelist no está bien hecha. Añade siempre las IPs de tu oficina y VPN a la lista blanca de fail2ban antes de activarlo. Si ya estás bloqueado, la consola del proveedor o el acceso físico son la única salida.