encontrando al spammer de turno dentro del 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 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 de apache 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 al ataque. 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 a veces he añadido rangos de ips de todo un pais como Rusia (desde donde suele haber más ataques y scripts kiddies hadiendo de las suyas)
