The Snort Top 10

I work with SNORT®..... constantly. It's my job to do so. I've been using Snort for many years, I teach classes on how to configure it, I teach classes on how to write Snort rules. I've been using Snort and setting up Sourcefire and Snort devices on hundreds of different networks for years on end now.
 
I am frequently asked questions, many of the questions are the same things over and over again, and I always see the same mistakes being made when setting it up. So, i've compiled a list of the top ten mistakes and commonly misconfigured or overlooked things when configuring everyone's favorite IDS.
 
None of these override the necessity to read the Snort manual, however. The manual supersedes all Snort books, because as great as these books are, they can't keep up with the fast-paced updates at which Snort is updated. So here goes...
 
1. The Snort.conf file.
Almost all your options are set in this file. This file should be read line by line, from top to bottom, taking the time to fully understand what each one of the configuration options are. 90% of all the questions I get can be answered by just reviewing the documentation in the snort.conf file.
 
2. Variables.
At the very top of the Snort.conf file there are variables to be set. The very least of which is "HOME_NET". HOME_NET should ALWAYS be configured. Depending on the placement of your IDS, your HOME_NET is loosely interpreted as "whatever the Snort box is protecting". For instance, on my network, it's 192.168.1.0/24. The whole network is controlled by my router, and no other IP addresses should be on the network unless it has this range. If I *had* other IP's pop on my network, I would definitely not want them treated as mine! Common settings for HOME_NET may be your whole internal network range, such as any RFC 1918 addresses. Depending upon the placement of your sensor (such as at your border) you many want to have your public IP address space in your HOME_NET as well. Remember that only CIDR notation is accepted within the variable notation. 192.168.1.1:254 won't work, neither will 192.168.1.1-254. Only 192.168.1.0/24 will. Another big thing to note is your setting for EXTERNAL_NET. By default, EXTERNAL_NET is set to "any". "Any" includes your HOME_NET. In order to make Snort treat traffic that is NOT in your HOME_NET as EXTERNAL, you can set your EXTERNAL_NET to "!$HOME_NET". Which setting applies to you is dependent upon the placement of your sensor.
 
3. Frag3 preprocessor.
Snort is able to avoid many different types of evasions. One of the big ones that people think they can slip by on any IDS is through IP fragmentation, or using malicious overlapping and underlapping fragments in order to slip the payload past your IDS's, but have it reassembled correctly on the target.
 
Okay.. I realized I may have just thrown a big ball at you... Let's back up.
 
IP fragmentation is when Packet A on Network A is too big to go onto Network B. So the router on the Network A side splits Packet A into Packet A.1, A.2, A.3, and so on, so it's able to fit onto Network B. However, these smaller packets aren't put back together until they reach the final destination IP. Still with me so far right? Cool...
 
The problem with that is, different operating systems put fragmented packets back together in different orders depending on the type of operating system. (and you thought they were all the same!) Well, the problem with IDS's is, they have absolutely not idea what the Operating Systems are that they are protecting. Frag3 allows you to tell it. Now, without writing a book about the subject, you need to go into the docs/ directory that is enclosed with your Snort tarball and read the README on frag3. (As well as the accompanying section in the Snort manual.)
 
However, in order to FULLY understand what I am talking about, go read the whitepaper written by Judy Novak. (You have to register to download it) She's one of the authors of the SANS 503 IDS course, one of the designers behind frag3, and currently a Vulnerability Research Team (VRT) employee at Sourcefire.
 
4. HTTP Inspection preprocessor.
The most misunderstood preprocessor there is. This preprocessor analyzes, normalizes, and alerts on http traffic. The thing to remember is, it's SERVER based. It's meant to analyze traffic coming inbound to your http SERVERS. It basically has two settings, the "global default" setting, which you should set to the majority of your web servers. For instance, are most of your web servers IIS, on port 80?  Then you need to set that to the global setting.  If only some of your web servers are not IIS, or  only some of them are not on port 80,  then those need to be specified INDIVIDUALLY, by IP! Does that mean you will have to create a separate line for each of your "non-standard" web servers? Yes! That's the way it's SUPPOSED to work!
 
5. Portscan preprocessor.
Also very mis-understood piece of code. You need to read the README for the "sfportscan" preprocessor in the docs/ directory. There is no better explanation on how to configure this preprocessor.
 
6. The rest of the preprocessors, to include the new "dynamic" preprocessors.
All of the preprocessors have configuration lines. Each need to be configured to the networks you are protecting with Snort. Review the documentation for each of them extensively. All the documentation is well written, and is written with the user in mind.
 
