Restricciones de Postfix

Restricciones de Postfix

1. Introducción

Si ha seguido la básica de postfix guía tendrá una sencilla sufijo de correo electrónico del servidor en funcionamiento que es capaz de enviar y recibir correo electrónico. Sin embargo, es probable que haya notado que su servidor de correo Postfix recibe todo el correo electrónico, sin restricciones, incluyendo spam. Correo no deseado, también conocido como email masivo no solicitado (UBE) o mensajes comerciales no solicitados (UCE) se estima que constituyen más del 80% de todo el correo electrónico enviado a través de Internet y, como tal, representa un desafío importante para cualquier administrador de correo electrónico. Esta guía se examinarán algunas de las restricciones disponibles en Postfix para combatir el correo no deseado y está diseñado para ser de tipo modular de tal manera que se puede implementar, además de la básica guía sufijo si el lector lo desea.

 

2. Postfix y spam

La Internet se basa en gran medida en una política de confianza y UBE abusos que confían para permitir la entrega de grandes cantidades de spam. Al colocar ningún tipo de restricciones a los correos electrónicos que se están evitando de la política de confianza y, como tal, también corren el riesgo de restringir o bloquear el correo electrónico legítimo. Por lo tanto debemos ser conservadores en las restricciones que aplicamos y debemos probar y monitorear a fondo. Sus usuarios se lo agradecerán para limitar la cantidad de spam que ven pero no se lo agradecerán para bloquear el correo electrónico legítimo.

Vamos a usar 3 clases de restricción sufijo diferentes para examinar la información proporcionada a nuestro servidor de correo electrónico por cualquier cliente que se conecta:

  • smtpd_helo_restrictions
  • smtpd_sender_restrictions
  • smtpd_recipient_restrictions

Por suerte para nosotros, muchos spammers no se molestan en seguir de cerca las directrices RFC y podemos utilizar estas clases de restricción para identificar el spam obvia sobre esa base y rechazar antes de que ingrese a nuestro servidor de correo electrónico. Rechazando el spam obvio antes de que entre nuestro servidor de correo electrónico tiene las ventajas de ahorro de ancho de banda, así como la reducción de los gastos generales de procesamiento adicionales para nuestro servidor de correo electrónico.

Restricciones de trabajo mediante la tramitación de una serie de reglas que determina la acción que se llevará a Postfix para ese mensaje. Posibles resultados están bien, rechazar o DUNNO. Restricciones se procesan o evalúan en el orden en el que aparecen.Si una regla devuelve un valor de RECHAZAR entonces el mensaje es rechazado de inmediato sin más transformación. Si una regla devuelve un valor del bien, entonces el tratamiento posterior de esa clase de restricciones se detiene y la próxima clase de restricciones se evalúan hasta que el mensaje tiene o ha superado con éxito todas las clases de restricción o posteriormente es rechazado por una norma posterior. Así, por ejemplo, un mensaje puede recibir un valor del bien de un smtpd_sender_restriction pero todavía puede ser rechazada por una regla smtpd_recipient_restriction posterior. Por lo tanto, tenemos que considerar cuidadosamente el orden de nuestras reglas de restricción. Si el mensaje no es rechazada explícitamente por ninguna regla, entonces la política por defecto es aceptar el mensaje.

Para comprender mejor las diferentes clases de restricciones y cómo se aplican, permite echar un vistazo al proceso smtp con más detalle, ya que telnet en nuestro servidor de correo electrónico y enviar un mensaje de prueba simple para nosotros mismos:

 

telnet 192.168.0.2 25 # Comentarios
Tratando 192.168.0.2 ...
Conectado a 192.168.0.2 (192.168.0.2).
Carácter de escape es '^]'.
220 mail.example.com ESMTP Postfix # <-smtp_client_restrictions
HELO mail.example.com # <-smtp_helo_restrictions
250 mail.example.com #
MAIL FROM: <ned@example.com> # <-smtp_sender_restrictions
250 2.1.0 Ok #
RCPT TO: <ned@example.com> # <-smtp_recipient_restrictions
250 2.1.5 Ok #
DATOS # <-smtp_data_restrictions
354 datos finales con <CR> <LF>. <CR> <LF> #
A: <ned@example.com> # <-header_checks
De: <ned@example.com> #
Asunto: SMTP Prueba #
Este es un mensaje de prueba # <-body_checks
. #
250 2.0.0 Ok: en cola como 301AE20034
SALIR
221 2.0.0 Adiós
Conexión cerrada por el host externo.

