[GTER] Data para Bloqueio da porta 25

[Rafael Henrique Faria]

Então Fabio, aí que entra o lado positivo da porta 587, como
obrigatoriamente tem que ter autenticação, o malware teria que se
autenticar para fazer o envio das mensagens... e com isso seria mais
fácil bloquear o usuário.

Enquanto que o malware enviando diretamente para o servidor destino
pela porta 25, dificilmente você conseguiria bloquear a origem, com um
malware enviando através de um login capturado, você bloqueia o login,
o cara vai entrar em contato, e vai receber a noticia que a conta dele
estava sendo usada para enviar spam.

IMHO, vai ficar bem mais facil para bloquear a origem dos spams.


2010/1/7 Fabio Catunda <fcatunda at lightcomm.com.br>:
> Eu venho acompanhando esse tópico do início, mas vou ser honesto, ainda não
> entendi em que o bloqueio vai ajudar.
>
> A grande vantagem que vi até o momento é que os provedores poderiam bloquear
> a porta 25/tcp, maravilha. Mas vocês não acham que os malwarez da vida vão
> se adaptar muito mais rápido do que os provedores de Internet?
>
> Att,
>
> Catunda!
>
> Danton Nunes wrote:
>>
>> On Thu, 7 Jan 2010, Rafael Henrique Faria wrote:
>>
>>> Acho que assim, para o lado do servidor, os benefícios não serão
>>> tantos, acredito que apenas 1:
>>>
>>> Por exemplo, se eu conectar direto no seu servidor a partir de
>>> qualquer máquina, eu consigo mandar uma mensagem para alguém do seu
>>> domínio através desta conexão, sem autenticar, pois o seu MTA irá
>>> apenas receber a mensagem como se eu fosse um MTA também.
>>
>> sim, é assim mesmo.
>>
>>> Mas claro, é possível contornar este procedimento verificando se o IP
>>> de origem da conexão é o MX do domínio em questão, e outras
>>> verificações do tipo.
>>
>> existe um jeito mais sofisticado de fazer isso que é o protocolo SPF, em
>> que o dono do domínio do remetente define uma lista de controle de acesso de
>> quem pode mandar email em nome do domínio.
>>
>>> Mas não permitindo que usuários comuns enviem mensagem pela porta 25,
>>> você pode fechar mais ainda o MTA, criando regras para certificar que
>>> a conexão de origem é um MTA válido. Mas nada que não possa ser
>>> realizado hoje.
>>
>> e como você distingue um MTA válido de um telnet na porta 25 do meu
>> notebook? as coisas não são tão pão-pão queijo-queijo assim.
>>
>>> Por exemplo, podemos ter um 200.x.x.0/24, com todas as portas TCP 25
>>> DEST bloqueadas. Então dá para garantir que nenhuma máquina desta
>>> faixa conseguirá se passar por um MTA e enviar mensagens.
>>
>> sim, porque MTAs conversam com outros MTAs justamente pela porta que está
>> bloqueada.
>>
>>> Agora se alguém de dentro desta rede, tentar enviar um e-mail através
>>> do seu servidor que ainda utilizará a porta 25, essa pessoa não
>>> conseguirá, mesmo que seja um e-mail valido.
>>
>> exatamente. mas como o servidor que ele usa é decente e segue as boas
>> regras do jogo, terá a porta 587 aberta para receber a submissão de
>> mensagens. então, tudo o que o usuário válido tem a fazer é configurar seu
>> cliente, trocar 25 por 587 e tacar lá suas credenciais. se o servidor for
>> indecente e não aceitar conexão pela 587 ainda resta a possibilidade de usar
>> um webmail, ou melhor ainda, trocar de provedor de serviço de correio para
>> um decente.
>>
>> usando a metáfora meio porca do correio comum, a 587 corresponde ao ato de
>> depositar o envelope na caixa do correio. a 25 é usada entre os vários
>> postos da empresa de correio. Assim como você não coloca sua carta
>> diretamente nas máquinas de classificação, também não deve enviar email para
>> servidores de transporte.
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



-- 
Rafael Henrique da Silva Faria
Grupo de Sistemas e Redes

Serviço Técnico de Informática
Faculdade de Ciências e Letras do Campus de Araraquara - UNESP