Desde ayer en la tarde algunos servidores comenzaron a recibir una cantidad inusual de mensajes de correo. Varios de ellos provocados por algunos equipos infectados con virus (de aquellos que envían SPAM) y otro tanto de sitios que lisa y llanamento envían SPAM como su «modelo de negocios». En los momentos más álgidos se procesaron entre 1100 y 1800 correos por minuto y a pesar de haber bloqueado mediante iptables a los equipos (internos) y controlar la carga, en la tarde volvió a producirse la misma situación. Muchos de los mensajes terminaban en rebotes, mayor parte de los cuales no podían entregarse, haciendo crecer la cola de salida.
La forma de determinar los equipos infectados paso básicamente por revisar las conexiones en el registro de correo. Sobre 200 conexiones en medio día es bastante sospechoso para una estación de trabajo. Por lo que resultó fácil identificar tales equipos.
Sin embargo, hoy la situación fue algo distinta. Habían sitios con un nivel de conexiones superior a lo normal, pero eran sitios externos y las cifras no eran tan alarmantes de conexiones. por lo demás, podría tratarse de conexiones de correo válido, exceptuando las conexiones caseras, en particular unas tres o cuatro conexiones de la red de VTR.
Verificar las cantidad de conexiones sirve, en este caso, para determinar equipos infectados. Sin embargo, en una sola conexión SMTP se pueden transmitir miles de mensajes, cuyo caso fue de una dirección estableció algunas conexiones (no muchas, como para evitar sospechas), pero en 6 horas intentó enviar más de 65.000 correos. Después de filtras algunas, estas fueron variando, pero todas eran del tipo 196.39.x.x. Por el momento, he filtrado a la red 196.39.0.0/17 (whois indica que es de Internet Solution).
Muchos mensajes se pueden determinar que son SPAM una vez que se analiza su contenido, por lo que el consumo de ancho de banda no se evita y significa mayor carga para los servidores, lo mismo con la cantidad de conexiones. De momento, se añaden a las lista de IP's que no se aceptarán conexiones. Por lo pronto, volveré a activar una RBL local, que permita controlar de manera centralizada (y detener más rápido) a los equipos que se infectan y rechazar a los nuevos spammers.