From owner-freebsd-security@FreeBSD.ORG Thu Feb 26 08:35:39 2004 Return-Path: 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 442E516A4CE for ; Thu, 26 Feb 2004 08:35:39 -0800 (PST) Received: from mail.secureworks.net (mail.secureworks.net [209.101.212.155]) by mx1.FreeBSD.org (Postfix) with SMTP id AEFBD43D2D for ; Thu, 26 Feb 2004 08:35:38 -0800 (PST) (envelope-from mdg@secureworks.net) Received: (qmail 12876 invoked from network); 26 Feb 2004 16:32:36 -0000 Received: from unknown (HELO HOST-192-168-8-243.internal.secureworks.net) (63.239.86.253) by mail.secureworks.net with SMTP; 26 Feb 2004 16:32:36 -0000 Date: Thu, 26 Feb 2004 11:35:37 -0500 (EST) From: Matthew George X-X-Sender: mdg@localhost To: Dorin H In-Reply-To: <20040226040210.25663.qmail@web12609.mail.yahoo.com> Message-ID: <20040226112647.A28880@localhost> References: <20040226040210.25663.qmail@web12609.mail.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-security@freebsd.org Subject: Re: improve ipfw rules X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 16:35:39 -0000 On Wed, 25 Feb 2004, Dorin H wrote: > > Snort http plugin does "application-level" stream > analysis, AFAIK. Why you could not design a similar > plugin, or just some well written rules ? (just 2c)Use > snortsam to alert the firewall (FBSD ipf for example) > to block the traffic, and keep the fw free of stateful > traffic analysis as much as possible. For the sake of > performance. > BTW, does anyone know if snortsam work with ipfw? > /Dorin. > there were patches released some time ago that abstracted packet acquisition so that you could put snort inline via divert (or netfilter in linux), so you could block the first packet and not have to inject firewall rules. as far as the application-level stream analysis, what I was referring to was something that would be smart enough to detect, for example, services running on non-standard ports based on the application protocol they are using, then filter based on the appropriate rules for that service. You can write snort rules for specific ports, but it would be better to have an HTTP set that gets applied once it has been identified that HTTP is the protocol in question. The same can then be used to do p2p or any other application filtering. -- Matthew George SecureWorks Technical Operations 404.327.6339