La reciente operación contra la botnet Rustock por parte de Microsoft, hace escasos dos meses, seguramente tenga algo que ver. También la desactivación de la botnet Waledac el año pasado. No hay más que ver las gráficas al respecto:

Parece que toda la “industria” del malware se está dirigiendo más hacia las redes sociales; no hay más que ver el éxito cosechado por campañas de videos con virus o el “botón no me gusta” de Facebook y la facilidad de engaño que tienen.
Veremos cómo se presenta el futuro, sobre todo con la entrada de IPv6 en juego, que seguro que da un nuevo empuje a las botnes. Nos encontraremos con la problemática de la gestión de RBLs para la gran cantidad de IPs disponibles que habrá.

18 Mayo 2011 (miércoles)

Esta sesión será cerrada a miembros del Foro ABUSES

09.30h-10.00h Recepción

10.00h-10.45h Bienvenida y presentación Brigada Investigación Tecnológica (BIT)

10.45h-11.00h Descanso, café y tertulia

11.00h-12.00 Propuesta de Objetivos Foro ABUSES
Moderador: Susana Rey

12.00h-13.30h Evolución del Foro para consecución de Objetivo
Moderador: Carlos Olea (Telefónica Internacional)

13.30h-16.00h Comida

16.00h-17.00h Conclusiones sobre evolución del Foro

17.00h-18.00 Propuesta de proyecto colaborativo en la lucha contra la propagación del malware. Roberto (Abbansys)

19 Mayo 2011 (jueves)
10.00h-10.45h Experiencias de la Guardia Civil

10.45h-11.00h Descanso, café y tertulia

11.00h-12.30h Temas varios:

Sistema de intercambio de firmas malware. Roberto Navarro (Abansys)
Red de spamtraps de RedIRIS
Caso estudios sobre el último bloqueo de hotmail
Nueva herramienta colaborativa para Foro ABUSES

12.30h-13.00h Próxima reunión

13.30h Comida comunal

Así que lo que antes era un Internet-draft, ahora ya es un RFC, el RFC 5965. Ahora solo falta lo más complicado…que todos los ISPs empecemos a adoptarlo :)

Día 20 de abril (martes)

# 10.00-10.30 Recepción y desayuno

* Bienvenida
* Actividades de Telefónica en la protección al menor
* Caso de estudio en fraude bancario. Marc Vilanova (CAIXA-cert)
* Retrospectiva de políticas actuales de Telefónica en el filtrado BGP de direcciones IP. Desde Blackhole hasta mitigación de DoS. Carlos Olea

* Seguridad en el futuro escenario de IPv6. Juan Pedro Cerezo (BT)

# 13.30-15.30 Almuerzo de trabajo ofrecido por Telefónica

# 16.00-18.00h. Intercambio de experiencias entre los miembros del Foro

* Políticas de actuación contra el malware en Telefónica
* Proceso de bloqueo del puerto 25 de salida en EUSKALTEL
* Experiencia de defensa contra Confiker usando listas de reputación. ABBANSYS

Día 21 de abril (miércoles)

Sesión cerrada y exclusiva para miembros del Foro ABUSES

# 10:00-10.30h Actividades de Telefonica en la protección al menor

# 10.30h-11.30h Presentación de nuevos Grupos de Trabajo
# 11:30-12:00h Desayuno.

# 12:00-13:00h Desarrollo de Grupos de Trabajo
# 13.00-13.30h

* Exposición conclusiones de grupos de trabajo
* Asuntos internos foro: Accesos al wiki, solicitudes de miembros, Eurodig
* Próxima reunión

El objetivo es evitar que los equipos de nuestros clientes puedan ser utilizados sin su consentimiento para envío masivo de SPAM, PHISHING y otras amenazas emergentes a día de hoy en Internet

Parece, no obstante, que el bloqueo se produce solamente a sus redes de IPs dinámicas.

Si por ejemplo, un cliente de Euskaltel tuviese un servicio de correo contratado en una empresa de hosting como puede ser Hostalia, simplemente cambiando el puerto de salida del 25 al 587 (como reza el RFC 2476 – Message Submission) en su cliente de correo, podría seguir usando dicho servicio.

Telefónica ya consiguió en su día salir de los primeros puestos de redes emisoras de spam con esta medida y a pesar de las quejas iniciales, todos nos hemos visto beneficiados por esta medida.

No queda más que decir que bien por Euskaltel y que a ver si el resto de ISPs siguen las mismas políticas.

Este año se celebra en A Coruña, organizada conjuntamente por Mundo-R y RedIRIS/Red.es

La agenda de la reunión es la siguiente:

Dia 20 de Octubre (martes)

* 10.00-10.30 Recepción y Bienvenida

* 10.30-13.30 Sesión 1

Mejores prácticas entre fiscales, ISPs y Fuerzas de seguridad del Estado

Debate y puesta en común. Se contará con la presencia de Luis M. Uriarte Valiente: (Fiscalía Provincial de Pontevedra, Miembro del Servicio de Criminalidad Informática (SCI) )

Presentación de la “Oficina de Seguridad del Internauta” INTECO-cert

* 16.00-18.00h. Sesión 2 (tarde):

Intercambio de experiencias entre miembros del Foro

