Terminal Linux con comandos de seguridad y monitoreo

21 feb 2026

Hardening de Servidores Linux en Producción: La Guía del Veterano

Checklist avanzado para mejorar la seguridad en servidores Linux: desde la configuración SSH hasta IPTables, Fail2Ban y protección de contenedores.

Asegurar un servidor no es solo cuestión de seguir una lista de verificación. Es un arte, una mentalidad. Es la diferencia entre dormir tranquilo o despertar a las 3 de la mañana con una alerta de intrusión. En esta guía, vamos a compartir las claves para convertir un VPS Linux recién salido de la fábrica de tu proveedor de hosting, en una fortaleza digital lista para producción. Hablaremos de lo que dice la documentación... y de lo que no.

1. El ABC del Hardening: Los Cimientos de tu Fortaleza

Antes de instalar cualquier herramienta llamativa, hay que asegurarse de que los cimientos no sean de arena. Estos son los pasos que ningún administrador con experiencia se salta.

1.1. La Regla de Oro: Actualiza, Actualiza, Actualiza

Puede sonar a disco rayado, pero es el consejo número uno por una razón. No tiene sentido blindar la puerta con candados si las paredes son de cartón. Las vulnerabilidades en paquetes de software son la puerta de entrada favorita de los atacantes.

1.2. Sincroniza tu Tiempo: Más Importante de lo que Parece

Para un investigador forense, la correlación de logs es fundamental. Si los registros de tu servidor tienen una hora distinta a la de tu firewall perimetral o a la del ataque reportado por un cliente, estás perdido. Configurar la zona horaria local y activar el NTP (Network Time Protocol) es pan comido:

timezone_ntp.sh
# Ejemplo para México
sudo timedatectl set-timezone America/Mexico_City
sudo timedatectl set-ntp on
timedatectl # Para verificar el estado
bash

2. Blindando la Puerta de Entrada: SSH a Prueba de Balas

El servicio SSH es la puerta principal de tu servidor. Por defecto, viene con una cerradura estándar (puerto 22) y permite acceso con contraseñas que se pueden adivinar por fuerza bruta. Vamos a cambiarlo.

2.1. Adiós root, Hola Usuario con Poderes

Trabajar como root es como pasear por una mina de oro con un cartel de 'atráquenme'. Es una pésima práctica. Crea un usuario administrativo y asígnale la capacidad de hacer tareas de superusuario cuando sea necesario (sudo).

create_user.sh
adduser tucuenta
usermod -aG sudo tucuenta

# Consejo: Verifica que puedas hacer 'sudo whoami' con tu nuevo usuario antes de continuar.
bash

2.2. Cambia la Cerradura y Usa Llave Maestra

El puerto 22 es el primero que escanean los bots. Cambiarlo a un puerto alto (entre 1024 y 65535) es una técnica de 'oscuridad' que filtra el 99% del ruido automatizado. Pero la autenticación por contraseña sigue siendo débil. Las claves SSH son el estándar de oro.

El toque de calidad: Olvídate del antiguo RSA. Usa el algoritmo Ed25519. Es más seguro, más rápido y las claves son más cortas.

ssh_keys.sh
# En tu máquina local, genera tu par de llaves
ssh-keygen -t ed25519 -C "tu_correo@ejemplo.com"

# Luego, en el servidor (con tu usuario, no con root), instala la llave pública
mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys  # Pega aquí el contenido de tu archivo .pub
chmod 600 ~/.ssh/authorized_keys
bash

2.3. La Configuración Fina del Demonio SSH

Ahora viene lo bueno. Edita el archivo /etc/ssh/sshd_config y busca o añade estas líneas. Es como ponerle un blindaje a la puerta.

sshd_config
Port 2965                    # Elige un puerto >1024 que no uses
PermitRootLogin no           # Prohibido el acceso directo de root
PasswordAuthentication no    # Solo se puede entrar con llave
PubkeyAuthentication yes     # Aseguramos que las llaves están activadas
X11Forwarding no             # Desactivamos cosas que no necesitamos
MaxAuthTries 3               # Solo 3 intentos de autenticación por conexión
ClientAliveInterval 300      # Desconecta sesiones inactivas tras 5 minutos
ClientAliveCountMax 2
bash

3. El Portero Electrónico: Firewall (UFW vs IPTables)

