Visite também: Currículo ·  Efetividade BR-Mac

O que é LinuxDownload LinuxApostila LinuxEnviar notícia


Spam: CGI.br determina bloqueio da porta 25 (smtp) a partir de janeiro

Segundo a cobertura no UOL Notícias, o Comitê Gestor da Internet no Brasil está divulgando que espera reduzir o tráfego de spam em até 90%. Para isso, empresas como Telefônica, Oi e Net vão atender à determinação de bloquear os dados transmitidos pela porta 25.

Enviado por Alexandro Silva (alexoslabsΘgmail·com):

“Para evitar a disseminação de spam, o Comite Gestor da Internet no Brasil (CGI.br) determinou o bloqueio do “local” por onde grande parte dos e-mail falsos são enviados, a porta 25 de seu computador. O bloqueio ocorre no dia 5 de janeiro de 2010.

Se você usa programas de gerenciamento de e-mails —como o Outlook, Thunderbird ou Mail— para não ficar impedido de mandar mensagens, a porta de envio deve ser trocada de 25 para 587. Usuários apenas de webmail não serão impactados.

“Com a implementação das recomendações, será mais difícil para que computadores zumbis sejam utilizados para o envio de spam, pois além de necessitar de um usuário e senha para utilizar o serviço de e-mail, ele ainda deverá burlar os possíveis controles antispam existentes no serviço mencionado”, diz Nelson Novaes, gerente de segurança do UOL.

A medida não é nova, órgãos internacionais aconselham o bloqueio da porta 25 desde 1998, mas apenas em 2005, provedores e operadoras de todo o mundo começaram a adotá-la em massa. O UOL oferece o acesso pela porta 587 desde 2004. Leia mais em UOL-Noticias” [referência: blog.alexos.com.br]


• Publicado por Augusto Campos em 2009-12-31

Comentários dos leitores

