Verificação HELO
Introdução
Em se tratando de spam, existem certas características que podem distinguir um MTA (Mail Transfer Agent) "verdadeiro" de um MTA spammer. Este artigo tem por objetivo apresentar de forma sucinta os bastidores de uma técnica básica para a detecção e prevenção do recebimento de spams - a verificação do parâmetro HELO - também conhecida como HELO Verification.
Escondendo a identidade
O objetivo principal de qualquer spammner é esconder ou forjar a sua identidade, enquanto tenta enviar a maior quantidade de e-mails possível em um menor espaço de tempo. Caso contrário, não lhe valerá a pena! Então, o que pode ser feito para conseguir isso, não valer a pena?!
Toda comunicação entre quaisquer clientes (estações, servidores, etc.) na Internet é baseada em um elemento essencial para a sua identificação, o endereço IP. Este "quarteto de números" identifica unicamente cada "ponta" em um canal de comunicação, enquanto esta durar.
Quando um canal de comunicação - uma conexão - é finalizado e posteriormente reiniciado, os endereços IP podem ser alterados por vários motivos (IPs dinâmicos, contas de dial-up, balanceamento de carga, etc.).
Não importa quanto tempo uma conexão dure, ambas as "pontas" terão esta parte única de identificação denominada endereço IP. A maior parte dos endereços IP também possui um "endereço amigável" (um apelido) denominado hostname. O hostname é o que geralmente as pessoas reconhecem como "endereço internet". Quando uma pessoa lê "www.uniwares.com", ela está lendo na realidade um hostname. O seu computador deverá ser capaz de traduzir este nome em um endereço IP.
O protocolo usado para a transferência de e-mails entre duas partes é conhecido como SMTP (Simple Mail Transfer Protocol), sendo o mesmo tão simples quanto poderia ser.
Um dos principais pontos de falha do SMTP é a ausência de uma verificação das "identidades" durante o estabelecimento de uma conexão. Se os servidores de e-mail sempre tivessem sido escritos para suspeitar da identidade de um cliente, o problema do spam não teria evoluído dessa forma.
A especificação básica do protocolo SMTP (RFC 821) introduz o comando HELO, o qual inicia a comunicação entre dois MTA's. Na seção 3.5 desta RFC, tem-se:
HELO <domain> <CRLF>
No comando HELO, o servidor remetente deve identificar a si próprio; Este comando pode ser interpretado como a saudação "Alô, Eu sou <domain>".
Não existe uma garantia que <domain> deva ser válido, ou que este deva ser verificado - o cliente pode alegar ser de qualquer domínio. A maioria dos servidores de e-mail atuais recebem esta informação, a qual é fornecida pelo cliente como sendo verídica, e não efetuam qualquer tipo de verificação. Se o cliente alega ser "mail.hotmail.com", a maioria dos servidores irão aceitar esta informação como sendo válida, e nem mesmo irão gravar o endereço IP do mesmo, sendo este a única e valiosa forma de identificação do cliente. Portanto, um cliente mal-intencionado não poderá ser identificado.
O padrão é suficientemente claro: "No comando HELO, o servidor remetente deve identificar a si próprio". Então, o que acontece quando um servidor de e-mail começa a verificar as informações fornecidas pelo cliente e compará-las com a sua identidade real (o endereço IP)?
Qualquer sistema (MTA) operado corretamente reportará o seu nome verdadeiro (ou um de seus apelidos válidos) durante a abertura de uma conexão SMTP (Muito embora ainda existam alguns clientes mal-configurados em funcionamento). A maioria dos servidores mal-intencionados, os quais enviam spams, sequer cumprem as definições e princípios básicos e ainda fornecem nomes falsos ou inexistentes.
Diversos testes têm mostrado que esta simples verificação durante o estabelecimento da comunicação pode reduzir a entrada de spams em até 80%. Infelizmente existem algumas "agências de propagandas" que praticam spam como meio de vida. Estas possuem servidores de e-mail configurados "corretamente", os quais não podem ser detectados por esta técnica.
Leon Anti-Spam Server e a Verificação HELO
A verificação do comando HELO (HELO Verification) é uma característica básica do Leon Anti-Spam Server, estando presente em todas as suas versões. Para manter o padrão de flexibilidade do produto, esta opção pode ser ativada ou desativada de acordo com as necessidades de cada cliente.
A técnica de verificação do comando HELO no Leon é baseada no protocolo DNS, através do processo de resolução de nomes. Assim, com a ativação da opção de verificação, o servidor Leon irá verificar a veracidade das informações recebidas de um MTA remetente, durante a abertura de uma conexão SMTP. MTAs que não enviem o comando HELO, ou que o façam com informações incorretas, terão a sua conexão rejeitada pelo Leon.
Veja a seguinte animação a respeito do seu funcionamento:
O que acontece depois? O endereço IP do MTA remetente é adicionado a uma lista negra interna do Leon, a qual tem duração de 1 (uma) hora. Isto significa que qualquer cliente rejeitado pela verificação de HELO do Leon terá a sua conexão bloqueada por pelo menos uma hora.
13112003 094815:859 [15c] 0 debug client claims to be 'cwsp.cushman.com.br' but is 'cl-s0-c5511084007-cpe.rt.spo.ipaccess.diveo.net.br'(200.202.112.190)
13112003 094815:937 [d0] 0 info accepting connection from 200.202.112.190:19960 to 192.168.0.25:6400
13112003 094815:937 [d0] 0 debug aparently from cl-s0-c5511084007-cpe.rt.spo.ipaccess.diveo.net.br to infraero.gov.br
13112003 094815:937 [d0] 0 debug IP is not listed in RBL.
13112003 094816:015 [154] 0 debug client claims to be 'cwsp.cushman.com.br' but is 'cl-s0-c5511084007-cpe.rt.spo.ipaccess.diveo.net.br'(200.202.112.190)
13112003 094816:390 [15c] 0 info closing connection cl-s0-c5511084007-cpe.rt.spo.ipaccess.diveo.net.br [200.202.112.190:19960], 32 bytes received
13112003 094816:390 [15c] 0 debug Connection closed (4 active connections)
Quem nos deu o direito de fazer isso?
Como é de conhecimento de todos (pelo menos dos administradores de sistemas de e-mails), o protocolo SMTP foi desenvolvido nos primórdios da Internet, onde o roteamento entre as redes ainda não era totalmente automático, e o spam inexistia ou estava longe de ser considerado um problema.
O fato de não existir atualmente uma norma ou uma RFC que obrigue a correta utilização do comando HELO não impede que recursos sejam criados e utilizados para evitar e combater vulnerabilidades como esta. Além disso, forjar ou utilizar domínios inexistentes também não é uma atitude compatível com qualquer RFC.
Assim, organizações criadas com o propósito de catalogar e divulgar fontes de envio de e-mail não solicitados estão cada vez mais comuns. O texto abaixo foi retirado do site da SBL (Spamhaus Block List), e exemplifica a situação em questão:
"A Internet é uma rede composta de redes privadas. Ninguém tem o direito, sob a lei de qualquer país, de enviar e-mails não solicitados para redes que não aceitem estes tipos de mensagens, ninguém tem o direito de forçar os usuários de outras redes a receber qualquer tipo de comunicação não desejada, qualquer que seja o seu mérito. É do direito e responsabilidade de todas as redes implementar e fazer cumprir medidas para proteger seus usuários e sistemas de e-mail de fontes geradoras de e-mails não solicitados em massa. As redes que utilizam a SBL, a utilizam de forma livre e voluntária com o propósito de proteger clientes e equipamentos privados da "praga" do envio em massa de e-mails não solicitados. A SBL não objetiva restringir o fluxo normal de e-mails, mas proteger do fluxo de e-mails normais. O direito de identificar e listar ameaças para os usuários da SBL é dado a nós por cada usuário da Internet que utiliza a SBL."