[Seguridad] Nuevo código de conducta anti-spam en Australia

Dom Abr 2 22:22:33 BRT 2006

Estimados.

He leído detenidamente todos los comentarios enviados hasta ahora
del tema SPAM, Phishing, virus ,etc y me alegra mucho que existe
gente TI competente en varios países y decidí aportar mi grano de
arena...

Mi nombre es Marcelo Maraboli y me desempeño como Jefe Area
de Redes y Comunicaciones (Servicios Internet) de una importante
universidad en Chile (UTFSM). Llevo 10 años en el cargo, y trabajo
con Internet casi desde los comienzos de la Internet en Chile (1990).

Hace más de 3 años vengo estudiando el tema de Fallas y Mecanismos
de Defensa del sistema de Email de Internet (no sólo SPAM, virus
y phishing) y me he dado cuenta que existen 2 deficiencias
generalizadas:

- el gran desconocimiento de cómo realmente funciona SMTP, cuáles
son sus fallas de diseño y cuáles son sus fallas de interacción,
en total 14. Me refiero al desconocimiento de los administradores
de los servicios de Email de Empresas e ISP.

En muchas ocasiones he tenido que "instruir" a otros admin
cómo configurar sus servicios de manera correcta. Me perdonarán
la osadía de decir esto, pero es verdad.

- La gran cantidad de mecanismos de defensa que existen, de los
cuales algunos en conjunto puede solucionar efectivamente una de
las 14 fallas, y otros mecanismos sólo proveen de mitigación
del problema y no una soluciòn final.

Habiendo dicho eso, 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...

- todos los computadores (PC) tienen denegado salida a Internet
hacia el puerto 25 SMTP, a excepción de servidores SMTP autorizados.
Parece simple, pero he visto varias empresas que no lo tienen 
habilitado. Esto erradica la emisión de emails provocados por virus,
erradica el SPAM generado internamente, etc..

- para enviar email, la única manera es vía SMTP_AUTH + TLS. Si
algún usuario se infecta con virus/emailer, no podrá enviar porque
dichos emisores son SMTP simples y no entienden TLS. En cada email
(como este) verán la autenticación realizada y por ende
el receptor puede validar al emisor. Muchas empresas instalan
SMTP_AUTH y no agregan el header correspondiente, por lo que el
receptor igual no tiene forma de verificar al emisor.

- Cada email entrante a la Universidad se le aplicada una serie
de pruebas:
	- antivirus (clamav)
	- antispam (spamassassin)
	- SPF	(anti fraude, phishing)
	- Domain Keys (igual)
	- greylist (anti slammer, anti spammer)
	- rate control (anti slammer, anti mail bombing)
	- SMTP flow control, cada flujo SMTP con un máximos de bps
		(anti DoS, DDos)
	- domain check : ningún email proveniente desde el exterior
	   puede venir con dirección de la Universidad, dado que
	   claramente es falsificado.
	- reglas clásicas de sendmail (check_domain, check_headers, etc.)

A modo de ilustración, me permito una leve corrección a mi
colega:  Antonio Galicia antoniogc en agc.com.mx dice sobre el "postgrey"...

 >Si consideramos que un muy alto porcentaje del correo no deseado (spam,
 >virus, phishing, etc) provienen de máquinas que no tienen un verdadero
 >MTA una manera límpia y rápida de evitar ese tráfico son las greylist
 >como la que implementa postgrey[1]. Lo que hace es crear un hash a
 >partir de algunos datos del correo como es la IP, el remitente y el
 >destinatario. Si es la primera vez que aparace ese hash simplemente lo
 >registra y le regresa un error 450 al cliente. Si hay un MTA "de verdad"
 >este reintetará pasado un tiempo, postgrey espera la nueva conexión
 >pasado un lapso de tiempo (300 segundos por default) y lo deja pasar.
 >¿Resultado? Que los correos "reales" van a tener un retraso de 5 minutos
 >la primera vez, el siguente si es en menos de un mes pasará de inmediato
 >en tanto que los correos no deseados normalmente no lo intentarán
 >nuevamente y simplemente nunca llegarán.

Esto anterior es "casi" verdad. Los emails de un MTA "de verdad"
serán re-transmitidos después de un tiempo que ESE MTA esté
programado para hacerlo, algunos 10m, otros 15m (default
de sendmail) y no cuando el Greylisting lo indique.

Esto me ha causado problemas con varias instituciones chilenas
que no tienen re-transmisión de emails rechazados temporalmente
(hablo de CODELCO, universidades, Ministerios, etc.) donde
dichos emails quedan eternamente en el QUEUE...

