Ciberseguridad en servidores de correo sobre Ubuntu: cómo atacan y cómo defenderse

Un servidor de correo combina tres cosas que lo vuelven atractivo: está expuesto a internet, guarda credenciales y suele ser la puerta de entrada a la identidad de toda la organización. Por eso aparece una y otra vez en los reportes de incidentes.

Por qué el correo es un blanco recurrente

El correo es el sistema que más usuarios toca y el que más servicios externos necesita: SMTP, IMAP, POP3, webmail, paneles de administración. Cada uno de esos servicios es una superficie de ataque, y muchos quedan expuestos sin que nadie lo note.

A esto se suma que una cuenta de correo comprometida no solo expone mensajes: permite restablecer contraseñas de otros sistemas, enviar campañas de fraude desde un dominio legítimo y moverse lateralmente dentro de la red.

Vectores de ataque más frecuentes

• Fuerza bruta y credential stuffing: intentos automatizados contra SSH, IMAP o el webmail, usando contraseñas filtradas de otros sitios.
• Relay abierto: una configuración permisiva de Postfix o Exim convierte el servidor en plataforma de spam y daña la reputación del dominio.
• Servicios de administración expuestos: paneles de webmail, interfaces de administración o puertos de base de datos accesibles desde internet.
• Software sin actualizar: vulnerabilidades conocidas en el servidor MTA, el motor de webmail o las librerías del sistema.
• Phishing y robo de sesión: el atacante no rompe el servidor, convence a un usuario de entregar sus credenciales.
• Malware en el puesto de trabajo: un equipo infectado puede leer el correo sincronizado sin tocar el servidor.

Medidas de endurecimiento en Ubuntu

Acceso y autenticación

• Deshabilitar el acceso directo de root por SSH y trabajar con claves, no con contraseñas.
• Activar autenticación de dos factores en el webmail y en las cuentas administrativas.
• Aplicar límites de intentos fallidos y bloqueos temporales por IP.
• Restringir el acceso a los servicios de correo por red o por VPN cuando el uso lo permita.

Configuración del servidor

• Verificar que el relay esté cerrado y que solo se acepte tráfico autenticado o de dominios propios.
• Exigir TLS en la entrega y en la consulta de buzones.
• Publicar y revisar registros SPF, DKIM y DMARC para reducir la suplantación del dominio.
• Mantener el firewall con política de denegación por defecto y solo los puertos necesarios abiertos.

Actualizaciones y monitoreo

• Aplicar parches de seguridad del sistema y del software de correo de forma periódica y planificada.
• Centralizar los registros de autenticación, MTA y webmail, y revisarlos con regularidad.
• Alertar sobre patrones anómalos: picos de envío, inicios de sesión desde ubicaciones nuevas, cambios en reglas de reenvío.
• Contar con respaldos probados de buzones y configuración, con restauración verificada.

Qué hacer ante un incidente

Si se detecta un compromiso, el orden importa: aislar el servicio afectado, rotar credenciales y claves, revisar reglas de reenvío y accesos creados por el atacante, y conservar la evidencia antes de reinstalar nada.

Después viene la parte que suele olvidarse: entender cómo entró el atacante y cerrar esa vía, porque de lo contrario el mismo acceso vuelve a funcionar semanas más tarde.

En resumen

La mayoría de los incidentes en servidores de correo no dependen de ataques sofisticados, sino de configuraciones heredadas, servicios expuestos y parches pendientes. Un inventario claro de lo que está publicado en internet y una rutina de actualización y revisión de registros eliminan buena parte del riesgo.