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 From owner-freebsd-security@FreeBSD.ORG Sat Sep 2 10:42:21 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 85BC416A4E0; Sat, 2 Sep 2006 10:42:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CD5C43D49; Sat, 2 Sep 2006 10:42:21 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id CBCE846DC6; Sat, 2 Sep 2006 06:42:20 -0400 (EDT) Date: Sat, 2 Sep 2006 11:42:20 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: stable@FreeBSD.org In-Reply-To: <20060816120709.N45647@fledge.watson.org> Message-ID: <20060902113521.P84468@fledge.watson.org> References: <20060816120709.N45647@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: trustedbsd-audit@TrustedBSD.org, freebsd-security@FreeBSD.org Subject: Re: Warning: MFC of security event audit support RELENG_6 in the next 2-3 weeks 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: Sat, 02 Sep 2006 10:42:21 -0000 On Wed, 16 Aug 2006, Robert Watson wrote: > Dear 6-STABLE users, > > In the next 2-3 weeks, I plan to MFC support for CAPP security eventing > auditing from 7-CURRENT to 6-STABLE. The implementation has been running > quite nicely in -CURRENT for several months. Right now, I'm just waiting on > a confirmation from Sun regarding formal allocation of a BSM header version > number so as to avoid accidental version number conflicts in the future, > which I hope to get this week, as well as a bug fix in the handling of > per-pipe preselection, which Christian Peron is currently working on. The > audit implementation will be considered an experimental feature in > 6.2-RELEASE, but in practice runs quite well, so is ready for more > wide-spread deployment. Dear 6-STABLE users, After a couple of weeks of settling, polishing, etc, the MFC of audit support is about to begin. Over the next couple of days, the 6-STABLE build may be briefly broken as inter-dependent components are merged. I do not anticipate any serious disruption, but some caution is called for. In principle, all the potentially tricky kernel ABI dependencies, etc, were dealt with before 6.0-RELEASE, such as changes in the size of the kernel system call data structures. The approximate merge plan, run by re@ a few days ago, is as follows: - Merge OpenBSM contrib subtree detached from build. - Merge kernel trees (src/sys/bsm, src/sys/security/audit), attach to build. - Merge kernel audit event hooks across the kernel. In principle, we've reserved space in the syscall table, etc, so that there is no disruptive kernel ABI change for critical data structures. - Merge OpenBSM library and command line tools build, as well as install of /etc/security, /etc/rc.d files. - Merge kernel man pages (src/share/man/man4/audit*). - Merge user space tool changes, such as to login, sshd, su, etc, so that events are audited. - Loose ends, such as make.conf man page, etc. - Update Handbook to indicate that Audit applies to 6.x and 7.x. I will send out a status e-mail once the merge is completed, and send out a notice if any problems are encountered. If you experience any problems, especially problems not related to the build (which will likely get picked up and fixed quickly, if they occur), please let me know. I'm especially interested in any issues relating to changes in ability to log in, programs exiting due to using unrecognized system calls (SIGSYS), etc. As I said above, these sorts of problems are unlikely to occur, but if they do occur, I'd like to fix them as quickly as possible. I would like to have the merge largely done by 4 September 2006, although it's possible a few straggling tweaks will come in after that. Thanks, Robert N M Watson Computer Laboratory University of Cambridge