In questo tutorial, condividerò con te i miei suggerimenti e trucchi per proteggere i server di posta elettronica dagli hacker con un server VPN self-hosted. Molti spammer stanno cercando di hackerare i server di posta di altre persone. In caso di successo, utilizzerebbe il server di posta hackerato per inviare grandi volumi di spam o rubare dati preziosi. Perché utilizziamo un server VPN self-hosted? Perché ti consente di abilitare la whitelist, quindi solo gli utenti fidati connessi al server VPN possono accedere al tuo server di posta.
Prerequisiti
Si presume che tu abbia un server di posta elettronica installato e funzionante. In caso contrario, segui uno dei tutorial seguenti per configurare il tuo server di posta.
- Come configurare facilmente un server di posta completo su Ubuntu 20.04 con iRedMail
- Come configurare facilmente un server di posta su Debian 10 Buster con iRedMail
Si presume inoltre che tu abbia configurato un server VPN . In caso contrario, segui uno dei tutorial qui sotto. Il server di posta e il server VPN possono essere eseguiti su host separati o sullo stesso host.
- Configura il tuo server VPN WireGuard su Ubuntu
- Configura il tuo server VPN WireGuard su Debian
Suggerimento :Si consiglia di eseguire il server VPN e il server di posta su host separati per ridurre le complessità operative . Se il server di posta e il server VPN vengono eseguiti sullo stesso host, sono necessari ulteriori passaggi, in particolare l'impostazione di una zona dei criteri di risposta sul server VPN per sovrascrivere il record DNS A del nome host del server di posta.
- Imposta Response Policy Zone (RPZ) in BIND Resolver su Debian/Ubuntu
Diciamo il record DNS A per mail.yourdomain.com si risolve in 12.34.56.78 , quindi devi creare un record nella zona dei criteri di risposta per risolverlo nell'indirizzo IP privato del server VPN 10.10.10.1 .
Nei testi seguenti utilizzo 12.34.56.78 come indirizzo IP pubblico del server VPN. Se il server VPN e il server di posta funzionano sullo stesso host, è necessario sostituire 12.34.56.78 con l'indirizzo IP privato del server VPN 10.10.10.1 .
Passaggio 1:aggiungi l'indirizzo IP del server VPN alla whitelist del firewall
Una volta che hai un server di posta e un server VPN attivi e in esecuzione, dovresti aggiungere l'indirizzo IP del server VPN alla whitelist del firewall del server di posta. Se utilizzi firewall UFW (Debian/Ubuntu), esegui il seguente comando sul server di posta. Sostituisci 12.34.56.78 con l'indirizzo IP del server VPN.
sudo ufw insert 1 allow in from 12.34.56.78
Puoi anche inserire nella whitelist gli indirizzi IP degli altri tuoi server. Ad esempio, alcune persone potrebbero avere un altro server Web che deve inviare e-mail tramite il server di posta elettronica. Quindi aggiungilo anche alla whitelist.
sudo ufw insert 1 allow in from IP-address-of-the-other-web-server
Fase 2:chiudi la porta di invio, la porta IMAP e la porta POP3
- Porta di invio :587 e 465
- Porta IMAP :143 e 993
- Porta POP3 :110 e 995
Le porte 587 e 465 sono utilizzate da client di posta come Mozilla Thunderbird e Microsoft Outlook per inviare e-mail in uscita. Gli hacker possono attaccare con la forza bruta alle porte 587 e 465.
Quello che segue è un esempio trovato nel mio registro di posta (/var/log/mail.log su Debian/Ubuntu, /var/log/maillog su CentOS/RHEL). Il malintenzionato stava tentando di accedere, ma ogni volta non è riuscito l'autenticazione 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
Non voglio vedere questo tipo di attività nel mio registro di posta, quindi chiudo semplicemente le porte 587, 465, 143, 993, 110 e 995 nel firewall. E poiché l'indirizzo IP del mio server VPN è nella whitelist, solo gli utenti che sono connessi al mio server VPN possono accedere a quelle porte.
Per chiudere queste porte nel firewall UFW, elenca prima le regole del firewall.
sudo ufw status numbered
Esempio di output
Come puoi vedere, ci sono sia le regole IPv4 che IPv6. Per chiudere la porta 587, devo eliminare la regola #16 e #6 . (Dovresti prima eliminare la regola con un numero di indice più alto.)
sudo ufw delete 16 sudo ufw delete 6
Quindi dovresti eseguire sudo ufw status numbered comando di nuovo per ottenere un nuovo elenco di regole del firewall. Nota che il numero di indice è cambiato per alcune regole.
Questa volta voglio chiudere la porta 465, quindi devo eliminare la regola #15 e #6 .
sudo ufw delete 15 sudo ufw delete 6
Quindi usa lo stesso metodo per chiudere le porte 143, 993, 110 e 995. Ovviamente, devi mantenere aperta la porta 25 per ricevere e-mail da altri server SMTP.
Fase 3:protezione del pannello di amministrazione e della webmail
Possiamo chiudere le porte 80 e 443 per proteggere il pannello di amministrazione e la webmail dall'hacking. Tuttavia, ciò vieterà l'accesso pubblico a tutti gli host virtuali. Alcune persone potrebbero avere host virtuali in Apache/Nginx che devono aprirsi a Internet. Invece di chiudere le porte 80 e 443 nel firewall, possiamo utilizzare la funzione di controllo degli accessi integrata in Apache/Nginx.
Nginx
Modifica il file dell'host virtuale per la webmail, ad esempio
sudo nano /etc/nginx/conf.d/mail.your-domain.com.conf
Aggiungi le seguenti righe al blocco del server SSL. Ciò consentirà solo l'indirizzo IP 12.34.56.78 per accedere alla webmail e negare tutti gli altri indirizzi IP.
allow 12.34.56.78; deny all;
Se hai più server VPN, puoi aggiungere più indirizzi IP in questo modo:
allow 12.34.56.78; allow 12.34.56.79; deny all;
Salva e chiudi il file. Quindi testa le configurazioni di Nginx.
sudo nginx -t
Se il test ha esito positivo, ricarica Nginx per rendere effettive le modifiche.
sudo systemctl reload nginx
Gli utenti non nella whitelist vedranno un errore 403 vietato.
Apache
Modifica il file dell'host virtuale per la webmail, ad esempio
sudo nano /etc/apache2/sites-enabled/mail.your-domain.com-le-ssl.conf
Aggiungi le seguenti righe tra <VirtualHost>...</VirtualHost> tag. Ciò consentirà solo l'indirizzo IP 12.34.56.78 per accedere alla webmail e negare tutti gli altri indirizzi IP.
<LocationMatch "^/">
Require ip 12.34.56.78
</LocationMatch>
Se hai più server VPN, puoi aggiungere più indirizzi IP in questo modo:
<LocationMatch "^/">
Require ip 12.34.56.78 12.34.56.79
</LocationMatch>
Salva e chiudi il file. Quindi testa le configurazioni di Apache.
sudo apache2ctl -t
Se la sintassi è ok, ricarica Apache per rendere effettive le modifiche.
sudo systemctl reload apache2
Gli utenti non nella whitelist vedranno un errore 403 vietato.
Rinnovo del certificato TLS di Certbot
Se abiliti la whitelist nell'host virtuale Apache/Nginx, bloccherai anche i server Let's Encrypt per accedere al tuo server web, che è necessario per rinnovare il certificato Let's Encrypt TLS con la sfida HTTP-01. Per risolvere questo problema, possiamo disabilitare la whitelist prima del rinnovo del certificato e riattivarla dopo il rinnovo.
Crea uno script di shell in /root/ directory.
sudo nano /root/certbot-renewal.sh
Se usi Nginx, aggiungi le seguenti righe a questo file.
#! /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
Se usi Apache, aggiungi le seguenti righe a questo file.
#! /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
Salva e chiudi il file. Quindi aggiungi l'autorizzazione di esecuzione a questo file.
sudo chmod +x /root/certbot-renewal.sh
Quindi modifica il file crontab dell'utente root.
sudo crontab -e
Aggiungi la riga seguente alla fine del file, in modo che lo script della shell venga eseguito una volta al giorno.
@daily bash /root/certbot-renewal.sh
Salva e chiudi il file.
Chiudere la porta SSH?
Poiché l'indirizzo IP del tuo server VPN è nella whitelist, puoi anche chiudere la porta SSH nel firewall. Tuttavia, ciò comporta un rischio. Se il tuo server VPN smette di funzionare, ti blocchi fuori. Per proteggere il servizio SSH dall'hacking, consiglio di configurare l'autenticazione a chiave pubblica o l'autenticazione a due fattori.
- 2 semplici passaggi per configurare l'accesso SSH senza password su Ubuntu
- Configura l'autenticazione a due fattori SSH (2FA) su Ubuntu Server