Snort_inline on Inliniac

Checking out SourceForge's Marketplace

Tue, 06 Jan 2009 14:26:31 +0000

I’ve registered myself as a seller of services on SourceForge’s Open Source Marketplace. I’ve done so offering software development services for the Snort, Snort_inline and Vuurmuur projects. I was wondering if anyone has any experience (good or bad) with the Marketplace system, either as a buyer or seller of services. Let me know!

Available for contract work

Mon, 05 Jan 2009 13:26:06 +0000

This year there will be a lot of work that needs to be done for the Open Infosec Foundation. And like I wrote a few days ago, a lot of work is already being done. However, most of it is unpaid at this time as it will be some months before our funding comes in. So at least until then I’m available and looking for contract work.

For the last two years I’ve been doing work as a contractor in the (open source) security field. My experience is mostly in coding in C and Perl, primarily on Snort and Snort_inline. Recently I created the (Perl language) SidReporter program for Emerging Threats. Areas I worked in: IPv6 IDS/IPS coding, signature writing, Web Application Firewalls, threading, bandwidth accounting, and more…

Snort_inline load balancing

Thu, 18 Sep 2008 11:32:40 +0000

Dave Remien of NitroSecurity created a patch that “implements a relatively simple form of (IPV4) load balancing” between multiple Snort_inline processes using Nfqueue. Here is what it does:

1. Load balancing. The bottom half of the source and dest addresses are added together, and mod’d with the number of “load-balancing” snorts you desire to run. This means that traffic stays with a particular snort, so that state is maintained.

2. Because you can run many snorts (presumably on many CPUs), you can now take advantage of that super-hooty 16way box and those 10 gig NICs you just got your hands on…

Snort_inline updated to 2.8.3 in SVN

Tue, 16 Sep 2008 21:08:26 +0000

Snort_inline was just updated to Snort 2.8.3 in SVN. Please give it a try. It hasn’t seen much testing so far, so be careful when putting it on production servers.

Get the code from SVN like this:

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

Check it out!

Snort_inline updated to 2.8.2.1 in SVN

Wed, 18 Jun 2008 07:41:48 +0000

This morning I updated our Snort_inline codebase with SourceFire’s just released 2.8.2.1 version. See the original changelogs here: 2.8.1, 2.8.2, 2.8.2.1.

Also Richard Bejtlich and Nr have good posts about the improvements of the last versions. See Richards post about a fixed frag3 vulnerability here and see Nr’s post here.

Please note that our SVN code has seen limited testing so far, so be careful! Please report any issues!

Snort_inline 2.8.2.rc1 in SVN

Sat, 10 May 2008 18:24:06 +0000

Today I’ve spent some time on updating the Snort_inline source to the latest 2.8.2.rc1. The updating went quite smooth, so I hope no big issues pop up. Like before, trying out this code can be done by checking out SVN like this:

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

This will save the source to the directory ’trunk’. In the directory ’trunk’, run ‘sh autojunk.sh’ and then configure, make, make install…

Snort_inline 2.8 status

Tue, 26 Feb 2008 17:12:15 +0000

A while ago I wrote about porting Snort_inline to 2.8.0.1. That worked well, however we are still trying to resolve some issues. Especially in stickydrop, that is just broken right now. Also, SourceFire released 2.8.0.2 last week, so we need to update to that too.

First however, I will be traveling to California this week. I will be meeting Will there, so I’ll try to get him to fix that damn code ;-)

Improving Snort_inline's NFQ performance

Wed, 23 Jan 2008 15:27:29 +0000

When using Snort_inline with NFQ support, it’s likely that at some point you’ve seen messages like these on the console: packet recv contents failure: No buffer space available. When the messages are appearing Snort_inline slows down significantly. I’ve been trying to find out why.

There are a number of setting that influence NFQ performance. One of them is the NFQ queue maximum length. This is a value in packets. Snort_inline takes an argument to modify the buffer length: –queue-maxlen 5000 (note: there are two dashes before queue-maxlen).

