William Metcalf has finally released the new Snort_inline version we have been working on so hard, the first release of our code against Snort 2.6. The last release was in June 2006.
Of course, we continue to lag behind SourceFire, as they just released 2.7.0 BETA 1, but I have good hope that we will be able to keep up a little bit better the following time!
Anyway, get the release from the SourceForge download section!
ModSecurity 2 has been out for a while now, and although I have played with it some, I never found some time to upgrade my own servers. The upgrading generally went quite smooth, even though ModSecurity 2 changed quite a bit.
First of all there are now 5 phases where you can filter. Actually, one of them only applies to the logging, so you can filter in 4 phases. The phases are headers and body for both request and response traffic. Filtering on specific URIs can be done in phase 1 (request headers), while inspecting a POST payload requires phase 2 (request body).
Next, some shortcuts where removed. In 1.9.4 there was a variable called POST_PAYLOAD, that enabled the user to match against payloads from POST requests easily. Now there is REQUEST_BODY, but since that can be part of non-POST requests as well, you have to use:
SecRule REQUEST_METHOD “POST” chain
SecRule REQUEST_BODY “evil”
instead of:
SecFilterSelective POST_PAYLOAD “evil”
One other change is visible above already. The keyword to create a rule has been changed from SecFilterSelective to SecRule. Many rules can be converted by just replacing the keyword, but certainly not all. A simple find/replace should not be done without a manual review!
I use a number of custom rules to protect certain parts of my server, so I needed to convert my rules. For most of them it was simply enough to replace SecFilterSelective with SecRule. For a few I had to replace the OUTPUT_STATUS variable with the RESPONSE_STATUS variable, as it is called now.
For one rule however, I had quite some problems to get it running correctly. This was the rule in 1.9.4 syntax:
# block wp-login.php
SecFilterSelective REMOTE_ADDR “!10.1.1.1” chain
SecFilterSelective REQUEST_URI “/wp-login.php”
log,deny,redirect:http://www.inliniac.net/nologin.html
This rule makes sure only 10.1.1.1 can open the login page, everyone else is redirected to a simple html page containing a ‘Access Denied – Logins disabled’ message. I converted it to the following:
SecRule REMOTE_ADDR “!10.1.1.1” chain
SecRule REQUEST_URI “/wp-login.php”
log,deny,redirect:http://www.inliniac.net/nologin.html
Guess what? It didn’t work. I’ve spend quite some time trying all kinds of variations of the rule, and finally I found out what the issue is. In 1.9.4 the rule actions, like deny, redirect etc could be in the final rule of a series of chained rules. With 2.0.4 this doesn’t work correctly. So when I changed the rules to the following, it worked:
# block wp-login.php
SecRule REMOTE_ADDR “!10.1.1.1” “chain,phase:1,log,deny,redirect:http://www.inliniac.net/nologin.html”
SecRule REQUEST_URI “/wp-login.php$”
I haven’t looked into this further to find out whether this is a bug or a feature.
The last thing that was interesting is the modsec2sguil script. There have been some changes to the alert files. So expect a new version of the script soon!
With the recent Snort vulnerabilities we had to make a choice if we would backport the fixes to our Snort_inline 2.6.0.2 patch or that we would upgrade to 2.6.1.2. Upgrading makes most sense since SourceFire improves Snort with every release, but since the upgrade process has been very painful the last couple of releases, we weren’t really looking forward to it.
Earlier I wrote about my testing with Subversion for Snort_inline, and I found out that using Subversion made the upgrade procedure much easier and much less time consuming. So upgrading it was. Generally there were little changes to the Snort_inline patch required.
One thing however, messed up the way the new stream4inline code works. A new option in Snort’s Stream4, which is enabled by default, is session dropping. The way it works is that when a packet is dropped, the session it belongs to is instructed to drop every packet from that session from that time on.
This makes sense in many cases, but not in all. In stream4inline, we have created options to drop out-of-order packets, out-of-window packets, bad reset packets, and more. Generally, in these cases we want just drop those individual packets, not kill off the session.
Especially killing the session on bad reset packets would be making it easier to kill sessions by third parties. One might argue that sessions writing outside of the window can be killed, but when looking at the out-of-order limits, this can’t be done.
The out-of-order limits are enforced not because it is bad traffic, but to prevent resource starvation attacks against Snort_inline’s stream reassebler. Out-of-order packets will have to be put in the right order before processing, taking CPU time. Also, they have to be queue’d so re-order, taking memory.
By setting out-of-order limits, the burden of getting the stream in order is on the sender of the packets. He will have to retransmit the right packets first, before sending more out-of-order packets. In this case, we don’t want InlineDrop() to kill the entire session. To deal with this, we introduced InlineDropPacketOnly(), that just drops the packet.
A official beta should be out RealSoonNow(tm) 😉
A reason for the slow development of Snort_inline is that we still weren’t using a version control system. Being sick of this, I decided to setup a private Subversion server to see how we could best use it. One thing that complicates the use of such a system is the fact that we maintain a patch on top of source code not maintained by ourselves. So the system must be able to deal with upstream sourcecode updates.
In the excellent book Practical Subversion, Garrett Rooney suggests the use of so called vendor branches. In this setup the vanilla sources of the upstream Snort would be in the svn repository as well. I’ve decided to experiment with this, and this is how I found it to work.
There are two branches in the svn:
vendor/
trunk/
In vendor, the vanilla source is imported, with tags to the specific releases. So for Snort you will have:
vendor/current
vendor/2.6.0.2
The trunk is first initialized as a copy of vendor/current, after which the Snort_inline specific code is added to the trunk. All modifications to our Snort_inline patch will be done in trunk/.
Where this approach shines is when there is a new upstream version. The procedure is this:
For going to 2.6.1.2, this also meant removing a few files. After this, you have:
vendor/current
vendor/2.6.0.2
vendor/2.6.1.2
After this, checkout the trunk, and do a merge of the two vanilla trees (2.6.0.2 and 2.6.1.2) into the trunk. This will update our Snort_inline code with the new ‘vendor’ version. This will create a number of conflicts that will have to be resolved manually (because of our changes in Snort_inline), but resolving this turns out to be a lot simpler and less time comsuming than our old method of just copy-pasting the Snort_inline code into the new Snort release.
Anyway, since Will and I were happy about this approach, we have decided to move to the SourceForge.net SVN server, which now contains a trunk with Snort_inline code, soon to be released as Snort_inline 2.6.1.2 BETA 1. But don’t wait for us, you can also checkout your own copy from:
https://snort-inline.svn.sourceforge.net/svnroot/snort-inline/trunk/
Check it out! 🙂
This is my first blog post in 2007, so let me start by wishing everyone a good and healthy new year. In the new year I finally released a new version of Vuurmuur. It was the longest period between two releases, the last one was in April 06. The last year has been pretty hectic, with my graduation, looking for work, and now working… Also I’ve been stepping up work on Snort_inline and Modsec2sguil, which all took away coding time from Vuurmuur.
Of course, just after the new release came out, I discovered some problems with the connection killing functionality, and a new alpha release partly fixing that is already out. Partly, since I have yet some fixes to make. The release got a fair amount of publicity since it was mentioned on the Dutch computer enthousiast site tweakers.net. The server that hosts the wiki (and the screenshots) nearly colapsed under the requests, but luckily I could adapts it’s config in time to bring the load down from 18 to 2.
Looking ahead, I intent to get a new release out fairly quickly, hopefully even this month. The focus of this release will be fixing the bugs from 0.5.72. Looking further ahead main focus will be the setup wizard, that should help new users to get going quickly. Adi is working on an updated autobuild server that can also support the newer versions of Debian and Ubuntu. He will also be looking at adding support for rpm-building.
I’m also thinking about modifying the iptables rules that Vuurmuur creates, to better handle traffic marking, add support for the classify target and support nfqueue. But it will be a while before work on that will start…
Inliniac 