Using Snort on Your Network

Your IDS can use just one Snort system, or more than one if you need redundancy. For example, it is possible to divide the task of network monitoring across multiple hosts. The chief benefit of redundancy is that if one element of the system goes down, the network can still be monitored and protected.

The previously outlined network structure can be used for passive monitoring or active monitoring. Passive monitoring is simply the ability to listen to network traffic and log it. Active monitoring involves the ability to:

• Monitor traffic and send alerts concerning the traffic that is discovered

• Intercept and block traffic

Snort is primarily used for active auditing and can perform signature-based and anomaly-based detection. Signature-based detection means that you predefine what an attack looks like, and then configure your network monitoring software to look for that signature. Anomaly-based detection requires the IDS to actually listen to the network and gather evidence about "normal" traffic. Then, if any traffic occurs that seems different, the IDS will respond by, for example, sending out an alert to the network administrator.

After dealing with a post-mortem on a compromised system, it's amazing how helpful a Snort NIDS can be. On the flip side, it's also frustrating when your Snort system does not log a possible attack. Let's take a possible attack: the IMAP login overflow attack. In this case, an attacker tries a buffer overflow to cause a remote root exploit.

Snort can let you know that someone is sending an IMAP packet that contains the signature of an IMAP login overflow. Depending on how you have Snort set up, you can either monitor the output or you can be notified by e-mail.

The rule for detecting this attack is:

alert tcp $EXTERNAL_NET any -> $HOME_NET 143 (msg:"IMAP login buffer \       overflow attempt"; flow:established,to_server; content:"LOGIN";   \       content:"{"; distance:0; nocase;                                  \       byte_test:5,>,256,0,string,dec,relative; reference:bugtraq,6298;  \        classtype:misc-attack; sid:1993; rev:1;)

This rule checks for any packet originating from the external network (defined by EXTERNAL_NET) to any system on the internal network (defined by HOME_NET) to port 143, which is the IMAP port. The msg variable defines what is sent to the Snort alert, and the rest of the information of the packet is content based. There are definitions on the type of attack (misc-attack), the SID number (1993), and the Bugtraq (www.securityfocus.com) reference on the attack 6298 (which you can find at www.securityfocus.com/bid/6298).

Then, there's the flip side: Snort does not detect an attack on your system. Suppose another UNIX system is running Apache with FrontPage extensions. Someone finds a new overflow on FrontPage for which there is no Snort rule yet, and then he has your box. Not to mention, your security solution did not provide any assistance with the attack.

Snort's Uses

Snort has three major uses:

• A packet sniffer

• A packet logger

• A NIDS

All the uses relate to each other in a way that builds on each other. However, it's easiest to put the packet sniffer and the packet logger together in the same category—basically, it's the same functionality. The difference is that with the logging functionality; you can save the packets into a file. Conversely, you can read the packet logs with Snort as well.

Using Snort as a Packet Sniffer and Logger

In its simplest form, Snort is a packet sniffer. That said, it's the easiest way to start. The command-line interface for packet sniffing is very easy to remember:

# snort –d –e -v

Note that the -v option is required. If you run Snort on a command line without any options, it looks for the configuration file (.snortrc) in your home directory. Table 29.2 lists Snort options and their function.

Table 29.2: Basic Snort Options for Packet Sniffing and Logging

Option	What It Does
-v	Put Snort in packet sniffing mode (TCP headers only)
-d	Include all network layer headers (TCP, UDP, and ICMP)
-e	Include the data link layer headers

You cannot use options –d and –e together without also using the –v option. If you do, you get the same output if you use snort without any options:

florida:/usr/share/doc/snort-doc# snort -de Log directory = /var/log/snort     Initializing Network Interface eth0 using config file /root/.snortrc Parsing Rules file /root/.snortrc     +++++++++++++++++++++++++++++++++++++++++++++++++++ Initializing rule chains... ERROR: Unable to open rules file: /root/.snortrc or /root//root/.snortrc Fatal Error, Quitting..

Now, if you run snort with the –v option, you get this:

florida:/usr/share/doc/snort-doc# snort -v Log directory = /var/log/snort     Initializing Network Interface eth0          —== Initializing Snort ==— Decoding Ethernet on interface eth0          —== Initialization Complete ==—     -*> Snort! <*- Version 2.0.1 (Build 88) By Martin Roesch ([e-mail], www.snort.org) 01/22-20:27:44.272934 192.168.1.1:1901 -> 239.255.255.250:1900 UDP TTL:150 TOS:0x0 ID:0 IpLen:20 DgmLen:297 Len: 277 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+     01/22-20:27:44.273807 192.168.1.1:1901 -> 239.255.255.250:1900 UDP TTL:150 TOS:0x0 ID:1 IpLen:20 DgmLen:353 Len: 333 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ []

After a while, the text scrolls off your screen. Once you press Ctrl-C, you get an output summary that summarizes the packets that Snort picked up, by network type (TCP, UDP, ICMP, IPX), data link information (including ARP), wireless packets, and any packet fragments:

