¿Qué es lo que está ocurriendo el intento de hackeo cuando veo: no se emitió MAIL / EXPN / VRFY / ETRN durante la conexión a MTA?

Question

¿Qué es lo que está ocurriendo el intento de hackeo cuando veo: no se emitió MAIL / EXPN / VRFY / ETRN durante la conexión a MTA?

#1 de tylerl (3 votos)
#2 de Lucas Kauffman (2 votos)
#3 de Eddie (0 votos)

0

Cuando veo mis registros de sendmail, el "error" más común que veo es el siguiente:

22 de noviembre 16:49:50 MyHostname sendmail [18832]: rAMMnj2u018832: [ la dirección IP redactada para ocultar al culpable ] no se emitió MAIL / EXPN / VRFY / ETRN durante la conexión a MTA

Esto no proviene de MUA mal configuradas dentro de mi pequeña red. Siempre proviene de fuera de mi red, desde donde solo los MTA deben comunicarse con mi sendmail. De manera abrumadora, la fuente más grande de estas direcciones IP es China, pero muchos otros países también lo son.

Supongo que esto debe ser parte de algún tipo de intento de piratería, pero no puedo entender de qué se trata. ¿Viene esto de hackers / scripts que se conectan al puerto 25? ¿Averiguar que mi sendmail no es una combinación de MTA / OS / versión con la que se pueden descifrar y desconectar sin hacer nada? (Si es así, ¿por qué se conectan repetidamente?) ¿O está sucediendo algo más? Si bien se ejecuta fail2ban y veo que se producen prohibiciones regulares, ¿hay algo más que hacer al respecto? Para el contexto, el sistema operativo es Fedora 19.

Nota: Lo que me confunde especialmente sobre esto es que normalmente veo mucho de esto en una fila desde la misma dirección IP. Casi nunca veo esto solo una vez desde una dirección IP dada. Incluso me han "atacado" de esta manera, antes, por varios servidores en la misma subred ... después de que cada uno es eliminado (a través de fail2ban), simplemente se mueven al siguiente servidor en la misma / 24 subred. Finalmente, cambié mi regla fail2ban de sendmail para prohibir una subred / 24 en lugar de una sola dirección IP, solo para reducir el ruido. Si esto fuera solo un "control para ver si pudiéramos explotar", entonces esperaría un solo golpe en la puerta, no esos intentos repetidos.

En realidad, estoy tentado de escuchar las 24 horas en el puerto 25; recibo el correo lo suficientemente pequeño como para que esto no me matara, solo para tratar de averiguar qué sucede en estas conexiones. Algunos días recibo docenas de estas conexiones desde la misma dirección IP.

attacks linux smtp

pregunta Eddie 23.11.2013 - 00:21

fuente

3 respuestas

Lea otras preguntas en las etiquetas attacks linux smtp

Si quiero proteger una cadena de una modificación, ¿es suficiente para saltearla y trashearla? ¿Cómo recuperar la contraseña del administrador de una aplicación web?

score 3 · Answer 1

SMTP espera comandos en la siguiente secuencia:

HELO o EHLO servername
MAIL FROM: < address >
RCPT TO: < address >
DATA

Aunque técnicamente en lugar de MAIL FROM , el servidor podría enviar EXPN , VRFY o ETRN , aunque nadie lo haga.

Aparentemente, su servidor recibió el saludo HELO o EHLO , pero luego nada después de eso, o algo después de eso no se esperaba.

A menudo, esto proviene de agentes de monitoreo u otros escáneres que no están interesados en enviar realmente correo, sino que simplemente realizan pruebas para ver qué está escuchando. Además, es muy probable que estén intentando explotar alguna vulnerabilidad anterior, que (de manera correcta) simplemente se interpreta como basura y termina la conexión.

Por lo general, cuando un servidor realiza algunos pasos inusuales (por ejemplo, al terminar prematuramente una conversación), se creará una entrada en el registro que notará el hecho, en caso de que necesite una depuración más adelante.

score 2 · Answer 2

did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

Esto sucede a veces cuando el cliente no ha emitido ningún comando relacionado con el envío de correo a su servidor (MTA). Esto podría significar que se está escaneando y que solo están agarrando su banner para ver qué versión de servidor está ejecutando. Por lo tanto, podría ser parte de una fase de recopilación de información y, por lo tanto, una advertencia del spam entrante.

score 0 · Answer 3

Comencé WireShark en el puerto 25, y ha estado funcionando durante casi 24 horas hasta ahora. He visto tres variantes diferentes de esto hasta ahora. Supongo que hay muchos más. Esto también me ayudó a darme cuenta de que mi sendmail está dando su nombre exacto (sendmail en lugar de postfix o algo más) y la versión. He modificado la respuesta 220 a continuación.

Hay los "ataques" que he visto hasta ahora:

El cliente emitió un FIN antes de que mi evento del servidor SMTP emitiera el 220. En otras palabras, vi el saludo de tres vías, seguido de un paquete FIN que cierra el lado del cliente, seguido de mi sendmail emitiendo su línea de identificación 220 , seguido de FIN / ACK y el cierre del zócalo. ¡No tengo idea de cuál era el punto de esa conexión! Al emitir FIN antes de que sendmail realmente enviara el 220, el cliente renunció a la capacidad de interactuar con él de cualquier manera. Si un montón de estos pasaran, pensaría que tal vez era un DoS, pero sucedió exactamente una vez. Raro.
Un cliente emitió HELO con un nombre de dominio no válido, luego EHLO con el mismo nombre de dominio no válido, donde sendmail aparentemente no registra el hecho de que está devolviendo 501 quejas de "nombre de dominio no válido". Sólo registró que nunca recibió MAIL / EXPN / VRFY / ETRN, lo cual es engañoso. A continuación se muestra una transcripción SMTP editada de WireShark, donde se suprimieron los nombres para ocultar a los culpables y los números en [ ] son los valores hexadecimales de lo que se envió como parte del nombre de host. suprimido es donde estoy suprimiendo el nombre de host real enviado.

220 MyHostname ESMTP Sendmail version / version ; Sun, 24 Nov 2013 04:05:22 -0400
EHLO [c7 cf bf b5 c1 f8]. suprimido .co.kr
501 5.0.0 Invalid domain name
HELO [c7 cf bf b5 c1 f8]. suprimido .co.kr
501 5.0.0 Invalid domain name

Básicamente, envió seis caracteres con el conjunto de bits alto, luego de lo que realmente es un dominio válido. Tal vez un poco de ahogo de la MTA en los personajes falsos?

Este es un intento de "golpe", supongo. por ejemplo, que ve la versión incorrecta y se da por vencida.

220 MyHostname ESMTP Sendmail version / version ; Sun, 24 Nov 2013 09:52:59 -0400
RSET
250 2.0.0 Estado de reinicio
SALIR
221 2.0.0 MyHostname cierre de la conexión

¿O esto estaba tocando, o quizás algunos MTA hacen algo gracioso después de obtener RSET ?

¿La moraleja de la historia? Sendmail presenta esta queja de registro para una variedad de diferentes comportamientos de clientes extraños o malintencionados.