Wednesday, November 16, 2011

Using Snort

One of the goals for me in my current position was to meet a number of requirements to be able to get insurance for our data center installation. The insurance form had a ton of questions, such as "Is your wireless secured? What is it using?" and "Do you have a Written Information Security Policy? How is it shared with users?". Obviously you want to be able to answer yes to most of the questions, otherwise chances are you won't get approved for the insurance, so I've been working my way down this list and trying to change our infrastructure and/or practices to be able to answer yes, within reason. This has led to investigating options for an IDS/IPS system.

I've never worked at a place that had such a system. Even for the largest company that I've worked for we didn't have anything like that, and only started tossing the idea around when PCI compliance became a mandatory goal.

As always I started my search off with Google, and solutions varied from expensive hardware solutions to open-source software solutions.
Being a small company without a lot of bread to burn, the latter was the clear choice for further investigation. By far the overwhelming recommendation here was Snort. A few others were mentioned, like OpenVAS, but Snort seemed to have the most documentation and the best track record in terms of actual implementation. As I've said before, if you're going open-source I think it's best to use tried and tested open-source, even if it's not bleeding edge, because your only support will be the community in most cases.

I set up a CentOS box for my installation. Why did I forgo Ubuntu here? I just wanted to do something different. I like CentOS, I enjoy working with it, I think it tends to be more lightweight than standard Ubuntu installs...and I found an excellent guide on setting it up on Snort's site. With it I had a working Snort installation within a day.

Getting it installed is only half the battle however. An IDS is only as good as your understanding of how to use it. I was nervous to test it out as well because I didn't know how much of the IPS part was out-of-the-box functionality. I tested it on a test network and it seemed to do no harm, so I mirrored the uplink port on my switch to another port, connected the Snort system to it, and watched the alerts rolls in.

The guide I followed used BASE for reporting, and it wasn't long before I saw the TCP graph turn completely red. Snort had already logged hundreds of alerts. I was not seeing any packets dropped, and there was no report of issues on the network. That told me that the default setting for Snort was rather conservative, and it would not drop suspect packets until you told it to, which is good. Snort comes with a pretty extensive ruleset, and it will take a while to go through and determine which ones you want to have active, and how you want Snort to handle events that match those rules. It's highly recommended to craft your own rules based on the specifics of your network. I read a whitepaper about how you should run Snort over the weekend and then for an hour during the middle of a work day to compare traffic to see what's legit and what's not so you can tailor your rules that way. This is a great idea in an environment where you have someone who can dedicate the time, but for a one-person IT department it's a difficult assignment. Heck, simply keeping on top of an IDS system is going to be difficult.

Anywho, the majority of the alerts I received were "http_inspect: OVERSIZE REQUEST-URI DIRECTORY". I'll talk more about what this actually means in another post, but there is contention between whether or not this is a legitimate alert or whether the buffer size is simply too small for modern websites. Other than that I also see a ton of DNS spoof alerts, likely due to configurations on my firewall. Either way, these will all require time and attention, which is definitely one of the challenges of implementing such a system. One of the features I like the most about BASE is the ability to drill down into alerts and use links to take you directly to sites that give you more information about what the alert means. You can also click on source or destination IP addresses and get WHOIS information. These features help some so I can immediately see if an IP belongs to one of our clients, which will generally tell me I don't have to be too worried...yet.

I was curious though. I've seen a number of mining attempts in our Apache logs—like looking for phpmyadmin or various  default web files—and I was surprised not to see any of them reflecting in Snort. I guess in reality there was nothing wrong with the requests themselves and Snort would have no way of knowing they were mining expeditions since they didn't match any specific malicious signatures. But it seemed to me a good idea to make sure Snort was actually working, so I set out to test it.

One of the first things I did was to make use of a tool called IDSWakeup. I installed it on my Nagios box and went to work. It didn't cause any alerts. This troubled me. IDSWakeup makes use of two individual pieces, one of which is called hping. I looked into testing using hping by itself to rule out any possible configuration/compile problems with IDSWakeup, and found some specific examples of commands to use from Symantec. Again I got no response in my sensor. Increasingly not good.

My next thought was that I was perhaps, in using canned examples, testing rules that weren't actually activated on my sensor. I needed to craft my own packet, specific to my needs. I checked my rules and found a fairly straight-forward one regarding outbound telnet attempts. I found nping and http://nmap.org/ to help me craft the packets, and I still got not hits on my sensor. In the meantime, it wasn't like the sensor was inactive completely. It would still log the occasional http_inspect alert above, as well as a rule that didn't exist in the Snort database (traffic was from my machine thankfully) and a few "FTP malformed parameter" alerts. It was logging something, but not sure why it wasn't catching other things.

I've since posted to the Snort mailing list. Disappointingly I've not received a single response to my question, while other posts after mine have. I have also found another article on InformIT that teaches how to create a very basic rule that is supposed to be a surefire way to test whether or not your Snort installation is working. I'm reading that entire chapter as well as delving into the Snort: IDS and IPS Toolkit.

No comments:

Post a Comment