[Seguridad] Spam - politicas SPs

[Jorge F. Messano]

Continuo con el mail anterior. 

Este mail en particular contiene una compilacion de las politicas "anti
spam" mas conocidas aplicadas por los Service Providers (SPs).

Tres comentarios previos. 
Primero: De esta lista he removido todas aquellas politicas que de alguna
manera hacen "analisis de contenido", pues a mi entender no podemos ni
debemos operar sobre el contenido de los mensajes.
No "debemos" pues el contenido del mensaje es de indole "privado". Hace al
derecho del destinatario y a las obligaciones del remitente. La
interpretacion del mensaje es un derecho del destinatario, y la
responsabilidad sobre el sentido del contenido es del remitente. Nuestra
responsabilidad como prestadores debe estar limitada a garantizar la entrega
del mensaje, independientemente del contenido del mismo.
Y no "podemos" operar sobre el contenido pues de hacerlo estariamos avalando
aquellas normativas que pretenden obligar al SP a filtrar el spam actuando
sobre el contenido, en contra del derecho.

Segundo: Ademas de las politicas de control de spam entrante, verán que
buena parte de las detalladas mas abajo tienen que ver con el control del
trafico saliente "puerto 25" de nuestras propias redes. Ese grupo de
politicas podria definir el marco operativo de "Buen Vecino"... es decir, lo
minimo que uno deberia hacer para no molestar a sus otros vecinos.

Tercero: Mientras transcribia estas politicas, decidi aprovechar el esfuerzo
y escribirlas a nivel "Discovery Channel"... es decir, con un lenguaje lo
suficientemente basico para que sea propagable y entendible fuera de
ambientes extremadamente tecnicos.

Dicho esto, resumo las "Best Practices" para Prestadores.

01. Cerrar los “Open Relays”.
Caso: Se considera “open relay” a aquel servidor de correo electrónico que
permite a un tercero (no vinculado al dueño del server) retransmitir correo
electrónico sin ningún mecanismo formal o informal de autenticación.
Recomendación 1: El SP debe configurar sus “open relays” como “secure
relays”. 
Recomendación 2: El SP debería verificar que el servidor remoto que solicita
establecer una sesion con sus propios servers no esté configurado como “open
relay”, autorizando o negando la conexión como resultado de esta acción.
Obviamente, el agregado de esta verificacion a las funcionalidades de los
sistemas de correo electrónico existentes implica costos, por lo que una
alternativa viable consiste en la suscripción a listas de “open relays”
disponibles en muchas organizaciones anti-Spam.

02. Supervisar los scripts “formmail.pl” y otras aplicaciones CGI.
Caso: Los programas generadores de correo electrónico tales como
“formmail.pl”, “CGI Email” y similares constituyen un grupo de alto riesgo. 
Por ejemplo, “formmail.pl” suele utilizarse en los formularios de respuesta
de los sitios web. Cuando un visitante ingresa su nombre y dirección en el
formulario, el script genera un mensaje de correo electrónico que luego es
enviado al dueño del sitio web en cuestión. Sin embargo, cuando
“formmail.pl” es instalado de forma insegura, habilita al spammer a generar
y enviar mails a su gusto, conviertiendo al server en un “open relay”.
Recomendación 1: Los SP, y especialmente los proveedores de Hosting, deben
revisar regularmente sus sistemas localizando todos aquellos programas mal
configurados o desactualizados que puedan ser utilizados para generar correo
electrónico.
Recomendacion 2: Nótese que al igual que estos scripts, existe el riesgo
potencial de que otros programas y sistemas conectados a la red puedan ser
utilizados por los spammers para enviar Spam en gran escala. 
Por tal motivo, la imposición de límites en las tasas de transmisión
aplicadas facultativamente sobre cuentas o circuitos específicos, puede
ayudar a acotar el daño que causaría un simple script inseguro.

03. Configurar los Proxies solo para uso interno.
Caso: Los “open proxies”, al igual que los open relays, permiten a terceros
enviar correo electrónico en forma anónima a cualquier dirección; sin
embargo, los “open proxies” constituyen un grupo especial pues aceptan
comunicaciones en puertos distintos a los estándares utilizados para enviar
correo electrónico.
Asi, los “open proxies” pueden ser usados, por ejemplo, para montar ataques
de “Denegación de Servicio” (DoS), hostear Web Sites sobre computadores
personales controlados remotamente por spammers sin el consentimiento de su
dueño, utilizar computadores personales para redirigir usuarios al sitio web
de un hacker, registrar cuentas de correo anónimamente, y para otros
propósitos del mismo tenor. 
Dado que los proxies normalmente no tienen configurado ningún mecanismo de
registro de actividad (log), se dificulta la tarea de descubrir a quien
abusa de un “open proxy”.
Recomendación 1: Los proxies deben ser configurados de forma tal que solo
permitan su uso a los usuarios internos de la red. 
Recomendacion 2: Solo si se cuenta con el presupuesto adecuado, seria
recomendable que el SP verifique y pruebe los proxies de sus clientes y
usuarios para determinar si alguno de ellos está mal configurado, o
configurado de tal forma que permita a terceros no autorizados hacer uso de
ellos.

04. Detectar y aislar a los “zombies”
Caso: Utilizando virus, worms, y malwares de todo tipo, los hackers y los
spammers han instalado inadvertidamente millones de “back doors”, open
relays y open proxies en los computadores personales de los usuarios.
La comunidad de spammers utiliza esta red de computadores “zombies” para
generar miles de millones de mensajes de correo electrónico no solicitados.
Adicionalmente, los hackers utilizan estos mismos recursos para montar
ataques del tipo DoS en forma distribuida, registrar cuentas fraudulentas, y
sentar las bases para futuras acciones de hacking.
Recomendación 1: Los SP deben implementar procedimientos para descubrir
“zombies” conectados a sus respectivas redes. 
Los procedimientos clasicos son los siguientes:
1. Atender y resolver las quejas de "abuso" enviadas por otros SPs.
2. Prestar atencion a incrementos puntuales en la cantidad de mensajes
enviados por las cuentas de correo propias.
3. Si fuese posible, efectuar scannings sobre la red interna buscando
computadores abiertos al abuso de terceros (open proxies y open relays).
En cualquier caso, aquel computador que muestre signos de haber sido tomado
por control remoto debe ser removido de la red o puesto en cuarentena, hasta
tanto haya sido removido el virus, gusano o malware que facilita el accionar
del spammer.
Comentario: Tal como fue discutido mas arriba, la política del “Buen Vecino”
requiere que los SPs se responsabilicen por todo el tráfico que emane del
puerto 25 de sus sistemas. 
Esto es especialmente importante en el caso del tráfico originado en los
“zombies”, pues ese tráfico puede incluir virus o gusanos que pondrían en
peligro a las redes o equipos de otros prestadores o usuarios.
Para muchos SPs que ofrecen servicios dirigidos al consumidor, la solución
más simple para detener el flujo de mensajes transportando gusanos y spam
consiste en bloquear el tráfico saliente del puerto 25 de sus redes. Sin
embargo, el bloqueo del puerto 25 a nivel de la red puede causar
inconvenientes a quienes necesitan operar sus propios mail servers, o
comunicarse con un servidor de correo en una red remota (como por ejemplo
aquellos operados por compañías de web hosting o que alojan dominios de
mail). 
En el primer caso, el Service Provider deberá desarrollar la capacidad de
identificar a aquellos usuarios que legítimamente necesitan operar sus
propios mail servers, a fin de habilitarles el paso a través del puerto 25.
En el segundo caso, los usuarios deberán usar el puerto 587 (Mail Submission
Port), el cual no deberá estar bloqueado por el Prestador. 
Un documento de “best practices” que discute esta recomendación se encuentra
en http://www.ietf.org/internet-drafts/draft-hutzler-spamops-05.txt. 
(Hasta hace un rato seguia siendo ...spamops-05.txt... si ya fue modificado,
probar con ...spamops-06.txt)

05. Autenticar la dirección IP del remitente.
Caso: La información contenida en el cabezal de un mensaje de correo
electrónico no es suficientemente confiable y verificable, impidiéndole
entonces al Prestador y al destinatario decidir si el mensaje es legítimo o
no.
Los spammers toman ventaja de este hecho encubriendo el origen y el
verdadero remitente fraguando la dirección y el nombre de dominio del
remitente. La misma técnica es usada por los hackers y quienes se dedican al
robo de identidad para encubrir su origen.
Recomendación 1: Implementar métodos de autenticación basados en atributos
verificables, tales como la dirección IP de origen del mensaje.
Actualmente, el único atributo confiable en el header de un mensaje de
correo electrónico es la dirección IP asignada al computador del cual
proviene. Dado esto, la dirección IP puede ser usada por quienes reciben el
correo electrónico para verificar otros atributos del cabezal del mensaje,
tales como el dominio del remitente. Este circuito de verificación puede ser
llevado a cabo utilizando la infraestructura de DNS actual, combinada con
cambios medianamente simples en las implementaciones de SMTP receptoras del
mensaje.
El DNS puede ser utilizado para verificar las direcciones IP de los mail
servers en cuestión. De esta forma, si la dirección IP del mail server que
envía el mensaje no esta declarada en el DNS; o mas aun, si no coincide con
la declarado para el dominio remitente indicado en el header del mensaje, el
receptor puede considerar a dicho mensaje como un intento de fraude y
aplicar la política local decidida para su tratamiento: poner el mensaje en
cuarentena, dejarlo en una carpeta especial del receptor, o bloquearlo
totalmente. 
Comentario: La información de los DNS constituye de hecho un “white
lists”... el mejor y mas viejo "white list". Si un dominio no esta en el
DNS, perfectamente puede asumirse que "no es valido".
Asimismo, el hecho de contar con un sistema de autenticación basado en la
dirección IP del remitente, es sumamente interesante y apropiado para
cualquier organización que desee defenderse a si misma contra el “domain
spoofing”, y especialmente valioso para organizaciones cuyas marcas son
afectadas por los spammers y por esquemas de “phishing”, tales como
servicios financieros y compañías de e-commerce. 

