Ataque de botnet

Vou postar um problema que tive em um servidor de e-mail que administro. Além do problema vou relatar a solução que apliquei para resolver o problema, com isso achei interessante publicar. Tenho o seguinte ambiente, servidor mta postfix, firewall Microsoft ISA Server.

Os e-mail vem a partir da internet atravessam o firewall e são entregues ao mta. O mta não tem endereço válido, portanto temos um nat estático. Monitorando o uso do mta durante períodos do dia e noite, o volume de tráfego era muito intensivo e a fila de e-mail chegava a ter 30mil e-mails. Um valor muito alto para o volume normal de e-mail.

A partir daí começou minha jornada para resolver problema, aumentei o nível de checagens na chegada dos e-mails. Apliquei as seguintes restrições:

# O numero maximo de tentativas de conexoes de qualquer clientes sao permitidas.
smtpd_client_connection_rate_limit = 15
# Como várias conexoes simultaneas de qualquer cliente e permitida
smtpd_client_connection_count_limit = 15
# O numero maximo de pedidos para entrega de mensagens de qualquer cliente é permitido
smtpd_client_message_rate_limit = 15
# O numero maximo de enderecos de destino que qualquer cliente pode enviar.
smtpd_client_recipient_rate_limit = 15

Tentei uma series de combinações de restrições via os “smtpd_X_restrictions” do postfix, mas sem sucesso, li e reli vários históricos de listas de discussões, li a documentação do postfix mas nada adiantou, até que resolvi monitorar a conexão com um sniffer(wireshark), e finalmente resolvi o problema. Segue abaixo os procedimentos e passos que segui para resolver o problema.

Diário de bordo.

Percebi um ataque vindo do ip 69.3.86.74, o spammers spoofava o from com o email “login@rbc.com” e enviava e-mails para vários destinos, dava para perceber que a lista de e-mails era gigante. Então comecei a monitorar pelo ip do spammer via sniffer e via logs do postfix.

# tshark -V host 69.3.86.74 > wireshark.log
# tail -f /var/log/mail.log | ack-grep –passthru “login@rbc.com”

Após monitorar analisando os logs notei o seguinte trechos do arquivo wireshark.log truncando alguns itens.

Logo depois do three-hanshake vemos a seguinte conexão:

Internet Protocol, Src: 192.168.0.2 (192.168.0.2), Dst: 200.193.244.45 (69.3.86.74)
Version: 4

O MTA é 192.168.0.2 respondendo ao spammer(69.3.86.74)

Agora o payload smtp

Response: 220 mail.dominio.com.br ESMTP Postfix\r\n
Response code: 220
Response parameter: mail.dominio.com.br ESMTP Postfix

Agora o EHLO

Simple Mail Transfer Protocol
Command: EHLO [xxx.xxx.xxx.xxx]\r\n
Command: EHLO
Request parameter: [xxx.xxx.xxx.xxx]

Agora vemos o pedido de autenticação

Simple Mail Transfer Protocol
Response: 250-mail.dominio.com.br\r\n
Response code: 250
Response parameter: mail.dominio.com.br
Response: 250-PIPELINING\r\n
Response code: 250
Response parameter: PIPELINING
Response: 250-SIZE 51200000\r\n
Response code: 250
Response parameter: SIZE 51200000
Response: 250-VRFY\r\n
Response code: 250
Response parameter: VRFY
Response: 250-ETRN\r\n
Response code: 250
Response parameter: ETRN
Response: 250-STARTTLS\r\n
Response code: 250
Response parameter: STARTTLS
Response: 250-AUTH PLAIN LOGIN\r\n
Response code: 250
Response parameter: AUTH PLAIN LOGIN
Response: 250-AUTH=PLAIN LOGIN\r\n
Response code: 250
Response parameter: AUTH=PLAIN LOGIN
Response: 250-ENHANCEDSTATUSCODES\r\n
Response code: 250
Response parameter: ENHANCEDSTATUSCODES
Response: 250 8BITMIME\r\n
Response code: 250
Response parameter: 8BITMIME

Vemos o envio de usuário e senha por parte do spammer.

Simple Mail Transfer Protocol
Command: AUTH PLAIN AHJpY2FyZG8AUEBzc3cwcmQ=\r\n
Command: AUTH
Request parameter: PLAIN AHJpY2FyZG8AUEBzc3cwcmQ=

E olhe a resposta do postfix (MTA), para o spammer.

Simple Mail Transfer Protocol
Response: 235 2.7.0 Authentication successful\r\n
Response code: 235
Response parameter: 2.7.0 Authentication successful

Verificando os logs do postfix(mail.log) verifiquei o usuário em questão.

Dec 18 14:46:20 mail postfix/smtpd[742]: 030CC681FD: client=unknown[69.3.86.74], sasl_method=PLAIN, sasl_username=maria

Após isso e com o postfix utilizando SASL fiz o seguinte teste com o utilitário testsaslauthd.

root@mail:~# testsaslauthd -u maria -p 123456
0: NO “authentication failed
root@mail:~# testsaslauthd -u maria -p 123
0: OK “Success.”
root@mail:~#

Duas tentativas que fiz descobri a senha frágil da “maria”, entrei em contato com o cliente e pedi que alterasse sua senha e os volume de 3 mil e-mails pararam.

Postei esse troubleshooting como prova de que senhas dificeis sao utéis, e uma politica de senha na empresa é essencial, é e sempre será de suma importância no ambiente corporativo. Portanto sysadmins, vamos cobrar politica de senhas para por fim aos spammers 😀

Até a próxima

Advertisements
  1. Cleberson
    December 19, 2009 at 10:19 pm

    Kakaroto, parabéns pelo Blog e principalmente pelo seu primeiro Post. Gostei muito da matéria.
    Já coloquei nos meus favoritos.

  2. Francisco Neto
    December 21, 2009 at 7:04 pm

    Iaew Ricardo!
    Cara meus parabéns pelo Post, é uma ótima lição!
    Seu blog já está nos meus Favoritos.
    Abraços.

  3. December 30, 2009 at 2:09 pm

    Show de bola !!!

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: