Archivo de la categoría ‘Internet’

La Autentificación en tiempos modernos. Índice.

Como siempre, empecé con una publicación sencilla y la cosa terminó siendo necesaria una división por partes… A medida que vaya publicando el resto de contenidos, iré actualizando los enlaces.

DNS Over HTTPS/TLS: Encriptado del tráfico DNS

 

A lo largo de los años, la mayoría de los protocolos «base» con los que se constituyó el Internet que hoy conocemos han ido evolucionando, algunos más algunos menos. Es cierto que la base en la que se sostiene es a groso modo la misma, pero no así los protocolos que están encima de la mesa. El mejor ejemplo es el propio protocolo HTTP, que aunque parezca muy antiguo, realmente su primera especificación es de 1991. Vale, son 27 años, pero Internet podemos datarla más o menos por 1980. Sí, a día de hoy el protocolo HTTP es la base de toda la Internet navegable, pero muy poco queda de esa primera especificación de 1991. En 1996 aparecería la especificación HTTP/1.0, en 1999 HTTP/1.1 (la más usada a día de hoy) y en 2015 HTTP/2.0. HTTP ha evolucionado y es posible que continúe haciéndolo, y HTTP/2.0 ofrece grandes mejoras en todos los aspectos frente a especificaciones más viejas.

HTTPS apareció en 1992, un modo ingenioso, práctico y seguro de poder enviar/recibir la información HTTP de forma cifrada punto a punto, es decir, se cifra y descifra en origen, permitiendo conocer si ha existido manipulación en medio y además añadiendo identificación de las partes por medio de certificados digitales. Ahora, en 2018, HTTPS lo vemos como imprescindible, y con los certificados digitales más a mano que nunca hemos visto como el % de webs que lo han implementado se han disparado. ¿Por qué? Porque después de años de hartazgo de las propias instituciones gubernamentales, de fallos de seguridad, de robos de datos… ahora somos más desconfiados que nunca, y nos gusta pensar que, aunque lo que estemos mirando en Internet sea donde comprar un colchón, nadie va a poder saberlo (Bueno, todo tiene sus limitaciones, claro). Realmente su importancia principal fue y ha sido y será, debido al intercambio de datos privados entre usuario y servidores. Desde usuarios y contraseñas, direcciones postales, tarjetas de crédito, expedientes médicos… todo. Cualquier información que no vaya cifrada punto a punto corre el riesgo de ser leída… y ya no solo por posibles «cucarachas» que se conecten a nuestra red interna, sino (y siendo un poco conspiranoicos), gobiernos, entidades, los mismos ISP…

Pero si existe otro protocolo de igual importancia en Internet, o incluso más, es sin duda el protocolo DNS (siempre por supuesto hablando de protocolos a nivel de aplicación).

 

DNS

Lo primero que debemos de tener en Internet es, como todo el mundo sabe, una IP. Una IP es un identificador numérico que no solo nos hace accesible desde el exterior, sino también poder ir a cualquier rincón de Internet. Las IPs son las verdaderas direcciones en Internet, pero en cambio rara vez tenemos que usarlas. El 99% del tiempo que estamos en Internet, nos valemos de un sistema de nombres (aka dominios) para poder acceder a un servicio/sitio u otro. ¿Por qué? Porque nuestra mente, nuestro cerebro, se le da infinitamente mejor recordar nombres o cadenas de caracteres que una sucesión de números. Para nosotros es infinitamente más sencillo recordar «google.es» que «216.58.201.163». Basados en esta premisa fundamentalmente, se creó un sistema de nombres (de dominios), llamado DNS (Domain Name System).

Posiblemente el protocolo DNS es de los más sencillos de entender. DNS funciona como un «traductor», algo así como unas páginas amarillas gigantes. Cuando introducimos un nombre de dominio en cualquier navegador o aplicación, esta envía la solicitud al servidor DNS que tenga especificado, y este será el encargado de resolver la dirección correspondiente al nombre de domino especificado, y el tipo de registro solicitado. En este artículo de hace tiempo puede verse mejor como funciona DNS. Es un poco más complejo debido a que el sistema DNS es distribuido e incluso jerárquico, pero en lo que nos atañe, es tan simple como eso.

El protocolo DNS no ha evolucionado en nada. Es cierto que se ha expandido con los años con la inclusión de nuevos tipos de registros DNS, e incluso mejoró notablemente la seguridad con la inclusión de DNSSec, pero el protocolo en sí mismo es el mismo que el que se empezó a desplegar en 1983. Eso no es malo, cuando algo ha evolucionado tan poco y aun así es usado tan extensamente, es que funciona realmente bien. No obstante, la sociedad ha cambiado, y tal como sucedió con HTTP, DNS no se creó con la privacidad en mente, por entonces había mejor voluntad y posiblemente mejores ideales. A día de hoy sería impensable crear un protocolo sin que la encriptación y autentificación no estuviesen desde el comienzo del desarrollo.

DNSSec ha dotado a DNS de un sistema de «autentificación», de modo que las peticiones DNS resueltas por los servidores DNS pueden verificarse/autentificarse, que proceden realmente del servidor DNS raíz a quien pertenecen. Sin DNSSec, se podría envenenar la caché de un cliente DNS, de modo que peticiones realizadas de dicho cliente fuesen respondidas con una IP falsa. Este tipo de ataques ha sido muy efectivo en el pasado… los mismos resolvers tienen que escalar la petición DNS a los servidores DNS, y en ese proceso puede ser bombardeado con respuestas DNS falsas, con lo que el resolver creer que la IP falsa es la real, y ser la IP que al final devolvería al equipo en cuestión. Cuando DNSSec es usado, el servidor DNS firmará la respuesta DNS con cifrado asimétrico, y las enviará en otro registro DNS conjunto a la petición original, y dicha firma el resolver/cliente puede verificarla con los registros del servidor DNS, que contienen a su vez la clave pública con la que se firmaron. De este modo el cliente puede saber con exactitud si la respuesta que hemos recibido proviene realmente del servidor DNS legítimo.

DNSSec es importante, añade autentificación, pero… ¿que pasa con la encriptación?

 

DNS Over HTTPS/TLS

Los datos que se transfieren por DNS son muy importantes. Vale, no van a contener datos confidenciales de tipo contraseñas, usuarios y otros, pero todo el tráfico DNS que generamos indica perfectamente nuestra actividad en la red. Es por medio de DNS que se filtran contenidos (controles parentales por ejemplo), se bloquean contenidos (autoridades/entidades), los ISP pueden crear enormes bases de datos con nuestras costumbres… simplemente mirando el tráfico DNS podemos saber de una persona una cantidad de información que ni imaginamos!! Pues imaginar eso aplicado a una red local entera, o a una red de una empresa, o, por qué no, toda la red de un ISP.

El protocolo DNS se transmite en formato plano, «legible». Desde hace muchos años han existido varias técnicas para «camuflar» o enmascarar el tráfico DNS, esto no es para nada nuevo. Estas técnicas han sido en su mayoría el uso de servidores VPN por ejemplo, donde las peticiones DNS se enviaban a través del mismo túnel, o usando el conocido DNSCrypt, una solución presentada hace tiempo por OpenDNS, unos servidores DNS independientes y gratuitos que ofrecen una buena tanda de opciones y filtrados para los hogares. No obstante este tipo de técnicas siempre ha tenido un impacto muy pequeño, y un poco por las razones de siempre: Soporte y estandarización.

Ya han pasado muchos años desde que Microsoft no dejase de implementar en su navegador Internet Explorer características propias. A día de hoy intentamos basarnos lo más posible en estándares, protocolos y técnicas que pueden ser usadas en cualquier sitio, que todos los dispositivos puedan entender y poder interaccionar unos con otros obteniendo resultados similares. Puede que DNSCrypt sea/fuese un sistema muy inteligente, pero sin ser un estándar ¿qué servidores DNS o que clientes iban a implementarlo? Por supuesto, era posible usando su servidor DNS y otros software, pero no es una solución real.

Por suerte, y aunque ha costado mucho mucho trabajo, se ve el final del problema gracias a DNS Over HTTPS/TLS (DoH). Me gustaría pensar que los retrasos se han debido al tiempo necesario para crear un estándar sólido, pero honestamente lo que creo es que a la gran mayoría de empresas, gobiernos y otros, cifrar el tráfico DNS es poner fin a un negocio multimillonario, a bloqueos, filtros… es una de esas cosas que públicamente nadie puede estar en contra, pero por detrás es raro encontrar quien esté de acuerdo. Sea como sea, y después de muchos tiros y afloja, DNS Over HTPS ya está «terminando» su camino para ser ratificado por la IETF como estándar, mientras que DNS Over TLS ya está estandarizado. Pero… ¿no son iguales? Bueno, en realidad no, son muy similares. Al igual que el protocolo DNS se usa mediante el puerto 53, DNS Over TLS usa un puerto específico para ello, el 853, y por él envía de forma serializada y ya bajo TLS las peticiones DNS. DNS Over HTTPS en cambio se basa en peticiones HTTPs estándares, usando por ello por defecto el puerto 443, y las peticiones son serializadas dentro de la propia petición HTTPS, creando una pequeña sobrecarga de protocolo inicial.

Aunque ambos sistemas encriptan por igual las peticiones DNS, realmente la diferencia de ellas desde un punto de vista práctico es que usar DNS Over TLS implica usar un puerto dedicado para ello, de modo que resulta mucho más sencillo bloquearlo, filtrarlo, discriminarlo o incluso como veremos luego obtener información de los dominios visitados de forma más sencilla… dicho de otro modo, es más fácil que terceros vuelvan a las andadas, aunque por otro lado es lógico que use un puerto propio. Por otro lado, DNS Over HTTPS usa el mismo puerto 443 que cualquier web HTTPS, con lo que el tráfico no solo pasa mucho más desapercibido, sino que además bloquearlo por puerto/servicio no sería una opción, a todos los efectos la conexión se vería como una conexión HTTPS más.

Usando por tanto DNS Over HTTPS enmascara todas nuestras peticiones DNS de forma doble. Por un lado encripta todo el tráfico DNS de modo que no pueda ser visible para terceros, y por otro lado «engaña» a cualquiera que pueda estar espiando el tráfico, a todos los efectos como si se tratase de tráfico HTTPS convencional.

Esto tiene infinidad de aplicaciones prácticas. Las más evidentes, nos blindan frente al exterior, impidiendo en la medida de lo posible que terceros puedan saber que Webs estamos o no visitando. Por otro lado este sistema permite «pasar por alto» innumerables filtros impuestos por gobiernos/ISP/entidades. Estos no pueden hacer filtros IPs por lo general, así que se filtran a nivel de DNS. Las primeras soluciones a esto eran usar servidores DNS alternativos, pero nada impide a un ISP interceptar las peticiones DNS a otros servidores. Con DoH no pueden evitarlo, las resoluciones nos son devueltas cifradas y bajo un tráfico que podría ser cualquier cosa.

 

Inconvenientes

Visto así, todo parecen grandes ventajas. No obstante el sistema no es perfecto, y además añade algunos «problemas» que no están presentes en las resoluciones DNS estándares.

