Inliniac

Last week there was some discussion in the #snort IRC channel about why Debian distributes such an ancient version of Snort, namely version 2.3.3. This release is more than 2 years old and no longer supported by SourceFire. The snort.org website says about the old versions:

You should not use these unless you really know what you are doing. Many bugs may have been fixed, including remote vulnerabilities

Even though Debian is able to fix any security bugs themselves, and they don’t need to rely on SourceFire for this, Snort 2.3.3 is still going to be inferior to the recent 2.6.1.5. Why? Well recent Snort versions have many more and improved detection options, such as a better pattern matcher, defragmentation preprocessor, improved stream preprocessor, smtp plugin, etc, etc.

So why is Debian not updating Snort? The answer can be found in the Debian bugtracker. Snort is released under the GPL and up to and including version 2.3.3 included a ruleset. But since then only Snort itself is distributed under the GPL, the (VRT) rules are now under a less free license. Of course the user can get them for free, but with a 30 day delay and only after registering with SourceFire. Big deal, I would say, just remove the rules from the package and put some doc describing how to get rules. But the Debian maintainer doesn’t like this idea:

“Consequently, upgrading to 2.4 would mean providing just an IDS engine, not an IDS “service”.” (source)

I think this reasoning makes no sense, for a number of reasons:

1. Snort can be useful even without any rules: it can detect anomalies in stream tracking, dns, ftp, http, smtp. It can provide statistics, capture traffic.
2. Managing the Snort rules through the very static Debian packages system make no sense in the first place. Many of the rules change weekly or even daily. Debian would never update the package for this. Oinkmaster should be used for this, and Debian provides this tool as well.
3. People can write their own rules.
4. There still are many free rules available. The Snort community rules are GPL licensed, Bleeding rules are BSD licensed. Together they have thousands of rules.

So Debian, please make your Snort package usable again, and update it to the latest stable version! And while you are at it, provide an inline enabled package as well

SourceFire just released Snort 2.6.1.5 so I have updated our patch to that. You can get it by checking out SVN with the following command:

svn co https://snort-inline.svn.sourceforge.net/svnroot/snort-inline/trunk

Check it out!

Every few weeks the same question comes up: what is the difference between Snort in inline mode and Snort_inline. This makes sense, because the Snort_inline documentation and website fail to explain it. In this post I will try to highlight the main differences. In general I can say that we try to develop Snort_inline as a patchset on top of Snort. Snort_inline is focused at improving the inline part of Snort. Originally of course, Snort’s inline capabilities were developed in the Snort_inline project. With Snort 2.3.0RC1 they were merged into mainline Snort.

Convenience

We did a number of things to make Snort_inline a little more convenient for inline users.

• inline is enabled by default in ./configure
• we got rid of libnet 1.0.2a, switched to libdnet 1.1 instead
• a snort_inline specific manual page was added, as well as some extra docs
• a example configuration file for inline use is supplied

Added functionality

• we support Linux’ new queue’ing mechanism called nfqueue. This was contributed by Nitro Security. Nfqueue supports running multiple copies of Snort_inline to take advantage of SMP and reduce risk of denial of service when Snort_inline should crash.
• stickydrop preprocessor enables you to add options to the rules to block an ipaddress for a configurable amount of time
• bait-and-switch preprocessor (Linux only) allows you to redirect traffic from a host to a honeypot based on the rules
• clamav preprocessor is included (you still need to pass –enable-clamav to ./configure)
• reinject action for FreeBSD: reinjects an accepted packet into the ipfw list at a specific rule number

Improved for inline use

• reject action can send RST packets to both source and destination
• stream4 can drop attacks detected in the reassembled stream. It also enforces the TCP window. It implements a number of ideas from Vern Paxson on TCP reassembly, such as a limit on the number of out of order packets and bytes that are accepted in a stream.
• some fixes for FreeBSD

As the list shows, if you are interested in Snort running inline, using Snort_inline might be a better choice for you!

After moving, which went fine, I now finally have some real coding time again. The last week I have been updating and fixing various parts of Snort_inline. The most important change was the update to Snort version 2.6.1.4, which contains security fixes. William also found an issue with the Stream4inline code. The issue was that the memcap that the admin sets to limit the amount of memory used by stream4 wasn’t properly enforced.

