서버가 smtp 로그인 공격을 받고 있지만 로그에 IP가 없기 때문에 방화벽이 이를 차단할 수 없습니다... 이와 같이var/로그/메시지:
Mar 13 16:00:05 sunucu saslauthd[1484]: do_auth : auth failure: [user=admin] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]
Mar 13 16:00:07 sunucu saslauthd[1483]: do_auth : auth failure: [user=admin] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]
Mar 13 16:00:09 sunucu saslauthd[1485]: do_auth : auth failure: [user=admin] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]
Mar 13 16:00:11 sunucu saslauthd[1482]: do_auth : auth failure: [user=admin] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]
Mar 13 16:00:12 sunucu saslauthd[1484]: do_auth : auth failure: [user=admin] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]
Mar 13 16:00:15 sunucu saslauthd[1482]: do_auth : auth failure: [user=admin] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]
...
...
소프트웨어 버전:
Operating system CentOS Linux 7.4.1708
Perl version 5.016003
Path to Perl /usr/bin/perl
BIND version 9.9
Postfix version 2.10.1
Mail injection command /usr/lib/sendmail -t
Apache version 2.4.6
PHP versions 5.4.16, 7.0.10, 7.1.8
Logrotate version 3.8.6
MySQL version 10.1.31-MariaDB
Dovecot IMAP/POP3 Server Version 2.2.10.
이 문제를 해결할 방법이 있나요?
답변1
질문은 ~이야오래 지속된 버그cyrus-sasl에서 이는 auth-pam 코드가 saslauthd에 호스트(또는 사용자) 정보를 전달하는 방법을 실제로 제공하지 않기 때문에 발생합니다. 이론적으로는 이 문제를 해결하기 위한 패치가 버전 2.2에 포함되어야 하지만 2.2.X 릴리스 노트에는 이에 대한 내용이 없습니다. 이것이 버전 2.1에서 백포트될 수 있지만(아마도 배포판별로), 이것이 실제로 RedHat이나 Ubuntu에서 발생한다는 증거를 찾을 수 없습니다.
실용적인 솔루션이 부족한 경우, 제안된 솔루션을 확인해 보세요.https://unix.stackexchange.com/a/480005그리고https://unix.stackexchange.com/a/511997, 특히 실패한 로그인에 대한 IP를 표시하기 위해 sendmail의 로그 수준을 높이거나 "연결 중에 MAIL/EXPN/VRFY/ETRN이 발행되지 않음" 오류를 실패한 시도에 대한 프록시로 사용합니다.
답변2
일반 SMTP 서비스 자체는 인증을 제공하지 않습니다. 인증된 SMTP는 일반적으로 SMTP 서비스를 사용하려면 먼저 IMAP 또는 POP를 통해 로그인해야 하기 때문에 완곡한 표현입니다.
종종 인터넷에 열려 있는 IMAP 포트(및 더 일반적으로 POP3 포트)는 취약한 로그인/비밀번호를 찾는 쉬운 방법으로 무차별 대입 공격을 받습니다.
그러나 기본 postfix+dovecot 구성에서는 saslauthd
일반적으로 인증 목적으로 dovecot
IMAP/POP3 서비스에 대한 호출이 제공됩니다.
따라서 dovecot
로그를 확인하여 무슨 일이 일어났는지 확인하고 문제의 IP 주소를 확인해야 합니다.
내 생각에 dovecot
로그는 대략 /var/log/dovecot.log
그런 것 같습니다(저는 한동안 centOS를 사용하지 않았습니다).
로깅만으로는 충분하지 않은 경우 dovecot
다음과 같이 구성을 일시적으로 변경할 수 있습니다.
편집 /etc/dovecot/conf.d/10-logging.conf
또는 /etc/dovecot/dovecot.conf
사용:
auth_verbose=yes
auth_debug=yes
verbose_ssl=yes
그런 다음service dovecote restart
또한 제안에 따르면 일반 형식보다는 TLS(pop3s 995/tcp 및 imaps 993/tcp)를 통해 이러한 서비스를 제공하는 것이 더 합리적일 수 있습니다. 더욱 안전해지고 공격에 덜 취약해집니다.
추신. 이 답변을 편집하려면 가지고 있는 구성 파일과 로그 파일의 이름을 확인해 주세요.