Tunnel unwrapping for Snort_inline 2.8.0.1

Fri, 11 Jan 2008 16:24:37 +0000

Not many people have native IPv6 connectivity and use some form of tunneling. For this reason Nitro Security asked me to develop a Snort preprocessor to unwrap various tunnels. This resulted in the preprocessor ‘ip6tunnel’, which I uploaded to Snort_inline’s SVN yesterday. The preprocessor is capable of unwrapping IPv6-in-IPv4, IPv6-in-IPv6, IPv4-in-IPv6, IPv4-in-IPv4 and finally IPv6-over-UDP. The latter is used by Freenet6.

I chose to develop it as a preprocessor because this allows Snort to inspect both the original packet and the tunnel packet(s). The preprocessor supports recursive unwrapping. The recursion depth is limited to 3 by default, but can be configured differently. Get the preprocessor from Snort_inline’s SVN by checking out the latest trunk:

Snort_inline updated to 2.8.0.1 in SVN

Wed, 09 Jan 2008 15:41:19 +0000

I’ve just committed an update to Snort_inline’s SVN. It brings it to the Snort 2.8.0.1 level. It supports both IPv4 and IPv6 on IPQ and NFQ. I have not been able to test IPFW on IPv6, so I don’t think that will work currently.

This update removes the libdnet dependency and replaces it with libnet 1.1. To be able to send ICMPv6 unreachable packets you will need the libnet 1.1 patch I wrote a while ago. You can find that here. Get the latest Snort_inline by checking out SVN:

Working on Snort_inline 2.8.0.1

Sat, 22 Dec 2007 12:49:20 +0000

The last week I’ve been working on bringing Snort_inline to the Snort 2.8.0.1 level, including it’s IPv6 support. I’m almost ready to commit it to SVN, there are just some issues I need to fix in the inline specific code. The code will get rid of libdnet and use libnet 1.1 for sending reset/reject packets for both IPv4 and IPv6. After committing I will start working on getting the IPv6 features I wrote for NitroSecurity into this tree. This includes more matches, tunnel decoding (including for example the freenet6 tunnel, etc). So stay tuned!

New Snort_inline TCP window normalization code in SVN

Sat, 17 Nov 2007 13:55:38 +0000

A while ago I wrote about why the TCP window scaling normalization in Snort_inline was broken by design. I also wrote about a new solution I was working on and testing that would be uploaded to SVN soon. I just committed the patch to SVN. What it does is add two new options to stream4:

norm_window: normalize the TCP window (disabled by default). This is to protect Snort_inline from being forced to queue too many packets. max_win_size: maximum size of the scaled TCP window. Packets increasing the window beyond the limit are modified.

Matt Jonkman leaves Bleeding Edge

Sat, 17 Nov 2007 12:05:56 +0000

Matt Jonkman is stepping out of the Bleeding Edge project. He announced this here. Apparently Sensory Networks, one of the sponsors of the project, now owns it. It will be interesting to see if they will continue it, and if so, how. Honestly, I’m a bit skeptical, since to my knowledge not many Sensory people are directly involved at this moment. Still I believe Sensory consists of good people. I did a contract job for them about a year ago, and enjoyed working with them.

Multiple Snort_inline processes with Vuurmuur

Mon, 12 Nov 2007 21:29:58 +0000

One of the cool things of the Snort_inline project is the support for NFQUEUE. NFQUEUE is the new queuing mechanism to push packets from the kernel to userspace so a userspace program can issue a verdict on it. What makes NFQUEUE cooler than it’s predecessor ip_queue is that it supports multiple queue’s. This means that there can be more than one Snort_inline process inspecting and judging traffic. The challenge is to make sure that each Snort_inline instance sees all traffic belonging to a certain connection so Snort_inline can do stateful inspection on it. Luckily, Vuurmuur makes it very easy.

Libnet 1.1 IPv6 fixes and additions