Una de las principales ventajas de las restricciones helo smtpd, remitente y destinatario son que se evalúan y actuar en consecuencia antes de que el cuerpo del correo electrónico se ha enviado nunca / recibidos hasta el spam potencial puede ser rechazada al principio del proceso smtp sin consumir ancho de banda adicional y / o recursos de procesamiento. Es probablemente el mejor que podemos ver algunas restricciones en la acción para entender mejor lo que hace cada uno. Se añaden todas las restricciones al archivo de configuración de postfix ubicado en / etc / postfix / main.cf

 

3. Restricciones Helo

Cuando un sistema cliente se conecta primero a nuestro servidor de correo electrónico, es necesario que la propia identidad con el comando HELO smtp. Muchos spammers bien tratan de saltarse este paso por completo, se enviará información imposiblemente válido o se tratan deliberadamente de confundir su identidad para obtener acceso. De cualquier manera, podemos rechazar con seguridad las conexiones de los clientes que están severamente mal configurado o que se ofuscar deliberadamente su identidad.

 

# / Etc / postfix / main.cf
# restricciones HELO:
smtpd_delay_reject = sí
smtpd_helo_required = sí
smtpd_helo_restrictions =
    permit_mynetworks,
    reject_non_fqdn_helo_hostname,
    reject_invalid_helo_hostname,
    permiso

Nota: Postfix 2.2 (CentOS 4) utiliza reject_non_fqdn_hostname y reject_invalid_hostname, respectivamente.

La primera línea (smtpd_delay_reject) permite la conversación SMTP para continuar hasta el punto de llegar a recibir el mensaje antes de que sea rechazada, y es útil porque permite que toda la información del remitente y el destinatario que estar conectado.También es un requisito para helo_restrictions. La segunda línea (smtpd_helo_required) rechaza correo electrónico desde cualquier sistema que no identifica a sí mismo.

Nuestros smtpd_helo_restrictions comienzan en la línea 3. permit_mynetworks dice Postfix para que acepte conexiones de máquinas de confianza definidos en mynetworks modo de correo electrónico de nuestros clientes de confianza, no se someterá a controles adicionales de restricción helo. reject_non_fqdn_helo_hostname rechazarán las conexiones si el nombre de host suministrado con el comando HELO no es un nombre de dominio completo como lo exigen las normas RFC. Debe ser perfectamente seguro para rechazar los intentos de conexión de los clientes que no hacen ningún esfuerzo para identificar correctamente a sí mismos. Del mismo modo, reject_invalid_helo_hostname rechazarán los intentos de conexión cuando la sintaxis hostname HELO es válida.Finalmente nos permitimos mensajes para pasar a la siguiente etapa de filtrado.

Una opción, además, que de vez en cuando se especifica es reject_unknown_helo_hostname que rechacen los mensajes si el nombre de host suministrado con el comando helo no tiene ya sea un DNS A válida o registro MX. Sin embargo, este ajuste se debe utilizar con precaución, ya que rechazará correo electrónico de sistemas legítimos con problemas de DNS temporales y puede dar lugar a falsos positivos.

 

4. Restricciones de remitente

El siguiente paso es filtrar los remitentes válidos con algunas restricciones del remitente:

 

# / Etc / postfix / main.cf
# restricciones del remitente:
smtpd_sender_restrictions =
    permit_mynetworks,
    reject_non_fqdn_sender,
    reject_unknown_sender_domain,
    permiso

