Setting up Snort on Windows

A short troubleshooting guide.

Posted by Michichael on Friday June 24, 2011 11:46 am

Odds are if you're here, you're looking for the errors I tagged. There's quite a few of them and not a lot on the net to walk you through it, so maybe this will help some folks.

Once you've got snort installed, if you're not a complete idiot you've done a bit of configuring in the snort.conf file. There are a few major things that'll throw you.

ERROR: C:Snortetcsnort.conf(39) Unknown rule type: ipvar

This error (obviously your path will be different) is a result of the default config having ipv6 in mind, while the scanner doesn't run in that mode by default. The fix is to rename all instances of "ipvar" with "var".

ERROR: C:SnortBuildsnort-2.9.0.5srcparser.c(5245) Could not stat dynamic module path "/usr/local/lib/snort_dynamicpreprocessor/": No such file or directory.

This one is pretty easy at first glance, but a little more complicated than one would think. Since we're on a Windows installation, you don't have /usr/local/ - you've got C:Snort.

The config file itself tells you to make these a non-relative path. If you try just making it C:/snort/lib/snort_dynamicpreprocessor/ (notice, NO quotes in the config file!) you'll notice you still get the error:

ERROR: C:SnortBuildsnort-2.9.0.5srcparser.c(5245) Could not stat dynamic module path "C:/Snort/lib/snort_dynamicpreprocessor/": No such file or directory.

And are probably wondering why it's doing it. It's simple actually: since its a nonrelative path, it doesn't like the trailing "/" that's normally present. Delete it and make that line:

# path to dynamic preprocessor libraries

dynamicpreprocessor directory c:/snort/lib/snort_dynamicpreprocessor

Replace the other instances of /usr/local in a similar fashion and you get yet another error:

ERROR: C:SnortBuildsnort-2.9.0.5srcparser.c(5245) Could not stat dynamic module path "c:/snort/lib/snort_dynamicengine/sf_engine.so": No such file or directory.

This one is a result of linux using .so files, Windows uses .dll. Make this line:

#path to base preprocessor engine

dynamicengine c:/snort/lib/snort_dynamicengine/sf_engine.dll

Finally, you get this when you run it again (well, if you haven't figured out by now that you should check the paths…)

ERROR: C:SnortBuildsnort-2.9.0.5srcparser.c(5245) Could not stat dynamic module path "c:/snort/lib/snort_dynamicrules": No such file or directory.

Simple answer is that this doesn't exist by default in the Windows install. Comment out the line.

# path to dynamic rules libraries

#dynamicdetection directory c:/snort/lib/snort_dynamicrules

If you're running snort in IDS/NIDS mode, you'll also want to comment out the following:

#preprocessor normalize_ip4

#preprocessor normalize_tcp: ipsecnstream

#preprocessor normalize_icmp4

#preprocessor normalize_ip6

#preprocessor normalize_icmp6

At this point, you should be able to run snort! There's a lot more configuration that goes into it, but here's your basics to get it running without those pesky fatal errors!

Updating Local Groups via GPO

Posted by Michichael on Tuesday May 24, 2011 12:04 pm

So, interestingly enough, we're in the middle of a massive AD migration for the company. Now unfortunately, we're using a company called EMC that apparently hires idiots. The EMC team is pushing us to go to one forest one domain; laughable as it is, considering the ITAR and other security concerns, not to mention the fact that we're a global corporation... Anyway, besides the fact that the entire structure is poised for catastrophic collapse at the first top level issue, they're so incompetent that they only know how to do things via their "Quest" tool. The result is that they're not really doing any ACL's - we have to do them all. They're not renaming groups or breaking things down to site by site, we have to do it. They're removing domain admins from everyone, and we have to figure out how to do our jobs without it, etc.

Totally incompetent, considering all of this can be scripted out by anyone with even cursory knowledge of how Active Directory works. It's painfully clear that EMC doesn't, and I can only hope that when this crashes and burns our lawyers have a field day and the people at the top clearing this project, that don't understand IT at all (they're managers) get the axe and put people that, even if they don't know technology, know enough to listen to the people that do.

