#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

Error temporal para Relay Access Denied en Postfix

Quizás, como buen administrador que revisa los logs de vez en cuando (¿verdad?), hayas visto en los de tu servidor de correo que hay bastantes errores de «Relay access denied«. O quizás en las gráficas que los muestran.
Este error se produce, resumiendo mucho, cuando se intenta enviar un mensaje a un servidor que no acepta correos para el dominio destino (por ejemplo, si intentas enviar correo con destino @gmail.com a los servidores de @outlook.com) o cuando no hay autenticación cuando se intenta enviar correo saliente. Centrándonos en el primer caso, no debería darse con una configuración de DNS correcta (el registro MX) y teniendo el dominio configurado en Postfix como destino, pero suele verse (dominios dados ya de baja de la plataforma, registros MX cacheados…etc), sobre todo si hay altas y bajas de dominios a lo largo del tiempo.

Hasta la versión 2.10 de Postfix, la política por defecto era rechazar este tipo de mensajes con un error permanente (errores de tipo 5XX), por lo que los servidores no reintentaban su envío durante varios días hasta que expirasen.
A partir de dicha versión, se añade la directiva smtpd_relay_restrictions que controla las restricciones de relay. Esto se hace, como bien se indica en la página de ayuda de Postfix, debido a que algunas configuraciones permitían el open relay sin saberlo, es decir, haciendo un PERMIT bajo smtpd_recipient_restrictions a una condición muy amplia (por ejemplo, que el FROM o el parámetro del comando HELO fuesen uno determinado). Para evitarlo, se añade la restricción para relay, de tal forma que aparte de las restricciones anteriores y para evitar esos fallos, quién envía hacia o a través de nuestro servidor se controla con:

smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination

Por defecto, podrán enviar a cualquier destino las redes indicadas en la directiva mynetworks y los usuarios autenticados; el resto de destinos no autorizados (dominios no configurados en mydestination, dominios no incluidos en relay_domains…etc), serán rechazados temporalmente. Es ahí donde se provoca que esos correos rechazados por «Relay access denied» lo sean de forma temporal y no permanente. Cambiando el «defer_unauth_destination» por «reject_unauth_destination«, haría que ese comportamiento cambiase y los rechazos fueran definitivos.

Esto evitará reintentos innecesarios (lo ideal es cambiar los MX de los dominios una vez que estemos seguros que el servicio de correo está bien configurado para aceptar sus correos, y no al revés) por parte de los servidores origen, que en caso de ser plataformas grandes, puede ser bastante tráfico.

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.

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

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

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

Desaparición de mensajes en Postfix

He tenido dudas a la hora de poner un título a este post. El concepto «desaparición» puede que sea algo amarillista, quizás «pérdida de rastro de mensajes» pudiese hacer más justicia a lo que voy a comentar, pero bueno, queda más «Expediente X» el actual ;-)

Todo esto viene debido a que buscando en los logs un determinado mensaje enviado, no se sabía (a priori) qué había pasado con él. Esto es lo que creo (y supongo que todo el mundo cree) que no debe hacer un log, no dejar evidencias de lo que pasa.

Juntar MailScanner con Postfix siempre ha sido muy criticado, sobre todo en la lista de usuarios de Postfix. No hay una interfaz que pase los mensajes recibidos en el demonio smtpd de Postfix a MailScanner, como sucede con otras pasarelas de correo como amavids-new, sino que cuando llegan los mensajes vía SMTP, pasan a la cola hold donde quedan retenidos y MailScanner, con un proceso batch, procede a recogerlos de ahí regularmente para analizarlos.

Sigue leyendo