Introdução
Spammers estão sempre e ativamente buscando um meio de acessar as instalações de servidores SMTP, a fim de conseguir realizar o envio de spam. Uma das formas mais comuns é através do abuso de POP before SMTP e IPs fixos liberados em Security/Trusted IPs (Segurança/IPs Confiáveis).
Tais ataques são prejudicias, pois além de realizar o envio de spams para usuários inocentes, gasta processamento do seu servidor e pode fazer com que entre em listas negras DNSBL, sendo necessário posteriormente solicitar remoção das mesmas.
Como se previnir
- Não deixe de ler nosso FAQ
sobre relay e seguir as recomendações de desabilitar POP antes de SMTP e manter apenas IPs de servidores nos IPs confiáveis.
- Não deixe de ler nosso FAQ sobre como ler logs, em: https://suporte.icewarp.com.br/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=415
Será importante para entender o processo de envio de e-mail.
Tal leitura também ajudará a entender a
respeito de sessões de entrada/saída e conseguir analisar se seu
problema está na entrada (/temp) ou saída (/mail/_outgoing), o que você pode ser visto no console, em Status/Estatísticas, onde pode ser observado pico de conexões Server e Client. No caso de abuso de spam pode ocorrer do problema afetar imensamente a entrada e
saída, mas sobretudo a saída. No
caso de problemas de performance, o problema costuma ocorrer na entrada.
- Verifique no seu IceWarp se existe o domínio icewarpdemo.com ou simular (este era criado por padrão em versões mais antigas) com exemplos de contas demo para simples demonstração que possuíam senhas fáceis. Se você não precisar destas contas de demonstração, simplesmente apague-as. Caso você precise destas contas, altere as suas senhas.
Como reagir a ataques de spam (abuso SMTP)
Se você sofreu ataque de mensagens spam, você provavelmente terá uma
quantidade significativa de mensagens na pasta de ítens a serem
enviados. Renomeie a pasta da sua fila de saída no local
/icewarp/mail/_outgoing/. O IceWarp irá criar uma nova - e a fila de
mensagens a serem encaminhadas será limpa, ficando mais fácil identificar novos spams enviados pelo seu servidor, podendo até visualizar as sessões SMTP em tempo real, em Status/Sessões/SMTP.
Verifique o arquivo o log do SMTP (icewarp/logs/s-data.log ou pelo console em Status/Logs/SMTP - caso verifique pelo console, especifique horário de início e fim, para evitar carregar todo log de uma vez no console). O objetivo é localizar qualquer mensagem spam, que tenha sido enviada para fora através do seu servidor, na qual tenha ocorrido autenticação SMTP (SMTP AUTH).
Se você sofreu um ataque de spam, o seu arquivo log provavelmente será bem grande. Renomeie esse arquivo - NÃO ABRA. Espere alguns minutos - um novo arquivo log será criado pelo IceWarp - bem menor, mas os spammers estarão nele.
Você pode verificar mensagens na sua fila de saída (Status/Logs/Fila de saída). Dê um duplo clique para abrir determinda mensagem de spam identificada na sua fila de saída. Veja o "Message ID" contido no topo do header das mensagens, o que pode ser um bom parâmetro para buscar nos logs, além do remetente/IP.
A parte do arquivo log do SMTP do seu interesse é a primeira etapa, quando o usuário consegue autenticar com sucesso, para em seguida ocorrer o envio do e-mail para fora (relay/Client session).
218.27.89.158 [0000036C] Fri, 14 Mar 2003 14:00:36 +0100 <<< AUTH LOGIN
218.27.89.158 [0000036C] Fri, 14 Mar 2003 14:00:36 +0100 >>> 334 VXNlcm5hbWU6
218.27.89.158 [0000036C] Fri, 14 Mar 2003 14:00:47 +0100 <<< YWRtaW4=
218.27.89.158 [0000036C] Fri, 14 Mar 2003 14:00:47 +0100 >>> 334 UGFzc3dvcmQ6
218.27.89.158 [0000036C] Fri, 14 Mar 2003 14:00:52 +0100 <<< YWRtaW4=
Você precisa encontrar - nome de usuário e senha que foram usados para o spamming.
Use a ferramenta abaixo para Codificação e Decodificação de Base 64:
http://www.opinionatedgeek.com/dotnet/tools/Base64Decode/
Copie e cole o trecho YWRtaW4= e selecione DECODE. Você verá que o usuário que autenticou é o "admin".
Dessa forma, você poderá encontrar o nome de usuário e senha do spammer e eliminá-los.
Outra opção de site para verificação, que tem se mostrado eficiente em revelar o username mesmo em caso de autenticação criptografada (MD5) é: http://tools.web-max.ca/encode_decode.php.
Altere a senha da conta afetada.
OBS: Já vimos casos em que o administrador configurou máquinas clientes
de uma rede local para usarem o mesmo IP de saída que o servidor de
mail em seu firewall, causando problemas devido a vírus que enviam
emails diretamente através da porta 25 e dificultando a análise, por
não se ter nada nesse caso nos logs do Merak. Portanto, sugerimos
também verificar esse aspecto.
Dicas importantes
- Considere usar a opção "Rejeitar se SMTP AUTH diferente do remetente", em Serviço de Correio/Segurança/Avançado. Pode até evitar spams de ocorrerem com contas que possuem senhas fáceis, já que muitas vezes spammers/vírus autenticam com uma conta e senha válidas, porém usam outro remetente (MAIL FROM) qualquer.
- Considere usar política de senha (em Global Settings/Configurações Globais), a fim de evitar ataques de spam através de autenticação SMTP AUTH com senhas fáceis. FAQ a respeito de política de senha em https://suporte.icewarp.com.br/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=368
- Use limites por dia em todas as contas. Por exemplo: toda conta pode enviar, no máximo, 300 e-mails por dia. Mesmo no caso de um abuso, o estrago não serião tao grande. FAQ sobre limites: https://suporte.icewarp.com.br/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=210