El primer y posiblemente el mayor inconveniente es el retardo, la latencia. Negociar una conexión HTTPS completa con el resolver DoH, enviar la petición, y obtener la respuesta, consume sensiblemente más tiempo que una resolución DNS estándar. Este tiempo puede reducirse de diversas formas, por ejemplo manteniendo la conexión abierta con el resolver para futuras peticiones DNS o haciendo uso de HTTPS/2.0. Pero aun con todo, no podemos suprimir la negociación requerida para establecer una conexión HTTPS, que es la que se llevará la mayor parte del tiempo. Muchos creen que la mejor forma de evaluar un servidor DNS es ver la latencia hacia ellos, pero eso solo es un % del tiempo, lo que nos importa no es la latencia hacia el servidor DNS, sino el tiempo que va a tardar en respondernos con la dirección.

¿Cuanto es esta aportación a la latencia? Bueno, el mejor modo de comprobarlo es con pruebas reales. Para esta prueba se ha usado el servidor DNS de Google convencional 8.8.8.8, y por otro lado un resolver usando también el servicio DoH de Google, «https://dns.google.com/experimental», en ambos casos deshabilitando todo tipo de cache

URL Servidor DNS 8.8.8.8 DoH https://dns.google.com/experimental
wikipedia.com 35ms 37ms
nic.es 31ms 39ms
facebook.com 11ms 38ms
google.es 32ms 42ms
theliel.es 32ms 38ms
twitter.com 12ms 38ms
elpais.com 38ms 40ms
microsoft.com 12ms 40ms
github.com 30ms 43ms
instagram.com 10ms 36ms

Los datos no son demasiado malos. Para dominios bien conocidos como Facebook, Twitter y otros, la latencia para resoluciones convencionales es mínima, ronda siempre los 10ms, mientras que el resto de hosts ronda una media de 33-34ms. Por contra, las resoluciones a través de DoH muestran un incremento claro, haciendo una media de 40-42ms. Estos resultados son simplificados y realizando medias entre 10 pruebas cada uno. En algunos casos existiendo gran variabilidad entre prueba y prueba.

 

El segundo inconveniente, es su soporte, su implementación. Mientras que el sistema DNS convencional está totalmente integrado en la propia estructura de Internet y podemos lanzar peticiones DNS desde nuestros equipos hacia cualquier servidor DNS, DoH es algo más complejo. Tal es así que actualmente requiere por un lado tener resolvers DoH, «servidores DNS» que sean compatibles con DNS Over HTTPS, que puedan traducir esas peticiones DNS encriptadas, resolverlas y devolvernos la dirección IP. Como es obvio, esos resolvers no elevan la petición DNS a servidores raíces por medio de DoH, sino por el modo convencional, pero esto no nos afecta, a menos que el resolver DoH fuese hackeado y guardase un registro de todas las peticiones realizadas. En todas las pruebas, en mi caso, he usado el servidor/resolver de Google DNS Over HTTPS que tienen habilitado: https:/dns.google.com/experimental.

Pero esto no es todo, así mismo requiere que los dispositivos sean compatibles también con DoH, ya sea a nivel integral en el propio OS, ya sea a nivel de aplicación. Esto es importante, porque como debemos de usar otro modo para realizar las peticiones DNS, requerimos de un software específico para ello, o que la aplicación esté preparada. En nuestro caso, por ejemplo, si usamos las últimas versiones de Firefox podemos habilitar el soporte para DoH de este, o podemos instalar un proxy en nuestro OS para que sea capaz de gestionar todas las peticiones DNS directamente de nuestra red.

En ambos casos, vemos que no es una opción que tengamos que habilitar si/no, requiere más que eso.

 

El tercer problema, y no menos importante, sea llama SNI. La idea detrás de DoH es cifrar las peticiones DNS, entre otras cosas para ocultar completamente los dominios que queremos visitar. El problema es que el uso de DoH no impida totalmente el «escape» de información que podemos tener referidos a los dominios visitados cuando son páginas webs HTTPS. Esto no es un problema de DoH realmente, sino del propio uso de los certificados digitales. Cuando realizamos una conexión HTTPS a cualquier host, el servidor remoto nos enviará en plano su certificado digital en el handbrake TLS. Los certificados digitales poseen una extensión llamada SNI, un campo que permite especificar los diferentes dominios para los cuales se aplica dicho certificado. Este campo no es obligado, es solo una extensión. Antes los certificados se emitían directamente para direcciones IPs específicas, pero con el agotamiento de estas ha sido cada vez más habitual que los servidores webs alojen bajo la misma IP muchas webs diferentes. Esto provoca que la emisión de certificados para una sola IP no sea viable, y se comenzó a usar SNI. Con SNI podemos especificar en el certificado los diferentes dominios, aun cuando todos ellos están bajo la misma IP.

El problema se ve claro, si un certificado que nos envía un servidor especifica el dominio para el cual ha sido emitido (el mismo), esa información también es potencialmente interceptable y usarla para conocer que hemos visitado dicho servidor. Eso no quiere decir que DoH sea inservible ni mucho menos. Para empezar un mismo certificado se emite muchas veces para diferentes dominios, así como consiguientes conexiones al mismo dominio tampoco requerirían de nuevo el certificado del servidor remoto. Otros servidores no usan siquiera SNI, y dentro de poco con la llegada de IPv6 es posible que en un futuro incluso sea común volver a certificados pre SNI, donde lo normal era su emisión para IPs.

Si un servidor nos responde con su certificado donde se especifica en SNI el/los dominios, nada evita que de nuevo se use software que rastree cada certificado que nos respondan los servidores remotos para hacer un perfil de nosotros de las webs visitadas. Pero estos sistemas al margen de ser más raros, tienen muchas limitaciones que de otro modo sería extremadamente sencillo tener un mapa completo del uso que hacemos en Internet, simplemente mirando las peticiones DNS.

 

El cuarto y último problema es que a veces falla. El software actual es limitado y tiene aun fallos que podemos encontrarnos, sin contar los problemas que pueden tener los resolvers actuales. Repito, todo esto es bastante nuevo, con lo que es de esperar algunos problemas, los más normales son resoluciones DNS que no son respondidas correctamente. Para atenuar esto, la mayoría de software cliente que existe permite configurar un servidor DNS convencional como fallover, en caso que DoH nos falle en alguna petición.

 

Como configurarlo

Bueno, por desgracia, y lo hemos visto en sus inconvenientes, no es algo que sea ejecutar y listo. Vamos a depender primero de un resolver DoH que actuará a modo de «proxy» entre DoH y peticiones de resolución DNS estándares. Cuando a estos resolvers les llegue una petición por DoH, la resolverán y nos la devolverán. Obviamente la confianza es esencial, a fin de cuentas que pasaría si dicho Resolver igualmente guardase una base de datos con las IPs originarias de las peticiones y una lista de los dominios accedidos.

Por otro lado como decíamos, requerimos de software o aplicaciones que sean capaz y compatibles con DoH. Ahora que es un estándar es de suponer que el soporte será ampliado enormemente, sobre todo en aplicaciones que nos gustan que sean seguras. Actualmente hay que decir que quedan cosas por pulir, el estándar DoH aun no ha sido alcanzado y algunas cosillas pueden cambiar. Algunos proveedores conocidos ya han lanzado resolvers DoH para poder ser usados de forma pública y gratuita, como Google o CloudFlare. Así mismo existen actualmente también la otra parte, software cliente para que podamos hacer uso de dichos resolvers. En este caso, quizás los dos casos más importantes en este punto sería el propio Navegador Web Firefox y DNSCrypt-Proxy. Al margen de ello, Google ya implementó DoH en Android también.

 

Firefox

El caso más básico y más sencillo de todos vamos a verlo con Firefox. Para ello necesitamos al menos Firefox 62, que si la memoria no me falla debería de estar ahora mismo en el canal Beta, Firefox 63 en Alpha. A partir de aquí es muy sencillo. Por defecto el soporte para DoH viene deshabilitado, ya que es un cambio importante. Básicamente necesitamos sólo realizar un par de ajustes en el editor de configuración. Para quien no lo conozca, el editor de configuración de Firefox se accede desde la barra de direcciones accediendo a: about:config.

 

network.trr.mode: (el modo de funcionamiento de DoH)

0: Deshabilitado
1: Usa ambos modos, DoH y resoluciones convencionales, el navegador usará la que resuelva antes
2: Usa DoH de forma predeterminada, y DNS convencionales como fallover
3: Usa solo DoH
4: Lanza ambas peticiones, pero solo usa las resoluciones convencionales.

network.trr.uri: (URL del resolver a usar)

Google: https://dns.google.com/experimental
CloudFlare: https://cloudflare-dns.com/dns-query
Mozilla/CloudFlare: https://mozilla.cloudflare-dns.com/dns-query

network.trr.bootstrapAddress: (opcional)

Si forzamos el uso del modo 3, como en mi captura, es necesario especificar la dirección IP del resolver. No podemos usar DoH sin conectarnos al resolver, con lo que necesitamos su IP, pero si forzamos usar solo DoH entramos en un bucle del que no salimos. De este modo preestablecemos la IP del resolver. No se requiere para el resto de los modos.

 

Hay muchos modos para conocer si DoH está funcionando en nuestro equipo. Un modo sería consultar la página de estado de Firefox sobre las peticiones DNS:

about:networking#dns

Podemos localizar la columna TRR y ver si para dicha resolución se está usando DoH o no.

Otra opción es usar un analizador de paquetes, y comprobar que no aparece tráfico DNS, al menos generado por el navegador web.

 

DNSCrypt-Proxy

DNSCrypt-Proxy es un proyecto de código abierto y multiplataforma. Actúa básicamente como un proxy que toma las peticiones DNS convencionales y las envía a un resolver por DoH. El proyecto lo tenemos en Github.

DNSCrypt-Proxy no es para nada nuevo, pero si ha sido recientemente cuando han añadido soporte para DoH. Anteriormente funcionaba con DNSCrypt de OpenDNS, de ahí su nombre, pero actualmente es compatible también con resolvers DoH. Este software es muy interesante porque nos permite pasar por ejemplo todas nuestras peticiones DNS (de todo el equipo, con independencia de que aplicación se use) a DoH. O mejor aun, si lo instalamos y configuramos en un Router, podemos asegurar directamente toda la red local, haciendo que absolutamente todas las peticiones DNS pasen por él. Esta última alternativa sería la ideal en entornos domésticos, pero ojo, de hacerse así no nos protegería de terceros conectados a nuestra red local, ya que las peticiones que se enviasen de nuestros equipos al Router si serían resoluciones DNS convencionales, sería el Router quien las convertiría en peticiones DoH y las enviaría hacia fuera.

En mi caso he optado por este último esquema, configurarlo directamente en el Router y no tener que tocar absolutamente ningún equipo ni dispositivo de mi red. El como hacer esto, es algo ya más complejo y que excede el artículo original. Para poder instalarlo en un Router se debería de descargar los binarios precompilados (o compilarlos) para nuestro dispositivo, crear la configuración necesaria, crear scripts para levantar los servicios… y como último paso decidir si queremos añadir reglas en iptables para forzar las peticiones DNS enviadas a servidores externos ser tratadas también de forma interna. En mi caso, y por cuestiones varias, prefiero no forzar las peticiones DNS externas. Es decir, que si alguna aplicación lanza una resolución DNS hacia un servidor DNS específico que no sea mi Router, serán convencionales, si usa las DNS del sistema, usará el Router y por ende irán bajo DoH.