Anyway, I'm sitting here engineering a way for us to continue, you know, doing our damn jobs while EMC breaks everything, and came across using group policy preferences to update the local groups. Now you used to have to manage things via restricted groups, but when you're adding local users as local admin for various poorly written vendor software, that's not an option. This seemed perfect for the job so I went ahead and set up the Administrators (built-in) with the accounts and lo and behold... it didn't work. This puzzled me, because i saw it was there, but it wasn't working.

After far too long troubleshooting whether or not preferences wasn't applying properly I noticed something: There were two administrators groups! One for "Administrators" and one for "Administrators (built-in)". Sure enough, the built-in one had the accounts, the real one didn't. There's a nasty bug in group policy preferences! 

The fix is when you add the group, delete (built-in) and it works like a charm. DO NOT try to Delete the group if you already pushed it, as it will kill the real one, not the (built-in) one. Buggy, I know. Here's a pictogram walkthrough:

 First, head to the preferences section of your computer configuration, and select Local Users and Groups:

 

 Next, create a new group, set it to "update", and choose the "..." to pick your group: 

 It will pull in the window saying "Administrators (built-in)" simply delete the (built-in) text and add your users! 

 

 

 Your final product should look similar to this:

 

 

That's all there is to it! Weird bug, hopefully MS fixes it at some point. 

A Tale of DisplayLink, Java, and nVidia Crashes

Ode to the 0xC0000005

Posted by Michichael on Monday October 25, 2010 5:29 pm

So. I decided I needed to get into ASDM to fix something, and discovered that Java had stopped working. Great - another java issue with java crashing. Just what I needed. Few seconds later, my computer bluescreens with an nvd3dum.dll error. Googling that returned nothing - I discounted it as being due to me getting a new laptop with a new graphics card and not reinstalling Windows. Little did I know...

So Java is acting out, computer's Bluescreening... this is going to be a wonderful day. First thing I did was update Java to 22. No dice. Uninstall. Can't uninstall, because that's only valid for products that are installed. What?! 

I spend the next few hours trying to get java to uninstall or reinstall and it just won't. Found the solution in the form of fixjava.bat and got java installing. Phew! But wait! Java is still crashing! What the hell!!!!

Faulting application name: java.exe, version: 6.0.220.4, time stamp: 0x4c908d11
Faulting module name: nvd3dum.dll, version: 8.17.12.6099, time stamp: 0x4cb9d8d7
Exception code: 0xc0000005
Fault offset: 0x0038b41b
Faulting process id: 0x14f8
Faulting application start time: 0x01cb749a5a9674a9
Faulting application path: C:Program FilesJavajre6injava.exe
Faulting module path: C:Windowssystem32 vd3dum.dll
Report Id: 98667891-e08d-11df-a5d9-c1ce0d13a7ea

Faulting application name: java.exe, version: 6.0.200.2, time stamp: 0x4bc398af
Faulting module name: java.dll, version: 6.0.200.2, time stamp: 0x4bc3c8dc
Exception code: 0xc0000005
Fault offset: 0x00005875
Faulting process id: 0xf74
Faulting application start time: 0x01cb749ee0cf396b
Faulting application path: C:Program FilesJavajre6injava.exe
Faulting module path: C:Program FilesJavajre6injava.dll
Report Id: 1e9130ab-e092-11df-a5d9-c1ce0d13a7ea

 

I won't go into the bloody details, but using procmon I discovered that it was somehow handing off data to Displaylink, which then somehow conflicted with nVidia. Updating to the latest nVidia did nothing. So I decided to uninstall everything - DisplayLink, Java, nVidia and see where things got me. Java worked after reinstalling it with the basic video drivers. Worked with the nVidia drivers, didn't work with DisplayLink. Hah! A clue! So the next few hours were spent trying various combinations. I eventually discovered that the DisplayLink 5.5 driver would cause the crash with JRE6 Update 22 and the latest nVidia drivers, and any combination with DisplayLink 5.5 would do so. 

Downgrading to DisplayLink 5.4 fixes the problems and java runs once more. Now to finally freaking set up ASDM! Hopefully somebody finds this troubleshooting info useful. :)