Dan las 14:00h en el reloj y me extraño de no haber recibido mucho correo electrónico a lo largo de la mañana. De repente, en la bandeja de entrada 120 mensajes, todos errores de Postfix y entre ellos un mensaje del proveedor de los servidores: hemos cortado el acceso al puerto 25 en el router porque hemos detectado muchos mensajes con una alta puntuación de spam saliendo del servidor. Raudo me pongo a ver los logs y hay entre 2 y 3 veces más que de costumbre, ¿qué o quién está haciendo esto?
Los antecedentes
Entre los dominios que gestiono, hay algunos dominios que pertenecen a empresas que tienen poco o ningún conocimiento informático. Ellos se conforman con tener su correo llegando a un webmail cómodo como squirrelmail o roundcube y listo. Nada más.
Después de unos años de tranquilidad, algunos ataques controlados a través de SSH y quizás intentos de fuerza bruta a través de IMAP, pero poco más, lo normal en la red. Mantengo la lista de los servidores a evitar e intento mantener el perímetro bien vigilado de los sospechosos habituales.
Esta mañana fue bien distinta. Habían entrado. En el log se veía claro que había usuarios de uno de los dominios (llamémosle garra.com por ejemplo) enviando emails a direcciones fuera del servidor... pero las direcciones de origen no existían en el servidor de origen.
¿Dejé la puerta abierta?
NOTA: si quieres saber más acerca de la cómo funciona el sistema de correo puedes leer este artículo.
Los servidores de correo realizan una acción de pasar emails de unos MTA a otros hasta localizar su destino final. La mayoría de MTA actuales ya no hacen eso. Tienen configurado uno o varios dominios de los que son destinatarios y el resto los ignoran. La configuración óptima de estos MTA suele ser:
- recibir emails cuyo destinatario sea un buzón válido dentro de uno de los dominios también válido dentro del servidor o
- enviar emails cuyo remitente sea un usuario válido dentro de uno de los dominios también válido dentro del servidor.
Si ninguna de estas premisas se cumple es porque puede pasar alguna de las siguientes causas:
- esté activo el sistema de relay o
- un usuario autenticado esté usando otra identidad.
El primer caso es el que comentaba y significaría un error en la configuración del sistema. En mi caso uso Postfix como MTA, Amavis como filtro primero de mensajes y Dovecot como MDA. Si la puerta estaba abierta debería de encontrarse en Postfix. Revisamos la configuración:
broken_sasl_auth_clients = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = bosqueviejo.net
smtpd_sasl_security_options = noanonymous
smtpd_sender_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
reject_unauth_destination
smtpd_data_restrictions =
reject_unauth_pipelining,
permit
smtpd_reject_unlisted_recipient = no
smtpd_recipient_restrictions =
reject_unknown_recipient_domain,
permit_sasl_authenticated,
permit_mynetworks,
reject_unauth_destination,
reject_rbl_client sbl.spamhaus.org,
smtp_sasl_security_options =
unknown_local_receipient_reject_code = 550Esta es la configuración (no completa) del servidor Postfix. Todo apunta a que no es posible realizar relay. Pero para asegurarnos, vamos a intentar realizar nosotros mismos un relay:
$ telnet bosqueviejo.net 25
Trying 176.31.105.29...
Connected to bosqueviejo.net.
Escape character is '^]'.
220 tornasauce.bosqueviejo.net ESMTP
HELO pringao
250 tornasauce.bosqueviejo.net
MAIL FROM: <aaa@garra.com>
250 2.1.0 Ok
RCPT TO: <another@gmail.com>
554 5.7.1 <another@gmail.com>: Relay access denied
QUIT
221 2.0.0 Bye
Connection closed by foreign host.Seguro. La puerta estaba cerrada. Entonces... ¿quién está enviando esos emails?
Buscando el agujero
Continúo pensando. Nos queda una posibilidad, pero se suman más. Las causas posibles ahora son:
- algo o alguien está enviando mensajes desde el servidor o
- algo o alguien autenticado está enviando mensajes desde fuera.
Miro las sesiones abiertas en la consola. Solo yo. Filtro los logs de Postfix para que me dé solo las conexiones y poder sacar conclusiones.
Si todas las conexiones provienen de localhost (o 127.0.0.1) tendría el problema de buscar el programa (o interfaz web) con vulnerabilidad o código inyectado para enviar esa cantidad de mensajes.
Si las conexiones son desde fuera puedo bloquear direcciones IP (las que no conozca o sean de países fuera del ámbito de visitas típico de las webs que alojo) y trazar una conexión y saber qué están haciendo exactamente.
# tail -1000f /var/log/syslog | grep "connect from"
Jun 24 08:05:38 ns392056 postfix/smtpd[3623]: connect from labig.ru[92.63.99.84]
Jun 24 08:05:54 ns392056 postfix/smtpd[3655]: connect from localhost.localdomain[127.0.0.1]
Jun 24 08:06:07 ns392056 postfix/smtpd[3623]: connect from mta86l1.r.grouponmail.es[50.115.214.89]
Jun 24 08:06:11 ns392056 postfix/smtpd[3655]: connect from localhost.localdomain[127.0.0.1]
Jun 24 08:09:16 ns392056 postfix/smtpd[4215]: connect from outmail021.prn2.facebook.com[66.220.144.148]
Jun 24 08:09:19 ns392056 postfix/smtpd[4230]: connect from localhost.localdomain[127.0.0.1]
Jun 24 08:14:21 ns392056 postfix/smtpd[4778]: connect from smtp180.efor.es[93.92.232.180]
Jun 24 08:14:24 ns392056 postfix/smtpd[4792]: connect from localhost.localdomain[127.0.0.1]
Jun 24 08:17:27 ns392056 postfix/smtpd[5135]: connect from labig.ru[92.63.99.84]
Jun 24 08:21:52 ns392056 postfix/smtpd[5599]: connect from localhost.localdomain[127.0.0.1]
Jun 24 08:21:54 ns392056 postfix/smtpd[5565]: connect from o1.email.change.org[208.115.214.201]
Jun 24 08:23:56 ns392056 postfix/smtpd[5807]: connect from labig.ru[92.63.99.84]
Jun 24 08:24:20 ns392056 postfix/smtpd[5879]: connect from localhost.localdomain[127.0.0.1]
...Hay conexiones desde localhost pero no más que de costumbre. Sin embargo hay conexiones que se repiten con bastante frecuencia a lo largo de todo el log y la mayoría con extensión ru curiosamente.
Descarto entonces la primera opción. Paso a la segunda. Hay alguien autenticándose desde fuera de forma correcta y enviando emails. Quiero saber quién es o qué cuenta es la que está usando. Voy a incrementar el log para el sistema de SASL de Dovecot:
auth_verbose = yes
auth_debug = yesEspero a que haya un poco más de movimiento y analizo los logs:
# grep sasl_method=LOGIN /var/log/syslog
...
... client=vologda.ru[178.64.186.224], sasl_method=LOGIN, sasl_username=cota@garra.com
... client=vologda.ru[178.64.186.224], sasl_method=LOGIN, sasl_username=cota@garra.com
... client=vologda.ru[178.64.186.224], sasl_method=LOGIN, sasl_username=cota@garra.com
... client=vologda.ru[178.64.186.224], sasl_method=LOGIN, sasl_username=cota@garra.com
... client=vologda.ru[178.64.186.224], sasl_method=LOGIN, sasl_username=cota@garra.com
... client=vologda.ru[178.64.186.224], sasl_method=LOGIN, sasl_username=cota@garra.com
... client=vologda.ru[178.64.186.224], sasl_method=LOGIN, sasl_username=cota@garra.com
... client=vologda.ru[178.64.186.224], sasl_method=LOGIN, sasl_username=cota@garra.com
¡Eureka! a lo largo del log veo la misma cuenta cota@garra.com repetida una y otra vez con direcciones de, ¿Rusia? Obviamente han conseguido la cuenta de correo de este usuario y la están empleando para enviar mensajes basura o publicitarios.
Cuenta comprometida, ¡A limpiar!
Lo primero que hay que hacer cuando una cuenta se ha visto comprometida es cambiar la clave. A ser posible por una más fuerte. Si somos muy paranoicos quizás sería mejor incluso eliminar la cuenta y crear otra.
Por mi parte, los pasos que seguí:
- Cambiar clave y enviar la nueva clave al usuario por mensajería instantánea.
- Bloquear direcciones IP e incluso los bloques de direcciones del mismo rango.
-
Eliminar los emails enviados por esa cuenta (empleando
postqueueypostsuper).
El ruso no se rinde. Comienzo a ver más direcciones IP entrantes hacia la misma cuenta y otras cuentas. Intentando hacer de nuevo fuerza bruta. En este caso, bloqueo direcciones IP insistentes o masivas y dejo el resto del trabajo a fail2ban agrandando el tiempo de bloqueo y acortando el número de intentos.
Conclusiones
En una guerra no hay vencedores ni vencidos desgraciadamente. El atacante pudo hacer un daño durante el tiempo que no fue detectado y finalmente fue expulsado de la cuenta que había capturado. En mi lado, el daño ya estaba hecho.
Tuve que eliminar la dirección IP de las listas de spam, lo cual llevó una cantidad de trámites (online) bastante importante y algún tiempo de espera hasta que GMail y otros comenzaron de nuevo a confiar en el dominio y la IP de origen. En algunos casos he optado por cambiar directamente de IP para acelerar este proceso.
Mantener la seguridad en el servidor es importante. Los fallos de esta vez para mi fueron:
- No insistir a los usuarios con la importancia de poner claves buenas y fuertes, muy fuertes.
- No haber vigilado más los intentos de fuerza bruta sobre ese dominio y ajustar antes los parámetros de fail2ban.
Esta vez hemos salido del paso, pero esto ha sido solo una batalla. La guerra sigue librándose día a día. ¿Qué estrategias de seguridad empleas o emplearías? ¡Déjanos tu comentario!
