🛡️ 9 cosas que hago siempre que monto un servidor Linux

Cada vez que leo noticias sobre brechas de seguridad tochas, el 90% de las veces el problema no es que los atacantes sean unos dioses juanquers malvados con técnicas ultrasofisticadas. Más bien son fallos tipo que alguien dejó SSH con la contraseña admin123, o un servicio escuchando en un puerto que no pintaba nada abierto, o que llevaban 6 meses sin actualizar nada del sistema.

La seguridad no tiene por qué ser super complicada, en muchos casos debemos aplicar el sentido común. La mayoría de desastres se evitan haciendo bien lo básico. Lo que hago yo siempre que monto un servidor Linux, ya sea un VPS en OVH o un cacharrito en casa.

Vamos a ver pasos sencillos, probados, y que funcionan.

Terminal de Linux mostrando comandos de seguridad en un servidor.

1. Instalar lo mínimo imprescindible

Lo primero de todo y que mucha gente no se da cuenta es que con cada paquete que instalas en tu servidor es un paquete más que puede tener una vulnerabilidad. Así de simple. Cada servicio corriendo es una puerta más que alguien puede intentar abrir.

Cuando monto un servidor nuevo, instalo solo lo que necesito para que funcione lo que tengo que hacer ahí. ¿Un servidor web? Pues Nginx, PHP y lo que toque. ¿Una base de datos? Pues MariaDB y ya. Nada de instalar cosas por si acaso, eso es un error, aquí, menos es más. Si luego necesitas algo, lo instalas. Pero de entrada, cuanto menos haya, menos hay que vigilar.

Menos paquetes = menos vulnerabilidades = menos superficie de ataque.

Lo primero que hago después de instalar es revisar qué hay escuchando:

sudo ss -tulpn

Ese comando te saca una lista con todos los puertos TCP y UDP abiertos y qué proceso está detrás de cada uno. Repásalo bien. Si hay algo ahí que no reconoces o que no necesitas, al carrer.

# Ver qué servicios están habilitados para arrancar con el sistema
systemctl list-unit-files --type=service | grep enabled

# Desactivar y parar un servicio que no necesites
sudo systemctl disable nombre_del_servicio
sudo systemctl stop nombre_del_servicio

# Limpiar paquetes huérfanos
sudo apt autoremove --purge

Es un poco rollo al principio, pero un servidor limpio es un servidor con el que duermes tranquilo. Lo que no está instalado no se puede explotar.

2. Blindar SSH a muerte

💡 SSH Secure Shell. Protocolo que permite conectarte de forma remota y segura a un servidor a través de la terminal. Es la herramienta principal de cualquier sysadmin. Más info → es la puerta principal de tu servidor. Es por donde entras tú… y por donde intentan entrar los demás. Así que lo primero que toco siempre es la configuración de SSH.

Nada de root por SSH

Jamás. Nunca. Ni de broma. El usuario root tiene acceso total al sistema. Si alguien consigue entrar como root, se acabó. Game over. Así que lo primero: desactivar el login como root por SSH y obligar a entrar siempre con un usuario normal que luego use sudo si necesita hacer algo de administración.

Nada de contraseñas

Las contraseñas se pueden adivinar por fuerza bruta. Las 💡 claves SSH Par de claves criptográficas (pública y privada) que permiten autenticarte en un servidor sin necesidad de escribir una contraseña. Mucho más seguro que password. no. Así que desactivamos también la autenticación por contraseña y usamos solo claves.

Edita /etc/ssh/sshd_config y asegúrate de tener esto:

PermitRootLogin no
PasswordAuthentication no

Después reinicia SSH:

sudo systemctl restart sshd

Ojito: antes de hacer esto, asegúrate de que ya tienes tu clave pública copiada en el servidor con ssh-copy-id. Si no, te quedas fuera y la has liado parda.

Cambiar el puerto por defecto

El puerto 22 es el estándar de SSH. Cada bot que anda por internet escaneando servidores lo primero que prueba es el puerto 22. Cambiarlo a otro (por ejemplo, 2222 o el que tú quieras) no es seguridad real de verdad, pero sí reduce una barbaridad el ruido de ataques automatizados en los logs.

# En /etc/ssh/sshd_config
Port 2222

Fail2Ban: el portero

