Date: Tue, 4 May 2010 08:26:13 -0400 From: Paul Mather <paul@gromit.dlib.vt.edu> To: freebsd-questions@freebsd.org Cc: John <john@starfire.mn.org> Subject: Re: pf suggestions for paced attack Message-ID: <F3704D14-F402-436C-8D65-7EBABCBE566B@gromit.dlib.vt.edu> In-Reply-To: <20100504060507.4ACE81065691@hub.freebsd.org> References: <20100504060507.4ACE81065691@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 3 May 2010 09:41:10 -0500, John <john@starfire.mn.org> wrote: > The script kiddies have apparently figured out that we use some > time-window sensitivity in our adaptive filtering. =46rom sshd, I've > been seeing "reverse mapping checking getaddrinfo ... failed" and > from ftpd (when I have the port open at all, which is rare), I am > seeing probes at about 27 second intervals. This stays well below > the 3/30 (three connections in 30 seconds) sensitivity that I had > been using. It took them nearly two and a half hours to make 154 > attemps, but computers are very patient. >=20 > I have now changed the timing window sensivity, but it's to the > point now where there's a significant probability that someone could > lock themselves out (temporarily, at least, I do clear these tables > periodically) if they are having a bit of a fat-finger moment with > their password. >=20 > Anybody got any superior suggestions? I'm not claiming these are superior, but they are suggestions. :-) You might want to try security/sshguard-pf from ports. It still uses a = pf table to do the blocking, but hooks into syslogd and scans for = various SSH login failure/abuse messages to add miscreants to that = table. (So, many successful logins won't cause a lockout.) Sshguard = will also block persistent offenders for progressively longer periods. = (Sshguard will also work with /etc/hosts.allow [security/sshguard], IPFW = [security/sshguard-ipfw] and IPfilter [security/sshguard-ipfilter].) = Maintenance of the pf table is handled entirely by sshguard. Also, you could consider instead of having a relatively short time = window in which the connection attempts occur, you could try lengthening = it, perhaps increasing slightly the number of permitted connection = attempts. So, instead of 3/30, you might use 5/300. That still allows = legitimate users some leeway when typing in incorrect passwords and = allows for more multiple successful connections, but forces automated = brute force attacks to lengthen their connection attempt delay = considerably. The downside is that if a legitimate user does provoke a = lockout, he or she will be locked out for a little longer. Cheers, Paul.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F3704D14-F402-436C-8D65-7EBABCBE566B>