Refuerzo de la seguridad del servidor de producción: una lista de verificación completa

El tiempo promedio para identificar una vulneración de datos es de 204 días. El refuerzo del servidor de producción reduce la superficie de ataque para que las vulneraciones sean más difíciles de iniciar y más rápidas de detectar. Esta guía cubre las medidas de seguridad concretas que todo servidor de producción debe implementar, desde la configuración SSH hasta los firewalls de aplicaciones web.

Conclusiones clave

• La autenticación solo con clave SSH y los puertos no estándar bloquean el 99% de los ataques automatizados de fuerza bruta
• Un firewall configurado correctamente reduce la superficie de ataque de miles de puntos de entrada a menos de diez
• Los firewalls de aplicaciones web bloquean la inyección SQL, XSS y otros ataques OWASP Top 10 en la capa de red
• La aplicación de parches automatizados garantiza que las vulnerabilidades se solucionen a las pocas horas de su divulgación, no semanas

---

Endurecimiento SSH

Configuración

# /etc/ssh/sshd_config

# Disable password authentication
PasswordAuthentication no
ChallengeResponseAuthentication no

# Disable root login
PermitRootLogin no

# Use SSH keys only
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

# Limit login attempts
MaxAuthTries 3
MaxSessions 5

# Set idle timeout (5 minutes)
ClientAliveInterval 300
ClientAliveCountMax 0

# Restrict SSH to specific users
AllowUsers deploy ubuntu

# Disable X11 forwarding
X11Forwarding no

# Use only strong algorithms
KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256
Ciphers [email protected],[email protected],[email protected]
MACs [email protected],[email protected]

Fail2Ban

# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600

[nginx-http-auth]
enabled = true
filter = nginx-http-auth
logpath = /var/log/nginx/error.log
maxretry = 5
bantime = 3600

---

Configuración del cortafuegos

UFW (Ubuntu)

# Reset and set default policies
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow SSH (consider changing port)
sudo ufw allow 22/tcp

# Allow HTTP/HTTPS
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Allow specific IPs for management
sudo ufw allow from 203.0.113.10 to any port 9090 comment "Grafana"
sudo ufw allow from 203.0.113.10 to any port 9093 comment "Alertmanager"

# Deny everything else (implicit with default deny)
sudo ufw enable
sudo ufw status verbose

Grupos de seguridad de AWS

# Terraform security group
resource "aws_security_group" "app" {
  name_prefix = "app-"
  vpc_id      = aws_vpc.main.id

  # Allow HTTPS from anywhere
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
    description = "HTTPS from internet"
  }

  # Allow SSH from office IP only
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["203.0.113.0/24"]
    description = "SSH from office"
  }

  # Allow all outbound
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

# Database security group - no public access
resource "aws_security_group" "db" {
  name_prefix = "db-"
  vpc_id      = aws_vpc.main.id

  ingress {
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.app.id]
    description     = "PostgreSQL from app servers only"
  }
}

---

Encabezados de seguridad de Nginx

# Security headers for all responses
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; connect-src 'self' https://api.example.com;" always;

# Hide server version
server_tokens off;

# Limit request size
client_max_body_size 10m;

# Rate limiting
limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=api:10m rate=30r/s;
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

server {
    location / {
        limit_req zone=general burst=20 nodelay;
    }

    location /api/ {
        limit_req zone=api burst=50 nodelay;
    }

    location /auth/ {
        limit_req zone=login burst=3 nodelay;
    }
}

---

Configuración SSL/TLS

# Modern TLS configuration
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers off;

# OCSP stapling
ssl_stapling on;
ssl_stapling_verify on;

# Session configuration
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;

# Certificate (Let's Encrypt)
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Renovación automatizada de certificados

# /etc/cron.d/certbot
0 0,12 * * * root certbot renew --quiet --post-hook "nginx -s reload"

---

Seguridad de contenedores

Si ejecuta Docker en producción, aplique estas medidas de refuerzo adicionales:

Seguridad del demonio Docker

