Jimmy

Scolaire

EvilCorp — infrastructure de messagerie sécurisée et résiliente

Conception et déploiement en binôme d'une messagerie sécurisée et résiliente — DNS, SMTP/IMAP, PKI interne et TLS, segmentation réseau, sauvegardes chiffrées et haute disponibilité.

Terminé
Schéma en deux zones reliées seulement par un tunnel IPSec entre deux passerelles strongSwan. Zone entreprise : messagerie Postfix et Dovecot sous SELinux, DNS Bind9, autorité de certification interne OpenSSL et Puppet ; le serveur de messagerie envoie ses sauvegardes Borg à la passerelle, puis au service de sauvegarde à travers le tunnel. Zone de sauvegarde isolée, sans routage direct : elle contient une paire actif / passif répliquée par DRBD, avec une IP virtuelle gérée par Pacemaker et un dépôt Borg chiffré.
Architecture mise en œuvreVue simplifiée et anonymisée de l'architecture mise en œuvre : messagerie et DNS, PKI et TLS, liaison IPSec réservée aux sauvegardes, et stockage de sauvegarde en actif / passif avec DRBD et Pacemaker. Adresses, noms de machines et matériel du homelab sont volontairement omis.

Ma contribution

J'ai assuré l'essentiel de la conception et de l'intégration technique de l'infrastructure : architecture de virtualisation, segmentation réseau, DNS, PKI et TLS, durcissement SELinux, sauvegarde et haute disponibilité. J'ai également conçu ou préparé les configurations de messagerie, de réplication et d'automatisation, mises en œuvre avec l'aide de mon binôme ; le tunnel IPSec a été réalisé ensemble.

Points clés

  • Autorité de certification interne, distincte du serveur mail, émettant son certificat TLS
  • Durcissement SELinux — contextes corrigés, aucun refus AVC sur le scénario testé
  • Tunnel IPSec réservé au flux de sauvegarde, sans routage direct entre les zones
  • Stockage de sauvegarde actif / passif répliqué par DRBD, bascule Pacemaker testée

Objectif

Fournir à une entreprise fictive, EvilCorp, une messagerie interne complète et sécurisée, et une sauvegarde de ses données à la fois confidentielle, isolée et hautement disponible. L’infrastructure a été réellement déployée, sur du matériel de mon homelab virtualisé avec Proxmox.

Architecture

L’infrastructure est découpée en zones réseau séparées par VLAN : une zone d’entreprise qui héberge les services (DNS, autorité de certification, Puppet, serveur mail, poste de test), une zone de sauvegarde isolée, et une zone de transit entre les deux. Aucun routage direct n’existe entre l’entreprise et la sauvegarde : seul le flux de sauvegarde traverse un tunnel IPSec établi entre deux passerelles strongSwan. Chaque service tourne dans sa propre machine virtuelle ou son propre conteneur.

Messagerie et DNS

Bind9 fait autorité sur le domaine de l’entreprise : enregistrement MX, enregistrements SPF, DKIM et DMARC, zone inverse. Postfix assure l’envoi et la réception (SMTP), Dovecot l’accès aux boîtes (IMAP) et l’authentification. Les adresses de la direction sont des alias redirigés vers les boîtes des utilisateurs concernés.

PKI et TLS

L’autorité de certification interne, construite avec OpenSSL, tourne sur une machine dédiée, distincte du serveur mail : elle émet le certificat racine puis signe le certificat du serveur de messagerie. Dovecot impose TLS ; Postfix propose STARTTLS et n’accepte l’authentification que sur une connexion chiffrée. La connexion IMAPS a été validée de bout en bout : chaîne de confiance vérifiée, TLS 1.3 négocié.

Durcissement SELinux : un diagnostic

Le cahier des charges imposait SELinux en mode Enforcing. Lors des premiers tests, Postfix ne parvenait pas à créer les boîtes Maildir des utilisateurs : SELinux refusait l’accès, car les répertoires portaient un contexte de sécurité inadapté. Plutôt que d’assouplir la politique, j’ai corrigé les contextes — un type prévu pour les boîtes mail, appliqué avec restorecon — et déclaré un contexte pour le répertoire des certificats. Sur le scénario de fonctionnement testé, envoi de messages réels compris, plus aucun refus AVC n’était journalisé.

Sauvegarde et haute disponibilité

Borg sauvegarde les données de messagerie vers la zone de sauvegarde, sous forme d’archives chiffrées, dédupliquées et compressées. Le stockage de destination repose sur deux nœuds en actif / passif : DRBD réplique le volume de l’un à l’autre, et Pacemaker pilote le volume, le système de fichiers et une adresse IP virtuelle. La synchronisation DRBD a été validée, et un scénario de bascule a été testé : lorsque le nœud actif est retiré, les ressources passent sur l’autre nœud.

Automatisation

Un serveur Puppet a été mis en place pour centraliser la configuration des machines Linux, avec pour objectif la diffusion du certificat racine interne et des mises à jour. Les agents se connectent au serveur et appliquent leur catalogue.

Ce qui n’est pas publié

Le domaine utilisé est fictif. Le plan d’adressage, les noms de machines et le matériel du homelab ne sont pas détaillés ici.