Dans ce tutoriel, je vais partager avec vous mes trucs et astuces pour sécuriser les serveurs de messagerie 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 Ubuntu 20.04 avec iRedMail
- Comment configurer facilement un serveur de messagerie sur Debian 10 Buster 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 Ubuntu
- Configurez votre propre serveur VPN WireGuard sur Debian
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 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 Debian/Ubuntu
Disons l'enregistrement DNS A pour mail.yourdomain.com se résout en 12.34.56.78 , vous devez 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 le pare-feu UFW (Debian/Ubuntu), exécutez la commande suivante sur le serveur de messagerie. Remplacez 12.34.56.78 par l'adresse IP du serveur VPN.
sudo ufw insert 1 allow in from 12.34.56.78
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 ufw insert 1 allow in from IP-address-of-the-other-web-server
É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. Les pirates peuvent lancer une attaque par force brute sur les ports 587 et 465.
Voici un exemple trouvé dans mon journal de messagerie (/var/log/mail.log sur Debian/Ubuntu, /var/log/maillog sur CentOS/RHEL). Le mauvais acteur essayait de se connecter, mais échouait à chaque fois à l'authentification SASL.
postfix/smtps/smtpd[18071]: Anonymous TLS connection established from unknown[92.118.38.56]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) postfix/smtps/smtpd[18071]: warning: unknown[92.118.38.56]: SASL LOGIN authentication failed: UGFzc3dvcmQ6 postfix/smtps/smtpd[18071]: lost connection after AUTH from unknown[92.118.38.56] postfix/smtps/smtpd[18071]: disconnect from unknown[92.118.38.56] ehlo=1 auth=0/1 rset=1 commands=2/3 postfix/smtps/smtpd[18071]: connect from unknown[92.118.38.56] postfix/smtps/smtpd[18071]: Anonymous TLS connection established from unknown[92.118.38.56]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) postfix/smtps/smtpd[18071]: warning: unknown[92.118.38.56]: SASL LOGIN authentication failed: UGFzc3dvcmQ6 postfix/smtps/smtpd[18071]: lost connection after AUTH from unknown[92.118.38.56] postfix/smtps/smtpd[18071]: disconnect from unknown[92.118.38.56] ehlo=1 auth=0/1 rset=1 commands=2/3 postfix/smtps/smtpd[18071]: connect from unknown[92.118.38.56] postfix/smtps/smtpd[18071]: Anonymous TLS connection established from unknown[92.118.38.56]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) postfix/smtps/smtpd[18071]: warning: unknown[92.118.38.56]: SASL LOGIN authentication failed: UGFzc3dvcmQ6 postfix/smtps/smtpd[18071]: lost connection after AUTH from unknown[92.118.38.56] postfix/smtps/smtpd[18071]: disconnect from unknown[92.118.38.56] ehlo=1 auth=0/1 rset=1 commands=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.
Pour fermer ces ports dans le pare-feu UFW, répertoriez d'abord vos règles de pare-feu.
sudo ufw status numbered
Exemple de sortie
Comme vous pouvez le constater, il existe à la fois des règles IPv4 et IPv6. Pour fermer le port 587, je dois supprimer la règle #16 et #6 . (Vous devez d'abord supprimer la règle avec un numéro d'index plus élevé.)
sudo ufw delete 16 sudo ufw delete 6
Ensuite, vous devez exécuter sudo ufw status numbered commande à nouveau pour obtenir une nouvelle liste de règles de pare-feu. Notez que le numéro d'index a changé pour certaines règles.
Cette fois, je veux fermer le port 465, donc je dois supprimer la règle #15 et #6 .
sudo ufw delete 15 sudo ufw delete 6
Utilisez ensuite la même méthode pour fermer les ports 143, 993, 110 et 995. 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.your-domain.com.conf
Ajoutez les lignes suivantes au bloc de serveur SSL. Cela n'autorisera que l'adresse IP 12.34.56.78 pour accéder au webmail et refuser toutes les autres adresses IP.
allow 12.34.56.78; deny all;
Si vous avez plusieurs serveurs VPN, vous pouvez ajouter plusieurs adresses IP comme suit :
allow 12.34.56.78; allow 12.34.56.79; deny all;
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 reload 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, tel que
sudo nano /etc/apache2/sites-enabled/mail.your-domain.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.
<LocationMatch "^/">
Require ip 12.34.56.78
</LocationMatch>
Si vous avez plusieurs serveurs VPN, vous pouvez ajouter plusieurs adresses IP comme suit :
<LocationMatch "^/">
Require ip 12.34.56.78 12.34.56.79
</LocationMatch>
Enregistrez et fermez le fichier. Testez ensuite les configurations Apache.
sudo apache2ctl -t
Si la syntaxe est correcte, rechargez Apache pour que les modifications prennent effet.
sudo systemctl reload apache2
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 # disable whitelisting sed -i 's/deny all;/#deny all;/g' /etc/nginx/conf.d/mail.your-domain.com.conf systemctl reload nginx # renew TLS certificate certbot renew --quiet # enable whitelisting sed -i 's/#deny all;/deny all;/g' /etc/nginx/conf.d/mail.your-domain.com.conf systemctl reload nginx postfix dovecot
Si vous utilisez Apache, ajoutez les lignes suivantes à ce fichier.
#! /bin/bash # disable whitelisting sed -i 's/Require ip/#Require ip/g' /etc/apache2/sites-enabled/mail.your-domain.com-le-ssl.conf systemctl reload apache2 # renew TLS certificate certbot renew --quiet # enable whitelisting sed -i 's/#Require ip/Require ip/g' /etc/apache2/sites-enabled/mail.your-domain.com-le-ssl.conf systemctl reload apache2 postfix dovecot
Enregistrez et fermez le fichier. Ajoutez ensuite l'autorisation d'exécution à ce fichier.
sudo chmod +x /root/certbot-renewal.sh
Modifiez ensuite 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 une connexion SSH sans mot de passe sur Ubuntu
- Configurer l'authentification SSH à deux facteurs (2FA) sur le serveur Ubuntu