💡 Fail2Ban Herramienta que monitoriza los logs del sistema y banea automáticamente las IPs que fallan repetidamente al intentar loguearse. Muy útil contra ataques de fuerza bruta. Más info → es una de esas herramientas que instalo siempre. Lo que hace es vigilar los logs de SSH y si ve que una IP está intentando entrar a lo bruto (muchos intentos fallidos seguidos), la banea automáticamente con el firewall. Así no tiene que estar yo mirando logs como un loco.

sudo apt install fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Y con la configuración por defecto ya funciona bastante bien para SSH. Si quieres afinar los tiempos de baneo y el número de intentos permitidos, puedes crear un archivo /etc/fail2ban/jail.local:

[sshd]
enabled = true
port = 2222
maxretry = 3
bantime = 3600
findtime = 600

Con esto, si alguien falla 3 veces en 10 minutos, se come un baneo de 1 hora. Al carrer.

3. Firewall: cerrar todo, abrir solo lo justo

Da igual que tu servidor esté en tu casa, en un VPS o en AWS. Siempre firewall. Siempre. La regla es sencilla: bloquear todo por defecto y abrir solo los puertos que necesites.

Yo uso 💡 UFW Uncomplicated Firewall. Interfaz simplificada para iptables que hace que configurar un firewall en Linux sea pan comido. Más info → porque es facilísimo:

# Política por defecto: denegar todo lo que entre
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Abrir solo lo necesario
sudo ufw allow 2222/tcp    # SSH (o el puerto que hayas puesto)
sudo ufw allow 80/tcp      # HTTP
sudo ufw allow 443/tcp     # HTTPS

# Activar
sudo ufw enable

# Verificar
sudo ufw status verbose

Si tienes una IP fija para conectarte, puedes restringir SSH solo a esa IP y ya nadie más en el mundo puede ni intentar conectarse:

sudo ufw allow from 83.50.XX.XX to any port 2222

Esto es nivel bestia de seguro. Si no tienes IP fija, al menos deja el puerto SSH abierto pero con Fail2Ban detrás.

Buena configuración de firewall

Política deny por defecto para tráfico entrante
Abrir solo los puertos que uses de verdad
Restringir SSH a IPs concretas si puedes

Errores típicos

Dejar el firewall desactivado porque "total, si no hay nada raro"
Abrir rangos enteros de puertos por comodidad
Olvidarte de abrir el puerto SSH nuevo antes de activar UFW (te quedas fuera)

4. Mantener el sistema actualizado

Esta es la que más gente se salta y la que más desastres causa. No actualizar tu servidor es como dejar la puerta de tu casa abierta con un cartel que dice pasa, cubatas gratis.

Los atacantes no suelen usar vulnerabilidades supersofisticadas y desconocidas. Usan exploits exploits Código que aprovecha una vulnerabilidad conocida en un software para hacer algo que no debería poder hacer. que llevan meses o años publicados y que tienen parche disponible. Pero claro, si tú no aplicas el parche, pues ahí sigues con el agujero abierto.

Actualizaciones automáticas de seguridad

Lo mejor que puedes hacer es configurar actualizaciones automáticas para los parches de seguridad. Así no dependes de que te acuerdes:

# Ubuntu / Debian
sudo apt install unattended-upgrades
sudo dpkg-reconfigure unattended-upgrades

# Rocky Linux / AlmaLinux / CentOS
sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic.timer

No te olvides de reiniciar

Algunas actualizaciones, especialmente las del kernel, necesitan un reinicio para aplicarse de verdad. Puedes comprobar si tu servidor necesita un reinicio así:

# Ubuntu / Debian
if [ -f /var/run/reboot-required ]; then echo "Reinicio necesario"; fi

# RHEL / Rocky Linux
sudo needs-restarting -r

Yo suelo tener un cron semanal que me avisa si hay reinicio pendiente. Así no se me pasa.

5. El principio del mínimo privilegio

Esto es de esas cosas que suenan de sentido común pero que luego nadie aplica: cada usuario y cada servicio debería tener solo los permisos que necesita y ni uno más.

No corras servicios como root

Si un servicio se compromete y está corriendo como root, el atacante tiene control total del sistema. Si corre como un usuario sin privilegios, el daño que puede hacer es mucho más limitado. La diferencia es abismal.

La mayoría de servicios modernos ya vienen preparados para correr con su propio usuario:

🌐 nginx

Corre como www-data

🐘 PostgreSQL

Corre como postgres

🗄️ MariaDB

Corre como mysql

🐳 Docker

Corre como docker

Siempre revisa la configuración de cada servicio y confirma que no esté corriendo como root. Es un detalle que marca la diferencia entre nos han hackeado un servicio y nos han hackeado el servidor entero.

Sudo con cabeza

Los usuarios normales deberían usar sudo solo cuando lo necesiten, y lo ideal es limitar qué comandos puede ejecutar cada uno. No todo el mundo necesita sudo completo.

sudo visudo

# El usuario 'deploy' solo puede reiniciar nginx, nada más
deploy ALL=(ALL) NOPASSWD: /bin/systemctl restart nginx

Así, si la cuenta de deploy se compromete, el atacante solo puede reiniciar nginx. Que es un coñazo, sí, pero no es el fin del mundo. Muy diferente a tener acceso root completo.

6. Monitorizar logs

Los logs de tu servidor te cuentan todo lo que está pasando. Intentos de login fallidos, servicios que petan, accesos sospechosos, errores raros… Está todo ahí. El problema es que nadie los mira.

No digo que te pongas a leer logs línea por línea todos los días. Pero sí que tengas algún sistema que te haga un resumen de lo importante.

Logwatch para resúmenes diarios

💡 Logwatch Herramienta que analiza los logs de tu servidor y te envía un resumen diario por email o lo guarda en un archivo. Te avisa de actividad sospechosa sin que tengas que revisar todo manualmente. Más info → te manda un email diario con un resumen de lo que ha pasado en tu servidor. Intentos de login fallidos, servicios que han arrancado o parado, uso de disco… Es muy cómodo.

sudo apt install logwatch

# Probar un resumen en consola
sudo logwatch --output stdout --range today

Lo configuras para que te mande un email diario y le echas un vistazo rápido cada mañana mientras te tomas el café. No tarda ni 2 minutos y te puedes ahorrar un susto gordo.

Logs importantes que deberías vigilar

/var/log/auth.log — Intentos de login, usos de sudo, actividad de SSH
/var/log/syslog — Mensajes generales del sistema
/var/log/fail2ban.log — IPs baneadas por Fail2Ban
Logs específicos de tus aplicaciones (Nginx, Apache, tu app…)

Si quieres ya ir a otro nivel, puedes montar un stack con Elasticsearch + Kibana para centralizar y visualizar logs. Pero eso ya es para cuando tienes varios servidores o mucho volumen. Para un servidor o dos, Logwatch va sobrado.

7. Backups: tu último salvavidas

Da igual lo seguro que sea tu servidor, los discos se rompen, la gente mete la caga, los despliegues salen mal, el ransomware existe, en resumen, las desgracias pasan. Si no tienes backups, estás jugando con fuego.

La regla del 3-2-1

Es un clásico que funciona:

3️⃣ 3 copias

De tus datos importantes. La original y dos copias más.

2️⃣ 2 soportes

En al menos dos tipos de almacenamiento diferentes. Disco local + nube, por ejemplo.

1️⃣ 1 fuera de casa

Al menos una copia en una ubicación física diferente. Si se quema la oficina, que no se pierda todo.

Automatiza las copias

Las copias manuales no se hacen, e ya. Es así. Automatízalas con cron + rsync, o usa herramientas como BorgBackup BorgBackup Herramienta de backup con deduplicación y cifrado. Muy eficiente para backups incrementales. o Restic Restic Herramienta de backup moderna, rápida y fácil de usar. Soporta cifrado y múltiples backends como S3, SFTP o repositorios locales. .

¿Qué hacer backup y qué no?

No necesitas hacer backup del sistema operativo entero. Si el servidor se va a la puta, es más rápido montar uno nuevo e instalar todo de cero. Lo que sí necesitas son los datos que no puedes recrear:

Bases de datos (el mysqldump o pg_dump de turno)
Datos de aplicación (uploads de usuarios, archivos generados)
Configuraciones (nginx, crontabs, scripts personalizados, .env)
Secretos (claves SSH, certificados SSL, tokens de API)

Y lo más importante de todo: prueba tus backups. Una copia que no puedes restaurar no es una copia, es una desgracia. Al menos una vez al mes, prueba a restaurar algo para asegurarte de que funciona.

8. Monitorización de integridad de archivos

Esta es de las que menos gente conoce pero que a mí me parece fundamental. La idea es sencilla: tener una herramienta que vigile los archivos críticos del sistema y te avise si algo cambia sin que tú lo hayas tocado.