La mejor forma de ver si funciona en este caso, es colocar un analizador de paquetes en la interfaz WAN PPPoE del Router, y capturar las peticiones DNS.

Esta primera prueba lanza una petición DNS a los servidores convencionales de google, 8.8.8.8. Dig es lanzado desde cualquier equipo de la red, tcpdump desde el Router:

dig theliel.es +noall +answer +stats @8.8.8.8

theliel.es. 599 IN A 188.121.46.128
;; Query time: 50 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Jul 20 18:19:02 Hora de verano romance 2018

tcpdump -i ppp0 udp port 53

16:19:02.137737 IP xxx.red-xxx-xxx-xxx.dynamicip.rima-tde.net.57185 > google-public-dns-a.google.com.domain: 14372+ [1au] A? theliel.es. (51)
16:19:02.384289 IP google-public-dns-a.google.com.domain > xxx.red-xxx-xxx-xxx.dynamicip.rima-tde.net.57185: 14372 1/0/1 A 188.121.46.128 (55)

Esto es el comportamiento normal, tcpdump está escuchando el tráfico en el puerto 53 que es por donde se realizan las peticiones DNS, y por tanto no solo registra la petición DNS realizada con Dig, sino que además incluso nos muestra directamente tanto la petición como la respuesta del servidor de Google.

Esta segunda prueba lanza la misma petición, pero esta vez usando los servidores DNS predefinidos por el servidor DHCP del Router (el mismo Router), que a su vez enviará las peticiones hacia el resolver configurado en DNSCrypt-Proxy:

dig theliel.es +noall +answer +stats

theliel.es. 573 IN A 188.121.46.128
;; Query time: 43 msec
;; SERVER: 192.168.2.1#53(192.168.2.1)
;; WHEN: Fri Jul 20 18:25:49 Hora de verano romance 2018

tcpdump -i ppp0 udp port 53

tcpdump -i ppp0 tcp port 443

16:28:41.849811 IP xxx.red-xxx-xxx-xxx.dynamicip.rima-tde.net.57197 > mad07s09-in-f14.1e100.net.https: Flags [P.], seq 8119:8303, ack 48627, win 4006, options [nop,nop,TS val 16309141 ecr 1452692457], length 184
16:28:41.859322 IP mad07s09-in-f14.1e100.net.https > xxx.red-xxx-xxx-xxx.dynamicip.rima-tde.net.57197: Flags [.], ack 8303, win 1050, options [nop,nop,TS val 1452694899 ecr 16309141], length 0
16:28:41.881146 IP mad07s09-in-f14.1e100.net.https > xxx.red-xxx-xxx-xxx.dynamicip.rima-tde.net.57197: Flags [P.], seq 48627:48721, ack 8303, win 1050, options [nop,nop,TS val 1452694921 ecr 16309141], length 94
16:28:41.881295 IP mad07s09-in-f14.1e100.net.https > xxx.red-xxx-xxx-xxx.dynamicip.rima-tde.net.57197: Flags [P.], seq 48721:48811, ack 8303, win 1050, options [nop,nop,TS val 1452694921 ecr 16309141], length 90

En este caso, a pesar de que Dig lanzó la petición DNS y quedó resuelta correctamente, tcpdump no es capaz de detectar tráfico por el puerto udp 53. Para poder «capturar» el tráfico, tendríamos que escuchar con tcpdump en el puerto TCP 443, como podemos ver… o no ver, porque el tráfico va encriptado, como mucho podemos saber que se está lanzando tráfico https a un servidor de google, pero imposible saber de que se trata, y menos aun pensar que es tráfico DNS.

 

Conclusiones

Es muy interesante que por fin tengamos un sistema fiable (y más importante, usable) para el cifrado DNS, y que por supuesto esté siendo estandarizado. Mozilla se ha puesto a trabajar duro en ello, Google está dando pasos agigantados también en la misma dirección, con lo que es de esperar que el resto se vayan uniendo a la fiesta. Esto no quiere decir que en dos días, un mes o un año todo el tráfico DNS irá cifrado, ni muchísimo menos. Del mismo modo que desde hace años disponemos de DNSSec, lo cierto es que solo un % pequeño lo usa, la mayoría de las Webs tampoco están adaptados para esto. DNS no se puede sustituir, pero si podemos imaginar que cada vez más servidores DNS convencionales permitirán su uso como resolvers DoH. Esto, sumado a que puede ser incorporado de forma transparente en las aplicaciones que se requieran, hace previsible su uso en muchos campos.

De los modos sistemas mostrados aquí, posiblemente para el usuario normal el que puede empezar a usar si así lo quiere es a través de Mozilla Firefox. Que yo sepa, a día de hoy Chrome no puede configurarse de un modo similar, pero es solo cuestión de tiempo, si es que no se puede ya. Esto no nos protegerá la red de nuestra casa, pero si todo el tráfico que generemos desde el navegador.

Para quien quiera aventurarse un poco más, puede instalar en local DNSCrypt-Proxy y configurarlo en su equipo para aplicarlo de un modo integral a su propio equipo, y por último, los más osados, pueden hacerlo en el Router, y afectar a todo el tráfico que genere nuestra red local.

Esto no va a saltarse de golpe todos los bloqueos existentes, no va a hacer que nadie bajo ningún concepto pueda saber las direcciones que visitamos, pero sin duda alguna es un plus muy importante a nuestra privacidad, sobre todo si tenemos un portatil o un dispositivo móvil el cual usamos en redes de datos de los ISP o en redes WIFIs públicas o que no controlamos, es aquí donde la configuración por aplicación es igualmente importante. Es decir, ya se use en el Router o en las propias aplicaciones, un uso no sustituye el otro.

Los problemas de rendimiento están presentes, no podemos engañarnos, pero es cierto que la inmensa mayoría de las veces son imperceptibles, y solo de cuando en cuando notamos realmente un «parón» en la resolución DNS y tarda algo más de lo habitual. Pero el 99% del tiempo no notaremos ninguna degradación.

Hay que entender que de cualquier modo todo es muy experimental, el estándar no se ha terminado de aprobar y algunas cosas aun cambiarán, por suerte para mejor con seguridad.

Saludos.

¿Que es el nuevo Reglamento General de Protección de Datos (RGPD), que no está dejando títere con cabeza?

 

LOPD (antigua) Vs RGPD

El día 25 de Mayo de 2018 será recordado, con bastante seguridad, por ser un antes y un después, porque han cambiado las reglas del juego, las reglas de un juego en el que el producto era el propio ciudadano, y el vendedor y el comprador empresas de medio mundo. Pero antes de entrar en detalles… ¿Que diablos es la RGPD?

En España llevamos años rigiéndonos por la Ley Orgánica de Protección de Datos (LOPD), supervisada por la agencia de protección de datos. Este organismo ha tenido un papel fundamental en los últimos años, sobre todo si tenemos en cuenta que cada año que pasa nos metemos más de lleno en una sociedad totalmente «tecnologizada», en una sociedad donde cada vez vale más nuestra información, lo que hacemos, lo que nos gusta, todo. Y si tengo que ser justo, tengo que decir que al contrario de la opinión que tengo sobre como funcionan la mayoría de las cosas aquí en España, la agencia de protección de datos a cumplido con su cometido, ha sido tanto comprensible,  flexible, firme como implacable, en función de las irregularidades, y más importante, de la intencionalidad.

El Reglamento General de Protección de Datos (RGPD) no es una ley ni un reglamento Español, tiene un alcance Europeo, es el acuerdo de años de trabajo de la UE, y digamos que sienta las bases, unas nuevas bases, de como se deben de tratar, recolectar, vender… cualquier dato/información de carácter personal de sus ciudadanos. Esto no va (solo) del mundo digital, ojo, esto se aplica absolutamente a todo. En España, el RGPD sustituye/modificará por tanto la LOPD actual, para darle cabida. Y sí, es de obligado cumplimiento para todos. Nuestra ya vieja LOPD, si bien es cierto que en algunas cosas era más restrictiva, en muchas otras se quedaba corta. El RGPD unifica en territorio europeo las nuevas reglas del juego de los datos personales.

El que más o el que menos ya sabe lo que es la RGPD. Vale, puede que desconociesen lo que estaba detrás, pero lo lleva viviendo cuanto menos desde el 25 de Mayo de este año. Hay que tener bien claro que el RGPD se aprobó hace ya dos años, el 25 de Mayo de 2016, lo que sucede es que se dio un plazo de 2 años para que absolutamente todo el mundo pudiese adecuarse al nuevo reglamento, y la fecha del 25 de Mayo de 2018 sería la fecha límite para empezar a aplicarlo por obligación. Pero como pasa siempre, y pese a esos 2 años de plazo, ha cogido a una cantidad ingente de compañías, entidades, organismos… con un pie fuera, y con dos también. Mientras escribo esto es 6 de Junio, han pasado solo 12 días desde la fecha límite, y os puedo asegurar que la sacudida, la relevancia que está teniendo es épica.

¿Pero que tiene el nuevo RGPD tan «especial» como para afectar tanto? ¿Es tan diferente a la actual LOPD? La LOPD actual ha sido una ley muy positiva, que no siempre se ha cumplido sobre todo a un nivel más de calle, pero tuvo un impacto bastante bueno. El RGPD básicamente no solo devuelve el derecho sobre nuestros propios datos, sino que obliga a cualquiera que los recopile/use/venda/comparta… a:

1º. Especificar de un modo claro, entendible y sencillo que uso se van a hacer de ellos, a quienes se les va a vender/ceder/compartir, el uso a su vez que podrían hacer esas compañías… todo.

2º. Solicitar/requerir permiso explícito sobre todo ello y de un modo granular, nuestro consentimiento no puede ser tácito o sobreentendido, tiene que ser igualmente claro y sin «trampas», sin denegarnos posibilidad de usar dichos servicios en caso de rechazar la explotación de nuestros datos, a menos que claro está que estos sean totalmente necesarios para el uso de dicho servicio/producto o lo que sea, pero en cualquier caso debe de existir un consentimiento expreso.

3º. Permitirnos acceder de un modo simple, legible, cómodo… a absolutamente todos nuestros datos que poseen, ya sea la finalidad que sea, incluyendo por supuesto la eliminación de todos ellos si así lo queremos, haciendo por ley por tanto el consabido derecho al olvido.

4º. El Reglamento no puede aplicarse de forma retroactiva, pero obliga también a que nos tengan que solicitar de forma expresa, en las mismas condiciones anteriormente citadas, nuestro consentimiento por los servicios y otros que en su día aceptamos al amparo de otras leyes.

5º. Transparencia y tomar las medida de seguridad y control que sea necesarias para salvaguardar los datos que se tengan. Eso quiere decir que ante cualquier fuga de datos, fallo del sistema.. tendrán que demostrar que cumplían con normas básicas de seguridad y que la privacidad era parte importante desde el principio, e igualmente informar tanto a las autoridades como a los afectados sobre dicho problema.

