Prioridades de seguridad de servidores dedicados durante los primeros 30 minutos
Un servidor bare-metal recién entregado puede tener una dirección IPv4 pública, credenciales predeterminadas de root y todos los puertos de red accesibles a menos que cambie la configuración. El primer objetivo no es el despliegue de aplicaciones: es establecer una ruta de administración segura sin bloquearse accidentalmente el acceso.
Complete estas acciones desde una estación de trabajo de confianza en una red privada. Mantenga abierta la consola del proveedor, IPMI, KVM-over-IP o el acceso a la consola de rescate hasta haber probado una segunda sesión SSH con la nueva cuenta y clave SSH. El acceso a la consola es el método de recuperación si falla un cambio de configuración de SSH, firewall o red.
Requisitos previos
- Un servidor dedicado que ejecute Ubuntu Server 24.04 LTS con acceso root o sudo.
- Una estación de trabajo con OpenSSH instalado. Linux y macOS lo incluyen; los usuarios de Windows pueden usar PowerShell o Windows Terminal.
- La dirección IPv4 de su servidor y, si está configurada, la dirección IPv6.
- Una dirección IP pública estática para su conexión de oficina o doméstica si planea restringir SSH por IP de origen.
- Al menos 4 núcleos físicos de CPU, 16 GB de RAM y 480 GB de almacenamiento SSD o NVMe para una pequeña carga de trabajo de producción en servidor dedicado. Las herramientas de seguridad usan poca capacidad, pero los servicios de producción, registros, instantáneas y copias de seguridad no.
No exponga una base de datos, API de Docker, Redis, Elasticsearch o panel de control a internet público durante la configuración inicial. Vincule los servicios privados a 127.0.0.1, una VLAN privada o una interfaz VPN a menos que se requiera explícitamente acceso público.
Dimensionamiento de producción después de la base de seguridad
Los controles de seguridad deben dejar suficiente espacio para registros del sistema, actualizaciones de paquetes, copias de seguridad, agentes de monitorización y los servicios que alojará el servidor. El siguiente dimensionamiento asume aplicaciones web de Linux, bases de datos, servidores de juegos, aplicaciones autoalojadas o ejecutores de CI con copias de seguridad remotas cifradas.
Un punto de partida útil es 4 núcleos, 16 GB de RAM y 480 GB de SSD para un pequeño servicio público; use más memoria y almacenamiento NVMe en espejo a medida que aumenten el volumen de solicitudes y la actividad de la base de datos.
| Solicitudes HTTP públicas por segundo | CPU | RAM | Disco | Ancho de banda mensual |
|---|---|---|---|---|
| Hasta 50 solicitudes/seg | 4 núcleos físicos | 16 GB | 480 GB SSD o NVMe | 5 TB |
| 50-300 solicitudes/seg | 8 núcleos físicos | 32 GB | 960 GB NVMe | 10 TB |
| 300-1.000 solicitudes/seg | 16 núcleos físicos | 64 GB | 2 × 1,92 TB NVMe en RAID 1 | 20 TB |
Para una única VPN ligera, nodo de monitorización o aplicación autoalojada de poco tráfico, un VPS con 2 vCPU, 4 GB de RAM y 80 GB NVMe puede ser más económico. Elija hardware dedicado para E/S sostenida de bases de datos, carga de CPU de servidores de juegos, grandes compilaciones de CI/CD, alto tráfico o cargas de trabajo que necesiten un aislamiento de hardware más sólido.
Paso 1: Registre el estado actual y actualice el sistema operativo
Inicie sesión usando las credenciales proporcionadas en la entrega. Confirme la distribución, los escuchas de red activos, la disposición de los discos y el historial de inicio de sesión actual antes de cambiar nada.
ssh root@SERVER_IP
hostnamectl
uname -a
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
ss -tulpn
last -a | head
apt update && apt -y full-upgrade
rebootVuelva a conectarse después del reinicio y confirme que se está ejecutando el kernel esperado:
ssh root@SERVER_IP
uname -r
apt autoremove -y
apt install -y sudo curl ca-certificates vim ufw fail2ban unattended-upgrades auditdRevise los puertos de escucha inesperados. Un servidor Ubuntu recién instalado normalmente solo tiene SSH en el puerto TCP 22. Si ss -tulpn muestra servicios que no instaló, identifique sus paquetes antes de eliminarlos. No detenga un agente de administración remota proporcionado por su proveedor sin confirmar que el acceso a la consola sigue disponible.
Paso 2: Cree un administrador con nombre e instale una clave SSH
La administración diaria debe usar una cuenta con nombre y sudo, no el inicio de sesión directo como root. En su estación de trabajo, cree una clave Ed25519 si aún no tiene una. Proteja la clave privada con una frase de contraseña.
ssh-keygen -t ed25519 -a 100 -C "admin@workstation"
ssh-copy-id root@SERVER_IPEl segundo comando copia temporalmente su clave pública a root. En el servidor, cree la cuenta de administrador y copie la clave autorizada en ella:
adduser admin
usermod -aG sudo admin
install -d -m 700 -o admin -g admin /home/admin/.ssh
cp /root/.ssh/authorized_keys /home/admin/.ssh/authorized_keys
chown admin:admin /home/admin/.ssh/authorized_keys
chmod 600 /home/admin/.ssh/authorized_keysAbra una segunda terminal y pruebe la nueva cuenta antes de modificar la configuración de SSH:
ssh admin@SERVER_IP
sudo -v
sudo whoamiEl comando final debe mostrar root. Mantenga abierta la sesión original de root hasta completar el Paso 4. Para equipos, proporcione a cada administrador una cuenta y clave independientes. No comparta una sola clave privada ni almacene claves en chats, tickets o archivos de contraseñas sin cifrar.
Paso 3: Configure un firewall de denegación predeterminada
UFW controla el tráfico entrante en el host. Permita primero SSH y, después, permita únicamente los servicios que sean intencionalmente públicos. Si su oficina tiene una IP pública fija, restringir SSH a esa dirección reduce los intentos de pulverización de contraseñas y explotación.
ufw default deny incoming
ufw default allow outgoing
ufw allow from YOUR_PUBLIC_IP to any port 22 proto tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status verboseReemplace YOUR_PUBLIC_IP por una dirección real como 203.0.113.10. Si su IP cambia con frecuencia, use ufw allow 22/tcp temporalmente y restrinja SSH más tarde mediante una VPN o una dirección de oficina estable. No habilite UFW hasta que exista una regla que permita SSH.
Para aplicaciones que necesitan UDP, agregue únicamente el puerto requerido. Por ejemplo, un servidor WireGuard normalmente necesita:
ufw allow 51820/udp
ufw status numberedNo use reglas amplias como ufw allow 1:65535/tcp. Un proxy inverso normalmente necesita TCP 80 y 443; PostgreSQL, MySQL, Redis y Docker no deben abrirse públicamente en despliegues ordinarios.
Paso 4: Refuerce SSH sin perder el acceso
Deshabilite el inicio de sesión de root y la autenticación por contraseña solo después de confirmar que el nuevo administrador puede iniciar sesión con una clave. Use un archivo de inclusión de SSH en lugar de editar directamente la configuración del proveedor.
cat > /etc/ssh/sshd_config.d/99-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
X11Forwarding no
MaxAuthTries 3
LoginGraceTime 30
AllowUsers admin
EOF
sshd -t
systemctl reload sshLa comprobación sshd -t no debe devolver ninguna salida. Abra una tercera terminal y verifique tanto el éxito esperado como el fallo esperado:
ssh -o PreferredAuthentications=publickey admin@SERVER_IP
ssh -o PreferredAuthentications=password admin@SERVER_IPEl comando basado en clave debe conectar; el comando de solo contraseña debe fallar. Si el inicio de sesión con clave falla, use la sesión de root aún abierta o la consola del proveedor, elimine el archivo de inclusión, ejecute systemctl reload ssh e inspeccione journalctl -u ssh -n 50.
Paso 5: Habilite la protección contra fuerza bruta y las actualizaciones automáticas de seguridad
Fail2ban lee los registros de autenticación y bloquea intentos fallidos repetidos. Es un complemento de las claves SSH y las restricciones de firewall, no un sustituto de ellas.
cat > /etc/fail2ban/jail.d/sshd.local <<'EOF'
[sshd]
enabled = true
backend = systemd
maxretry = 4
findtime = 10m
bantime = 1h
EOF
systemctl enable --now fail2ban
fail2ban-client status sshdHabilite las actualizaciones de seguridad desatendidas para que las vulnerabilidades conocidas reciban parches entre ventanas de mantenimiento:
dpkg-reconfigure -plow unattended-upgrades
systemctl enable --now apt-daily-upgrade.timer
systemctl status apt-daily-upgrade.timer --no-pagerRevise regularmente los requisitos de reinicio. Las actualizaciones del kernel y de bibliotecas de bajo nivel pueden requerir un reinicio programado incluso si los paquetes se instalaron correctamente:
test -f /var/run/reboot-required && cat /var/run/reboot-required || echo "No reboot required"Paso 6: Establezca registros, sincronización horaria y auditoría básica
La hora precisa hace posible la investigación de incidentes. Ubuntu usa systemd-timesyncd de forma predeterminada; verifique la sincronización y habilite el registro de auditoría para cambios en archivos y comandos privilegiados.
timedatectl status
systemctl enable --now auditd
systemctl status auditd --no-pager
auditctl -lInspeccione la actividad de autenticación con estos comandos:
journalctl -u ssh --since "30 minutes ago"
last -a | head -20
sudo ausearch -m USER_LOGIN --start todayPara servidores de producción, envíe los registros a un sistema independiente usando syslog, una plataforma de monitorización o un servicio de gestión de información y eventos de seguridad. Un atacante que obtiene acceso root puede alterar los registros locales; la retención fuera del servidor mejora la calidad de la evidencia.
Paso 7: Compruebe el estado del almacenamiento y cree un plan de copias de seguridad
RAID mejora la disponibilidad después de un fallo de disco, pero no es una copia de seguridad. Una base de datos eliminada, una aplicación comprometida o un evento de ransomware pueden replicarse inmediatamente en un espejo. Mantenga copias cifradas fuera del servidor y pruebe la restauración.
apt install -y smartmontools
smartctl -a /dev/sda | less
systemctl enable --now smartd
mkdir -p /root/backup-test
tar -czf /root/backup-test/etc-$(date +%F).tar.gz /etcLos nombres de dispositivos varían. Use lsblk para identificar los discos; los dispositivos NVMe normalmente aparecen como /dev/nvme0n1. Para los datos de aplicaciones, haga copias de seguridad de las bases de datos con herramientas nativas de la base de datos como pg_dump o mariadb-dump, y después envíe copias cifradas a una ubicación de almacenamiento independiente. Conserve varios puntos de restauración y realice una restauración de prueba al menos trimestralmente.
Paso 8: Verifique la superficie de ataque expuesta desde el exterior
Ejecute un escaneo de puertos desde su estación de trabajo después de configurar el firewall. El resultado debe mostrar únicamente los puertos que permitió deliberadamente.
nmap -Pn -sV -p 22,80,443,51820 SERVER_IP
curl -I http://SERVER_IP
sudo ufw status numbered
sudo fail2ban-client status sshdSi no hay un servidor web instalado, los puertos 80 y 443 pueden mostrarse como filtrados porque UFW permite el tráfico, pero nada escucha en esos puertos. Esto es aceptable durante la configuración; elimine las reglas de UFW hasta que se despliegue un proxy inverso o servicio web. Vuelva a comprobar los escuchas abiertos con ss -tulpn después de instalar Docker, un servidor de juegos, una pila de correo o un panel de control, ya que cada uno puede añadir nueva exposición.
Solución de problemas comunes durante los primeros 30 minutos
SSH dejó de funcionar después del refuerzo
Use el acceso a la consola del proveedor, valide la configuración con sshd -t e inspeccione journalctl -u ssh -n 100. Confirme que su clave pública está en /home/admin/.ssh/authorized_keys, que el modo del directorio es 700 y el modo del archivo es 600. Elimine AllowUsers admin si su nombre de inicio de sesión real es diferente.
UFW bloqueó su conexión
Desde la consola, ejecute ufw status numbered. Agregue la regla correcta usando ufw allow 22/tcp o su IP de origen correcta, y después elimine la regla equivocada con ufw delete NUMBER. Mantenga disponible el acceso a la consola para cada cambio remoto del firewall.
Fail2ban bloqueó la IP de su oficina
Compruebe la cárcel y elimine el bloqueo con:
fail2ban-client status sshd
fail2ban-client set sshd unbanip YOUR_PUBLIC_IPAgregue direcciones IP de administración de confianza a una lista ignoreip solo si son estables y están controladas. No incluya en listas blancas rangos amplios de ISP.
Las actualizaciones automáticas no se aplicaron
Compruebe la actividad del temporizador con systemctl list-timers apt-daily-upgrade.timer y revise /var/log/unattended-upgrades/unattended-upgrades.log. Confirme la conectividad DNS y HTTPS saliente antes de asumir que hay un problema con los paquetes.
Trabajo de seguridad después de los primeros 30 minutos
La base inicial es solo el comienzo. Añada un proxy inverso con configuraciones TLS actuales, despliegue monitorización para el uso de disco, carga, memoria, vencimiento de certificados y fallos de copias de seguridad, separe producción de desarrollo, aplique parches a las aplicaciones con rapidez y revise periódicamente usuarios, claves SSH, reglas de firewall y contenedores en ejecución. Para servidores de correo, sistemas de pago, datos sanitarios o cargas de trabajo reguladas, documente los controles de acceso y considere una revisión de seguridad independiente.