o Experiencia de soluciones antispam: CloudMark , Commtouch etc
o R: “Sobre análisis de protocolos y búsqueda de IRCs de control de botnets”
o ARSYS: “Experiencias abuses”
o Dynahosting: “Nuevo miembro del Foro ABUSES”

Día 21 de Octubre (miércoles)

* 10.00-13.30h. Sesión cerrada y exclusiva a miembros del Foro ABUSES

Experiencias con implementación de herramientas para los requerimientos de la Ley de Retención de Datos. Solución implementada en EUSKALTEL.

Asuntos internos Foro ABUSES

* 13.00-13.30h Sesión final

Conclusiones y próxima reunión

Durante el foro, haré una presentación de nuestra experiencia con Cloudmark, un software antispam que llevamos tiempo probando con interesantes resultados.

Esto es más aceptable; se soluciona el problema para evitar más envío de spam y se da de baja la IP de dicha lista negra. Hasta aquí correcto. El problema viene con listas que o tienen una política dudosa de listado (como listar rangos completos sin motivo alguno) o ponen mil impedimentos para dar de baja tu IP.

Por ello, desde el Foro Abuses, se acordó sacar un documento de consenso para comentar las listas más conocidas y ver cuáles eran las que más problemas nos acarreaban.

El documento final, muestra una serie de puntuaciones sobre las RBLs en base a varios criterios y califica a varias de ellas como “no recomendables” para su uso, como APEWS, SPAMCANNIBAL, UCEPROTECT…etc.

Este documento, obviamente, es público y se le puede dar la difusión que se considere (para eso está ;-) ).

Es común ver en los webmails, ya no solo de ISPs como el nuestro sino también en servicios gratuitos de correo electrónico como Hotmail, Gmail, Yahoo…etc el típico botón de “reportar como spam” para que el usuario pueda indicar que el email recibido es correo no deseado por él. Parece no obstante, que este botón se está convirtiendo en algo “peligroso”.

Leyendo un interesante artículo llego a la misma conclusión que el autor. El botón de “reportar como spam” no sirve para desuscribirte de una lista de correo a la que estabas apuntado. Es la tendencia que estoy viendo últimamente; el proceso sería:

1. Un usuario ve una lista que le pueda interesar y se apunta
2. Si es una lista “double opt-in” deberá contestar un mensaje de confirmación de alta
3. El usuario, empieza a recibir los mensajes de la lista
4. El usuario ve que realmente no le interesa por lo que para dejar de recibir dichos mensajes, en vez de usar el formulario de desuscripción que suele aparecer en el final del mensaje, empieza a marcar esos mensajes como spam

Es en este cuarto paso cuando empiezan los problemas (sobre todo para el emisor legítimo de esa newsletter). Y realmente es lo que esto se está haciendo últimamente. El usuario final, supongo que por vagancia, en vez de cumplimentar el proceso de baja de la lista empieza a marcar esos mensajes como spam; esto provoca que el emisor de los correos pueda tener problemas de bloqueos debido a que sus usuarios lo catalogan como correo no deseado (a pesar de haber permitido su envío al apuntarse a la lista).

Hotmail por ejemplo, toma muy en cuenta este feedback y puede convertir la IP de un servidor que envía correo de forma legítima, en una IP con reputación baja y que no puede enviar más mensajes. Además, está provocando que otros usuarios que sí quieren recibir esa newsletter no puedan hacerlo.

Para paliar esta tendencia, existen servicios como JMRPP que permiten a los administradores de listas de correos, qué mensajes son calificados por sus usuarios como spam, para poder así desuscribirlo directamente de la lista.

Por lo tanto, si quieres desuscribirte de una lista de correo, tómate 20 segundos de tu tiempo para hacerlo correctamente, por favor :-)

Los ISPs cuando recibimos un ataque, mensaje de spam…etc solemos avisar al propietario de la red en la que se encuentra la IP origen para que resuelvan el problema (esto se indica en el WHOIS de la IP). Hasta ahora, cada ISP tenía su forma de enviar estos mensajes (llamados Feedback Loops pero ahora, en vez de enviar el típico email diciendo “tu IP manda spam, revisa tu servidor en busca de scripts/virus”, se está intentando estandarizar el formato de estos avisos para poder hacer más fácil la creación de parsers y herramientas de lectura y procesado; vamos, facilitar la vida a la gente de seguridad/abuse.

La última versión del draft ha sido publicada el 17 de Abril y puede leerse en:

http://www.shaftek.org/publications/drafts/abuse-report/draft-shafranovich-feedback-report-07.txt

Desde hoy mismo, los avisos automáticos de nuestra lista negra, rbl.dns-servicios.com se harán en dicho formato.

Sin embargo, los mensajes ARF de Hostalia tendrán el asunto como el mensaje original (el mensaje de spam) como dice el borrador precedido del texto “Abuse Report for IP X.X.X.X:” para permitir buscar fácilmente por IP, ordenar mensajes…hasta que el ARF sea RFC y los destinatarios hayan actualizado sus filtros y parseadores para permitir ARF.

Actualmente, AOL ( en su portal se puede leer ) y Outblaze envían ya sus avisos en este formato y nosotros nos unimos a esta iniciativa pionera a la espera de que se estandarice.

Para más información: http://postmaster.hostalia.com/arf.es.html

Y para recursos sobre ARF: http://wordtothewise.com/resources/arf.html

Que siga así :-)