¿Cómo evitar el abuso de SMTP mediante el envío de correos electrónicos no deseados?

6

No soy administrador, acabo de crear un sitio web y también hay un servidor de correo en el servidor por el que pagué de mi proveedor de alojamiento. La mayoría de lo que aprendí sobre los servidores de correo proviene de tutoriales en Internet.

Estoy usando Open Panel (con Postfix), porque fallé al configurar Exim correctamente. Pero mis problemas no han llegado a su fin.

Ahora puedo ver que mi servidor de correo probablemente (?) está siendo usado por otra persona, porque en el archivo /var/log/mail.log puedo ver muchas direcciones de correo electrónico desconocidas, como:

postfix/smtp[31747]: C1EF776612: to=<[email protected]>, relay=mail2.gieprod.com[195.182.17.37]:25, delay=21527, delays=21525/0.01/1.8/0, dsn=4.0.0, status=deferred (host mail2.gieprod.com[195.182.17.37] refused to talk to me: 554-mail2.gieprod.com 554 Your access to this mail system has been rejected due to the sending MTA's poor reputation. If you believe that this failure is in error, please contact the intended recipient via alternate means.)

o:

postfix/smtpd[31772]: NOQUEUE: reject: RCPT from smtp-sortant.sn.auf.org[213.154.65.69]: 550 5.1.1 <EmmanuelRoy@mydomain>: Recipient address rejected: User unknown in virtual mailbox table; from=<> to=<EmmanuelRoy@mydomain> proto=ESMTP helo=<smtp-sortant.sn.auf.org>

¿El último significa que está bien, o significa algo más?

Estos no son mis correos electrónicos. Y hay muchos de ellos, y su comando "RCPT TO" generalmente toma 20 direcciones de correo electrónico como veo en el registro. A veces aparece la frase "Throttling" (?). Y están usando mi nombre de dominio para muchas direcciones de correo electrónico falsas como "MAIL FROM", por ejemplo. chevassucathy @ mydomain, AKZwart @ mydomain, MichaelLESKINEN @ mydomain, SantinaZappulla @ mydomain y muchos otros.

Ayer por la noche, lo he usado para borrar una cola de correos electrónicos (acabo de enterarme de que hay algo parecido a una cola):

postsuper -d ALL

Pero hoy por la mañana puedo ver que hay nuevos correos electrónicos no enviados en una cola.

Entonces, me pregunto si podría restringir el uso de SMTP en mi servidor, como quizás:

  • ¿Podría restringir el uso de SMTP desde fuera (no local) a solo números de IP determinados?
  • No puedo permitir el envío de otras direcciones de correo electrónico como "MAIL FROM" que relacionadas con las cuentas de correo electrónico existentes (configuradas).
  • otras formas?

O, ¿solo puedo evitarlo deteniendo el servicio SMTP y ejecutando postfix cuando quiero enviar un correo electrónico (por supuesto, muy incómodo)?

EDIT : intenté hacer una prueba en este sitio: enlace

Esto es lo que obtuve:

    >>> 220 name ESMTP Postfix (Debian/GNU)
    <<< EHLO u16544016.aboutmyip.com 
    >>> 250-name
    >>> 250-PIPELINING
    >>> 250-SIZE 10240000
    >>> 250-VRFY
    >>> 250-ETRN
    >>> 250-STARTTLS
    >>> 250-AUTH PLAIN LOGIN
    >>> 250-ENHANCEDSTATUSCODES
    >>> 250-8BITMIME
    >>> 250 DSN
    <<< MAIL FROM: 
    >>> 250 2.1.0 Ok
    <<< RCPT TO: 
    >>> 554 5.7.1 : Recipient address rejected: Relay access denied
    <<< QUIT 

    Connection test: PASS
    Reverse IP Lookup: WARNING - Reverse IP lookup test failed on your server. Some servers on the Internet may reject emails from this server.

    Open relay test: PASS

EDIT2: Autenticación

Pensé que esto es una autenticación: este es un contenido del archivo /etc/postfix/sasl/smtpd.conf :

pwcheck_method: authdaemond
log_level: 3
mech_list: PLAIN LOGIN
authdaemond_path: /var/run/courier/authdaemon/socket

El servidor SMTP cuando lo telnet me parece que requiere, por ejemplo. para pasar "auth plain [base64 with email address y pswd]" para utilizar el comando "MAIL TO".

    
pregunta forsberg 05.08.2015 - 08:45
fuente

2 respuestas

2

A primera vista, su primera línea de registro parece que su servidor de correo está intentando enviar mensajes de rebote a remitentes falsos.

En otras palabras, obtienes spam con un remitente falso. Esto se rechaza, y su sistema intenta devolver un mensaje de error pero falla. El rebote se pone en la cola deferred , que se intentará de nuevo.

La solución a corto plazo es efectivamente borrar la cola (pero use postsuper -d ALL deferred para borrar solo esa cola específica). También primero asegúrese de que no haya ningún correo electrónico útil allí ( mailq o postqueue -p ).

Pero también, parece que su servidor está en algún tipo de lista negra, lo que puede deberse a que los spammers abusan de su sistema, pero también podría significar que su proveedor tiene una mala reputación con el spam (los sistemas de reputación a veces funcionan bloques de direcciones IP).

Consulte también aquí: enlace

    
respondido por el Mark Koek 09.12.2015 - 14:19
fuente
0

El problema descrito aquí apenas encaja en la categoría de prevención. Es control de daños y algunos forenses. ¿Cómo prevenir el abuso de SMTP? Lea los manuales, comprenda su sistema o, al menos, utilice configuraciones reforzadas, actualice y aplique parches a menudo, observe los registros. Y ahora a la resolución de problemas:

Si alguna vez tiene un problema como este, lo primero que debe hacer es dañar el control: detenga el servidor smtp, haga una copia de seguridad. El siguiente paso es el análisis forense: verifique de dónde provienen esos correos. ¿Cómo lograron hacer esto?

Localice el ID de correo en la línea de registro problemática (C1EF776612 en la pregunta) y grep para ello. (Algo como grep C1EF776612 /var/log/mail.log).

Comprueba la primera línea. ¿De dónde se conecta el cliente?

  • ¿Es localhost? Tienes un problema local. Probablemente uno de su sitio web fue hackeado. Tenga en cuenta que es muy posible enviar correos, incluso si no está publicando ningún correo de sus sitios. Además, cualquier otro servicio, incluso su propia cuenta podría ser hackeada y enviar correos.
  • ¿Es otro host? Uno de sus clientes está comprometido o usted es un proxy abierto (este no es el caso del problema anterior)

Si está utilizando milters (como amavis), de todas formas su correo podría provenir de localhost (es decir, de milter). En este caso, debe verificar las líneas de registro del milter para obtener el ID de mensaje original. El grep anterior debería revelar este también. Un segundo grep en la segunda identificación le mostrará la fuente real.

Después de identificar el vector de ataque, puede realizar pasos preventivos. Hay muchas posibilidades, desafortunadamente el tema es demasiado amplio para abarcarlo aquí.

    
respondido por el goteguru 15.09.2015 - 18:29
fuente

Lea otras preguntas en las etiquetas