Wednesday, October 26, 2011

Install and Configure Snort IDS on Windows

I recently attended the BSidesMO conference in the Missouri Capitol building at Jefferson City, MO. I had the honor of doing a presentation on running Snort as a sysadmin. Even though I struggled through the presentation, it went pretty well. The audience was very responsive and had a lot of questions which I think is a good thing (at least I know they weren't sleeping). I probably forgot to mention it but if you were in the audience, thank you for attending. More importantly, thank you for not heckling me. Lucky for you, I'm better at writing blog posts than I am leading in person presentations.

Managing Security with Snort and IDS Tools by Cox, Kerry/ Gerg, Christ (Google Affiliate Ad)

This blog post is the missing manual from my presentation. My perspective is that good sysadmining is good security. While I may not be a security professional, that does not mean I do not care about doing my part to keep my organization secure. A copy of my BSidesMO presentation is available at

If you are interested in running Snort on Windows there are a few things you should know beforehand. I'll run through the steps to get Snort installed and configured on Windows.

The first thing you need is a Windows computer. Any modern version of Windows will work (XP/Vista/7/2003/2008). The same goes for hardware, most modern desktop or server systems will run Snort to monitor a small/medium sized network. A modern CPU with 2 GB+ RAM will be adequate. You will want multiple network cards, at least two. If you plan to monitor more than one location in your network then you will need a NIC for each.

Configure one network card as you normally would, assign an IP address and install clients as normal. This network card will be used for management. The other cards should be "silent" on the network. That means disable all the clients, services, and protocols. This will prevent your IDS from introducing any traffic on the interface it is supposed to be monitoring. See the screen shot to the right.

With that out of the way, the next step is to start installing Snort and it's prerequisites. Here's the list of things I would suggest you install. The order you install these does not particularly matter.
 Okay you caught me, these are not all required. I put an asterisk next to the optional ones. I suggest installing these just to make your life a little easier. Kiwi Syslog is not actually required either. I suggest using a dedicated syslog server but if that's not an option, Kiwi will do. One last suggestion, install Snort and Kiwi Syslog on a separate hard disk or partition from the Windows OS. This will prevent a run away log file from crashing your server.

One last prerequisite is a perl module, Sys::Syslog. This is necessary for using pulledpork and can be installed by opening a command prompt and entering the commands below.
perl -MCPAN -e shell
install Sys::Syslog

Next, head over to and get the latest version of pulledpork (0.6.1 as of this post). Pulledpork is a perl script for downloading and managing Snort rules. Since pulledpork is distributed as a tarball, you will need 7-Zip to extract it. I put it in a directory named D:\pulledpork-0.6.1. While you are there, go ahead and create a directory named D:\tmp to use as a temp folder for pulledpork.

You need to edit This is necessary to get pulledpork to run on Windows. Open with gVim and go to line 528. Change line 528 from this:
open( DATA, "$path$file" ) || croak "Couldn't read $file - $!\n";

to this:

open( DATA, "$path$file" ); # || croak "Couldn't read $file - $!\n";

Next use gVim to open pulledpork.conf from the etc directory. You will need to make several changes to this file. This is a good time to mention the two main sources for free or premium rules. You can get rules from and You can use either or both rulesets.

Back to editing pulledpork.conf. Start by enabling one or more of the rule_url lines. If you plan to use the or premium EmergingThreats rules, you will need to include your oink code. Make the rest of the changes below (appropriate to your installation location).
  • temp_path=D:\tmp
  • sid_msg=D:\Snort\etc\
  • sid_changelog=D:\Snort\log\sid_changes.log
  • comment out entire so_rule section
  • snort_version=
The last line is just a trick to get the latest version of the free rules from Open a command prompt and change directories to your pulledpork installation. Run the command below to grab the rules from the URLs you selected in pulledpork.conf. This command is all on one line.

perl d:\pulledpork-0.6.1\ -c d:\pulledpork-0.6.1\etc\pulledpork.conf -vTk -K D:\Snort\rules
After it completes, check your D:\Snort\rules folder for newly downloaded rules. If everything went right, you can use this command and create a scheduled task to automate rule downloads.

A quick note, pulledpork modifies the name of the .rule files that it downloads and extracts. It prepends VRT- to rules from and ET- for rules from EmergingThreats. This will be important in a later step.

If you decided to use the EmergingThreats rules then you need to get a copy of emerging.conf. Go to, browse to the ruleset and Snort version you are using, and get a copy of emerging.conf. Put this file in your D:\Snort\rules folder. Edit it with gVim and uncomment var SSH_PORTS 22.

Now, do a gVim substitute (:s) or find and replace. You need to modify the .rule file names. Replace all instances of $RULE_PATH/ with $RULE_PATH/ET-.


Browse through the rules and uncomment the rules you would like to run. More on this in a minute.

You are getting closer and will be running snort in just a few more minutes. This will be the last file that needs to be edited. Using gVim, open snort.conf from D:\snort\etc. Do a find and replace replacing include $RULE_PATH/ with include $RULE_PATH/VRT-. Do another find and replace, this time changing ipvar to var. The rest of the changes to make are listed below.
  • modify var HOME_NET X.X.X.X/X (change to your network)
  • modify var RULE_PATH d:\snort\rule
  • modify dynamicpreprocessor directory d:\Snort\lib\snort_dynamicpreprocessor <- no trailing slash!
  • modify dynamicengine d:\Snort\lib\snort_dynamicengine\sf_engine.dll
  • comment out #dynamicdetection directory /usr/local/lib/snort_dynamicrules
  • comment out all preprocessor lines (preprocessors do not work in IDS mode)
  • add output alert_syslog: host=, LOG_AUTH LOG_ALERT
  • uncomment or add output log_tcpdump: tcpdump.log
  • add include $RULE_PATH/emerging.conf
  • Choose a few VRT rules to run (optional)
Running Snort
Snort is now installed and configured. All that is left is starting and testing your Snort install and then you are ready to start monitoring. The first thing to do is identify the interface you want to monitor. This command will help you: snort.exe -W

You should get some output like this:

In my case, the interface I will be using is 1. I can tell because the IP address field is listed as disabled. Next, test the snort.conf configuration by running this command:
snort.exe -i1 -s -l D:\snort\log\ -c D:\Snort\etc\snort.conf -T

You may see a few warnings or other messages. Don't worry about those, as long as the last two lines appear as below then you have a valid configuration.
Snort successfully validated the configuration!
Snort exiting

Now you are ready to run Snort for real. To see all of the command line options, run snort.exe -h. To run Snort interactively, you can try this:
snort.exe -i1 -s -l D:\snort\log\ -c D:\Snort\etc\snort.conf

Again, don't worry too much about any warnings or errors. If Snort notifies you that it is: Commencing packet processing then everything should be up and running.

When you are satisfied with your command line configuration, install Snort as a service. This command will do that:
snort.exe /SERVICE /INSTALL -i1 -s -l D:\snort\log\ -c D:\Snort\etc\snort.conf

The last thing to do is set the service to start automatically at boot time and start it.

Now that you have snort running, this is a good place to make a couple of statements about what rules to enable. The first piece of advice is to start with very few rules, maybe just one .rule file. The reason for this is to help prevent you from getting overwhelmed with alerts. It also gives you an opportunity to fine tune the rule file. The second thing is to be smart about what rules you are enabling. If you are monitoring client traffic that is destined for the Internet, then it would not make sense to use rules for detecting IIS or SQL rules. Knowing what you are monitoring and what you expect to be alerted on will help you get better performance and results from your Snort installation.

Testing Snort
Testing Snort is actually quite easy. You can enable the VRT ICMP rules. This will alert you on any ping packets. Here's the rule file line to enable in snort.conf.
include $RULE_PATH/VRT-icmp-info.rules

Now just ping any host that will pass the IDS interface and you should get an alert in your syslog server. If you see something like the screenshot below then your IDS is working!

You can also browse to D:\Snort\log and look for some tcpdump.log.0000000000 files. These contain a packet capture of the alert traffic. If you want to see the packets that generated an alert, you can use Wireshark to open these files.

This blog post should be enough to help you get Snort up and running on Windows but it just scratches the surface of Snort. There are lots of other options and features that I did not even mention. As you become more comfortable and familiar with Snort you will want to look into things like shared object rules, thresholding, and maybe even writing your own rules (really it's not that hard). My true recommendation would be to run Snort on Linux. You will probably see better performance and some features only work on nix platforms. If Linux is not in your comfort level then Snort on Windows is a good compromise.

Hopefully you found this information useful. If you liked what you read or noticed an error, feel free to send me a message or leave a note in the comments below. Thanks!


Tuesday, October 4, 2011

Remote Packet Captures With Wireshark

Here's a Wireshark feature I just recently discovered. I don't know how long it's been available but I believe it's fairly new. It is listed as experimental in WinPcap so YMMV.

If you have ever needed to do a remote packet capture you know it can be painful. It usually requires that you to go to the remote system or switch. You probably have to configure a mirrored port or install a hub inline. If you are lucky, you can get someone at the remote end to do this for you. In either case, it seems like it takes longer than it should. With Wireshark 1.6.2 and WinPcap 4.1.2 you can make this a much simpler task. Use the simple diagram below as a guide. In this example, we want to capture packets from the remote host with IP address

Start by installing WinPcap on the machine you would like to capture packets from. This is probably a good time to note that this only works on Windows. After WinPcap is installed, drop to a command prompt (elevated command prompt in Vista/7/2008/2008R2).  Change directories to C:\Program Files\WinPcap or C:\Program Files (x86)\WinPcap. Run "rpcapd.exe -s rpcapd.ini -l" and then press Ctrl+C. Remember, is the Wireshark computer. This creates the rpcapd.ini file necessary to run as a service. Next open rpcpad.ini in notepad.

This next part may be a little controversial. In order to connect, you need to disable username/password authentication. According to, username/password authentication is possible however I have not been able to locate any documentation on how to configure it. I have also asked on the winpcap-users mailing list. If you know the answer to this, drop me a line. Once I have this problem solved, I will update this post to enforce authentication. For additional security, you should disable the rpcapd service or uninstall WinPcap when you are finished with your capture.

With that out of the way, go back to notepad. Change the line NullAuthPermit = NO to NullAuthPermit = YES. Close notepad and run "net start rpcapd" to start the "Remote Packet Capture Protocol v.0 (experimental)" service. We are now done with the remote system.

Go to your computer with Wireshark installed and open Wireshark. Click Capture->Options.

Click the drop down arrow next to Interface and choose Remote.

Enter (your remote capture machine) and 2002 for the port. Choose Null Authentication and click OK.

Next, just click Start to begin your packet capture. Wireshark behaves exactly as if you were capturing packets locally. By default, Wireshark ignores the RPCAP traffic. You might want to a make a copy of your rpcapd.ini file. If you need to do more caputres in the future, you can install WinPcap, copy your rpcap.ini file to a host, and start the rpcapd service.

As always, feel free to leave comments below and drop me a note if you found this useful.