[Snort-devel] Re: FFPF with Snort

Willem de Bruijn wdebruij at ...323...
Fri Feb 25 05:59:46 EST 2005


On Wednesday 23 February 2005 08:51, you wrote:
> I'm quite interested in this project as well. Has there been any further
> development since your initial prototype?

we're certainly still working on it. I'm doing maintenance work now and then, 
as I'm officially working on other projects. At the moment I'm trying to get 
a version out the door with some bugfixes, and AMD64 port and a new front-end 
(SDK+CmdLine UI).

More interesting is the work others are doing. Occasionally we get students 
looking for cool projects or a chance to hire a developer. Right now one 
person is porting FFPF to the Intel IXP2X00 line of network processors, one's 
building a graphical user interface and a third is writing P2P blockers as 
kernelspace filters. Concurrently, a PhD in Leiden is working on the FPL3 
compiled language filters. And a programmer recently finished writing a 
better input language. 

My job is basically to tie the loose ends together after they've finished with 
the interesting stuff ;-)

> If you do manage to find the version of that paper with your results in
> it, I'd appreciate it if you could forward it on to me too.

attached you can find the figures that used to be in the paper. I'm afraid the 
CVS server the paper used to be in is no more, but I managed to fetch these 
from the trash. One's related to snort, the other to tcpdump. Both tests 
suffered from relatively high variability in results, that's why I dropped 
them from the paper. I'll talk you through the examples

What we did with snort was comparing a vanilla snort doing string matching 
with a version that was hooked up to FFPF through pcap, where an FFPF filter 
in the kernel did the string matching. In this case snort did no filtering at 
all, just reporting. In FFPF, the filter implementation was based on 
boyer-moore-horspool, as is Snort's single string matcher, I believe. 

We measured system load using `top -b`, which was a bad decision, leading to 
high result variance, as explained. But what the results do show is that we 
managed to flood regular snort easily, while flooding snort using kernelspace 
filtering didn't happen at all, I'm not sure what caused the spikes in the 
vanilla-snort graph, by the way. Attack percentages of 100% are somewhat 
academic. But circumventing the memory copies incurred even to non-malicious 
packets under normal setup is advantageous, ofcourse.

The righthand chart is a bit pointless, basically it shows again that we reach 
100% CPUtime with vanilla-snort. The only interesting bit is that snort 
already fails to receive packets in userspace before that, while a memory 
mapped solution will continue to work at full speed until the kernel starves.
The tcpdump example shows roughly the same, but scales more linearly with 
load.

Note that all of this was 1 application versus 1 applications. Real gains 
occur when you want to run multiple tasks simultaneously, as shown in our 
OSDI paper.

What's lacking at the moment is an easy way for snort to setup filters in FFPF 
in the kernel. That's why we set-up snort+ffpf manually for our tests. I 
don't know enough about snort to know exactly how to implement it, but from 
the FFPF side of things I can say that we're working on supplying a better 
client-side API than we have today. For one, we need this ourselves for the 
student working on the GUI, as he's not enough knowledge of kernelspace 
programming.

There's no real coding involved, as the new API will be simply a wrapper 
around existing calls that go deeper into the framework. I'll have a 
preliminary version ready at the end of the week. Basically, I'm thinking on 
making something related to libpcap, but more expressive, as the current pcap 
API is too limited for full FFPF support.

> Is your prototype code available anywhere? I'd be interested in taking a
> look at it. The company I'm working for (Sensory Networks, as per my
> address) is currently researching methods to make Snort go faster, and
> eliminating bottle-necks like this sounds like it could be a big win.

We have FFPF code available through our project website at 
ffpf.sourceforge.net, in tarball and CVS versions. At the moment I suggest 
checking out the CVS version as it contains some minor patches. The main 
branch is stabilized, the scanner branch is more cutting-edge.

> Thanks,

your absolutely welcome, James. As most of the scientific research is done the 
project is officially over for us, but we feel that it would be a waste to 
leave it at this near-usable state. Therefore we're actively trying to get 
developers and network admins interested, so that others can continue working 
on it. Embedding FFPF in the snort community would certainly be a great 
future for it, I feel. 

Thus, if you have more questions, just ask.

By the way, I've looked at your company's website. It seems like your doing 
interesting development yourselves. As your cards have dedicated stream logic 
I think you might want to look at the work of Mihai, one of our PhD students, 
as well. He's working on compilers for packet filtering. Right now we have an 
IXP1200 back-end, but he told me that he's working on an FPGA back-end for 
content matching as well. His latest paper, which 'll be presented at IFIP 
Networking'05, is online at ffpf.sourceforge.net, under publications.

cheers,

Willem



 




-------------- next part --------------
A non-text attachment was scrubbed...
Name: systemload.pdf
Type: application/pdf
Size: 109502 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20050225/67bcea33/attachment.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: snort.pdf
Type: application/pdf
Size: 91584 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20050225/67bcea33/attachment-0001.pdf>


More information about the Snort-devel mailing list