Tue, 16 Oct 2007 21:35:11 +0000

Libnet is a cool packet crafting tool, used by Snort to send TCP reset packets and ICMP unreachable packets as part of active responses. Libnet 1.1 supports IPv6 which is what I needed for my work. After some reading and testing there were a few problems. First, while possible to send TCP reset packets, the packets didn’t have a correct checksum and debugging this with valgrind showed lots of memory errors. Second, ICMPv6 was only partly implemented. The libnet_build_* functions for it are missing. This is, by the way, quite a common picture. Many libraries and projects have some support for IPv6, but generally incomplete and less well tested.

Window scaling normalization in Snort_inline broken by design

Tue, 04 Sep 2007 15:51:25 +0000

After debugging some connection problems I found that the wscale normalization concept is flawed. I’ll describe here what is wrong with it and then move on to suggest a different solution I’m currently testing. The problem I was seeing is that some connections to some webservers stalled without an apparent reason.

First a quick reminder of why I originally came up with the wscale normalization. Stream4 originally doesn’t look at the window scaling value when determining the TCP window. This causes it to be wrong about the TCP window in about every connection, which is one of the reasons out of window packets are not dropped (this is actually a gaping evasion hole since these packets are not used in stream reassembly). This is why I decided to add window scaling support to the stream4inline extension. This works great and allows the admin to drop out of window packets. There is a problem associated with it though. The maximal window that is possible with wscaling is 1GB. This would mean that Snort_inline would in the worst case have to queue almost 1GB of data in it’s buffers for a single stream. To prevent this being used by an attacker to attack Snort_inline, I wanted give the admin the option to set a maximal wscale size.

Snort_inline and out of order packets

Mon, 30 Jul 2007 21:22:56 +0000

In Snort_inline’s stream4 modifications, one of the changes is that out of order TCP packets are treated differently from unmodified stream4. This can cause some new alerts to appear and some unexpected behaviour. So I’ll try to explain what happens here.

First of all let me explain quickly what out of order packets are. To put it simple, TCP packets are send out by the source host in a specific order but can arrive in a different order at the destination. Packetloss, link saturation, routing issues are among many things that can cause this. A Snort_inline specific issue is that when Snort_inline can’t keep up with the packets it needs to process, it will drop packets which causes packetloss. These packets will then have to be resent by the sending host.

Snort and the GPL version 3

Fri, 29 Jun 2007 20:21:24 +0000

Today the final version of the GPL version 3 was released. This is interesting from many perspectives, and one of them is Snort licensing. Much has been written about Snort and the GPL lately, but that was all about new license language introduced with Snort 3.0 alpha and not about the currently maintained and developed 2.6 and 2.7 branches. When I’m talking about Snort here and now, I mean those versions prior to 3.0.

Compiling Snort_inline with NFQUEUE support on Ubuntu

Tue, 26 Jun 2007 15:59:21 +0000

I needed to setup the right libraries for Snort_inline development on my fresh Ubuntu Feisty installation, so I decided to write down the procedure for those who think compiling Snort_inline from source is hard. :)

Make sure you have build-essential package installed. This makes sure you have a compiler and development packages for glibc and other important libraries. I’m installing the libraries from source to get the latest versions because the latest versions are more stable and perform better than the versions included in Feisty. I’m installing them into /usr because some programs like them there best.

TCP Window scaling in Snort_inline

Fri, 15 Jun 2007 22:04:57 +0000

The TCP window field in the TCP header is only 16 bits, so the maximum window size it can handle is only 64kb. A long time ago this was enough, but nowadays it isn’t, by far. Luckily, this is something the window scaling option fixes. Window scaling is very common these days. Your pc or laptop probably uses it by default. Snort’s stream4 however, does not support it. This means that when tracking and reassembling streams, Snort for most connections has no idea about what data is in window and which is out of window. To make matters worse, the packets that are in window when using wscaling, but appear out of window when the wscaling is not accounted for, are never used in the reassembly process. This makes Snort evadable.

