|
Sumário
1. Introdução
Servidores Web podem ser abusados para enviar spam dependendo dos
serviços disponíveis, portanto o administrador de sites também
é responsável pela prevenção. As fontes de abuso mais comuns são o
envio de mensagens através de formulários e funções de linguagens de
geração de conteúdo dinâmico capazes de enviar e-mail.
Spam vindo de servidores Web são particularmente difíceis de combater,
porque eles vem de MTAs legítimos, com fila e retransmissão, e com
envelopes consistentes com o endereço IP, passando assim tanto por
graylisting quanto por teste de SPF. Por conta disso a ação
preventiva nestes casos é fundamental.
2. Mensagens enviadas por formulários
O caso mais conhecido de abuso de envio de mensagens por formulários é
o do script CGI FormMail.pl, que envia o e-mail
utilizando-se de informações vindas do formulário e que pode ser
abusado para prover anonimato para um spammer.
Existem mecanismos automáticos de busca por formulários vulneráveis
que, ao localizar páginas contendo formulários, analisam seus campos e
submetem diretamente ao script CGI um e-mail para um
endereço de teste. Se o CGI for vulnerável o endereço de teste
receberá uma mensagem. Vale ressaltar que o spammer não
precisa invadir o site, basta acessar diretamente a URL do CGI,
com argumentos especialmente construídos.
Qualquer programa que envie e-mail a partir de um formulário,
independente da linguagem em que é escrito, não deve receber o
endereço de destino do próprio formulário, mas sim tê-lo como uma
constante interna, inacessível ao usuário. Além disso, vale a regra de
que qualquer programa deve validar todos os campos submetidos pelo
usuário e tratá-los como potencialmente hostis.
Ao escrever esse tipo de script é fundamental tomar cuidado para que o
conteúdo da mensagem, vindo do formulário, não injete linhas de
cabeçalho no e-mail a ser enviado. Para evitar isso é
aconselhável, após a construção do cabeçalho, que o script
insira uma linha em branco contendo o par CRLF, e só então
inclua o conteúdo da mensagem que veio do formulário.
Este cuidado deve ser redobrado em servidores de hospedagem de
sites, onde o usuário pode, inadvertidamente ou não, utilizar
um script vulnerável à exploração por spammers. Há
relatos de spammers que contratam um serviço de hospedagem
somente para ter uma plataforma para envio de spams.
É necessário que esses serviços possuam uma política bem definida em
contrato sobre o envio de e-mails a partir do site
hospedado. Também é interessante prever a possibilidade de auditorias
com a intenção de localizar scripts vulneráveis, incluindo a
análise de logs do MTA e do servidor Web.
3. Mensagens enviadas por linguagens de conteúdo dinâmico
A maior parte das linguagens de geração de conteúdo dinâmico possuem
algum método para envio de e-mails. Estes métodos podem ser
utilizados para envio de formulários e geração de alertas, entre
outras funcionalidades. E, a exemplo dos scripts CGI, também
podem ser abusados para o envio de spam. Um exemplo é a função
mail() da linguagem PHP, disponível na grande maioria dos
servidores que suportam essa linguagem.
Funções como essa podem ser abusadas de duas maneiras: ou o
spammer contrata o serviço de hospedagem de sites e
então disponibiliza seus programas ou ele compromete algum site
e utiliza seu programa neste site.
Para evitar o abuso por parte clientes de serviços de hospedagem,
aconselha-se possuir uma política de uso aceitável ou prever os termos
de uso de serviços de e-mail em contrato, além de possuir
informações cadastrais completas sobre o cliente, permitindo a
identificação de possíveis spammers reincidentes.
Também é possível mitigar este problema com as seguintes providências:
- filtrar as mensagens vindas do servidor Web: normalmente o
servidor Web chamará um MSA para fazer o serviço de envio da
mensagem. No caso de uso de Sendmail e PHP, por exemplo, é
possível configurar o sistema para que envie a mensagem
primeiro para um filtro, ao invés de ir diretamente para o
Sendmail. Deve ser configurada a variável
sendmail_path do PHP, que apontará a mensagem para o
filtro, este verificará se a mensagem obedece a uma política
pré estabelecida e só repassará para o Sendmail aquelas
mensagens que forem aprovadas. Este esquema, porém, pode ser
driblado pelo acionamento direto do Sendmail real via
popen() ou system();
- analisar bounces: muitos spams são enviados para listas
de e-mails que contém endereços que não existem, gerando
muitos bounces. A análise de bounces causados
pelo servidor Web pode identificar o abuso por parte de um
spammer;
- possuir um usuário para cada site hospedado: nem sempre
isto é de fácil implementação, mas facilita a análise de
logs do MTA e dos bounces recebidos;
- descredenciar o servidor Web junto ao MTA: não dar permissão
para que o servidor Web utilize o MTA como relay, mesmo
que seja o localhost. Deste modo, para poder enviar
mensagens para domínios externos ele deverá se autenticar.
Essa providência, entretando, pode impedir o funcionamento de
programas legítimos e, também, permitir o envio de spam para
domínios locais.
Do ponto de vista de quem recebe spam vindo de servidores Web há
algumas características peculiares, mas que não devem ser usadas como
único critério de bloqueio, pois podem gerar muitos falsos positivos:
- o MAIL FROM do envelope (conseqüentemente o campo
Return-Path: do cabeçalho) apresenta um nome de usuário
normalmente associado ao servidor Web, tal como
nobody, wwwrun, apache, etc;
- há dois campos Received: no cabeçalho, um colocado
pelo MTA de destino e outro pelo de origem, ao receber a
mensagem do servidor Web. Este último normalmente mostra o
endereço 127.0.0.1 como origem.
Ao receber um spam suspeito de ter sido gerado por um servidor Web é
aconselhável contatar o responsável pelo servidor Web, normalmente
acessível pelo endereço webmaster@domínio (de acordo com a RFC 2142 esse endereço
deve existir). Caso esteja sendo recebido um volume muito grande de
spams, pode-se considerar a inclusão das informações de envelope em
uma lista de bloqueio.
|
|