Debian Lenny, Dovecot v 1.0.15. I'm getting a lot of what I think is a local socket asking dovecot:auth to verify username/passwords:> May 31 09:00:54 server dovecot-auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=admin rhost=Note the empty 'rhost='. That's why I think it's on the server. I see others that look like bots:> May 30 23:08:43 server dovecot-auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=admin rhost=200.119.139.22And I know how to promote the latter to a firewall. But with no rhost, I'm stumped... I've read books, googled, read docs, and asked for help on other mailing lists, and I've learned a lot. And I no longer think it really has much to do with Dovecot, other than the login attempt going through it to get to PAM. But has anyone here seen this before? Is my current theory correct? What did you do to make it go away? (I suspect that upgrading to Debian Squeeze might get rid of it, but I'm afraid that if I don't figure out what's going on, it might just come back.) -- Glenn English hand-wrapped from my Apple Mail
I forgot to include this config info:> # 1.0.15: /etc/dovecot/dovecot.conf > log_timestamp: %Y-%m-%d %H:%M:%S > protocols: imap pop3 > ssl_listen: * > ssl_disable: yes > disable_plaintext_auth: no > login_dir: /var/run/dovecot/login > login_executable(default): /usr/lib/dovecot/imap-login > login_executable(imap): /usr/lib/dovecot/imap-login > login_executable(pop3): /usr/lib/dovecot/pop3-login > login_max_processes_count: 12 > mail_privileged_group: mail > mail_executable(default): /usr/lib/dovecot/imap > mail_executable(imap): /usr/lib/dovecot/imap > mail_executable(pop3): /usr/lib/dovecot/pop3 > mail_plugin_dir(default): /usr/lib/dovecot/modules/imap > mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap > mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3 > pop3_uidl_format(default): > pop3_uidl_format(imap): > pop3_uidl_format(pop3): %08Xu%08Xv > auth default: > mechanisms: plain login > verbose: yes > passdb: > driver: pam > userdb: > driver: passwd > socket: > type: listen > client: > path: /var/spool/postfix/private/auth > mode: 432 > user: postfix > group: postfix-- Glenn English hand-wrapped from my Apple Mail
Glenn English writes:> I'm getting a lot of what I think is a local socket asking > dovecot:auth to verify username/passwords: > >> May 31 09:00:54 server dovecot-auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=admin rhostIf dovecot-auth is getting input from a local socket, then rhost information is irrelevant since the host doing the asking is the server itself (maybe from another daemon connected to a remote host). Maybe someone is brute forcing your server's Postfix authenticated SMTP service since Postfix can be configured to use Dovecot's SASL authentication framework. Joseph Tam <jtam.home at gmail.com>
Glenn English wrote:>> Maybe someone is brute forcing your server's Postfix authenticated >> SMTP service since Postfix can be configured to use Dovecot's SASL >> authentication framework. > > and for the suggestion -- I do have Postfix using Dovecot-Auth checking > for SASL. > > I think I'm going to re-install and run Tripwire...Tripwire? If the purpose of your query is to automate blocking of brute forcers, this software is not what you want (which detects tampering of critical system files). I suggest trying to find where Postfix failed login reports go, then use your fail2ban or what-have-you to detect and block hosts that repeatedly fail authentication. (First Google hit I did on this subject) http://scottlinux.com/2011/05/26/prevent-postfix-brute-force/ The log entries might look like {timestamp} {servername} postfix/smtpd[{pid}]: lost connection after AUTH from {remote-hostname}[{remote-ip}] Joseph Tam <jtam.home at gmail.com>