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!
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…
Checkout my LinkedIn profile for more info. My resume is available on request.
If you have some work or know someone that does, please let me know!
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…
3. The snort at the “magicqueue” is a back-up snort – normally no traffic is sent to it, but in the event that one of the “load-balancing” snorts isn’t present, the traffic for that “load-balancing” snort gets sent to the “backup” snort.
And even more, read that here.
I haven’t tried this myself, but it sure looks cool. Try it by checking out the latest SVN code for Snort_inline. Then follow the instructions from README.NFQUEUE.
Big thanks to Dave Remien & NitroSecurity for this contribution!
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:
Check it out!
Please note that our SVN code has seen limited testing so far, so be careful! Please report any issues!
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:
This will save the source to the directory ‘trunk’. In the directory ‘trunk’, run ‘sh autojunk.sh’ and then configure, make, make install…
A while ago I wrote about porting Snort_inline to 220.127.116.11. That worked well, however we are still trying to resolve some issues. Especially in stickydrop, that is just broken right now. Also, SourceFire released 18.104.22.168 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 😉
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).
That’s not enough though. The following settings increase the buffer that NFQ seems to use for it’s queue. Since I’ve set it this high, I haven’t been able to get a single read error anymore:
sysctl -w net.core.rmem_default=’8388608′
sysctl -w net.core.wmem_default=’8388608′
The values are in bytes. The following values increase buffers for tcp traffic.
sysctl -w net.ipv4.tcp_wmem=’1048576 4194304 16777216′
sysctl -w net.ipv4.tcp_rmem=’1048576 4194304 16777216′
For more details see this page: http://www-didc.lbl.gov/TCP-tuning/linux.html
Setting these values fixed all my NFQ related slowdowns. The values probably work for ip_queue as well. If you use other values, please put them in a comment below.
Thanks to Dave Remien for helping me track this down!
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:
Then have a look at doc/README.IP6TUNNEL for configuration options.
Once again thanks to the great people of Nitro Security. I think it’s great to see this company giving back to the community!
I’ve just committed an update to Snort_inline’s SVN. It brings it to the Snort 22.214.171.124 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:
Consider the code to be of beta quality for now, so be careful with it. Please report any problems with it!
Again, a big thank you to NitroSecurity for funding this work!