Server hardening básico para cargas de email — la configuración mínima que separa servidor expuesto de servidor preparado para producción

Un servidor de email es target atractivo para atacantes: si lo comprometen, pueden enviar spam desde IP con buena reputación durante horas antes de ser detectados, robar credenciales SMTP de los logs, o usar el servidor como pivot para acceder a otros sistemas. La configuración default de la mayoría de Linux distributions es razonable pero no suficiente para servidor expuesto a internet. Este post cubre el hardening básico — la configuración mínima viable que cualquier servidor de email serio debería tener antes de empezar a procesar tráfico de producción.

SSH — el primer punto de entrada

SSH es típicamente el primer vector de ataque. Configuración default permite password authentication, lo que abre la puerta a brute force. Hardening básico:

Deshabilitar password authentication completamente. Solo SSH key authentication. En /etc/ssh/sshd_config:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
ChallengeResponseAuthentication no
UsePAM no

Cambiar puerto SSH default. No es seguridad real (security by obscurity) pero reduce el ruido de intentos automatizados. Mover de puerto 22 a algo como 2222 reduce 90%+ de intentos de brute force aunque no protege contra atacante dirigido.

Restringir usuarios que pueden hacer SSH. Usar AllowUsers o AllowGroups para limitar a usuarios específicos:

AllowGroups sshusers
AllowUsers admin

Configurar SSH key con passphrase. La key SSH debe tener passphrase para que un atacante con acceso a la key tampoco entre directamente. Usar ssh-agent para no introducir passphrase en cada conexión.

Considerar 2FA en SSH. Para entornos sensibles, libpam-google-authenticator o equivalente añade segundo factor TOTP encima de SSH key.

Firewall — controlar qué entra y qué sale

Firewall restrictivo es base de la defensa. Para servidor de email típico, política por defecto: deny all, permitir explícitamente lo necesario.

Con ufw (Uncomplicated Firewall):

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp comment 'SSH'  # o el puerto custom
ufw allow 25/tcp comment 'SMTP inbound'
ufw allow 587/tcp comment 'SMTP submission'
ufw allow 465/tcp comment 'SMTPS implícito'
ufw allow 80/tcp comment 'HTTP - Let''s Encrypt cert renewal'
ufw allow 443/tcp comment 'HTTPS - admin web'
ufw enable

Lo que NO se debería permitir por defecto: cualquier puerto no relacionado con la función específica del servidor. SQL ports (3306, 5432), Redis (6379), Elasticsearch (9200) no deberían estar abiertos a internet — solo accesibles desde servidores específicos vía VPN o internal network.

Outbound restrictivo. Para casos sensibles, también restringir outbound — el servidor de email solo necesita conectar a puertos 25 (a otros MTAs) y outbound HTTPS para updates. Limitar outbound previene que un servidor comprometido conecte a servidores command-and-control de atacantes.

Fail2ban — bloqueo automático de intentos abusivos

Fail2ban monitorea logs y bloquea IPs que muestran patrones de ataque (varios intentos SSH fallidos, varios intentos SMTP AUTH fallidos, etc.). Configuración básica:

# /etc/fail2ban/jail.local
[DEFAULT]
bantime = 3600       # Bloquear por 1 hora
findtime = 600       # Ventana de 10 min para contar
maxretry = 5         # Máximo 5 intentos antes de bloquear
backend = systemd

[sshd]
enabled = true

[postfix-sasl]
enabled = true
port = smtp,submission,smtps
filter = postfix-sasl
logpath = /var/log/mail.log

[postfix-rbl]
enabled = true
filter = postfix-rbl
logpath = /var/log/mail.log

Esto bloquea automáticamente IPs que: hacen 5 intentos SSH fallidos en 10 minutos, 5 intentos SMTP AUTH fallidos, o intentan enviar desde IPs ya en blacklist conocida.

Para entornos con más actividad legítima, ajustar bantime y maxretry según patrones reales — bloquear demasiado agresivamente puede afectar usuarios legítimos.

Kernel updates y patch management

Vulnerabilidades del kernel y servicios system se descubren regularmente. Mantener actualizaciones es no opcional para servidor expuesto.

Unattended upgrades para security patches. En Debian/Ubuntu, unattended-upgrades configurado para aplicar security updates automáticamente:

# /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";

