Cybersecurity on Ubuntu mail servers: how they attack and how to defend yourself

A mail server combines three things that make it attractive: it is exposed to the internet, it stores credentials, and it is often the gateway to the identity of the entire organization. That is why it appears again and again in incident reports.

Why email is a recurring target

Email is the system that the most users touch and the one that requires the most external services: SMTP, IMAP, POP3, webmail, administration panels. Each of those services is an attack surface, and many remain exposed without anyone noticing.

On top of this, a compromised email account does not only expose messages: it allows resetting passwords for other systems, sending fraud campaigns from a legitimate domain, and moving laterally within the network.

Most frequent attack vectors

• Brute force and credential stuffing: automated attempts against SSH, IMAP, or webmail, using passwords leaked from other sites.
• Open relay: a permissive Postfix or Exim configuration turns the server into a spam platform and damages the domain's reputation.
• Exposed administration services: webmail panels, administration interfaces, or database ports accessible from the internet.
• Unpatched software: known vulnerabilities in the MTA server, the webmail engine, or system libraries.
• Phishing and session theft: the attacker does not break into the server, but convinces a user to hand over their credentials.
• Malware on the workstation: an infected device can read synchronized email without touching the server.

Hardening measures on Ubuntu

Access and authentication

• Disable direct root access via SSH and work with keys, not passwords.
• Enable two-factor authentication in webmail and on administrative accounts.
• Apply failed attempt limits and temporary IP blocks.
• Restrict access to mail services by network or VPN when usage allows it.

Server configuration

• Verify that the relay is closed and that only authenticated traffic or traffic from your own domains is accepted.
• Require TLS for delivery and mailbox access.
• Publish and review SPF, DKIM, and DMARC records to reduce domain spoofing.
• Keep the firewall with a default deny policy and only the necessary ports open.

Updates and monitoring

• Apply security patches for the system and mail software periodically and on a planned basis.
• Centralize authentication, MTA, and webmail logs, and review them regularly.
• Alert on anomalous patterns: sending spikes, logins from new locations, changes to forwarding rules.
• Have tested backups of mailboxes and configuration, with verified restoration.

What to do in the event of an incident

If a compromise is detected, order matters: isolate the affected service, rotate credentials and keys, review forwarding rules and access created by the attacker, and preserve evidence before reinstalling anything.

Then comes the part that is often forgotten: understanding how the attacker got in and closing that path, because otherwise the same access will work again weeks later.

In summary

Most incidents on mail servers do not depend on sophisticated attacks, but on inherited configurations, exposed services, and pending patches. A clear inventory of what is published on the internet and a routine of updating and reviewing logs eliminate much of the risk.