Snort_inline 2.6.1.5 released

Fri, 08 Jun 2007 12:55:29 +0000

Finally, after many months of development and testing, Snort_inline 2.6.1.5 has been released. It’s the first stable release in almost a year and also the first stable release based on Snort 2.6. William sent the announcement:

snort_inline-2.6.1.5 released

List,

I know it has been a long time since we have had a non-beta release,
but what can I say? Victor and I have both been busy in our personal
and professional lives. If you have been running the version of code
in SVN, there are no major updates with this release other than a
memleak fix for stream4inline. I don't think this gets said often
enough, so I would like to thank Sourcefire for all the hard work they
put into snort and the snort rule sets for which I and the rest of the
community greatly benefit.

Regards,

Will

snort_inline-2.6.1.5
http://snort-inline.sourceforge.net/download.html

Differences between snort in inline mode and snort_inline
http://www.inliniac.net/blog/?p=74

Go and get it! :)

Memory leak fixed in stream4inline

Tue, 22 May 2007 21:54:17 +0000

A few days ago William told me that if he enabled stream4inline on a busy gateway, Snort_inline would consume all memory within hours. The problem went away when disabling stream4inline, so it made sense that the problem would be in there somewhere.

The first suspect was the reassembly cache. The reassembly cache is used to keep a per stream copy of the reassembled packet in memory. While being memory expensive, it greatly speeds up the sliding window stream reassembly process, especially with small packets. The reason for this being the first and primary suspect is that this is the only place where stream4inline code allocates memory. Reviewing the code however, showed no leaks and adding a debug counter to monitor the memory usage also showed that the leak was not in that code.

Snort_inline updated to 2.6.1.5 in SVN

Mon, 14 May 2007 20:02:12 +0000

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! :)

Differences between Snort and Snort_inline

Mon, 14 May 2007 17:05:41 +0000

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.

Snort_inline updated to 2.6.1.4 in SVN

Fri, 20 Apr 2007 16:47:33 +0000

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.

Snort_inline and TCP Segmentation Offloading

Fri, 20 Apr 2007 16:36:55 +0000

Since a short while I have a gigabit setup at home. My laptop has a e1000 Intel NIC, my desktop a Broadcom NIC.While playing with Snort_inline and netpipe-tcp, I noticed something odd. I got tcp packets that had the ‘Don’t Fragment’ option set, but were still bigger than the mtu size of the link. Snort_inline read packets of up to 26kb from the queue, and wireshark and tcpdump were seeing the packets as well. This was only for outgoing packets on the e1000 NIC. The receiving pc saw the packets split up in multiple packets that were honoring the mtu size. This got me thinking that some form of offloading must be taking place and indeed this was the case:

New WordPress issue + Snort and ModSecurity rules

Tue, 20 Mar 2007 18:03:21 +0000

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:

Experimenting with IPv6

Tue, 13 Mar 2007 19:04:51 +0000

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:

Snort_inline in svn updated to 2.6.1.3

Thu, 22 Feb 2007 07:59:05 +0000

This week SourceFire published a security advisory for (among others) Snort version 2.6.1.2, on which Snort_inline is based. So I took some time to update Snort_inline. Normally this would have taken Will and me quite some time, but since we switched to using svn those days are gone. I was able to update it in under a hour. I was very happy I blogged about the procedure to follow, since I had already forgotten about it ;-)

Snort_inline 2.6.1.2 BETA 1 released!

Tue, 23 Jan 2007 15:52:00 +0000

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!

Snort_inline patch updated to 2.6.1.2

Wed, 17 Jan 2007 11:55:34 +0000

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.

Setting up Subversion for Snort_inline

Wed, 17 Jan 2007 11:02:31 +0000

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.

Snort_inline 2.6 development update

Sat, 23 Dec 2006 00:35:58 +0000

