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

Master en Seguridad de la Información @ Universidad de Deusto

Tenía pendiente subir esto desde hace mucho tiempo…dicen que más vale tarde que nunca, así que aquí está. Eso sí, el contenido sigue estando vigente, así que puede que le ayude a alguien de uno u otro modo.

Parcheando MailScanner para soportar long_queue_ids y hash_queues de Postfix

Desde la versión 2.9 de Postfix, hay una directiva llamada enable_long_queue_ids, la cual viene deshabilitada por defecto, que da la posibilidad de que los IDs de los mensajes que gestiona Postfix sean más largos que los de por defecto (por ejemplo: 2FEE85E0213 Vs 3zWlWK2Vxgzd8Wj).

Sin dicha opción, cuando un mismo servidor gestiona cientos de miles de mensajes, puede darse el caso de que el ID que se le asigna a un mensaje se repita a lo largo del día (true history). Esto provoca que la gestión de logs pueda dar problemas debido a que un identificador que debería ser único, no lo es y tenemos asociado a él dos FROMs, dos TOs, dos IP origen…etc.

Además, hay otras directivas llamadas hash_queue_depth y hash_queue_names, en las que se pueden definir qué colas van a estar hasheadas, es decir, los mensajes en ellas se guardarán en un árbol de directorios (esto permite los accesos más rápidos a los mensajes, en vez de tener miles en un solo nivel). Por ejemplo:

/var/spool/postfix/hold/A/F/AF12D45
/var/spool/postfix/hold/A/D/AD64212
/var/spool/postfix/hold/3/B/3B123DF

Con los IDs de cola cortos, como en el ejemplo, se van cogiendo secuencialmente caracteres del ID de mensaje (hasta el valor de hash_queue_depth que en el ejemplo sería «2») para ir creando subdirectorios. Con los IDs largos, esto es más complicado, como veremos más adelante.

MailScanner no tenía soporte para IDs de cola largos y las colas hasheadas, por lo que hubo que remangarse (pizza y café, como decimos por la oficina) y ponerse manos a la obra.

Sigue leyendo

Muere Ray Tomlinson, el creador del correo electrónico

Ray Tomlinson, ingeniero estadounidense creador del correo electrónico, murió el pasado sábado a los 74 años de edad.

Mientras trabajaba en ARPANET, en 1971, modificó el programa sndmsg, que se usaba para enviar mensajes entre usuarios de una misma máquina, para enviar mensajes entre distintos ordenadores. Lo que ahora entendemos por correo electrónico.

Para identificar en qué máquina estaba cada usuario, ideó el uso de la arroba «@» para indicarlo, con el formato: usuario@host. De esta forma, el programa sabía si un envío era a un usuario local o remoto y en caso de ser remoto, a qué máquina enviarlo. Este sistema sigue funcionando ahora, 45 años después.

Sirva esta escueta entrada como humilde homenaje.

Bug de Scan Messages en MailScanner

Unas de las cosas que más gustan de MailScanner es la feature de que cada una de las directivas de configuración, en su gran mayoría, pueden ser un archivo de reglas o una llamada a una función. Esto permite que para cada configuración típica de un sistema antispam pueda diferenciarse en base a cuenta origen/destino, IP origen, dominio origen/destino…etc, lo cuál, permite la personalización absoluta del sistema.

Por ejemplo, a la hora de decidir si un mensaje va a ser escaneado o no, en vez de tener un valor de «yes» o «no» para la directiva de configuración que lo controla, que se aplicaría a todos los mensajes, puede hacerse mediante un archivo de reglas externo:

Scan Messages = %rules-dir%/scanmessages.rules

donde se establecerán las reglas que se deseen, por ejemplo:

From: origen@confiable.com no
From: 192.168.1.10 no
From: /^192\.168\.13[4567]\./ no
FromOrTo: default yes

evitando que se escaneen los mensajes de un determinado FROM, de una determinada IP o de un conjunto de IPs que cumplan la expresión regular. Con el resto de mensajes, se hará lo que el «default» diga, en este caso, «yes» (escanearse).

