Comment sécuriser le serveur de messagerie contre le piratage avec VPN (CentOS/RHEL)

Dans ce tutoriel, je vais partager avec vous mes trucs et astuces pour sécuriser les serveurs de messagerie CentOS/RHEL contre le piratage avec un serveur VPN auto-hébergé. De nombreux spammeurs tentent de pirater les serveurs de messagerie d'autres personnes. En cas de succès, ils utiliseraient le serveur de messagerie piraté pour envoyer de gros volumes de spam ou voler des données précieuses. Pourquoi utilisons-nous un serveur VPN auto-hébergé ? Parce qu'il vous permet d'activer la liste blanche, de sorte que seuls les utilisateurs de confiance connectés au serveur VPN peuvent accéder à votre serveur de messagerie.

Prérequis

Il est supposé que vous disposez d'un serveur de messagerie opérationnel. Sinon, suivez l'un des tutoriels ci-dessous pour configurer votre propre serveur de messagerie.

Comment configurer facilement un serveur de messagerie complet sur CentOS 8 avec iRedMail

Il est également supposé que vous avez configuré un serveur VPN . Si ce n'est pas le cas, veuillez suivre l'un des tutoriels ci-dessous. Le serveur de messagerie et le serveur VPN peuvent s'exécuter sur des hôtes distincts ou sur le même hôte.

Configurez votre propre serveur VPN WireGuard sur CentOS

Astuce :Il est recommandé d'exécuter le serveur VPN et le serveur de messagerie sur des hôtes distincts pour réduire les complexités opérationnelles . Si le serveur de messagerie et le serveur VPN s'exécutent sur le même hôte, des étapes supplémentaires sont nécessaires, à savoir la configuration d'une zone de stratégie de réponse sur le serveur VPN pour remplacer l'enregistrement DNS A public du nom d'hôte de votre serveur de messagerie.

Configurer la zone de stratégie de réponse (RPZ) dans le résolveur BIND sur CentOS/RHEL

Disons l'enregistrement DNS A pour mail.yourdomain.com se résout en 12.34.56.78 , vous devez alors créer un enregistrement dans la zone de stratégie de réponse pour le résoudre en adresse IP privée du serveur VPN 10.10.10.1 .

Dans les textes suivants, j'utilise 12.34.56.78 comme adresse IP publique du serveur VPN. Si le serveur VPN et le serveur de messagerie fonctionnent sur le même hôte, vous devez remplacer 12.34.56.78 avec l'adresse IP privée du serveur VPN 10.10.10.1 .

Étape 1 :Ajoutez l'adresse IP du serveur VPN à la liste blanche du pare-feu

Une fois que vous avez un serveur de messagerie et un serveur VPN opérationnels, vous devez ajouter l'adresse IP du serveur VPN à la liste blanche du pare-feu du serveur de messagerie. Si vous utilisez Firewalld (CentOS/RHEL), exécutez la commande suivante sur le serveur de messagerie. Remplacez 12.34.56.78 par l'adresse IP du serveur VPN.

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="12.34.56.78" accepter'

Vous pouvez également mettre en liste blanche les adresses IP de vos autres serveurs. Par exemple, certaines personnes peuvent avoir un autre serveur Web qui doit envoyer des e-mails via le serveur de messagerie. Ensuite, ajoutez-le également dans la liste blanche.

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="IP-address-of-the-other-web-server" accept'

Rechargez firewalld pour que les modifications prennent effet.

sudo systemctl recharger le pare-feu

Étape 2 :Fermez le port de soumission, le port IMAP et le port POP3

Port de soumission :587 et 465
Port IMAP :143 et 993
Port POP3 :110 et 995

Les ports 587 et 465 sont utilisés par des clients de messagerie tels que Mozilla Thunderbird et Microsoft Outlook pour envoyer des e-mails sortants. Des acteurs malveillants peuvent lancer une attaque par force brute sur les ports 587 et 465.

Voici un exemple trouvé dans mon journal de messagerie (/var/log/maillog sur CentOS/RHEL). Le mauvais acteur essayait de se connecter, mais échouait à chaque fois à l'authentification SASL.