7. Rules.
The Rules in Snort are key. At the bottom of the Snort.conf you will see a bunch of "include" lines. "include $RULE_PATH/web-iis.rules" for example. This line will call the rules file web-iis.rules and load it in at runtime. Alot of people ask "what is the best ruleset to run?" Well, by far the first and foremost ruleset to run the VRT ruleset available after registration here. However, does this mean that you need to run every rule in that ruleset? NO! Take a look at the categories.. pop3.rules, imap.rules, oracle.rules, web-coldfusion.rules, pop2.rules, mysql.rules.. etc... Do you run these services on your network? Do you run pop3? Do you run pop2? Do you run imap? No? Then turn the rule category off! There is no sense in running rules that have no application to your network! All you are doing is potentially creating more work for yourself through false positives, as well as making the Snort engine work harder then it needs to.
 
"But I hear there are other rulesets besides the VRT set!" YES! There are. There are basically two. The BleedingThreats set available at www.bleedingthreats.com and the Community ruleset. Each of these rulesets is contributed to regularly by YOU the Snort community and each have their own pros and cons. Should you run all three rulesets? Sure! However, you need to go through each rule file, and turn on/off what you are not interested in or what does not apply to your network. For example, do you have Vertias on your network? No? Then go into exploit.rules and shut off the Veritas rules.
 
8. Output.
Snort can output to syslog, to pcap format (default), to a database, or lastly, to Unified. The "official" recommendation is to unified. The unified file format is the fastest output format coming out of the backend of Snort. Especially when you are trying to output to database! When Snort has to output to a database directly, it has to perform an INSERT into the db... doing so is CPU intensive. Do you want your IDS to be an IDS? Or a database insertion tool?  So use Unified! Well, the problem with unified is, you need something that reads unified file format and outputs it into the db, or tcpdump file format you want....
 
9. Barnyard (or FLoP)
Barnyard reads the unified file format and inserts what it finds into a db, or outputs into tcpdump file format. FLoP is another tool that also reads Snort's output (albeit in a different method) and does what you want with it. Both are excellent tools and both need to be checked out and use the one that's appropriate to you.
 
10. Rule updates.
However you choose to update your rules is up to you, I recommend Oinkmaster. Nice perl proggie to keep your rules up to date. Just don't forget to register on Snort.org and get your oinkmaster code if you wish to download the VRT registered user set.
 
Notice that I didn't put a recommendation for any type of Snort log reviewing tool. BASE, Sguil, Placid, etc.. all have their merits and you will want to check out the one that is most appropriate to your situation. However, I do have one recommendation that I will make here... and it's turning into more of a "RULE" now. Do NOT use ACID. Don't get me wrong, ACID was great for it's day, however, with over 200+ bug fixes, feature implementations, and the fact that ACID hasn't been updated in.. going on 4 years now... go with BASE if all you are looking for is an Alert browser. BASE works with your existing ACID db, and is very easy to upgrade to.
 
So there you go. I hope this helps a bit to get you started down the correct path of tuning Snort. Don't forget to hit the mailing list archives, post to the mailing lists with any questions, look for your local Snort User Group, visit the Snort Forums, or even write into us here at the ISC (several of us use Snort constantly, not just me).. or drop into irc.freenode.net into #snort and say hello! Thanks!
 
Stay tuned for another article on Snort in the future.. If you have suggestions about what I should write about as far as Snort goes, feel free to write in!
 
/** Joel Esler **/
 
Sourcefire and Snort are registered trademarks of Sourcefire.

Are CAC (Common Access Cards) worth it?

A buddy of mine Richard Bejtlich, a known security blogger and consultant, had this article on his blog... I made a big long comment about it.. displayed below, and linked above...

--- begin ---

Yes. The CAC is used for signing on, email signing and encryption, web authentication, basically anything that can be done, or is done with a certificate.

It's only being used in NIPR (Unclassified) systems. It has a magnetic strip on the back that is blank, and can be coded for swipe doors at whatever location you are currently working at.. (problem is, most DOD facilities have proximity cards).

Could this be implemented in a commercial setting? Yes. But at what cost? What what expense? What do you gain out of it? When I worked for DOD, all I got out of the deal was a headache... implementation, it became our ID, which.. only SOME people accepted (like, the gate guards on post wanted our Drivers License sometimes -- grrrr) going to get a new one every three years, using it for sign-on, using it to get in the building. Here's the kicker. Say you left it in your computer at night, your computer would screensaver lock after a while, no problem.. but you couldn't get back in the building the next day!

Annoying is the key. I never liked it. The Email signing and authentication never worked across all platforms with ease. Doesn't work with ALL email clients. (and IMO, trying to say something like "well everyone MUST use OUTLOOK" is not an answer, it's a 'way out'.) Ours didn't work with sign on to the network. The only feature about the CAC that I DID like, is when I walked away from my computer, I took the CAC out of the reader, and viola... my computer locked.

That was about it. Now. You know whats kinda cool (but involves us going back to terminals), is Sun's (yes Sun Microsystems, as much as I hate Sun...) card that you can carry from machine to machine and wherever you plug it in.. you can call up YOUR desktop. That's a descent idea. However, no one likes dummy terminals. I digress.