Development of Snort_inline 2.6 experienced a bit of a setback when William and I discovered that the new Stream4inline had some issues with detecting certain attacks. Since we are scanning the reassembled stream certain detection plugins didn’t work as expected. Basically every detection plugin that uses absolute offsets from the packet start is messed up when we scan the reassembled stream only.

This is because the start of the reassembled stream doesn’t match with the start of the last packet added to this stream. Most TCP sigs are using offsets match against the start of the stream, or relative matches. For example a rule like:

Snort_inline: good article in hackin9 magazine

Tue, 05 Dec 2006 21:50:28 +0000

William pointed me at a nice introductionary article in Hackin9 magazine about setting up and running Snort_inline in various scenarios. Written by Pierpaolo Palazzoli and Matteo Valenza. Worth a read!

http://en.hakin9.org/attachments/hakin9_6-2006_str22-33_snort_EN.pdf

Detecting and blocking Phishing with Snort and ClamAV

Sun, 12 Nov 2006 18:12:31 +0000

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.

Update on Snort_inline 2.6.0.2 development

Fri, 10 Nov 2006 11:54:11 +0000

I have spend the last week trying to find a very annoying bug that caused Snort_inline to go into 100% CPU on certain traffic. It kept working, only my P3 500Mhz home gateway slowed down to between 2kb/s and 25kb/s, while normally it handles the full 325kb/s for my DSL line at around 25% CPU.

Snort comes with a number of performance measurement options. In 2.6 –enable-perfprofiling was introduced. Also, –enable-profile builds Snort for use with gprof. Next to those you can use strace and ltrace with the -c option to see the ammount of time spend in the several functions.

I already knew the problem was related to my new Stream4 code, since running Snort_inline without the ‘stream4inline’ option made the problem go away. So my performance debugging and code reviews were focussed on that code. However, the performance statistics showed no functions that took large ammounts of time in Stream4.

New ClamAV patch for Snort 2.6.0.2

Mon, 06 Nov 2006 08:11:50 +0000

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??? ;-)

Rules for reported Tikiwiki vulnerabilities

Thu, 02 Nov 2006 11:02:52 +0000

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.

Snort_inline: getting closer to 2.6.0.2

Sun, 29 Oct 2006 22:40:29 +0000

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.

Snort_inline: running Snort_inline 2.6.0.2

Thu, 05 Oct 2006 08:13:29 +0000

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.

Sguil: full content logging in combination with Snort_inline, revisited again

Wed, 09 Aug 2006 23:54:33 +0000

Note to self: never assume something works, instead, test it.

Yesterday there was some discussion in the #snort channel over whether or not passing multiple interface to snort works or not. As a reminder, some time ago i noted that passing two interfaces to snort like this: ‘snort -i eth0:eth1’ worked just fine. However, common mentioned in irc that he could not imagine it to be working. Determined to proof him wrong, i decided to run a few test. On my gateway, i ran ‘snort -v -i eth0:eth1 ip proto 1’. This should print all ICMP packets to the screen for both interfaces. The first clue that something wasn’t right was this message:

Sguil: full content logging in combination with Snort_inline, revisited

Sun, 30 Jul 2006 17:02:51 +0000

