Application layer classifier for ipfw

[Patrick Tracanelli]

Julian Elischer escreveu:
> Patrick Tracanelli wrote:
>> Mike Makonnen escreveu:
>>> 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.
>>>
>>> Cheers.
>>
>> Wont compile on RELENG_6 but is working perfectly on REL_7. I am 
>> trying hard with ssh, soulseek and msn. Its working like a charm with 
>> the suggested rc.firewall.
>>
>> I have configured ipfw-classfyd.conf changing the rules, for a number 
>> of L7 patterns, and now I try to understand why the "diverted" rules 
>> only match if the rule number is 1 after the configured, ie, I put 
>> soulseek to 65530 and a rule wont match there, but the very same rule 
>> matches 65531. I will read the code, but it seems that reinjection of 
>> the packet is made +1, correct?
> 
> 
> yes,
> the idea is:
> If you get the sockaddr for the received packet, and use it unmodified 
> when reinjecting the packet,
> then it will continue on at the next rule.
> so since the rule number is "unchanged" we need to add 1 to it
> to say where to start from..
> 
> hope that helps..

Perfect. Thanks.

To let you know of my current (real world) tests:

- Wireless Internet Provider 1:
	- 4Mbit/s of Internet Traffic
	- Classifying default protocols + soulseek + ssh
	- Classifying 100Mbit/s of dump over ssh

Results in:
	No latency added, very low CPU usage, no packets dropping.

- Wireless ISP 2:
	- 21 Mbit/s of Internet Traffic
	- Classifying default protocols + soulseek + ssh

Results in:
	No tcp or udp traffic at all; everything that gets diverted never comes 
out of the divert socket, and ipfw-classifyd logs

Aug  1 12:07:35 ourofino last message repeated 58 times
Aug  1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: bittorrent 
(rule 50000)
Aug  1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: edonkey 
(rule 50000)
Aug  1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: fasttrack 
(rule 50000)
Aug  1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: gnutella 
(rule 1000)
Aug  1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: soulseek 
(rule 50000)
Aug  1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: ssh   (rule 50000)
Aug  1 12:18:28 ourofino ipfw-classifyd: unable to write to divert 
socket: Operation not permitted
Aug  1 12:18:50 ourofino last message repeated 90 times
Aug  1 12:18:51 ourofino ipfw-classifyd: packet dropped: input queue full
Aug  1 12:19:11 ourofino last message repeated 94 times

Raised queue len a lot (up to 40960), when the application starts it 
uses up to 25% CPU and a second after that, CPU usage gets lower the 0.1%.

So far, this is what I have in real world enviroments.

-- 
Patrick Tracanelli