Obviamente el reglamento es mucho más complejo, pero de cara al ciudadano, lo más importante es eso.

Las multas serán ejemplares por otro lado para los menos cumplidores. Hablamos de un 2% a un 4% de la facturación o de 10 a 20 millones de euros, no es calderilla desde luego.

 

No parece tan malo el nuevo reglamento, ¿Por qué tanto revuelo y quejas?

A priori, para la inmensa mayoría todo suena muy bueno, somos felices con todo ello. El problema es que llevamos muchos años en una sociedad donde somos el producto, donde somos los que nutrimos y alimentamos a cientos y miles de empresas con nuestros datos. Esto es complicado de ver a veces, muchos se preguntan que valor puede tener para una empresa cosas en principio con tan poca importancia como saber nuestra edad, o nuestro nombre, o nuestro sexo… si hablamos del teléfono o el correo electrónico muchos podrán entenderlo mejor, porque el uso publicitario de ello es más inmediato, pero el resto de datos tienen el mismo valor. Servicios como Facebook, Instagram, Twitter, Google, Apple… recopilan ingentes cantidad de datos nuestros a cambio de usar sus productos/servicios. Esas empresas generan miles de millones de uros gracias a nuestros datos. Publicidad dirigida, big data, estudios…

La repercusión es inmensa, porque si bien es cierto que para muchas grandes empresas el negocio del bigdata es secundario, para muchas otras es de primer nivel, y el nuevo reglamento va a disminuir enormemente tanto la cantidad como la calidad de los datos, a fin de cuenta ahora el control va a tenerlo de un modo más férreo cada persona. Pensemos en cosas simples, no hace falta ejemplos sofisticados. Si entramos en una web que usa Google Analytics sencillamente para tener una idea de visitas y otros, aunque sea sin animo lucrativo siquiera, requiere confirmación expresa, denegarlo o simplemente no interactuar, implica que no puede usarse con nosotros, con lo que para empezar, la totalidad de Webs que «monitorizan» del modo que sea sus visitas van a ver un descenso brusco de estas. Y fijaros que el ejemplo más sencillo no puede ser. Bien pues si eso pasa con una web de cualquier individuo, pensar que pasa con una web de una compañía/empresa. Pongamos de ejemplo la web del diario «El PAIS», el cual no cumple rigurosamente por cierto con la nueva normativa, y vemos en su política de Cookies una lista de terceras empresas con las que se colabora y usan nuestros datos.

En lo personal, entiendo que mis datos son necesarios para las empresas y que contribuye a que pueda usar ciertos servicios de forma «gratuita». Lo mismo pasa cuando usamos aplicaciones gratuitas muchas veces, asumimos que lo «gratis» es pagar con algo de nuestros datos. Me parece bien, lo asumo, pero siempre que ese uso y esa recolección de datos sea proporcionada. Antes era el gran coladero, en el mejor de los casos tenías una opción escondida para compartir datos, y páginas incontables de condiciones legales. Ahora todo va a ser más simple y sencillo, quienes no quieran arriesgarse tendrán que ser claros, permitir granularidad y ante la duda no recopilar ni usar nada.

Muchas empresas tendrán que cerrar directamente, lo que antes era el pan nuestro de cada día hoy no será viable, sobre todo si tenemos en cuenta que una vulneración de nuestros derechos conllevará sanciones importantes. Otras se verán muy afectadas al ver como el gran volumen que manejaban cae enormemente. Y otras, las que menos, sencillamente tendrán las herramientas necesarias para que simplemente el usuario pueda hacer lo que alguna vez a lo mejor quiere hacer: Saber que datos tienen de uno, y permitir o denegar su uso en las condiciones que dicen, sin ser abusivo.

Se ha hablado mucho de que las sanciones son desproporcionadas, tal es así que muchas empresas no europeas, están denegando el acceso a sus servicios/webs/otros a ciudadanos Europeos por miedo de incumplimiento. Otras, no han optado por algo tan radical, pero si han creado versiones específicas (mismo contenido realmente) para los Europeos para poder cumplir con las normativas nuevas. Esto nos da una idea del tráfico actual que existe/existía de datos personales, de nuestros datos personales. Cuando una empresa prefiere denegar el tráfico a los Europeos a sus servicios por miedo a no cumplir con la RGPD, te da que pensar, a saber que barbaridades están haciendo. Pero lo mismo para aquellas empresas/servicios que crean versiones especiales ahora para poder cumplirla. Hace un rato, leía no recuerdo donde, que habían hecho experimentos en diferentes diarios extranjeros para ver cuan diferente podían ser estas «versiones» de webs para europeos y para el resto… los resultados estremecedores, las webs que cumplen ahora con la normativa europea pesaban algunas incluso un 90% menos!!, con lo que cargaban mucho antes también. ¿Por qué? Pues porque el grueso de una web a día de hoy es el contenido audiovisual, scripts y otros, y todo ello muy de la mano siempre de la publicidad, estadísticas, analíticas y tantas otras cosas.

No estoy diciendo que el RGPD sea el mejor, es más, llega muy tarde, llevan con él años y años y años… pero eso no quita con que no sea positivo. Existen flecos, existen algunas dudas, pero la mayoría de quejas que se han levantado son quejas de aquellos precisamente que lo hacen con la boca pequeña y mirando hacia otro lado. Es de esas leyes/normativas que aunque te contravenga, ponerte en su contra es casi imposible debido al sentido común, ética, impacto y derechos propios…se ha intentado criticarla poniendo de facto que al final el perjudicado serán las PYMES o usuarios particulares como bloggers, «influencers» y otros..  El reglamento viene para cumplirse, y a medio largo plazo se va a cumplir seguro, pero aunque las sanciones pueden ser muy muy duras, eso no significa que porque un bloggero de moda no ponga o se le olvide poner una casilla de verificación, le va a llegar una multa estratosférica. En primer lugar siempre se alertará, se dará un toque de atención se…. se es realista, eso sin contar que se tendrá muy en cuenta también tanto el volumen de datos que se manejan como su importancia y otras cuestiones.

Bien, llegado a este punto, para quien ande perdido y vea que esto va en serio. Yo no me dedico a venta de datos ni a compartirlos ni a nada, pero por ejemplo este blog es mío. Bien, yo estoy obligado a cumplir con el nuevo RGPD. Pero parece absurdo si realmente… ¿qué datos de caracter personal puedo recoger yo? No recopilo información de nadie, no vendo nada, no publicito nada… aun así, hay 3-4 cosas que tengo por ley que dejar claras:

1º. Lugar siempre visible de política de privacidad y cookies
2º. En mi caso, el único contenido externo creo recordar que es Google Analytics para contar visitas, pues aun así tengo por defecto que no usarlo, y solo usarlo si se me da un consentimiento expreso que saldrá en pantalla.
3º. El formulario de contacto ahora tiene que incluir por narices una casilla de aceptación de la política de privacidad y cookies. En mi caso es muy simple porque los únicos datos que se recogen son lo mínimo imprescindible, pero da igual, tengo que decir bien claro que voy a hacer con esos datos, para qué… etc etc

Y todo eso en un blog que es, o intenta al menos, ser escrupuloso con la privacidad y el respeto a los usuarios, sin publicidad, sin tráfico de datos, sin absolutamente nada. Imaginad ahora que pasa cuando se trata de una empresa que se dedica a traficar con datos y un buen día de buenas a primeras tienen una filtración de datos, o se descubre que nos han engañado y han estado vendiendo nuestros datos sin nuestro consentimiento. Pues aun así, pese a los ya pequeños cambios que he realizado en mi propio blog, es posible que aun esté violando el RGPD en algún punto, no soy jurista a fin de cuentas, pero lo más importante que podemos ofrecer cualquiera que sea un comunicador, es ser transparente. Sin transparencia no hay confianza, y sin confianza…

Las empresas de cierto tamaño lo van a tener más complicado, pero también tienen infinitamente más medios. Desde designar delegados específicos, rediseñar la privacidad desde cero, auditorias.. pero señores, hablamos de cosas serias, no tengo nada que ocultar, pero no me gusta que se me use como moneda de cambio y sin yo saberlo.

 

Futuro Inmediato

El efecto ya lo estamos viviendo, y vendrá además por fases.

La primera fase la llevamos viviendo algunas semanas y meses, ¿cuantos correos electrónicos hemos recibido de diferentes sitios, muchos de ellos sin siquiera saber quienes eran, sobre actualizaciones de políticas de privacidad y para pedir nuestros consentimientos? Muchos, yo he perdido ya la cuenta…

La segunda fase ha empezado hace poco, y cada vez más vemos en todas las webs avisos mucho más concretos, posibilidades de denegar el rastreo o incluso la publicidad. En algunas nos dejan seleccionar cookie a cookie, empresa por empresa, que permitimos y que no. Y esto va a continuar, se acabaron carteles ambiguos o el aceptar de forma pasiva las cosas. Muchos que se están adecuando van a tener que volver a cambiarlas, lo estoy viendo a diario… sí, han cambiado 2 cosas pero siguen violando el RGPD. Como todo habrá que esperar a que pase un tiempo a que se asiente todo. Esto se aplica no solo a páginas webs, lo vemos también en aplicaciones, software, todo.

La tercera será más dramática, y serán cortes y cierres. Muchas muchas aplicaciones a día de hoy de App Store o Play Store se nutren de publicidad, de venta de datos de… serán ilegales si no cumplen con el RGPD, y eso implica consentimiento expreso, granularidad, explicación… aquellas, las más «dañinas» para nuestros datos se verán obligadas a cerrar porque no será rentable, ni los ciudadanos estarán dispuestos a dar los datos que exigen. Muchas otras podrían ver un decremento muy importante de sus ingresos indirectos/directos a los datos privados y hacer que dejen de ser rentables. Y repito, esto mismo se extrapola a Webs y otros negocios, ya se han visto muchos casos.

La cuarta fase, serán tribunales. Un negocio tan lucrativo no se va a abandonar así como así, y las trampas siempre han existido, desde moverse siempre en la fina línea de lo legal y lo ilegal, hasta simplemente las cazicadas de mentir/engañar y robar datos sin que se sepa. Pensar que no han pasado ni 12 días y las grandes compañías ya estan TODAS denunciadas. Sí, Facebook, Google, Apple… No creo que en ese punto haya a corto plazo sanciones importantes y poco a poco se adecuarán seguro, pero, y espero equivocarme, asistiremos a algun que otro escándalo multimillonario de alguna gran empresa por pasarse por el arco del triunfo la nueva normativa e ir con «maldad».

 

