☰

¿De dónde vienen estos fallos de conexión SMTP de "un solo punto"?

tag-icon • tag-icon smtp smtpd 502-error
¿De dónde vienen estos fallos de conexión SMTP de "un solo punto"?

Estoy ejecutando un servidor de correo basado en postfix. Hay muchos fallos de conexión como este:

Transcript of session follows.

Out: 220 hostname.tld ESMTP Postfix
In:  .
Out: 502 5.5.2 Error: command not recognized
In:
Out: 500 5.5.2 Error: bad syntax

Session aborted, reason: lost connection

Estas conexiones provienen de diferentes IP, pero en la mayoría de los casos en una cantidad de unas pocas décimas a cientos de intentos por IP.

¿Qué causa estas conexiones? Si se tratara de virus, gusanos o botnets que están "llamando a la puerta", ¿por qué tantas veces por host? ¿O enviar un solo punto es algún tipo de prueba de funcionalidad y mi servidor reacciona de manera incorrecta? Una vez más, los intentos múltiples no tienen sentido. Y está muy lejos de cualquier escala DoS.

¿Quizás algunos de ustedes saben lo que está pasando allí?

Respuesta1

El punto se utiliza para finalizar el mensaje de un correo electrónico en el protocolo SMTP: una línea vacía (CR, LF), seguida de un solo punto y nuevamente una nueva línea con CR y LF. Pero claramente este no es el caso aquí.

Para saber si estos clientes SMTP son sólo botnets o remitentes legítimos, puede echar un vistazo al PTR de sus IP, ambos están registrados. Si el PTR es genérico de un proveedor, algo como 192-0-2-1.broadband.customers.example.com. Entonces realmente puedes ignorarlo y usar fail2ban para bloquearlos.

El HELO debería coincidir con el PTR, al menos es la mejor práctica. Pero si no son similares, probablemente se trate de una botnet.

En el otro caso, es posible que alguien esté realizando un escaneo en su servidor y buscando protocolos y cifrados TLS.

Para prohibir a los clientes después de dichas solicitudes, puede usar fail2ban, que bloquea temporalmente una IP después de demasiadas solicitudes incorrectas.

filter.d/postfix-syntax.conf

[INCLUDES]
before = common.conf

[Definition]
failregex = reject: RCPT from (.*)\[<HOST>\]: 502 5.5.2
            reject: RCPT from (.*)\[<HOST>\]: 500 5.5.2
ignoreregex =

Y agrega esto a tu jail.conf:

[postfix-syntax]
enabled  = true
port     = smtp,ssmtp,submission
filter   = postfix-syntax
logpath  = /var/log/mail.log
maxretry = 10

Respuesta2

Si ha expuesto su servidor de correo a Internet, espere que la mayoría de las conexiones provengan de robots de spam y otros remitentes ilegítimos.

Consideraría simplemente hacer coincidir los rechazos para cualquier error en fail2ban. los remitentes legítimos rara vez deberían generar un error, y lo volverán a intentar más tarde si son baneados. Hago algunas cosas desagradables con presuntos spammers y han pasado años desde que un remitente legítimo tuvo otros problemas además de retrasos en la entrega.

Utilizo algunas pruebas para comprobar la legitimidad de los remitentes:

  • La IP no aparece en zen.spamhaus.org. (Incluye una amplia selección de IP dinámicas).
  • La IP tiene un DNS PTRque pasa rDNS. Rara vez el correo legítimo no tiene PTRregistro, y rDNScasi siempre pasa por la dirección IP.
  • El nombre en el comando HELO/EHLO es un nombre de dominio completo (FQDN) que pasa rDNS. Con la excepción de una gran corporación, esto casi siempre pasa. Normalmente este nombre es el mismo que se utiliza para la dirección IP.
  • El nombre del registro PTR y el comando HELO pasan la verificación SPF HELO directamente o para su dominio principal. Los dominios sin registros SPF también obtienen un pase, pero no obtienen credibilidad. Esto bloquea los robots de spam que se identifican utilizando el dominio de una organización grande.

Me gustaría usar DKIM para validar, pero un alto porcentaje de remitentes no publica correctamente su clave pública en DNS.

Si no puede ejecutar estas pruebas mientras la conexión aún está abierta, no devuelva el mensaje a menos que pueda verificar que el remitente no fue falsificado. (Aprecio todas las ofertas de dinero del FBI, la ONU, los bancos, etc., pero aún no las han entregado).

información relacionada