From owner-freebsd-pf@FreeBSD.ORG Wed Feb 9 20:55:51 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 885A41065675 for ; Wed, 9 Feb 2011 20:55:51 +0000 (UTC) (envelope-from vchepkov@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 32AD78FC19 for ; Wed, 9 Feb 2011 20:55:50 +0000 (UTC) Received: by qwj9 with SMTP id 9so467113qwj.13 for ; Wed, 09 Feb 2011 12:55:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=g1MYWj8REZtk6u57tOI9kbeC/8NWTMPH97SojVwQa1o=; b=UIDDDkJxb8FVc0T5SLPeajtj4SNqlqeumPdxRB/0wj1CGi9PvIFpE2mT3Owhhfiom4 TEkGh44mUU1KeyQ42kxOAi+9iLPnZdIUq/dT1bOkjhsMiHne4abfJ6ousr8//aZtVVvN Pzfolk3wOJaLKK+c0+aycRzbRBkeA7iGIGG5E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=HIYx7L+siu0PTA3XQf92M4NUv5x2hhFdmtvJpftBvaTpIvSPvp8mH7hH6D5h8omaKu ntghUXuL+MuparNuQ/LGfN6/MNZZLxkPBRKzdK5y3iHwVHpmt54FuyuIMxgexRTctyor FqrSHoAo7ls4YyL69fM7AXsOtm8eX502TtnmI= Received: by 10.229.181.75 with SMTP id bx11mr5661791qcb.74.1297284943972; Wed, 09 Feb 2011 12:55:43 -0800 (PST) Received: from vvcmac.chepkov.lan (pool-173-71-213-51.clppva.fios.verizon.net [173.71.213.51]) by mx.google.com with ESMTPS id q12sm453432qcu.6.2011.02.09.12.55.43 (version=SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 12:55:43 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Vadym Chepkov In-Reply-To: <20110209185118.GA16942@insomnia.benzedrine.cx> Date: Wed, 9 Feb 2011 15:55:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5A0B04327C334DA18745BFDBDBECE055@charlieroot.de> <98689EFE59404E4B838E79071AABA8B4@charlieroot.de> <56413CA2-EE4F-4E06-B044-0982E864E44D@gmail.com> <20110209185118.GA16942@insomnia.benzedrine.cx> To: Daniel Hartmeier X-Mailer: Apple Mail (2.1082) Cc: freebsd-pf@freebsd.org 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: Wed, 09 Feb 2011 20:55:51 -0000 On Feb 9, 2011, at 1:51 PM, Daniel Hartmeier wrote: > On Tue, Feb 08, 2011 at 08:07:52PM -0500, Vadym Chepkov wrote: >=20 >> No idea, why it didn't stop after 9 attempts. >=20 > The connection rate is not calculated precisely, from pf.conf(5) >=20 > max-src-conn-rate / > Limit the rate of new connections over a time interval. The = con- > nection rate is an approximation calculated as a moving = average. >=20 > There is a counter, and a last-update-time. >=20 > When the first connection matches, the counter starts at zero, and the > time (one second resolution) is noted. >=20 > Whenever a subsequent connection matches, the following happens: >=20 > 1) if the last-update-time is further back than (60, in = your > case), the counter is reset to zero. > 2) otherwise, the counter is reduced relative to how much time has > passed since last-update-time (i.e. the counter is multiplied by > (now - last-update-time) / > 3) the counter is incremented by 1000 >=20 > When the counter exceeds 1000 * (9, in your case), the > max-src-conn-rate is triggered. >=20 > This works reasonably well in many cases, but may be quite inprecise, > especially when is much smaller than . >=20 > You could try max-src-conn-rate 2/5 instead. >=20 Wouldn't it be dangerous to reduce it this drastically? I can lock out = myself. I don't think it's uncommon to try to open 3 connections at the same = time, especially in NAT environment. I would increase "number", but it will negate the rule. Here is an example of an actual intruder: Feb 8 11:27:01 castor sshd[57304]: Invalid user ariane from = 113.185.0.16 Feb 8 11:27:04 castor sshd[57306]: Invalid user armand from = 113.185.0.16 Feb 8 11:27:08 castor sshd[57308]: Invalid user armande from = 113.185.0.16 Feb 8 11:27:11 castor sshd[57310]: Invalid user armando from = 113.185.0.16 Feb 8 11:27:15 castor sshd[57312]: Invalid user armani from = 113.185.0.16 Feb 8 11:27:18 castor sshd[57314]: Invalid user arnie from 113.185.0.16 Feb 8 11:27:22 castor sshd[57316]: Invalid user arne from 113.185.0.16 Feb 8 11:27:25 castor sshd[57318]: Invalid user arnold from = 113.185.0.16 Feb 8 11:27:29 castor sshd[57320]: Invalid user art from 113.185.0.16 Feb 8 11:27:33 castor sshd[57322]: Invalid user arthur from = 113.185.0.16 Feb 8 11:27:36 castor sshd[57324]: Invalid user artie from 113.185.0.16 Feb 8 11:27:47 castor sshd[57326]: Invalid user arty from 113.185.0.16 Feb 8 11:27:50 castor sshd[57328]: Invalid user asha from 113.185.0.16 Feb 8 11:27:54 castor sshd[57330]: Invalid user asher from 113.185.0.16 Feb 8 11:27:57 castor sshd[57332]: Invalid user ashley from = 113.185.0.16 Feb 8 11:28:01 castor sshd[57334]: Invalid user ashton from = 113.185.0.16 That's 16 packets in 60 seconds. 2/5 wouldn't caught him either - 7 seconds between 3 packets And I would be fine if just 3-4 packets exceeded the threshold, if it's = not precise. But it doesn't stop him at all, that what puzzles me # bzgrep 113.185.0.16 /var/log/auth.log.0.bz2 | wc -l 939 # pfctl -t abusive_hosts -T show=20 46.23.72.63 69.162.99.220 79.136.100.188 93.174.31.134 109.169.21.37 188.127.244.107 200.24.219.198 221.133.41.170 221.238.253.85 222.186.37.205 some do caught, as you can see, but I still see every day those that = avoid the trap Thanks, Vadym > The details can be found in pf.c, see >=20 > = http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/contrib/pf/net/pf.c?rev=3DHE= AD >=20 > The reason this was chosen over a more precise algorithm is that this = is > very cheap CPU-wise and requires only a minimal amount of memory. >=20 > Regards, > Daniel