As a side project, I have been setting up SNORT on a small network. The nice thing about this setup is also the annoying thing: it will never touch any other network. This is nice in a sense that traffic seen by the sensor will [hopefully] only be originating on the network and/or its interfaces. However, the annoying thing is that 99% of the packets ever viewed by SNORT are going to be normal traffic for the network. This means that the chances of anything of interest being in the logs is slim to none!
The initial setup of SNORT was actually done by someone else. I had been testing an earlier version, 2.4, successfully before we moved this to the production environment. What I didn't know was that version 2.8.4 was the one installed. There were some minor differences in the snort.conf file, but other than that, there was nothing specific to worry about for our environment.
When 2.8.4 was installed however, there were some issues that were unkown at the time (I had to leave town directly after the install). Apparently, when the installation happened and the tar files were decompressed, they were put, by the operator, into the wrong file location. With that in mind, the sequence of events goes like this:
1) SNORT installed initially
2) SNORT configured to run as a service (so the installer thought) :-)
c:\Snort\bin>snort.exe /SERVICE /INSTALL -c "c:\snort\etc\snort.conf -l "c:\snort\log" -A full -i2 ideX
3) SNORT set to start "Automatically"
- Here is where the problem/bug(?) was
At this point the installer verified that SNORT was capturing packets (with no attempt to trigger alerts). However, what the installer failed to realize at this point was that the log file being created was snort.log.XXXXXXXXXX, as opposed to the name we had set in snort.conf.
4) Returned from trip and started verifying that SNORT was running properly, or in this case, NOT running properly.
5) Investigated why SNORT was not logging packets to the right file, why it was logging all packets, and why NO alerts had been triggered over a ten day period. (With a full rule set and some of the required user actions, something should have triggered)
- I, after talking with the SNORT genius Doug Burks, stopped the SNORT service
- I restarted SNORT (in IDS mode) manually from the command line using:
>snort.exe -c "c:\snort\etc\snort.conf" -l "c:\snort\log" -A full -deX
- At this point, I realized I had a problem. Multiple errors with the snort.conf file reported.
- These errors all resolved to issues with preprocessor items.
- After some investigating, I realized that the structure of c:\snort was severly messed up! This is why at run time I was getting multiple errors...the files were not where they were supposed to be.
- In the interest of time, I removed SNORT completely and re-installed, paying attention to the folder structure from the tarballs.
- I then restarted SNORT manually using the same command as above.
- I then used HPING2 to craft some packets and sent them on their merry way.
- I also used the windows NMAP, ZenMap, to fun some noisy scans against some boxes.
- At this point, things were golden, SNORT was properly acting in NIDS mode, and all was right in the world.
6) I reconfigured SNORT to run as a service, using the command above (#1 ).
7) Took a much needed nap.
Lessons Learned:
1) Do not let someone who has never used or configured SNORT install it for you, unless you are present to help! (I should say that I didn't have a choice here)
2) When installing SNORT as a service, if the snort.conf cannot be built at runtime, SNORT will default into packet logger mode.
- ALWAYS test your deployment manually before running as a service!
- Look at the logs in \snort\log
- if they are named "snort.log.XXXXXXXXXX" then you are probably running in logger mode (a good way to know is to assign a name to the .log file in snort.conf that will be obvious to you when it is working correctly)
3) Pay close attention to the path variables in the snort.conf file...they are your friend for configuring SNORT.
No comments:
Post a Comment