Re: pam problem
On Sun, 20 May 2012 09:40:02 -0600, Glenn English wrote:
> 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.
Well, those can be false alarms or something that can be tweaked for
rkhunter config.
>> 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.
And nothing for Dovecot? Or maybe is that the logs are only registered for
the pam service :-?
> 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
That IP coming from a Mexican ISP is blacklisted in some RBLs.
> 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.
Yes, it's necessary to know where are those hits coming from.
>> 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?
I'm far to be a linux programmer :-) but you can use "tcpdump" to monitor
your network activity.
> 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.
Programming sockets goes beyond my knowledge but maybe someone here can give
you aditional hints on how to do this.
> 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 :-)
Hard to say... what seems to be true is that regardless the origin (local or
remote) it's something automated, a script scheduled to be run on certain
hours.
>> 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.
Yup. Login to your Dovecot account from your local server and give a bad
password or faked username, then look at the logs, just to compare both
outputs...
Greetings,
--
Camaleón
Reply to: