[GTER] Spam

[Renato Fernandes De Lima]

Sandro,
    Olá obrigado pelos comentários. Realmente resumindo seria uma lista com
checagem dinâmica.

>    Como foi citado anteriormente na lista como "interceptação de tcp/25".
>    Mas a sua idéia é capturar a sessão tcp/25 dos usuarios dial/speedy
> para a Internet ou o contrário, das conexões advindas da Internet para
> seus servidores?

    Todo o tráfego tcp com porta destino 25. Tanto inbound como outbound.
Acho que controlando o tráfego outbound controlariamos que nossas redes
mandem spam para fora. E controlando para inbound podemos protege-las. Acho
que o problema aqui seria:
1) implementar isso de modo transparente, ou seja, ainda queremos que no
servidor e-mail remoto receba o ip do servidor original como iniciador da
conexão;
2) privacidade: com certeza cairiamos em questões como: o isp está lendo
meus mails!
3) performace: isso tem que ser feito sem afetar equipamentos de rede ou
servidores em geral;

>    Ops, ai são dois lookup, certo? Um para saber se o dominio do "MAIL
> FROM" tem MX. E um outro para saber ser o IP de destino da conexão
> TCP/25 tem reverso ou para saber se existe reverso do IP que esta
> originado a conexão? Muitos servidores de email não tem o reverso
> configurado corretamente, não só no Brasil, como lá fora.

    Opa, desculpem e por favor ignorem a frase    "e o ip do servidor " no
item 2. O que queria dizer é que ele checa os MX apenas. Sem reverso. Nesso
caso penso que possíveis problemas seriam:
1)  Alguem possui ou conhece alguma arquitetura em que o servidor de mx não
é realmente aquele que envia o e-mail...simplificando o mx só recebe e-mail
e a saida do mesmo é por outro ip..existe ?

>    Para isso existem as RBLs, deve-se ter um critério para utiliza-las
para não haver a possibilidade de um falso negativo.
>    Além disso uma "white list" para não bloquear alguns clientes da
própria Telefonica, conhecidos spammers.

    O bom deste processo seria sua checagem dinâmica da situação. Isso não
afetaria os "bons clientes". Sendo que poderia ajudar. Estas listas seriam o
start inicial da base de dados de "maus clientes". ...hmm!?!? -)

>    Existem RBLs que contem listas de open relays, fazer testes de open
relay "on the fly" só iria gerar timeout nas suas conexões.
    Será que este timeout seria tão grande ? Talvez sim na primeira vez(vou
tentar realizar testes). Depois isso iria para um cache(tipo um cache que o
bind faz para não precisar fazer queries toda a hora).

>     Voce tem que ter alguma rotina de "garbage collection" para remover
IPs ou hosts que possam não mais estar listados, como no caso de "open
> relays" ou "open proxies".

    Sim. Mas o serviço não ia ficar checando toda a hora o servidor remoto
para verificar se o ip esta OK quanto aos bons parametros de segurança.  A
partir do momento que ele entrou na base de dados de ips "spammers" o
servidor remoto não é mais checado. Só é checado novamente se não tiver na
base(que seria removido por outra forma(um frontend que permitiria a
retirada manual - por exemplo). Problemas que consigo enxergar:

- Trabalho manual de operadores para isso seria necessário.

    Outra coisa pode ser o aviso automatico de pessoas envolvidas sobre o
caso(como um antivirus que checa virus em e-mail e emite uma resposta
automática para remetente e destinatario dizendo que seu e-mail foi
bloqueado).

>     Acho que esse deveria ser o item (6). Não entendi sua idéia de
"timeout", não seria na verdade um "ttl"? Ou seja a sua inteção é
> fazer sua propria RBL.

    O "timeout" seria, para falar a verdade, uma especie de cache com testes
já realizados. Quando o servidor estiver "OK" quanto aos parametros de
segurança ele entra em um cache. A partir dai ele não precisa ser
"rechecado" toda hora.

>      Se você não usa alguma RBL, terá que fazer testes extensos no IP
"bloqueado",  tanto para "open relay" e "open proxies" e os testes
> tem caracteristicas "invasivas".

    Sim teriamos que fazer estes testes. E isto é uma questão a ser vista
como um GRANDE problema.  Estes testes não seriam tantos em intensidade pois
o cache serviria para aliviar isto. Dan farmer e Wietse Venema já diziam em
1993  que "Improving the security of your site breaking into it" é o melhor
jeito! -)