Other fixes that are done is that Snort_inline in nfqueue mode now properly honors signals and also no longer needs the libipq library and headers. There are few changes that will be committed soon. One is an issue that clamav can sometimes return an error when parsing malformed file. Until now the spp_clamav preprocessor would issue a FatalError and cause Snort_inline to die. This is obviously not desirable so the patch makes sure that Snort_inline no longer dies and gives the admin an option to either drop or pass traffic that can’t be inspected.

Last but not least there will be a fix to the nfqueue code that appears to solve the ’stuck packet problem’ we were seeing under heavy load. A number of people are testing my patch currently so if all goes well that will be commited soon as well.

Checking out the latest code is done with the following command:

svn co https://snort-inline.svn.sourceforge.net/svnroot/snort-inline/trunk

I just read about a new issue with WordPress here at SecurityFocus. It’s a potential credential stealing vulnerability, so I quickly created these ModSecurity 2 rules:

SecDefaultAction “log,deny,status:403,phase:2,t:lowercase,t:escapeSeqDecode”
SecRule REQUEST_FILENAME “/wp-login.php$” “chain,msg:’WORDPRESS wp-login.php redirect_to credentials stealing attempt’,severity:2,t:normalisePath”
SecRule ARGS_NAMES “^redirect_to$” “chain”
SecRule ARGS:redirect_to “(ht|f)tps?\://”

I can still login to my WordPress install, so it seems that the rule does no harm. Use at your own risk!

Update: I’ve created a Snort rule as well:

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:”WORDPRESS wp-login.php redirect_to credentials stealing attempt”; flow:to_server,established; uricontent:”/wp-login.php”; nocase; uricontent:”redirect_to”; pcre:”/redirect_to=(ht|f)tps?\:\//iU”; classtype:web-application-attack; sid:4000003; rev:1;)

Update 2: fixed the Snort rule, thanks to Shirkdog for pointing out that it had some broken pcre in it. The rule is now included in the BleedingThreats ruleset (check here), however that (slightly modified) rule doesn’t detect the attack for me.

Update 3: the Bleeding rule is now fixed. I’ve updated the above rule as well.

Update 4: updated the ModSecurity rule to prevent a possible evasion by prepending tab chars to the redirect url. Thanks to Ryan Barnett for pointing this out.

My ISP is one of the few here in the Netherlands that provides a IPv6 tunnel broker. I have played with it some during the last year or so, but now decided to get a little more serious with it. So I’ve decided to enable it for my blog. When opening up my site to IPv6 one thing that is important is security. I will describe the status of IPv6 support of my current setup:

Linux firewalling: IPtables supports IPv6 for quite some time, however it only very recently gained stateful packet filtering support. This hasn’t made it into Debian Sarge or even backports yet, so I’m just using stateless filtering now.

Vuurmuur: my own IPtables frontend has no support for IPv6 at all. I’ve been thinking about adding it for years, but decided to wait at least until stateful support would be available. Next to this my coding time is limited, and many other features are probably more interesting to Vuurmuur users.

Snort/Snort_inline: both Snort and Snort_inline lack support for IPv6. Sourcefire is working on it as far as I know, but no code is available from them. I did find a IPv6 patch for Snort 2.3.3, which can be found here. I ran it in sniffer mode and that works. I haven’t played with it much other than that, but I certainly will in the future.

ModSecurity: my Apache 2 installation has IPv6 enabled by default and ModSecurity 2.x just worked with it without any configuration change! I haven’t looked into how to create rules specific for IPv6 addresses however, so maybe surprises will come up here. I do know from looking at the source that the rbl functionality doesn’t support IPv6 addresses yet, but I haven’t even checked if realtime blacklists exist for IPv6.

Sguil/Modsec2sguil: my modsec2sguil script, that takes ModSecurity alerts and feeds them to Sguil, doesn’t act on the IPv6 alerts because it expects IPv4 addresses. This is not a problem however, since Sguil doesn’t support IPv6 addresses. This makes sense since Snort doesn’t support it either.

So compared to my IPv4 access, protection is somewhat limited. I’m only enabling HTTP for now, so ModSecurity should be able to handle that just fine.

Anyway, it seems to be working fine now, but consider the IPv6 support experimental, as I’m playing with how it all works. So don’t be surpised if it’s broken all of a sudden

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:

