From owner-freebsd-security@FreeBSD.ORG Wed Aug 16 09:59:29 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 E9D3D16A4DF for ; Wed, 16 Aug 2006 09:59:29 +0000 (UTC) (envelope-from freebsd4@fadesa.es) Received: from fuego.fadesa.es (fuego.fadesa.es [195.55.55.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19D3C43D49 for ; Wed, 16 Aug 2006 09:59:28 +0000 (GMT) (envelope-from freebsd4@fadesa.es) Received: (from root@localhost) by fuego.fadesa.es (8.9.3p2/8.8.8) id LAA20602 for ; Wed, 16 Aug 2006 11:52:00 +0200 Received: from tierra.fadesa.es(195.55.55.7) by fuego.fadesa.es Wed, 16 Aug 06 11:51:37 +0200 Received: from [195.55.55.6] (filemon.fadesa.es [195.55.55.6] (may be forged)) by tierra.fadesa.es (8.9.3p2/8.8.8) with ESMTP id LAA02579 for ; Wed, 16 Aug 2006 11:58:51 +0200 Message-ID: <44E2EC5B.3010007@fadesa.es> Date: Wed, 16 Aug 2006 11:58:51 +0200 From: =?ISO-8859-1?Q?=22Jos=E9_M=2E_Fandi=F1o=22?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060417 X-Accept-Language: gl, es, en MIME-Version: 1.0 To: freebsd-security@freebsd.org References: <38802.1155288265@critter.freebsd.dk> <20060811123921.K43265@volatile.chemikals.org> In-Reply-To: <20060811123921.K43265@volatile.chemikals.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Logged: Logged by tierra.fadesa.es as LAA02579 at Wed Aug 16 11:58:51 2006 Subject: Re: atheros chips dangerous? 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: Wed, 16 Aug 2006 09:59:30 -0000 Wesley Morgan wrote: >> Other vendors have been totally impossible to work with. > > > I agree, the Atheros driver is fantastic. The driver may be "binary" in > some ways, but I think we got the best of both worlds. The vendor is > providing every scrap of information necessary without having to give > away trade secrets, and FreeBSD got a driver authored by a developer who > is probably one of the most qualified people in the world to work on it. > I know I go out of my way to purchase and recommend Atheros-based > wireless devices because of this. because of this, I'm buying their hardware. > Anyone who simply makes the blanket assumption that because something is > "FOSS" that it gets more peer review need only to look at some of the > oldest open source projects around, such as sendmail or XFree/Xorg, to > realize that security problems can persist for years without being > discovered. I know that by the mere fact of making it free it isn't automatically more secure, it needs reviews from people interest in it. But by reducing the potential number of reviewers with some type of restrictive contract doesn't help either. Anyway, as it was commented in this case the solution was reasonable because the NDA in use is for the 802.11 PHY layer to comply with the regulatory laws, see: http://madwifi.org/wiki/HAL#WhyistheHALclosedsource From owner-freebsd-security@FreeBSD.ORG Wed Aug 16 11:24:14 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 EE4EF16A4DE; Wed, 16 Aug 2006 11:24:14 +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 8D6D243D58; Wed, 16 Aug 2006 11:24:14 +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 ADBE346CDE; Wed, 16 Aug 2006 07:24:13 -0400 (EDT) Date: Wed, 16 Aug 2006 12:24:13 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: stable@FreeBSD.org Message-ID: <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: 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: Wed, 16 Aug 2006 11:24:15 -0000 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. For those who are unfamiliar with it, security event auditing ("audit") is the fine-grained logging of system security events, from login events to security relevant system calls. The result is a secure audit trail, which can be used for post-mortem analysis, intrusion detection, etc. The FreeBSD implementation is based on the Mac OS X audit implementation, implemented by my team at McAfee Research a few years ago, which Apple has kindly donated under a BSD license. However, it has been substantially enhanced since forking the Apple code. Additions include infrastructure to support live intrusion detection (live "audit pipes" with per-pipe preselection facilities independent of the global trail), 64-bit support, additional cross-platform portability, endian-independent trail files, and a great number of other cleanups, including support for FreeBSD's fine-grained SMP architecture. Both Mac OS X and FreeBSD implement Sun's de facto standard BSM API and audit trail format (with extensions for FreeBSD and Mac OS X events not present in Solaris), so many existing monitoring and analysis tools will run "out of the box", and FreeBSD and Mac OS X can be integrated into existing Sun-based audit infrastructure without too much work. While the open source FreeBSD releases have not been evaluated, this implementation is intended to be compliant with the CAPP standard's audit requirements. If you are interested in getting FreeBSD evaluated, and have been waiting on audit support (I know there are several people out there who have talked to me about this in the past), please let me know, and we can talk about how this might affect the evaluation of FreeBSD. Configuring audit requires the addition of "options AUDIT" to your kernel configuration file, modification of /etc/rc.conf, and any necessary tweaking of /etc/security/audit* to configure. There are detailed man pages, as well as a chapter in the FreeBSD Handbook, thanks to Tom Rhodes, explaining audit and audit configuration at a high level. Feedback on both the documentation and implementation would be most welcome; please direct this to the trustedbsd-audit@TrustedBSD.org mailing list. Until the implementation is upgraded from "experimental", AUDIT will remain disabled in the GENERIC kernel by default. I hope to compile AUDIT in by default starting around FreeBSD 6.3 or 6.4, but exactly when will depend on the nature of feedback, bug reports, etc, over the next few months. In its disabled state, some audit code is present in userland applications, but should not be run by default. We provide a NO_AUDIT build option to prevent audit support from being compiled into user space applications at all, which may be appropriate in embedded environments where space constraints are more of a pressing issue. The integration process will take around a week, and may result in intermitent build failures or other unexpected quirks in 6-STABLE. We have planned this fairly carefully in order to minimize disruption, but with any large set of source code changes, there is the risk of unexpected consequences. Once the code base to be merged is finalized, I will post a more specific merge schedule to the freebsd-stable and trustedbsd-audit mailing lists detailing how things will go. Once the merge is complete, I will post tutorial information to various mailing lists for those interested in giving this a try. You can learn more about Audit by reading the handbook chapter, and visiting http://www.TrustedBSD.org/audit.html As an FYI for those interested, we are shipping the user space audit components as a portable package, OpenBSM, so that BSM-based applications can be built to process Solaris, FreeBSD, and Mac OS X audit trails on a variety of platforms, including Linux, older versions of FreeBSD, and other *BSD systems. OpenBSM is present in the contrib tree in the FreeBSD source tree as a vendor branch import, and will track the most recent OpenBSM release. You can learn more about this at http://www.OpenBSM.org/. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-security@FreeBSD.ORG Sat Aug 19 19:48:57 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 F2A7F16A4DF for ; Sat, 19 Aug 2006 19:48:57 +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 6C62543D46 for ; Sat, 19 Aug 2006 19:48:56 +0000 (GMT) (envelope-from pieter@thedarkside.nl) Received: from [192.168.2.112] (i67156.upc-i.chello.nl [62.195.67.156]) by mail.thelostparadise.com (Postfix) with ESMTP id 5CC0561C77 for ; Sat, 19 Aug 2006 21:49:19 +0200 (CEST) Message-ID: <44E76B21.8000409@thedarkside.nl> Date: Sat, 19 Aug 2006 21:48:49 +0200 From: Pieter de Boer User-Agent: Thunderbird 1.5.0.5 (X11/20060803) MIME-Version: 1.0 To: freebsd-security@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 19 Aug 2006 21:16:02 +0000 Subject: 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: Sat, 19 Aug 2006 19:48:58 -0000 Gang, 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: table { } block quick from to any pass in quick on $ext_if inet proto tcp from any to ($ext_if) port 22 modulate state (source-track rule max-src-nodes 8 max-src-conn 8 max-src-conn-rate 3/60 overload flush global) 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: Aug 18 00:00:01 aberdeen sshd[87989]: Invalid user serwis from 83.19.113.122 Aug 18 00:00:03 aberdeen sshd[88010]: Invalid user serwis from 83.19.113.122 Aug 18 00:00:05 aberdeen sshd[88012]: Invalid user serwis from 83.19.113.122 Aug 18 00:00:10 aberdeen sshd[88014]: Invalid user serwis from 83.19.113.122 Aug 18 00:00:13 aberdeen sshd[88019]: Invalid user serwis from 83.19.113.122 Aug 18 00:00:14 aberdeen sshd[88021]: Invalid user serwis from 83.19.113.122 My theory was/is that this particular scanner simply multiplexes multiple authentication attempts over a single connection. I 'used the source luke' of OpenSSH to find support for this theory, but found the source a bit too wealthy for my brain to find such support. So, my question is: Does anyone know how this particular attack works and if there's a way to stop this? If my theory is sound and OpenSSH does not have provisions to limit the authentication requests per TCP session, I'd find that an inadequacy in OpenSSH, but I'm probably missing something here :) Regards, Pieter From owner-freebsd-security@FreeBSD.ORG Sat Aug 19 21:29:41 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 A775716A4E1 for ; Sat, 19 Aug 2006 21:29:41 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1544E43D55 for ; Sat, 19 Aug 2006 21:29:39 +0000 (GMT) (envelope-from swhetzel@gmail.com) Received: by nf-out-0910.google.com with SMTP id n29so1771863nfc for ; Sat, 19 Aug 2006 14:29:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WN/a4ysM6slLFc2Pj/2hwpEDEdIJveoA4Jy95r0pg/OcXijAIFYwmF8SltDcUA5AyYqwLI5iASwW2QVmSC4QSesAXFdj85vYnbClpOZdxKKvynIJX4iJtt78SkYREjO2Hztb9DMJeTaKTAjlwQnEf5xLcjchnyCHTOGvGkcngiw= Received: by 10.49.29.3 with SMTP id g3mr5705224nfj; Sat, 19 Aug 2006 14:29:38 -0700 (PDT) Received: by 10.78.83.2 with HTTP; Sat, 19 Aug 2006 14:29:38 -0700 (PDT) Message-ID: <790a9fff0608191429p180c20celc7b9ebae811097cd@mail.gmail.com> Date: Sat, 19 Aug 2006 16:29:38 -0500 From: "Scot Hetzel" To: "Pieter de Boer" In-Reply-To: <44E76B21.8000409@thedarkside.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44E76B21.8000409@thedarkside.nl> Cc: freebsd-security@freebsd.org 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: Sat, 19 Aug 2006 21:29:41 -0000 On 8/19/06, Pieter de Boer wrote: > 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: > > Aug 18 00:00:01 aberdeen sshd[87989]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:03 aberdeen sshd[88010]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:05 aberdeen sshd[88012]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:10 aberdeen sshd[88014]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:13 aberdeen sshd[88019]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:14 aberdeen sshd[88021]: Invalid user serwis from 83.19.113.122 > > It looks as though you need to lower 'MaxAuthTries' in your sshd_config file, as the default is set to allow six authentication attempts per connection. You'll find this in the sshd_config(5) man page. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-security@FreeBSD.ORG Sat Aug 19 21:31:37 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 EEC8116A4DF for ; Sat, 19 Aug 2006 21:31:37 +0000 (UTC) (envelope-from Joerg.Pulz@frm2.tum.de) Received: from mailhost.frm2.tum.de (mailhost.frm2.tum.de [129.187.179.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id B329E43D73 for ; Sat, 19 Aug 2006 21:30:58 +0000 (GMT) (envelope-from Joerg.Pulz@frm2.tum.de) Received: from localhost (mailhost.frm2.tum.de [129.187.179.12]) by mailhost.frm2.tum.de (8.13.6/8.13.6) with ESMTP id k7JLUvOn014297; Sat, 19 Aug 2006 23:30:57 +0200 (CEST) (envelope-from jpulz@frm2.tum.de) X-Virus-Scanned: at mailhost.frm2.tum.de Received: from hades.admin.frm2 (hades.admin.frm2 [172.25.1.10]) by mailhost.frm2.tum.de (8.13.6/8.13.6) with ESMTP id k7JLUstG014293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 19 Aug 2006 23:30:54 +0200 (CEST) (envelope-from jpulz@frm2.tum.de) Received: from hades.admin.frm2 (localhost [127.0.0.1]) by hades.admin.frm2 (8.13.6/8.13.6) with ESMTP id k7JLUr1G078507; Sat, 19 Aug 2006 23:30:53 +0200 (CEST) (envelope-from jpulz@frm2.tum.de) Received: (from jpulz@localhost) by hades.admin.frm2 (8.13.6/8.13.6/Submit) id k7JLUr5C078506; Sat, 19 Aug 2006 23:30:53 +0200 (CEST) (envelope-from jpulz) Date: Sat, 19 Aug 2006 23:30:50 +0200 (CEST) From: Joerg Pulz To: Pieter de Boer In-Reply-To: <44E76B21.8000409@thedarkside.nl> Message-ID: <20060819232810.N978@hades.admin.frm2> References: <44E76B21.8000409@thedarkside.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-security@freebsd.org 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: Sat, 19 Aug 2006 21:31:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 19 Aug 2006, Pieter de Boer wrote: > Gang, > > 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: > > table { } > > block quick from to any > > pass in quick on $ext_if inet proto tcp from any to ($ext_if) port 22 > modulate state (source-track rule max-src-nodes 8 max-src-conn 8 > max-src-conn-rate 3/60 overload flush global) > > > 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: > > Aug 18 00:00:01 aberdeen sshd[87989]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:03 aberdeen sshd[88010]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:05 aberdeen sshd[88012]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:10 aberdeen sshd[88014]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:13 aberdeen sshd[88019]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:14 aberdeen sshd[88021]: Invalid user serwis from 83.19.113.122 > > > My theory was/is that this particular scanner simply multiplexes multiple > authentication attempts over a single connection. I 'used the source luke' of > OpenSSH to find support for this theory, but found the source a bit too > wealthy for my brain to find such support. > > So, my question is: Does anyone know how this particular attack works and if > there's a way to stop this? If my theory is sound and OpenSSH does not have > provisions to limit the authentication requests per TCP session, I'd find > that an inadequacy in OpenSSH, but I'm probably missing something here :) Isn't it the "MaxAuthTries" option for sshd which provides such functionality? Please look for "MaxAuthTries" in the sshd_config(5) manpage for details. regards Joerg - -- The beginning is the most important part of the work. -Plato -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE54MNSPOsGF+KA+MRAh0GAJ45v4C9+xJ5vy+4BPltXwBxpKzzIwCePWa8 o/XSdoB2tFdMXQv1Yo1rwFU= =dHjL -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Sat Aug 19 21:32:18 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 1955916A4DA for ; Sat, 19 Aug 2006 21:32:18 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B26A43D6D for ; Sat, 19 Aug 2006 21:32:05 +0000 (GMT) (envelope-from lyndon@orthanc.ca) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by orthanc.ca (8.13.4/8.13.4) with ESMTP id k7JLVwax045215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Aug 2006 15:32:02 -0600 (MDT) (envelope-from lyndon@orthanc.ca) Date: Sat, 19 Aug 2006 14:31:58 -0700 (PDT) From: Lyndon Nerenberg To: Pieter de Boer In-Reply-To: <44E76B21.8000409@thedarkside.nl> Message-ID: <20060819142846.N45201@orthanc.ca> References: <44E76B21.8000409@thedarkside.nl> Organization: The Frobozz Magic Homing Pigeon Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on orthanc.ca Cc: freebsd-security@freebsd.org 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: Sat, 19 Aug 2006 21:32:18 -0000 Take a look at /usr/ports/security/bruteforceblocker. It monitors the system log for failed ssh logins, and blocks the sites via pf. It's reasonably configurable, and works very well. I've been running it for months without trouble. Note that it lets you whitelist specific hosts to prevent against someone DOSing you by forging your IP address. --lyndon From owner-freebsd-security@FreeBSD.ORG Sat Aug 19 21:37:51 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 3349F16A4DF for ; Sat, 19 Aug 2006 21:37:51 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from virtual.micronet.sk (smtp.micronet.sk [84.16.32.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45F8B43D6E for ; Sat, 19 Aug 2006 21:37:42 +0000 (GMT) (envelope-from danger@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by virtual.micronet.sk (Postfix) with ESMTP id 9F24410E65B; Sat, 19 Aug 2006 23:37:34 +0200 (CEST) X-Virus-Scanned: by amavisd-new at virtual.micronet.sk Received: from virtual.micronet.sk ([127.0.0.1]) by localhost (virtual.micronet.sk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epd2AV8QDvc9; Sat, 19 Aug 2006 23:37:33 +0200 (CEST) Received: from danger.mcrn.sk (danger.mcrn.sk [84.16.37.254]) by virtual.micronet.sk (Postfix) with ESMTP id 0486210E610; Sat, 19 Aug 2006 23:37:33 +0200 (CEST) Date: Sat, 19 Aug 2006 23:37:30 +0200 From: Daniel Gerzo Organization: The FreeBSD Project X-Priority: 3 (Normal) Message-ID: <47517034.20060819233730@rulez.sk> To: Pieter de Boer In-Reply-To: <44E76B21.8000409@thedarkside.nl> References: <44E76B21.8000409@thedarkside.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 19 Aug 2006 21:50:19 +0000 Cc: freebsd-security@freebsd.org Subject: Re: SSH scans vs connection ratelimiting X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Gerzo List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2006 21:37:51 -0000 Hello Pieter, Saturday, August 19, 2006, 9:48:49 PM, you wrote: > Gang, > 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: > table { } > block quick from to any > pass in quick on $ext_if inet proto tcp from any to ($ext_if) port 22 > modulate state (source-track rule max-src-nodes 8 max-src-conn 8 > max-src-conn-rate 3/60 overload flush global) > 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: > Aug 18 00:00:01 aberdeen sshd[87989]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:03 aberdeen sshd[88010]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:05 aberdeen sshd[88012]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:10 aberdeen sshd[88014]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:13 aberdeen sshd[88019]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:14 aberdeen sshd[88021]: Invalid user serwis from 83.19.113.122 > My theory was/is that this particular scanner simply multiplexes > multiple authentication attempts over a single connection. I 'used the > source luke' of OpenSSH to find support for this theory, but found the > source a bit too wealthy for my brain to find such support. > So, my question is: Does anyone know how this particular attack works > and if there's a way to stop this? If my theory is sound and OpenSSH > does not have provisions to limit the authentication requests per TCP > session, I'd find that an inadequacy in OpenSSH, but I'm probably > missing something here :) try http://legonet.org/~griffin/openbsd/block_ssh_bruteforce.html or my pet project http://danger.rulez.sk/projects/bruteforceblocker/ > Regards, > Pieter -- Best regards, Daniel mailto:danger@FreeBSD.org