ipfw-classifyd

ipfw-classifyd is an userland application for FreeBSD, capable of tagging traffic flows by their layer7 protocol. It uses application patterns in order to identify the application protocol. Ermal Luçi has done a great job in improving the original ipfw-classifyd and, thanks to its efforts, it is now compatible with pf. In order for it to receive the traffic flows, the flows are diverted to the application by using divert sockets.

The configuration file for ipfw-classifyd is very straight forward and is capable of using queues defined in the pf configuration. The pf present in pfSense 2.0 Alpha is also capable of using dummynet, once again thanks to the efforts of Ermal Luçi. As a consequence, ipfw-classifyd is capable of using pipes and queues from dummynet, queues from AltQ and actions from pf itself.

In order to divert traffic from pf, one has to write the following rule:

pass in on $int from any to any divert $divertport keep state(max-packets 5)

It’s just an example rule and keep state can have different options. One option that seems to be very important is “max-packets 5″. This is necessary in order to limit the overhead of the kernel to userland switch.

The syntax for ipfw-classifyd configuration can be seen in the above example:

$protocol1 = dnpipe 20
$protocol2 = dnqueue 30
$protocol3 = queue $queue_name
$protocol4 = action pass|block

The syntax is pretty simple. Let’s take a closer look at it. If $protocol1 is detected, than the ip flow will be assigned to the dummynet pipe 20. This can be usefull, for example, to limit the available bandwith for $protocol1. If $protocol5 is detected, we can allow the traffic to pass as it is or, we can decide to block the traffic. You can imagine the possibilities of such configuration: (i) port hoping will stop being a problem since the flow will be identified not by port but by application protocol; (ii) you can define a network where only certain protocols are allowed, no matter what port (for example, a network where you only authorize http traffic); (iii) block p2p traffic or any other unwanted traffic. These are only some examples, the possibilities are enormous.

Now, the next step will be to test ipfw-classifyd and report the results. Being an userland application we will have to see if it works well under heavy load. To do so, we will setup a simple ruleset and see how it behaves. I will post back our findings and configurations soon!

About these ads

2 Responses to ipfw-classifyd

  1. 鳥毅 says:

    Why you do not use pf? IMHO, pf is better than ipfw.
    Maybe you need to keep backward compatibility.

    Thank you very much for your efforts.

  2. Helder Pereira says:

    We actually use pf! The name ipfw-classifyd comes from the time when ipfw-classifyd only worked with ipfw. Ermal Luçi did the necessary changes not only to ipfw-classifyd but also to pf to integrate them. The new pf already as divert capabilities wich allows us to use ipfw-classifyd with it. So the simple answer is, we use pf, not ipfw.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: