| Downloads |
|---|
| 26449.zip |
Intrusion Detection Systems (IDSs) are an important part of any network. One free, open-source tool for implementing an IDS on networks is Snort. (If you're unfamiliar with IDSs, see Jason Harper, "Protect Your Network from Intrusion" and "Deploy Your Network IDS Effectively," http://www .secadministrator.com, InstantDoc ID 24650 and InstantDoc ID 25013, respectively.) To build a Snort server in a Windows 2000 environment, you need to install and secure Win2K Server, install Snort and its companion files, and test Snort's various modes.
Installing and Securing Win2K Server
To build a Snort server, you first need to secure the server's OS so that the OS doesn't become a victim of intruders' attacks. In IDSs, the OS typically resides outside a firewall's protection, so the OS needs to be both secure and invisible to intruders' probes. (Some administrators use two NICs to dual-home the Snort server, then connect the server to a port-mirrored switch or hub to transmit only. However, I think that having a system that's completely isolated from the main network is best. That way, the system can stand on its own outside a firewall.) Because Microsoft designed Win2K Server to be a platform on which applications run, the default setup creates an environment that maximizes the system's ability to offer services to the rest of the network. The security administrator's ultimate goal is to turn Win2K on the Snort server into an OS that's undetectable by attackers—a stealthy OS.
To create a stealthy OS, you need to start by installing Win2K Server from scratch. Be sure to delete all existing partitions on the hard disk and create new partitions. Also be sure to put a fresh Master Boot Record (MBR) on the hard disk. Both of these precautions are necessary to ensure that the system has no viruses or worms. The easiest way to accomplish both tasks is to use the Win2K Server CD-ROM to boot the system. When the setup program asks you where you'd like to put the system files, you have the option of deleting all the existing partitions and creating new partitions. Creating partitions this way lets you use the disk's entire capacity for one partition. The log directory that Snort creates can get quite large; therefore, bigger is always better in sizing partitions for IDSs. In the rest of the setup program, you can keep the defaults because you'll be disabling all unwanted services after you apply the service packs and patches.
When the setup program finishes, install Service Pack 3 (SP3) and reboot the system. After you reboot, go to the Windows Update site by clicking Start, Windows Update. Click the Product Updates link and install all the suggested updates, including those for Microsoft Internet Explorer (IE).
After you install the updates and reboot, you're ready to remove all unnecessary services through the Control Panel Add/Remove Programs applet. In this applet, click Add/Remove Windows Components and clear the Internet Information Services (IIS) check box. Removing this service closes the biggest hole in your system's armor. Remove other unnecessary services as well. (If you're unsure of which services to remove, check out Windows & .NET Magazine's free guide "Securing your Operating System—Guidelines for Hardening Windows 2000," http://www.itbuynet.com/pdf/0202-security.pdf.) The only Windows components I leave enabled are Accessories and Terminal Services (in Remote Administration mode). Although having Win2K Server Terminal Services violates the goal of having a stealthy system, I decided that being able to administer the system remotely is worth the risk.
Next, you need to secure the local hard disk and registry. To make the job easier, I created a Win2K security template that contains all the settings I want for an IDS. You can download this template from the Code Library at the Security Administrator Web site. If you need a quick tutorial about what templates do and how to use them, see Paula Sharick, "Security Templates Define and Enforce the Rules," http://www.secadministrator.com, InstantDoc ID 23375.
The template disables the services that an IDS doesn't need. For example, the template disables the Routing and Remote Access, Server, Print Spooler, and RunAs services. The result is that the Snort server will be missing some of the functionality you would expect on production servers.
One service that the template doesn't disable is the Remote Procedure Call (RPC) service. Several administrative tools (e.g., Computer Management, Event Viewer) use RPC to obtain information from the OS. If you disable the RPC service, these administrative tools don't work properly. However, if you leave the RPC service running so that you can manage the server, you must restrict access to the system services because the RPC service listens for connections on port 135.
After you apply the template, only ports 135 and 3389 (the port for Terminal Services) will be visible on the network. In addition, both the registry and the hard disk will allow only local Administrators group members and System account members access to crucial functions.
Although leaving ports 135 and 3389 active can alert an intruder to the IDS's existence, it doesn't defeat the purpose of having a secure system. Both ports require authentication before an intruder can access them, and the template makes unauthorized access more difficult three ways:
- The template requires users to create passwords 8 characters long and a combination of uppercase and lowercase letters, numbers, and special characters. If you want to decrease the chance of a successful dictionary or brute-force attack on the passwords, you can increase the required length to 10 or more characters.
- The template sets the account policies to allow five attempts to enter the password and a 30-minute wait time after five incorrect entries. That way, an account will be disabled for 30 minutes after an intruder makes five logon attempts. At best, an intruder could try 10 passwords per account per hour. If your IDS has only one or two active accounts, guessing a password will take a long time.
- The template removes the Access this computer from the network user right from all groups. The net effect is that even if intruders know the correct password, they can't log on unless they're sitting at the console. Removing this user right doesn't disable Terminal Services because Terminal Services uses the Log on locally user right and the Allow log on to terminal server account property to determine whether an account can log on to the server. In addition, when Terminal Services is in Remote Administration mode, only members of the local Administrators group can log on.
The combination of these three settings makes attacking the IDS through ports 135 and 3389 pointless. Managing the server is much easier with the RPC and Terminal Services services running, so leaving these services enabled is worth the small risk of attack on ports 135 and 3389.
Installing Snort and Its Companion Files
With Win2K Server installed and secured, you need to prepare your system for Snort. Snort, like many other effective security tools, is a Linux application that has been ported to Windows. Snort on Linux uses libpcap library capture drivers to read network packets. Rather than rewrite the packet capture routines from scratch, Snort for Windows uses the WinPcap library in place of Linux's libpcap packet-capture library.
WinPcap is a free download (http://winpcap.polito.it). Although the current version at the time of this writing is WinPcap 2.3, an early alpha release of WinPcap 3.0 is available. When you download WinPcap, you need to download WinDump as well (http://windump.polito.it/misc/bin). WinDump is a port of tcpdump, a Linux packet-logging tool. You can use WinDump to test WinPcap. Note that WinDump is a self-contained executable, so you don't need to run a setup program.
Unlike WinDump, WinPcap requires you to run a setup program. The setup program takes about 15 seconds. After installing WinDump, you might need to reboot the system. If WinDump or Snort can't find your NIC after installing WinPcap, rebooting the system should fix any problems.
WinPcap 2.3's packet capture driver won't be listed in the network connection's Properties dialog box. To determine whether WinPcap 2.3 installed correctly, open a command window and navigate to the folder in which you copied WinDump. Run the command
windump -D
to test WinPcap's installation. WinDump's parameters are case sensitive, so be sure to use an uppercase D. If you see a list of network interfaces, WinPcap is working. To double-check, click Start, Run. In the Run dialog box, type Msinfo32 and click OK. Click the Drivers folder in the System Software folder, then wait for the system to display a list of drivers. Find NPF and make sure the State column says Running.
One limitation of WinPcap 2.3 is that it doesn't support systems that have multiple CPUs. The setup program will tell you it was successful, and the driver will show up in Msinfo32, but WinPcap 2.3 never runs. WinPcap 2.3 fails to run because it checks for multiple CPUs during the driver's initialization phase. If the system reports more than one CPU, WinPcap 2.3 stops executing. Earlier WinPcap versions will run because they don't have that CPU check. However, WinPcap's FAQs state that you can get erroneous results if you run WinPcap 2.2 or earlier on a multiple-CPU system. Thus, you should run Snort only on a single-CPU system.
Assuming all went well with WinPcap's installation, you're ready to install Snort. You can download it from http://www.snort.org/dl/binaries. If you're just getting started with IDS, download the most recent stable version for Windows and leave the beta testing to the experts. As of this writing, Snort 1.8.7 is the most recent stable version for Windows. Next, run the setup program. You have six installation options:
- Snort-Barebones
- Snort-Flexresp
- Snort-MySQL-Flexresp
- Snort-MSSQL-MySQL-Flexresp
- Snort-MSSQL-MySQL
- Snort-MySQL
The Flexresp options install additional code that drops a connection that matches a rule. The code forces a disconnect by sending a TCP reset command to the offending computer. You can use the Flexresp options to stop an attacker from scanning ports or trying brute-force attacks against a server, or even to stop a user from connecting to a Web site. However, as of this writing, Flexresp is unproven code, so you might want to wait before you install those versions.
The MSSQL and MySQL options are special compilations of Snort that include support for logging network packets and alerts to a database. MySQL versions support the free MySQL open-source database for both Linux and Windows implementations. MSSQL versions support Microsoft SQL Server databases. Because the goal here is to create a standalone system, choose the Snort-Barebones option during installation. After you run the setup program, reboot the system.
If you want to use database logging at a later date, you can run Snort's setup program again, choose the Modify option, and install the version that matches the database system you want to use. When you log packets to the disk, be sure to use the -b parameter to write them in tcpdump binary format. The -r parameter lets you use Snort to process an existing log file and write the packets to the database.
Testing Snort's Modes
Snort has three modes: sniffing, logging, and intrusion detection. The sniffing mode works with both the logging and intrusion detection modes, so you should test the sniffing mode first.
Sniffing mode. Although Snort has a GUI, it's not a very good one. It's a rather confusing mess of commands and options, with little indication of what you need to do to run Snort. So I prefer to run the commands from a command window. For basic sniffing, using a command window is the only way to see the packets as Snort captures them.
Assuming you chose the default installation path, open a command window, type the command
cd \snort
and press Enter. After you're in the Snort folder, you can type
snort /?
to obtain a list of Snort's commands and parameters. The command you use for testing is
snort -d -e -v
Snort's parameters are case sensitive, so be sure to type the parameters in the correct case. You have some flexibility in regard to how you list the parameters. For example, for the command just given, you can combine the three parameters into one parameter
snort -dev
and obtain the same results.
After you run this command, packets should start scrolling in the command window. To see more than the default 300 lines of output, click the command prompt icon in the command window's upper-left corner and select Properties. In the Properties dialog box, select the Layout tab, enter 9999 in the Height field of the Screen Buffer Size section, and click OK. In the Apply Properties dialog box that appears, select Save properties for future windows with same title and click OK. Now, you can see 9999 lines of output in your command window.
If you're using wireless network adapters, be aware that WinPcap works with some 802.11b network adapters, but the results might not be what you would expect. Because 802.11b packets are the only packets that an 802.11b network adapter recognizes, you can sniff only wireless traffic. In addition, Snort sees only the traffic destined for the wireless NIC, which means you only see packets with the IDS's IP address as the destination and broadcast packets. WinPcap doesn't put 802.11b network adapters into the mode needed to see all the packets sent over the wireless network. If you want to see all traffic, you need to use a regular Ethernet network adapter.
Logging mode. Next, you need to test the logging mode. To determine whether you can log packets, you use the sniffing mode's command with the -l parameter. You use this parameter to specify the folder in which you want to store the packets. For example, if you want to store all packets in a folder named Log, you run the command
snort -dev -l log
Snort places the packets in subfolders named after the packet's source IP address. In the subfolder, Snort groups the packets according to their TCP stream number. With this logging arrangement, you can easily find the traffic coming from a particular computer. However, logging packets this way takes up a lot of room on the hard disk because the packets are written in text format. In addition, you can't look at traffic from multiple computers at the same time and analyzing the packets is difficult.
A better solution is to log the packets to a single file in tcpdump binary format with the command
snort -dev -b -l log
To read the packets, you run the command
snort -dev -r log/[email protected]
where date and time correspond to the date and time the logging started. You can filter the packet data based on criteria such as the source or destination IP address, a protocol, or a port number. The Snort documentation contains all the details about how to write a filter.
Intrusion-detection mode. The intrusion-detection mode differs from the other modes because Snort compares a list of rules with each packet. If the packet matches the rules' triggering criteria, Snort executes the specified corresponding action. The possible actions are pass (Snort ignores the packet and stops applying rules), log (Snort places the packet in the log directory), and alert (Snort signals an alert condition and places the packet in the log file). Under Windows, Snort can write alerts to the Application event log, but a better way to see alerts is to set up a syslog monitor. A syslog monitor provides alerts in realtime.
Syslog is a Linux program that listens for messages from other applications. Several companies have ported syslog to Windows. For example, Kiwi Enterprises' Kiwi Syslog Daemon (http://www.kiwisyslog.com) is a simple syslog daemon at a good price—free.
To test Snort's intrusion-detection mode, download and install Kiwi Syslog Daemon. To log alerts to an IDS running syslog, you use the command
snort -dev -s syslog_IP_address -c snort.conf
where syslog_IP_address is the IP address of the syslog system. Snort.conf is a sample rule file that will alert you when most of the common attacks (e.g., port scans, Code Red) occur. The Snort Web site has a large database of rules that cover a wide range of intrusion exploits, and the documentation includes a helpful section about how to write custom rules. Play with snort.conf to learn how rules work, then write a rule file that's customized for your IDS.
When a packet matches the triggering criteria in a rule that has an alert action, Snort sends the specified text message to the syslog server. Although the Kiwi Syslog Daemon works well for testing Snort, you'll probably find that you need a more powerful reporting tool. With a commercial syslog application, you can email alerts to administrators and text pagers.
Capacity Planning
A common question about Snort is "How much traffic can Snort handle?" The answer depends on several variables. If you're just sniffing traffic, Snort can handle a full 100Mbps network load on a server with an 800MHz CPU. If you don't want to lose packets, the NIC needs to be a server-quality card. My preference is to use midrange, server-class 3Com cards. In addition, don't use the command console for sniffing busy networks because Windows has a limit on how fast it can update the console. The best way to sniff a busy network is to log the packets in binary format to a disk file, then use Snort, WinDump, tcpdump, Ethereal, or any other tcpdump-compatible packet analyzer to look at the contents of the file.
If you use Snort in intrusion-detection mode, the total load it can handle depends on the number, complexity, and types of rules you want it to process. Typically, rules that search for a series of characters in the packet take longer to process than rules that look at single bits or specific bytes. As the number of rules increases, plan to increase the CPU speed and the amount of memory in the system. No estimates exist for how fast the CPU needs to be to handle a given number of rules; therefore, you might want to take advantage of the low cost for 2GHz CPUs and RAM and build a fast system from the outset.
The Next Step
I've only touched briefly on Snort's basic features. In its basic configuration, Snort catches the most common network attacks and offers a good evaluation of what's happening on your network. The next step is to explore the rich language for creating rules. The ability to tailor Snort to your environment is what makes Snort such a powerful, useful tool. Start out by becoming familiar with the standard set of rules, then experiment with your own rules. You might be surprised at everything that was happening without your knowing about it.