Snort analyzed 56 out of 56 packets, dropping 0(0.000%) packets Breakdown by protocol:      Action Stats:     TCP: 0     (0.000%)        ALERTS: 0     UDP: 44    (78.571%)       LOGGED: 0    ICMP: 0     (0.000%)        PASSED: 0     ARP: 1     (1.786%)   EAPOL: 0     (0.000%)    IPv6: 0     (0.000%)     IPX: 0     (0.000%)   OTHER: 11    (19.643%) DISCARD: 0     (0.000%) ============================================================================ Wireless Stats: Breakdown by type:     Management Packets: 0   (0.000%)     Control Packets:    0   (0.000%)     Data Packets:       0   (0.000%) ============================================================================ Fragmentation Stats: Fragmented IP Packets: 0  (0.000%)     Fragment Trackers: 0    Rebuilt IP Packets: 0    Frag elements used: 0 Discarded(incomplete): 0    Discarded(timeout): 0   Frag2 memory faults: 0 ============================================================================ TCP Stream Reassembly Stats:      TCP Packets Used: 0     (0.000%)      Stream Trackers:  0      Stream flushes:   0      Segments used:    0      Stream4 Memory Faults: 0 ============================================================================ Snort received signal 2, exiting

Since this isn't very useful for checking the data of the packets, we'll run snort with the –dev option to give us the most information:

florida:/usr/share/doc/snort-doc# snort -dev Log directory = /var/log/snort     Initializing Network Interface eth0          —== Initializing Snort ==— Decoding Ethernet on interface eth0          —== Initialization Complete ==—     -*> Snort! <*- Verions 2.0.1 (Build 88)     By Martin Roesch ([e-mail], www.snort.org) 01/22-20:28:16.732371 0:4:5A:F2:F7:84 -> 1:0:5E:7F:FF:FD type:0x800 len:0x5B 131.215.183.30:57535 -> 239.255.255.253:427 UDP TTL:254 TOS:0x0 ID:26121 IpLen:20  DgmLen:77 Len: 57 02 01 00 00 31 20 00 00 00 00 73 70 00 02 65 6E  ....1 ....sp..en 00 00 00 17 73 65 72 76 69 63 65 3A 64 69 72 65  ....service:dire 63 74 6F 72 79 2D 61 67 65 6E 74 00 00 00 00 00  ctory-agent..... 00                                       .     =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+     01/22-20:28:18.354830 0:4:5A:F2:F7:84 -> 1:0:5E:0:0:2 type:0x800 len:0x3E 131.215.184.253:1985 -> 224.0.0.2:1985 UDP TTL:2 TOS:0x0 ID:0 IpLen:20 DgmLen:48 Len: 28 00 00 10 03 0A 78 01 00 63 69 73 63 6F 00 00 00  .....x..cisco... 83 D7 B8 FE                               ....     =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 

If you've used TCPDump before, you will see that Snort's output in this mode looks very similar. It looks very typical of a packet sniffer in general.

{date}-{time} {source-hw-address} -> {dest-hw-address} {type}  {length} {source-ip-address:port} -> {destination-ip-address:port} {protocol} {TTL}  {TOS} {ID} {IP-length} {datagram-length} {payload-length} {hex-dump} {ASCII-dump}

This is all great information you're gathering, and Snort can collect it into a file as well as display it to standard output. Snort has built-in packet logging mechanisms that you can use to collect the data as a file, sort it into directories, or store the data as a binary file.

To use the packet logging features, the command format is simple:

# snort -dev -l {logging-directory} -h {home-subnet-slash-notation}

If you wanted to log the data into the directory /var/adm/snort/logs with the home subnet 10.1.0.0/24, you would use the following:

# snort -dev -l /var/adm/snort/logs -h 10.1.0.0/24

However, if you log the data in binary format, you don't need all the options. The binary format is also known as the TCPDump formatted data file. Several packet sniffers use the TCPDump data format, including Snort.

The binary format for Snort makes the packet collection much faster because Snort doesn't have to translate the data into a human readable format immediately. You only need two options: the binary log file option -L and the binary option -b.

For binary packet logging, just run the following:

# snort -b -L {log-file} 

For each log file, Snort appends a timestamp to the specified filename.

It's great that you're able to collect the data. Now, how do you read it? You need to parse it back through Snort with filtering options. You also have the option to look at the data through TCPDump and Ethereal, as they use the same type of format for the data.

# snort [-d|e] -r {log-file} [tcp|udp|icmp]

The last item on the line is optional if you want to filter the packets based on packet type (for example, TCP). To take further advantage of Snort's packet logging features, you can use Snort in conjunction with the Berkeley Packet Filter (BPF).

# snort –vd –r <file> <bpf_filter>

The BPF allows packets to be filtered at the kernel level. This can optimize performance of network sniffers and loggers by eliminating packets with the best performance because it happens at such a low level in the operating system.

The following are some examples of BPF filters. They are commonly used for ignoring packets, and work with expressions (and, or, not).

If you want to ignore all traffic to one IP address:

# snort -vd -r <file> not host 10.1.1.254

If you want to ignore all traffic from the 10.1.1.0 network to destination port 80:

# snort -vd -r <file> src net 10.1.1 and dst port 80

