Recebo uma tonelada de tentativas de login de SMTP com falha. Eu realmente gostaria de me defender disso, mas o registro dessas tentativas é ruim.
Estou usando o sendmail 8.15, cyrus-sasl 2.1.26. A configuração do SASL é a maneira mais simples, padroniza tudo ao redor, autenticando com o pam_unix.
Recebo muito mensagens de log assim:
saslauthd[8292]: pam_unix(smtp:auth): check pass; user unknown
saslauthd[8292]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
saslauthd[8292]: DEBUG: auth_pam: pam_authenticate failed: Authentication failure
saslauthd[8292]: do_auth : auth failure: [user=colby] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]
Isso significa que, embora eu saiba que tentativas falsas de fazer login estão acontecendo, não posso fazer nada sobre isso, como ter a cadeia do fail2ban nelas.
Eu não posso dizer se o problema é que o Sendmail está contando coisas para o pam_unix, e isso está acontecendo, ou se o sendmail não está informando sobre onde a tentativa está sendo feita.
O que eu quero é que as tentativas de autenticação sejam registradas com o endereço IP de onde elas vieram, portanto, se houver muitas falhas, o fail2ban poderá prender o IP.
Infelizmente, a resposta parece ser que, com o sendmail e o cyrus-sasl, não há controle. O Sendmail parece enviar as informações para o sasl, e o cyrus-sasl não faz nada com ele, e igualmente o sendmail não faz nada depois que a autenticação falha.
As respostas de Thrig acima podem ser úteis para os outros, e talvez um dia alguém veja isso e forneça uma resposta melhor.
A sessão aqui é dividida entre o agente de transporte de email e também saslauthd :
testhost saslauthd[17177]: do_auth : auth failure:
[user=AzureDiamond] [service=smtp] [realm=] [mech=pam]
[reason=PAM auth error]
Um log completo do que você deseja pode não estar disponível por padrão ou exigirá reconstrução em algum serviço de agregação de log. (O registro também é ruim no Postfix ao usar saslauthd ; alguns dos logs acabam nos logs de correio e outros em outros lugares.) O Sendmail suporta regras de syslog personalizadas; no entanto, se um cliente emitir apenas EHLO nurse , AUTH LOGIN , QXp1cmVEaWFtb25k , SHVudGVyMg== e, em seguida, falhar (com quit ou simplesmente soltar a conexão), isso pode não dar uma chance aos ganchos comuns de conjunto de regras para executar.
Com o LogLevel aumentado para 11 (ou superior), há uma falha de logon que inclui o endereço de retransmissão:
testhost sendmail[20684]: wA6KuRRJ020684: AUTH failure
(LOGIN): authentication failure (-13) SASL(-13):
authentication failure: checkpass failed,
relay=localhost [127.0.0.1]
Isso vem de sendmail/srvrsmtp.c e acontece quando LogLevel > 9 . Ou você pode corrigir esse arquivo para evitar aumentar o LogLevel , mas isso pode apresentar problemas diferentes.
Outros métodos para limitar o SMTP AUTH seguem.
Ajuste a configuração do PAM e rejeite SMTP AUTH , a menos que o usuário pertença a um grupo específico; Isso evitará muitos ataques de adivinhação de senhas, embora seja viável se apenas um pequeno e previsível subconjunto de usuários precisar usar SMTP AUTH :
account required pam_access.so accessfile=/etc/security/smtp_access.conf
e, em seguida, em /etc/security/smtp_access.conf
+ : ok-sasl : ALL
- : ALL : ALL
e, em seguida, coloque os usuários no grupo ok-sasl .
Outra opção seria colocar uma VPN ou algo na frente do SMTP para que o serviço simplesmente não esteja disponível para a Internet; isso deve reduzir a pulverização do ruído de log que um serviço voltado para o público recebe nos dias de hoje.
Eu também tentei pam_tally2 , mas isso foi muito bom em bloquear contas, incluindo contas legítimas que se conectaram sem nenhum erro aparente ... talvez funcione melhor para você?