¿cómo vamos a implementar greylisting a nivel latino-america
si los email-admins ni siquiera vacían sus QUEUE ? :(

He notado que casi ninguna institucion en Chile ha publicado
su registro SPF o Domain Keys, ¿Qué pasaría si nos ponemos de
acuerdo para hacerlo en Latino-America ? podríamos detectar
los fraudes latinos ?

Considero que las únicas medidas decentes de aplicar y
que tienen efecto real son:

- greylisting http://hcpnet.free.fr/milter-greylist/
- Sender Policy Framework - SPF http://spf.pobox.com/
- Domain Keys http://antispam.yahoo.com/domainkeys
- CAMRAM http://www.camram.org/
  (emisor debe realizar un cálculo computacional definido
por el receptor para que éste le acepte su email. Con esto,
los spammers se van a 0, porque el "costo" computacional
es muy alto).... inteligente la solución!

Para los realmente interesados en SPAM, vean la última en:
- MIT SPAM Conference 2006 http://www.spamconference.org/

Sobre Australia....uf! 2 cosas antes del tema SPAM..

- en los años 199x, Australia sacó una ley que indica que todo
email sigue siendo propietario de quién lo envía. Por ende,
el que recibe un email NO TIENE DERECHO A HACER UN FORWARD
sin el consentimiento del emisor...!

- Por ley, todo sitio web que desee hacer un link a otro
sitio web, debe solicitar por escrito (o por email) una
autorización del otro. O sea, no es llegar un poner un
link....

Considero a Australia muy avanzado en el tema legislativo,
pero no necesariamente en la dirección correcta. No puedo
hacer responsable a los ISP del tráfico que circula por sus
cables, a excepción que el "criminal" sea un cliente directo.

Se imaginan que si llamo por AT&T a Osama bin Laden, entonces
es posible demandar a AT&T por terrorismo ?? caso distinto
es que AT&T tenga contrato de cliente con Osama...

Mi estudio sobre SMTP (donde 1 de los temas es SPAM) estará
publicado pronto y por ende libre para hacerles hagar llegar
una copia, de los cuales me gustaría recibir sus  expertas
opiniones (buenas y malas)...

disculpen lo extenso...

atentamente,

Webmaster Comtron wrote:
> Ricardo:
> 
> Quien establece este código es la ACMA, Australian Communications and 
> Media Authority, que es una entidad gubernamental, donde se puede ver 
> este link: 
> http://www.acma.gov.au/ACMAINTER.65640:STANDARD:304849823:pc=PC_100488
> con la información de prensa referida al mismo.
> 
> El código puede leerse en este pdf: 
> http://www.acma.gov.au/acmainterwr/telcomm/industry_codes/codes/iia%20spam%20code%20dec%202005.pdf
> y por lo que dice ahi, dicho código ha sido escrito entre muchos de los 
> actores tecnológicos para cumplir con lo establecido con la Spam Act 2003
> http://www.comlaw.gov.au/ComLaw/Legislation/ActCompilation1.nsf/0/DED153276FD7C6F9CA2570260013908A/$file/SpamAct03WD02.pdf
> y no correr el riesgo de caer en sus penalidades.
> 
> Lamentablemente, no he podido leer estos textos en forma completa, dadas 
> las limitaciones de tiempo que uno tiene, y muchas veces las 
> informaciones periodísticas contienen algunos vicios de resúmen que 
> dejan mas dudas que certezas.
> Calculo que estos documentos van a responder algunas de tus consultas.
> Y otras, como las "limitaciones razonables" que a propósito puse en 
> mayúsculas, las podremos discutir en esta lista, con casos como CUANTOS 
> mails diarios son razonables para un usuario, si habrá que distinguir 
> entre usuarios residenciales y comerciales, si se deberían filtrar o no 
> los datos dirigidos al puerto 25 de una red externa de un ISP, y una 
> larga lista de etcs.
> 
> Saludos
> 
> Javier
> 
> 
> 
>  
> Ricardo Presta escribió:
> 
>> Javier : Gracias por la info, sabés quién establece el código y las multas?
>> O que sucede con los isp o sistemas de correos globales si no lo cumplen.?
>>
>> La pregunta es porque no me queda claro si es una ley, un decreto una
>> resolución o un código gral. entre isp´s agrupados en algun foro o cámara
>> y como es ese modelo de multas quienes están alcanzados, quien las paga
>> con que fuerza se puede pretender cobrarlas a que se lo conisera spam o
>> que son limitaciones razonables etc.
>>
>>
>> Ricardo
>>
>>
>>
>>
>>  
>>
>>  
>>
> _______________________________________________
> Seguridad mailing list
> Seguridad en lacnic.net
> http://lacnic.net/mailman/listinfo/seguridad
> 

-- 
Marcelo Maraboli Rosselott
Jefe Area de Redes y Comunicaciones (Network & UNIX Systems Engineer)
Ingeniero Civil Electronico                     (Electronic Engineer)

Direccion Central de Servicios Computacionales (DCSC)
Universidad Tecnica Federico Santa Maria         phone: +56 32 654237
Chile.                                    http://elqui.dcsc.utfsm.cl/