>     Como você disse todo os MTAs já verificam se o dominio do "MAIL FROM"
tem MX. E alguns tem opção de fazer um "double checking" para
> verificar ser o reverso bate com o nome do host.
    É verdade. O que se faria a mais é apenas a checagem por "open relays".


>      Não é RFC. Spammers usam programas para depacho em massa de email,
que não precisam de um servidor SMTP. Muita gente adepta da
> instalação "Next->Next->Finish" não fazem o "feijão com arroz" e
confogiram corretamente os serviços do servidor.

     Nesse caso todo o tráfego smtp seria redirecionado por este "check smtp
server" (como acho que o Danton Nunes já sugeriu anteriormente). Depois o
serviço verificaria que o ip não pertence ao dominio X  e bloquearia o
tráfego.


>     Depende do volume, quanto mais emails/min., mais escalonavel tem que
ser essa implementação.
    Exatamente depende do volume.

>    Isso remete as questões tratadas na lista. Com que base legal você tera
> para trata-los? Se for um cliente seu, isso *poderia* estar em
> contrato, caso não seja, como processar alguem de Bostwana ?
>    Quanto ao whois revelar o nome do dono do dominio, nem sempre quer
> dizer que o contratante do serviço envie dados verdadeiros do serviço
> de registro, seja aqui ou lá fora, como o velho diar.com.br, tanto
> citado aqui nessa lista, cliente speedy da Telefonica.
    Vc tem razão  talvez não poderiamos processar mais sim notificar e
bloquear como os .mil fizeram conosco. A partir de então os dominios
".bos" -) não acessariam o bloco brasil -).


----- Original Message -----
From: "Enomoto" <senomoto at estadao.com.br>
To: <gter at eng.registro.br>
Sent: Thursday, January 16, 2003 2:04 PM
Subject: Re: [GTER] Spam


