Eu estava nos registros de e-mail ontem quando notei as seguintes mensagens, mas havia mais de 10.000 ocorrências estranhas:
Jun 21 10:47:10 exi-svr-2 dovecot: pop3-login: Disconnected: user=<tori>, method=PLAIN, rip=67.228.94.206, lip=xxx.xxx.xxx.xxx
Jun 21 10:47:10 exi-svr-2 dovecot: pop3-login: Disconnected: user=<last>, method=PLAIN, rip=67.228.94.206, lip=xxx.xxx.xxx.xxx
Eu adicionei o 67.228.94.206 ao meu firewall da mesma forma
iptables -I RH-Firewall-1-INPUT -s 67.228.94.206 -j DROP
tabelas de serviço ip salvar
O ataque parou imediatamente, mas no processo conseguiu obter uma conta de usuário e começou a falsificar com ela. Excluí essa conta de usuário, mas parece que ela ainda está sendo falsificada, pois estou sendo inundada com e-mails de devolução de vários servidores de e-mail:
Jun 22 15:08:08 exi-svr-2 postfix/smtp[27219]: connect to vahoo.com[216.151.212.175]: Connection refused (port 25)
Jun 22 15:08:07 exi-svr-2 postfix/smtp[27158]: connect to mail.gamdak.co.za[196.215.56.13]: Connection refused (port 25)
Jun 22 15:08:07 exi-svr-2 postfix/smtp[27169]: A72A61068460: to=<[email protected]>, relay=none, delay=33839, delays=33839/0.13/0.51/0, dsn=4.4.1, status=deferred (connect to keywordranking.com[208.87.35.105]: Connection refused)
Jun 22 15:08:07 exi-svr-2 postfix/smtp[27169]: connect to keywordranking.com[208.87.35.105]: Connection refused (port 25)
Jun 22 15:08:07 exi-svr-2 postfix/smtp[27179]: 40A9C1068515: to=<[email protected]>, relay=none, delay=32038, delays=32038/0.22/0.19/0, dsn=4.4.1, status=deferred (connect to graintech-makeway.com[50.116.103.74]: Connection refused)
Não tenho certeza de como consertar isso e as medidas preventivas que preciso tomar para impedir que isso aconteça daqui para frente. Eu li em outro lugar que esse tipo de coisa é inevitável e pode muito bem ser ignorado por não capturar essas mensagens no log. Eu não estou totalmente confortável com essa solução.
Estou executando o CentOS 5.6 com o Postfix, o Dovecot, o AMaViS, o SpamAssassin e o ClamAV.
Se os e-mails forem enviados pelo usuário, os servidores externos poderão enviar os erros. Eles vão parar assim que perceberem que o usuário não está disponível.
Verifique sua fila postfix para ver se não há mensagens esperando para serem enviadas (pelo comando mailq )