Hay que ser realistas, y entiendo que muchos productos y servicios son posibles a que nosotros mismos nutrimos sus bases de datos, y lo acepto, y lo asumo. Pero quiero saberlo, quiero saber que se hacen con mis datos, quien los tiene y que uso le dan. Para mi la importancia no radica tanto en multas o en que no tengan mis datos. Siempre lo he dicho, cuando instalo una app interesante y se me solicita de forma adecuada si quiero compartir con los desarrolladores o incluso terceros datos anónimos de uso o alguna otra cosilla, casi siempre les digo que sí, entiendo el valor y la importancia que tienen para ellos y yo me estoy beneficiando. Pero siempre que entienda que es razonable lo que se pida. Tengo Facebook, pero en el equipo, no uso Facebook en el móvil. Lo desinstalé hace años cuando vi que, sin preguntar, sin necesitar y sin nada, Facebook estaba constantemente intentando recopilar datos de geolocalización propios, o mi agenda de contactos o… Repito, hay usos directos y necesarios, usos entendibles, usos «razonables», y hay mucho mucho abuso. Y contra el abuso si me posiciono y lo denunciaré siempre que pueda públicamente… (estoy preparando un artículo sobre Movistar al respecto, no creo que les haga mucha gracia, y menos con el nuevo RGPD)

No hay que ser alarmistas, para los que podemos vernos afectados desde un punto de vista de «adaptar» webs o empresas o… es muy simple: Buen hacer, buena voluntad, transparencia, y pensar que nos beneficiamos todos. Si se va con buena fe y voluntad, en realidad es sencillo cumplir la nueva normativa, y como usuario que soy, también, me siento más seguro y más tranquilo.

¿Son realmente necesarios los Antivirus? ¿Causan más mal que bien?

Buenas compañeros.

Es de estas veces que… digamos que estás haciendo alguna cosa sin demasiada importancia y sin necesidad de atención, mientras lees algunas publicaciones aquí o allí. Y de pronto me he topado con un artículo publicado por Robert O’Callahan, persona bien conocida (en el mundillo) y que sigo desde hace tiempo, con un gran talento como ingeniero de software, y un poco siempre controvertido. Robert O’Callahan ha sido Ingeniero de Mozilla durante muchos años, siendo una pieza fundamental de ellos, un gran programador, experto en seguridad y bueno… creerme, es cierto que siempre ha sido políticamente incorrecto, pero sabe de lo que habla.

El artículo no tenía desperdicio, animo a todos a leerlo: « Disable Your Antivirus Software (Except Microsoft’s)«. Cuando cualquiera escribe sobre temas que conoce (o cree conocer), sus palabras pueden ser más o menos escuchadas y tenidas en cuenta por un grupo de seguidores o lectores, pero cuando personas de cierto y conocidas por su trabajo hacen comentarios tan tajantes, se arma un revuelo… y no es para menos.

Para quien no quiera leerse el artículo o vaya regular en Ingles, se lo resumo de forma sencilla:

En primer lugar, O’Callahan aprovecha para recordar que al no estar de momento en Mozilla (espero sinceramente que vuelva), tiene «libertad» en poder expresarse de forma abierta ya que a fin de cuenta no representa ni la opinión ni palabras de Mozilla y está desvinculado de ellos. Esto nos dice que muy posiblemente Mozilla piensa igual en general, sólo que como es normal no puede hacer afirmaciones tales por las repercusiones que tiene, como veremos luego.

A continuación, hace un pequeño resumen exponiendo que los Antivirus, lejos de hacer nuestros sistemas más seguros, por lo general lo que logran es hacerlo más inseguros, crearle agujeros de seguridad, son invasivos, matan el rendimiento y generalmente por raro que parezca no cumplen las normativas básicas de seguridad de software, con un código mal optimizado y problemático. Y desde el punto de vista de ellos como desarrolladores de software, específicamente navegadores Webs, afirma también que una parte muy importante del tiempo dedicado por los desarrolladores es precisamente tener que lidiar con los fallos de seguridad y otros de los propios antivirus, por supuesto da ejemplos de ello.

Muchos han visto esto como un guiño a Microsoft, por Windows Defender, pero en lo personal no creo que sea así, y en parte lo explica. La gran diferencia entre Windows Defender (En Windows) y cualquier otro AV como pueda ser Symantec, Avira, Avast… (pongo 3, pero en general cualquiera), es que Defender en primer lugar está integrado en el sistema y mucho más optimizado, en segundo lugar Microsoft por política somete a todo su software a estrictos controles de seguridad y estándares que deben de seguir, cosa que la mayoría de empresas de software no hacen, y en tercer lugar porque para lo que sirve un AV, Defender cumple con lo que necesita cualquiera. Dicho de otro modo… Windows ya tiene su propio AV/AntiMalware que funciona bien, para que usar software de terceros que puede provocar todo tipo de problemas.

Bien… cualquier que me conozca, sabrá lo que pienso al respecto: Estoy totalmente de acuerdo con sus palabras.

Es complicado hacer este tipo de afirmaciones y más para ellos, como bien dice. los desarrolladores de Software tienen que trabajar a fin de cuenta codo con codo con los desarrolladores de AV, y es evidente por qué… creéis que a cualquier desarrollador de software le gustaría que un AV salte una advertencia de seguridad o que hagan un comunicado diciendo que el software de X no es seguro?? Es indiferente si dicha afirmación o dicha alarma es cierta o no, el daño lo hacen, porque son compañías que tienen mucho peso. Yo puedo hacer los comentarios que quiera, puedo dar mi opinión y ninguna empresa de AV puede «influenciarme» de ningún modo, pero la mayoría no puede hacer eso.

Las empresas de AV se aprovechan de la historia y del desconocimiento de los usuarios, intentando venderte no su software, sino la idea de que si no usas un AV, tu equipo está desprotegido, y que el suyo es el mejor. Y esto es falso… al menos de un punto de vista global, y he hablado de ello muchas otras veces. Los AV tienen su utilidad, pero es limitada en el mejor de los casos, y por lo general causan un mal mucho peor que la posibilidad de coger algún tipo de malware. El desconocimiento es tal, que por paradójico que sea, la mayoría deshabilita las actualizaciones de Windows para mantener su equipo en buena forma y seguridad, mientras que usan AV para «protegerlo», cuando es exactamente al contrario!! Lo más importante para la lucha contra CUALQUIER tipo de malware, es TENER ACTUALIZADO EL SOFTWARE empezando evidentemente por el OS.

Pues han pasado unos días desde que el señor O’Callahan escribiese dicho artículo, y al margen de lo polémico que ha sido muchas veces (que no es sinónimo de no tener razón), esta vez se le ha unido incluso algunos Ingenieros de Google, que aunque han sido algo más suaves, han venido a darle la razón, aludiendo que al margen de las estadísticas y otros que sacan las propias empresas de AV, ellos tienen sus propios datos que muestran que tales afirmaciones son ciertas, y que duela a quien duela, Defender es digamos mucho menos problemático que el resto de los AV.

No es normal que expertos de cierto calibre hagan afirmaciones tales: «Deshabilita/Desinstala tu Antivirus», pero me alegra que por fin algunas voces se atrevan a decirlo. Como queda dicho, hay demasiados intereses económicos, y luchar contra empresas de importante tamaño te puede pasar factura, sobre todo si tu producto puede verse afectado por el producto de otro.

 

Mi opinión personal es bien conocida para todos mis círculos, y alguna vez la he expresado aquí. Cualquier tipo de Malware es introducido en el equipo o por interacción directa del usuario o por algún agujero de seguridad. Lo primero se evita con una educación mínima de como usar Internet y otros, a fin de cuenta repito entra porque el usuario instala o ejecuta algo que no debía. Lo segundo se evita actualizando el Software, sobre todo cualquier programa de cara a Internet, como navegadores Web, Sistema operativo y otros. Y no, en ninguna de esas dos luchas contra el malware aparece un AV. Sí, en algunos momentos específicos puede ser bueno poder disponer de un AV para analizar un archivo del cual no estamos seguro o dudamos… pero para eso tenemos una herramienta mejor a todo ello:

http://virustotal.com/

Tengo que decir que siempre que tengo que recomendar configurar un equipo, software a instalar… o incluso a amigos/familiares que soy quien se encarga de ello, el AV lo tengo vetado. Por lo general, es cierto que les dejo habilitado Defender, aunque en mi círculo más cercano, también lo tengo deshabilitado. Esto no es una recomendación ni lo deja de ser, porque al final como dice también O’Callahan, si recomiendas algo y alguien termina con problemas por ello, se contará siempre la negativa y no la positiva, sólo digo que a todo en lo que tengo o pueda tener mano, los AV de terceros están totalmente vetados, y en mis círculos más cercanos, todos.

Por supuesto… cada cual es libre de creer, hacer 🙂

eMail: SPF+DKIM = DMARC

Una pequeña reflexión antes de empezar

No sé como evolucionará la tecnología en el modo que nos relacionaremos unos con otros digitalmente dentro de unos años, pero me gustaría pensar que el eMail seguirá teniendo ese papel imprescindible. No son pocos los que año tras años auguran su muerte en pos de la mensajería instantánea. Es cierto que para la mayoría de adolescentes y jóvenes, el uso que puedan darle al correo electrónico es anecdótico, y generalmente para realizar reservas, compras y otros. Llamadme nostálgico o de la vieja escuela, pero pese a las virtudes que nos brinda la mensajería instantánea (la cual por supuesto uso de forma constante), lo único que supera a un buen correo electrónico cargado de contenido es una carta matasellada. Por supuesto no entramos en el mundo laboral/escolar/empresarial, donde a día de hoy el eMail sigue siendo completamente indiscutible.

Dicho esto, recordemos que el eMail no es algo nuevo, que data al menos desde 1970!! y poco cambiado desde entonces. Eso son casi 50 años, y evidentemente desde entonces todo ha cambiado.

 

Como funciona a groso modo el eMail

Como siempre, antes de entrar en materia «pesada», para los que aun andan un poco despistados, un pequeño resumen rápido de como funciona el eMail, importantísimo para comprender la importancia de tecnologías como SPF, DKIM o DMARK.

El eMail, pese a que pueda parecer algo complejo es un sistema de mensajería tremendamente sencillo, se basa posiblemente en unos de los protocolos más simples que podemos encontrar a día de hoy como puede serlo SMTP. Otra cuestión que la mayoría desconoce es que pese a que tenemos proveedores de eMail a lo largo y ancho de todo el mundo, en realidad cualquiera puede enviar un eMail sin tener siquiera una cuenta propia, y que incluso podría crearse una sin demasiada complicación. Esto es así porque el eMail se creó como modo de comunicación sencilla, sin mirar cuestiones de seguridad o las posibilidades en la suplantación de identidad o…

La Wikipedia nos deja una imagen que ilustra bastante bien el funcionamiento del eMail:

correo

Un usuario envía un texto correctamente formateado a un servidor SMTP para que realice el envío (1), indicando entre otras cosas quien lo manda y a quien se lo mandamos. Este servidor SMTP lo primero que hace es consultar el destino de dicho correo, para lo cual lee el realm de la dirección de destino, es decir, el dominio al cual se envía, la parte derecha de la dirección, y realiza una consulta DNS al registro MX de dicho dominio, pues dicho registro se usa precisamente para ello, para conocer donde se encuentra el servidor de Correos de dicho dominio (2). El servidor DNS de dicho dominio devuelve la dirección de su servidor de correos (3) al servidor SMTP. Este al conocer ya el servidor al que debe de enviarlo, conecta directamente con el y entrega el correo en dicho servidor (4). Dicho servidor debería de reconocer la dirección de correo a la que está destinado, así que lo colocaría en su bandeja, a la espera de que el destino lo reclamase por medio de POP/IMAP (5).

