☰

sendmail SMTP 인증 로깅을 제어하는 ​​방법은 무엇입니까?

tag-icon • tag-icon pam sendmail sasl
sendmail SMTP 인증 로깅을 제어하는 ​​방법은 무엇입니까?

SMTP 로그인 시도에 실패하는 경우가 많습니다. 나는 그것에 대해 정말로 방어하고 싶지만 이러한 시도의 기록은 좋지 않습니다.

저는 sendmail 8.15, cyrus-sasl 2.1.26을 사용하고 있습니다. SASL 설정은 가장 간단한 방법이며 기본적으로 인증을 위해 pam_unix를 사용합니다.

나는 종종 다음과 같은 로그 메시지를 받습니다.

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]

즉, 가짜 로그인 시도가 발생하고 있음을 알지만, Fail2ban을 감옥에 가두는 등 이에 대해 제가 할 수 있는 일은 아무것도 없습니다.

Sendmail이 pam_unix에 정보를 전달하고 이를 덤프하는 것이 문제인지, 아니면 sendmail이 pam에게 시도 중인 위치를 알려주지 않는 것이 문제인지는 알 수 없습니다.

내가 원하는 것은 해당 IP 주소를 사용하여 인증 시도를 기록하는 것입니다. 따라서 실패가 많으면 fall2ban이 해당 IP를 감옥에 넣을 수 있습니다.

답변1

여기의 세션은 메일 전송 에이전트와 다음으로 구분됩니다 saslauthd.

testhost saslauthd[17177]: do_auth         : auth failure:
  [user=AzureDiamond] [service=smtp] [realm=] [mech=pam]
  [reason=PAM auth error]

원하는 전체 로그는 기본적으로 사용할 수 없거나 일부 로그 집계 서비스에서 재구성해야 할 수 있습니다. (Postfix를 사용할 때 로깅도 끔찍합니다 saslauthd. 일부 로그는 메일 로그에 남고 다른 로그는 다른 곳에 나타납니다.) Sendmail은 사용자 정의 syslog 규칙을 지원합니다. 그러나 클라이언트가 , EHLO nurse, AUTH LOGIN, QXp1cmVEaWFtb25k실패 SHVudGVyMg==(전달하거나 quit단순히 연결을 끊음) 만 발행하는 경우; ) 일반적인 규칙 세트 후크가 실행될 기회를 제공하지 않을 수 있습니다.

11(또는 그 이상)에 도달하면 LogLevel릴레이 주소를 포함하는 로그인이 실패합니다.

testhost sendmail[20684]: wA6KuRRJ020684: AUTH failure
  (LOGIN): authentication failure (-13) SASL(-13):
  authentication failure: checkpass failed,
  relay=localhost [127.0.0.1]

이는 sendmail/srvrsmtp.c다음과 같은 시점에서 발생합니다 LogLevel > 9. 또는 증가를 피하기 위해 파일을 패치할 수 있지만 LogLevel이로 인해 다른 문제가 발생할 수 있습니다.

SMTP AUTH를 제한하는 다른 방법은 다음과 같습니다.

pam은 특정 그룹을 제한합니다

PAM 구성을 조정하고 SMTP AUTH사용자가 특정 그룹에 속하지 않는 한 비활성화합니다. 이렇게 하면 대부분의 비밀번호 추측 공격이 방지되지만 예측 가능한 소수의 사용자만 사용해야 하는 경우에는 가능합니다 SMTP AUTH.

account     required      pam_access.so accessfile=/etc/security/smtp_access.conf

그럼 안으로/etc/security/smtp_access.conf

+ : ok-sasl : ALL
- : ALL : ALL

그런 다음 사용자를 ok-sasl그룹에 넣습니다.

SMTP AUTH 서비스 숨기기

또 다른 옵션은 인터넷에서 서비스를 사용할 수 없도록 VPN 등을 SMTP 앞에 배치하는 것입니다. 이렇게 하면 현재 공용 서비스에서 수신하는 로그 노이즈가 줄어듭니다.

pam_tally

나도 그것을 시도했지만 pam_tally2로그인할 때 명백한 오류가 없는 합법적인 계정을 포함하여 계정을 잠그는 데 유용합니다... 아마도 그것이 당신에게 더 잘 맞을 것입니까?

답변2

조금 도움이 되는 해결책이 있습니다. 귀하가 나열한 메시지는 /var/log/secure(적어도 RedHat/Centos에서는)에서 오는 것처럼 보입니다.

아시다시피 IP가 없으므로 이러한 항목으로 많은 작업을 수행할 수 없습니다.

그러나 /var/log/maillog를 보면 다음과 같은 항목을 찾을 수 있습니다.

Apr 11 13:58:48 alpha sendmail[23712]: x3BKwjij023712: [118.24.45.165] did not issue MAIL/EXPN/VRFY/ETRN during connection to MSA

이러한 연결은 인증(또는 두 번), 실패 및 연결 해제를 시도합니다. /var/log/secure에 있는 pam 메시지와 이들 메시지 사이에는 거의 100% 상관관계가 있습니다.

나는 이것을 Fail2ban 감옥에 대한 입력으로 사용합니다. 많은 자동화된 시스템 프로브가 전체 클래스 C(또는 원할 경우 /24) 주소 공간을 사용하고 주소가 다시 표시되기까지 꽤 오랜 시간이 걸리기 때문에 단일 발생으로 인해 금지가 발생합니다.

현재 IP가 여기저기 흩어져 있는 봇넷을 사용하고 있는 것으로 보이는 누군가/사물이 있습니다. 이러한 증상은 며칠 후에만 반복되는 것으로 보이며 전혀 반복되지 않는 경우도 있습니다. 결국에는 많은 Fail2ban 항목이 발생하게 됩니다. 하지만 아무것도 하지 않는 것보다는 낫습니다.

답변3

안타깝게도 대답은 아무런 통제 없이 sendmail과 cyrus-sasl을 사용하는 것 같습니다. Sendmail은 sasl에 정보를 보내는 것처럼 보이지만 cyrus-sasl은 이에 대해 아무 작업도 수행하지 않으며 마찬가지로 sendmail은 인증 실패 후 아무 작업도 수행하지 않습니다.

위의 Thrig의 답변은 다른 사람들에게 유용할 수 있으며 언젠가 누군가가 이것을 보고 더 나은 답변을 제공할 것입니다.

관련 정보