I'm seeing strings of failed POP3 login attempts with obvious bogus usernames coming from different IP addresses. Today's originated from 216.31.146.19 (which resolves to neovisionlabs.com). This looks like a botnet attack. I got a similar probe a couple days ago. Is anyone else seeing these? The attack involves trying about 20 different names, about 3-4 seconds apart. Here's a few sample log lines: dovecot: Aug 15 04:15:45 Error: auth-worker(default): pam(mike,216.31.146.19): pam_authenticate() failed: User not known to the underlying authentication module dovecot: Aug 15 04:15:49 Error: auth-worker(default): pam(alan,216.31.146.19): pam_authenticate() failed: User not known to the underlying authentication module dovecot: Aug 15 04:15:53 Error: auth-worker(default): pam(info,216.31.146.19): pam_authenticate() failed: User not known to the underlying authentication module dovecot: Aug 15 04:15:57 Error: auth-worker(default): pam(shop,216.31.146.19): pam_authenticate() failed: User not known to the underlying authentication module Timo, can you add the port used in the attempt to the error log entry? (It does show up in the info log entry, but that means I need to correlate lines in the two log files.)
On 8/15/2008, Kenneth Porter (shiva at sewingwitch.com) wrote:> I'm seeing strings of failed POP3 login attempts with obvious bogus > usernames coming from different IP addresses. Today's originated from > 216.31.146.19 (which resolves to neovisionlabs.com). This looks like > a botnet attack. I got a similar probe a couple days ago. Is anyone > else seeing these?You're kidding, right? Dictionary attacks are a fact of life these days. Just install some kind of blocking on your firewall (fail2ban is a good one), and let it take care of the worst of it... -- Best regards, Charles
Kenneth Porter wrote:>--On Friday, August 15, 2008 5:51 PM -0400 Bruce Bodger ><bruce.bodger at demval.com> wrote: > >> fail2ban will not work for this as the incoming ip addresses are >> spoofed. fail2ban would end up blocking legitimate servers. > >How do you spoof a source address on a TCP connection? I was unaware that >was possible. How would replies know how to get back to the spoofing host? >At best, you can spoof another host on your own routed segment. Unless you >have control of the routing tables on the connecting routers, of course.Exactly. These days, IP spoofing is most useful to hide the identity of the perpetrator of a DoS attack. It certainly is not applicable to a dictionary attack on POP3 or other logins since with a spoofed IP, the perpetrator will never see the response to determine if the login attempt was successful. -- Mark Sapiro <mark at msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Aug 16, 2008, at 11:14 AM, Mark Sapiro wrote:>>> Exactly. These days, IP spoofing is most useful to hide the >>> identity of >>> the perpetrator of a DoS attack. It certainly is not applicable to a >>> dictionary attack on POP3 or other logins since with a spoofed >>> IP, the >>> perpetrator will never see the response to determine if the login >>> attempt was successful. >> >> I stand corrected... sorry. I was thinking of an http cross-site >> attack which also seems popular now-a-days. >> >> So if I read you right then you would consider the IP address shown >> in the original thread post.. >> >>> dovecot: Aug 15 04:15:45 Error: auth-worker(default): pam(mike, >>> 216.31.146.19): pam_authenticate() failed: User not known to the >>> underlying authentication module >>> dovecot: Aug 15 04:15:49 Error: auth-worker(default): pam(alan, >>> 216.31.146.19): pam_authenticate() failed: User not known to the >>> underlying authentication module >>> dovecot: Aug 15 04:15:53 Error: auth-worker(default): pam(info, >>> 216.31.146.19): pam_authenticate() failed: User not known to the >>> underlying authentication module >>> dovecot: Aug 15 04:15:57 Error: auth-worker(default): pam(shop, >>> 216.31.146.19): pam_authenticate() failed: User not known to the >>> underlying authentication module >> >> >> ..216.31.146.19, to be a party to the attack and therefore a >> candidate for locking out? > > > Yes. I do it (with my own script, not fail2ban, but it works the same > way).Thank you for the clarification. B. Bodger