Ataque do servidor de email do telnet

Question

Meu servidor de e-mail está tendo um problema em bloquear algum invasor que tente telnetar para o nosso servidor de e-mail. mas eu não consigo bloqueá-lo, o ip vai continuar mudando mesmo que bloqueamos pelo ip. Parece que ele está tentando telnet em vez de normal da transação smtp. Eles não podem entrar no nosso servidor de e-mail, mas isso é uma transação a cada segundo. existe alguma maneira de bloqueá-lo / pará-lo? abaixo estão a mensagem de erro:

81.198.214.48   [0968] 16:14:01 Connected, local IP=xx.xx.xx.xx:25
81.198.214.48   [0968] 16:14:01 >>> 220 mymailserver.com ESMTP IceWarp 11.0.1.2; Fri, 13 Feb 2015 16:14:01 +0800
81.198.214.48   [0968] 16:14:02 <<< EHLO ylmf-pc
81.198.214.48   [0968] 16:14:02 >>> 250-mymailserver.com Hello ylmf-pc [81.198.214.48], pleased to meet you.
81.198.214.48   [0968] 16:14:03 <<< AUTH LOGIN
81.198.214.48   [0968] 16:14:03 >>> 334 VXNlcx5hbWU6
81.198.214.48   [0968] 16:14:04 <<< aGFua3M=
81.198.214.48   [0968] 16:14:04 >>> 334 UGFzcxdvcmQ6
81.198.214.48   [0968] 16:14:04 <<< ODg4ODg4
81.198.214.48   [0968] 16:14:24 >>> 535 5.7.8 Authentication credentials invalid
81.198.214.48   [0968] 16:14:24 *** <> <> 0 0 00:00:00 INCOMPLETE-SESSION 
81.198.214.48   [0968] 16:14:24 Disconnected

    

Answer 1

Esse argumento EHLO idiossincrático e inválido "ylmf-pc" é uma impressão digital conhecida de um botnet de spam generalizado conhecido como "PushDo" (e, às vezes, alternativamente, "Cutwail"). Como mostrado na sua transcrição, é principalmente tentar adivinhar a senha para autenticar e enviar e-mails através do seu servidor. Evitar o envio de spam para ou através do seu servidor é fácil, devido a três características:

1. Na verdade, ele envia o comando EHLO antes de receber o SMTP banner enviado pelo MTA de destino, um comportamento que qualquer valor MTA moderno usar (ou seja, talvez não o Exchange ou QMail) pode detectar como um definitivo indicação de um cliente indesejável de spam puro. Nenhum cliente SMTP legítimo exibe um comportamento de "fala rápida", pois quebra a funcionalidade básica do SMTP.

2. A string "ylmf-pc" não é um argumento EHLO válido, porque não é um nome de host totalmente qualificado ou literal de endereço IP entre colchetes. Nenhum cliente SMTP legítimo utilizará esse argumento. Como com o comportamento de conversa rápida, qualquer MTA decente pode ser configurado para rejeitar o correio de clientes usando um argumento EHLO inerentemente inválido.

3. Quase todos os membros infectados do PushDo / Cutwail estão listados gratuitamente zen.spamhaus.org DNSBL, através do seu componente "CBL". Mesmo se você não pode bloquear para falar rápido ou usar um argumento EHLO falso, você deve ser capaz de bloquear com base em um DNSBL e fazê-lo com o Zen lista é quase universalmente uma boa escolha.

Prevenir que o seu MTA aceite qualquer spam sendo oferecido deve ser relativamente fácil com um MTA bem configurado, mas exatamente como fazer isso com o MTA "IceWarp" que você parece estar usando é uma pergunta bem feita ao fornecedor. É mais difícil lidar com o volume puro de tráfego que pode estar envolvido, já que um único zumbi do PushDo pode tentar abrir muitas centenas de sessões simultâneas e voltar várias vezes em um dia, enquanto pode haver dezenas de zumbis tentando ativamente atacar um servidor em um determinado dia. Opções para mitigar que podem vir do MTA; por exemplo, versões recentes do Postfix podem ser configuradas para simplesmente derrubar clientes de velozes clientes unilateralmente (usando sua facilidade 'postscreen') em vez de tocar junto com eles através de toda a conversa SMTP educadamente, e o Sendmail pode ser configurado da mesma forma. Para reduzir ainda mais o problema, você pode usar uma ferramenta de verificação de log como o fail2ban (descrito em uma resposta anterior) para bloquear o tráfego dos IPs específicos. Se você escolher essa opção, observe que as infecções do PushDo tendem a durar vários dias de uma vez, portanto, você não deve expirar os bloqueios mais do que uma semana.

    

Answer 2

O nome do helo do atacante é inválido ( ylmf-pc ) porque não é um FQDN, nem pode ser resolvido via DNS, então você pode se livrar dele mais cedo, bloqueando-o depois que o EHLO inválido for enviado.

Para fazer isso com o postfix, por exemplo, faça:

smtpd_helo_restrictions = permit_mynetworks, check_helo_access reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_unknown_helo_hostname, permit

Mas leia também os documentos sobre smtpd_helo_restrictions

Depois, você pode usar o fail2ban para bloqueá-lo depois que algumas dessas consultas inválidas chegarem. Já existe um exemplo de postfix incluído no fail2ban, mas não sei se ele também inclui regras para os erros do HELO. Você pode adicioná-los, se necessário.

jail.conf :

[postfix-ddos]

enabled  = true
port     = smtp,ssmtp
filter   = postfix-helo
logpath  = /var/log/mail.log
maxretry = 5

filter.d/postfix-helo :

[INCLUDES]
before = common.conf

[Definition]
failregex = reject: RCPT from (.*)\[<HOST>\]: 504 5.5.2

ignoreregex =

Isso é totalmente suficiente para bloquear as crianças. Você pode desativar a configuração maxretry no fail2ban para bloquear o ataque instantaneamente, embora eu não recomende isso.

    

Answer 3

Um dos outros problemas com os ataques do CutWail é que, embora seja fácil parar na porta 25, como normalmente é o tráfego MTA - > MTA, fica mais difícil abordar a porta 587, onde os clientes legítimos podem estar tentando conectar. Embora os IPs possam estar em muitas RBLs, como SpamHaus e SpamRats, porque os clientes usam IPs dinâmicos para se conectar, conexões compartilhadas, etc, apenas porque o IP está listado, não significa que a conexão seja ruim. No entanto, para ser eficaz, os ataques de força bruta normalmente precisam de muitas conexões, e você pode minimizar isso limitando as tentativas sucessivas, especialmente se o banner (HELO / EHLO) for 'ylmf-pc', mas você deve estar ciente de que ferramenta que você usa para fazer isso, verifique se o bloco é temporário. E enquanto o botnet em breve escolherá um HELO diferente, nesse meio tempo o bloqueio de todas as tentativas que apresentam que o EHLO na porta 587 é provavelmente o melhor.