06. Autenticar el envío de e-mail
Caso: Los spammers toman ventaja de aquellos sistemas de correo electrónico
que no requieren de la autenticación del remitente antes de que este envíe
sus mensajes.
Recomendación: Implementar métodos de autenticación robustos a fin de
verificar la identidad del usuario antes de que este pueda acceder al
sistema de correo electrónico. 
Esto puede ser logrado de varias maneras, siendo lo más usual requerir algún
tipo de nombre de usuario y password para validar la cuenta en el sistema.
Comentario: Parece una recomendacion "tonta"... pero la importancia de un
sistema de correo electrónico autenticado está directamente relacionada al
tema principal: verificar la identidad de quien envía el mail.
Una vez que la identidad del remitente ha sido verificada, el receptor puede
confiar en la validez del mensaje. Luego, si surge algún tema de abuso, el
Prestador puede determinar el origen del mail y detener futuros abusos.
El mensaje aquí debe ser claro y simple. Recomendamos implementar los
métodos de autenticación más robustos que se encuentren disponibles. 
Al respecto, el protocolo SMTP AUTH es una buena forma de autenticación,
pero sucede que envía el password del usuario en texto legible a través de
la red. Una forma de autenticación más robusta consiste en el despliegue de
SMTP AUTH conjuntamente con el protocolo STARTTLS. Este protocolo codifica
el password forma similar a como lo hace HTTPS.
Además de esto, seria recomendable que la autenticación SMTP sea
implementada en el puerto 587, y que el Prestador aliente a sus usuarios a
configurar sus programas de correo electrónico de tal forma que utilicen
dicho puerto. De esta forma se proveerá una conexión adecuada y segura que
no dependerá de si la red filtra o no el tráfico de correo sobre el puerto
25.
Detalles acerca del Mail Submission Port (587)y SMTP autenticado pueden
encontrarse en:
http://www.ietf.org/rfc/rfc2476.txt
http://www.ietf.org/rfc/rfc2554.txt
http://www.ietf.org/internet-drafts/draft-hutzler-spamops-05.txt

07. Remover el acceso a los CPEs.
Caso: Los hackers y los spammers suelen utilizar los CPEs como relays o
proxies a fin de retransmitir spam a través de ellos. Normalmente, el hacker
o spammer debe conocer el password del CPE a fin de poder programarlo para
que realice esta función.
Recomendación: Asegurarse que el acceso remoto a esos CPEs está
deshabilitado, o que al menos no sean accessibles desde IPs fuera del
control propio, y que ese CPE no responde a los nombres de usuario y
password provistos por el fabricante del equipo.

08. Controlar el registro automático de cuentas.
Caso: Los spammers y hackers han desarrollado métodos para registrar
automáticamente cuentas en servicios de correo electronico, especialmente
aquellos que brindan cuentas gratuitas. 
Estas cuentas pueden ser utilizadas para muchos propósitos, incluyendo el
envío de spam y el montaje de ataques de tipo DoS.
Recomendación: Desarrollar e implementar métodos para bloquear la generación
automática de cuentas.
Para los SPs que brindan servicios pagos, esto puede incluir que la
solicitud y preautorización de un medio de pago provisto por el usuario como
requisito previo, antes de habilitarle el acceso a una cuenta de correo o
determinados privilegios de la misma. 
Para los Prestadores que brindan servicios gratuitos, esto puede incluir la
ejecución, por ejemplo, de un test de “Turing”, a fin de asegurarse que la
cuenta no ha sido solicitada por un script.

09. Cerrar los servicios de redirección Web susceptibles de abuso.
Caso: Los servicios de redirección son utilizados por las áreas de
“ad-serving” de muchas organizaciones para contabilizar los “clicks
through”. 
Desafortunadamente, muchos de estos servicios no solo pueden ser utilizados
por los clientes de aquellas organizaciones que legítimamente proveen
publicidad, sino que están abiertos al uso de cualquiera que quiera
utilizarlos. Esto permite a los spammers publicitar sus propios sitios y
productos, los que aparecen entonces "apoyados" por el Prestador que está
operando el servicio de redirección inseguro. Esto no solo dificulta el
bloqueo del URL recibido en el Spam, sino que también puede engañar a los
consumidores quienes piensan que el URL recibido es legítimo.
Recomendación: Asegurar todos los sistemas de redireccionamiento web que
puedan ser utilizados por terceros sin consentimiento.

