February 20th, 2010
One area of interest in the development of Suricata is hardware acceleration. Using the GPU is particularly interesting, as they are cheap and widely available. We’ve been looking at using the GPU to speed up pattern matching as a first step. Since OpenCL promises to be a cross platform multi vendor API for doing this we first looked at OpenCL. But we were never able to get something stable out of it, not on the NVIDIA drivers in Linux anyway. As that didn’t go anywhere we decided to use CUDA for the time being. CUDA obviously is NVIDIA only. Once we have CUDA fully running we may revisit OpenCL or look at other implementations like AMD/ATI’s stream API.
What we have so far is a implementation our 2 gram SBNDM pattern matcher algorithm in CUDA. The detection thread(s) currently send packets one by one to a central dispatcher thread that controls the GPU. This setup is far from ideal performance wise, but our first goal was to get it working at all. Currently on my desktop CUDA actually slows things down.
In the next weeks and months we plan to do some redesigning of the CUDA implementation and it’s integration into the engine. We plan to send the packets in batches to the dispatcher thread right after the decoders have determined what the payload portion of a packet is. The (separate) detection thread(s) can then process the results of the GPU when they get to a packet. By using the CUDA scanning async like this we hope that we can reduce the costs of the transfer of packets from and to the card.
Currently the code in the tree can be activated by passing the “–enable-cuda” option to ./configure. Next, in the configuration file enable the cuda pattern matcher by setting the “mpm-algo” option to “b2g_cuda”. As a first test, run the CUDA unittests (assuming you enabled the building of the unittests too) by using “suricata -uUCuda”. Please note that currently running all unittests will fail if CUDA is enabled.
The code is only tested on 32bit Linux at the moment. There are some issues with 64bit that we’re resolving right now. We’re expecting to be continuously updating this code, so be sure to work with the most current version of the git repo all the time!
Let us know your experiences!
Tags: cuda, gpu, pattern matching, Suricata
Posted in Suricata, oisf | No Comments »
February 20th, 2010
Yesterday the OISF development team released Suricata 0.8.1. This release is much improved from our December 31st release. It is way more stable, performs better and has more features. Thanks to the now included HTP library we have much better HTTP handling. The stream engine has seen massive improvements. Initial experimental CUDA code has been added. Initial Win32 support has been added. We’ve added number of missing rule keywords. Many bugs were fixed.
Personally I’m very excited about the help we have gotten from the community. Quite a few patches from community members were applied in this release. Thanks everyone!
Next week the OISF team and a number of experts are meeting up in Istanbul. We’ll be working on crunching a number of technical challenges, sharing ideas and we will start our brainstorming on future development. If you have any ideas about where you think IDS/IPS should go, please let us know so we can discuss it and possibly include it in our future plans.
Tags: cuda, htp, oisf, Suricata
Posted in IPS, Suricata, ids, oisf | No Comments »
January 4th, 2010
If you’re running into issues with Suricata, it may be worth spending some time looking at the debugging options.
To enable the debugging code, pass “–enable-debug” to configure.
./configure –enable-debug
And make & make install again. Make sure that during compilation you see -DDEBUG in the gcc commands.
Then to really enable it at runtime, pass the SC_LOG_LEVEL
SC_LOG_LEVEL=Debug
Depending on how you run the engine, this will output massive amounts of debugging info. Thats why we added a pcre regex filter option.
SC_LOG_OP_FILTER=regex
The regex currently is case sensitive. It will be matched against the full debug line. For example if you want to want to see only output related to the HTP module do something like:
SC_LOG_LEVEL=Debug SC_LOG_OP_FILTER=”htp” suricata -c suricata.yaml -r /path/to/file.pcap
Or maybe you want the stream messages as well:
SC_LOG_LEVEL=Debug SC_LOG_OP_FILTER=”(htp|stream)” suricata -c suricata.yaml -r /path/to/file.pcap
You can also control the logging format by passing the SC_LOG_FORMAT environment variable. By default it’s set to “[%i] %t – (%f:%l) <%d> (%n) — “.
The following format specifiers are available:
t timestamp
p process id (pid)
i thread id
m thread module name
d log level
f filename
l line number
n function name
Example:
SC_LOG_FORMAT=”[%i] %t – (%f:%l) <%d> (%n) — “
Putting it all together:
SC_LOG_LEVEL=Debug SC_LOG_FORMAT=”[%i] %t – (%f:%l) <%d> (%n) — ” SC_LOG_OP_FILTER=”(htp|stream)” suricata -c suricata.yaml -r /path/to/file.pcap
If you have any questions or suggestions, let me know!
Tags: debug, oisf, Suricata
Posted in Suricata, oisf | No Comments »
December 31st, 2009
Today we’ve finally released the first public version of Suricata, the Open Source IDS/IPS developed by the Open Information Security Foundation. With a team of great people we’ve been working really hard to get this ready. Please see the full announcement here.
As it’s lead developer I’m very much interested in getting feedback, bug reports and such. We run our ticket system in a redmine install at https://redmine.openinfosecfoundation.org/ If you have any feedback, please register an account and let us know what you think.
If you’re running into any issue, reconfigure and recompile the engine with –enable-unittests and –enable-debug and send us the output of “suricata -u” this will run all the unittests (1191 currently). If everything is set up properly, they should all pass. If not, please start bugging us!
Happy new year everyone!
Tags: ids, IPS, oisf, Suricata
Posted in Suricata, oisf | No Comments »
December 30th, 2009
Things here at OISF are crazy busy since we’re wrapping up our first version of the engine. Tomorrow there will be a first release! Stay tuned!
Tags: oisf, Suricata
Posted in Suricata, oisf | 1 Comment »
November 3rd, 2009
Daniele Sluijters has spend quite an effort at creating Vuurmuur rpms for Fedora 11 and CentOS 5, both 32 bit and 64 bit. The packages are available at the Vuurmuur ftp-server here: ftp://ftp.vuurmuur.org/releases/0.7/contrib/ Currently we have packages for 0.7, hopefully 0.8beta2 will follow later. Thanks Daniele!
Tags: rpm, Vuurmuur
Posted in Vuurmuur | No Comments »
November 1st, 2009
Ever since I’ve been working on the OISF engine I’ve been unable to spend much time on my Vuurmuur project. Luckily it seems development is picking up some speed again because there are some (new) people working on some improvements. Two development branches have been started in svn. The first is “nflog” which is meant for the development of support for libnetfilter_log to replace the current syslog based vuurmuur_log.
The second is called “ipv6″ and is meant for adding IPv6 support to Vuurmuur as a frontend to ip6tables. This is going to be quite an effort, but I’m excited that it got started!
Anyone interested in joining the development effort is welcome to do so. Join us at #vuurmuur on freenode.
On a side note, last week I released Vuurmuur 0.8 beta 2, exactly 6 months after beta 1. I’ll try to do the next release a little sooner!
Tags: IPv6, Vuurmuur
Posted in IPv6, Vuurmuur | No Comments »
October 31st, 2009
Today I installed a Qemu virtual machine with the ARM architecture. I think ARM is becoming an interesting architecture as smartphones and many home routers use it. I was interested in seeing if our OISF engine would compile and run properly on it. So far it seems really well. Compilation was without issue, all our current 800+ unittests ran successfully and it seems to run just fine so far. Too bad the virtual machine is so slow though…
Also, since a few weeks I have a Android based smartphone. Since it runs Linux and uses an ARM CPU I think/hope it should be able to run the engine. I hope to find some time soon to look into Android development for this…
Tags: android, arm, oisf, qemu
Posted in oisf | No Comments »
September 30th, 2009
Another quick update on the development of the OISF engine. Overall development is going great. Basics like signature keywords, stream reassembly, ip defragmentation are nearing completion. Unified1 + barnyard was already working for quite some time, but now we also have unified2 compatible output. I’ve tested this to work with barnyard2 and Sguil which works nicely.
We have the first versions of our new YAML based configuration format checked in, a brand new logging API, midstream pickup support in our Stream engine, native PFRING support and many other additions.
Next up in development is IP reputation support in the engine, support for advanced vars and more L7 modules.
The IP reputation is one of the things we have high expectation about. In working group discussions we defined 16 categories for which to keep reputation, for example: spammer, cnc, p2p, etc. We’re currently designing the datatypes for holding as much of this info in memory as possible.
The advanced vars is the idea of applying ModSecurity’s var collections to our engine. They will be like Snort’s flowbits, but then more advanced. At least 2 more types will be supported: integers and raw buffers. Integers should enable signatures to modify counters, but also compare various counters with each other.
In the L7 modules development we’re putting a big focus on HTTP (more on that later). We’re also currently working on a DCE/RPC decoder. For this work we hired Kirby Kuehl from Breaking Point. The L7 framework I’m still working on should make development of modules for new protocols fairly straightforward.
We expect to announce the name and mascot of our engine soon. Also our bylaws should also finally been done almost now, just as the consortium license. Once thats all into place, we expect to open up our code to the public quite soon. Exciting times!
Tags: engine, ModSecurity, oisf, pfring, Sguil, yaml
Posted in oisf | No Comments »
August 16th, 2009
The last month has been crazy busy. Development of the engine is progressing nicely. My own role has been assigning tasks to our coders, guiding them, reviewing their work, integrating it and of course write code. We currently have nine people coding, not all full time though, and are still looking for more coders.
Progress has been made on a number of things: we have many more decoders, threading updates, a stats subsystem, stream tracking and reassembly, a L7 protocol parser framework and many more unittests. We’re working on OpenCL hardware accelaration, although we’re running into driver issues, so that may take some time before it’s usable.
On the QA side Will Metcalf is busy setting up an automated test rig, doing daily tests runs of our unittests on various platforms and with different compiler settings and such. When that is done pcap based tests and live traffic testing is next.
We have set up a number of “working group” mailinglists that discuss different subjects such as a configuration language and a rule language. Most are still ongoing, however the configuration language discussion seems to have come to a conclusion.
For the configuration language the discussion has settled on using YAML, a structured but still nicely editable format. It has many language bindings, so I hope management tools will be built for it later.
Other discussions, such as about the ip reputation, are still ongoing. You are very welcome to share your ideas with the group.
Like stated above, we’re still looking for coders. If you are a C coder and you’re interested in working with and for us, send us your resume!
Tags: engine, oisf, william metcalf, yaml
Posted in oisf | No Comments »