From owner-freebsd-questions@FreeBSD.ORG Tue May 4 13:31:12 2010 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A57E106567B for ; Tue, 4 May 2010 13:31:12 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by mx1.freebsd.org (Postfix) with ESMTP id E4CB48FC23 for ; Tue, 4 May 2010 13:31:11 +0000 (UTC) Received: from zidane.cc.vt.edu (zidane.cc.vt.edu [198.82.163.227]) by lennier.cc.vt.edu (8.13.8/8.13.8) with ESMTP id o44CQENR000605; Tue, 4 May 2010 08:26:14 -0400 Received: from auth3.smtp.vt.edu (EHLO auth3.smtp.vt.edu) ([198.82.161.152]) by zidane.cc.vt.edu (MOS 4.1.8-GA FastPath queued) with ESMTP id HPF32242; Tue, 04 May 2010 08:26:14 -0400 (EDT) Received: from gromit.tower.lib.vt.edu (gromit.tower.lib.vt.edu [128.173.51.22]) (authenticated bits=0) by auth3.smtp.vt.edu (8.13.8/8.13.8) with ESMTP id o44CQDUm011675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 May 2010 08:26:13 -0400 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Paul Mather In-Reply-To: <20100504060507.4ACE81065691@hub.freebsd.org> Date: Tue, 4 May 2010 08:26:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100504060507.4ACE81065691@hub.freebsd.org> To: freebsd-questions@freebsd.org X-Mailer: Apple Mail (2.1078) X-Mirapoint-Received-SPF: 198.82.161.152 auth3.smtp.vt.edu paul@gromit.dlib.vt.edu 5 none X-Mirapoint-IP-Reputation: reputation=neutral-1, source=Fixed, refid=n/a, actions=MAILHURDLE SPF TAG X-Junkmail-Info: (0) X-Junkmail-Status: score=10/50, host=zidane.cc.vt.edu X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A020209.4BE01266.0176,ss=1,fgs=0, ip=0.0.0.0, so=2009-09-22 00:05:22, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: John Subject: Re: pf suggestions for paced attack X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 13:31:12 -0000 On Mon, 3 May 2010 09:41:10 -0500, John 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.