www.alvaromarin.com

Como hace tiempo hizo Telefónica y como podemos ver a través de su centro de seguridad Nemesys, Euskaltel ha pasado a bloquear el tráfico saliente hacia el puerto 25 para alguna de sus redes.
Como dicen en su web:

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.

Comments(0)

El próximo 20 y 21 de Octubre se celebra la IX reunión del Foro Abuses, que para el que no sepa qué es (c&p):

El Foro ABUSES es un espacio para técnicos de Operadores (telcos o ISPs) que gestionan o están interesados en solucionar incidentes de seguridad y abusos en Internet. En estas reuniones del Foro ABUSES se pretende mejorar la confianza entre ISPs españoles a través de reuniones participativas que generen conclusiones y acciones.

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.

Comments(2)

Es común en los ISPs tener problemas con ciertas RBLs ( hasta Telefónica los tuvo con Hotmail hace poco aunque estos últimos no usen RBLs públicas sino más bien sistemas de reputación); son miles los clientes y las IPs que se gestionan, y siempre puede haber alguna intrusión en algún servidor, algún cliente al que le han robado el usuario/contraseña…etc.

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á ;-) ).

Comments(4)

En los sistemas antispam, el feedback de los usuarios finales es algo fundamental. Son ellos al fin y al cabo quienes reciben el correo y nos permite ver qué efectividad de filtrado tenemos, qué casos de falsos positivos existen…etc. Esos reportes nos permiten que podamos corregirlos o tomar las medidas oportunas en cada situación.

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:

(Lee el artículo entero)

Comments(5)

Supongo que para muchos el asunto no dice mucho, pero a modo de resumen, ARF (Abuse Reporting Format) es un formato que deberá ser estándar en breve (está en su séptimo draft) para los avisos de abusos.

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

Comments(0)

Como nota curiosa, SpamHaus nos concede una estrella de reconocimiento como red proactiva de no tolerancia al spam. Desde el equipo de abuse de Hostalia, estamos comprometidos con este asunto y tratamos los casos de spam/phishing/seguridad con toda la seriedad posible para acabar con ellos lo más rápido posible.

Que siga así :-)

Comments(2)

Ya han pasado 13 días desde que comentábamos la desaparición de McColo en la red de redes. En diversos medios se han comentado la pronunciada bajada de mensajes de spam recibidos por distintos ISPs.

Por ejemplo, SpamCop muestra las estadísticas en su web del último mes:

Nosotros también seguimos notando dicho descenso.

Si por ejemplo miramos los mensajes recibidos (contando los rechazados por RBLs y otros motivos y los procesados), lo vemos claramente:

Y si vemos la relación de correo legítimo (en verde) con el correo calificado como spam (en rojo), de los mensajes analizados por la pasarela antispam (una vez pasada la conversación SMTP), también es percibida:

Por tanto, seguimos con esa tranquilidad…pero como comentaba en el título de este post, da la sensación de ser una “tensa calma” ya que seguramente en unos días veamos el resurgir de mensajes no solicitados para volverse a establecer en los umbrales que teníamos meses anteriores o incluso más, debido a la campaña de navidad que realizarán (y más con la “crisis”).

Comments(11)

Esta mañana, al ver las gráficas de conexiones entrantes, mensajes rechazados…etc en nuestros relays de entrada, he notado un bajón importante en cuanto a spam recibido. La gráfica siguiente lo muestra claramente, cómo a partir de última hora de ayer empiezan a bajar los rechazos por listas negras (línea negra, rosa y verde):

(Lee el artículo entero)

Comments(3)

Parece que la ICANN se está empezando a tomar las cosas en serio. Acaba de retirar la acreditación de registrador a EstDomains, como se puede ver en esta nota:

http://www.icann.org/correspondence/burnette-to-tsastsin-28oct08-en.pdf

EstDomains es un agente registrador que tiene registrados más de 240.000 dominios según WebHosting.info, mediante el cuál se registra(ba)n numerosos dominios para el envío de spam y diversos fraudes a través de Internet. Un informe más completo se puede encontrar en:

http://www.f-secure.com/weblog/archives/00001522.html

En dicho artículo se comenta la relación de EstDomains con Atrivo (también conocido como Intercage), ISP que ha sido noticia recientemente debido al cese del peering con ellos de otros ISPs americanos como UnitedLayer, que cansados de intercambiar tráfico con un ISP dedicado a las “malas artes”, decidieron poner fin a ello.

En resumen, bien por la ICANN!

Comments(3)

Tras un rediseño del sistema de notificaciones enviadas cuando una IP cae en nuestra lista negra RBL.DNS-SERVICIOS.COM, ahora el mensaje incluye una de las evidencias por la cuál ha sido listada. Con ella el ISP responsable de dicha IP podrá buscar el origen del mensaje de spam. Por ejemplo:

http://rbl.dns-servicios.com/ids/evidence.txt

Es curioso, no obstante, el “desastre” con el que uno se encuentra al enviar mensajes de este tipo a los contactos que aparecen en el WHOIS de las IPs:

mail.local: /var/mail/f/fkchung: Disc quota exceeded

Command rejected (in reply to end of DATA command)

Los hay incluso mejores, que pasan directamente de lo que pueda haber o salir de sus redes:

We would point out that, within its activity as a provider of
electronic communication services, XXXX merely provides its
clients with access to the Internet, which entails the activity
of simply transporting information over the network.

No obstante, también se reciben comentarios de agradecimiento por la información facilitada. Por ello y por ayudar a la erradicación de estas fuentes de spam, seguiremos con esta política.

Comments(2)