Application layer classifier for ipfw

[Ermal Luçi]

On Fri, Aug 1, 2008 at 12:21 PM, Mike Makonnen <mtm at wubethiopia.com> wrote:
> Ermal Luçi wrote:
>>>
>>> Hi,
>>>
>>> An Internet Cafe I do some work for was recently having problems with
>>> very slow internet access. It turns out customers were running P2P file
>>> sharing applications which were hogging all the bandwidth. I looked for
>>>  programs that would allow me to shape traffic according to the
>>> application layer protocol, but couldn't find any for FreeBSD. I found a
>>> couple: l7-filter and ipp2p, but these are Linux specific. So, I decided
>>> to write one. The result is ipfw-classifyd :
>>> http://people.freebsd.org/~mtm/ipfw-classifyd.tar.bz2
>>>
>>> As the name implies it uses ipfw(4) to implement a userland daemon that
>>> classifies TCP and UDP packets according to regular expression patterns
>>> for various protocols. It's intended to be used with divert(4) sockets
>>> and dummynet(4) so you can do traffic shaping depending on the
>>> application level protocol. The protocol patterns are from the l7-filter
>>> project.
>>>
>>> Basically, you use ipfw(8) to divert tcp/udp packets to the damon. It
>>> reads its configuration file for a list of protocols and ipfw(8) rules.
>>> Then, when it detects a matching session it re-injects the packet back
>>> at the specified rule number. The tarball has a sample configuration
>>> file and firewall script to get you started.
>>>
>>> While I have not done extensive testing, preliminary tests are
>>> encouraging and it seems to work, so I thought I'd announce it to the
>>> rest of the world in case anyone else is interested in this kind of
>>> application.
>>>
>>> Comments and suggestions highly appreciated.
>>>
>>
>> Thanks for this.
>> I have a question, you remove a flow from if you see a FIN for the TCP
>> case and only on overlapping flow for either TCP/UDP how do the other
>> flows expire i am missing that part?
>>
>>
>
> No, you're not missing anything.  It's on my TODO list. I wanted to get
> this out and get feedback as early as possible, so I released it as soon as
> I had it basically working.  I'm thinking of storing some session
> information
> for the flow (like a timestamp for the last packet seen) and implementing
> a garbage collector thread that removes sessions that have been idle for
> some period of time.
>

BTW, why not make it a port?!
-- 
Ermal