Solución al aumento de SPAM de estos últimos días

En estos primeros días de Mayo he notado mucho el aumento considerable de SPAM y hablando con los sysadmins que conozco y demas hemos llegado a la conclusión de usar el siguiente script que usa iptables para bloquear las redes bien conocidas de spammers de las listas de spamhaus y okean.

Spamhaus

http://www.spamhaus.org/drop/drop.lasso

Okean

Es una lista exclusiva de redes de spammers chinos y koreanos.
Son lo mismo pero representado de diferentes formas.

http://www.pettingers.org/media/spamblock.txt
http://www.okean.com/antispam/iptabl…wall.sinokorea
http://www.okean.com/sinokoreacidr.txt
http://www.okean.com/sinokorea.txt
http://www.okean.com/antispam/iptabl…wall.sinokorea

Aqui os dejo el dicho script para bloquear las redes spammers de Spamhaus y Okean:

Continuar leyendo «Solución al aumento de SPAM de estos últimos días»

Evitar el SPAM en Plesk 9

Plesk 9, al igual que sus antecesores tiene un pequeño problema de spam. Si no esta bien configurado, el servidor puede ser usado facilmente para mandar spam, el problema viene en la configuración de qmail, si echamos un vistazo a la “whitelist” vemos que tiene configurado el host 127.0.0.0/32, lo cual, hablando claramente, significa que autoriza a cualquier IP a mandar correo a traves de su servidor SMTP… un verdadero problema.

Lo primero que debemos hacer es borrar esta entrada e incluir 127.0.0.1/8, con lo cual limitamos en envio a la ip local.

El problema de hacer esto es que automaticamente hemos desautorizado a que cualquier script dentro de nuestro server envie correo, incluyendo la funcion sendmail() o los correos de wordpress para autorizar usuarios, etc,etc

La solucion es sencilla, añadir una nueva entrada en la whitelist para cada ip configurada en nuestro servidor, del tipo x.x.x.x/8. Ya tenemos el problema casi solucionado

Ahora configuramos la proteccion de spam en blacklisk DNS, es decir, la proteccion DNSBL, añadiendo estas dos zonas, separadas por punto y coma, ta como estan aqui

  • sbl.spamhaus.org;cbl.abuseat.org

Entramos por SSH en nuestro servidor y reiniciamos qmail con

  • /etc/init.d/qmail restart

Y listo…

Enjuto Mojamuto y el SPAM

Aqui os dejo este video de ENJUTO MOJAMUTO (es la risa) relacionado con el spam, phising y demas variantes de la estafa por internet.

Saber el top de dominios que envia mas emails en un servidor (Plesk + QMail)

Siempre es útil conocer quienes son los clientes y dominios que dentro de un servidor envian más email y quienes pueden abusar los recursos. Por eso os voy a copypastear los scripts que me encontre en el blog personal de oscar montero:

Por ejemplo para saber  el top de dominios que más envia emails en un servidor (con qmail y plesk) puedes usar:

grep user  /usr/local/psa/var/log/maillog | grep LOGIN | cut -c50-140 | cut -d,
-f 2 | cut -d@ -f 2 |sort|uniq -c|sort -nk 1

Otra forma sería esta:
Continuar leyendo «Saber el top de dominios que envia mas emails en un servidor (Plesk + QMail)»

Encontrar scripts spammers en el servidor

Cuando el script del spammer es un script realizado en php, el problema que tenemos para localizarlo es que el usuario será apache (a no ser que el servidor use su_exec o similares) y será más dificultoso encontrarlo ya que no puede ser identificado con el nombre de usuario del dominio.

Si se usa Plesk hay dos procedimientos estándares creando wrappers de Sendmail y que suelen funcionar. El propio Plesk lo describe en estos dos artículos:

http://kb.parallels.com/article_22_1711_en.html

http://kb.parallels.com/en/766

Podemos dejar el wrapper funcionando durante algún día para intentar localizar al spammer. Adicionalmente podemos dejar un cron que dispare un fichero con greps del tipo:

grep X-Additional /var/tmp/mail.send | grep `cat /etc/psa/psa.conf | grep HTTPD_VHOSTS_D | sed -e ’s/HTTPD_VHOSTS_D//’ ` | awk ‘{print $2}’ | awk ‘BEGIN {FS=”|”} {print $1}’ | sort|uniq -c | sort -rn

y que nos envié por email los resultados del wrapper.

Una vez conocido el directorio o fichero desde donde se envía el spam, tendremos que comprobar en los logs como se ha logrado el acceso para subir el citado fichero. Normalmente suele haber aplicaciones php muy antiguas que no han sido actualizadas a versiones nuevas. Tendremos que advertir al propietario del sitio que actualice sus aplicaciones, cambie sus claves, revise todos los ficheros e incluso suba un backup anterior. Habrá que eliminar los ficheros maliciosos y colocar restricciones más fuertes al dominio creando un fichero .htaccess o en el propio /conf/vhosts.conf del dominio.

Tales restricciones podrían ser:

php_flag register_globals off

php_flag allow_url_fopen off

php_flag file_uploads off

php_flag magic_quotes_gpc on

php_flag safe_mode on

php_flag disable_functions show_source

php_flag disable_functions system

php_flag disable_functions shell_exec

php_flag disable_functions passthru

php_flag disable_functions exec

php_flag disable_functions phpinfo

php_flag disable_functions popen

php_flag disable_functions proc_open

Adicionalmente habría que revisar los directorios temporales /tmp para comprobar que no hay scripts con usuario apache que estén enviando spam.

Igualmente siempre es utilizar las reglas actualizadas de mod_security para prevenir ataques comunes vía web (el 95% de los ataques son vía web) y herramientas de deteción de intrusos como OSSEC, y Atomic Secure Linux

Sería recomendable añadir a iptables las ips de las maquinas que realizaron el ataque, aunque el atacante atacará desde otras ips sin complicaciones. Incluso puede ser interesante bloquear rangos de ips de forma momentanea si hay un ataque en progreso.