July 21st, 2009
So I just got back from Washington D.C. where we had our first public meeting for the OISF. I think it went very well as there were more people than expected. The attendees came from all parts from the industry & government. Overall reception was very positive and we’ve gotten many offers for help in development & testing.
Around the public meetings we had private meetings with a number of companies and I’m very happy that three of them commited to the project already:
Endace the New Zealand based hardware acceleration company was first to commit. They are providing us with hardware and time from their coders. Naturally they will be interested in getting our code to perform as good as possible on their hardware, but they have offered to assist in the general development of the engine as well.
Breach Security is supporting us too. They are providing us with coding time of Brian Rectanus, the current developer and maintainer of ModSecurity. Given my enthusiasm about ModSecurity, no one will be surprised that I’m really excited to having Brian and Breach involved. Naturally, they are going to help us make sure our engine excels at HTTP security. More on that in a later post.
Last (for now), we’re getting support from Nitro Security. Having worked with Nitro in the past I’m really excited about this as well, especially as Nitro has an IPS interest. Of course inliniac cares a lot about IPS! 
The form of Nitro’s support is still to be determined, but it’ll likely be in the form of time from their coders.
At this point, contributions like this (coding support, QA hardware) is what we are interested in most. We’re talking to a number of other companies for setting similar partnerships. We’ll announce them as soon as we know more.
On a last note, I’d like to thank Frank Knobbe, Daniel Peck and Richard Bejtlich for attending the meeting. It was great finally meeting you guys in person and thanks for your great input. Same goes for the other people that were there, thanks a lot for coming!
We will be publishing our meeting notes soon. Stay tuned!
Tags: breach security, endace, ModSecurity, nitro security, oisf
Posted in oisf | No Comments »
June 30th, 2009
We’re doing a public OISF meeting in DC next July. Everyone thats interested, please show up! Here is the original announcement:
We'll be having a public forum and brainstorming session in Washington
DC on July 16th, 2009! This session will be a mix of technical and
political issues.
We encourage our current and potential consortium members, potential
users and resellers, as well as future end users to attend. We very much
want to hear from all in a discussion format what is most important to
you, and what you need to have in the next iteration of IDS. The
discussion on the lists has been great, but most often even better
things come to life when a lot of smart folks are in the same room at
the same time, as we've seen at our prior brainstorming sessions.
We'll be getting quite technical, but we'll also answer any and every
question about the politics, goals, and funding sources of the
foundation. We know this is a very strange situation we have, being
funded by DHS to create open source security software.
So please plan to attend, July 16th in Washington DC, at the SRI
Building in Rosslyn:
http://www.sri.com/contact/wdc.html
If you plan to or are rather sure you'll be there please drop an email
to Matt Jonkman, we need an approximate headcount for the
catering, provided courtesy of SRI.
If you can't make this one don't worry, we are planning similar meetings
through the development cycle on the west coast and in Europe. We want
to hear every idea we can get!
I’ll be there personally, as will (most of) the rest of the team be. Look forward to meeting everyone there!
Tags: oisf
Posted in oisf | No Comments »
June 30th, 2009
Next to creating a new IDS with the OISF project I’ve been busy lately assisting Digital Bond with their Quickdraw project. The purpose of the project is to create a passive network based event logger for SCADA networks. Digital Bond has now released a first beta of the project here. Check it out!
Tags: digital bond, quickdraw, scada
Posted in ids | No Comments »
May 28th, 2009
Next week I’ll be in Chicago, IL for a OISF team meeting. We’ll be discussing features, work flow, job applications, contractors, etc. I’ll probably update my blog from there on the progress. If you’re interested in OISF and/or you’re around there, please let me know. Maybe we can try to meet up!
Tags: oisf
Posted in oisf | No Comments »
May 13th, 2009
The OISF is a non profit foundation and we’ve created a bylaws document to govern it that is now up for comments. See the announcement here. It’s a draft so if you have comments about it, please speak up soon so we can see if it needs to be adjusted!
One thing that excites me a lot is that it also specifies the OSS license we’re going to use: the GPLv3.
Tags: bylaws, gplv3, oisf
Posted in oisf | No Comments »
May 13th, 2009
Funny how things go: not long ago I posted here that I was looking for (contract) work, today I’m posting that we’re looking for people to work for us at the OISF project
Anyway, have a look at Matt Jonkman’s announcement here.
If you’re interested or know someone that is, please contact us!
Tags: oisf
Posted in oisf | No Comments »
April 4th, 2009
A new version of Vuurmuur is out: 0.7. This release mainly fixes bugs and build issues. Translations are generated and installed again, lots of traffic shaping fixes were made.
Support for pmtu MSS clamping was added, as was support for NAT source port randomization.
See http://www.vuurmuur.org/trac/wiki/Changelog for all changes.
Debs for Debian and Ubuntu are available, see
http://www.vuurmuur.org/trac/wiki/InstallationDebian
The source installer and Autopackage are on the ftp server:
ftp://ftp.vuurmuur.org/releases/0.7/
Looking forward, I’m planning on improving the services handling in 0.8. Especially supporting all protocols from /etc/protocols, instead of just a small list of hardcodes ones. Check http://www.vuurmuur.org/trac/milestone/0.8 to monitor the plans and progress on the 0.8 release. Suggestions & help are welcome!
Update November 3rd: RPMS are available as well: ftp://ftp.vuurmuur.org/releases/0.7/contrib/
Tags: Vuurmuur
Posted in Vuurmuur | 3 Comments »
March 31st, 2009
The next stable version of Vuurmuur, 0.7, is getting close. Last week I released release candidate 3. If you’re a Vuurmuur user, please try 0.7rc3 and report back to me on how it works! For a list of changes, please see the closed tickets. Thanks!
Tags: Vuurmuur
Posted in Vuurmuur | No Comments »
March 31st, 2009
I’ve been thinking about how to deal with streams in the OISF engine. We need to do stream reassembly to be able to handle spliced sessions, otherwise it would be very easy to evade detection. Snort traditionally used an approach of inspecting the packets individually and reassembling (part of) the stream in a pseudo packet, that was inspected mostly like a normal packet. Recent Snort versions, especially when Stream5 was introduced, have a so called stream api. This enables detection modules to control the reassembly better.
In Snort_inline’s Stream4 I’ve been experimenting with ways to improve stream reassembly in an inline setup. The problem with Snort’s pseudo packet scanning way of operation is that it’s after the fact scanning. Which means that any threat detected in the reassembled stream can’t be dropped anymore. The way I tried to work around this was by constantly scanning a sliding window of reassembled unacked data. It worked quite well, except for the performance of it. That was quite bad.
I’m thinking about a stream reassembler for the OISF engine that can both do the after-the-fact pseudo packet scanning and do a sliding window approach as I did in stream4inline. This would be used for the normal tcp signatures. I think it should be possible to determine the minimal size of the reassembled packet based on the signatures per port, possibly more fine grained. Of course things like target based reassembly and robust reassembly will be part of it.
In addition to this I’m thinking about a way to make modules act on the stream similary to how programs deal with sockets. Code that only wakes up if a new piece of data in that connection is received, with semantics similar to recv()/read(). I haven’t really made up my mind about how such an api should work exactly, but I think it would be very useful to detection module writers if they only have to care about handling the next chunk of data.
I haven’t implemented any of this yet, but I plan to start working on this soon. I’ll start with simple TCP state tracking that I’m planning to build on top of the flow handling already implemented. I’ll blog about this as I go…
Tags: engine, oisf, prototype, stream reassembly, TCP
Posted in TCP, oisf | No Comments »