Sigue leyendo

Open-Xchange

Por fin…tras meses y meses de proyecto (instalaciones, pruebas, workshops, cientos de emails…), salió a la luz :)

Ya se publicó, hace un par de meses, la nota de prensa del acuerdo con
Open-Xchange, la suite colaborativa open source por excelencia. Y ayer fue el momento en que el producto se lanzó y salío a Internet.

No voy a hacer publicidad desde estas líneas, esto es simplemente una reseña por el trabajo de los últimos meses ;-)

Transparencias Master 2010/2011

Ayer mismo terminé de dar las clases en el Master de Seguridad de la Información de la Universidad de Deusto, relativas al módulo «Seguridad en sistemas de correo electrónico». A continuación, las transparencias usadas para la introducción a dicho módulo:

Prioridades en la bandeja de entrada

Hace pocos días, se ha hecho conocida una nueva feature de Gmail, la prioridad en su bandeja de entrada:

La idea como tal no es nueva pero ya sabemos que cuando Google hace algo, parece que lo hace a lo grande :)
Sin embargo, algo parecido ya lo habían puesto en marcha antes Yahoo y Microsoft.

Yahoo con su pestaña «What’s New» ya mostraba los mensajes de correo de los contactos de la libreta de los que hubiese correo y de las conexiones (a través de otros servicios «sociales») antes que cualquier otro; incluso un twitt de un contacto, podía salir antes en dicho tab que un e-mail . Además, las vistas del inbox del webmail de Yahoo ya permitían ver solamente los mensajes de tus contactos, de tus conexiones…etc.

Hotmail por su parte, también había cambiado su página de inicio, mostrando solamente mensajes e información de contactos y amigos. En el webmail, también se pueden usar las vistas «de contactos», «actualizaciones sociales»…etc, para ver lo que más interese. Además, si Hotmail detecta que estás borrando directamente los mensajes de alguna lista a la que te hayas suscrito, te ofrece un botón para desuscribirte fácilmente (para mí, esta es la mejor feature por encima de cualquier otra, por lo ya comentado hace tiempo). Además, desde hace poco, para decidir la acción a realizar con un mensaje, pesa más el resultado del análisis que se haya hecho sobre el usuario que la decisión global. Las métricas que se usan para hacer dicho análisis por usuario son: mensajes leídos y borrados, mensajes no leídos y borrados, mensajes respondidos…etc.

El servicio de Gmail seguramente sea el más completo (también es el último en salir), pero también hay que decir que ha sido el que mejor ha sabido venderse.

Reporte Q2-2010 de Commtouch

Como es habitual en Commtouch, han publicado el reporte sobre el Q2 del 2010. Se puede ver un vídeo o bien, bajarse el reporte en PDF, que incluye gráficas y detalles.

A modo de resumen, cabrían resaltar los siguientes topics:

– 179 billones de mensajes de spam/phishing diarios
– 82% del tráfico en este Q2 es spam, con un pico del 92% en Junio
– Dominios más usados en el FROM por spammers: gmail.com, hipenhot.nl, yahoo.com, 123greetings.com, hotmail.com…
– La mayoría de la «temática» del spam sigue siendo productos farmacéuticos (64%)
– 307.000 nuevos zombies activos diarios
– India, Brasil , Vietnam y Alemania son los países con más PCs zombies

Como siempre, buen trabajo estadístico por parte de Commtouch!

Transparencias Master Seguridad Deusto

A continuación, dejo las transparencias usadas en el Master de Seguridad de la Información, en el que impartí el módulo de Seguridad en sistemas de correo electrónico.

Dicho módulo comenzó con estas transparencias introductorias en las que se da un repaso a todo lo que engloba el servicio de correo electrónico, como son los protocolos y RFCs, MTAs, el problema del spam, botnets, phishing, diversas técnicas antispam, filtrado por contenidos, pasarelas de correo…etc.

Espero que os resulte interesante ;-)