Un servidor sin firewall es como una casa sin puertas. Todo el mundo puede entrar. Necesitas un portero que decida quién pasa y quién no.

3.1. UFW: El Portero Amigable (y Poderoso)

Para la mayoría de los casos, UFW (Uncomplicated Firewall) es más que suficiente. Es una interfaz sencilla para las complejas reglas de iptables. La estrategia es simple: 'Prohibido todo lo que no esté explícitamente permitido'.

ufw_setup.sh
# 1. Establece las políticas por defecto
sudo ufw default deny incoming
sudo ufw default allow outgoing

# 2. Permite SSH en tu nuevo puerto
sudo ufw allow 2965/tcp comment "SSH en puerto personalizado"

# 3. Permite HTTP y HTTPS si es un servidor web
sudo ufw allow 80/tcp comment "HTTP"
sudo ufw allow 443/tcp comment "HTTPS"

# 4. Activa el firewall y verifica
sudo ufw enable
sudo ufw status numbered
bash

3.2. IPTables: El Portero con Cinturón Negro

UFW es genial, pero a veces necesitas hacer cosas muy específicas. Ahí es donde entras en el modo experto con iptables. Es el firewall nativo de Linux, más flexible pero con una curva de aprendizaje más empinada.

iptables_rate_limit.sh
# Limitar nuevas conexiones SSH a 10 por minuto (La joya de Rate Limiting)
iptables -A INPUT -p tcp --dport 2965 -m state --state NEW -m recent --set
iptables -A INPUT -p tcp --dport 2965 -m state --state NEW -m recent --update --seconds 60 --hitcount 10 -j DROP

# Limitar conexiones simultáneas por IP (antiflood básico)
iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 20 -j REJECT
bash

4. El Guardia de Seguridad: Fail2Ban

Imagina a un guardia que no solo está en la puerta, sino que revisa las cámaras (los logs) y, si ve a alguien merodeando sospechosamente (varios intentos fallidos de contraseña), lo pone en la lista negra por un rato. Eso es Fail2Ban.

sshd.local
# Instalación: sudo apt install fail2ban -y
# Configuración en /etc/fail2ban/jail.d/sshd.local:

[sshd]
enabled = true
port = 2965          # Tu puerto 
filter = sshd
logpath = /var/log/auth.log
maxretry = 3         # 3 intentos fallidos
findtime = 600       # en los últimos 10 minutos
bantime = 3600       # y te bloqueo por 1 hora
ini

5. La Capa Invisible: SELinux y AppArmor

Este es un tema que suele intimidar, pero es el guardaespaldas personal de tus procesos. Tanto SELinux (Red Hat) como AppArmor (Debian/Ubuntu) implementan un control de acceso obligatorio (MAC).

¿Qué significa esto? Que incluso si un proceso malicioso logra colarse (por ejemplo, un servidor web comprometido), su capacidad de hacer daño está limitada. No podrá leer archivos de configuración ni escribir en directorios del sistema porque, simplemente, no tiene permiso a nivel de kernel para hacerlo.

6. El Rincón Avanzado: Toques de Verdadero Experto

  • LKRG (Linux Kernel Runtime Guard): Un módulo del kernel que realiza comprobaciones en tiempo real para detectar intentos de explotación del propio kernel. Una capa espectacular de defensa profunda.
  • WireGuard para redes privadas: No expongas servicios internos (como bases de datos) a internet. Configura WireGuard, una VPN moderna y rápida, y accede a tus servicios internos solo a través de este pasadizo seguro.
  • Integración con Docker: Docker manipula iptables por su cuenta. Usa siempre la cadena DOCKER-USER de iptables para añadir reglas que afecten al tráfico de tus contenedores, y limita los recursos desde su creación (--cpus, --memory).
  • Automatización: No confíes en tu memoria. Crea scripts para aplicar tu configuración de seguridad y guárdalos en Git. Si un día tu servidor cae, podrás levantar uno nuevo asegurado en minutos.

Conclusión: La Seguridad es un Viaje

Hardening no es una tarea de un día. Es un proceso continuo de aprendizaje y mejora. Compartir este conocimiento contribuye a una comunidad de profesionales que entienden que la tranquilidad de un sistema seguro se construye paso a paso, con paciencia y con pasión. Ve y fortifica tus servidores.

#linux#vps#sysadmin#seguridad#iptables#ssh