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 definately 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.
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 definately 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.
Keywords:
0 comment(s)
Christmas Botnet Follow-up
In response to yesterday's diary entry on the drop in botnets right before Christmas, Claude wrote to us with an interesting theory. Here is what he said:
From the dshield reports, I do also see a (small) drop in the number of scans during the last day, both at home and on the office firewall, about 10% less sources & hits.
My thoughts to explain this drop are the following : the new (unpatched) computers replaced the old (infected) ones, so the global number of bots has decreased. 99.9% of the new computers must be Windows XP SP2 with firewall turned on - and that's why the new computers are not yet infected. XP firewall does a fair job in protecting a computer from the most common attacks *from the outside* (137,139,135 & 445 are closed), allowing to visit windowsupdate and download the missing patches.
So my assymption is that 99% of the new computer will stay clean ... at least until their users begin to click each and every popup on the screen, install an IM program and receive xmas & ny wishes in their mailboxes.
My guess is we will see a slow rise in the botnet size over the next month, until most of the new computers are infected again with malware - not because they were unpatched from the start, but because the users received no education with their new toy. Why can't you buy that at Walmart too ?
Great analysis, Claude! I think you've nailed it. Many of the infected machines are turned off, the new shiny ones have not been infected, and the Internet is momentarily a safer place. But like you said, give it a few weeks and we'll be right back to where we started from.
Marcus H. Sachs
Director, SANS Internet Storm Center
From the dshield reports, I do also see a (small) drop in the number of scans during the last day, both at home and on the office firewall, about 10% less sources & hits.
My thoughts to explain this drop are the following : the new (unpatched) computers replaced the old (infected) ones, so the global number of bots has decreased. 99.9% of the new computers must be Windows XP SP2 with firewall turned on - and that's why the new computers are not yet infected. XP firewall does a fair job in protecting a computer from the most common attacks *from the outside* (137,139,135 & 445 are closed), allowing to visit windowsupdate and download the missing patches.
So my assymption is that 99% of the new computer will stay clean ... at least until their users begin to click each and every popup on the screen, install an IM program and receive xmas & ny wishes in their mailboxes.
My guess is we will see a slow rise in the botnet size over the next month, until most of the new computers are infected again with malware - not because they were unpatched from the start, but because the users received no education with their new toy. Why can't you buy that at Walmart too ?
Great analysis, Claude! I think you've nailed it. Many of the infected machines are turned off, the new shiny ones have not been infected, and the Internet is momentarily a safer place. But like you said, give it a few weeks and we'll be right back to where we started from.
Marcus H. Sachs
Director, SANS Internet Storm Center
Keywords:
0 comment(s)
Taiwan Earthquakes cut undersea cables
A number of readers submitted reports of Internet slowness to/from Asia. We now know that this is a direct result of up to six submarine cables being severed during a series of temblors off the coast of Taiwan. From Bloomberg:
"Taiwan was jolted by three earthquakes yesterday, killing two people
and injuring 42 others, the island's National Fire Agency said. The
tremors damaged undersea cables, causing a disruption to Internet
traffic and some telephone calls in the region for customers including
Singapore Telecom, PCCW, Chunghwa Telecom Co., Taiwan's biggest
telephone operator, and KDDI Corp., Japan's second-largest telephone
carrier."
Our thoughts and prayers go out to all who have been lost or injured in the quakes and to their friends & families.
"Taiwan was jolted by three earthquakes yesterday, killing two people
and injuring 42 others, the island's National Fire Agency said. The
tremors damaged undersea cables, causing a disruption to Internet
traffic and some telephone calls in the region for customers including
Singapore Telecom, PCCW, Chunghwa Telecom Co., Taiwan's biggest
telephone operator, and KDDI Corp., Japan's second-largest telephone
carrier."
Our thoughts and prayers go out to all who have been lost or injured in the quakes and to their friends & families.
Keywords:
0 comment(s)
US President Ford Dies
The news is breaking, and only a few sites are carrying the story. Former US President Ford died a few minutes ago. Details will be coming out soon on all of the major news outlets. Our condolences to Mrs. Ford and the Ford family.
Marcus H. Sachs
Director, SANS Internet Storm Center
Marcus H. Sachs
Director, SANS Internet Storm Center
Keywords:
0 comment(s)
×
![modal content]()
Diary Archives
© 2024 SANS™ Internet Storm Center
Developers: We have an API for you! 
Comments