From owner-freebsd-ipfw@FreeBSD.ORG Sun Apr 30 18:11:42 2006 Return-Path: X-Original-To: ipfw@freebsd.org Delivered-To: freebsd-ipfw@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC2AD16A400 for ; Sun, 30 Apr 2006 18:11:42 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (vrrp.freebsdbrasil.com.br [200.210.70.30]) by mx1.FreeBSD.org (Postfix) with SMTP id 28B0F43D46 for ; Sun, 30 Apr 2006 18:11:40 +0000 (GMT) (envelope-from eksffa@freebsdbrasil.com.br) Received: (qmail 17952 invoked by uid 0); 30 Apr 2006 15:12:39 -0300 Received: from eksffa@freebsdbrasil.com.br by capeta.freebsdbrasil.com.br by uid 82 with qmail-scanner-1.22 (spamassassin: 2.64. Clear:RC:1(201.17.231.143):. Processed in 0.472449 secs); 30 Apr 2006 18:12:39 -0000 Received: from unknown (HELO ?10.69.69.69?) (201.17.231.143) by capeta.freebsdbrasil.com.br with SMTP; 30 Apr 2006 15:12:39 -0300 Message-ID: <4454FDD2.9060201@freebsdbrasil.com.br> Date: Sun, 30 Apr 2006 15:11:30 -0300 From: Patrick Tracanelli Organization: FreeBSD Brasil LTDA User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051013 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paolo Pisati References: <44526C7C.10208@bonddesk.com> <20060430165656.GA49262@tin.it> In-Reply-To: <20060430165656.GA49262@tin.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Corey Smith , ipfw@freebsd.org Subject: Re: IPTABLES to IPFW for Packet Inspection Filtering X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2006 18:11:42 -0000 Paolo Pisati wrote: > On Fri, Apr 28, 2006 at 03:26:52PM -0400, Corey Smith wrote: > >>Daniel Walker wrote: >> >>>IPTABLES allows for string matching. IPFW does not. I'll >>>have to fire up my Ubuntu to do this. >>> >> >>This has been brought up before on this list. IPFW does not intend on >>ever supporting string matching as a standard feature. The developers >>feel that this kind of expensive operation does not belong in the kernel >>with IPFW. >> >>This does not mean that this functionality is impossible to do with >>IPFW/freebsd. >> >>AFAIK String match deny processing should be done using divert(4) >>sockets like natd. You use IPFW to divert outgoing DNS requests to your >>natd-like (userland) process. This process determines whether or not it >>contains your string and blocks the request/response if it does. >> >>Unfortunately I'm not aware of a userland app that does this today. > > > maybe this functionality could be developed entirely as > a libalias module, in that case it will work out of the box > for user and kernel land code linked against libalias: > > natd, ppp, ipfw and ng_nat. > > The only drawback is that such functionality doesn't belong > to libalias at all, so as long as we don't want to turn it > into something different, it's not going to happen... > I use this funcionality with two different approaches, snortsam and snort_inline. Both work fine for dropping packets. But with none I can do classification (say, sending those traffic to a dummynet queue/pipe or an altq queue rule with ipfw). A solution with this capabilities would be very good. Today we have such solutions with Cisco routers and netfilter, but no BSD-based approach, it is needed every day, specially a way to send packets based on l7 to dummynet. An approach similar to ng_nat would be nice, but could it send packets to dummynet/altq? My feel is that the matching string should be known by ipfirewall(4) rule body to make it flexible enought and send it wherever the user may need (divert, tee, dummynet, altq, skipto, etc). Hope it can be done based on userland processing. -- Patrick Tracanelli