Haciéndole la vida difícil a los Spammers: SMTP Tar Pitting (Pozo de Brea)

NOTA:

Este post fue publicado originalmente en mi anterior blog el
14/08/2007. 
Hice algunos cambios, modificaciones y adiciones para mejorar el artículo

Como vimos en los artículos sobre envío de correo SMTP (PARTE I, PARTE II y Relay), al establecer una conexión SMTP es bastante fácil poder obtener una lista de las direcciones de correo válidas en un dominio: Basta con adivinar los nombres de usuario al enviar al correo el comando “rcpt to: <usuario_adivinando>@dominio.org”.
Por ejemplo, si Juan Pérez tiene una cuenta de correo jperez@dominio.org, generalmente veremos en los logs de recepción (y/o bloqueo) de correo, más de algún mensaje dirigido a casillas del tipo: jperez128@dominio.org, juanjperez@dominio.org, etc.  Claramente el spammer está intentando adivinar direcciones de correo válidas.

Si tenemos habilitado en nuestro servidor Exchange el filtrado por destinatario (recipient filter) para que no acepte mensajes a destinatarios que no están en el directorio, es decir, sólo reciba correos para destinatarios que posean una dirección de correo válida, el servidor entregará un mensaje de error con código 5.x.y al atacante durante la conexión smtp.
Esto tiene 3 problemas:

  1. Estamos dando –indirectamente – a nuestro atacante información sobre cuáles son las direcciones de correo electrónico válidas en nuestra organización.
  2. Nuestro servidor SMTP está procesando un alto volumen de peticiones del atacante y realizando una gran cantidad de consultas al Servicio de Directorio (Active Directory), consumiendo inútilmente recursos valiosos.
  3. El servidor de correo está obligado, por adhesión a la RFC 2821 a enviar un correo con un NDR al “remitente” que trata de enviar correos a las direcciones “equivocadas”. En el caso de un ataque, aún más recursos desperdiciados y posibilidad de caer en listas de backscatter.

La situación recién mencionada es conocida como un ataque de Directory Harvest, o “Cosecha de Directorio”.

Como respuesta a este problema, se puede implementar en nuestros servidores SMTP la funcionalidad de Tar Pitting, la cual consiste en introducir un retraso en las respuestas con código 5.x.y, usualmente asociadas a problemas derivados de ataques de SPAM.

Exchange 2003

La funcionalidad de TarPitting no es exclusiva de Exchange 2003, pues es una característica del servidor SMTP, y por tanto de IIS, la cual está disponible para cualquier equipo tenga instalado el SP1 de Windows 2003 Server.

Cómo se configura?

Súper simple.

  1. Debemos abrir el editor del registro (Inicio -> Ejecutar -> Regedit).
  2. Buscamos la siguiente ruta: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesSMTPSVCParameters
  3. Clic derecho – Nuevo Valor DWORD.
  4. Escribir: TarpitTime (OJO con las mayúsculas y minúsculas), Presionar Enter.
  5. Abrir el nuevo valor creado (TarpitTime) haciendo doble clic sobre él, luego haga clic sobre decimal e ingrese un número en el cuadro de texto. Por ejemplo: 8.
  6. Cierre el editor de Registro.
  7. Reinicie el Servicio SMTP del servidor.

Qué hicimos?. Creamos el valor en el registro y configuramos una demora de 8 segundos en las respuestas del tipo 5.x.y.
Por qué 8 segundos? porque 8 segundos es un tiempo razonable para que un usuario que escribió mal una dirección espere por su respuesta, pero es una eternidad para un robot spammer ;)… además, me gusta el número 8 :p

Referencias:

Exchange 2007/2010:

En Exchange 2007 la configuración de TarPit viene habilitada de forma predeterminada en los conectores de recepción (Servidores de Transporte) en un valor de 5 segundos. Para revisar esta configuración se puede utilizar el cmdlet:

get-ReceiveConnector | select name,tarpitinterval

y para modificar esta configuración, se puede usar este comando:

set-ReceiveConnector "Receive Connector Name" -tarpitinterval 00:00:10

hay que reemplazar el nombre del conector y el valor de la demora en horas:minutos:segundos

Referencias:

 

Bonus: Mi Amigo Christian Aguilera me comentó que además el retraso tiene una “Duración Aleatoria”. Con esto se persigue engañar a los robots de spam, para que así no logren detectar que existe un mecanismo de Tar Pitting configurado en nuestro servidor. Esta es una de las ventajas que Exchange 2007 traiga su propio servicio SMTP (y ya no use el servicio SMTP del IIS).


Si quieren conocer más sobre Exchange 2007, les recomiendo los sitios de:

 

Gonzalo

2 comentarios en “Haciéndole la vida difícil a los Spammers: SMTP Tar Pitting (Pozo de Brea)”

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *