From owner-freebsd-questions@FreeBSD.ORG Mon May 3 14:41:11 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 62F54106566B for ; Mon, 3 May 2010 14:41:11 +0000 (UTC) (envelope-from john@starfire.mn.org) Received: from elwood.starfire.mn.org (starfire.skypoint.net [173.8.102.29]) by mx1.freebsd.org (Postfix) with ESMTP id 2FB6A8FC23 for ; Mon, 3 May 2010 14:41:10 +0000 (UTC) Received: from elwood.starfire.mn.org (john@localhost [127.0.0.1]) by elwood.starfire.mn.org (8.14.3/8.14.3) with ESMTP id o43EfAi5014478 for ; Mon, 3 May 2010 09:41:10 -0500 (CDT) (envelope-from john@elwood.starfire.mn.org) Received: (from john@localhost) by elwood.starfire.mn.org (8.14.3/8.14.3/Submit) id o43EfAkf014477 for freebsd-questions@freebsd.org; Mon, 3 May 2010 09:41:10 -0500 (CDT) (envelope-from john) Date: Mon, 3 May 2010 09:41:10 -0500 From: John To: freebsd-questions@freebsd.org Message-ID: <20100503144110.GA14402@elwood.starfire.mn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: 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: Mon, 03 May 2010 14:41:11 -0000 The script kiddies have apparently figured out that we use some time-window sensitivity in our adaptive filtering. From 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. 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. Anybody got any superior suggestions? -- John Lind john@starfire.MN.ORG