Jimmy

Academic

EvilCorp — Secure and Resilient Mail Infrastructure

A secure, resilient mail infrastructure designed and deployed as a two-person project — DNS, SMTP/IMAP, internal PKI and TLS, network segmentation, encrypted backups and high availability.

Completed
Diagram of two zones linked only by an IPsec tunnel between two strongSwan gateways. Corporate zone: Postfix and Dovecot mail under SELinux, Bind9 DNS, an internal OpenSSL certificate authority and Puppet; the mail server sends its Borg backups to the gateway, then through the tunnel to the backup service. Isolated backup zone with no direct routing: it holds an active/passive pair replicated with DRBD, with a Pacemaker-managed virtual IP and an encrypted Borg repository.
Implemented architectureSimplified, anonymized view of the implemented architecture: mail and DNS, PKI and TLS, an IPsec link reserved for backups, and active/passive backup storage with DRBD and Pacemaker. Addresses, host names and homelab hardware are deliberately left out.

My contribution

I led most of the design and technical integration: the virtualization layout, network segmentation, DNS, PKI and TLS, SELinux hardening, backups and high availability. I also designed or prepared the mail, replication and automation configurations, which my teammate helped roll out, and we built the IPsec tunnel together.

Highlights

  • Internal certificate authority, kept separate from the mail server, issuing its TLS certificate
  • SELinux hardening — contexts fixed, no AVC denials on the tested scenario
  • IPsec tunnel carrying only backup traffic, with no direct routing between zones
  • Active/passive backup storage replicated with DRBD, with a tested Pacemaker failover

Goal

Give a fictional company, EvilCorp, a complete and secure internal mail service, along with backups that are confidential, isolated and highly available. The infrastructure was actually deployed, on hardware from my homelab virtualized with Proxmox.

Architecture

The infrastructure is split into network zones separated by VLANs: a corporate zone hosting the services (DNS, certificate authority, Puppet, mail server, test client), an isolated backup zone, and a transit zone between the two. There is no direct routing between the corporate and backup zones: only backup traffic crosses an IPsec tunnel set up between two strongSwan gateways. Each service runs in its own virtual machine or container.

Mail and DNS

Bind9 is authoritative for the company domain: MX record, SPF, DKIM and DMARC records, and a reverse zone. Postfix handles sending and receiving (SMTP), Dovecot handles mailbox access (IMAP) and authentication. Executive addresses are aliases forwarded to the relevant users’ mailboxes.

PKI and TLS

The internal certificate authority, built with OpenSSL, runs on a dedicated machine, separate from the mail server: it issues the root certificate and then signs the mail server’s certificate. Dovecot requires TLS; Postfix offers STARTTLS and only accepts authentication over an encrypted connection. The IMAPS connection was validated end to end: trust chain verified, TLS 1.3 negotiated.

SELinux hardening: a diagnosis

The brief required SELinux in enforcing mode. During the first tests, Postfix could not create the users’ Maildir mailboxes: SELinux was denying access because the directories carried the wrong security context. Rather than loosening the policy, I fixed the contexts — a type meant for mailboxes, applied with restorecon — and declared a context for the certificate directory. On the tested scenario, including real messages being sent, no further AVC denials were logged.

Backup and high availability

Borg backs up the mail data to the backup zone as encrypted, deduplicated and compressed archives. The target storage runs on two nodes in an active/passive setup: DRBD replicates the volume from one to the other, and Pacemaker manages the volume, the file system and a virtual IP address. DRBD synchronization was validated, and a failover scenario was tested: when the active node is taken out, the resources move to the other node.

Automation

A Puppet server was set up to centralize the configuration of the Linux machines, with the goal of distributing the internal root certificate and system updates. The agents connect to the server and apply their catalog.

What is not published

The domain used is fictional. The addressing plan, machine names and homelab hardware are not detailed here.