Esta otra imagen muestra lo que sería un esquema más real de todo ello, más completo (no tenía muchas ganas de crear un esquema propio, así que espero que no se moleste oasis-open.org)

howemailworks

El usuario envía un correo a través del MUA (el cliente email que use) y posiblemente a través de SMTP a su MTA/MDA (Mail Transfer/Delivery Agent). Aquí se almacenará posiblemente en su bandeja de enviados, y como dijimos anteriormente se resuelve la dirección de destino y se procede a su envío, conectando al MTA de destino y entregando el mensaje allí. El MTA de destino lo manda ya por su red al buzon correspondiente y el destino lo recoge de ahí.

No obstante, este funcionamiento tan sencillo deja la puerta abierta a muchas preguntas concernientes a la seguridad de los propios correos electrónicos. Algunas cuestiones de gran importancia:

-Los correos no se mandan cifrados? No, por defecto el correo es un texto plano, si se quisiese cifrar se debería de realizar de un modo punto a punto, con tecnologías como PGP o similar, que a día de hoy siguen sin ser usadas de forma global por la complicación que implica el «compartir» las claves públicas. Lo mismo sucede si mandamos un archivo protegido por contraseña la otro extremo, tendríamos que mandarle la contraseña para poder ver dicho archivo. Eso significa que quien accediese tanto a nuestra bandeja de entrada como la de salida podría ver siempre el contenido de los correos.

-La comunicación se realiza de forma segura?? En su modo más simple no, al ser un texto plano, en cualquier punto se podría escuchar la comunicación y con ello el mensaje. La mayoría de servidores SMTP a día de hoy permiten realizar las conexiones por medio de TLS/SSL, pero… resuelve esto completamente el problema?? Tampoco, el mensaje podría llegar de forma segura al MTA, pero para que TODA la comunicación fuese segura, el MTA debería de mover el correo por su propia red de forma segura también, y transmitirlo al MTA destino de forma segura (que no todos los MTA origen/destino permiten), y el MTA destino por su parte volver a moverlo en su red interna de forma segura, y por último el destinatario recibirlo en su MUA por medio de POP/IMAP usando TLS/SSL. Por lo general el único dato que ve el usuario es si se conecta al servidor SMTP de forma segura o no, pero nada más, y eso es sólo el primer salto.

Pero quizás, el principal problema que se abre en el eMail, es la capacidad de poder crear un eMail desde el remitente que se quiera y poder enviarlo al destinatario que se quiera, es decir, la posibilidad de suplantar la identidad del remitente. Uno podría pensar que para que eso fuese posible se tendría que poder hackear/acceder a la cuenta de un usuario para poder enviarlo desde su cuenta, pero nada mas lejos. Sí, necesitaríamos acceder a la cuenta de un usuario para poder enviar un correo desde dicha cuenta DESDE EL MTA DE SU PROVEEDOR, pero… y si nos saltamos los pasos 1, 2 y 3 de la primera imagen?? Podemos consultar directamente el servidor de correo de cualquier dominio, es algo público, y podemos conectarnos a él directamente para dejar en su bandeja de entrada el correo que queramos, usando de remitente lo que nos de la gana. Y sí, es así de sencillo, tal y como suena. No hace falta decir la importancia de esto, de poder suplantar la identidad de un correo… es decir, poder mandar un correo a quien queramos haciéndonos pasar por cualquier otro..

Debido precisamente a esto, empezó una larga guerra contra el SPAM y el fraude, y se empezaron a crear mecanismos para combatir esto, lo que al final nos llevará a DMARC. Sí, es importante que la comunicación sea segura, pero cuando tenemos encima de la mesa la posibilidad de poder engañar a quien queramos, todo se centró en ello. Recordemos que hace ya tiempo escribí un artículo precisamente hablando de todo esto, de la suplantación del eMail que podemos ver AQUI. Así que hoy veremos precisamente lo contrario, como evitarlo en la medida de lo posible. Para ello vamos a ver las «armas» más habituales de las que disponemos:

  • «Filtro» IP del origen: Listas negras/grises/blancas
  • SPF
  • DKIM
  • DMARC

Antes de seguir, todo lo que veremos a continuación es interesante sobre todo desde el punto de vista de proveedores de correo de nuestros propios dominios. Es aplicable igualmente a los proveedores «públicos» como Gmail, Hotmail… pero estos sistemas son configurados y gestionados por ellos, con lo que usen o no SPF, DKIM, DMARC… no podremos hacer nada, no es algo que podamos habilitar o deshabilitar. Eso sí, recomiendo en este caso usar proveedores que realmente se tomen la seguridad en serio y apliquen los máximos estándares de seguridad.

 

Listas Negras/Blancas/Grises en función del Origen de la IP

Estas listas se llevan usando desde hace ya muchísimos años, y prácticamente todos los proveedores conocidos las usan de un modo u otro. No obstante, aun existen muchos correos empresariales o «domésticos» que carecen de ellas, y aun así, su utilidad como veremos es relativa.

La idea es muy simple… si en teoría cualquiera puede conectarse al MTA de cualquier dominio, vamos a configurar esos MTA para que sólo acepten conexiones desde IPs que ellos consideran legítimas. El problema es que Internet es dinámico, y que no puedes crear una lista blanca rigurosa, porque a fin de cuentas Internet también es «abierto» y cualquiera podría legítimamente querer enviar un correo desde su propio servidor a otra dirección. Así que estas listas se sostienen un poco siempre por pelos, aplicando reglas muy generalistas.

Por ejemplo, casi siempre se impide el entregar un mensaje a cualquier IP que en una de sus listas esté identificada como «dinámica», pues se supone que si es una IP dinámica debe de ser un usuario malicioso desde su conexión el que quiere entregar el mensaje, y no un MTA legítimo. Otra norma habitual es meter en listas blancas los MTA mas conocidos de los proveedores de correo para asegurarse que estos no se filtren nunca, o meter en lista negra aquellas IPs o rangos IPs que se conocen que proceden de servidores con una fama bastante importante en el uso de SPAM y otros.

Pero como digo estas listas son de todo menos fiables, tal es el caso que por lo general puedes acceder a las web donde las gestionan para indicar falsos positivos, o registrar tu propia IP en caso de ser legítima, o que un rango que antes era sospechoso ahora es válido, o al contrario… Además estas listas no evitan el uso de conexiones Proxy desde otros lugares, es decir, un atacante podría estar realizando la conexión usando un tunel o un proxy o cualquier otra técnica desde servidores o redes que no estén filtradas, y creerme… no suele ser nada complicado encontrar una red o host que puda evadir estas listas.

Un ejemplo de estas listas son las que proporciona Spamhaus, pero hay muchas otras. Estas se implementan a nivel del MTA, comprueba la IP de la conexión que se está realizando y la cruza. Si esa IP intenta entregar un mensaje en dicho MTA y está en una de sus listas negras, denegará directamente la entrega. El mensaje no es que termine en SPAM, es que no atravesará siquiera el MTA de destino. Es un modo muy eficaz de filtrar, pero por desgracia no es muy efectivo cuando uno sabe bien lo que está haciendo. .

Además, este sistema tiene otro problema añadido… un usuario podría estar usando un proveedor de correo legítimo, y usar una conexión SMTP a su proveedor para colocar el mensaje en otro MTA modificando el remitente del correo. Este tipo de correos pasarían completamente este filtrado basado en listas, ya que la IP de origen sería la del MTA legítimo.

 

SPF

LLegamos a la primera gran parte de este artículo.

Pese a que la mayoría ni siquiera sabrá que existe, gracias a SPF me atrevería a decir que más del 80% de los correos SPAM y fraudulentos, acaban precisamente en las bandejas de SPAM, y no penetran a nuestras bandejas de entrada. Se creó como sistema de defensa ante precisamente los intentos de suplantación de correos. Por supuesto tiene sus puntos débiles y SPF no nos protege de todo, pero respecto a aquello para lo que fue diseñado, desempeña su papel muy bien.

Al contrario de como sucedía en el sistema de listas, SPF requiere de cierta configuración/preparación no sólo por parte del MTA de destino, que debe como es natural ser compatible con esta tecnología y poder tomar decisiones en función de SPF, sino que además el dominio del remitente del eMail debe de estar configurado y preparado para ello. Es necesario así un trabajo conjunto de las dos partes. El resultado en cambio es sorprendente. Aquí no se protege realmente a las cuentas de destino propiamente dicho, sino lo que se intenta es que a las cuentas de los destinatarios no lleguen correos que suplantan la identidad de otros dominios, con lo que realmente se está protegiendo a los dominios que quieren usar para suplantar.

Con las listas teníamos el problema de no saber nunca bien si la IP de quien enviaba el correo era legítima o no… SPF viene a solucionar este problema de raíz. Básicamente de lo que se trata es de configurar el servidor DNS del dominio de origen de los correos para indicar precisamente desde que direcciones IP/dominios se permiten enviar dichos correos. Esto puede sonar un poco lioso, pero es muy simple, veamos un ejemplo sencillo:

Sin SPF:

Digamos que Pedro, cuya dirección de correo es pedro@pedrito.com, usa Paypal para realizar compras, algo muy habitual a día de hoy. Bien, pues un atacante quiere intentar engañar a Pedro, y para ello quiere enviar un correo a Pedro haciéndose pasar por Paypal. Es muy facil, saca la dirección del MTA de pedrito.com con una consulta a su registro MX, y se conecta directamente al MTA para redactar su mensaje, y escribe lo siguiente:

mail from: Servicios Paypal <servicio@paypal.es>
rcpt to: Pedro <pedro@pedrito.com>
data

from: Servicios Paypal <servicio@paypal.es>
to: Pedro <pedro@pedrito.com>
subject: Verificación de contraseña

Por favor verifique su contraseña en el siguiente enlace, bla bla bla
.

Aun cuando el MTA de Pedro usase listas, si el atacante es listo habrá sabido como evitarlas, así que a todos los efectos el correo parece legítimo, a fin de cuentas cuando Paypal manda un correo legítimo a Pedro puede ser de echo exactamente igual. El correo podría entrar en la bandeja de entrada perfectamente, y Pedro hacer caso de lo que dice el correo, a fin de cuenta el remitente está claro que es Paypal.

Con SPF:

Supongamos el mismo caso, pero en esta ocasión el dominio paypal.es tiene configurado SPF. Evidentemente es igualmente importante que el MTA de Pedro sea compatible con SPF. Bien, Paypal que sabe la importancia y lo que le interesa de que nadie suplante sus correos, hace una pequeña modificación en su servidor DNS, y establece que sólo las IPs 100.100.100.0/24 (por poner un ejemplo) tienen autorización para mandar mensajes.

