|
Introduction
Not too long ago when talking about network security tools like Snort or Nmap, those of us in the Windows world were often left on the outside looking in. The problem was that those tools simply were not available for any Windows platform. But recently things have changed. Snort, Nmap, Ngrep, and many other network security tools have been ported to the Win32 platform. Finally we can play too.
In a world of bloated applications and cluttered windows, the simplicity of a command-line tool such as Snort can be attractive. I am a Windows user and yet I find myself frequently opening up the command prompt for some MS-DOS action. The simple elegance of running the 175K Snort executable on a command-line is much preferable to a memory-hogging Windows application that is not any easier to learn or use.
It's this simplicity that makes Snort so popular. It is simple and yet it has enough power to protect a good-sized network. It does not try to be everything - it does one job and it does it efficiently. It watches network traffic, looking for rule-based intrusion signatures, alerting and logging when a match is made. There is no GUI, no reporting engine, and no pop-up help file, just a simple command-line utility that sniffs traffic and keeps on sniffing until you tell it to stop. Although there are those who would consider this a weakness, it is exactly what makes it so versatile and so powerful.
Snort - A Brief Overview
Martin Roesch developed Snort in 1998 for Unix platforms. Dubbing it a "Lightweight Intrusion Detection System," Martin made the tool open source and the number of people using Snort has been growing ever since. In the summer of 2000, Mike Davis created the first Win32 port of Snort, bringing a great tool to a whole new world of Windows users and bringing a world of Windows users to a different understanding of security. The tool has a small memory footprint and normally uses very little CPU power to do its job. The application runs quite socially with other applications, very rarely crashing or causing other programs to crash. And best of all, it is completely open source and free for anyone to use.
However, as with any security tool, it is easy to feel a false sense of security once it is up and running. One must appreciate Snort for what it is and use it for its strengths, namely sniffing traffic looking for attack signatures. It must be remembered that Snort will only serve as one component in an effective security strategy: firewalls, log analysis, and good security policy are still important aspects of a secure network.
Using Snort
Snort's uses are widespread and varied, including network intrusion detection, protocol analysis, troubleshooting, controlling unauthorized applications, and even password sniffing. Depending on the rule-set and configuration used, Snort can be an invaluable tool for both network and security administrators. One thing that Snort is particularly good at is watching a web server for web-based attacks. It can run on the web server itself or on another computer within that same network. And with the right rule-set, very few attacks will go by undetected.
The most difficult part about using Snort is getting it installed and running. Snort and the Winpcap drivers must be installed manually and require a reboot of the computer. Although everything usually installs without problems, there are the occasional configurations that need some tweaking. To test your install, open a command prompt and from the Snort directory type: "snort.exe -dve". Then, open up an Internet browser window, or use some other network tool. The command prompt window should instantly be filled with network packet captures. If that is what you see, then you are in business. If Snort does nothing or you get an error, then you must go back and retrace your steps to see what went wrong.
The first decision to make when using Snort is where you are going to run it. Snort can listen to all traffic to one computer or it can put the network adaptor in promiscuous mode and listen to all traffic on the wire. The amount of traffic it has to analyze can effect its performance. With that in mind, I prefer to have one copy of Snort with a large rule-set running on the web server listening only to that computer's traffic. At the same time, I keep another copy running in promiscuous mode with a more general rule-set on another network computer. That way, the computer that is exposed to the Internet has a larger rule-set to monitor, but monitors fewer packets, i.e. only those that are directed at that computer. On the other hand, the copy of Snort running on the network will monitor the whole network but will have a smaller rule-set to process.
It is also important to consider what command-line options to use while running Snort. Using fast alerting, logging to TCPDUMP format, and avoiding the use of verbose mode will all help to speed up Snort to handle medium to large-sized networks. Refer to the Snort documentation for a complete listing of all the options and their descriptions.
Another decision the user will have to make is how to launch Snort. Sure, you can open up a command prompt and run it there but the command prompt window must remain open while Snort is running. On Windows NT/2000 the more efficient method is to run it as a service. Running Snort as a service allows you start and stop Snort from the command prompt.
Another option, and one that works better with Win9x computers, is to use Xato's freeware snort.panel tool. Snort.panel has been designed to set Snort options easily, as well as to monitor Snort and the logs it creates. Snort.panel will launch Snort in the background and flash a tray icon when alerts are logged.
Finally, although Snort is hardly a resource hog, it does use CPU time, memory, and potentially a huge amount of disk space. If a system is already overloaded, it obviously would not be a good place to run Snort. You should consider how much space you want to dedicate to logs and be sure you have plenty of space to store the logs.
Rules Strategy
A well thought out rules strategy is crucial to the effective implementation of Snort. Rules establish the parameters within which Snort operates. Without a rules file, Snort will log all packets that it sniffs on the wire. As this would create an enormous amount of information, users must give Snort a rules file that clearly defines what to log and when to alert.
The rules file is the guts of the system and determines how effective it will be. Developing an effective, efficient rules file is crucial, it is also tricky. A rules file cannot be so complete that it creates too many (often false) alarms, thereby causing alerts to be ignored. On the other hand, it must be complete enough to detect a wide range of attacks. For this reason, it is important that the user have a clear understanding of what he or she wants to accomplish with Snort, and to configure the rules file for optimal attainment of those objectives.
Rules should also be optimized so that Snort does not put too much of a load on the system. Snort is a program and programs require CPU time. The more code a program runs, the more CPU time it requires. If there are many network packets to compare against a large rule-set it will take more CPU time that a small rule-set. Ultimately, your network configuration and traffic load will determine what size rule-set will work best for you, but careful consideration should be given to your rules strategy. You must know your network and customize the rules for your particular needs.
One thing users avoid doing, is to download the generic rule-set from the Snort web site and blindly implement it. By doing that, you will probably get many false alerts while letting many attacks go by undetected. Even worse, this may create a false sense of security that could prevent you from implementing other security measures. If you do not want to bother with making your own rules, perhaps Snort is not the best tool for you. (In fact, if that is the case, you do not deserve to use Snort.)
In addition to the number of rules, it is also important to consider the complexity of the rules. Rules that use the "content" option are much more complex than other rules. Content matching requires many CPU instructions and loops. To lighten the load, users can include rule options that are less processor-intensive, such as the "flags" option. Web requests will have the PSH and ACK flags set by using "flags:PA" before the content option; as a result, the "flags" criteria must be matched before the content. If it does not pass the "flags" criteria, the content match will not even be performed.
Keep in mind that the order in which the options appear in the rule will affect the order in which they are evaluated. This is a common source of user error, and it can have a negative effect on the rule performance. On rules that are checking for web attacks, you may want to limit the destination to the specific IP address of your web server, which will keep many packets from having to be checked, therefore further lightening the load.
If you look at IIS vulnerabilities, you will see that many rules can be combined to make a more efficient rule-set. For example, there are several vulnerabilities in the iissamples and samples directories. All of these could be combined by simply checking for the content "samples/" within a packet destined for port 80. This will alert when any of the following requests are made:
/iissamples/exair/howitworks/Codebrws.asp /iissamples/exair/howitworks/Code.asp /iissamples/exair/howitworks/Codebrw1.asp /iissamples/sdk/asp/docs/codebrws.asp /iissamples/sdk/asp/docs/codebrw2.asp /iissamples/query.asp /iissamples/exair/search/advsearch.asp
To take that concept even further, you could make it simply match on "samples/" and also get the following urls:
/samples/search/queryhit.htm /adsamples/config/site.csc /scripts/samples/search/webhits.exe /msadc/samples/adctest.asp /scripts/samples/details.idc /scripts/samples/ctguestb.idc /msadc/Samples/selector/showcode.asp /Sites/Samples/Knowledge/Membership/Inspired/ViewCode.asp /Sites/Samples/Knowledge/Membership/Inspiredtutorial/ViewCode.asp /Sites/Samples/Knowledge/Push/ViewCode.asp /Sites/Samples/Knowledge/Search/ViewCode.asp
In this way, through careful planning, you can easily turn eighteen rules into a single rule. Certainly, you do not have the granularity in your alerts, but if someone is looking for sample files on your web server, do you really care exactly which file they are looking for?
Another decision to be made in rule selection is whether you should include rules matching vulnerabilities for other web servers such as Netscape or Apache. Some users argue that if an attack is not something that affects your web server, there really is no point in being alerted if someone scans for it. For example, one may choose to leave off cgi-bin rules if they do not even have a cgi-bin directory on their web server. The other side of the argument is that an intrusion detection system should warn of an attempted attack, regardless of whether it would actually have succeeded. If your strategy is to keep the rule-set trim, then you may only want to check for a few of the most common scans intended for other server types, especially those that do not produce many false alerts. On the other hand, if you are finding that you have enough system power to spare you may want to throw in just about anything you can. The balance is to get enough pre-warning of an attack without producing too many false alerts.
A full discussion of the intricacies of implementing an effective rule-set is beyond the scope of this article. For complete instructions on using Snort rules, refer to the document Writing Snort Rules.
Conclusion
Through the implementation of carefully considered rules and smart rule strategies, you can detect, log and minimize most IIS attacks before they become too serious. You can also have a better picture of what is happening on their web site. You can catch script kiddies before they can inflict meaningful damage on a user's site, and even the more advanced attackers will generate a few alerts. You will pick up on all kinds of network abuse, coming from the outside as well as from within. All from a tiny command-line tool named Snort.
To read Running Snort on IIS Web Servers Part 2: Advanced Techniques, click here.
|