Building a Anti-SPAM Gateway. Part 2 (Best Practices)

PiPo e2H – Soluciones TIC Avanzadas Jose Luis Gomez Ferrer de Couto – vEXPERT 2011-2013, CCNA, VCP 4&5, VCAP5-DCA, CCA, EMC, IBM

7jul/106

Construyendo un Anti-SPAM Gateway. Parte 2 (Buenas prácticas)

En la primera parte se explicaba como instalar paso a paso nuestro Anti-SPAM Gateway con Postfix. En esta segunda parte vamos a ver como mejorar el comportamiento de nuestro servidor con unas buenas prácticas, lo que permitirá controlar el flujo de correos que pasarán por nuestro Gateway.

Estas buenas prácticas se basan en varios parámetros que se declaran en el fichero main.cf, permitiendo controlar errores entra la comunicación cliente -> servidor. Los pasos que vamos a seguir durante este artículo son los siguientes:

  1. Agregar parámetros en main.cf
  2. Probar parámetros.

Agregar parámetros en main.cf

Con los parámetros que vamos a configurar vamos a intentar que nuestro Anti-SPAM Gateway se adapte a las diferentes RFCs que normalizan el funcionamiento del servicio SMTP.

El primer parámetro que vamos a configurar es la obligación que tiene el cliente en comenzar introduciendo HELO/EHLO para realizar un envío correctamente. Para ello ejecutamos los siguientes comandos como usuario root:

vi /etc/postfix/main.cf

smtpd_helo_required = yes

Ahora vamos a ampliar las opciones en el parámetro smtpd_recipient_restrictions, decir que estas opciones pueden ir separadas por comas o espacios; y recalcar que la lectura de sus opciones se realizan en orden de principio a fin, por lo que es importante conocer que opciones estamos configurando para no tener un funcionamiento inesperado.

Para conocer mejor estas opciones las vamos a definir y explicar para saber como se va a comportar  nuestro servidor. Estas opciones son:

  • reject_unknown_sender_domain -> Rechaza la solicitud cuando MAIL FROM tiene en su dirección un dominio no existente.
  • reject_unknown_recipient_domain -> Rechaza la solicitud cuando RCPT TO tiene en su dirección un dominio no existente.
  • reject_unauth_pipelining -> Rechaza la solicitud cuando el cliente envía comandos SMTP antes de tiempo sin saber que Postfix soporta command pipelining. Esto detiene a programas de correo masivo que usan command pipelining para acelerar entregas.
  • reject_invalid_hostname -> Rechaza la solicitud cuando el cliente proporciona en el HELO/EHLO un FQDN inválido.
  • reject_non_fqdn_helo_hostname -> Rechaza la solicitud cuando el cliente proporciona en el HELO/EHLO un FQDN que no existe.
  • reject_non_fqdn_sender -> Rechaza la solicitud cuando la dirección en MAIL FROM no cumple FQDN.
  • reject_non_fqdn_recipient -> Rechaza la solicitud cuando la dirección en RCPT TO no cumple FQDN.

Una vez que conoces el cometido de cada una de las opciones, únicamente falta introducirlas en nuestro fichero main.cf. Ejecutamos los siguientes comandos como root para efectuar los cambios:

vi /etc/postfix/main.cf

smtpd_recipient_restrictions =

reject_unknown_sender_domain

reject_unknown_recipient_domain

permit_mynetworks

reject_unauth_destination

reject_unauth_pipelining

reject_invalid_hostname

reject_non_fqdn_helo_hostname

reject_non_fqdn_sender

reject_non_fqdn_recipient

permit

Para que los cambios tomen efecto tenemos que recargar nuestro Postfix, para ello ejecutamos el siguiente comando como root:

postfix reload

Una vez recargada la configuración de Postfix, vamos a seguir probando cada una de las opciones para conocer como afectan.

Probar parámetros

A continuación vamos a probar cada una de las líneas introducidas en el fichero main.cf. Para ello vamos a seguir el orden en el que se han introducido.

  • smtpd_helo_required = yes

En esta primera prueba vamos a conectar a nuestro servidor desde un equipo cliente y vamos a introducir todos los comandos necesarios para enviar un correo electrónico pero sin introducir el parámetro inicial helo/ehlo dominio. Para ello ejecutamos los siguientes comandos desde un cliente:

telnet IP_ANTISPAM 25

mail from:test@test.com

  • reject_unknown_sender_domain

Ahora vamos a comprobar como devuelve un error cuando introducimos un dominio no válido en el MAIL FROM. Hay que tener en cuenta que este parámetro también afecta a las redes locales declaradas en mynetworks, ya que este se encuentra antes del parámetro permit_mynetworks. Para ello nuevamente ejecutamos los siguientes comandos:

telnet IP_ANTISPAM 25

ehlo test.com

mail from:user@test.invalid

rcpt to:user@example.com

  • reject_unknown_recipient_domain

Ahora se va a rechazar el envío porque el dominio va a ser inválido en el RCPT TO, recalcar también que este parámetro afecta también al envío desde las redes declaradas en mynetworks. Nuevamente ejecutamos los siguientes comandos:

telnet IP_ANTISPAM 25

ehlo test.com

mail from:user@test.com

rcpt to:user@example.invalid

  • reject_invalid_hostname

Ahora vamos a introducir en el comando HELO/EHLO un dominio con caracteres no válidos. Ejecutamos los siguientes comandos:

telnet IP_ANTISPAM 25

ehlo .

mail from:user@test.com

rcpt to:user@example.com

  • reject_non_fqdn_helo_hostname

En la siguiente prueba vamos a introducir en el comando HELO/EHLO un dominio no válido. Para esto ejecutamos los siguientes comandos:

telnet IP_ANTISPAM 25

ehlo test

mail from:user@test.com

rcpt to:user@example.com

  • reject_non_fqdn_sender

Ahora vamos a comprobar como bloqueamos los correos que no proporcionan un FQDN válido en el MAIL FROM. Ejecutamos los siguientes comandos:

telnet IP_ANTISPAM 25

ehlo test.com

mail from:user

rcpt to:user@example.com

  • reject_non_fqdn_recipient

En esta última prueba vamos a comprobar como se rechazan correos que no cumplen con FQDN en el RPCT TO. Ejecutamos los comandos mostrados a continuación:

telnet IP_ANTISPAM 25

ehlo test.com

mail from:user@test.com

rcpt to:user

Con estas pruebas comprobamos el funcionamiento de todos los parámetros configurados. Se recomienda que cuando se realicen cambios no se hagan más de tres y realizar pruebas, ya que si realizamos todos los cambios de una vez no podremos saber por donde nos falla nuestro servidor.

Quería hacer una mención, en estos momentos que termino el artículo disfruto de ver ganar la selección nacional de mi país la semifinal a Alemania, esperamos que el próximo domingo seamos campeones del mundo ganando a Holanda. Hasta otra entrega amigos.

José Luis Gómez Ferrer de Couto

VMware vExpert 2011 & 2012 / VCP 4&5 / VCAP5-DCA. SysAdmin at TUI Travel PLC. Author of blog PiPo e2H specialized in Virtualization, Storage and Networking.

More Posts - Website

Follow Me:
TwitterFacebookLinkedInGoogle PlusYouTube

Share

¿Te gustó este artículo?

¡Suscríbete a nuestro feed RSS!

Archivado en: Postfix Deja un comentario
Get Adobe Flash player