Recientemente recibí uno Undelivered Mail Returned to Sendermientras enviaba mi boletín a uno de mis 1500 clientes. Mi sitio web utiliza un procedimiento de doble suscripción para asegurarse de que el usuario desea recibir mi boletín de forma explícita.
El mensaje de error:
smtp; 554 ...
Swisscom AG IP: 94.130.34.42, You are not allowed to send us mail. Please
refer to xyz.com if you feel this is in error.
Recibí un ejemplo de correo no deseado (del proveedor de correo del servidor de correo receptor):
Received: from mail.com ([94.130.34.42])
by smtp-27.iol.local with SMTP
id itOWeYZ6O42IFitOWe35TR; Tue, 13 Feb 2018 03:54:09 +0100
From: "Servizi online - Poste Italiane" <[email protected]>
Subject: Abbiamo ricevuto una segnalazione di accredito
Date: Mon, 12 Feb 2018 11:32:03 -0500
El proveedor también declaró que mi servidor parece estar pirateado. Además, afirmó que "el servidor de correo del destinatario simplemente ha registrado el rDNS que le presentó la IP de conexión, en este caso mail.com ([94.130.34.42])", que definitivamente NO es como configuré mi entrada de rDNS (mail.lotsearch.de) para mi dirección IP. Entonces, si entendí rDNS correctamente, el servidor de correo receptor consulta la IP del remitente para obtener una entrada rDNS (94.130.34.42 => debería resolver a => mail.lotsearch.de, lo que definitivamente hace, cuando lo pruebo desde mi máquina local a través de $ host 94.130.34.42)
¿Cómo es posible falsificar rDNS? No puedo imaginar de ninguna manera cómo esto puede funcionar técnicamente (solo con un ataque man-in-the-middle en algún lugar de la infraestructura entre el servidor de correo receptor y mi servidor).
El proveedor también mencionó que "es probable que una máquina que se conecta desde mi IP se haya visto comprometida y envíe estos mensajes a través de conexiones directas al servidor de correo del destinatario (también conocido como MX directo)". Que direct MXsignifica ¿Alguien robó o encontró credenciales de correo filtradas en una de mis cuentas de correo y las usó para enviar correos?
Lo que he hecho hasta ahora para asegurarme de que mi servidor NO sea / no sea pirateado:
- buscado en los registros de correo (
var/log/mail*): nada especial allí - comprobado los registros de inicio de sesión ssh (
last,lastb): nada inusual - comprobado si postfix está retransmitiendo: no, no lo hace (verificado a través de telnet)
- comprobado malware a través de clamav: sin resultados
- instalado y configurado fail2ban para ssh, postfix y dovecot
- instalé los últimos parches / actualizaciones para Ubuntu 16.04 (lo hago todas las semanas)
- comprobado si mi dirección IP está en alguna lista negra: no está
- entrada rDNS verificada en la consola de administración de mi proveedor de hosting: está configurada correctamente en
mail.lotsearch.de. - cambio de contraseñas de todas las cuentas de correo
- claves públicas modificadas para acceso de shell
Más importante: no había información sobre [email protected]en los registros. Entonces, si mi servidor hubiera sido mal utilizado por un spammer (por ejemplo, debido a las credenciales de smtp filtradas de una de las cuentas de correo), lo vería en los archivos de registro.
La última posibilidad que se me ocurre es que un intruso colocó malware en mi servidor que aún no encontré.
¿Cómo puedo monitorear el tráfico de correo saliente (por proceso y por puerto)?
Solo monitorear el puerto 25 saliente no ayudaría, ya que esto solo atraparía los correos irregulares enviados a través de postfix, pero no el tráfico de correo causado por una posible infección de malware (si el malware usa otro puerto que no sea el 25 para enviar correos directamente / comunicarse con los servidores de correo del destinatario) . Si monitorizo el tráfico saliente en todos los puertos, obtendré una forma de archivo de registro enorme que no puedo buscar de manera eficiente actividades sospechosas.
EDITAR - Prueba agregada para relé abierto:
$ telnet mail.lotsearch.de 25
$ HELO [email protected]
250 mail.lotsearch.de
$ MAIL FROM: [email protected]
250 2.1.0 Ok
$ RCPT TO:<[email protected]>
454 4.7.1 <[email protected]>: Relay access denied
EDITAR - Ejecutar webapps
- Plataforma personalizada basada en Zend Framework 3 ( https://framework.zend.com/ )
- Mediawiki ( https://www.mediawiki.org/ )
- Mantis Bug Tracker ( https://www.mantisbt.org/ )
fuente
Respuestas:
Antes de llegar a mi sugerencia, quiero comentar un poco sobre algo que su proveedor le dijo:
Esto no indica que el DNS inverso para 94.130.34.42 es (o era) mail.com. Más bien, indica que el cliente SMTP envió
mail.comen suHELO(oEHLO) línea. (Un servidor de correo bien configurado habría rechazado esta conexión por completo, pero está en Swisscom, no tú ...) Esta línea no indica ninguna entrada inversa de DNS. Si lo hiciera, habría aparecido entre paréntesis. Por ejemplo:En este caso, el primer nombre de host es el que el servidor de correo identificó en sí mismo
EHLO. El segundo nombre de host es el DNS inverso registrado en el momento en que se realizó la conexión.La sección 4.4 del RFC 5321 explica el formato de la línea Recibido: con una gramática formal.
En su caso, no se registró ningún DNS inverso. Dado que su dirección IP tiene un registro PTR, esto puede deberse a que no lo buscaron o a que hubo un error temporal de DNS.
Ahora, parece que ejecuta un servicio de alojamiento web y tiene numerosas aplicaciones web. Si uno de estos se ve comprometido, puede comenzar a enviar spam. A menudo, realizan conexiones directas a servidores de correo remotos buscando sus registros MX y conectándose al puerto 25, como si en realidad fueran un servidor de correo, en lugar de entregar el correo a la bobina de correo local o un servicio de correo autenticado en los puertos 587 o 465 como lo hacen las aplicaciones web legítimas.
Una forma de detener esto es mediante la implementación de una regla de firewall que evite las conexiones salientes en el puerto 25 a menos que el usuario sea el usuario del servidor de correo. Por ejemplo:
Las aplicaciones web ya no pueden enviar correo directamente a servidores SMTP remotos, sino que deben usar la cola de correo local o un servicio de correo autenticado.
fuente
iptablesregla para permitir que postfix y el usuario de plesk envíen correos electrónicos (ya que creo que el Panel de Plesk sí envía correos directamente y no a través de postfix)? ¿También es posible configurar crondaemon (mis cronjobs) para enviar correos electrónicos a través de smtp a través de postfix? No quiero agregar el usuario cron a iptables (como otra excepción) ya que sería más seguro permitir que el tráfico de correo pasara por postfix. ¿Es posible dejar que crontab use postfix para enviar registros de errores? ¿Debo poner eso en una nueva pregunta aquí en serverfault?root? Porque el proceso maestro de postfix se ejecutarooten la mayoría de los casos. ¿O el proceso maestro de postfix genera subprocesos usandopostfix-user para enviar correos electrónicos / hacer cosas? Probé su regla de iptables, los correos electrónicos no se pudieron entregar ... Si lo hagops -ef | grep "postfix", veo algunos subprocesos ejecutados porpostfix-user y un proceso maestro ejecutado porroot...En la actualidad, tratar de hacer su propio servidor de correo es, en su mayor parte, una batalla perdida y es mejor que encuentre un servicio asequible. Una vez dicho esto..
Mire sus registros que van al proveedor que lo bloqueó y vea si puede encontrar algo sospechoso. Es posible, y sucede a menudo, que alguien olvide que se suscribió a su boletín informativo y lo marque como spam. Luego, dependiendo del proveedor, puede ingresar a la lista negra del proveedor aunque no haya hecho nada malo.
Separe los correos masivos de todos sus otros correos electrónicos en dos servidores.
Mantenga registros durante semanas como mínimo y mejores meses. Entonces, cada vez que sucede algo, investigas.
Revise sus registros diariamente para detectar situaciones similares de cualquier proveedor y verifíquelo diariamente o más rápido. En el segundo en que se bloquea y si sigue intentando enviarlo, puede empeorar. Puedes pasar de un bloqueo temporal a un bloqueo permanente ... para que te denuncien en una lista negra.
No estoy seguro de cómo lo implementan, pero una cosa que sé que muchos proveedores hacen por los servicios de correo salientes es que en el segundo en que un proveedor / IP bloquea un correo electrónico, no se intenta enviar ningún otro correo electrónico. Idealmente, quieres algo así. Debido a que el segundo se bloquea, enviar más solo agravará el problema.
fuente