postfix/smtps/smtpd[18071] :connexion TLS anonyme établie à partir d'inconnu[92.118.38.56] :TLSv1.2 avec le chiffrement ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)postfix/smtps/smtpd[ 18071] :avertissement :inconnu[92.118.38.56] :échec de l'authentification SASL LOGIN :UGFzc3dvcmQ6postfix/smtps/smtpd[18071] :connexion perdue après AUTH de l'inconnu[92.118.38.56]postfix/smtps/smtpd[18071] :déconnexion de l'inconnu[ 92.118.38.56] ehlo=1 auth=0/1 rset=1 command=2/3postfix/smtps/smtpd[18071] :connexion depuis inconnu[92.118.38.56]postfix/smtps/smtpd[18071] :connexion TLS anonyme établie depuis inconnu[92.118.38.56] : TLSv1.2 avec le chiffrement ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)postfix/smtps/smtpd[18071] : avertissement :inconnu[92.118.38.56] :l'authentification SASL LOGIN a échoué :UGFzc3dvcmQ6postfix/smtps/smtpd[18071] :connexion perdue après AUTH depuis inconnu[92.118.38.56]postfix/smtps/smtpd[18071] :déconnexion depuis inconnu[92.118.38.56] ehlo=1 auth=0/1 rset=1 commandes=2/3postfix/smtps/smtpd[18071] :se connecter depuis un inconnu n[92.118.38.56]postfix/smtps/smtpd[18071] :connexion TLS anonyme établie à partir d'inconnu[92.118.38.56] :TLSv1.2 avec chiffrement ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)postfix/smtps /smtpd[18071] :avertissement :inconnu[92.118.38.56] :échec de l'authentification SASL LOGIN :UGFzc3dvcmQ6postfix/smtps/smtpd[18071] :connexion perdue après AUTH depuis inconnu[92.118.38.56]postfix/smtps/smtpd[18071] :déconnexion from unknown[92.118.38.56] ehlo=1 auth=0/1 rset=1 command=2/3

Je ne veux pas voir ce genre d'activité dans mon journal de messagerie, donc je ferme simplement les ports 587, 465, 143, 993, 110 et 995 dans le pare-feu. Et comme l'adresse IP de mon serveur VPN est sur liste blanche, seuls les utilisateurs connectés à mon serveur VPN peuvent accéder à ces ports.

Sur CentOS/RHEL, exécutez les deux commandes suivantes pour désactiver imap , imaps , smtp-submission , smtps , pop3 et pop3s services.

sudo firewall-cmd --permanent --remove-service={smtp-submission,smtps,imap,imaps,pop3,pop3s}sudo firewall-cmd --permanent --remove-port={587/tcp,465 /tcp,143/tcp,993/tcp,110/tcp,995/tcp}

Si vous voyez un avertissement du type Warning: NOT_ENABLED: smtps , vous pouvez ignorer l'avertissement. Rechargez firewalld pour que les modifications prennent effet.

sudo systemctl recharger le pare-feu

Bien sûr, vous devez garder le port 25 ouvert pour recevoir des e-mails d'autres serveurs SMTP.

Étape 3 :Protéger le panneau d'administration et la messagerie Web

Nous pouvons fermer les ports 80 et 443 pour protéger le panneau d'administration et le webmail contre le piratage. Cependant, cela interdira l'accès public à tous les hôtes virtuels. Certaines personnes peuvent avoir des hôtes virtuels dans Apache/Nginx qui doivent s'ouvrir à Internet. Au lieu de fermer les ports 80 et 443 dans le pare-feu, nous pouvons utiliser la fonction de contrôle d'accès intégrée dans Apache/Nginx.

Nginx

Modifiez le fichier d'hôte virtuel pour le webmail, tel que

sudo nano /etc/nginx/conf.d/mail.votre-domaine.com.conf

Ajoutez les lignes suivantes dans le server {...} le contexte. Cela n'autorisera que l'adresse IP 12.34.56.78 pour accéder au webmail et refuser toutes les autres adresses IP.

autoriser 12.34.56.78 ;tout refuser ;

Si vous avez plusieurs serveurs VPN, vous pouvez ajouter plusieurs adresses IP comme suit :

