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 -- 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/67440d73-a037-4ceb-88d3-5c9beac89...@slsware.com