¿Por qué? Porque si un atacante consigue entrar en tu servidor, lo primero que va a hacer es modificar archivos. Puede cambiar un binario del sistema, meter un backdoor en algún script, modificar la configuración de SSH para dejarse una puerta abierta… Si tú tienes un sistema que detecta esos cambios, te enteras rápido.

💡 AIDE Advanced Intrusion Detection Environment. Herramienta que crea una base de datos con las huellas digitales (hashes) de los archivos de tu sistema y te avisa cuando algo cambia. Más info → es la herramienta que yo uso para esto:

# Instalar
sudo apt install aide

# Crear la base de datos inicial (tarda un rato)
sudo aideinit

# Mover la base de datos generada
sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

# Comprobar si algo ha cambiado
sudo aide --check

Después de inicializar AIDE, puedes configurar un cron diario que ejecute la comprobación y te mande el resultado por email. Si algún archivo crítico cambia y no has hecho nada, ya sabes que algo raro pasa.

Recuerda actualizar la base de datos de AIDE después de cada actualización legítima del sistema (sudo aide --update), porque si no te va a cantar cambios que son normales.

9. Endurecer los servicios de red

Para cualquier servicio que expongas a internet, dedícale tiempo a configurarlo bien. No te limites a instalarlo y dejarlo con la configuración por defecto.

Algunas reglas generales que yo sigo:

Los servidores web siempre con HTTPS y configuraciones TLS modernas. Nada de TLS 1.0 o 1.1, eso ya está más muerto que el tato. Usa Mozilla SSL Configuration Generator para generar una configuración sólida
Las bases de datos no deberían escuchar en interfaces públicas nunca, a no ser que sea estrictamente necesario. Si tu app y tu BD están en el mismo servidor, que escuche solo en 127.0.0.1
Los frameworks y aplicaciones deben correr con los mínimos privilegios posibles

# MariaDB / MySQL: escuchar solo en localhost
# En /etc/mysql/mariadb.conf.d/50-server.cnf
bind-address = 127.0.0.1

# Nginx: headers de seguridad básicos
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Y algo que mucha gente no hace: lee la documentación de seguridad de cada servicio que despliegas. PostgreSQL tiene su sección de seguridad. Nginx tiene la suya. Docker tiene la suya. Cada uno tiene sus particularidades y sus mejores prácticas.

Tu checklist de blindaje

¿Cuántos de estos pasos tienes ya hechos en tu servidor? Marca los que tengas y mira cómo de blindado andas. El progreso se guarda en tu navegador, así que puedes volver cuando quieras.

0/9 — 0% blindado

Instalar solo lo mínimo imprescindible y revisar puertos abiertos
Desactivar login como root por SSH y usar solo claves
Cambiar el puerto SSH por defecto e instalar Fail2Ban
Configurar firewall (UFW) con política deny por defecto
Activar actualizaciones automáticas de seguridad
Aplicar el principio del mínimo privilegio (no correr servicios como root)
Monitorizar logs con Logwatch o similar
Configurar backups automáticos siguiendo la regla 3-2-1
Endurecer servicios de red (HTTPS, headers de seguridad, bind a localhost)

Reflexión final

La seguridad perfecta no existe, si alguien con recursos suficientes quiere entrar en tu servidor, probablemente acabe encontrando la manera. Pero eso no es excusa para no hacer nada.

Lo que sí existe es una seguridad razonable. Y se consigue haciéndote estas tres preguntas con cada cosa que montas:

🤔 ¿Necesita correr?

Si un servicio no tiene un motivo claro para estar ahí, no debería estar.

👤 ¿Quién necesita acceso?

Cuanta menos gente tenga acceso a un recurso, menos riesgo hay.

💥 ¿Qué pasa si lo revientan?

Piensa en el peor caso y prepárate: backups, privilegios mínimos, logs.

No te rayes con herramientas superavanzadas ni con configuraciones de la NASA. Haz bien las cosas básicas que te he contado aquí y ya vas a estar por delante del 95% de servidores que hay en internet. De verdad, la mayoría de brechas son por cosas ridículamente simples.

EA, pos eso. Aplícate el cuento y nos vemos en los bares!

Pon a prueba lo aprendido

1. ¿Cuál es el primer paso que deberías hacer tras instalar un servidor Linux?

2. ¿Por qué se desactiva el login como root por SSH?

3. ¿Qué hace Fail2Ban?

4. ¿Cuál es la política correcta de firewall por defecto?

5. ¿Qué significa la regla de backup 3-2-1?