From owner-freebsd-security@FreeBSD.ORG Thu Mar 22 14:47:13 2007 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 846CA16A405 for ; Thu, 22 Mar 2007 14:47:13 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 2C64A13C484 for ; Thu, 22 Mar 2007 14:47:12 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=TLjeGb1DN7pMGuaU2J94KfXJdOrY7Vz1sfCuK+t5AEQG2mh39PCb1x0Pwvcdwe6xxSNVghm/jvgOlwmq/1Qii3/JwjUmuwBassno2klrF0WKyHlHlSsCjd6WXVoyLOp9ya72O8JKfYnbN1MHR0H1czc2PjTFV2Pw4tcJM/aiuzk=; Received: from codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1HUOZH-0006EW-M3; Thu, 22 Mar 2007 17:47:08 +0300 Date: Thu, 22 Mar 2007 17:47:02 +0300 From: Eygene Ryabinkin To: Volker Message-ID: <20070322144702.GN14837@codelabs.ru> References: <20070321123033.GD31533@bunrab.catwhisker.org> <20070321092724.fd6f1541.wmoran@collaborativefusion.com> <20070321103006.c57729cc.wmoran@collaborativefusion.com> <20070321145041.GG14837@codelabs.ru> <46027EEE.1080105@vwsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <46027EEE.1080105@vwsoft.com> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.4 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: freebsd-security@freebsd.org, "W. D." , Bill Moran Subject: Re: Re: Reality check: IPFW sees SSH traffic that sshd does not? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2007 14:47:13 -0000 Good day! Thu, Mar 22, 2007 at 02:04:46PM +0100, Volker wrote: > > You can use the following rule that will put very fast SSH connectors > > to the pf table ssh_scans: > > ----- > > pass in quick on $iface proto tcp from any to $ip port 22 flags S/AUSPF \ > > keep state (max-src-conn 4, max-src-conn-rate 6/1, overload flush) > > ----- > > If you replace the "flush" keyword by "flush global" would give > better results as it immediately will kill all additional > connections with that host (IP address). Without the "global" > keyword just the ssh connection causing the rule overload is being > killed. > > Also a max-src-conn-rate of 6/1 (6 connections in 1 second) is IMO a > bit too friendly to those brute force script kiddies but YMMV. I happen to make some rapid scp's that are doing about 5 or 6 connections in a minute from the ligitimate hosts, so sometimes even the ligitimate hosts are getting blocked. And if that host has another session to the server I do not like it to be dropped, since then the session will be lost and I will not be able to drop the ligitimate host from the ssh_scans manually. Whitelisting will help, but I have no persistent list of the machines I can come from. But your mileage may vary. By the way, the 6/1 rule is very good when you're firewalling the large number of clients: massive SSH scans are often hitting the full netblock, so changing the '$ip' to '' above you will get very good throttling for the entire network you're protecting. > While doing nearly the same as you did in your pf rules, I also let > a cron job run every 10 minutes and scan the auth log for login > errors. If a threshold value is being reached, the IP address gets > inserted into a pf table and gets blocked (forever). This is just a > second line of defense. Yeah, this is also helpful. But my setup currently gives me about 4 probes from the SSH scanners and then that host gets blocked. And the blocking for a long time (ot forever) can be not so good on the busy public login servers -- machine can just be hacked, but rapidly reinstalled and patched. Again, your mileage may vary. -- Eygene