Sender Policy Framework: Buenas prácticas contra el phishing

El envío de correo es un sistema que, por definición, carece absolutamente de seguridad. Esto permite que, por ejemplo, sea tan sencillo falsificar un remitente de un email. Para solucionar esto, se han propuesto varios métodos que son como «parches» en el protocolo SMTP. Uno es Sender Policy Framework (SPF) que se considera una buena práctica contra la falsificación de correos en general y el phishing en particular.

El phishing se suele basar en el envío de correos falsos, que dicen venir de la entidad bancaria. Para conseguir dar credibilidad a estos correos, los atacantes suelen, entre otros métodos, utilizar logotipos de la entidad atacada o el envío desde direcciones pertenecientes al dominio de la entidad. Por ejemplo, es más probable que una potencial víctima del phishing dé más credibilidad a un correo que viene de soporte@banco.com, que si viene de soporte@gmail.com pidiendo las contraseñas de la que es cliente.

Sender Policy Framework se basa en que un correo de un dominio, debe haber sido enviado desde el servidor de correo de ese dominio, y nada más. Cuando un email llega a un servidor, el programa se cuestiona lo siguiente: «Este correo dice venir de @banco.com y ha sido enviado desde la dirección IP 1.2.3.4. ¿Está la dirección 1.2.3.4 autorizada a enviar correos en nombre de ese domino?» Y a continuación le pregunta a @banco.com por sus IPs autorizadas. Sólo los correos enviados desde el servidor de correo legítimo de @banco.com se considerarán válidos.

¿Cómo sabe el servidor qué direcciones IP son las válidas?

Esta información se deja en un registro DNS público de la entidad, en el que básicamente se constata «qué direcciones IP están autorizadas a enviar y con qué política marcar a los correos que no han sido enviados desde ellas». Las políticas, entre otras, que se pueden seguir son éstas:

     .– Dejar pasar los válidos y marcar el resto como «hardfail», o sea, que se marcan en la cabecera como correos falsos a todas luces.
     .– No hacer nada.
     .– Dejar pasar los válidos y marcar el resto como como «softfail», o sea, que se marcan como falsos pero tampoco «tajantemente».

En realidad, las dos últimas opciones se suelen usar para comprobar que funciona en fases de pruebas. Es responsabilidad de la entidad una buena configuración de sus registros DNS para que funcione correctamente el Sender Policy Framework.

Imaginemos que un phisher envía un correo a una cuenta de Gmail cualquiera, diciendo que es seguridad@banco.es y lo envía desde una IP (1.2.3.4) que no corresponde al registro Sender Policy Framework del Banco. Gmail marcará el correo en su cabecera con esto:

      – Received-SPF: fail (google.com: domain of seguridad@banco.es does not designate 1.2.3.4 as permitted sender)

Donde vemos un fail, es decir, hardfail. El administrador del servidor de correo al que llega (en este caso Gmail), decide qué hacer con esto. Por ejemplo, descartarlos o desterrarlos al spam y que no llegue el buzón de los usuarios (que probablemente sea lo más conveniente, tratándose de un hardfail).

En resumen, Sender Policy Framework ayuda a que los correos con el remitente falsificado lleguen en menor medida a las bandejas de entrada de los usuarios, pero no es definitivo. Primero porque el phisher puede usar otro dominio inventado (por ejemplo @soportebanco.com) que no use Sender Policy Framework y también pueda convencer a la víctima. Segundo porque el servidor es quien recibe el email y elige qué hacer con el correo… siempre se marca, pero no garantiza que lo descarte totalmente por fallar en el Sender Policy Framework, aunque puede tomarlo como un punto más en la evaluación como correo basura. Y tercero porque si no se configura bien, el atacante podría usar otros dominios legítimos para engañar al usuario, por ejemplo, enviarlo desde @www.banco.com, que también tendría credibilidad a los ojos de una potencial víctima.

Existen otros métodos más efectivos como DomainKeys Identified Mail (DKIM) para validar el correo, pero son menos populares entre los administradores y mucho más complejos de implementar. La ventaja de Sender Policy Framework es que es trivial de configurar y mitiga en parte el impacto del phishing.

– Más información pulse aquí.