Banca, Phishing y SPF
Hace unos años abrí una carpeta en mi buzón de correo llamada "Estafas" donde voy situando todos los mails que me llegan de phishing, muleros, venta fraudulenta, etc... Esta carpeta se ha ido llenando al cabo de los años y hoy en día tiene más de 1.000 correos que utilizo para explicar cosas en las charlas.
Desde que migramos nuestro servidor a Exchange Server 2007 y se realizó un assesment de las opciones de Anti-Spam, la verdad es que me cuesta recibir algún correo que llevar a la boca de esa carpeta.
El otro día, repasando con Joshua Sáenz, MVP de Exchange Server y compañero de I64, las opciones y el funcionamiento de los filtros ante correos suplantados, comprobamos el funcionamiento del servidor ante diferentes tipos de spam. Al final, no sabía si besar a Joshua o al Exchange Server 2007 por lo bien que se portan ambos.
El servidor tiene configurados filtros con RBL, filtro de Reputación (basado en registro PTR, estadística de SCL de los correos recibidos de ese servidor y prueba de proxy abierto), filtro de contenido (basado en la tecnología del IMF), soporte para recepción de correos cifrados con canal TLS y filtro de Sender ID.
Esta configuración ha hecho que, por ejemplo, correos de phishing tradicional que suplantan a bancos, hayan dejado de entrar en mi buzón tiempo ha. Esos correos que dicen venir del equipo técnico de un banco para que cambies la contraseña o entres en tu cuenta pinchando en el siguiente link. Esto me sucedió mucho durante un periodo con Cajamadrid.es.
Sin embargo, esto ya no me sucede jamás, porque la gente de Cajamadrid.es ha hecho los deberes y ha configurado el registro SPF en el DNS dando información a los servidores de correo que implementan Sender Policy Framework o Sender ID de quiénes son los servidores autorizados.
El uso del registro SPF ayuda especialmente a las entidades bancarias, víctimas tradicionales del envío de correos electrónicos falsos desde sus dominios, a evitar que lleguen al usuario final. Es un sencillo gesto, configurar un registro TXT en el DNS y se consigue que un porcentaje mayor de correos falsos en su nombre no lleguen a las posibles víctimas. Y eso se transforma en dinero.
Así, he podido ver que algunos han hecho los deberes, como Cajamadrid o Cajamar, ambas con registro SPF con la opción -all para que todos los correos que vengan de una IP no dada de alta en él sean destruidos automáticamente.
Registro SPF de Cajamadrid.es y Cajamar.es
Sin embargo, hoy recibí un correo falso de un banco y....alto, esto no puede ser. Algo falla. Si los bancos han puesto el registro SPF y yo tengo el Sender ID configurado...¿cómo es posible que haya entrado este mail? La respuesta es bien fácil, una de las dos premisas no es cierta... y me ha dejado flipado.
Correo falso de un supuesto Banco
Tras comprobar el registro SPF del DNS del banco del mail he podido constatar la no existencia del mismo. Esta acción la he repetido con muchos bancos y las respuestas han sido desalentadoras, casi nadie implementa ese registro. ¿Por qué?. Ni puta idea.
Lo cierto es que un banco que se gasta pasta en auditorías de seguridad y que se gasta pasta en la lucha contra el fraude debería tener implementada una de las medidas más baratas y que más información ofrece a los usuarios a la hora de detectar correos falsos. Pero no es así. ¿Alguien me lo explica?. Haz una prueba con el DNS de tu banco y dime que encuentras...
Saludos Malignos!
Fuente: Un Informático en el lado del Mal
Desde que migramos nuestro servidor a Exchange Server 2007 y se realizó un assesment de las opciones de Anti-Spam, la verdad es que me cuesta recibir algún correo que llevar a la boca de esa carpeta.
El otro día, repasando con Joshua Sáenz, MVP de Exchange Server y compañero de I64, las opciones y el funcionamiento de los filtros ante correos suplantados, comprobamos el funcionamiento del servidor ante diferentes tipos de spam. Al final, no sabía si besar a Joshua o al Exchange Server 2007 por lo bien que se portan ambos.
El servidor tiene configurados filtros con RBL, filtro de Reputación (basado en registro PTR, estadística de SCL de los correos recibidos de ese servidor y prueba de proxy abierto), filtro de contenido (basado en la tecnología del IMF), soporte para recepción de correos cifrados con canal TLS y filtro de Sender ID.
Esta configuración ha hecho que, por ejemplo, correos de phishing tradicional que suplantan a bancos, hayan dejado de entrar en mi buzón tiempo ha. Esos correos que dicen venir del equipo técnico de un banco para que cambies la contraseña o entres en tu cuenta pinchando en el siguiente link. Esto me sucedió mucho durante un periodo con Cajamadrid.es.
Sin embargo, esto ya no me sucede jamás, porque la gente de Cajamadrid.es ha hecho los deberes y ha configurado el registro SPF en el DNS dando información a los servidores de correo que implementan Sender Policy Framework o Sender ID de quiénes son los servidores autorizados.
El uso del registro SPF ayuda especialmente a las entidades bancarias, víctimas tradicionales del envío de correos electrónicos falsos desde sus dominios, a evitar que lleguen al usuario final. Es un sencillo gesto, configurar un registro TXT en el DNS y se consigue que un porcentaje mayor de correos falsos en su nombre no lleguen a las posibles víctimas. Y eso se transforma en dinero.
Así, he podido ver que algunos han hecho los deberes, como Cajamadrid o Cajamar, ambas con registro SPF con la opción -all para que todos los correos que vengan de una IP no dada de alta en él sean destruidos automáticamente.
Registro SPF de Cajamadrid.es y Cajamar.es
Sin embargo, hoy recibí un correo falso de un banco y....alto, esto no puede ser. Algo falla. Si los bancos han puesto el registro SPF y yo tengo el Sender ID configurado...¿cómo es posible que haya entrado este mail? La respuesta es bien fácil, una de las dos premisas no es cierta... y me ha dejado flipado.
Correo falso de un supuesto Banco
Tras comprobar el registro SPF del DNS del banco del mail he podido constatar la no existencia del mismo. Esta acción la he repetido con muchos bancos y las respuestas han sido desalentadoras, casi nadie implementa ese registro. ¿Por qué?. Ni puta idea.
Lo cierto es que un banco que se gasta pasta en auditorías de seguridad y que se gasta pasta en la lucha contra el fraude debería tener implementada una de las medidas más baratas y que más información ofrece a los usuarios a la hora de detectar correos falsos. Pero no es así. ¿Alguien me lo explica?. Haz una prueba con el DNS de tu banco y dime que encuentras...
Saludos Malignos!
Fuente: Un Informático en el lado del Mal
0 Comments:
Publicar un comentario
Gracias por dejar un comentario en Segu-Info.
Gracias por comentar!