Eu tenho um relé postfix 3.5 funcionando onde a configuração inclui:
smtpd_client_restrictions = permit_mynetworks,
reject_unknown_client_hostname,
permit
smtpd_helo_required=yes
smtpd_helo_restrictions = reject_unknown_helo_hostname
reject_invalid_helo_hostname
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_unauth_destination
Vejo tentativas frequentes de autenticação nos logs:
23 de fevereiro 16:53:02 m.example.com postfix/smtpd[30155]: conexão de desconhecido[196.190.41.137]
23 de fevereiro 16:53:17 m.example.com postfix/smtpd[30155]: aviso: desconhecido[ 196.190.41.137]: Falha na autenticação SASL LOGIN: falha de autenticação
23 de fevereiro 16:53:19 m.example.com postfix/smtpd[30155]: conexão perdida após AUTH de desconhecido[196.190.41.137]
23 de fevereiro 16:53:19 m .example.com postfix/smtpd[30155]: desconectar de desconhecido[196.190.41.137] ehlo=2 starttls=1 auth=0/1 comandos=3/4
Eu esperava que isso reject_unknown_helo_hostname
rejeitasse isso imediatamente, mas parece permitir que eles tentem o login SASL. Embora eu ache que meu saslauth é bastante seguro, eu preferiria que eles nem tentassem.
Não há como fazer com que o nome do host "desconhecido" seja rejeitado anteriormente? Isso evitaria 90% das tentativas de login, já que a maior parte desse botnet que continua tentando os mesmos logins tem nomes de host desconhecidos.
Existe algo na minha configuração que é muito permissivo para que eles sempre possam chegar à etapa saslauth?
Em que ordem são aplicadas as diversas restrições de acesso SMTP?
Editar: Wireshark mostra que uma dessas falhas recentes de autenticação de login SASL enviou isto para iniciar a sessão:
EHLO [182.150.23.17]
Então, por que não foi rejeitado antes que isso acontecesse:
23 de fevereiro 23:49:42 m.example.com postfix/smtpd [42557]: aviso: desconhecido [182.150.23.17]: falha na autenticação SASL LOGIN: falha na autenticação
Com base em minhas próprias observações e testes, e em uma observação semelhante em https://mailing.postfix.users.narkive.com/AheRlxjc/blocking-access-before-sasl , parece que os clientes SMTP têm permissão para tentar a autenticação SASL antes do servidor aplica as diversas
smtpd_xxx_restrictions
regras.Do link acima:
Assim, um cliente conectado pode iniciar a etapa AUTH e obter uma resposta informando se funcionou ou não (o que significa que um invasor saberá se adivinhou a senha com sucesso!) Antes que o servidor decida se essa conexão deve ser rejeitada por qualquer razão. O motivo da rejeição pode ser porque o cliente não enviou um nome de host válido, ou está em um intervalo de endereços bloqueado, ou porque falhou na autenticação SASL. Mas essas condições e a rejeição acontecem após a tentativa de AUTH.
Este comportamento é provavelmente uma consequência deliberada da avaliação atrasada das listas de restrição de acesso SMTP . Vou experimentar se o uso
smtpd_delay_reject=no
altera o comportamento, embora isso esteja documentado como causando problemas para alguns clientes. Pode ser que eu não me importe com esses clientes, porque clientes SMTP com bugs provavelmente são spambots de qualquer maneira.A sugestão no link acima é usar o postscreen para filtrar spammers. Acho que vou investigar isso também.
Editar: O uso
smtpd_delay_reject=no
parece dar os resultados desejados. Clientes com nomes de host inválidos agora são rejeitados imediatamente, antes mesmo de poderem negociar uma sessão TLS ou tentar autenticar. Meus registros agora mostram:postfix/smtpd[64594]: NOQUEUE: rejeitar: CONNECT de desconhecido[45.88.90.174]: 450 4.7.25 Host do cliente rejeitado: não é possível encontrar seu nome de host, [45.88.90.174]; proto=SMTP
Suspeito que o motivo pelo qual não vi esses erros no passado é que os spambots que tentavam aplicar força bruta à minha autenticação SASL estavam interrompendo a conexão assim que não conseguiam fazer login, de modo que não permaneceram por tempo suficiente para obter uma rejeição. Isso parece consistente com os logs mostrados na pergunta acima, onde a conexão cai após falha no login:
23 de fevereiro 16:53:19 m.example.com postfix/smtpd[30155]: conexão perdida após AUTH de desconhecido[196.190.41.137]
Portanto, o motivo pelo qual eu não estava vendo os
reject
logs esperados com base em nomes de host de clientes inválidos/desconhecidos é porque os clientes são maus atores que nem sequer esperam o tempo suficiente para serem rejeitados.