Una vez más, en primer lugar nos permitimos correo electrónico de los remitentes en nuestra propia red (permit_mynetworks). Las siguientes dos líneas rechazan los mensajes si la dirección de correo electrónico de remitentes es incorrecto o no existe ya que no hay ninguna razón real para aceptar correo de ellos. reject_non_fqdn_sender rechazará email cuando MAIL FROM dirección no se encuentra en forma de dominio completo como lo requiere el RFC. reject_unknown_sender_domain rechazarán correo electrónico cuando el dirección de MAIL FROM tiene ni DNS ni un registro MX, o cuando se tiene un registro MX malformaciones tales como un registro con una longitud cero MX nombre de host. El código de respuesta para reject_unknown_sender_domain es 450 (a intentarlo más tarde) en caso de un error temporal de DNS. Además, como la dirección de MAIL FROM es la dirección que rebotan notificaciones deberán ser enviadas a, no tiene sentido para recibir correo de un dominio desconocido. La última línea permite a cualquier otro mensaje para pasar a la siguiente fase de la filtración.

 

5. Las restricciones de destinatario

Por este tiempo, está claro que el equipo cliente no está completamente mal configurado y que el remitente se encuentra al menos una oportunidad de ser legítimo. El último paso es ver que el cliente tiene permiso para enviar al destinatario dado y aplicar algunos controles no postfix externos al pequeño número de mensajes que hacen que sea tan lejos.

 

# / Etc / postfix / main.cf
# restricciones de destinatarios:
smtpd_recipient_restrictions =
   reject_unauth_pipelining,
   reject_non_fqdn_recipient,
   reject_unknown_recipient_domain,
   permit_mynetworks,
   reject_unauth_destination,
   check_sender_access
         de hash :/ etc / postfix / sender_access,
   reject_rbl_client zen.spamhaus.org,
   reject_rbl_client bl.spamcop.net,
   check_policy_service unix: postgrey / socket,
   permiso

Postfix soporta una técnica conocida como la canalización que acelera las entregas a granel de correo electrónico mediante el envío de múltiples comandos SMTP a la vez. El protocolo requiere que los clientes primero verifique que el servidor soporta la canalización. Muchos spammers enviar una serie de comandos sin esperar la autorización, a fin de entregar sus mensajes lo más rápidamente posible. reject_unauth_pipelining detiene el correo de software de correo masivo que utiliza indebidamente la segmentación con el fin de agilizar las entregas.

Las siguientes líneas deben ser algo familiar ya y rechazar el correo a los dominios que no existen o no pueden existir. En primer lugar, rechazamos correo electrónico cuando el RCPT TO abordar no está en forma de dominio completo (reject_non_fqdn_recipient) exigidos por RFC y luego rechazamos email cuando nuestro servidor de correo electrónico no es destino final de la dirección del destinatario, cuando el RCPT TO abordar no tiene DNS A o un registro MX, o cuando se tiene un registro MX con formato incorrecto. El código de respuesta para reject_unknown_recipient_domain es 450 (a intentarlo más tarde) en caso de un error temporal de DNS. Una vez más, le dice a Postfix permit_mynetworks para aceptar conexiones de usuarios locales en nuestra red.

La siguiente línea, reject_unauth_destination, es de vital importancia , ya que le dice a Postfix no aceptar los mensajes con destinatarios en dominios que no están alojados localmente o que servimos como un servidor de copia de seguridad para. Sin esta línea, nuestro servidor sería una retransmisión abierta.

El siguiente ajuste, check_sender_access, nos permite implementar listas blancas y listas negras de direcciones y dominios de correo electrónico completas o parciales como se especifica en el campo MAIL FROM contra una tabla de acceso especificada con un objetivo de Aceptar o Rechazar. En primer lugar debemos crear nuestra tabla de consulta, que en este caso es el archivo de texto sin formato / etc / postfix / sender_access:

 

# / Etc / postfix / sender_access
#
# Negro / lista blanca de remitentes que coinciden con el 'CORREO DE' campo. Ejemplos ...
#
myfriend@example.com Aceptar
junk@spam.com REJECT
comercialización @ RECHAZO
theboss @ OK
deals.marketing.com REJECT
somedomain.com Aceptar

En el ejemplo anterior podemos ver que podemos lista de correo negro o blanco de direcciones completos de correo electrónico, nombres de usuario en cualquier dominio o dominios y nombres de dominio parciales contenidos en el campo MAIL FROM. Tenga en cuenta que estos son sólo ejemplos y, en general usted no debe la lista blanca de su propio dominio como spammers suelen falsificar la dirección del remitente sea la de tu propio dominio. Una vez que haya creado su archivo sender_access debe ejecutar el comando postmap contra ella para crear la versión indexada que Postfix utilizará (también se debe repetir este cada vez que cambie el archivo):

 

postmap / etc / postfix / sender_access

Es el último de nuestros cheques postfix internos. El resto de los controles, bien consultar fuentes externas o aplicaciones de ayuda.

Realizaremos alguna lista negra en tiempo real (RBL) cheques. RBL del, también conocido como listas negras de DNS (DNSBL) son servicios de 3 ª parte que mantienen una lista de direcciones IP que se sabe están involucrados en algún tipo de actividad ilícita, tales como la distribución de spam u otro contenido no deseado, como los virus. La línea reject_rbl_client causa de postfix para realizar una comprobación contra la base de datos de la lista y rechazará el mensaje si se trata de una mala fuente conocida. Debido a que estos controles implican una búsqueda de DNS que son relativamente “caro” en términos de recursos y por lo tanto son los mejor situados hacia el final de nuestros cheques para que tanto el spam como sea posible ya ha sido eliminado para reducir al mínimo el número que se producen. Del mismo modo, también tiene sentido colocar las listas de los más eficaces en primer lugar, de nuevo minimizando el número de búsquedas que se necesitan para rechazar un mensaje (spam).

Hay muchos de disposición DNSBL, cuántos y qué usted elige utilizar depende de usted, pero usted debe controlar sus registros de forma regular para revisar su efectividad (pista: instalar el paquete postfix-Pflogsumm y utilizar el Pflogsumm comando para analizar su registros postfix). También debemos reconocer que el uso de las aperturas de DNSBL para introducir la posibilidad de falsos positivos, ya que confiamos en la política de la lista mantenedor para agregar direcciones sin escrúpulos. Algunos son muy eficaces, algunos bloques prácticamente nada, y otros bloqueará tanto correo genuino como lo hacen spam. Para más información y estadísticas en tiempo real sobre DNSBL del lector se refiere a: https://stats.dnsbl.com/

El control final, check_policy_service, se utiliza para llamar a un complemento de la aplicación o el script, en este caso postgrey unido a un socket unix. Postgrey puede ser muy eficaz cuando se trata de eliminar el spam y hay una guía separada dedicada exclusivamente a la instalación de postgrey en el servidor de correo electrónico de postfix. El lector se anima encarecidamente leer que guía siguiente.

 

6. Resumen

En esta guía hemos visto cómo podemos utilizar las restricciones de sufijo para rechazar el correo de los clientes, obviamente, mal configurado o los que de otra manera no tienen negocios el envío de correo electrónico a nuestro servidor. Las restricciones aplicadas son deliberadamente conservadora con la intención de no causar falsos positivos y deberían funcionar bien en cualquier instalación de postfix. Restricciones de Postfix, particularmente rechazando nombres de host helo en forma de nombres de dominio que no estén totalmente cualificados, pueden bloquear hasta el 30% del spam y el uso de 1 o 2 buenos DNSBLs puede bloquear el 90% o más del resto. En combinación con otras técnicas de filtrado tales como la lista gris , debería ser posible para filtrar la gran mayoría de correo no deseado (~ 99%) antes de que entre en el servidor de correo electrónico con el consiguiente ahorro en los recursos de ancho de banda y de procesamiento. Esta guía está diseñada para complementar la base guía de postfix .

 

7. Agradecimientos

Este artículo fue inspirado por y en estrecha colaboración basada en la excelente guía de Kirk Strauser publicado bajo el “Reconocimiento-Compartir Igual” Creative Commons License 2.5 en: https://www.freesoftwaremagazine.com/articles/focus_spam_postfix

Leave a Reply

Your email address will not be published. Required fields are marked *

*
To prove you're a person (not a spam script), type the security word shown in the picture. Click on the picture to hear an audio file of the word.
Anti-spam image