autoriser 12.34.56.78 ; autoriser 12.34.56.79 ; refuser tout ;

Enregistrez et fermez le fichier. Testez ensuite les configurations Nginx.

sudo nginx -t

Si le test réussit, rechargez Nginx pour que les modifications prennent effet.

sudo systemctl recharger nginx

Les utilisateurs ne figurant pas dans la liste blanche verront une erreur 403 interdite.

Apache

Modifiez le fichier d'hôte virtuel pour le webmail dans le /etc/httpd/conf.d/ répertoire, tel que

sudo nano /etc/httpd/conf.d/mail.votre-domaine.com-le-ssl.conf

Ajoutez les lignes suivantes entre <VirtualHost>...</VirtualHost> Mots clés. Cela n'autorisera que l'adresse IP 12.34.56.78 pour accéder au webmail et refuser toutes les autres adresses IP.

  Nécessite l'ip 12.34.56.78

Si vous avez plusieurs serveurs VPN, vous pouvez ajouter plusieurs adresses IP comme suit :

  Require ip 12.34.56.78 12.34.56.79

Enregistrez et fermez le fichier. Testez ensuite les configurations Apache.

sudo apachectl -t

Si la syntaxe est correcte, rechargez Apache pour que les modifications prennent effet.

sudo systemctl recharge httpd

Les utilisateurs ne figurant pas dans la liste blanche verront une erreur 403 interdite.

Renouvellement du certificat Certbot TLS

Si vous activez la liste blanche dans l'hôte virtuel Apache/Nginx, vous bloquerez également les serveurs Let's Encrypt pour accéder à votre serveur Web, ce qui est nécessaire pour renouveler le certificat Let's Encrypt TLS avec le défi HTTP-01. Pour résoudre ce problème, nous pouvons désactiver la liste blanche avant le renouvellement du certificat et la réactiver après le renouvellement.

Créez un script shell dans le /root/ répertoire.

sudo nano /root/certbot-renewal.sh

Si vous utilisez Nginx, ajoutez les lignes suivantes à ce fichier.

# ! /bin/bash# désactiver la liste blanche dans l'hôte virtuel Nginxed -i 's/deny all;/#deny all;/g' /etc/nginx/conf.d/mail.your-domain.com.confsystemctl reload nginx# renouveler TLS certificatecertbot renouveler --quiet# enable whitelistingsed -i 's/#deny all;/deny all;/g' /etc/nginx/conf.d/mail.your-domain.com.confsystemctl reload nginx

Si vous utilisez Apache, ajoutez les lignes suivantes à ce fichier.

# ! /bin/bash# désactiver la liste blanche dans l'hôte virtuel Apachesed -i 's/Require ip/#Require ip/g' /etc/httpd/conf.d/mail.your-domain.com-le-ssl.confsystemctl reload apache2 # renouveler le certificat TLS certificatecertbot renouveler --quiet# enable whitelistingsed -i 's/#Require ip/Require ip/g' /etc/httpd/conf.d/mail.your-domain.com-le-ssl.confsystemctl reload apache2

Enregistrez et fermez le fichier. Ajoutez ensuite l'autorisation d'exécution à ce fichier.

sudo chmod +x /root/certbot-renewal.sh

Modifiez le fichier crontab de l'utilisateur root.

sudo crontab -e

Ajoutez la ligne suivante à la fin du fichier pour que le script shell s'exécute une fois par jour.

@daily bash /root/certbot-renewal.sh

Enregistrez et fermez le fichier.

Fermer le port SSH ?

Étant donné que l'adresse IP de votre serveur VPN est sur liste blanche, vous pouvez également fermer le port SSH dans le pare-feu. Cependant, cela comporte un risque. Si votre serveur VPN cesse de fonctionner, vous vous verrouillez. Pour protéger le service SSH contre le piratage, je recommande de configurer l'authentification par clé publique ou l'authentification à deux facteurs.

2 étapes simples pour configurer l'authentification par clé publique SSH sur CentOS/RHEL
Configurer l'authentification SSH à deux facteurs (2FA) sur le serveur CentOS/RHEL