I’m back from my vacation which was very nice. Hardly did any geek stuff, other than meeting up with Philippe, who lives in Paris. It was the first time I met someone I got to know through the Vuurmuur project :)
So with Snort_inline things aren’t moving as fast as I hoped, but there is certainly progress. I’m currently hunting for a few bugs. First of all I’ve seen it segfault on me once. Sadly I had forgotten to enable coredumps, so no clue as of why. Second, William and I have been ironing out some issues where the new stream4 mode was getting mixed up with the old. I think these are pretty much taken care of now. Third, there is a bug where an unified alert fired by http_inspect doesn’t contain a payload. Finally, i’m hunting what appears to be a heisenbug in the new stream reassembly, because I’ve never encountered it since I’m actually looking for it.
Still it has been running on my gateway with good stability and performance for a few weeks now. So I think that if we can find the http_inspect issue, we should be ready for a beta release…
Since I was very busy this summer with finishing my Master thesis I still owed my girlfriend a vacation. Tomorrow we are leaving for a week of vacation in Paris…
Yesterday the talks between me and my employer of the last five years broke down in disagreement. The company where I have been working as a part-time Sytem Admin for the last five years next to my study, offered me a job in their webdevelopment team. It wasn’t security related, but it sounded interesting enough since I would mostly work on the backend where connections with databases and third parties would be handled. Anyway, the talks broke down so I’m now looking for work.
My work experience in the IT field consists of the two jobs I currently (still) have. The first is as a part-time System Admin in a very competetive company operating in the travel market. It is a mostly Windows environment, with more than fifty workstations and about fifteen servers. Here I have done all administration for about three years, after which I got someone to support me. From that moment I have been working on the more difficult issues, planning new projects and preparing work for my co-worker.
The other job is a part-time position at a small IT Consultancy company. Here my main focus was on setting up and administration of Linux firewalls, email servers and database servers, as well as some limited development work. Next to this I was involved in supporting the consultant in thinking through advices to customers on a broad range of issues.
I just graduated in August, and hold a Masters degree in a non-IT related field.
I’m especially interested in security work of course, since that has been my passion for the last couple of years. I have been working on a Firewall project, an IPS project and a NSM project. My programming skills are mostly C, but also Perl, Bash and to a lesser degree C#. This experience ranges between socket programming, complex data structures, GUI programming and performance critical programming. I know a lot about Firewalls, IDS’ and IPS’ and TCP/IP in general.
So, if you know of any interesting security project, tell me! ;-)
Since William and I are working on Snort Inline 220.127.116.11 this weekend we also have a working ClamAV for 18.104.22.168. So I took a few minutes to patch it against Snort 22.214.171.124 as well. Nothing changed in it, it is just a port to 126.96.36.199.
I’ve just release a new version of modsec2sguil, the set of Perl scripts that feeds ModSecurity alerts to Sguil. No new features, but many changes ‘under the hood’. I’ve created two modules, ModsecAlert and SguilBarnyardComms. These can be used in a Object Oriented way to parse ModSecurity events and communitcate a Sguil sensor agent.
It would be interesting to see if the SguilBarnyardComms module could be connected with the work of Jason Brevnik of SourceFire, who wrote a Barnyard replacement in Perl. If I have some spare time, I will have a look at this.
After this release, I want to look at bypassing the sensor_agent altogether and instead connect directly to the Sguil server. Bamm Visscher has plans to redesign parts of the agent – server communications. In the new ideas Sguil moves away from the one monolithic sensor_agent. Instead, different tasks will have their own agent which connects directly to the sguil server. For example a sancp sensor, a snort sensor, a pcap sensor, etc. Next, a number of the same sensors would be able to share a common id, called network id. This way the user can ask a transcript for an alert produced by a modsec sensor. It is my intention to create a Perl module or library that will make creating new agents for this setup easy.
Anyway, thats the future, modsec2sguil 0.6 is ready for your testing right now! Let me know how it works for you!
Download it here: http://www.inliniac.net/files/modsec2sguil-0.6.tar.gz
No, it’s not released. But it wil be soon… really!
William has done most of the hard work of porting our Snort_inline patch from 2.4.5 to 2.6. I have mostly been working on improving the stream4inline modification. I have written about this before. Like the stream4inline modification in Snort_inline 2.4.5 it scans the stream in a sliding window, making it possible to drop an attack detected in the reassembled stream. The new code does the same but is much faster, at the cost of higher memory usage.
Another interesting feature is that it keeps track of the number of sequence holes there are in a stream, and it can force a stream to get back in order. This limit can be enforced by the number of out-of-order packets and bytes, and also by the number of simultanious sequence number holes. Inspired by the paper by Sarang Dharmapurikar and Vern Paxson.
Last but not least it adds support for window scaling to stream4. Since window scaling adds the possibility to have window sizes of up a gigabyte, I’ve added a normalizing function as well, that can force all streams to use a configurable maximum wscale setting.
But it is running on my gateway now, which is also the gateway leading to this blog, so if it is unavailable to you, you’ve hit a bug ;-)
In Vuurmuur 0.5.72 alpha 1, I introduced a connection management interface to the connection viewer, allowing the administrator to kill connections and add ipaddresses to the blocklist. Next, I’m working on doing about the same for the logviewer. The idea is to have a menu with options for each individual logline. I can think of a large number of interesting options, but I think the best would be an option like ‘create a rule based on this logline’. This would then open a prefilled rule window based on the values in the log. This option would make it very easy to get going with a new Vuurmuur setup.
Other options I can think of are:
- create a host based on the logline
- create a service
- append a portrange to a service
- add a host to a group
- change new connection limit
For now I will first focus on getting the same options as with the connection viewer. When that is done I will probably release it as 0.5.72 alpha 3. For alpha 4 I will extend the number of options.
I would be very interested in hearing more ideas for the connection and log options. If you are missing something in the list above, please add a comment!