#DNSFLAGDAY is coming!

Estas última semanas se está generando bastante revuelo en torno a los servidores DNS y dominios en general, debido a la campaña #DNSFLAGDAY.

Con dicha campaña, los principales desarrolladores de software de resolución DNS (Bind, PowerDNS…) junto con empresas como Cisco, Facebook, Google…están invitando a los proveedores DNS (autoritativos y/o de resolución) a que actualicen sus plataformas en caso de no ser completamente compatibles con el estándar DNS, de lo contrario, a partir de mañana, día 1 de Febrero de 2019, puede que las respuestas DNS sean excesivamente lentas (lo cual impacta en todas las conexiones del resto de protocolos) o incluso que el dominio deje de resolver.

Como bien comentan, durante muchos años se ha estado arrastrando el soporte de software muy antiguo, no estándar y que no permite la evolución del protocolo e implementación de mejoras, de ahí que haya llegado el momento de cortar por lo sano. Por ejemplo, hay servidores que no responden correctamente a las queries relativas a EDNS, una extensión del protocolo que permite paquetes UDP más largos de los 512 bytes habituales (ojo en este punto que hay firewalls que tampoco lo soportan y deben ser actualizados también), nuevos flags…etc.

Por lo tanto, lo primero que habría que hacer es comprobar si tu dominio va a seguir funcionando correctamente, algo que puede hacerse desde el formulario de la web http://www.dnsflagday.net. En ella, se mostrarán los resultados sobre los NS del dominio consultado, indicando si va a tener problemas o si cada uno de los servidores DNS autoritativos del dominio, sigue los estándares. En caso de que salga algún error «rojo», mejor contactar rápidamente con tu soporte o administrador de sistemas ya que puede que a partir de mañana, tengas problemas.

Cuando los resolvers DNS de Google no resuelven

Cuando un dominio no resuelve en los resolvers DNS públicos de Google (8.8.8.8 y 8.8.4.4), lo primero que piensas es que tiene algún fallo en sus registros DNS (los NS de la zona, por ejemplo), que el dominio ha caducado…etc. Pero cuando compruebas que todo es correcto y que el resto de resolvers responden bien a a las consultas DNS, entonces se acaban las ideas.

Buscando errores similares, llegué a un artículo que comentaba:

Google’s Public DNS service is now performing DNSSEC validation for all DNS queries by default!

We have recently enabled validation by default globally, and you should now get SERVFAIL for validation failures. Apologies again for the original, unclear announcement.

Sigue leyendo

Postfix con DKIM y múltiples dominios

Tras pruebas varias e integraciones con otros sistemas de la plataforma, ya estamos firmando, desde hace unos meses, correos salientes con DKIM (RFC 5585).

¿Y qué es DKIM? Es una idea desarrollada a partir de DomainKeys e IdentifiedMail que
garantiza que un mensaje procede de un determinado sitio. Es usado por grandes proveedores como Yahoo, Gmail, Hotmail…etc.

DKIM usa claves públicas/privadas para certificar el origen de un email a través de DNS. Se crean dos claves, la pública se publica en un registro TXT del DNS del dominio cuyos mensajes se quieren firmar y la privada se usa para crear la firma digital de los mensajes añadiendo el resultado en una cabecera del propio mensaje a enviar.

El servidor destino, consultará la clave pública y chequeará que se corresponde con la clave que ha firmado el mensaje.

Sigue leyendo

Bajada histórica del spam

Ya comentamos en el pasado Foro Abuses varios de los ISPs allí reunidos, que habíamos notado un descenso bastante acusado de los niveles de spam y rechazo por RBLs.

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:

RBLs

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

XI Reunión del Foro ABUSES

Los próximos 18 y 19 de Mayo se celebra la ya XI reunión del Foro ABUSES. En ella nos reuniremos los equipos abuse y administradores de correo electrónico de los principales ISPs españoles. A continuación, la agenda prevista:

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

ARF tiene ya su RFC

Hace tiempo que venimos hablando de ARF (Abuse Reporting Format) como sistema de reporte de abusos entre ISPs.
Incluso en alguna presentación pude hablar sobre ello:

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 :)

X Reunión del Foro ABUSES

Una nueva edición del Foro Abuses, esta vez en el Edificio Distrito C de Telefónica. La agenda, completita e interesante, como siempre:

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

Euskaltel bloquea el tráfico saliente hacia el puerto 25

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.

IX Reunión del Foro ABUSES

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.

Recomendaciones de RBLs del Foro Abuses

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