1. checkout vendor/current
2. update your working copy to the new version
3. commit
4. create a new tag for the new version.

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!

ClamAV is a great Open Source virusscanner that can be used for detecting virusses from Snort or Snort_inline using the ClamAV preprocessor. However, by using the anti-phishing and anti-scam signatures by SaneSecurity, this combination can also be used to detect and block phishing and scam attempts. Here is how to set it up.

I’ve decided to run this on my gateway, which is a slow machine. Because I don’t want all my traffic to slow down to much, I’m not going to run the ClamAV defs, only the anti-phishing ones. The default location of the defs on my Debian Sarge system is /var/lib/clamav, so I’ve created a new directory called ‘/var/lib/clamav-phish’. Next I’ve downloaded the defs from SaneSecurity. After unzipping them and the defs were ready.

Next was setting up the clamav preprocessor. For this I used the config line in my snort config:

This line says that spp_clamav should look for traffic on port 80 that flows to the client. It should use the signatures in /var/lib/clamav-phish/ and it should drop the traffic if a phishing attempt is detected. It also checks once an hour to see if the defs in the directory have been updated, and reloads them if so.

William Metcalf pointed me to a site where you can test this setup. It’s called MillerSmiles.co.uk and it’s an anti-phishing site, with many examples on their site. Opening an example shows this in my snort_inline log:

The site failed to open, so it works just fine!

Okay, so i’m fired at patch making because I screwed up the last patch. I never bothered to test it with Snort in inline-mode. This didn’t work because we included all kinds of specific features for Snort_inline into the preprocessor. I have updated the patch.

Get it here: http://www.inliniac.net/files/061106-snort-2.6.0.2-clamav.diff.gz

Will, am I re-hired now? Pretty please???

Yesterday there was a mail to the bugtraq mailinglist about two types of vulnerabilties in Tikiwiki 1.9.5. The most serious is a claimed MySQL password disclosure through a special URI. The second is an XSS, also through an special URI. The message can be found here.

I wrote ‘claimed password disclosure’, because on the Tikiwiki server I run, I could not reproduce it. With that I mean the password disclosure, since I do see that Tikiwiki gives an error that reveals other information, most notably the location of the website on the local filesystem.

Anyway, since I’m running Tikiwiki I was eager to protect myself, so I started to write some rules.

XSS

Since I run ModSecurity on this server, I started with a rule for that:

SecFilterSelective REQUEST_URI “\/tiki-featured_link\.php\?type” “chain,status:403,msg:’LOCAL tikiwiki featured link XSS attempt’,severity:6″
SecFilterSelective REQUEST_URI “\/iframe>” log,deny,status:403

I did the same for Snort, and submitted it to the Bleeding Edge ruleset, see here.

Passwd/filesystem disclosure

This one is much harder to catch in a rule. The problem is in how Tikiwiki handles the sort_mode option in an URI. Only if the argument to sort_mode is valid (such as hits_asc or hits_desc for sorting on number of hits) the error is prevented. If the argument to sort_mode is empty or invalid then the disclosure condition triggers.

The only way I can think of to write rules for this is by adding some positive security filtering. In other words, create a rule that defines the valid arguments to sort_mode and drop anything else. Below is an example of one of the affected pages in Tikiwiki:

SecFilterSelective REQUEST_URI “tiki-listpages\.php” chain
SecFilterSelective REQUEST_URI “sort_mode=(pageName|hits|lastModif|creator|user|version|
comment|flag|versions|links|backlinks|size)_(asc|desc)” pass,skip:2

SecFilterSelective REQUEST_URI “tiki-listpages\.php” “chain,msg:’LOCAL tikiwiki listpages mysql passwd disclosure attempt’,severity:7″
SecFilterSelective REQUEST_URI “sort_mode=” log,deny,status:403

As you can see, here are two logical rules, each consisting of two chained rules. The first rule defines all the possible valid options to sort_mode and then has the action ‘pass,skip:2′. This says that this rule should not use the default action of deny and that the next two rules should be skipped. These next two rules drop every use of the sort_mode option, thus blocking the attack.

I have not yet looked at doing this in Snort. According to the advisory, there are 21 different vulnerable URI’s in Tikiwiki, which all have different arguments to sort_mode. So only 20 more to go!