En este tutorial, voy a compartir con ustedes mis consejos y trucos para proteger los servidores de correo electrónico CentOS/RHEL contra la piratería. con un servidor VPN autohospedado. Muchos spammers intentan piratear los servidores de correo electrónico de otras personas. Si tiene éxito, usarían el servidor de correo electrónico pirateado para enviar grandes volúmenes de spam o robar datos valiosos. ¿Por qué usamos un servidor VPN autohospedado? Porque le permite habilitar la inclusión en la lista blanca, por lo que solo los usuarios de confianza conectados al servidor VPN pueden acceder a su servidor de correo.
Requisitos
Se supone que tienes un servidor de correo electrónico está funcionando. Si no, sigue uno de los tutoriales a continuación para configurar tu propio servidor de correo.
- Cómo configurar fácilmente un servidor de correo con todas las funciones en CentOS 8 con iRedMail
También se supone que ha configurado un servidor VPN . De lo contrario, siga uno de los tutoriales a continuación. El servidor de correo y el servidor VPN pueden ejecutarse en hosts separados o en el mismo host.
- Configure su propio servidor VPN WireGuard en CentOS
Sugerencia :Se recomienda ejecutar el servidor VPN y el servidor de correo en hosts separados para reducir las complejidades operativas . Si el servidor de correo y el servidor VPN se ejecutan en el mismo host, se requieren pasos adicionales, a saber, configurar una zona de política de respuesta en el servidor VPN para anular el registro DNS A público del nombre de host de su servidor de correo.
- Configurar la zona de política de respuesta (RPZ) en BIND Resolver en CentOS/RHEL
Digamos el registro DNS A para mail.yourdomain.com se resuelve en 12.34.56.78 , debe crear un registro en la zona de política de respuesta para resolverlo en la dirección IP privada del servidor VPN 10.10.10.1 .
En los siguientes textos, uso 12.34.56.78 como la dirección IP pública del servidor VPN. Si el servidor VPN y el servidor de correo se ejecutan en el mismo host, debe reemplazar 12.34.56.78 con la dirección IP privada del servidor VPN 10.10.10.1 .
Paso 1:agregue la dirección IP del servidor VPN a la lista blanca del cortafuegos
Una vez que tenga un servidor de correo y un servidor VPN en funcionamiento, debe agregar la dirección IP del servidor VPN a la lista blanca del servidor de seguridad del servidor de correo. Si utiliza Firewalld (CentOS/RHEL), ejecute el siguiente comando en el servidor de correo. Reemplace 12.34.56.78 con la dirección IP del servidor VPN.
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="12.34.56.78" accept'
También puede incluir en la lista blanca las direcciones IP de sus otros servidores. Por ejemplo, algunas personas pueden tener otro servidor web que necesita enviar correos electrónicos a través del servidor de correo electrónico. Luego también agréguelo a la lista blanca.
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="IP-address-of-the-other-web-server" accept'
Vuelva a cargar firewalld para que los cambios surtan efecto.
sudo systemctl reload firewalld
Paso 2:cierre el puerto de envío, el puerto IMAP y el puerto POP3
- Puerto de envío :587 y 465
- Puerto IMAP :143 y 993
- Puerto POP3 :110 y 995
Los clientes de correo como Mozilla Thunderbird y Microsoft Outlook utilizan los puertos 587 y 465 para enviar correos electrónicos salientes. Los actores malintencionados pueden realizar un ataque de fuerza bruta en los puertos 587 y 465.
El siguiente es un ejemplo que se encuentra en mi registro de correo (/var/log/maillog en CentOS/RHEL). El mal actor estaba tratando de iniciar sesión, pero falló la autenticación SASL cada vez.
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
No quiero ver este tipo de actividad en mi registro de correo, así que simplemente cierro los puertos 587, 465, 143, 993, 110 y 995 en el firewall. Y debido a que la dirección IP de mi servidor VPN está incluida en la lista blanca, solo los usuarios que están conectados a mi servidor VPN pueden acceder a esos puertos.
En CentOS/RHEL, ejecute los siguientes dos comandos para deshabilitar imap , imaps , smtp-submission , smtps , pop3 y pop3s servicios.
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 ve una advertencia como Warning: NOT_ENABLED: smtps , puede ignorar la advertencia. Vuelva a cargar firewalld para que los cambios surtan efecto.
sudo systemctl reload firewalld
Por supuesto, debe mantener abierto el puerto 25 para recibir correos electrónicos de otros servidores SMTP.
Paso 3:Proteger el panel de administración y el correo web
Podemos cerrar los puertos 80 y 443 para proteger el panel de administración y el correo web de la piratería. Sin embargo, eso prohibirá el acceso público a todos los servidores virtuales. Algunas personas pueden tener hosts virtuales en Apache/Nginx que necesitan abrirse a Internet. En lugar de cerrar los puertos 80 y 443 en el firewall, podemos usar la función de control de acceso integrada en Apache/Nginx.
Nginx
Edite el archivo de host virtual para correo web, como
sudo nano /etc/nginx/conf.d/mail.your-domain.com.conf
Agregue las siguientes líneas en el server {...} contexto. Esto permitirá solo la dirección IP 12.34.56.78 para acceder al correo web y denegar todas las demás direcciones IP.
allow 12.34.56.78; deny all;
Si tiene varios servidores VPN, puede agregar varias direcciones IP de la siguiente manera:
allow 12.34.56.78; allow 12.34.56.79; deny all;
Guarde y cierre el archivo. Luego pruebe las configuraciones de Nginx.
sudo nginx -t
Si la prueba es exitosa, vuelva a cargar Nginx para que los cambios surtan efecto.
sudo systemctl reload nginx
Los usuarios que no estén en la lista blanca verán un error prohibido 403.
Apache
Edite el archivo de host virtual para correo web en /etc/httpd/conf.d/ directorio, como
sudo nano /etc/httpd/conf.d/mail.your-domain.com-le-ssl.conf
Agregue las siguientes líneas entre <VirtualHost>...</VirtualHost> etiquetas Esto permitirá solo la dirección IP 12.34.56.78 para acceder al correo web y denegar todas las demás direcciones IP.
<LocationMatch "^/">
Require ip 12.34.56.78
</LocationMatch>
Si tiene varios servidores VPN, puede agregar varias direcciones IP de la siguiente manera:
<LocationMatch "^/">
Require ip 12.34.56.78 12.34.56.79
</LocationMatch>
Guarde y cierre el archivo. Luego pruebe las configuraciones de Apache.
sudo apachectl -t
Si la sintaxis es correcta, vuelva a cargar Apache para que los cambios surtan efecto.
sudo systemctl reload httpd
Los usuarios que no estén en la lista blanca verán un error prohibido 403.
Renovación del certificado TLS de Certbot
Si habilita la inclusión en la lista blanca en el host virtual Apache/Nginx, también bloqueará los servidores de Let's Encrypt para acceder a su servidor web, que es necesario para renovar el certificado TLS de Let's Encrypt con desafío HTTP-01. Para resolver este problema, podemos deshabilitar la inclusión en la lista blanca antes de la renovación del certificado y habilitarla nuevamente después de la renovación.
Cree un script de shell en /root/ directorio.
sudo nano /root/certbot-renewal.sh
Si usa Nginx, agregue las siguientes líneas a este archivo.
#! /bin/bash # disable whitelisting in the Nginx virtual host 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
Si usa Apache, agregue las siguientes líneas a este archivo.
#! /bin/bash # disable whitelisting in the Apache virtual host sed -i 's/Require ip/#Require ip/g' /etc/httpd/conf.d/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/httpd/conf.d/mail.your-domain.com-le-ssl.conf systemctl reload apache2
Guarde y cierre el archivo. Luego agregue permiso de ejecución a este archivo.
sudo chmod +x /root/certbot-renewal.sh
Edite el archivo crontab del usuario root.
sudo crontab -e
Agregue la siguiente línea al final del archivo, para que el script de shell se ejecute una vez al día.
@daily bash /root/certbot-renewal.sh
Guarde y cierre el archivo.
¿Cerrar puerto SSH?
Dado que la dirección IP de su servidor VPN está en la lista blanca, también puede cerrar el puerto SSH en el firewall. Sin embargo, hacerlo conlleva un riesgo. Si su servidor VPN deja de funcionar, entonces se bloqueará. Para proteger el servicio SSH de la piratería, recomiendo configurar la autenticación de clave pública o la autenticación de dos factores.
- Dos sencillos pasos para configurar la autenticación de clave pública SSH en CentOS/RHEL
- Configure la autenticación de dos factores SSH (2FA) en el servidor CentOS/RHEL