> -------- Mensagem Original --------
> >Assunto: [GTER] Spam
> >Remetente: "Renato Fernandes De Lima" <renato.lima at ticbrasil.com.br>
> >Data: Qui, 16 de Janeiro de 2003, 12:24
> >
> >
> > GTER,
> >     Olá, pensei sobre um processo simples e gostaria de saber o que
> > acham sobre o assunto:
> >
> > 1) Todo o tráfego smtp/25 seria redirecionado para um "check smtp
> > server" -)
>
>    Como foi citado anteriormente na lista como "interceptação de tcp/25".
>    Mas a sua idéia é capturar a sessão tcp/25 dos usuarios dial/speedy
> para a Internet ou o contrário, das conexões advindas da Internet para
> seus servidores?
>
> > 2) O "check smtp server" faria um lookup do mx do domínio e o
> > ip do servidor que estão mandando o e-mail
>
>    Ops, ai são dois lookup, certo? Um para saber se o dominio do "MAIL
> FROM" tem MX. E um outro para saber ser o IP de destino da conexão
> TCP/25 tem reverso ou para saber se existe reverso do IP que esta
> originado a conexão? Muitos servidores de email não tem o reverso
> configurado corretamente, não só no Brasil, como lá fora.
>
> >3) O "check smtp server"
> > verificaria em uma lista "oficial" de spammers para verificar se os
> > servidores em questão já se encontram na lista
>
>    Para isso existem as RBLs, deve-se ter um critério para utiliza-las
> para não haver a possibilidade de um falso negativo.
>    Além disso uma "white list" para não bloquear alguns clientes da
> própria Telefonica, conhecidos spammers.
>
> > 4) Se não estiver na
> > lista ele se conecta na porta smtp do ip e faz testes (que seriam
> > atualizados) para verificar se o servidor é um open relay
>
>    Existem RBLs que contem listas de open relays, fazer testes de open
> relay "on the fly" só iria gerar timeout nas suas conexões.
>
> > 5) Se o
> > servidor fosse um "open relay" ou estivesse de alguma forma aberta para
> > o spam o tráfego seria rejeitado. Adicionalmente o servidor seria
> > acrescentado em uma lista "oficial" de spammers. Nas próximas checagens
> > os testes não seriam mais necessários.
>
>     Voce tem que ter alguma rotina de "garbage collection" para remover
> IPs ou hosts que possam não mais estar listados, como no caso de "open
> relays" ou "open proxies".
>
> 7) Se o servidor não fosse um
> > "open relay" o tráfego seria permitido. É guardado um cache com um
> > "timeout" de valor X para não se refazer a checagem toda a hora
>
>     Acho que esse deveria ser o item (6). Não entendi sua idéia de
> "timeout", não seria na verdade um "ttl"? Ou seja a sua inteção é
> fazer sua propria RBL.
>
> > Ponto A) Para se tirar da lista de spammer testes seriam refeitos após
> > requisição formal de empresas que constem na lista(declaração que
> > ficaria disponivel a toda a comunidade). Além disto em casos de
> > reincidência o processo seria bem mais burocrático e demorado.
> > Automatizando este processo poderiamos inclusiver criar penalidades e
> > tempos cada vez maiores para sair da lista.
>
>      Se você não usa alguma RBL, terá que fazer testes extensos no IP
> "bloqueado",  tanto para "open relay" e "open proxies" e os testes
> tem caracteristicas "invasivas".
>
> > Ponto B) Se o domínio não existir o e-mail não pode ser enviado(isso já
> > deve ser feito pelos smtp tradicionais!)
>
>     Como você disse todo os MTAs já verificam se o dominio do "MAIL FROM"
> tem MX. E alguns tem opção de fazer um "double checking" para
> verificar ser o reverso bate com o nome do host.
>
> > Ponto C) Se alguem quiser montar um smtp server de testes com amigos
> > pode usar outra porta tcp - que tal a 26 !! -)
>
>      Não é RFC. Spammers usam programas para depacho em massa de email,
> que não precisam de um servidor SMTP. Muita gente adepta da
> instalação "Next->Next->Finish" não fazem o "feijão com arroz" e
> confogiram corretamente os serviços do servidor.
>
> > Ponto D) Este serviço pode ser implementado de forma centralizada ou
> > não. Pode estar contido em scripts ou códigos nos próprios smtp servers.
>
>     Depende do volume, quanto mais emails/min., mais escalonavel tem que
> ser essa implementação.
>
> > Ponto E) Se um dominio válido que tiver o servidor configurado de
> > maneira correta mandar spam este pode ser acionado judicialmente de
> > forma mais clara. Afinal uma consulta simples poderia revelar o nome dos
> > responsáveis pelo dominio. Através do novo código civil facilmente ações
> > poderiam ser tomadas.
>
>    Isso remete as questões tratadas na lista. Com que base legal você tera
> para trata-los? Se for um cliente seu, isso *poderia* estar em
> contrato, caso não seja, como processar alguem de Bostwana ?
>    Quanto ao whois revelar o nome do dono do dominio, nem sempre quer
> dizer que o contratante do serviço envie dados verdadeiros do serviço
> de registro, seja aqui ou lá fora, como o velho diar.com.br, tanto
> citado aqui nessa lista, cliente speedy da Telefonica.
>
>
> []s
> [Sandro]
>
>
> --------------------------------------------------
>                Email PLus Estadão
> Agora você pode ter mais ferramentas e espaço para
> armazenar seus emails.
> http://www.estadao.com.br/webmail/pago/
> --------------------------------------------------
>
>
> --
> GTER list    http://eng.registro.br/mailman/listinfo/gter