Pages

Showing posts with label windows. Show all posts
Showing posts with label windows. Show all posts

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 http://bit.ly/u99bfm.

Setup
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.

Installation
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

exit
pulledpork
Next, head over to https://code.google.com/p/pulledpork/ 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 pulledpork.pl. This is necessary to get pulledpork to run on Windows. Open pulledpork.pl 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 http://www.snort.org and http://www.emergingthreats.net. 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 snort.org 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-msg.map
  • sid_changelog=D:\Snort\log\sid_changes.log
  • comment out entire so_rule section
  • snort_version=2.9.1.0
The last line is just a trick to get the latest version of the free rules from snort.org. 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\pulledpork.pl -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 snort.org and ET- for rules from EmergingThreats. This will be important in a later step.

emerging.conf
If you decided to use the EmergingThreats rules then you need to get a copy of emerging.conf. Go to http://rules.emergingthreats.net, 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-.

Before


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

snort.conf
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=127.0.0.1:514, 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.

Conclusion
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!

                    

Wednesday, August 3, 2011

The Undeletable File and a Bunch of Dots



Error Deleting File or Folder
Cannot delete file: Cannot read from the source file or disk.

This error message does not seem too scary. It looks similar to other error messages that Windows produces. Maybe it could be more descriptive but when I first saw this I had no idea what it would take to delete this file...

The other day I was doing my annual domain account and user directory clean up tasks when I came across a problem. There was one user directory that I could not delete. I have encountered problems like this before so I started by modifying the ownership and permissions. I made my account the owner with full control of the file. Say good bye file, you are toast. Oh no! It didn't work. And I'm still getting the same message.

The next step for me is FileAssassin. If you don't know what FileAssassin is, it is a great little utility from the Malwarebytes people. It will delete a file if it is locked or otherwise unable to be removed. I have used it several times with great results. Hasta la vista, baby. What!?! It's still there? No luck with FileAssassin, this thing is stubborn.
  • Maybe I can just rename the file. Nope.
  • I will try opening fsmgmt.msc and see if the file is locked. Still no.
  • Alright, uncle! I give!

At this point, I thought I better start looking at this more closely. Right away I noticed something strange. The file is named .jpg. (dot-jpg-dot). It starts and ends with a period character.

I thought this was odd but I didn't understand how this would prevent me from removing the file.

After doing some research I discovered that the Win32 API does not allow a file name to end with a dot. NTFS will allow a file to end with a dot but the Win32 API blocks access to this. You can verify this by trying to save a file with the name ending in a dot. Windows will just drop the dot. If you try to save a file named "myfile.", you end up with a file named "myfile" sans ending dot. So how did I end up with this file on my server? Perhaps this file was put there by a Mac or a Linux machine which would not have to honor the Win32 API. I really don't know the answer but that is my best guess.

That is all well and good but what I really want to know is how to get rid of this file. I eventually ended up on this MSDN page. You can read it all if you want, but the short of the story is you can bypass the Win32 API by prefixing the path with "\\?\" which I will demonstrate below.

To delete a file that contains a dot or other illegal character in the name, open a command prompt type the following:

del \\?\C:\demo\.jpg. 



BLAMO!!! The file is gone!

Neat, huh? You will have to substitute your drive letter, path, and file name. If there are spaces in the path then you can wrap it in quotes. I've tried this on Windows Server 2003 R2, Windows Server 2008, Windows XP, and Windows 7. I think it will work on all modern versions of Windows.

While it took me too long to figure it out, it is a handy trick to have in your arsenal. If you want to have some fun with your friends, try running this command:

echo This file cannot be deleted. > \\?\%USERPROFILE%\Desktop\you-cannot-delete-this.

But I don't think you would want to do that...