0

server gets smtp login attacks but firewall cant ban them because there is no IP in logs... like this in var/log/messages:

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]
...
...

Software versions:

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. 

Any idea to fix this?

1
  • Sorry for lacking information. Dovecot IMAP/POP3 Server Version 2.2.10. Please tell me if need any more information Mar 16 '18 at 13:14
0

Plain SMTP services per se do not provide authentication. Authenticated SMTP is an euphemism, as usually you have to log in previously via IMAP or POP, to be able to use the SMTP service.

Usually IMAP, and more often POP3 ports open for the Internet at large are brute-forced as an easy way to find weak login/passwords.

However, in the default postfix+dovecot configurations, normally saslauthd is, for authentication purposes, being invoked by dovecot, which provides the IMAP/POP3 services.

As such, as you have to look into dovecot logs to understand what is happening, and have a look at the offending IP addresses.

I think the dovecot logs are at /var/log/dovecot.log or something similar (I have not used centOS for a while).

If the logging is not enough for you, you might change dovecot configurations temporarily as:

Edit /etc/dovecot/conf.d/10-logging.conf or /etc/dovecot/dovecot.conf with:

auth_verbose=yes
auth_debug=yes
verbose_ssl=yes

and then service dovecote restart

Also as an advice, it may make more sense providing these services over TLS (pop3s 995/tcp and imaps 993/tcp ), and not in plain form. It will be more secure, and you will get far less attacks.

PS. Please confirm me the name of the configuration files and log files you have got, to edit this answer.

0

This issue is a long-standing bug in cyrus-sasl, caused by the the fact that the auth-pam code doesn't really provide a way to pass host (or user) information to saslauthd. In theory, the patch to fix it is supposed to be rolled into 2.2, but I don't see anything about it in the 2.2.X release notes. While it's possible this could get backported in the 2.1 release (maybe on a per-distribution basis), I can't find any evidence of that actually happening on RedHat or Ubuntu.

Lacking any actual resolution, you might look at the solutions proposed in https://unix.stackexchange.com/a/480005 and https://unix.stackexchange.com/a/511997, in particular increasing the log level in sendmail to reveal the IP of failed logins, or using the "did not issue MAIL/EXPN/VRFY/ETRN during connection" error as a proxy for failed attempts.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.