Como interpretar o cabeçalho de um spam
Marlon Borba
Após perceber que recebeu mais um spam, depois de vários minutos
conectado e à espera das mensagens, você se pergunta o que poderia fazer
para combater essa praga, constante invasora das caixas postais do
usuário de Internet. A primeira providência é observar os cabeçalhos (headers)
da mensagem de correio eletrônico. A partir deles é possível determinar,
com precisão e de maneira quase imune a fraudes, de "onde" (isto é, de
que máquina) partiu o spam e, a partir daí, fazer a queixa ao provedor
responsável. Assim, neste breve tutorial, procurarei explicar-lhes como
interpretar as informações dos cabeçalhos e, de posse delas, a quem
fazer as reclamações pertinentes.
Interpretação do cabeçalho
Para tornar a explicação o mais próximo possível da realidade,
utilizaremos exemplos reais de cabeçalhos de spam. Todo programa de
correio eletrônico permite enxergá-los. Não pretendemos, por motivo de
espaço e por brevidade, expor detalhadamente como fazer isso, uma vez
que existem muitos e diferentes softwares de correio no mercado.
Recomendamos, nesse caso, uma consulta ao seu manual de instruções.
Comecemos pela análise do cabeçalho de um spam comum, desses tão
freqüentemente encontrados no dia-a-dia. O endereço de destino foi
editado para preservar a identidade do receptor da mensagem. As demais
partes mantêm-se verdadeiras. Observe:
Return-path: <innjkiigeinformacoes@mentiras.com>
Received: from mentiras.com
(1-114.mganm700-2.telepar.net.br [200.181.210.114])
by mail-server.xyz.com.br; Wed, 08 Oct 2003 12:22:42 -0300
From: "mentiras" <innjkiigeinformacoes@mentiras.com>
To: <xyz@xyz.com.br>
Subject: Detector de mentiras
Sender: "mentiras" <innjkiigeinformacoes@mentiras.com>
Mime-Version: 1.0
Content-Type: text/html; charset="ISO-8859-1"
Date: Wed, 8 Oct 2003 12:28:13 -0300
Content-Transfer-Encoding: 8bit |
Em todo cabeçalho de e-mail existem linhas que se originam do programa
de correio eletrônico (por sinal, a maior parte delas) e linhas que são
adicionadas pelos servidores de correio eletrônico que manuseiam sua
mensagem a cada passada pelo caminho. Aqui é interessante fazermos um
pequeno desvio para falar do processo de manipulação dos e-mails pelos
servidores na Internet.
Aparentemente, quando um internauta envia sua mensagem para o
destinatário, ela parece ir de uma caixa-postal a outra "magicamente".
Não é o que acontece. Cada e-mail passa por pelo menos um servidor de
correio eletrônico: o do provedor onde está a conta do receptor da
mensagem. Assim acontece nos casos em que o usuário envia a mensagem
diretamente a partir de seu micro pessoal para o servidor de correio do
destinatário ― técnica, por sinal, utilizada pelos spammers, como
veremos mais adiante.
Existem provedores que não permitem ao usuário o envio direto de
correio; as mensagens têm de passar primeiro para o servidor de correio
do provedor que se encarrega de contatar os outros servidores e de fazer
a mensagem. Fazendo uma comparação com um sistema de correio em papel,
no primeiro caso, o escritor da mensagem a entrega diretamente na caixa
postal do destino, e no outro caso entrega o envelope em uma agência dos
Correios, que se encarrega do envio da mensagem.
Para envio das mensagens, os clientes de correio e os servidores
utilizam-se de um método padronizado de comunicação, um protocolo,
chamado SMTP. Portanto, os servidores de correio eletrônico são também
chamados de servidores SMTP.
Assim, seu correio eletrônico passa, no mínimo, por um servidor SMTP,
aquele onde está a caixa postal eletrônica do destinatário. Se você
assina um provedor, pode ser que tenha de usar o servidor SMTP dele para
o envio da sua mensagem. E, se você estiver dentro de uma empresa, os
mecanismos de segurança utilizados podem exigir que você utilize um
servidor SMTP dentro da sua empresa, que por sua vez se comunique com
outro do seu provedor, e assim sucessivamente. Em outras palavras, sua
carta passa sempre por uma ou mais agências dos Correios.
Embora existam diferentes elementos dos cabeçalhos definidos pelas
normas que regulam o protocolo SMTP, deteremos nossa atenção
especificamente sobre o header "Received", que é acrescentado pelos
servidores SMTP a cada passo da sua mensagem. Esse header, inserido na
mensagem automaticamente em cada servidor pelo qual ela transita, é
muito difícil, senão impossível, de fraudar. Sempre haverá pelo menos um
header Received em qualquer mensagem de correio eletrônico.
O trecho dos cabeçalhos que nos será útil para a denúncia do spam é a
primeira diretiva Received colocada por algum servidor de correio do
nosso provedor, onde está a nossa caixa postal, pois contém o endereço
do último servidor que manuseou a mensagem antes de ela ser entregue
(este, aliás, geralmente identifica o provedor ou empresa da qual se
originou o spam).
Observando o exemplo anterior, lá encontramos:
Received: from mentiras.com
(1-114.mganm700-2.telepar.net.br [200.181.210.114])
by mail-server.xyz.com.br; Wed, 08 Oct 2003 12:22:42 -0300 |
Façamos, ponto a ponto, uma avaliação do "Received" dessa mensagem. De
um modo geral, a forma do cabeçalho é
Received: from <nome do computador de origem>
(nome verdadeiro do computador [endereço ip])
by <servidor de correio do destino> (versão do "software" de correio) with ESMTP id <número de identificação da mensagem> <data e hora> for <efetivo endereço do destinatário> |
O que significam essas informações? Todo computador, quando inicia uma conversação SMTP com outro,
apresenta-se e diz seu nome, verdadeiro ou fictício, usando a diretiva
smtp HELO (traduzindo literalmente, "hello", olá). No entanto, os
servidores SMTP de hoje, sabendo o endereço IP (isto é, número que
identifica a máquina na Internet), conseguem, quando é possível,
descobrir o verdadeiro nome da máquina. No exemplo, 1-114.mganm700-2.telepar.net.br.
Esse endereço IP é o que aparece logo depois do verdadeiro nome. Nem
sempre este é identificado; nesse caso, só aparece o endereço IP. Assim,
é preciso usar um recurso chamado Whois para identificar a quem pertence
esse endereço IP e portanto o destinatário da reclamação (mais a
respeito disso na próxima seção, "Como (e a quem) reclamar").
A seguir, o servidor de correio coloca o seu próprio (e verdadeiro)
nome; alguns inserem a versão do "software" de correio que está usando (Sendmail,
por exemplo, é um dos mais usados); em alguns casos coloca um número de
identificação da mensagem (a chamada ESMTP id) que é usado para seu
controle interno e seus "logs"; e a data e a hora de recepção da
mensagem. É preciso observar que a hora é a local do servidor receptor
da mensagem, que pode nem estar no Brasil, mas em um fuso horário
completamente diferente.
Em muitos cabeçalhos aparece também o endereço de correio eletrônico do
destinatário real da mensagem, depois da diretiva "for" (para). É a ele,
e nem sempre ao receptor cujo endereço aparece no cabeçalho "To:", que o
servidor SMTP entrega a mensagem. Em conseqüência disso não se pode
confiar no "To:" para se saber com certeza o destino da mensagem. Quando
não está presente essa diretiva "for", presume-se que o destinatário da
mensagem é a pessoa que a recebeu em sua caixa-postal.
Interpretando o cabeçalho do exemplo, a mensagem foi recebida de um
computador que se apresenta como mentiras.com, mas tem como seu
verdadeiro nome 1-114.mganm700-2.telepar.net.br e como endereço IP o
200.181.210.114.
Quando existem dois ou mais servidores envolvidos no processo de
entrega, os "headers" Received aparecem numa ordem lógica, ou seja, cada
servidor acrescenta um Received em cima do último encontrado na
mensagem. Vejamos este exemplo:
Received: from mailgate.immense-isp.com (mailgate.immense-isp.com [121.214.11.102]) by mailhost3.immense-isp.com (8.8.5/8.7.2) with ESMTP id LAA30141 for <tmh@immense-isp.com> Tue, 18 Mar 1997 14:41:08 -0800 (PST)
Received: from firewall.immense-isp.com (firewall.immense-isp.com [121.214.13.129]) by mailgate.immense-isp.com (8.8.5/8.7.2) with ESMTP id LAA20869 for <tmh@immense-isp.com> Tue, 18 Mar 1997 14:40:11 -0800 (PST)
Received: from firewall.bieberdorf.edu (firewall.bieberdorf.edu [124.211.4.13]) by firewall.immense-isp.com (8.8.3/8.7.1) with ESMTP id LAA28874 for <tmh@immense-isp.com> Tue, 18 Mar 1997 14:39:34 -0800 (PST)
Received: from mail.bieberdorf.edu (mail.bieberdorf.edu [124.211.3.78]) by firewall.bieberdorf.edu (8.8.5) with ESMTP id LAA61271; Tue, 18 Mar 1997 14:39:08 -0800 (PST)
Received: from alpha.bieberdorf.edu (alpha.bieberdorf.edu [124.211.3.11]) by mail.bieberdorf.edu (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (PST)
From: rth@bieberdorf.edu (R.T. Hood) |
A mensagem de correio em questão foi escrita localmente em um computador
chamado alpha.bieberdorf.edu (cujo endereço IP é 124.211.3.78) e depois
entregue a um servidor de correio funcionando na mesma rede (mail.bieberdorf.edu).
Como a rede da Universidade Bieberdorf possui um "firewall", ou seja, um
equipamento de proteção entre a sua rede e a Internet, seria preciso
atravessá-lo para prosseguir no envio da mensagem. Como pode ser isso?
Por meio de um servidor SMTP no próprio "firewall". O provedor do
usuário receptor da mensagem, chamado immense-isp.com, também utiliza um
desses computadores de segurança para se resguardar de ataques vindos da
Internet. Assim, este utiliza um servidor SMTP dentro do "firewall", que
recebe a mensagem e a encaminha para o servidor de correio interno da
empresa (mailgate.immense-isp.com), e este a deposita na conta do
usuário.
Observe a ordem dos "headers": descendente de data e de hora de chegada,
e na exata seqüência dos servidores que manipularam a mensagem. Daí
decorre a quase impossibilidade da fraude dos cabeçalhos Received. Outro
fato que denuncia uma tentativa de ocultar a origem da mensagem é a
presença de um header Received deslocado, ou seja, fora do conjunto dos
demais (quando existe mais de um, eles estão juntos).
Chamo a sua atenção, prezado leitor, para o exemplo a seguir:
Received: from unwilling.intermediary.com (unwilling.intermediary.com [98.134.11.32]) by mail.bieberdorf.edu (8.8.5) id 004B32 for <rth@bieberdorf.edu> Wed, Jul 30 1997 16:39:50 -0800 (PST)
Received: from turmeric.com ([104.128.23.115]) by unwilling.intermediary.com (8.6.5/8.5.8) with SMTP id LAA12741; Wed, Jul 30 1997 19:36:28 -0500 (EST)
From: Anonymous Spammer <junkmail@turmeric.com>
To: (recipient list suppressed)
Message-Id: <w45qxz23-34ls5@unwilling.intermediary.com>
X-Mailer: Massive Annoyance
Subject: WANT TO MAKE ALOT OF MONEY??? |
Em geral, nos cabeçalhos Received, observa-se que os servidores de
"e-mail" pertencem ao mesmo domínio (definindo em um sentido amplo, é a
designação pela qual se conhece, na Internet, uma determinada rede) da
conta de correio eletrônico do remetente e do destinatário. No entanto,
o exemplo mostra um terceiro servidor, que não faz parte da rede do
domínio de origem e nem do de destino.
Esse é mais um exemplo de servidor SMTP que permite "relay" aberto de
mensagens ("open-relay"). Servidores "open-relay" não verificam, como
deveriam, se (a) o destinatário da mensagem está dentro do domínio para
o qual prestam serviços, e/ou (b) o remetente da mensagem pertence a
esse domínio. Eles permitem o envio não-autorizado de correio eletrônico
para qualquer domínio. Embora as boas práticas de administração de
servidores de correio tendam a fazer diminuir o número de servidores "open-relay",
ainda existem muitos deles em operação, para alegria dos spammers, que
os utlizam na tentativa de mascarar a efetiva origem do lixo eletrônico.
Examinemos, para concluir, este exemplo de cabeçalho:
Received: from mail.bieberdorf.edu (mail.bieberdorf.edu [124.211.3.78]) by mailhost.immense-isp.com (8.8.5/8.7.2) with ESMTP id LAA20869 for ; Tue, 18 Mar 1997 14:39:24 -0800 (PST)
Received: from alpha.bieberdorf.edu (alpha.bieberdorf.edu [10.11.3.11]) by mail.bieberdorf.edu (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (PST) |
Aqui observamos, no primeiro Received, que o endereço IP da máquina
alpha.bieberdorf.edu é 10.11.3.11. Pode acontecer que a rede da
Universidade Bieberdorf utilize endereços especiais, ditos reservados,
que só podem ser usados na estrutura interna, como os iniciados por 10.
As seguintes faixas de IPs são reservadas e os "headers" que possuem IPs
dessas faixas podem ser desconsiderados: 10.0.0.0 - 10.255.255.255;
172.16.0.0 - 172.31.255.255; e 192.168.0.0 - 192.168.255.255. Assim,
considere na análise o próximo cabeçalho Received que contiver um IP
válido (não contido nas classes anteriores).
Pode acontecer também, mas é bastante raro em caso de spam, que a
mensagem contenha um header Received indicando como origem da mensagem
um equipamento chamado localhost (ou localhost.localdomain) e endereço
IP 127.0.0.1. Esse fato é mais freqüente em sistemas de webmail, onde um
programa capta a mensagem digitada pelo usuário e a entrega a um
servidor SMTP no próprio computador onde o webmail roda (em outras
palavras, na prática a mensagem apenas "mudou de mãos", mas não de
computador!). A seguir, o servidor SMTP em tal máquina entrega a
mensagem ele próprio ao sistema de SMTP de destino ou a outro
equipamento preparado para essa tarefa. Também não é necessário
considerar esses Received na análise.
Finalmente, quando um único header Received é encontrado na mensagem ―
lá colocado pelo provedor que hospeda a caixa-postal de destino do
correio ― o spammer não utilizou o servidor SMTP do provedor em que se
conecta, e nem mesmo um "open-relay" para isso, mas enviou-o diretamente
de sua máquina conectada na Internet. Para isso, o spammer instala em
seu próprio micro um mini-servidor SMTP, cuja função é fazer a entrega
direta do spam. Essa prática generalizou-se a partir da disponibilidade,
no Brasil, de serviços de conexão à Internet pela chamada banda larga
(por meio de ADSL, como Speedy, através de cabo, como Virtua e Net, e
por meio de telefonia sem fio, como o Giro da Vésper). Aqui um exemplo
de cabeçalho típico dessa prática:
Received: from 200-158-152-45.dsl.telesp.net.br ([200.158.152.45] helo=HOTMAIL.COM.BR) by mx.xxx.com.br with smtp (Exim 4.22) id 1A7yqZ-000882-2y for xxx@xxx.com.br; Fri, 10 Oct 2003 12:06:27 -0300 |
Marlon Borba é diretor de suporte técnico do TRF da 3a. Região.
Autodidata, trabalha desde 1996 com administração de redes locais,
segurança da informação e Internet.
FONTE:
http://www.infoguerra.com.br/infonews/viewnews.cgi?newsid1067911200,2079,