If you want to ignore all traffic coming from host 10.1.1.20 on port 22:

# snort -vd -r <file> not host 10.1.1.20 and src port 22

Using Snort as an NIDS

Now that you understand the basic options of Snort, you can see where the IDS comes into play. To make Snort an IDS, just add one thing to the packet logging function: the configuration file.

# snort -dev -l /var/adm/snort/logs -h 10.1.0.0/24 -c /root/mysnort.conf

Your rules are in the configuration file, and they are what trigger the alerts.

Snort and Your Network Architecture

So, how do you make Snort as useful as possible? You put the Snort system(s) on your network where it (they) will be most useful. Where this is depends on factors such as the size of your network and how much money you have to spend on Snort systems.

If you cannot afford to acquire enough Snort systems to achieve the optimal designs shown in Figure 29.6, you'll need to see what you can use from a practical sense. If you need to limit your spending, forego the system inside the router and just make sure you have the Snort systems inside the subnets you want to protect.

Figure 29.6: An IDS Network Architecture with a Screening Router

Many network administrators set up a screening router. This enables the router to act as a poor-man's firewall and stop packets at the network level, usually by their well-known ports. The problem with this is that many packets can be rerouted through other ports.

However, if a packet gets past your screening router, this might be a good place to put your IDS. This enables you to detect what you deem as attacks while enabling some filtering to hopefully catch some of the problems with the router. Figure 29.6 shows the IDS network architecture with a screening router.

In this case, you would want to put an IDS system on the inside of your firewall and another in between your outside router and your firewall. Here we're also assuming that your router is filtering some traffic through the access lists as well. You do not want your Snort system on the outside of your network because it will increase your false positive rate, and it leaves your Snort system more vulnerable to attack. This is illustrated in Figure 29.7. Most important is the Snort system inside your firewall. This is the one you should monitor frequently for attacks. This system should only trigger alerts from possible legitimate attacks, and produce much fewer false alerts, or a false positive. However, the Snort system between your router and your firewall will also provide you with useful information—especially for a postmortem on a compromised system.

Figure 29.7: A Firewalled Network with Snort Systems

Many network architectures have a Demilitarized Zone (DMZ) for providing public services such as Web servers, FTP servers, and application servers. DMZs can also be used for an extranet (which is a semi-trusted connection to another organization), but we'll stick to the public server DMZ architecture in this example. This is illustrated in Figure 29.8.

Figure 29.8: A Firewalled Network with a DMZ

In this case, you would want three Snort systems: one inside the router, one inside the DMZ, and one inside the firewall. The reason for the additional IDS machine is that you have an additional subnet to defend. Therefore, a good rule of thumb for an optimal situation for your Snort systems is:

• One inside the router

• One inside each subnet you want to protect

This is illustrated in Figure 29.9.

Figure 29.9: A Firewalled Network with a DMZ and Snort

Snort and Switched Networks

Snort can also be used on a switched network. As switches become increasingly popular, monitoring them with Snort (or any other IDS) becomes more and more critical. Your switch can either be inside your router or inside your firewall.

A switch provides you with Layer 2 (Data Link layer on the OSI seven layer model) configurability, including virtual LANs (VLANs), which allows you to subnet directly at the switch. Switches have also been used as overpriced routers. In this case, you'll want to save your money if you're not using your switch's features.

You can connect the Snort system directly to the switch. The switch has a Switch Port ANalyser (SPAN ) port, which is where the Snort system will be connected. The Snort system then takes copies of the packets to be analyzed. This is illustrated in Figure 29.10.

Figure 29.10: A Switched Network

In this case, you'll have to decide which other ports on your switch you want to monitor with the SPAN port. Usually, you will monitor just one port; otherwise, you can flood the SPAN port. This might kill the performance of both your switch and your IDS. This is illustrated in Figure 29.11.

Figure 29.11: A Switched Network with Snort Systems

Pitfalls When Running Snort

Snort is a wonderful tool; however, like all tools, it has its disadvantages. Snort has three major pitfalls:

• Not picking up all the packets

• False positive alerts

• False negative alerts.

Snort might not pick up all packets because of the speed of the network and the speed of the promiscuous interface. This can also be dependent on the network stack implementation of the operating system.

False Alerts

False positives occur when Snort gives you a warning when it shouldn't. Basically, a false positive is a false alarm. If you go with a default rule set with Snort, then you will definitely get many false alarms. This can trigger a lot of alerts until you decide what is relevant to your network. The more open your network is, the more alarms you'll want to monitor.

On the opposite end, you can get false negatives. In other words, someone compromises a Snort- monitored system and your Snort system doesn't detect it. You might think that this doesn't happen, but this is a very real scenario. Make sure you keep your Snort rule sets up to date, and your continually evaluate your expectations as to what to expect from your Snort system.

Upgrading Snort

Upgrading Snort can be quite painful for two reasons: the rule set syntax might change, and the interface to the alert logs. We have found both to be obstacles when trying to upgrade Snort systems, and can be quite tedious to deal with. Any upgrade could mean a significant change with your local rule sets, so you need to be aware of this when you upgrade.