One of the keys to any type of security is knowledge. To keep a network secure, you must know about security in general, but you must also be aware of the environment in which your computers operate.
For example, any computer that’s connected directly to the Internet is likely to see several unauthorized access attempts per day from outside the local network. Indeed, there may even be suspicious activity from within your local network, either from disgruntled insiders or from a successful outside intrusion or infection. If you’re to effectively guard against intrusions, it’s helpful to be aware of them. Even if you don’t respond to every probe (a monumental and unrewarding task), changes in the patterns of attack may be important: Changes may tip you off to new vulnerabilities and attack tools.
Network monitoring tools help you keep an eye on network attacks. Several network monitoring tools are available, but this month, let’s focus on just one: Snort (http://www.snort.org). Snort is a very powerful system for monitoring network traffic. It can be used in one of two ways:
- As a packet sniffer. Snort can echo network packets, or parts of them, to the screen or to a log file you specify. Used as a packet sniffer, Snort can be useful for network diagnostics — say, to verify that packets are actually reaching a target computer.
- As a network intrusion detection system (NIDS). Snort supports powerful rules for interpreting network traffic. You can create a rule set (or use a prepackaged one) to have Snort alert you to suspicious activity such as packets that match the profile of known attacks.
Most Linux distributions ship with Snort, but it’s sometimes broken into several different packages. Snort supports a variety of compilation options, so a distribution may include multiple Snort binary packages — for instance, one that supports logging to a MySQL database and another that doesn’t. You may also find separate documentation, configuration, and common-file packages.
Where to Place a Snort System
Whether you use Snort as a simple packet sniffer or as a NIDS, one important question is where to place a Snort system. Although you can run Snort on any Linux computer (and many kinds of other systems), its effectiveness depends largely on where on your network Snort runs and how that computer is connected to the rest of your network. The fundamental issue is what network traffic hits the Snort system’s network interface card (NIC). Snort can monitor any traffic it sees, but for efficiency’s sake, many networks are designed to keep computers from seeing each others’ traffic. This configuration is usually desirable, but it can reduce Snort’s effectiveness.
A couple of important issues to keep in mind are:
- Hubs vs. switches. Modern Ethernet networks use hubs or switches to interconnect computers. These two devices fill more-or-less the same role: You connect each computer on a network to the hub or switch, which echoes network traffic to other computers. Switches are the smarter type of device: They learn which computer is connected to each port, and whenever possible, direct traffic for specific computers only to the appropriate port, thus preventing other computers from seeing that traffic. Hubs, by contrast, echo all traffic onto all of the other ports. So, although switches are better for network efficiency, hubs are better for use with Snort.
- Firewalls. If you use a firewall to protect your computers from the outside world, Snort’s placement relative to that firewall is important. If you put Snort outside of the firewall, it can monitor external attacks on your network, but won’t see most internal traffic. If you put Snort behind the firewall, it can monitor internal traffic and attacks that manage to breach the firewall, but not attacks blocked by the firewall.
Some switches can be configured to echo all traffic to a specific port in addition to sending the data to the destination computer. Consult your switch’s documentation to learn if yours can do this. If it can’t, you may be limited in your ability to monitor internal traffic.
 |
| Figure One: Snort monitors may be placed inside or outside a firewall |
Many security-conscious sites employ two Snort systems, one outside the firewall and one inside it, as shown in Figure One. In the figure, Snort System One monitors outside attempts to break in, while Snort System Two looks for suspicious activity within the local network (albeit with the usual caveats about switches). In theory, you could run Snort on the firewall, but this may degrade the firewall’s performance. You may also want to run more than two Snort systems, particularly if your network is more complex than the one shown in Figure One — say, if you have two separate subnets or if you have several layers of security with firewalls between each.
For added security on the Snort system itself, you can run it without an IP address of its own. For instance, rather than bring up its network interface with a command such as ifconfig eth0 192.168.1.2, you can omit the IP address, which results in a system on which the Ethernet port is active but no IP address is assigned. This configuration enables Snort to monitor network traffic, but many types of outside attacks simply won’t work against the Snort system. Such a configuration isn’t invulnerable, though; for instance, a denial-of-service (DoS) attack on your network may still bring down the Snort system. Also, the lack of an IP address means that you won’t be able to log into the Snort system remotely, can’t have it send alerts to another computer, and so on; you’ll only be able to access the Snort system from its console.
Using Snort as a Packet Sniffer
Snort’s greatest power resides in its use as a NIDS, but its use as a packet sniffer is much easier to describe, so let’s start with that. One very simple way to use Snort’s basic packet-sniffing features is to type the following command:
# snort -v
This command tells Snort to echo the TCP/IP headers to the console. You can also add the -d option to have the program echo the application data, or -e to echo the link-layer data. Of course, this output is likely to be quite copious if the computer on which Snort runs sees a lot of traffic or is connected via a hub to computers that send and receive a good amount of data. A single packet’s headers look like this, as reported by Snort:
02/12-12:56:00.502227 192.168.1.2:22 -> 192.168.1.3:54749
TCP TTL:64 TOS:0x10 ID:12986 IpLen:20 DgmLen:404 DF
***AP*** Seq: 0x86279E65 Ack: 0x85942B0A Win: 0x2200 TcpLen: 32
TCP Options (3) => NOP NOP TS: 214886681 180747313
This header indicates a TCP packet came from port 22 on 192.168.1.2 and was directed at port 54749 on 192.168.1.3. Snort also reports other information, such as the date and time, the sequence number, and so on. Some of this information can be useful in low-level network debugging or security analyses, but describing it all would take too long for this column.
If you want to monitor all network traffic, but don’t want to sit glued to the screen, you can have Snort send its output to a log file instead. The -l option takes a log file directory as a parameter. You may also want to pass the -h option, which tells Snort the address of the home network. For example, the command
# snort -l /var/log/snort -h 192.168.1.0/24
creates a series of subdirectories under /var/log/snort, one for each IP address. These directories hold files named after the port numbers involved in a data transfer. For instance, /var/log/snort/192.168.1.3/TCP:54749-22 holds information on packets originating from port 54749 on host 192.168.1.3 and directed at port 22. This arrangement can help you track specific types of information. For instance, if you suspect a person who uses a particular computer is up to no good, you can monitor that system’s traffic while ignoring other systems.
One disadvantage of logging everything, of course, is that the log files are likely to grow unmanageably large very quickly. Performing logging in this way may be helpful when diagnosing network problems, though. For instance, you can monitor the exchange of data between computers if a network protocol isn’t working as you expect, then shut down Snort when you’re done.
For ongoing security monitoring, you’ll probably use Snort as a NIDS, and this use requires you to configure the system to log far less data.
Configuring Snort as a NIDS
To use Snort to automatically detect intrusion attempts, you must tell Snort how to do its job. To do that, you edit the Snort configuration file, which is generally /etc/snort/snort.conf. This file begins with a series of options to tell Snort what its home network is, what tools to use to preprocess packets (defragment fragmented packets, for instance), what tools to use to format output logs (to enable XML output, for instance), and so on. You can leave most of these options alone, but you may want to adjust the HOME_NET variable to reflect your local network’s IP address. You can have the variable pick up an address from a network interface, if you like:
var HOME_NET $eth0_ADDRESS
Alternatively, you can pass network address specifications in square brackets:
var HOME_NET [192.168.1.0/24,10.120.0.0/16]
Similar variables set external network addresses and enable you to point to your local SMTP (mail), Web, SQL, and DNS servers. The default value for most of these variables is any, which matches any address. Some Snort rules use these pointers to monitor only traffic that’s destined for or sent from the relevant machines. As a general rule, you should leave these values set at their default of $HOME_NET because this practice lets you see random probes for vulnerable servers, even on systems that aren’t running them. You might also see attacks on servers you don’t realize are running.
Snort relies upon a series of rules to detect specific types of attacks. In practice, many Snort installations load rules from files in the Snort configuration directory or a subdirectory of it, such as rules. These files have names that end in .rules.
Most distributions include a set of Snort rules, sometimes in their own package. For instance, Debian uses the snort-rules-default package. The Snort files available from the program’s main Web site incorporate the rules into the main package. Collectively, these rules tell Snort how to watch for a variety of attacks, while ignoring most innocent traffic.
A typical rule looks like this:
alert tcp $EXTERNAL_NET any -> $HOME_NET
1080 (msg:"SCAN Proxy attempt";flags:S;
classtype:attempted-recon; sid:615;
rev:1;)
This rule tells the system to log an alert message when it detects traffic from a computer on $EXTERNAL_NET (typically any computer) directed at port 1080 on a $HOME_NET(local) computer. The information within parentheses includes a logging message and classification codes. The flags keyword indicates TCP flags — S indicates that the rule matches only packets on which the SYN flag is set. In many cases you’ll also find information on packet contents (indicated by a content keyword) or other packet features.
If a packet matches the criteria specified by a rule, Snort logs it. If a packet doesn’t match any rules, Snort does nothing so you’re not bothered by traffic Snort isn’t configured to notice.
If you want to expand Snort’s capabilities, you can do so, but you’ll need additional rules. You can find many on the Snort web page, and particularly from http://www.snort.org/snort-db. You can search for a particular rule or browse the rule list. If you find a rule that matches the type of activity you want to monitor, you can copy the “Signature” field from the rule’s description into one of your .rules files, or you can create a new .rules file and add a reference to the new file to your snort.conf file.
If you’re feeling adventurous, you can try creating your own rules. Doing so requires a strong knowledge of what an attack looks like at a packet level, as well as knowledge of the Snort rules control file. You can learn about the latter from the Snort documentation and particularly the “Writing Rules” chapter of the user manual (http://www.snort.org/docs/writing_rules).
Once you’re satisfied with your Snort rule set, you can launch Snort. Typically, you’ll have Snort log its output, which you can peruse later. You can launch Snort to function as a NIDS using a command such as the following:
# snort -c /etc/snort/snort.conf -l /var/log/snort
You can also add various other options to tweak Snort’s behavior. For example, -A Fastturns on a shorter alert log format, which can reduce disk accesses and log file size. Whether or not you use this option, Snort creates a log directory tree much like the one it creates when you use Snort as a packet sniffer. One difference is that the “Fast” log files contain less data; only packets that match a rule are logged. There’s also a file called alert, which contains a summary of all the suspicious activity Snort has detected.
 |
| Figure Two: LinPopUp can display real-time reports of Snort alerts |
One alerting tool deserves special mention: You can send alerts in real time to computers using the Server Message Block (SMB)/Common Internet Filesystem (CIFS) WinPopup mechanism. If you specify a Windows machine as the recipient, WinPopup displays a popup message when an alert occurs. A Linux target needs to be running a program such as LinPopUp (http://www.littleigloo.org/software_002.php3) or KPopUp (http://www.henschelsoft.de/kpopup_en.html), and its Samba configuration must have the message command option set correctly in its smb.conf file. The Snort system must also have Samba installed to send these messages. You must also specify a configuration file that contains a list of machines to receive the popup message. You do this by passing it to Snort with the -M option. When all works well, the receiving system displays messages from Snort, as shown in Figure Two.
Keeping Up with Snort
Using SMB/CIFS alerting can be convenient, but if your network sees a lot of attacks, it may be hard to keep up. Thus, you may want to investigate using tools such as the Simple Watcher (SWATCH; http://www.oit.ucsb.edu/~eta/swatch). SWATCH can monitor log files, such as the Snort alert file, and respond by sending periodic e-mail summaries.
No matter how you monitor your Snort reports, be sure to clean out the log files periodically. The simplest way to do this is to add the /var/log/snort directory to your system’s log rotation schedule. In most distributions, adding lines like the following to /etc/logrotate.conf does the trick:
/var/log/snort/* {
missingok
weekly
create 0664 root utmp
rotate 4
}
This configuration causes the system to rotate the files in /var/log/snort on a weekly basis. Unfortunately, this configuration skips the log files for specific systems that are stored in subdirectories of /var/log/snort. So, you may need to add a cron job to clean these files out on a periodic basis. Alternatively, you can use a binary logging format by passing the -b option to Snort; this disables creation of the per-system subdirectories, but the log files won’t be readable without the use of special tools. You can examine a Snort binary log file with tcpdump -r.