El atacante escribiría lo mismo y enviaría el mensaje, y se frotaría las manos pensando que lo ha triunfado. No obstante una vez enviado, el MTA que usa SPF, realiza la rutina pertinente. Lee el realm del remitente y anota la IP de este, en este caso paypal.es y pongamos que la IP del atacante fuese 1.1.1.1. Conecta a su servidor DNS (al de paypal.es) y busca a ver si existe un registro TXT que identifique como un registro SPF. Lo encuentra, y obtiene que sólo el rango IP 100.100.100.0/24 tiene autoridad para enviar correos con ese dominio. El MTA compara las dos IPs, ve que la IP del atacante no está dentro de las que el servidor DNS le ha dicho. Paypal indicaba una política estricta SPF (aparece en el mismo registro DNS), así que como no se cumple el criterio establecido, el MTA manda sin pensarlo el correo a la bandeja de SPAM de Pedro, y marca el mensaje con un FAIL en SPF.

 

Gracias a SPF los administradores de los dominios pueden garantizar, hasta cierto punto, que los correos que dicen ser de ellos, sean realmente de ellos, y que de lo contrario sean tratados como SPAM, o sometidos a un escrutinio mayor. La ventaja de SPF es que requiere de muy poco para cualquier dominio implementarlo, no requiere una configuración especial en su MTA, sólo requiere el poder añadir un registro TXT en su servidor DNS. La otra mitad será tarea del MTA de destino, que por cierto a día de hoy la inmensa mayoría usan

Como se hace?? Los registros DNS SPF son sencillos. Lo que necesitamos es crear un registro TXT con el siguiente formato:

"v=spf1 [IP/Dominios permitidos] [Politica a aplicar si no está en permitidos]"

Por ejemplo, si el correo de nuestro dominio está gestionado por Google Apps y queremos añadir como protección SPF, tendremos que crear un registro SPF que permita el envío de los correos por los servidores de Google Apps. Google nos dice que ellos aúnan todos sus rangos bajo el dominio _spf.google.com, así que si añadimos dicho dominio a nuestro registro SPF, realmente estaríamos añadiendo todos los rangos IP que existiesen en el registro SPF de dicho dominio. Pero esto sólo no sirve, con eso tendremos las direcciones que están permitidas, así que hay que decidir que se quiere hacer con aquellas que no cumplen dicho criterio

«v=spf1 include:_spf.google.com ip4:100.100.100.0/24 ~all»

«include:_spf.google.com» indica a otros MTA que reciban un correo de su dominio, que lo acepten si el origen de él está dentro de los registros SPF de _spf.google.com

«ip4:100.100.100.0/24» a lo anterior, se suma a aquellos correos cuyo origen se encuentre entro de ese rango IP

«~all» indica al MTA de destino que hacer con esos correos que lleguen de parte de su dominio en caso de no coincidir con alguna IP anterior. En este caso la tilde expresa un softfail, un fallo, pero no «radical», a modo que el MTA destino lo tenga en cuenta a la hora de decidir si lo manda a SPAM o no. Si se usase un signo menos, sería un FAIL estricto. Por lo general suele ser más seguro un softfail, por si las políticas del MTA de destino son muy estrictas y eliminan directamente el correo, a fin de cuenta el administrador del dominio de origen podría a ver olvidado alguna IP o malconfigurado el registro SPF. También se podría usar el signo + para identificar un PASS o un ? para indicar un «Neutral».

El MTA, en función de la política indicada por el dominio marcará dicho correo como Pass, Neutral, Softfail, Fail… y en función de dicho «marcado» actuará de un modo u otro, ya sea entregando el correo en la bandeja de entrada por creerlo legítimo, marcarlo como SPAM, simplemente ignorar SPF y usar otros modos AntiSPAM…

La mayoría de proveedores de correo usan SPF para aplicar diferentes políticas de SPAM. Por lo general cualquiera puede comprobar esto, sólo tiene que mirar la cabecera de cualquier correo que le llega. Tomemos por ejemplo uno de Paypal, y encontramos lo siguiente en su cabecera:

Received-SPF: pass (google.com: domain of servicio@paypal.es designates 173.0.84.226 as permitted sender) client-ip=173.0.84.226;

Es decir, Google ha marcado como Pass dicho correo, puesto que la IP del emisor, 173.0.84.226, dice estar dentro de las permitidas por el dominio origen, Paypal.es. Si mirásemos el registro TXT de Paypal, nos encontraríamos con un registro SPF donde se encontraría incluida dicha IP. Es decir, dicho correo ha sido enviado por un equipo que tiene permitido enviar correos en nombre de paypal.es, Google lo reconoce y lo trata como un correo legítimo.

SPF funciona francamente bien, no obstante no soluciona algunos otros problemas. Por ejemplo SPF no puede garantizar la integridad del mensaje, y basa «solo» su legitimidad en el origen de la IP, que como siempre puede ser relativo. Con esto en mente nació DKIM

 

DKIM

DKIM no viene a sustituir SPF, sino más bien a complementarlo, aplicando una capa de seguridad diferente. DKIM lo que realiza es básicamente un firmado digital del correo que se envía, de modo que el MTA de destino puede verificar su autenticidad leyendo la firma DKIM incluida en la cabecera del correo. Además, no solo puede verificar el dominio emisor, sino también si el mensaje ha sido modificado en lo más mínimo, ya que aunque se modificase una sola coma, la firma se invalidaría, con lo que también garantiza su integridad.

DKIM hace uso de infraestructura de clave pública (cifrado simétrico) para realizar el firmado. Debido a esto, por desgracia, no sólo nos vale con añadir una entrada en el servidor DNS, como hacíamos con SPF, sino que nuestro MTA debe de permitir DKIM, puesto que deberá de firmar todos los correos que enviemos con él. Si nuestro MTA no permite DKIM no podremos hacer uso de esta tecnología.

Como cualquier infraestructura de clave pública, para que funcione el sistema se requiere de una clave publica y una privada. En este caso nuestro MTA generará ambas, guardará de forma segura la clave privada y nos dará a nosotros la clave pública para que la pongamos en el servidor DNS a modo de registro TXT. La idea es simple… el MTA firmará con la clave privada todos los mensajes que enviemos, de tal forma que tan solo la clave pública asociada a nuestra clave privada podrá verificar la firma. Esto requiere que los MTA de destino puedan tener acceso a nuestra clave pública, así que esta es «publicada» en nuestro servidor DNS, a modo similar que se hacía con SPF.

Como toda firma digital, esta no solo verifica que el emisor del correo es efectivamente quien dice ser, sino que si en cualquier momento existe cualquier modificación del mensaje, la firma quedaría rota, con lo que el cliente podría darse cuenta.

Por supuesto tiene sus defectos, de ahí que lo ideal sea combinarlo junto a SPF. Por ejemplo, alguien podría interceptar el mensaje, modificarlo, cambiar el dominio de origen de la firma y volver a firmarlo con una clave privada propia. El MTA de destino podría ver que la firma proviene efectivamente de donde dice venir y la verificaría con su clave privada, mientras que el remitente seguiría siendo el del origen. Pero si se está aplicando al mismo tiempo SPF, este no daría por válido el origen de dicho correo, pues pertenecería a otra IP de las permitidas (a menos que dicha IP se recogiese también en SPF)

En este caso, no se usa DKIM tan extensamente como SPF para clasificar el correo como SPAM, pero sí para crear dominios de… «confianza». Los MTA ponderan muchas variables a la hora de determinar si un correo es SPAM o no, ó peor incluso, si es un Phising/Scam. DKIM es el modo que tenemos de decir: Ei, este dominio es mío realmente y todos mis correos que voy a enviar van a ir firmados. Eso crea una cadena de confianza, y garantiza en la medida de lo posible que nuestro dominio no sea objeto de suplantaciones.

Como se configura un dominio para usar DKIM?? Bueno, como he dicho son dos partes. En primer lugar se debería de poder configurar el MTA para firmar los correos con DKIM. No todos los proveedores lo permiten, aunque la mayoría de ellos (al menos los más importantes) sí. Tomemos por ejemplo Google Apps, una vez configurado un dominio allí podremos instruir a Gmail para firmar los correos que enviemos desde nuestro dominio. El primer paso por tanto es iniciar la autentificación para dicho dominio que realmente lo que hará será crear las claves públicas y privadas, mostrándonos la clave pública que deberemos añadir a nuestro dominio en forma de registro TXT. Con dicha clave pública, tan solo tendremos que crear un registro TXT asociado a un selector concreto. Por normativa, DKIM almacena en el servidor DNS la entrada TXT bajo el subdominio asociado a dicho selector con el siguiente formato: selector._domainkey.midominio.es.

En «selector» podremos por lo general poner lo que deseemos, incluso podemos usar diferentes selectores, pero el resto es invariante. Esto es así porque cuando nuestros correos se firmen el MTA de destino debe de conocer donde mirar para obtener la clave pública, y el único dato que se suministra en la firma es el selector. Es decir, si usamos en Google Appls como selector «google», tal como estoy diciendo, la clave pública se podría consultar mirando los registros TXT del dominio en cuestión en google._domainkey.midominio.com. Hagamos la pruena… cojamos cualquier correo que nos hayan enviado desde Gmail y miremos su cabecera. Ahora busquemos en la cabecera la firma, puesto que por suerte y por seguridad todos los correos de gmail se firman, y nos encontramos con esta sección:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to;
        bh=nzLCaIESeBg8KtAGcaKCJbAggDVfBjZVSa6oLSVMOfU=;
        b=HBNSvMfDejs8TIHnh3vtDeXrtYuRKNivRUm4WMlBo7HWc7+ClZTVosOwheoajzuXZ8.. 

la d indica que dominio está firmando el correo, la s es el selector, la bh el hash del cuerpo del mensaje, la b la firma… Con esos datos, el MTA de destino puede acceder a la clave pública asociada a la clave privada que firmó el correo:

dig 20120113._domainkey.gmail.com txt

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;20120113._domainkey.gmail.com. IN      TXT

;; ANSWER SECTION:
20120113._domainkey.gmail.com. 299 IN   TXT     «k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1Kd87…»

Como digo, cualquiera puede hacer la prueba, y ver si los correos que le mandan usan DKIM o SPF, o ambos. Os sorprendería ver la cantidad de proveedores que incluso a día de hoy no usan estos sistemas. Esto toma aun importancia mayor en el mundo empresarial, por lo general usan proveedores o servicios de correo muy deficiente y con unos estándares de seguridad de risa. El uso de DKIM o de SPF debería de ser de obligado cumplimiento para cualquier administrador más o menos competente.

Por desgracia no siempre es viable DKIM. Mientras que por lo general SPF suele ser bastante simple de implementar y general pocos problemas (algunos sí), DKIM es más limitado. Muchas veces no sólo usamos nuestros MUA o el acceso web para enviar correos desde nuestro dominio, muchas veces hacemos uso de herramientas como PHP Mail() que suele ser raro que firmen los correos y además conocer bien el dominio de origen, o usamos forwarders de correo para enviarlos de un lado a otro con lo que no siempre se respeta las cabeceras  o a lo mejor una suite AV en el servidor del trabajo que analiza todos los correos al llegar y modifican su cuerpo indicando que ha pasado ciertos controles, rompiendo también DKIM. Y todo ello sin contar con la aun gran cantidad de servidores que no lo usan, ya sea porque no pueden configurarse para firmar los correos o ya sea porque cuando les llegan correos firmados no realizan ningún tipo de verificación.

 

