Date: Sun, 30 Apr 2006 15:11:30 -0300 From: Patrick Tracanelli <eksffa@freebsdbrasil.com.br> To: Paolo Pisati <p.pisati@oltrelinux.com> Cc: Corey Smith <csmith@bonddesk.com>, ipfw@freebsd.org Subject: Re: IPTABLES to IPFW for Packet Inspection Filtering Message-ID: <4454FDD2.9060201@freebsdbrasil.com.br> In-Reply-To: <20060430165656.GA49262@tin.it> References: <OFBD7BBE12.3AD0268B-ON8525715E.005548F1-8525715E.00561E4E@zbi.com> <44526C7C.10208@bonddesk.com> <20060430165656.GA49262@tin.it>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4454FDD2.9060201>