Os comentários são responsabilidade de seus autores, e não são analisados ou aprovados pelo BR-Linux. Leia os Termos de uso do BR-Linux.

    Frank (usuário não registrado) em 31/12/2009 às 9:12 am

    Demorou pra o órgão gestor tomar essa decisão, mas não sei se vai adiantar muita coisa. Possivelmente o tráfego de spam disseminados a partir de computadores zumbi localizados no Brasil irá diminuir num primeiro momento, mas logo os spammers passarão a utilizar a porta 587.

    Eduardo (usuário não registrado) em 31/12/2009 às 9:33 am

    Os provedores menores vem fazendo isso a mais de 10 anos. AGORA é que o comitê acordou pra mandioquinha? Comitê Gestor desse jeito era melhor nem ter.

    Bremm (usuário não registrado) em 31/12/2009 às 9:50 am

    @ Frank

    Para isso eles precisarão também saber a senha para autenticação no servidor SMTP. Não impossibilita, mas complica um pouco a vida destes ratos cibernéticos. Antigamente alguns provedores de e-mail já usavam o popb4smtp (pop before smtp, cuja transmissão de e-mail só é possível após proceder com o login e verificar a conta no pop3).

    Um outro problema é a capacidade de alguns spambots de lidarem com CAPTCHA e/ou JavaScript (em webmail). Neste caso, é interessante usar um “honeypot”, com um campo que um usuário normal não conseguiria preencher por não ser possível vê-lo (escondido pela CSS da página) mas o bot ao preenchê-lo não consegue validar sua tentativa de acesso, pois o backend exige aquele campo em branco por padrão.

    http://damienkatz.net/2007/01/negative_captch.html

    Com este artifício aliado ao JavaScript, não é necessário o CAPTCHA, eliminando mais de 90% dos spambots e preservando a paciência dos usuários. O CAPTCHA só é interessante para prevenir ataques de quebra de senha por dicionário, depois de “n” tentativas de login sem sucesso.

    Anderson Santos (usuário não registrado) em 31/12/2009 às 9:57 am

    So para deixar claro para quem nao tem tanta experiencia com servidores, o que eles estao propondo eh mudar o envio de mensagens entre o Outlook e o servidor do provedor, alterando-se a porta e exigindo a autenticacao de quem envia.

    Mas esta proposta nao muda a comunicacao entre servidores, que continua sendo realizada pela porta 25.

    Alem da mundanca proposta, quem gerencia servidores postfix pode colocar a seguinte regra:

    smtpd_sender_restrictions = …outras regras…
    reject_authenticated_sender_login_mismatch,
    …outras regras…

    O reject_authenticated_sender_login_mismatch forca que o email enviado tem de ser obrigatoriamente do mesmo usuario que se autenticou, dificultando assim que enviem-se emails em nome de outros usuarios.

    Em redes com senhas de email fracas, eh relativamente facil um spamer usar um usuario legitimo para envio de emails, e este reject dificulta um pouco estes envios.

    Entretanto este reject traz impactos negativos em servidores que precisem enviar emails em nome de contas alias, mas mesmo assim eh uma medida bastante interessante.

    Eduardo Kalinowski (usuário não registrado) em 31/12/2009 às 10:04 am

    Para usuários domésticos é só trocar a porta 25 pela porta 587… desde que o servidor SMTP do outro lado suporte recepção na porta 587, claro :-) (Em tese todos deveriam suportar, com autenticação. Na prática…)

    Ozzy (usuário não registrado) em 31/12/2009 às 10:45 am

    Hmmmm… que eu saiba o CGI.br não tem poderes para determinar tal procedimento, mas ele vem sugerindo isso a *muitos anos* as grandes operadoras é que teimavam em não fazer. Acho que finalmente o volume insuportável de spam começou a pesar na contabilidade e elas resolveram tomar esta providência, que aliás já vem sendo adotada com sucesso em muitos países a bastantem tempo.

    Que bom ! Vamos começar 2010 com a rede um pouco melhor !!

    Aliás, FELIZ 2010 a todos(as) !!

    O.O.

    try{
    Connect(25){

    try{
    Connect(25){
    exception(Connect(587));
    }

    ehueheueheuh

    Rafael Gomes (usuário não registrado) em 31/12/2009 às 11:22 am

    Vou repetir aqui, o que comentei no blog de referência:

    Não entendi realmente onde eles desejam chegar, pois essa medida apenas diminuirá momentaneamente o SPAM, pois é somente o tempo dos spamers descobrirem essa nova porta e a utilizarem.

    Veja que o fato de mudar a porta não implica em um email autenticado. São coisas distintas.

    Acredito que seja uma ação desesperada para diminuir o caos que vivemos com os spams, mas não será uma mudança realmente efetiva no combate ao spam.

    Eu realmente estou me perguntando o porque dessa ação, já que até o momento não vejo um efeito prático tão bom, que justifique toda a mudança.

    Acredito que os comentários posteriores possam me mostrar algum detalhe que possa ter passado despercebido por mim.

    Valcir S. (usuário não registrado) em 31/12/2009 às 11:51 am

    Acredito que essa notícia está um tanto quanto equivocada.

    Não percebi nenhuma movimentação do cgi.br determinando o bloqueio a partir da data mencionada.

    Até onde eu sei o cgi.br vem trabalhando a tempos com a Gerencia da Porta 25 http://antispam.br/admin/porta25/ que são algumas recomendações para diminuir a quantidade de spams, e é claro que não está apenas previsto alterar a porta 25 para 587.

    Com certeza o número de spams não vai cair a zero, mas irá diminuir. A ação no meu ponto de vista visa combater principalmente as bootnets.

    Luciano (usuário não registrado) em 31/12/2009 às 11:53 am

    Simplificadamente, o fluxo do e-mail é o seguinte: (remetente) -> (porta 25 do servidor de e-mail do remetente) -> (porta 25 do servidor de e-mail do destinatário). Perceba que o servidor de e-mail do cliente precisa se conectar à porta 25 do servidor de e-mail do destinatário, exatamente a mesma porta que o destinatário se conectaria para enviar seus e-mails.

    Ou seja, quando é um outro servidor se conectando, não se pode exigir senha. Então, um spammer poderia colocar sua máquina para operar como se fosse um servidor smtp fazendo o devido encaminhamento das mensagens. Claro que existem técnicas para reduzir o impacto, como blacklist de ips e verificação de dns reverso.

    Mudando de porta, pode-se deixar a porta 587 exclusivamente para acessos autenticados cliente->servidor e a porta 25 para comunicação servidor->servidor.

    José (usuário não registrado) em 31/12/2009 às 11:55 am

    Isto não adiantará de nada. Várias empresas vendem “e-mail marketing”, que na verdade não passa de SPAM mascarado. Ao mesmo tempo em que são contra o SPAM, não abrem mão de vender … A tendência é piorar …

    Sem contar grandes provedores que são coniventes com SPAM como a Locaweb. Eu recebo constantes spam vindos de lá ou ao menos de sites hospedados lá, cansei de reclamar e não ouvir um pio de resposta.

    Marcelovborro (usuário não registrado) em 31/12/2009 às 12:39 pm

    Aos que estão em dúvida sobre a eficácia do bloqueio da porta 25 para os usuários domésticos, eu sugiro a leitura de http://www.ietf.org/rfc/rfc4409.txt

    A porta 587 somente aceita conexões smtp autenticadas, ao contrário da 25.

    Os “programadores” de vírus deveriam sugerir algum algorítmo para descobrir senhas ;-)

    Philippe (usuário não registrado) em 31/12/2009 às 1:58 pm

    A Porta25 que deveriam bloquear é esta:

    http://port25.technet.com/

    hehehe

    Locaweb realmente é suspeita. Parece até que eles ganham algo pra isso, mas não podemos afirmar.

    Por esses e uma série de outros motivos, trocamos a hospedagem na Locaweb pelo Google. Mais barato, mais rápido e com uma p* estrutura.

    abcd@abcd.com.br (usuário não registrado) em 31/12/2009 às 4:29 pm

    daqui há pouco não bastará trocar a porta 25 pela 587 nos zumbis para continuar mandando spam????

    Genilson (usuário não registrado) em 31/12/2009 às 5:28 pm

    Eu li os comentários e acho tudo isso muito estranho. Até onde eu sei os servidores de e-mail smtp que usam a porta 25 exigem senha para envio de e-mails. Por que tem gente aqui falando que não?
    Eu por exemplo quando cadastro no outlook um e-mail e ponho lá os dados do servidor smtp usando a porta 25, só manda e-mail se eu colocar senha. Se eu deixar a senha em branco dá erro.
    Antigamente não tinha senha, e eu lembro muito bem disso. Mas hoje, se tiver algum servidor que não use senha, deve ser coisa rara. Quero saber, além disso, como é possível um servidor bloquear a porta 25 de outro. Por exemplo, o cara conecta num servidor smtp problemático (“@seilaoque.com”) que não usa senha, manda um spam, e este encaminha para o servidor de e-mail da vítima (por ex. “@hotmail.com”). O uso da porta 25 só ocorreu no momento inicial, e foi usado e-mail falso, chegou ao destino sem que alguém pudesse evitar, porque aquele servidor se comunica com o servidor da vítima usando outra porta.

    Rafael Peregrino da Silva (usuário não registrado) em 31/12/2009 às 5:35 pm

    A solução para os problemas de SPAM é muito mais simples: basta todo mundo aderir final e integralmente ao padrão SPF! Mais detalhes em:

    http://pt.wikipedia.org/wiki/Sender_Policy_Framework

    Abraços,

    Rafael Peregrino da Silva
    Linux Magazine

    MarcusJabber (usuário não registrado) em 1/01/2010 às 6:22 pm

    @Rafael

    O problema desta solução é, se o yahoo nao aderir ao SPF, ou o hotmail. Voce rejeitaria eles?

    Tambem concordo com o colega acima, desconheco algum servidor que nao requeira autenticacao na porta 25.

    Abs!

    Rafael Peregrino da Silva (usuário não registrado) em 1/01/2010 às 8:51 pm

    Olá Marcus,

    Sexta, 01/01/2010 às 18:22, MarcusJabber escreveu:
    O problema desta solução é, se o yahoo nao aderir ao SPF, ou o hotmail. Voce rejeitaria eles?

    Foi por isso que eu escrevi que TODO MUNDO precisaria aderir total e integralmente ao padrão SPF. Aliás, se somente o GMail ou o Hotmail já o fizessem, o resto do mundo viria atrás (incluindo provavelmente o Yahoo!, de roldão por conta do acordo com a Microsoft). Precisaríamos de uma campanha global nesse sentido. Qualquer outra solução, a meu ver, tem mero efeito paliativo e não resolve o problema de verdade.

    Abraços,

    Rafael Peregrino da Silva
    Linux Magazine

    André Luis Pereira (usuário não registrado) em 2/01/2010 às 12:14 am

    Tem muitos equívocos na interpretação desse movimento do CGI e dos ISPs.

    O que está sendo feito é um entendimento entre o CGI e os ISPs que desejarem aderir às suas recomendações. Os ISPs não são obrigados a bloquear a porta 25. Os que fizerem, farão por espontânea vontade.

    arnaldocan (usuário não registrado) em 2/01/2010 às 2:21 am

    @Rafael Gomes e @Genilson

    Existe uma sutileza no protocolo SMTP que passa despercebida por muita gente. O envio do e-mail é feito em duas etapas (veja a explicação do Luciano):

    1 – Da máquina do remetente para o servidor de e-mails do remetente (dá para exigir autenticação).
    2 – Do servidor de e-mail do remetente para o servidor de e-mail do destinatário (não dá para exigir autenticação, pois um provedor não tem como autenciar usuários do outro).

    A idéia é que a etapa 1 seja feita na porta 587 e a etapa 2 na porta 25. Assim, a telefônica e os outros grandes provedores podem tornar a autenticação obrigatória bloqueando o tráfego da porta 25 nas máquinas dos usuários comuns.

    Isso complica bastante a vida do spammer, que agora além de invadir a máquina do usuário, precisa descobrir o servidor de e-mails dele e a respectiva senha para se autenticar.

    O objetivo é desestimular os spammers de usarem máquinas invadidas na rede desses provedores para o envio de e-mails.

    CarlosCaldas (usuário não registrado) em 2/01/2010 às 9:48 am

    Em minha opinião essa medida irá influenciar (mas não muito), uma vez que os Spammers poderão invadir máquinas e criar servidores fora do Brasil. Ou será que as empresas brasileiras vão descartar dados da porta 25 que vierem de fora?

    MarcusJabber (usuário não registrado) em 2/01/2010 às 3:40 pm

    @Rafael Peregrino da Silva

    Sim, entendi. =)

    Abs!

    Exatamente como esclareceu o arnaldocan, considerando o modelo atual, podemos afirmar que não é necessário autenticação para enviar uma mensagem para qualquer endereço de e-mail. Caso você mesmo queira enviar um e-mail para fulano@ciclano.com.br a partir de seu próprio computador, ou seja, sem necessidade de usar um servidor com autenticação, basta descobrir qual é o servidor MX do domínio, conectar em sua porta 25 e enviar a mensagem.

    Em uma linguagem mais simples de entender:
    $ nslookup -type=MX ciclano.com.br
    Non-authoritative answer:
    ciclano.com.br mail exchanger = 10 mail.ciclano.com.br.

    $ telnet mail.ciclano.com.br 25

    mail from: beltrano@hotmail.com
    rcpt to: fulano@ciclano.com.br
    data
    MENSAGEM
    .

    O propósito do CGI.br é impedir que os usuários domésticos se comuniquem diretamente com os servidores de e-mail através da porta 25. Como as botnets se valem dessa comunicação sem autenticação para fazer a farra, espera-se reduzir a grande maioria do volume de Spam.

    O Rafael Peregrino disse muito bem. Qualquer solução em relação ao SMTP infelizmente é paliativa. Ninguém se atreve a modificar o modelo atual com medo das conseqüências, e os únicos com força suficiente para ditar um padrão seriam os grandes provedores.

    Flávio Gomes Coutinho (usuário não registrado) em 3/01/2010 às 11:59 pm

    Deve haver algum problema com o autenticidade de e-mail enviados pelo serviço SMTP. Tanto que o Yahoo e o Gmail aderiram ao DomainKeys.

    Viana (usuário não registrado) em 4/01/2010 às 12:02 am

    O que muda é que será mais difícil para vc montar uma rede de spambots que os users utilizem tal provedor. Mas os servidores SMTP e redes de spam estrangeiras continuaram firme e forte.

    Guilherme Alves (usuário não registrado) em 4/01/2010 às 10:09 am

    Repetindo o que foi dito por algumas pessoas, parece estar havendo algum equívoco. Não achei no site do CGI nenhuma referência ao bloqueio referido, mas sim à RECOMENDAÇÃO. Em contato com o suporte da OI (uma dos operadoras citadas na referência) fui informado de que não existe nenhum tipo de bloqueio na porta 25, e nenhuma informação sobre isso.

    Parece, de fato, que o UOL resolveu atender a recomendação do CGI, e no mais vai depender de cada servidor de e-mail atender às recomendações ou não, mas não de bloqueio na porta 25 pelas operadoras.

    A impressão que fica é de que haveria um bloqueio irrestrito na porta 25, mas acho que isso não procede. Me corrijam se eu estiver errado…

    Lewis (usuário não registrado) em 4/01/2010 às 11:26 am

    SMTP, TCP/IP, tudo isso tem que mudar.

    O Rafael está corretíssimo e eu incluo todos os protocolos da stack TCP/IP, está tudo atrasado!!!

    Além disso, acredito que essa “solução” será muito temporária, pois afetará apenas maquinas zumbis que não atualizam seus vírus automaticamente, diferente do Conflicker por exemplo.

    Patrick (usuário não registrado) em 4/01/2010 às 3:44 pm

    Acredito que não haverá nenhum bloqueio por parte das operadoras “por enquanto”.

    Assim como disse o Guilherme Alves, no site do CGI.br apenas há a recomendação.

    Acho que o UOL ou leu errado no site do CGI.br ou está tentando fazer com que os usuários passem trocar de porta. Se eles mesmos bloquearem a porta 25 talvez o plano deles funcione.

    Agora, se as operadoras podem bloquear o Youtube, porque não bloquearem a porta 25? Quem sabe algum dia elas façam algo em conjunto para ajudar a grande rede a continuar viva…

    Vamos esperar

    Abraço
    Patrick

    Pablo (usuário não registrado) em 5/01/2010 às 10:19 am

    Quais tipos de modificação devo fazer em meu postfix?

    Davi (usuário não registrado) em 5/01/2010 às 10:51 am

    Qual a dificuldade de vcs entenderem que se as operadoras de Internet bloquearem a porta 25 o SPAM vai diminuir? Por favor me expliquem? Não tinha que se uma recomendação a gerencia da porta 25 e sim obrigatório..

    Abs,

    João (usuário não registrado) em 5/01/2010 às 10:53 am

    Isso só vai complicar a vida de quem presta suporte e serviços de e-mail, e também para os usuários que terão que se virar para mudar as configurações de suas ferramentas de e-mail, ou pagar um técnico para efetuar esta tarefa. A única coisa que está mudando com isso tudo, é a porta para acesso. Atualmente grande parte dos SPAMS ocorre em servidores fora do Brasil e os que ocorrem aqui, são enviados por grandes empresas de e-mail marketing (SPAM), que possuem servidores e provedores dentro e fora do país. Funciona da seguinte maneira:

    Você compra um pacote de “e-mail marketing” ou “mala direta” ou se preferir “SPAM” mesmo. A empresa lhe envia um CD, com centenas de milhares de contas de e-mail, normalmente de empresas e pessoas interessadas no assunto (ou não). Você coloca este disco no seu computador, em qualquer lugar do mundo, este software faz a conexão com o servidor da empresa de “e-mail marketing” e os e-mails começam a ser disparados da sua máquina, conectada ao servidor da empresa prestadora de serviços de SPAM.

    Agora você imagine, esta empresa vai ter o trabalho de apenas mudar a porta onde o software que está no CD vai se conectar ao servidor deles. Não vai mudar em NADA! Enquanto isso, vamos ter que adaptar serviços e nossos programas pessoais para esta “mudança”. O que tem que ser feito, é a prisão e desmanche dessas “quadrilhas” que fabricam estas soluções de e-mail marketing, por invasão de privacidade e venda de informações pessoais de terceiros sem autorização (noma e e-mail). Busca e bloqueio de domínios e IPs de empresas que prestam estes serviços seria no mínimo racional.

    Não sou profeta, mas leiam com atenção. Nos 2 primeiros meses, vai ser uma maravilha quanto ao número de spams recebidos, pois os softwares antigos de e-mail em massa não vão mais funcionar. Após 2 meses, tudo voltará ao normal, e você ainda vai estar se quebrando para re-configurar algumas contas de e-mail em seu Thunderbird, mozilla-mail, epiphany ou qualquer outra ferramenta para envio/recebimento de e-mails.

    Davi (usuário não registrado) em 5/01/2010 às 11:58 am

    Engano seu meu caro. Os caras que recomendam esta gerencia da porta 25 não inventaram a regra do nada e sim em pesquisas de vários anos. Todos os lugares que a gerencia da porta 25 foi implantado os resultados foram bastantes satisfatórios. Realmente a regra não se aplica para quem vende email marketing, mas para todos os PCs zumbis a regra se aplica.

    Abraços,

Este post é antigo (2009-12-31) e foi arquivado. O envio de novos comentários a este post já expirou.