Politica DMARC

Últimamente me las están metiendo dobladas :D.

Hace un par de semanas alerté que habían conseguido tumbar la página durante hora y media gracias a un ataque de negación de servicio DoS que conseguimos contener, sobre todo gracias a haber previamente habilitado CloudFlare como proxy inverso.

Pues el otro día, Muhammad Arslan, un auditor de seguridad que por su nombre, y porque me escribía en perfecto inglés, supongo que muy lector de esta página no debe ser, me alertaba de que era posible hacer una suplantación de identidad al correo @pabloyglesias.com.

Pensé al principio que se trataba de una estafa.

A fin de cuentas, ya en su día configuré el SPF, DKIM y DMARC del correo.

Pero tras hacer una prueba rápida en MXToolBox.com (EN), me di cuenta de que, en efecto, aunque tenía todo lo anterior correctamente definido, el DMARC lo tenía marcado con una política permisiva, lo que quiere decir que, en la práctica, cualquiera con conocimientos técnicos podía, en efecto, firmar correos con el dominio.

Ojo que no soy el único.

De hecho, por eso de cotillear a ver si habían hecho los deberes el resto de compañeros de profesión (desde consultores externos a algunas de las grandes empresas de seguridad de este país), me di cuenta que casi todos suspenden en esto.

  • O no tienen tan siquiera un DMARC.
  • O si lo tienen, tienen la política DMARC configurada como permisiva, como era mi caso.

Pero oye, eso no quita que el bueno de Muhammad tuviera razón, así que me puse el fin de semana con ello, y quería explicar aquí, a grosso modo, cómo deberíamos configurarlo en nuestros dominios.

Sobre el DMARC Policy

Ya dediqué en su día una pieza en profundidad a explicar la importancia del SPF, DKIM y DMARC, así que no voy a repetirme.

Si esto te suena a chino, lo mejor es que empieces por ese tutorial, y luego, cuando lo completes, vuelvas a esta pieza.

Para el tema que nos importa, el DMARC vendría a ser una serie de directrices que el administrador del dominio indica a los receptores para sepan que los correos electrónicos enviados desde ese dominio están protegidos por SPF y/o DKIM, dando a las herramientas de correo una serie de instrucciones en caso de que alguno de ellos no sea validado (por ejemplo, que se marque como Spam).

El problema, como decía, es que aunque en efecto yo lo tenía bien definido, lo había configurado de forma permisiva, por lo que realmente informaba de lo primero (este correo cuenta con este SPF y este DKIM), pero no recomendaba al receptor qué hacer en caso de que la validación fallase.

¿Conclusión? Que al no definir nada, la mayoría de gestores de correo se tragan el email sin problemas.

Y esto es lo que puede aprovechar un cibercriminal para hacerse pasar por mí y enviar, a mi nombre, contenido malicioso.

Un ataque de Email Spoofing de guión, vaya, del cual también hablamos por estos lares no hace mucho.

Afortunadamente es sencillo de solventar. Basta con configurar el DMARC como:

  • O Quarantine: Es decir, que si no se puede validar, que se etiquete como SPAM.
  • O Reject: Es decir, que si no se puede validar, que lo rechace.

Y para hacer esto, hay que modificar (o crear si no lo teníamos) una nueva DNS en nuestro editor de zonas del servidor/dominio:

  1. De tipo TXT.
  2. De nombre _dmarc.NOMBREDELDOMINIO.EXTENSION.
  3. De tiempo de expiración automático.
  4. De contenido:
v=DMARC1; p=quarantine; sp=quarantine; rf=afrf; pct=100; ri=86400;rua=mailto:CORREODEERROR

Sobra decir que tanto NOMBREDELDOMINIO.EXTENSION como CORREODEERROR debemos cambiarlo por lo que corresponda.

Por ejemplo, pabloyglesias.com y [email protected]

En mi caso, además, la cosa se complicaba un pelín ya que realmente quien gestiona las DNS del dominio no es mi proveedor de hosting, sino CloudFlare, así que tuve que hacerlo ahí. Eso y que yo realmente envío correos desde el servidor… y desde MailChimp, por lo que era importante que previamente estuviera bien configurado todo lo anterior, o los correos de la newsletter no les iba a llegar a nadie.

Luego toca esperar a que se propaguen las DNS, y andar muy al loro de que no la hayamos liado, ya que con el cambio podemos estar haciendo que, a partir de entonces, nuestros correos lleguen siempre a SPAM.

Bonito, ¿verdad?

Pues bueno, que esto ya lo hice hace como un par de semanas, y a priori no he notado ningún problema a la hora de enviar y recibir correos, así que quiero pensar que ya está todo funcionando correctamente (eso o precisamente no me estoy enterando de que están fallando mis envíos).

En fin, que una configuración extra que me ha mantenido entretenido unas cuantas horas.

Y un aviso para navegantes.

Que veo por ahí muchos dominios de grandes multinacionales que al parecer son vulnerables, como lo era yo, a este tipo de ataques G.G.

________

¿Quieres conocer cuáles son mis dispositivos de trabajo y juego preferidos?

Revisa mi setup de trabajo, viaje y juego (ES).

Y si te gustaría ver más de estos análisis por aquí. Si el contenido que realizo te sirve en tu día a día, piénsate si merece la pena invitarme a lo que vale un café, aunque sea digitalmente.