{
  "userns-remap": "default",
  "no-new-privileges": true,
  "live-restore": true,
  "userland-proxy": false,
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Restricciones de tiempo de ejecución del contenedor

# docker-compose.yml security settings
services:
  api:
    security_opt:
      - no-new-privileges:true
    read_only: true
    tmpfs:
      - /tmp
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE

Principios clave:

• Elimine todas las capacidades y vuelva a agregar solo lo que sea necesario
• Sistema de archivos de sólo lectura evita que los atacantes modifiquen el contenido del contenedor
• No hay privilegios nuevos evita la escalada de privilegios dentro de los contenedores
• Usuario no root en Dockerfile (consulte nuestra guía de implementación de Docker)

Seguridad de imagen

• Utilice imágenes base oficiales y mínimas (variantes alpinas)
• Anclar versiones de imágenes (nunca use :latest en producción)
• Escanear imágenes en busca de vulnerabilidades con Trivy o Grype
• Firmar imágenes con Docker Content Trust
• Utilice un registro privado con controles de acceso

---

Seguridad de la base de datos

Endurecimiento de PostgreSQL

# postgresql.conf security settings
listen_addresses = 'localhost'        # Only listen on localhost
ssl = on                              # Require SSL for connections
ssl_cert_file = '/path/to/server.crt'
ssl_key_file = '/path/to/server.key'
password_encryption = scram-sha-256   # Modern password hashing
log_connections = on                  # Log all connections
log_disconnections = on               # Log disconnections
log_statement = 'ddl'                 # Log DDL statements

# pg_hba.conf - restrict connections
# TYPE  DATABASE  USER  ADDRESS      METHOD
local   all       all                scram-sha-256
host    all       all   10.0.0.0/8   scram-sha-256
hostssl all       all   0.0.0.0/0    scram-sha-256

• Nunca expongas PostgreSQL a la Internet pública.
• Utilice usuarios de bases de datos dedicados con los permisos mínimos requeridos
• Habilitar el cifrado de conexión (SSL)
• Establecer políticas de contraseñas seguras
• Verificación periódica de la copia de seguridad (consulte nuestra guía de recuperación ante desastres)

---

Detección de intrusiones

Configuración OSSEC

<!-- /var/ossec/etc/ossec.conf -->
<ossec_config>
  <syscheck>
    <!-- Monitor critical files for changes -->
    <directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
    <directories check_all="yes">/opt/app/dist</directories>

    <!-- Ignore frequently changing files -->
    <ignore>/etc/mtab</ignore>
    <ignore>/etc/resolv.conf</ignore>

    <!-- Run integrity check every 6 hours -->
    <frequency>21600</frequency>
  </syscheck>

  <rootcheck>
    <rootkit_files>/var/ossec/etc/shared/rootkit_files.txt</rootkit_files>
    <rootkit_trojans>/var/ossec/etc/shared/rootkit_trojans.txt</rootkit_trojans>
  </rootcheck>
</ossec_config>

Servicio de guardia de AWS

resource "aws_guardduty_detector" "main" {
  enable = true

  datasources {
    s3_logs {
      enable = true
    }
    kubernetes {
      audit_logs {
        enable = true
      }
    }
  }
}

---

Parches de seguridad automatizados

# Ubuntu: Enable unattended security updates
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

# /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";
Unattended-Upgrade::Mail "[email protected]";

---

Lista de verificación de refuerzo de seguridad

Nivel de servidor

• [] Autenticación solo con clave SSH, inicio de sesión raíz deshabilitado
• [] Firewall configurado con política de denegación por defecto
• [] Fail2Ban activo en SSH y servidor web
• [] Actualizaciones de seguridad automáticas habilitadas
• Servicios no esenciales deshabilitados
• Monitoreo de integridad de archivos (OSSEC o equivalente)
• [] Registro de auditoría habilitado (auditd)

Nivel de aplicación

• [] TLS 1.2+ en todos los puntos finales, HSTS habilitado
• [] Cabeceras de seguridad configuradas (CSP, X-Frame-Options, etc.)
• [] Limitación de velocidad en todos los puntos finales públicos
• [] Validación de entradas y consultas parametrizadas (no sql.raw())
• [] HttpOnly, cookies seguras para autenticación
• [] CORS restringido a orígenes conocidos
• [] Las respuestas de error no filtran rastros de pila

Nivel de red

• [] Base de datos no accesible públicamente
• Servicios internos en subredes privadas
• [] Puntos finales de VPC para servicios de AWS (sin Internet público)
• [] WAF en puntos finales públicos
• [] Protección DDoS (Cloudflare, AWS Shield)

Monitoreo

• [] Alerta de eventos de seguridad configurada
• [] Retención de registros durante al menos 90 días
• [] Intentos fallidos de autenticación monitoreados
• [] Patrones de tráfico inusuales detectados

---

Preguntas frecuentes

¿Con qué frecuencia debemos realizar auditorías de seguridad?

Escaneos automatizados trimestrales (análisis de vulnerabilidades, auditorías de dependencia) y pruebas de penetración manuales anuales. Las aplicaciones de alto riesgo (procesamiento de pagos, datos de atención médica) deben someterse a pruebas de penetración externas cada 6 meses. Cada implementación de producción debe incluir un escaneo de seguridad automatizado en el proceso de CI/CD. Consulte nuestra guía de mejores prácticas de CI/CD.

¿Es necesario un WAF si ya tenemos un límite de velocidad?

Sí. La limitación de tasas previene el abuso pero no inspecciona el contenido de la solicitud. Un WAF bloquea la inyección SQL, XSS y otros ataques a la capa de aplicación mediante el análisis de las cargas útiles de las solicitudes. Piense en la limitación de velocidad como protección contra inundaciones y en WAF como inspección de contenido: necesita ambos.

¿Cómo protegemos un servidor de producción de Odoo?

Además del endurecimiento general anterior: deshabilite el administrador de la base de datos en producción (list_db = False), establezca un admin_passwd fuerte, use dbfilter para restringir el acceso a la base de datos, ejecute Odoo detrás de Nginx (nunca exponga Odoo directamente) y mantenga Odoo y todos los módulos actualizados. ECOSIRE proporciona refuerzo de seguridad de Odoo como parte de nuestros servicios de alojamiento administrado.

¿Cuál es la medida de seguridad más impactante?

Habilitar MFA (autenticación multifactor) en todas las cuentas administrativas. Este control único previene el 99% de los ataques basados ​​en credenciales. Implemente MFA en SSH (a través de PAM), la consola de AWS, las herramientas de administración de bases de datos y los paneles de administración de aplicaciones antes de cualquier otra medida de refuerzo.

---

¿Qué viene después?

El refuerzo de la seguridad es una práctica continua. Combínelo con monitoreo y alertas para detección, recuperación ante desastres para resiliencia y escaneo de seguridad CI/CD para prevención.

Comuníquese con ECOSIRE para obtener asesoramiento sobre fortalecimiento de la seguridad, o explore nuestra guía DevOps para obtener la hoja de ruta completa de infraestructura.

---

Publicado por ECOSIRE: ayuda a las empresas a proteger la infraestructura de producción.