Lista de verificación de seguridad para los primeros 30 minutos de un servidor dedicado
Un servidor bare-metal recién entregado suele tener una dirección IPv4 pública, una contraseña inicial de root y servicios que aún no han sido revisados. Trate el primer inicio de sesión como un evento de aprovisionamiento: registre el hardware, actualice el sistema operativo, cree un administrador que no sea root, instale claves SSH, restrinja el acceso de red y confirme que el acceso de recuperación funciona.
Esta guía utiliza Ubuntu Server 22.04 o 24.04 LTS. Los comandos se ejecutan como root salvo que se indique lo contrario. Mantenga abierta su sesión SSH original hasta haber probado una segunda sesión con la nueva cuenta de administrador. Si su proveedor ofrece IPMI, iDRAC, iLO u otra consola fuera de banda, confirme que sea accesible únicamente mediante una VPN, direcciones IP incluidas en una lista de permitidas o una red de administración independiente.
Requisitos previos y requisitos mínimos del servidor
- Un servidor dedicado con Ubuntu Server 22.04 o 24.04 LTS instalado.
- Al menos 4 núcleos físicos de CPU, 16 GB de RAM y 240 GB de SSD NVMe para un servidor de producción pequeño que ejecute una aplicación web, una pila de monitorización o varios servicios autoalojados.
- Un equipo local con un cliente SSH, como OpenSSH en Linux, macOS o Windows PowerShell.
- La dirección IPv4 de su servidor, las credenciales iniciales de root y los detalles de acceso a consola o administración remota.
- Una dirección IP pública estática y estable para su estación de trabajo de administración si planea restringir SSH por IP de origen.
Un VPS con 2 vCPU, 4 GB de RAM y 80 GB NVMe es suficiente para un único servicio de poco tráfico o un punto de acceso VPN. Elija alojamiento dedicado o bare-metal para actividad sostenida de bases de datos, ejecutores de compilación, servidores de juegos, streaming, virtualización o cargas de trabajo que requieran CPU, E/S de disco y aislamiento de inquilinos predecibles.
Elija hardware para la carga de trabajo que protegerá
Los controles de seguridad usan relativamente poca CPU, pero la retención de registros, las copias de seguridad, la monitorización, las bases de datos y el tráfico de aplicaciones determinan la capacidad de producción. Las cifras siguientes asumen Linux, almacenamiento NVMe, copias de seguridad diarias en almacenamiento independiente y tráfico estándar de aplicaciones web.
Conclusión: comience con 4 núcleos, 16 GB de RAM y 240 GB NVMe para hasta aproximadamente 50 usuarios activos; después, aumente la RAM y la capacidad NVMe antes de que una carga de trabajo de base de datos o CI alcance una contención sostenida de disco.
| Usuarios activos simultáneos de la aplicación | vCPU / núcleos de CPU | RAM | Disco | Ancho de banda mensual |
|---|---|---|---|---|
| Hasta 50 usuarios; sitio web pequeño, VPN, monitorización o 1-2 aplicaciones autoalojadas | 4 núcleos físicos | 16 GB | 240 GB NVMe | 2 TB |
| 50-500 usuarios; aplicación web con PostgreSQL, relay de correo o ejecutor CI/CD pequeño | 8 núcleos físicos | 32 GB | 480 GB NVMe | 5 TB |
| 500-3.000 usuarios; plataforma respaldada por base de datos, nodos de juego, origen de streaming o varios ejecutores de compilación | 16 núcleos físicos | 64 GB | 2 x 960 GB NVMe en RAID 1 | 10 TB |
1. Registre el estado del servidor y aplique actualizaciones
Inicie sesión utilizando las credenciales de entrega e inspeccione el host antes de modificarlo. Guarde la salida en su gestor de contraseñas o documentación de infraestructura. Compruebe el sistema operativo, la disposición de los discos, los servicios activos en escucha y las actualizaciones de seguridad disponibles.
hostnamectl
uname -a
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
free -h
ss -tulpn
apt update
apt full-upgrade -y
rebootDespués del reinicio, vuelva a conectarse y verifique que el host ejecuta el kernel esperado:
uptime
uname -r
apt autoremove --purge -yNo instale paquetes de aplicaciones antes de aplicar parches. Una imagen nueva puede contener correcciones para OpenSSH, el kernel de Linux, OpenSSL, sudo u otros componentes expuestos.
2. Cree un administrador identificado e instale una clave SSH
La administración diaria debe usar una cuenta identificada con privilegios sudo, no la cuenta root. En su equipo local, genere una clave SSH Ed25519 si todavía no tiene una:
ssh-keygen -t ed25519 -a 100 -C "[email protected]"Desde su equipo local, copie la clave pública a la nueva cuenta. Sustituya adminuser y SERVER_IP.
ssh-copy-id adminuser@SERVER_IPSi la cuenta aún no existe, créela primero en el servidor:
adduser adminuser
usermod -aG sudo adminuser
install -d -m 700 -o adminuser -g adminuser /home/adminuser/.ssh
nano /home/adminuser/.ssh/authorized_keys
chmod 600 /home/adminuser/.ssh/authorized_keys
chown adminuser:adminuser /home/adminuser/.ssh/authorized_keysPegue una línea completa de clave pública en authorized_keys. Abra una segunda terminal y pruebe el nuevo inicio de sesión antes de cambiar la configuración SSH:
ssh adminuser@SERVER_IP
sudo -v
whoamiEl comando final debe devolver root después de sudo -i, o el nombre de su cuenta sin él. No continúe si el inicio de sesión con clave falla.
3. Refuerce OpenSSH sin perder el acceso
Cree una configuración SSH independiente en un archivo drop-in en lugar de editar el archivo del proveedor. Esto facilita la revisión de futuras actualizaciones de paquetes. El ejemplo mantiene SSH en el puerto 22; cambiar el puerto puede reducir el ruido en los registros, pero no sustituye la autenticación mediante clave ni las restricciones del firewall.
cat > /etc/ssh/sshd_config.d/99-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no
X11Forwarding no
MaxAuthTries 3
LoginGraceTime 30
AllowUsers adminuser
EOF
sshd -t
systemctl reload sshMantenga abierta la sesión existente. Desde una nueva terminal, verifique que la clave funciona y que se rechazan los inicios de sesión de root y con contraseña:
ssh -o PreferredAuthentications=publickey adminuser@SERVER_IP
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no adminuser@SERVER_IPLa prueba de contraseña debe fallar. Si no falla, inspeccione la configuración SSH efectiva con:
sshd -T | grep -E 'permitrootlogin|passwordauthentication|kbdinteractiveauthentication|allowusers'4. Configure un firewall de denegación predeterminada
UFW es adecuado para un único servidor dedicado. Permita primero SSH y luego autorice solo los puertos utilizados por los servicios que realmente pretende ejecutar. Para un servidor web típico, se necesitan TCP 80 y 443; PostgreSQL en el puerto 5432 normalmente debe permanecer privado y no debe abrirse a Internet.
apt install -y ufw
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status verbosePara una protección más sólida del plano de administración, permita SSH únicamente desde la dirección de salida fija de su oficina o VPN. Añada esta regla antes de eliminar la regla SSH amplia y pruebe desde esa red aprobada.
ufw allow from 203.0.113.25 to any port 22 proto tcp
ufw delete allow 22/tcp
ufw status numberedLos puertos publicados por Docker pueden omitir el comportamiento esperado de UFW porque Docker añade reglas nftables o iptables. Evite publicar puertos de bases de datos, Redis o administración con -p 0.0.0.0:PORT:PORT salvo que se requiera acceso público. Vincule los servicios privados a 127.0.0.1 o a una red interna y verifique la exposición con ss -tulpn.
5. Añada protección contra fuerza bruta y actualizaciones automáticas de seguridad
Las claves SSH eliminan la adivinación de contraseñas, pero fail2ban sigue reduciendo los intentos repetidos de autenticación y protege servicios futuros como la autenticación básica de Nginx. Instale fail2ban y active su jail de SSH:
apt install -y fail2ban unattended-upgrades
cat > /etc/fail2ban/jail.d/sshd.local <<'EOF'
[sshd]
enabled = true
maxretry = 5
findtime = 10m
bantime = 1h
EOF
systemctl enable --now fail2ban
fail2ban-client status sshdActive las actualizaciones automáticas de seguridad y luego revise la política generada. Las actualizaciones automáticas son útiles para la mayoría de los servidores de propósito único, pero las organizaciones con ventanas formales de cambio deberían aplicar parches mediante su proceso de gestión de configuración.
dpkg-reconfigure --priority=low unattended-upgrades
systemctl status unattended-upgrades --no-pager6. Proteja la cuenta del proveedor, la consola y el DNS
El refuerzo del sistema operativo no puede protegerle de un atacante que pueda restablecer el servidor, montar sus discos, modificar el DNS inverso o acceder a la consola remota. Use una contraseña única y MFA respaldada por hardware o mediante una aplicación autenticadora para el panel de control de alojamiento. Elimine las cuentas de antiguos empleados, restrinja los permisos de facturación y restablecimiento de servidores, y almacene los códigos de recuperación en un gestor de contraseñas cifrado.
Para IPMI, iDRAC o iLO, cambie inmediatamente la contraseña de administración entregada, instale las actualizaciones de firmware del proveedor durante una ventana de mantenimiento y no exponga públicamente su interfaz web. Si no dispone de una VLAN de administración privada, acceda a ella a través de una VPN WireGuard o una lista de permitidas por IP de origen.
7. Establezca registros, sincronización horaria y copias de seguridad
Una hora precisa hace posible SSH, TLS, la respuesta a incidentes y la correlación de registros. Confirme la sincronización NTP y el almacenamiento persistente del journal:
timedatectl set-ntp true
timedatectl status
mkdir -p /var/log/journal
systemctl restart systemd-journald
journalctl --disk-usageLas copias de seguridad deben estar separadas del servidor respaldado. Un espejo RAID 1 protege contra el fallo de un disco; no protege contra eliminación, ransomware, acceso root comprometido o un error a nivel de cuenta. Como mínimo, respalde diariamente los datos de aplicaciones y archivos de configuración en almacenamiento cifrado externo al servidor.
apt install -y restic
export RESTIC_REPOSITORY='s3:https://OBJECT_STORAGE_ENDPOINT/server-backup'
export RESTIC_PASSWORD='replace-with-a-long-unique-secret'
restic init
restic backup /etc /home /var/www
restic snapshotsColoque las credenciales del repositorio en un archivo de entorno legible por root o en un gestor de secretos, en lugar de en el historial de shell. Pruebe la restauración durante la primera semana:
mkdir -p /root/restore-test
restic restore latest --target /root/restore-test
ls -la /root/restore-test/etc8. Verifique la postura de seguridad final
Ejecute estas comprobaciones antes de desplegar aplicaciones. Identifican errores comunes como un puerto de base de datos abierto, un firewall inactivo, un servicio fail2ban fallido o una configuración SSH que todavía permite acceso root.
ufw status verbose
ss -tulpn
systemctl --failed
fail2ban-client status sshd
sshd -T | grep -E 'permitrootlogin|passwordauthentication'
last -a | head
journalctl -p 3 -xb --no-pagerDesde una red externa, escanee únicamente su propia dirección para confirmar que los puertos esperados están expuestos:
nmap -Pn -sV -p 22,80,443,5432 SERVER_IPUn servidor web normalmente debe mostrar solo los puertos 22, 80 y 443. Si el puerto 5432, 3306, 6379, 2375 o un puerto de panel de control aparece inesperadamente, detenga el servicio relacionado o restrínjalo a localhost o una red privada.
Solución de problemas comunes del primer día
SSH dejó de funcionar después del refuerzo
Use la consola del proveedor o su sesión SSH abierta existente. Compruebe la sintaxis con sshd -t, inspeccione la configuración cargada con sshd -T y confirme que la clave pública existe en /home/adminuser/.ssh/authorized_keys. Corrija la propiedad con chown -R adminuser:adminuser /home/adminuser/.ssh y los permisos con chmod 700 /home/adminuser/.ssh && chmod 600 /home/adminuser/.ssh/authorized_keys.
UFW bloqueó el acceso de administración
Use el acceso a consola fuera de banda y ejecute ufw status numbered. Añada la regla correcta específica por origen, por ejemplo ufw allow from 203.0.113.25 to any port 22 proto tcp. Evite desactivar el firewall de forma permanente; corrija la regla y pruebe una segunda conexión SSH.
Fail2ban bloqueó la IP de su oficina
Compruebe el jail con fail2ban-client status sshd y elimine el bloqueo usando fail2ban-client set sshd unbanip 203.0.113.25. Investigue la causa del inicio de sesión fallido antes de añadir su dirección a una lista de ignoradas.
El espacio en disco se llena después de activar registros o copias de seguridad
Revise el uso con df -h, journalctl --disk-usage y du -xhd1 /var | sort -h. Configure la retención del journal, rote los registros de aplicaciones y no almacene los archivos de copia de seguridad únicamente en el servidor de producción.