From owner-freebsd-security@FreeBSD.ORG Tue Aug 29 19:21:53 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA82B16A4DE for ; Tue, 29 Aug 2006 19:21:53 +0000 (UTC) (envelope-from pieter@thedarkside.nl) Received: from mail.thelostparadise.com (aberdeen.thelostparadise.com [193.202.115.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B4FF43D45 for ; Tue, 29 Aug 2006 19:21:52 +0000 (GMT) (envelope-from pieter@thedarkside.nl) Received: from [192.168.1.10] (s55915f73.adsl.wanadoo.nl [85.145.95.115]) by mail.thelostparadise.com (Postfix) with ESMTP id A118961C22 for ; Tue, 29 Aug 2006 21:22:17 +0200 (CEST) Message-ID: <44F493CC.4000205@thedarkside.nl> Date: Tue, 29 Aug 2006 21:21:48 +0200 From: Pieter de Boer User-Agent: Thunderbird 1.5.0.4 (X11/20060611) MIME-Version: 1.0 To: freebsd-security@freebsd.org References: <44E76B21.8000409@thedarkside.nl> In-Reply-To: <44E76B21.8000409@thedarkside.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: SSH scans vs connection ratelimiting 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: Tue, 29 Aug 2006 19:21:53 -0000 Just to put an end to this sillyness :) A few days ago, I wrote: > For months now, we're all seeing repeated bruteforce attempts on SSH. > I've configured my pf install to ratelimit TCP connections to port 22 > and to automatically add IP-addresses that connect too fast to a table > that's filtered: > This works as expected, IP-addresses are added to the 'lamers'-table > every once in a while. > > However, there apparently are SSH bruteforcers that simply use one > connection to perform a brute-force attack: As mysteries go, this one was a PEBKAC, too. My pf config had a 'deny all'-statement, but only for the external interface. A tunnel interface wasn't filtered in any way and no ratelimiting was taking place for the SSH daemon bound on that tunnel interface's address, hence the succeeding scans. Sorry for the confusion, Pieter