Re: pam problem
On May 20, 2012, at 4:55 AM, Camaleón wrote:
>>> You can also run rkhunter to scan your system.
rkhunter may not have found any rootkits, but it found a
couple inetd entries it didn't care for. I had ident turned
on, and it doesn't like Amanda, my backup.
> 1/ Monitor the Fail2ban logs to check if the attack is still in place.
There's nothing about them in the Fail2ban log -- but there are a lot in
auth.log. But I may well not have Fail2ban configured correctly -- I've
got fail2ban-apache, fail2ban-apache-overflows, fail2ban-postfix, and
fail2ban-pam-generic running.
I looked for pam-generic. There are several entries, all with IPs:
> 2012-05-14 23:19:24,475 fail2ban.actions: WARNING [pam-generic] Ban 201.130.6.102
and when I egrep auth.log for the IP, they're in the rhost= param:
> /var/log/auth.log.0:May 14 23:19:08 server dovecot-auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=admin rhost=201.130.6.102
But nothing in Fail2ban without an IP to ban. I couldn't see the strange
login names from auth.log's empty rhosts in the Fail2ban log either.
> 2/ Try to find out the IP source of the machine(s) that is generating
> this just to confirm this is a common dictionary attack and nothing more
> serious or from a different nature.
You (and I at first) seem to be looking for IP network activity. The guy on SDLU
suggested it might be a program running on the host, using a *nix socket to go
through Dovecot to PAM to try different usernames and passwords. There doesn't
seem to be a "One Second Delay on Fail" rule here like there is with login, so
it'd much more effective for someone who wants to sit there all day trying to
find a log in.
And a failure from this scheme would produce no rhost param in the auth log.
I'm not a *nix programmer. Are you? If so, do you think the SDLU idea is viable?
After reading the sockets part of "TCP/IP Illustrated, vol 2", I believe it might
be. But I can't find anything that looks suspicious to me.
OTOH, the attacks seem to happen during business hours in the US's Pacific time
zone, and not on weekends. That makes me believe it's maybe coming from outside (I
looked at the cron jobs and saw nothing with this schedule :-)
> And there's no much you can do, sadly this is a usual situation for every
> service (web server, ftp, ssh, smtp, pop3/imap...) that is connected to
> Internet: once you are online you'll be fried ;-(
I'm dealing with many of the Internet miscreants fairly well -- lots of multi-layer
firewalling, secure servers, DMZ/LAN, non-dictionary usernames and passwords, etc. But
without a sender IP to block, I'm stumped.
--
Glenn English
hand-wrapped from my Apple Mail
Reply to: