Cómo configurar el servicio de listas grises en el servidor de correo Postfix

El spam se convirtió en un regalo notable para los servidores de correo hace muchos años. Hoy en día, ningún servidor podría estar funcionando sin estar protegido contra el spam: según algunos informes, hasta el 75% de todo el tráfico de correo electrónico es spam. Se nota por la capacidad de la red, el hardware y el consumo de electricidad, incluso si ejecuta un sistema de correo de una pequeña empresa. Aunque el contenido comercial que analiza las soluciones anti-spam puede ser pesado y costoso y los de código abierto pueden ser pesados ​​y complicados, existen varias técnicas que eliminarían alrededor del 80% del tráfico de spam casi sin costo desde la perspectiva de los recursos. La creación de listas grises es una de estas técnicas.

La idea detrás de la solución de listas grises es muy simple pero elegante: los hosts que envían los mensajes de spam no son servidores de correo reales y no están controlados por el administrador del sistema real: son bots que se ejecutan en hosts aleatorios. Dado que su vida es impredecible incluso para el propietario de la botnet, no obedecen las reglas que hace el servidor de correo normal. Y si intenta pedirle cortésmente a dicho anfitrión que posponga el mensaje durante 5 minutos, desaparecerá para siempre o volverá a intentarlo inmediatamente. Esa es toda la idea de las listas grises: pida volver a intentarlo en 3 o 5 minutos y analice el comportamiento del remitente. Si obedece correctamente, lo más probable es que sea un agente de correo legítimo; si no, definitivamente es un robot de spam. Si ya hemos visto al remitente enviando este mensaje de destinatario desde el host en particular (es decir, triplete), entonces no deberíamos molestarlo con ninguna verificación y no demoraremos el mensaje para ellos.

En este artículo, le mostraré cómo configurar el servicio de listas grises para el servidor de correo Postfix. Usaríamos CentOS 7.4, pero en otras versiones de Linux el procedimiento es casi el mismo. La forma más conveniente de implementar esta técnica en los Centos con Postfix es usar postgrey.

Dado que el postgrey se agrega al repositorio principal, podemos instalarlo simplemente ejecutándolo

    # yum install postgrey

Luego ejecute el demonio y habilítelo en el arranque:

    #systemctl start postgrey
    #systemctl enable postgrey

Utiliza el mecanismo estándar smtpd_recipient_restriction para lidiar con el postgrey a través del socket UNIX. Simplemente agregando la ruta del socket al check_policy_service allí:

  smtpd_recipient_restrictions =
   permit_mynetworks,
   check_policy_service unix:postgrey/socket,
   permit

Esto le dirá al proceso smtpd que envíe mensajes al socket del postgrey después de todas las demás verificaciones (no queremos revisar trivialmente el correo electrónico filtrado) y que lo acepte solo después de que el postgrey lo acepte.

Postgrey en sí no tiene un archivo de configuración real y la única opción que realmente necesita es cuánto tiempo desea que se demore el mensaje. Entonces, en / etc / sysconfig / postgrey podemos definir la opción de inicio para el demonio. De forma predeterminada, la demora es de 300 segundos, pero incluso 60 segundos pueden ser suficientes para la mayoría de los bots.

    OPTIONS="--unix=/var/spool/postfix/postgrey/socket --delay=60"

Si ve «acceso denegado», es un problema de SELinux que se puede solucionar con audit2allow que le dirá a SELinux que está bien que el demonio postgrey escriba en el socket de UNIX:

    # grep smtpd_t /var/log/audit/audit.log | audit2allow -m postgreylocal > postgreylocal.te
    # cat postgreylocal.te
    module postgreylocal 1.0;
    require {
            type postfix_smtpd_t;
            type postfix_spool_t;
            type initrc_t;
            class sock_file write;
            class unix_stream_socket connectto;
    }
    #============= postfix_smtpd_t ==============
    allow postfix_smtpd_t initrc_t:unix_stream_socket connectto;
    allow postfix_smtpd_t postfix_spool_t:sock_file write; 

Aquí podemos ver un ejemplo del mensaje donde el remitente, el destinatario y el host del remitente ya están

Sep 21 14:38:04 andreybondarenko postgrey[518]: action=pass, reason=triplet found, client_name=mail2.static.mg.example.com, client_address=192.127.58.166, sender=bounce+d58b.00a37-me=andreybondarenko.com@mg.example.com, recipient=me@andreybondarenko.com

A continuación, se muestra un ejemplo de mensaje retrasado:

Sep 22 11:20:31 andreybondarenko postgrey[518]: action=greylist, reason=new, client_name=ppp91-122-100-196.pppoe.avonddsl.com, client_address=91.12.10.196, sender=ilepct@csu.edu, recipient=me@andreybondarenko.com

Como podemos ver en el PTR, es un grupo xDSL, por lo que definitivamente es un bot.

El inconveniente del postgrey es que el primer correo que se entrega desde el nuevo servidor se retrasaría varios minutos. Si está ejecutando varios MX’ex, este problema podría ser peor, ya que el servidor de correo de envío irá al siguiente MX y si la lista gris está habilitada allí, se retrasaría también en este host por separado, por lo que el retraso aumentaría. .

En conclusión, quiero decir que la lista gris rebota la mayor parte del spam sin costo alguno, ya que la idea y el software detrás de ella son gratuitos y no agregan falsos positivos como lo hacen los filtros de Bayes.