10. Implementar sistemas de reporte de quejas y suscríbirse a los
existentes.
Caso: La detección del Spam es especialmente difícil sin conocer exactamente
que cree el receptor que es Spam y que no. Por esto es crítico que los SPs
cuenten con herramientas que les permitan a sus usuarios indicar que es lo
que consideran Spam. A partir de esta información los SPs pueden luego
analizar y determinar el tipo y nivel de Spam que están recibiendo, y los
métodos que los spammers utilizan para evadir sus sistemas de bloqueo y
filtrado.
Recomendación: Desarrollar sistemas y procedimientos para recibir reportes
de Spam y procesarlos en consecuencia.
Obviamente, este tipo de sistemas y procedimientos tienen costo operativo,
por lo que cada Prestador deberá determinar hasta donde está dispuesto a
involucrarse.
En cualqueir caso, lo minimo recomendable es atender a lo requerido por los
RFCs de correo electrónico. Es decir, crear las casillas “abuse” y
“postmaster”, las que deben ser chequeadas al menos en forma diaria para
responder reportes de abuso informados por fuentes externas.
En el caso extremo, y en particular los grandes Prestadores que cuentan con
suficiente volumen de usuarios (y por lo tanto de quejas) y recursos,
podrían por ejemplo desarrollar sistemas mas sofisticados en los cuales las
quejas puedan ser automáticamente cargadas en una base de datos. Esta
información puede ser utilizada luego para rastrear el Spam generado en
fuentes internas, y para proveer información a otros Prestadores acerca del
Spam originado en sus correspondientes redes.

11. Mantener informado al usuario.
Caso: El Spam no solo afecta al usuario, sino que buena parte del flujo de
Spam que corre en la red se genera en “zombies” propiedad de estos usuarios.

Es entonces allí donde se debe actuar, sea para ayudar al usuario a detener
la llegada de Spam a su sistema, como para prevenir la exposición de sus
recursos a la red.
Recomendación: En la medida de las posibilidades, informar a su comunidad de
usuarios acerca de la disponibilidad de herramientas destinadas a lidiar
contra el spam y el abuso de la mensajería. 
Es útil enfatizar este tema, especialmente cuando el usuario adquiere el
servicio, y enviar luego recordatorios y actualizaciones al respecto cada
vez que el tema lo amerite. 
Adicionalmente, sería tambien útil destinar un lugar en los web sites de
cada Prestador en la cual informar a sus clientes acerca de cómo pueden
lidiar contra el spam.


Hasta aqui he llegado hoy.
Saludos
  Jorge

-----Original Message-----
From: Jorge F. Messano [mailto:Jorge en Messano.com.ar] 
Sent: Tuesday, April 04, 2006 12:58 PM
To: 'seguridad en lacnic.net'
Subject: RE: [Seguridad] Spam - politicas

Marcelo, et al

> [...] he implementado las siguientes medidas tendientes
> a solucionar las 14 fallas. Mi propuesta es que si todos hacemos esto,
> el tema EMAIL pasa a ser un tema agradable y no perderíamos tanto
> tiempo...

Seria bueno compilar y comparar las medidas adoptadas por cada uno de los
aqui presentes, y a partir de ese trabajo tratar de elaborar un "grupo de
politicas anti spam genericas".
Lo ideal sería que este grupo de "politicas genericas" fuese de facil
implementacion, con inversion tendiente a cero, es decir utilizando
tecnologías, herramientas y protocolos ya existentes, y que por supuesto
asegure un minimo exito.
Al mismo tiempo, ya pensando a quien dirigir esas politicas, creo que
debemos ser amplios y trabajar mas alla de nuestro segmento (SPs),
recomendando "best practices" tambien para nuestros usuarios y clientes
quienes, al fin del dia, son los que hacen uso del correo electronico.

Digo esto ultimo pues a la fecha, prácticamente todo el accionar de los
spammers se basa en la explotación de “brechas de seguridad” existentes
tanto en las redes de los SPs, como en las PCs de los usuarios. Entonces,
cuanta más información acerca de como operan los spammers acerquemos al
punto donde existe la “brecha de seguridad”, mayor será la posibilidad de
reducir significativamente el nivel de spam.

Si me permiten, y como primer movimiento a partir de la propuesta de arriba,
a continuacion de este mensaje enviare otros con las listas de politicas que
llevo acumuladas durante los ultimos años.

Saludos
  Jorge Messano
  Sr. Technology Manager
  Telmark S.A.