Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
Sender ID
Artículo del 15 de Septiembre de 2004.
Publicado originalmente en Informatica64
El correo Spam es considerado hoy en día una autentica pandemia en Internet. Esta afirmación refleja una realidad admitida por todos y recoge un auténtico reto para la comunidad técnica. El número de mensajes que es enviado por virus-gusanos, campañas de marketing y publicidad ilegales, etc..., es superior al número de mensajes de correo "útiles". Estudios como Spam Survey II realizado por la empresa Sybari ( www.sybari.com ) recoge que sus clientes estiman el coste producido por el correo Spam en 301 € anuales por empleado.
Los mecanismos de defensa que se han empleado para evitar el "correo basura" son muchos y muy variados. Pero, desgraciadamente, las técnicas utilizadas por los spammers cambian y evolucionan permanentemente, para poder evitarlos.
Inicialmente se utilizaron filtros estáticos basados en la dirección de correo del emisor. Pero, evidentemente, en la gran mayoría de las ocasiones cuando se realiza un envío de correo Spam la dirección suele ser falsa. En estos territorios nadie es quien dice ser. Para poder bloquear una dirección de correo de un spammer es necesario garantizar que se está bloqueando la dirección correcta y no la de un usuario que no tiene nada que ver. Es decir, garantizar el No Repudio . Para poder asegurar que el bloqueo de una dirección de correo es correcto, debería haberse enviado el mensaje firmado, y lógicamente, no es algo a lo que acostumbren virus-gusanos y spammers.
Otra opción utilizada es la de bloquear la dirección IP de los servidores que envían masivamente correos Spam. Se mantienen en bases de datos DNS listas de servidores de correo a bloquear llamadas Realtime Blackhole Lists (RBL) . Los servidores de correo antes de recibir mensajes comprueban la dirección IP de origen contra una o varias RBLs, decidiendo si admiten o no dichos correos. Para evitar estos sistemas de protección, los hackers utilizan direcciones IP usurpadas o servidores de correo mal configurados (Open Relay) , lo que puede llevar a bloquear los servicios de usuarios y empresas que nada tienen que ver con los spammers.
La lista de mecanismos antispam es muy larga como la tecnología fingerprinting , Smartscreen utilizada en IMF (Intelligent Message Filter) , los filtros bayesianos , etc..., pero he mencionado las dos anteriores porque la nueva tecnología, Sender ID , que analizamos en el presente artículo, tiene que ver con ambas.
Para ayudar a mitigar la incidencia del correo Spam Microsoft ha mejorado todos los mecanismos antispam en Ms Exchange Server 2003 , pero es necesario un trabajo coordinado de toda la comunidad técnica para poder atajar el problema.
Microsoft presentó, el 13 de Febrero de 2004, la " Iniciativa Coordinada de Reducción de Correo Electrónico No Deseado" (CSRI) , en la que se presentaba una tecnología llamada Caller ID , que ofrecía una nueva herramienta para poder detectar correos enviados mediante técnicas de spoofing (suplantación).
Existían en el mercado alguna iniciativa que tenía el mismo objetivo, como por ejemplo SPF (Sender Policy Framework) de Meng Wong ( http://spf.pobox.com/ ) que incluso contaba con alguna implementación para Windows ( http://www.michaelbrumm.com ), o Submitter Optimization . Aunando estas tres iniciativas se presenta Sender ID al Internet Engineering Task Force (IETF) para desarrollar un estándar.
El objetivo de Sender ID es detectar que mensajes están siendo enviados desde servidores de correo que no corresponden con el dominio del remitente. La idea es sencilla; si recibimos un correo del dominio Informatica64.com su procedencia no puede ser otra que la de uno de sus servidores. Para identificar el conjunto de servidores de correo válidos, se dan de alta las direcciones IP de éstos en registros SPF dentro del servidor DNS que almacena los datos del dominio Informatica64.com.
Si el correo procede de un remitente que dice pertenecer al dominio Informatica64.com, pero la dirección IP del servidor origen no está dada de alta en los registros SPF del dominio, la conclusión es clara. Se trata de un correo con dirección de remitente suplantada y susceptible de ser falso, proceder de un virus gusano, o ser correo no deseado.
Si por el contrario, la procedencia del mensaje es de un servidor de correo presente en el registro SPF del dominio se trata de un correo no suplantado. A partir de este momento podemos filtrar por la dirección de remitente o la dirección IP del servidor de correo, sin riesgos de bloquear direcciones de correo erróneas o servidores no culpables.
El funcionamiento del filtro es el siguiente:
1.- El emisor envía el correo desde su servidor de correo entrante.
2.- El servidor de correo entrante de nuestra organización recibe el correo.
3.- El servidor de correo entrante de nuestra organización consulta los registros SPF del servidor DNS de la organización del supuesto remitente para comprobar que contiene la dirección IP desde la que se ha recibido el mensaje de correo.
4.- Si la dirección IP está en los registros SPF entonces será un correo autenticado. De lo contrario, es un correo falso.
Más información sobre este articulo en las siguientes direcciones Web:
- Sender ID:
http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx
- CSRI: http://www.microsoft.com/latam/twc/privacy/spam_csri.mspx
Publicado originalmente en Informatica64
El correo Spam es considerado hoy en día una autentica pandemia en Internet. Esta afirmación refleja una realidad admitida por todos y recoge un auténtico reto para la comunidad técnica. El número de mensajes que es enviado por virus-gusanos, campañas de marketing y publicidad ilegales, etc..., es superior al número de mensajes de correo "útiles". Estudios como Spam Survey II realizado por la empresa Sybari ( www.sybari.com ) recoge que sus clientes estiman el coste producido por el correo Spam en 301 € anuales por empleado.
Los mecanismos de defensa que se han empleado para evitar el "correo basura" son muchos y muy variados. Pero, desgraciadamente, las técnicas utilizadas por los spammers cambian y evolucionan permanentemente, para poder evitarlos.
Inicialmente se utilizaron filtros estáticos basados en la dirección de correo del emisor. Pero, evidentemente, en la gran mayoría de las ocasiones cuando se realiza un envío de correo Spam la dirección suele ser falsa. En estos territorios nadie es quien dice ser. Para poder bloquear una dirección de correo de un spammer es necesario garantizar que se está bloqueando la dirección correcta y no la de un usuario que no tiene nada que ver. Es decir, garantizar el No Repudio . Para poder asegurar que el bloqueo de una dirección de correo es correcto, debería haberse enviado el mensaje firmado, y lógicamente, no es algo a lo que acostumbren virus-gusanos y spammers.
Otra opción utilizada es la de bloquear la dirección IP de los servidores que envían masivamente correos Spam. Se mantienen en bases de datos DNS listas de servidores de correo a bloquear llamadas Realtime Blackhole Lists (RBL) . Los servidores de correo antes de recibir mensajes comprueban la dirección IP de origen contra una o varias RBLs, decidiendo si admiten o no dichos correos. Para evitar estos sistemas de protección, los hackers utilizan direcciones IP usurpadas o servidores de correo mal configurados (Open Relay) , lo que puede llevar a bloquear los servicios de usuarios y empresas que nada tienen que ver con los spammers.
La lista de mecanismos antispam es muy larga como la tecnología fingerprinting , Smartscreen utilizada en IMF (Intelligent Message Filter) , los filtros bayesianos , etc..., pero he mencionado las dos anteriores porque la nueva tecnología, Sender ID , que analizamos en el presente artículo, tiene que ver con ambas.
Para ayudar a mitigar la incidencia del correo Spam Microsoft ha mejorado todos los mecanismos antispam en Ms Exchange Server 2003 , pero es necesario un trabajo coordinado de toda la comunidad técnica para poder atajar el problema.
Microsoft presentó, el 13 de Febrero de 2004, la " Iniciativa Coordinada de Reducción de Correo Electrónico No Deseado" (CSRI) , en la que se presentaba una tecnología llamada Caller ID , que ofrecía una nueva herramienta para poder detectar correos enviados mediante técnicas de spoofing (suplantación).
Existían en el mercado alguna iniciativa que tenía el mismo objetivo, como por ejemplo SPF (Sender Policy Framework) de Meng Wong ( http://spf.pobox.com/ ) que incluso contaba con alguna implementación para Windows ( http://www.michaelbrumm.com ), o Submitter Optimization . Aunando estas tres iniciativas se presenta Sender ID al Internet Engineering Task Force (IETF) para desarrollar un estándar.
El objetivo de Sender ID es detectar que mensajes están siendo enviados desde servidores de correo que no corresponden con el dominio del remitente. La idea es sencilla; si recibimos un correo del dominio Informatica64.com su procedencia no puede ser otra que la de uno de sus servidores. Para identificar el conjunto de servidores de correo válidos, se dan de alta las direcciones IP de éstos en registros SPF dentro del servidor DNS que almacena los datos del dominio Informatica64.com.
Si el correo procede de un remitente que dice pertenecer al dominio Informatica64.com, pero la dirección IP del servidor origen no está dada de alta en los registros SPF del dominio, la conclusión es clara. Se trata de un correo con dirección de remitente suplantada y susceptible de ser falso, proceder de un virus gusano, o ser correo no deseado.
Si por el contrario, la procedencia del mensaje es de un servidor de correo presente en el registro SPF del dominio se trata de un correo no suplantado. A partir de este momento podemos filtrar por la dirección de remitente o la dirección IP del servidor de correo, sin riesgos de bloquear direcciones de correo erróneas o servidores no culpables.
El funcionamiento del filtro es el siguiente:
1.- El emisor envía el correo desde su servidor de correo entrante.
2.- El servidor de correo entrante de nuestra organización recibe el correo.
3.- El servidor de correo entrante de nuestra organización consulta los registros SPF del servidor DNS de la organización del supuesto remitente para comprobar que contiene la dirección IP desde la que se ha recibido el mensaje de correo.
4.- Si la dirección IP está en los registros SPF entonces será un correo autenticado. De lo contrario, es un correo falso.
Más información sobre este articulo en las siguientes direcciones Web:
- Sender ID:
http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx
- CSRI: http://www.microsoft.com/latam/twc/privacy/spam_csri.mspx
3 comentarios:
Yo los publico, pero aún me queda implementarlo en mi servidor. Buen artículo :)
Estoooo, no veo nada diferente a lo que ya hace el SPF.
Claro Net, es la misma idéa. SenderID es la puesta en común del Checker id (nombre original que dio Spectra a ese registro) para que fueran todos compatibles.
Publicar un comentario