¿Cómo solucionar el servidor de email enviando spam ?

Tuve un problema con uno de mis servidores en donde Amazon me dice que el servidor está enviando spam ( Amazon EC2 Abuse Report ). Este post es para demostrar el como lo solucioné para que no eliminaran la máquina virtual.

Ok, esto me había pasado anteriormente pero había sido más sencillo de encontrar. En mi caso al parecer fue un exploit de wordpress, que aún debo descubrir, con cual es con el cual subieron unos archivos a mi servidor que les permitieron tener acceso a mi servidor.

Antes de iniciar la búsqueda del Xploit hay que evitar que el servidor siga mandando los mails, en mi caso estaba mandando “muchos” emails por segundo como lo muestro a continuación ( /var/log/mail.log ) :

Sep  9 14:20:09 ip-10-10-10-69 sm-mta[15189]: t88AKWIF028943: to=<[email protected]>, delay=1+03:59:36, xdelay=00:00:00, mailer=esmtp, pri=14161449, relay=mta6.am0.yahoodns.net., dsn=4.0.0, stat=Deferred
Sep  9 14:20:09 ip-10-10-10-69 sm-mta[10782]: t84F0QGk008417: to=<[email protected]>, delay=4+23:19:43, xdelay=00:00:00, mailer=esmtp, pri=46651427, relay=mta7.am0.yahoodns.net., dsn=4.0.0, stat=Deferred: Connection reset by mta7.am0.yahoodns.net.
Sep  9 14:20:09 ip-10-10-10-69 sm-mta[13194]: t87Ex5gs029908: to=<[email protected]>, delay=1+23:21:04, xdelay=00:00:00, mailer=esmtp, pri=21001484, relay=mta7.am0.yahoodns.net. [98.138.112.34], dsn=4.0.0, stat=Deferred: 421 4.7.1 [TS03] All messages from 54.152.254.77 will be permanently deferred; Retrying will NOT succeed. See http://postmaster.yahoo.com/421-ts03.html
dsn=4.0.0, stat=Deferred: 421 RP-001 (BAY004-MC3F37) Unfortunately, some messages from 54.152.254.77 weren't sent. P...t per hour and per day. You can also refer to http://mail.live.com/mail/troubleshooting.aspx#errors.
Sep  9 14:20:10 ip-10-10-10-69 sm-mta[12118]: t86NQsov021294: to=<crazyrus[email protected]>, delay=2+14:53:16, xdelay=00:00:00, mailer=esmtp, pri=26401429, relay=mta7.am0.yahoodns.net., dsn=4.0.0, stat=Deferred: Connection reset by mta7.am0.yahoodns.net.

En mi caso mi servidor estaba usando SendMail, por lo que lo desinstalé temporalmente para poder solucionar el problema.

Luego la idea es evitar que quien fuera que accedió a wordpress pueda hacerlo nuevamente, por lo que es buena idea cambiar todas las claves de los usuarios.

Ahora habría que agregar una herramienta que detectara el malaware del sitio, en mi caso instalé Sucuri Security que no encontró ningún problema pero que me ayudó a darme cuenta que estaba siendo víctima de un Brute Force Attack.

Un Brute Force Attack consiste en intentar entrar a tu sitio intentando cada clave posible, de ahí el termino de fuerza bruta, sin ninguna inteligencia por detrás. Está de más decir que existe la posibilidad de que se haya encontrado la contraseña de administrador y que de esa manera pudieron acceder al sitio y subir los scripts que mandaban los correos spam.

Jetpack tiene una herramienta muy buena que ayuda a prevenir este tipo de ataques y viene activada por defecto, por lo que recomiendo instalar este plugin. Otra alternativa es el plugin Brute Force Login Protection que hace exactamente lo que dice su nombre, prevenir estos ataques agregando los IPs que lo intentan a una lista negra para que no puedan acceder al sitio.

En general cuando ingresan un script malicioso a tu servidor, la idea es que este sea ubicado en algún lugar que no pueda ser borrado, por lo que dentro de un plugin, los temas o el core de wordpress es pésima idea debido a que después de una actualización el contenido sería eliminado. De todas formas reinstalar wordpress, los plugins y los temas nunca es una mala opción para poder descartar algún problema.

Si revisamos nuevamente el archivo mail.log podemos ver si los correos se siguen enviando o no .

Sep  9 15:36:33 ip-10-10-10-69 sm-mta[15797]: t886MG8i009210: to=<[email protected]>, delay=1+09:14:17, xdelay=00:00:00, mailer=esmtp, pri=16051438, relay=mta6.am0.yahoodns.net. [98.138.112.38], dsn=4.0.0, stat=Deferred: 421 4.7.1 [TS03] All messages from 54.152.254.77 will be permanently deferred; Retrying will NOT succeed. See http://postmaster.yahoo.com/421-ts03.html

En mi caso se seguían intentando enviar y esto era debido a que sendmail a pesar de haber sido desinstalado seguía en memoria, pero al no existir estos no eran enviados.  Eliminando la aplicación de memoria debería ayudar.

  sudo killall sendmail 
  sudo killall sendmail-mta

Teniendo todo esto, evitamos que puedan subir nuevamente scripts malintencionados al sitio de wordpress y eliminamos la posibilidad que esté dentro de un plugin, del tema o wordpress, ahora nos queda simplemente encontrar el script encargado de enviar los mails si es que aún no lo hemos eliminado.

Antiguamente simplemente buscaba con “grep -r” todas las coincidencias del texto “mail(” en los archivos php de mi sitio y era muy fácil de encontrar. Está de más decir que esto no dio ningún resultado, por lo que continué en la búsqueda del script malicioso.

Bajé una versión de wordpress desde el servidor y comparé los archivos que estaban con los que no deberían de estar ahí, muchos de ellos se veían inofensivos pero de todas maneras los borré, no tenían razón de estar ahí. Haciendo esto también encontré un archivo que debería de ser inofensivo llamado wp-apps.php pero algo me llamó la atención. Un gran texto encriptado en base 64, que además estaba comprimido y luego evaluado… Esto no podía ser algo bueno.

EVAL BASE64
Exploit comprimido y evaluado en base64

Eliminando el archivo y evaluando su contenido me pude percatar que poseía un exploit que permitía que alguien pudiera acceder directamente a mi servidor.

PHP XPloit
PHP XPloit para acceder al sistema de archivos.

Sabiendo esto ahora la idea es buscar una coincidencia de los archivos en donde tenga algo codificado en base64 o simplemente usando la función eval. Encontré un archivo más que tenía estas características y procedí a eliminarlo.

Ya teniendo todo eliminado y con la seguridad reforzada no he tenido problemas.

En resumen :

  1. Eliminar la posibilidad de seguir mandando mails.
  2. Cambiar las claves por unas más seguras.
  3. Reforzar el servidor contra ataques de fuerza bruta.
  4. Encontrar y eliminar la vulnerabilidad.
  5. Revisar si pudiera haber otra.
  6. Estar atento por si el servidor presenta nuevamente un problema similar.

Eso debería ser todo, espero que a alguien le sirva.

2 Replies to “¿Cómo solucionar el servidor de email enviando spam ?”

Deja un comentario

This site uses Akismet to reduce spam. Learn how your comment data is processed.