Tenho ataques contínuos contra meu servidor exim. Estou tentando atrasar as tentativas com a seguinte acl
deny condition = ${if and {\
{>{$rcpt_count}{10}}\
{<{$recipients_count}{${eval:$rcpt_count/2}}} }}
delay = 5s
message = Rejected for too many bad recipients
logwrite = REJECT [$sender_host_address]: bad recipient count high [${eval:$rcpt_count-$recipients_count}]
.endif
Isso atrasa uma vez após as primeiras 10 tentativas.
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:39 REJECT [212.164.218.15]: bad recipient count high [11]
2023-09-10 12:14:39 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Rejected for too many bad recipients
2023-09-10 12:14:39 REJECT [212.164.218.15]: bad recipient count high [12]
2023-09-10 12:14:39 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Rejected for too many bad recipients
Quero que isso atrase cada tentativa subsequente. Como posso conseguir isso?
Responder1
Encontrei o mesmo problema/pergunta e fiz algumas pesquisas e testes.
A primeira coisa que você precisa saber é que o SMTP era originalmente baseado estritamente em resposta de comando, o que significa que o cliente pode enviar exatamente um comando ao servidor e tem que esperar pela resposta antes de enviar o próximo. Como esse vaivém envolve sempre um pouco de espera e, portanto, cria latência,RFC 2920mais tarde introduziu o "Pipelining SMTP". Isso permite que um cliente envie vários comandos em um lote ao servidor, que os processa e envia de volta as respostas. No exim a disponibilidade do “SMTP Pipelining” pode ser controlada pela pipelining_advertise_hostsopção, que por padrão permite isso para todos. Presumo que este também seja o caso da sua configuração.
O que eu acho que aconteceu no seu caso é que o cliente (também conhecido como spammer) conectado ao seu servidor exim foi informado de que ele suporta "Pipelining SMTP" e, portanto, enviou um lote de 100 RCPT TO:comandos. Seu servidor os recebeu e começou a processá-los, executando a acl_smtp_rcptACL para cada destinatário. Os primeiros 10 comandos retornaram uma 550 Unrouteable addressresposta cada, 550sendo umCódigo de erro RFC5321significado Requested action not takenseguido por uma razão legível por humanos. Esse motivo pode ser definido no exim com a messagediretiva e também é impresso no log após os dois pontos. O cliente provavelmente simplesmente os ignorou; afinal, ele está procurando destinatários válidos.
Ao processar o 11º comando/destinatário, a condição da sua denyregra é avaliada como verdadeira e o exim atrasa (hiberna) por 5 segundos; este é o único atraso que você vê. Depois disso ele envia a 550 Rejected for too many bad recipientsresposta ao cliente. Pelo motivo incluído (bem conhecido), o cliente detecta que ultrapassou os limites e não há mais chance de encontrar um destinatário válido; todos os comandos a seguir também serão rejeitados. Como não há mais nada que valha a pena esperar/ganhar, ele encerra a conexão sem esperar pelo restante das respostas (e provavelmente se volta imediatamente para sua próxima vítima). Embora seu servidor perceba isso (porque o TCP é usado), ele ainda continua processando o lote de comandos. Mas como a conexão SMTP com o cliente já foi encerrada, não faz mais sentido atrasar; o único que atrasaria seria ele mesmo. Portanto, o atraso é ignorado e seu servidor executa os comandos até que todo o lote seja concluído.
Se o cliente não encerrasse a conexão, isso funcionaria como você esperava: O atraso de 5s seria aplicado a cada destinatário após o dia 10.
Supondo que o que foi dito acima esteja correto, a melhor solução que posso encontrar é remover o motivo/mensagem padrão. Se o servidor simplesmente continuar respondendo com algo como 550 Unrouteable address, o cliente não terá como saber que ultrapassou os limites e não poderá desistir. Dependendo de como o cliente funciona, pode ser suficiente alterá-lo/reformulá-lo para algo diferente do padrão para que não seja tratado de maneira especial.
Alternativamente, você pode desabilitar o "Pipelining SMTP" em seu servidor usando a opção mencionada acima. O cliente provavelmente ainda abortará depois de ver a 11ª resposta com o motivo revelador, e seu servidor ainda atrasará apenas uma vez, mas pelo menos você não receberá os outros 89 destinatários com falha em seu log. A desvantagem óbvia é que você "desacelera" todos os clientes, mas isso pode ser um pouco elevado ativando o "Pipelining SMTP" apenas para clientes "conhecidos como bons" selecionados.
E apenas como observação: o atraso não precisa ser um valor estático, também pode ser uma expressão. Isto torna possível implementar atrasos progressivos, onde cada destinatário inválido adicional o tornará mais longo. O excelenteFiltragem de spam para trocadores de e-mailHowTo tem um exemplo disso.