A few days ago i wrote about some challenges that my Snort_inline presented. Especially the full content logging wasn’t working quite as i would have liked. Logging on pseudo device ‘any’ didn’t work right because then the traffic that was NAT-ted was both recorded before NAT and after NAT. The solution I (with help of #snort-gui) came up with was using ‘-i any’ anyway, but exclude my public ip using a BPF filter. Later i saw Joel Esler write the solution in a unrelated problem to someone else. Sometimes solutions can be so simple!

Sguil: full content logging in combination with Snort_inline

Wed, 26 Jul 2006 19:44:06 +0000

Just spend some time trying to get the transcripts part of Sguil working with my Snort_inline sensor. Without an obvious clue it returned no data for every alert that was received. After much trial and error, and especially much help by Bamm Visscher on IRC, i noticed that i recorded the full packet data from my ppp0 device. Then i remembered issues i had before with that, namely that the logging occurs after NAT. Snort_inline however, gets the packets from the system before NAT. That results in a mismatch causing the sensor not to be able to provide the transcript requested. Changing the interface to record the full packets from to eth0 solved the problem!

Snort_inline: idea for an improved bait-and-switch

Mon, 10 Jul 2006 22:13:09 +0000

William Metcalf recently wrote a bait-and-switch plugin for Snort_inline. The idea is that when a rule matches on certain traffic this plugin loads an iptables rule into the system that redirects the offending host to another server. This can present the user an error message such as “Access Denied” for example, but this server can also have al kinds of sniffing tools, or even be a honeypot.

As the plugin currently creates an iptables rule it only works with linux. Also, it has some difficulty with existing iptables rulesets that might be maintained by other programs, such as my own Vuurmuur. My idea is to investigate whether or not it is possible to simply do the redirection in Snort_inline itself. By rewriting the ipaddress in the IP header, it might work as well. Naturally, this would need to be done for every packet, but with a connection to either the flow engine or the stream engine, this should be able to work… just a thought…

Snort_inline: Adapting the TCP stream reassembler

Mon, 10 Jul 2006 16:34:25 +0000

Currently I am rewriting a modification of the TCP reassembler in Snort_inline. Snort’s TCP reassembler is called Stream4 and it works fairly well in IDS mode, however it has some serious issues in inline mode. The biggest and most important issue is that Snort_inline cannot block an attack if it is detected in the reassembled stream. In Snort_inline 2.4 we made our first attempt to fix this with the stream4inline modification.

Snort_inline on Inliniac

Checking out SourceForge's Marketplace

Available for contract work

Snort_inline load balancing

Snort_inline updated to 2.8.3 in SVN

Snort_inline updated to 2.8.2.1 in SVN

Snort_inline 2.8.2.rc1 in SVN

Snort_inline 2.8 status

Improving Snort_inline's NFQ performance

Tunnel unwrapping for Snort_inline 2.8.0.1

Snort_inline updated to 2.8.0.1 in SVN

Working on Snort_inline 2.8.0.1

New Snort_inline TCP window normalization code in SVN

Matt Jonkman leaves Bleeding Edge

Multiple Snort_inline processes with Vuurmuur

Libnet 1.1 IPv6 fixes and additions

Window scaling normalization in Snort_inline broken by design

Snort_inline and out of order packets

Snort and the GPL version 3

Compiling Snort_inline with NFQUEUE support on Ubuntu

TCP Window scaling in Snort_inline

Snort_inline 2.6.1.5 released

Memory leak fixed in stream4inline

Snort_inline updated to 2.6.1.5 in SVN

Differences between Snort and Snort_inline

Snort_inline updated to 2.6.1.4 in SVN

Snort_inline and TCP Segmentation Offloading

New WordPress issue + Snort and ModSecurity rules

Experimenting with IPv6

Snort_inline in svn updated to 2.6.1.3

Snort_inline 2.6.1.2 BETA 1 released!

Snort_inline patch updated to 2.6.1.2

Setting up Subversion for Snort_inline

Snort_inline 2.6 development update

Snort_inline: good article in hackin9 magazine

Detecting and blocking Phishing with Snort and ClamAV

Update on Snort_inline 2.6.0.2 development

New ClamAV patch for Snort 2.6.0.2

Rules for reported Tikiwiki vulnerabilities

Snort_inline: getting closer to 2.6.0.2

Snort_inline: running Snort_inline 2.6.0.2

Sguil: full content logging in combination with Snort_inline, revisited *again*

Sguil: full content logging in combination with Snort_inline, revisited

Sguil: full content logging in combination with Snort_inline

Snort_inline: idea for an improved bait-and-switch

Snort_inline: Adapting the TCP stream reassembler

Sguil: full content logging in combination with Snort_inline, revisited again