Could it be done? Yes. Is it worth it? No. Not in my opinion.

Are CAC (Common Access Cards) worth it?

A buddy of mine Richard Bejtlich, a known security blogger and consultant, had this article on his blog... I made a big long comment about it.. displayed below, and linked above...

--- begin ---

Yes. The CAC is used for signing on, email signing and encryption, web authentication, basically anything that can be done, or is done with a certificate.

It's only being used in NIPR (Unclassified) systems. It has a magnetic strip on the back that is blank, and can be coded for swipe doors at whatever location you are currently working at.. (problem is, most DOD facilities have proximity cards).

Could this be implemented in a commercial setting? Yes. But at what cost? What what expense? What do you gain out of it? When I worked for DOD, all I got out of the deal was a headache... implementation, it became our ID, which.. only SOME people accepted (like, the gate guards on post wanted our Drivers License sometimes -- grrrr) going to get a new one every three years, using it for sign-on, using it to get in the building. Here's the kicker. Say you left it in your computer at night, your computer would screensaver lock after a while, no problem.. but you couldn't get back in the building the next day!

Annoying is the key. I never liked it. The Email signing and authentication never worked across all platforms with ease. Doesn't work with ALL email clients. (and IMO, trying to say something like "well everyone MUST use OUTLOOK" is not an answer, it's a 'way out'.) Ours didn't work with sign on to the network. The only feature about the CAC that I DID like, is when I walked away from my computer, I took the CAC out of the reader, and viola... my computer locked.

That was about it. Now. You know whats kinda cool (but involves us going back to terminals), is Sun's (yes Sun Microsystems, as much as I hate Sun...) card that you can carry from machine to machine and wherever you plug it in.. you can call up YOUR desktop. That's a descent idea. However, no one likes dummy terminals. I digress.

Could it be done? Yes. Is it worth it? No. Not in my opinion.

A Question for my readers

Please describe to me.. At what point does security become an operational burden?

When too many passwords, authentication mechanisms, log-on tokens, segmentation..etc... mount up.. what what point do you just say "hey, you know, this sucks!"

Please leave comments.

A Question for my readers

Please describe to me.. At what point does security become an operational burden?

When too many passwords, authentication mechanisms, log-on tokens, segmentation..etc... mount up.. what what point do you just say "hey, you know, this sucks!"

Please leave comments.

Christmas, and the holiday spirit, and Internet security

Recently, since we've all been shopping, out there paying attention to gifts, what we are going to get, and what we aren't going to get. An attack has been going on. Apparently, against my web server.

I review my weblogs (I review all my logs) on a weekly basis. Because really, what's the point in having logs if you're not going to look at them? A log that isn't looked at is a pointless log. You might as well shut off syslog if you aren't going to look at the logs. But I digress.

I review my weblogs. I have mod_security installed on my apache webserver here, so through my custom mod_security rules, I am provided with audit_log in my logging directory.

I usually get about 200 to 300 entries a week in that file. All denied.

Last week that number jumped to almost 9000. As of this morning (my logs roll over on Sunday), I had over 3000.

As I am on my blackberry I don't have a copy of the logs, so I'll post a sample entry later.

But the string I see a lot is "x-aaaaaaaaaaa" in the header.

Anyone else seeing these?

Two words for Delta....

In reference to your Crown Rooms, take a note from your partner Continental...

FREE INTERNET

who makes up these rules?

On some flights, you can't have your phones with the wireless turned on.
Then some you can't have them on at all.
On ASA you can't fly with the windows shades down, but on delta you can.
Today we were told that laptop computers had to be completely off, and NOT in the standby mode.

Why can't we just have one set of rules? Everyone the same. The flight attendants all having the same info, so we don't have flight attendants just making stuff up arbitarily?

FAA -- is this so hard?

Two words for Delta....

In reference to your Crown Rooms, take a note from your partner Continental...

FREE INTERNET

who makes up these rules?

On some flights, you can't have your phones with the wireless turned on.
Then some you can't have them on at all.
On ASA you can't fly with the windows shades down, but on delta you can.
Today we were told that laptop computers had to be completely off, and NOT in the standby mode.

Why can't we just have one set of rules? Everyone the same. The flight attendants all having the same info, so we don't have flight attendants just making stuff up arbitarily?

FAA -- is this so hard?

0wned

0wned

Excellent Patent Article

This article is an excellent article on patents concerning Apple and the GUI and stuff. Really interesting stuff.

Excellent Patent Article

This article is an excellent article on patents concerning Apple and the GUI and stuff. Really interesting stuff.

Apple needs to go to a subscription model? Pullleeezz

Hey dude, Apple owns 75%+ Market share. I am pretty sure that they know what the hell they are doing.

Apple go to a subscription model?

Apple needs to go to a subscription model? Pullleeezz

Hey dude, Apple owns 75%+ Market share. I am pretty sure that they know what the hell they are doing.

Apple go to a subscription model?