DMARC

Por último, llegamos al némesis del SPAM y de la suplantación de correo. En realidad DMARC es más la unificación de SPF+DKIM trabajando juntos que una tecnología propia. SPF es muy efectivo para filtrar los correos ilegítimos, DKIM es un genio validando los correos y asegurando si integridad… los dos juntos pueden hacer muy complicada la labor al hacker de turno poder usar un dominio protegido correctamente con fines de SPAM o suplantación de identidad. DMARC no requiere de ambos modos, pude usar uno, el otro o ambos, a fin de cuenta como hemos dicho no siempre puede usarse SPF y no siempre puede usarse DKIM. Hay que entender que nosotros con nuestro dominio podemos enviar un correo desde el mediante infinidad de formas como se ha dicho… podríamos enviar un correo del modo tradicional por SMTP, podría enviarlo el servidor Web que tenemos para enviar notificaciones, podría ser usado nuestro dominio para usar listas de distribución usando servicios externos, o usar servcios de correo marketing como MailChimp para el envío masivo de correos, y todos ellos usarían direcciones de nuestro propio dominio!! Es decir, a veces algunos de los correos incluso que mandemos de forma legítima no seremos capaces de protegerlos mediante SPF y DKIM. DMARC pude ser suficientemente inteligente para entender estos pormenores.

Pero al margen de este baile entre SPF y DKIM, DMARC tiene algo que no tiene ninguno de los sistemas vistos hasta ahora. DMARC está preparado para que sí así lo configuramos, indicar al destinatario que si no es capaz de lograr un «pass» en DMARC, el correo lo tome por ilegítimo y LO ELIMINE. Es decir, no a SPAM, no a devolver, simplemente eliminación silenciosa de él. Os lo imagináis?? Si por un momento todos los proveedores de correo usasen correctamente DMARC y Paypal usase esta tecnología correctamente, cualquier que intentase falsificar un correo haciéndose pasar por paypal cuya dirección de correo fuese loquesea@paypal.es, jamás llegaría a su destino, el dominio de Paypal quedaría prácticamente blindado y nadie podría usarlo de forma ilícita. Sí, podría usar otro correo parecido, pero no el mismo dominio.

Otra característica especial de DMARC que lo hace único, es que se diseñó de tal modo que los MTA de destino compatibles con DMARC generan reportes diarios que envían al origen del dominio indicando datos valiosísimos, como por ejemplo la cantidad de emails que ha llegado a sus puertas usando dicho dominio, cuantos lograron pasar DMARC y si pasaron SPF o DKIM o ambos… y todo esto es de forma casi automática, el MTA de destino cuando lee un correo con DMARC (y si es compatible con él), además de leer los datos SPF  y DKIM también accede al servidor DNS para recuperar los datos relativos a DMARC, y de allí saca la política a aplicar y como tratar DKIM y SPF de dicho correo, y por supuesto la dirección de correo a la que enviar los reportes diarios. Nada se escapa a DMARC.

Como de útil es esto de los reportes?? Esencial. Los MTA de destino no tienen por qué ser compatibles con DMARC y por tanto generar reportes, pero si tenemos en cuenta que la mayoría de cuentas a día de hoy son correos tipo Gmail, Hotmail, Yahoo… y que todos ellos lo hacen, podemos tener una visión bastante buena de si se están usando nuestros dominios para fines de suplantación o no. Si a esto le sumamos que existen herramientas que nos permiten centralizar todo esto y ordenar y analizar nuestros reportes, el resultado es más que interesante. A continuación algunas imágenes de unos cuantos dominios que tengo que usan DMARC (Y SPF/DKIM):

En primer lugar, para los que creen que eso de suplantar identidades es cosa del pasado y que nadie se centra en hacer estas cosas… esta primera imagen da una visión general, y viene a decirnos que sí, que es necesario usar este tipo de tecnologías:

Captura

Como vemos en la leyenda, en verde tendríamos aquellos correos que fueron enviados y el MTA de destino pudo dictaminar que pasaban DMARC, y por tanto eran legítimos. En un porcentaje pequeño lo que llamamos forwarders, por lo general son correos legítimos pero que son reenviados por diferentes hosts para fines diversos. Y por último en rojo aquellos que fueron enviado supuestamente en nombre de nuestros dominios, pero que al comprobarlos los MTA de destino dictaminaron que no podía pasar DMARC. En todos los casos esta información se extrae de los reportes generados por los MTA de destino, y aunque en dichos reportes no se indica como es natural destinatarios o cuerpos de mensajes o… si se indica las direcciones IP de origen, entre otras cosas, con lo que podemos ver también que host/dominio está enviándolos. Como vemos, en estos 7 días de intervalo seleccionado, yo diría que un 40% han sido correos no legítimos. Dado que ninguno de mis dominios usa actualmente una política DMARC de rechazo, esos correos posiblemente lleguen aun todos ellos a los destinos, aunque casi seguro siempre a la bandeja de SPAM. Con el tiempo, cuando cambie a una política más restrictiva, ninguno de esos correos llegará siquiera a los destinatarios.

En segundo lugar vemos realmente todos los correos que se han enviado clasificados según su origen, y a la derecha un dato interesante… todos ellos pasaron DMARC, pero no significa que todos pasasen simultaneamente SPF y DKIM. Dado que las reglas de mis dominios son «laxas» DMARC puede pasar cuando uno de ellos falla.

Captura2

Por ejemplo, vemos que los que se origina en Godaddy cumplen el 100% SPF, pero no se firman. En cambio con MailChimp pasa exactamente lo contrario, todos son firmados pero SPF no pude verificarse… esto sucede porque MailChimp usa varios dominios como origen, y aunque se pueden añadir las diferentes IPs, el dominio emitido por MailChimp no coincide con el usado en el remitente real, así que SPF falla.

Podemos ver algo similar con los Forwarders:

Captura3

Los Forwarders reenvían los correos, generalmente esto no es malo, lo que pasa es que no todos funcionan igual. Por ejemplo hay Forwarders que preservan la firma y no la alteran, mientras que otros alteran el cuerpo del mensaje de algún modo y rompen la firma.

Y para acabar, por supuesto, tenemos aquellos que quieren usar nuestros dominios como origen de correos fraudulentos:

Captura4

Y no, no son pocos.

 

Desde el punto de vista del administrador del dominio, no requiere nada para habilitarlo en su dominio, sólo crear la entrada TXT correspondiente en su servidor DNS, similar a como se ha realizado anteriormente. Eso sí, si el MTA de destino no es compatible con DMARC simplemente ignorará las directrices configuradas en el registro TXT del servidor de correo, y tampoco generará reportes.

Un ejemplo real de esto.. supongamos q pedro@pedrito.com usa DMARC, y manda un correo a lacasito@gmail.com. Gmail es compatible con SPF, DKIM y DMARC. Pedro firma su correo por DKIM y también usa SPF y DMARC. Cuando el correo llega a Gmail: a) Verifican que SPF es correcto como hemos comentado antes, y lo marca como superado (Pass). b) Verifica la firma y la integridad del correo como hemos dicho anteriormente, como es correcto de nuevo lo marca como superado (Pass). Por último, mira las políticas DMARC que hace Pedro, y lee algo como:

«v=DMARC1; p=reject; rua=mailto:reportes@pedrito.com»

Dado que tanto SPF como DKIM han dado de resultado un superado (Pass), y no hay nada que impida en las políticas DMARC de pedrito que falle DMARC, DMARC se marcará igualmente como superado, y Google enviará un correo a reportes@pedrito.com al final del día con todos los correos que fueron enviados por direcciones de pedrito.com a sus servidores.

Pero que pasaría si DKIM o SPF fallan?? Bueno, aquí depende de como se configuren las políticas. Por defecto, son relajadas, si fallase alguna de las dos por lo general DMARC seguiría siendo superado, aunque como digo esto puede configurarse. Y que pasa si DMARC falla?? Si falla se aplica la política que hay en el registro DNS. En el caos anterior aplica la política «reject», es decir… si DMARC falla el MTA de destino debe de borrar el correo, rechazarlo. Se podría usar none, y simplemente DMARC no haría «nada». Esto es muy útil sobre todo al principio de implementar DMARC, a fin de cuenta si de primeras decimos que se rechacen, posiblemente perderíamos muchos correos legítimos por una mala configuración de DKIM/SPF o de alguno de nuestros servicios. Es práctica común usar «none» durante un tiempo de meses, comprobar que funciona todo bien, y pasar poco a poco a rechazarlos.

El formato a usar en el servidor DNS es similar a los anteriores, aunque en este caso de nuevo por normativa se usa el subdominio _demarc. Es decir, que la entrada DNS irá ubicada en _dmarc.midominio.es. Hemos visto arriba como sería, en su versión más simple:

«v=DMARC1; p=reject; rua=mailto:reportes@pedrito.com»

Donde p es la política y rua la dirección de correo para los reportes.

Cualquiera que mire la cabecera de un correo que le ha llegado, pude igualmente ver si su MTA verifica de algún modo estas tecnologías. Por ejemplo si miramos un correo entrante de una cuenta de google.coml, vemos algo así (aunque sería similar en las de GMAIL)

Authentication-Results: mx.google.com;
       dkim=pass header.i=@google.com;
       spf=pass (google.com: domain of ...;
       dmarc=pass (p=REJECT dis=NONE) header.from=google.com

Vemos que Google, en los correos de sus dominios si fuerza una política de Reject. Esto hace que si alguien intenta usar su dominio para falsificar una dirección de correo en su remitente, el MTA de destino si es compatible con DMARC lo eliminará instantáneamente. Vemos igualmente que ese correo ha logrado pasar DKIM, SPF y por tanto DMARC


 

Conclusiones

De verdad aun hay quien cree que no necesita saber nada sobre SPF/DKIM/DMARC?? Está claro que para los usuarios que usen correos ordinarios tipo gmail, hotmail y otros no es tan importante, además ellos no pueden configurar nada, solo tener la esperanza que sus proveedores usen los mejores estándares de seguridad. En este caso Gmail posiblemente es pionero, mientras que Hotmail por ejemplo no los firma y bla bla bla. Pero para el resto de usuarios que usan cuentas personalizadas, o empresariales, o de cualquier otro tipo, es aun más importante usar estas tecnologías. A fin de cuentas, al final, cualquier usuario puede crear una cuenta de gmail o hotmail para enviar o intentar enviar correo falsificado a otra cuenta con el mismo dominio, pero nadie puede crear cuentas de un dominio propio. Además, es evidente que es mucho más… jugoso para los hackers/spammers y otros atacar cuentas personales/profesionales independientes, sobre todo a la hoar de intentar suplantar la identidad de alguien.

Volver a arriba

Sobre Mí

Alma Oscura por Theliel is licensed under a Creative Commons Reconocimiento-No comercial-Sin obras derivadas 3.0 Unported License.
Política de Privacidad.
Para otros permisos que puedan exceder el ámbito de esta licencia, contactar en blog.theliel.es/about/contactar.