Esto aplica security updates automáticamente y reinicia a las 3 AM si requiere reboot. Para servidores con tráfico 24/7, considerar live kernel patching (Canonical Livepatch, KernelCare) que aplica patches sin reboot.

Subscripción a security advisories. Inscribirse en listas de seguridad de la distribución (debian-security-announce, ubuntu-security-announce, RHEL Security Advisories). Vulnerabilidades críticas reciben atención inmediata, no esperan al unattended-upgrades scheduled.

Separación de servicios — minimizar superficie de ataque

Servidor que solo hace email no debería tener instalado: bases de datos completas (PostgreSQL, MySQL), web servers innecesarios, scripting interpreters no usados, herramientas de desarrollo, compiladores en producción.

Cada servicio adicional es superficie de ataque. Servidor minimalista con solo MTA + dependencias necesarias es mucho más fácil de hardenificar y mantener.

Si alguna funcionalidad requiere base de datos (queue persistence, supresión storage), considerar:

• Base de datos en servidor separado, no en el mismo
• Versión minimalista (PostgreSQL configurado para uso específico, no instalación default con extensions)
• Acceso solo desde el MTA del mismo servidor (localhost, no exposed a network)

El principio: servidor de email hace email. Otras funciones en otros servidores. Aislar servicios protege en caso de compromiso parcial — atacante que entra al servidor de email no tiene acceso directo a la base de datos de aplicación.

Logging y monitoring de intrusion básico

Logs son la primera línea de detección post-incident. Sin logs adecuados, descubrir compromiso es ejercicio de adivinanza.

Logs centralizados. Enviar logs del servidor a logging service externo (Loki, ELK, Graylog, Splunk, Datadog Logs). Esto previene que atacante que comprometa el servidor borre logs locales — los logs ya están copiados externamente.

Auditd para tracking de comandos. auditd registra cada llamada de sistema sensible: ejecución de binaries, escrituras a archivos críticos, conexiones de network. Para análisis post-incident, dato invaluable.

OSSEC o Wazuh para HIDS (Host Intrusion Detection). Monitorea cambios en archivos críticos (configuration, binaries, certificates), detecta rootkits conocidos, alerta sobre patrones sospechosos. Open source y bien establecido.

Alertas sobre eventos críticos. Login SSH exitoso desde nueva IP, escalada a sudo por usuario no admin, modificación de /etc/passwd, instalación de paquete nuevo — eventos que en operación normal son raros y deberían generar alerta inmediata.

Configuración específica de Postfix para hardening

Postfix tiene varios settings que mejoran seguridad además de los defaults:

# /etc/postfix/main.cf

# Limitar message size para prevenir DoS
message_size_limit = 26214400  # 25 MB

# Limitar conexiones simultáneas por IP origen
smtpd_client_connection_count_limit = 10
smtpd_client_connection_rate_limit = 30
smtpd_client_message_rate_limit = 100

# Restricciones de envío
smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    reject_rbl_client zen.spamhaus.org,
    reject_rbl_client bl.spamcop.net

# Helo correcto requerido
smtpd_helo_required = yes
smtpd_helo_restrictions =
    permit_mynetworks,
    reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname

# TLS robusto (cubierto en otro post)
smtpd_tls_security_level = may
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

Esto previene varios ataques comunes: DoS por mensajes muy grandes, abuse por exceso de conexiones desde una IP, relay abierto (envío anonymous a destinos arbitrarios), spam desde IPs ya conocidas como problemáticas.

Backups que sobreviven al compromiso

Backups en el mismo servidor o en infraestructura accesible desde el mismo servidor son inútiles si el servidor se compromete — el atacante los borra o cifra (ransomware típico).

Backups robustos: copias en infraestructura completamente separada (otro provider cloud, off-site storage), inmutables (no se pueden borrar desde el servidor), regulares (al menos diarios para configuración crítica), testeados (verificar restore funciona, no solo que el backup se hizo).

Para servidor de email, lo crítico a backup: configuración (/etc/postfix, /etc/opendkim, certificados TLS, configuración fail2ban), tabla de supresión, queue persistente si aplica, logs históricos (si auditoría retroactiva puede necesitarse).

Hardening básico no es producto único — es proceso continuo. Configuración inicial bien hecha protege durante meses; mantenimiento regular (updates, revisión de logs, ajustes según nuevos vectores conocidos) protege durante años. La inversión es modesta vs el coste de un compromiso serio que afecta deliverability, reputación de marca, y potencialmente expone datos de clientes.