From owner-freebsd-pf@FreeBSD.ORG Thu Feb 10 14:13:14 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 584CC1065673 for ; Thu, 10 Feb 2011 14:13:14 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id E282B8FC19 for ; Thu, 10 Feb 2011 14:13:13 +0000 (UTC) Received: by bwz12 with SMTP id 12so2043725bwz.13 for ; Thu, 10 Feb 2011 06:13:12 -0800 (PST) Received: by 10.204.22.10 with SMTP id l10mr487643bkb.49.1297347192591; Thu, 10 Feb 2011 06:13:12 -0800 (PST) Received: from dfleuriot.local ([83.167.62.196]) by mx.google.com with ESMTPS id v25sm31269bkt.18.2011.02.10.06.13.11 (version=SSLv3 cipher=OTHER); Thu, 10 Feb 2011 06:13:11 -0800 (PST) Message-ID: <4D53F276.5040006@my.gd> Date: Thu, 10 Feb 2011 15:13:10 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-pf@freebsd.org References: <4D51A061.20704@sentex.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: brutal SSH attacks X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 14:13:14 -0000 On 2/8/11 11:06 PM, Vadym Chepkov wrote: > > On Feb 8, 2011, at 2:58 PM, Mike Tancsa wrote: > >> On 2/8/2011 1:11 PM, Vadym Chepkov wrote: >>> Hi, >>> >>> Could somebody help in figuring out why PF configuration meant to prevent brutal SSH attacks doesn't work. >>> >>> Here are the relevant parts: >>> >>> /etc/ssh/sshd_config >>> >>> PasswordAuthentication no >>> MaxAuthTries 1 >>> >>> /etc/pf.conf >>> >>> block in log on $wan_if >>> >>> table persist >>> block drop in quick from >>> >>> pass quick proto tcp to $wan_if port ssh keep state \ >>> (max-src-conn 10, max-src-conn-rate 9/60, overload flush global) >> >> >> On RELENG_7 and 8 I use something like that. Is there a different IP >> they might be connecting to that is not covered under $wan_if? >> > > That would mean this rule doesn't work: > > block in log on $wan_if > > No it wouldn't. Your "block in log on $wan_if" rule is not quick, which means the ruleset evaluation continues. If another rule further down matches (the pass in quick for instance) then it is applied instead. normal rules: last match is applied to the packet quick rules: first match is applied and ruleset evaluation ends On a side note, I think you are under no obligation to add the "keep state" bit to the rule. Rules default to "keep state flags S/SA".