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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jpb6le$u2v$1...@dough.gmane.org
