07- Snort

Installing Snort

Snort is an open source intrusion detection systemavailable for most major platforms. In these notes, we will install the current version of Snort on our CentOS machines.

As of Snort 2.9.0, and DAQ, Snort now requires the use of a libpcap version greater than 1.0. Unfortunately there is no official RPM for libpcap 1.0 for CentOS 5.5. The best option would be to install Snort from source. For simplicty, we will use the (unofficial) RPMs developed by Vincent Cojot (http://vscojot.free.fr/dist/snort/) which were released on March 29, 2011.

There is a directory on labshare2 with 14 rpm packages; download these packages to a convnenient directory, and as root install them. You can use wild cards in an RPM installation. I simply created a temporary directory called snort, dropped all of the files, and ran

[root@localhost snort]# rpm -ivh ./*

Basic testing

To check that snort is running, let it simply sniff packets and print the TCP/IP headers to the screen:

# snort -v

To print the application data, try

# snort -vd

To print even more information, try

# snort -vde

Rather than printing the data to the screen, we can log the packets as they go by. Create a directory named log in the current directory and run instead

# snort -dev -l ./log

You can, of course, replace the name of the directory with any other name; you can specify the directory name absolutely or relatively (as we have done).

Let snort run for a while, then stop it. The result is now no longer ASCII data; indeed an attempt to list the data will result in a warning that this is a
binary file. Instead, open the file in wireshark, and note that this file
contains a complete packet dump. Would this be a better approach to logging packet data during an exercise? Why or why not?

For a complete list of command line switches and their significance, see /usr/share/doc/snort-2.9.0.4/README

Rule Installation

Before we can use snort as an intrusion detection system, we need to install an appropriate rule set. Snort provides two sets of rules, one is for paid subscribers
the second for registered users. The rule set for registered users is a 30-day delayed feed of the rules provided to subscribers. Snort rules are provided under a license that prohibits their commercial re-use; see https://www.snort.org/vrt/license-agreement/ for the complete
details.

To install the rules, first backup the existing directory /etc/snort, say to /etc/snort_original. Unpack the rules archive; it contains four directories (etc,
preproc_rules, rules, and so_rules). Copy the contents of the archive directory rules into the directory /etc/snort/rules.

Do the same for the preproc_rules directory and the so_rules directory.

Start the snort system by running the script /etc/init.d/snort start Verify that the IDS started correctly by examining the logs.

Run an nmap scan of your snort box. Note that, despite the fact that snort is up an running, no alerts will be generated. [By default these would be noted in /var/log/snort/alerts]. Before snort becomes useful, we need to specify which rules will be used and to otherwise configure the system.

Configuration of snort as an intrustion detection system

The key configuration file for snort is /etc/snort/snort.conf; we will work out way through this file.

Lines 397-449 contain a number of include statements like

### include $RULE_PATH/attack-responses.rules

Uncomment these lines, and restart snort. Run another nmap scan (with service version checking; i.e. nmap -A target) of your snort host; notice that a number of alerts are now generated in /var/log/snort/alerts. The precise collection of alerts will depend on the type of nmap scan that you run. We will discuss these rules later, but by enabling these rules now, you will be able to see the effect of changes you make to the snort configuration.

Lines 39-75 describe your network, and should be modified appropriately. The variable HOME_NET is used to determine which machines you are protecting. Being precise with this variable will help reduce the number of false positives.

To add a single address, simply enter the IP

ipvar HOME_NET 192.168.1.250

To specify a collection of addresses, list them and enclose them in square brackets, without spaces

ipvar HOME_NET [192.168.1.250,192.168.1.201]

To specify a range, use CIDR notation

ipvar HOME_NET 192.168.1.0/24

Ranges can be included in lists

ipvar HOME_NET [10.0.1.0/24,10.0.2.0/24]

The EXTERNAL_NET is the list of machines that are considered to be external to your network. Again, precision will reduce the number of false positives.

To negate a value, preceed it by an exclamation point:

ipvar EXTERNAL_NET !192.168.1.0/24

Variables can be included, provided they are preceeded by a dollar sign

ipvar EXTERNAL_NET !$HOME_NET

Most remaining network variables are self-explanatory. Remember- precision here will reduce false positives, but errors will allow potential intrusions to go undetected.

There is no point to specifying https ports for the HTTP_PORTS variable, as that data would be encrypted.

The variable SHELLCODE_PORTS is used to specify which port(s) should be examined for the presence of a NOP sled, which may indicate the use of shellcode.

AIM refers to the AOL instant messaging service; the IP ranges listed are AOL servers.

Lines 81-85 specify the location of your snort rules. If you installed the snort rules as described above, then these variables do not need to be modified.

Lines 91-116 specify how snort will respond to TCP packets that may be malformed. You can leave these variables alone. Details of this process are found in /usr/share/doc/snort-2.9.0.4/README.decode. When snort encounters a packet, it is first decoded; as part of that process it looks at checksums and the like for evidence that the packet is malformed. If it finds a malformed packet, snort
can then raise an alert.

Alerts can be raised for malformed packets altogether, for bad IP options, for bad TCP options, for bad T/TCP options (c.f. RFC 1644) and for various combinations. See the documentation for details. We should not need to make any changes in this section.

Line 119 configures the maximum number of flowbits. These are a way for snort to relate the contents of one packet to another. A rule can see a particular pattern in a packet, and then set a flowbit. If another rule sees a different pattern and if the flowbit is set, then the second rule can fire an alert. Do not simply uncomment the line however, as the community ruleset provided actually required 65 flowbits- more than the 64 specified in the configuration file. This also can be left in its default state.

The section “Configure PCRE match limitations” (lines 134-135) provide the limits on the use of regular expressions; see the snort manual, p. 36. There is no need to modify this value.

The section “Configure the detection engine” (line 138) determines the algorithm snort uses for pattern matching; see the snort manual, pp. 31-34. There is no need to modify this variable.

Lines 173-180 provide the locations of the dynamic modules for snort; these should not need to be modified from their defaults.

Lines 189-193 configure some preprocessors that are used if snort is run inline; i.e. as part of a firewalling system rather than as an intrusion detection system. We will not consider these options here.

Lines 196-197 configure the frag3 preprocessor. One approach to evading an intrusion detection system is to fragment the packets. Individually the different fragments may be inoffensive, but when reassembled they are malicious.

Different operating systems may reassemble fragmented packets in different ways; this is especially the case when the fragmented packets are malformed. This preprocessor reassembles fragmented packets so that they can be evaluated. See the snort manual, pp. 38-41 for details.

Lines 200-209 configure the stream5 preprocessor. This reassembles both TCP and UDP streams for subsequent analysis. See the snort manual, pp. 41-46 for details.

Notice that the TCP reassembly process does depend on the underlying OS; the rule in /etc/snort/snort.conf specifies that snort should use the same rules that windows does for reassembly- line 201. It is possible to use different values for different hosts; see the snort manual, p. 42. Note also the list of ports on which the TCP reassembly is performed. If you are running a service on a nonstandard port- like splunk or TCP syslog, then you may wish to add your port to the list.

Lines 214-243 cover the http_inspect preprocessor. This reassembles HTTP streams for subsequent analysis. See the snort manual, pp. 51-66 for details. Note that the http_inspect preprocessor can be tuned differently for different IP addresses through the use of the server directive (manual, p. 57). Note that the rule in /etc/snort/snort.conf is applied globally; this probably should be modified depending
on your network.

Note that the http_inspect preprocessor can be tuned differently for different types of web servers through the use of the profile directive. Available values include all, apache, iis, iis5.0, and iis4.0; see the manual, pp. 58-59. This variable should also be tuned for your environment.

The http_inspect preprocessor only decodes traffic on the ports specified. Note that the values specified in the /etc/snort/snort.conf file should be trimmed to only those ports on which a web server actually listens to avoid false positives.

HTTPS traffic is encrypted, and cannot be decoded with http_inspect; thus port 443 and other SSL protected ports should not be included in the list of ports for http_inspect.

Line 246 covers the preprocessor for RPC traffic. See the snort manual, pp. 51-52 for the syntax. Note that this only covers ONC-RPC traffic; i.e. RPC traffic for
linux / unix type machines- not windows.

Line 249 starts the back orifice preprocessor. Back orifice is a remote windows administration tool commonly used in trojan horses; the original was released in 1998 and an updated version (BO2K) in 1999. This preprocessor is meant to normalize traffic sent to/from back orifice tools. In 2005, it was noted that the version of the bo preprocessor that shipped with snort 2.4.0 – 2.4.3 was vulnerable to a buffer overflow that could result in an attacker obtaining root privileges on the snort sensor; exploit code was released and is even available for metasploit. What is the lesson here? Never run unnecessary services! In 2005 Back Orifice was not a priority threat.

Lines 252-289 describe the FTP preprocessor; this preprocessor also normalizes telnet traffic. It is described in the snort manual on pp. 69-76. The telnet preprocessor is enabled on a global level, through you can specify the ports it checks. The ftp_server preprocessor lets you specify the ip address(es) and port(s) of FTP servers. Note that the configuration in /etc/snort/snort.conf applies to traffic to any IP address, on ports 21, 2100, and 3535. These values should be tuned to
your particular network. Snort can also normalize traffic from FTP clients.

Lines 302-323 configure the SMTP preprocessor; it is described in the snort manual on pp. 66-69. This should be tuned for your network (since we are not running email servers).

Line 326 holds a (commented out) configuration for the portscan module. This module is covered in the snort manual, pp. 46-51. Simply uncommenting the line will not produce any results, as no log file is specified. To specify the location where portscan alerts are sent, simply use the logfile directive; e.g.

preprocessor sfportscan: proto { all } memcap { 10000000 } 
sense_level { low } logfile { pscan }

will send the results of the portscan module to the file /var/log/snort/pscan.

Some of the more clever of you have suggested that, with the classroom laboratory being isolated and on its own private network, that you should have the opportunity to play some fun ARP spoofing games. I said no- then.

Lines 329-330 are the (commented out) lines to configure snort to detect ARP spoofing; they are covered in the snort manual on p. 80. Before you are permitted to use an ARP spoofing attrack in the class exercises, you simply need to demonstrate that you know how to configure snort to detect them and show me (in class) that you can both perform the attack and have it detected by snort.

Lines 333-339 configure the SSH preprocessor; this is discussed in the snort manual on pp. 76-77. Because SSH traffic is encrypted, snort can do little with the data;
however it is able to scan for certain attacks (Challenge-Response overflow and CRC 32) that involve sending very large payloads immediately after the SSH authentication completes.

Lines 342-346 are for the configuration of the SMB DCD-RPC preprocessor. This normalizes traffic to and from SMB services, including windows based RPC calls and Samba servers. The syntax is discussed in the snort manual, on pp. 80-94. You may wish to update the policy variable to match your network; available choices include Win2000, Win2003, WinXP, WinVista, and various Samba versions.

Line 349 configures the DNS anonaly preprocessor; see the snort manual pp. 77-78 for details. This preprocessor only checks for three specific vulnerabilities- DNS Client RData Overflow, Obsolete Record Types, and Experimental Record Types

Line 352 configures the SSL/TLS preprocessor; this is described in the snort manual on pp. 78-79. In general, you want snort to ignore SSL encrypted traffic, as it
cannot read the data, and may cause false positives. This module is configured to only track traffic until the data is encrypted. Note also the large collection of default ports for this directive; this should be tuned for your particular network.

Line 355 configures the sensetive personal data preprocessor; this is discussed in the snort manual on pp. 94-96. This preprocessor allows for the creation of rules that can fire if certain types of data are noted, including credit card numbers, email addresses and social security numbers.

Lines 362-378 describe how snort is to store the results. Note that, by default in this install, files have been logged to /var/log/snort. This is controlled by the startup script /etc/init.d/snortd, which uses the configuration file /etc/sysconfig/snort. That file specifies the log directory; it also specifies the keeping of the binary packet logs we have already examined in wireshark.

Changes made to the output section here will not actually occur, because the startup script manually sets a log directory and structure, which overrides these values. If you want to make changes here, then either change the startup script, create your
own startup script, or run snort manually from the command line with e.g.

[root@snort snort]# /usr/sbin/snort -c /etc/snort/snort.conf -D

If you want to log your snort results to a databse, note also that the rpm provided a number of binaries (in /usr/sbin) including /usr/sbin/snort-mysql, /usr/sbin/snort-plain, /usr/sbin/snort-potgresql, and /usr/sbin/snort-unixODBC. Note also that /usr/sbin/snort is a symlink to /usr/sbin/snort-unixODBC.

Lines 396-450 contain the include statements for the various signature files that snort uses for its standard rules, while lines 468-484 contain the include statements for the signature files for the various shared object rules. Be sure to enable those rules that are appropriate for your environment, and be sure to include both types. The shared object rules were made available for CentOS operating systems in January 2011.

Examples of snort use.

Placement
Because VMWare uses a hub internally, a snort sensor on your host will sniff traffic directed at any of the guests on that host. It will not, however, sniff traffic directed at a VM on another host.

Portscans
Configure the portscan module to store its results in the file of your choice. Be sure you get the syntax correct (brackets and spaces) or snort may not start. Note also that if snort is unable to write to the file, it may fail silently. You may have run the init.d script and the script may have returned the happy green OK and all
looks good- and yet SNORT DID NOT START CORRECTLY. You MUST check your logs. Well, actually you don’t HAVE to, after all that will just give me a chance to make some red marks all over your next report, referring to this exact point in the notes.

Set up the portscan module and verify that it works by- wait for it- running an nmap portscan against your snort host.

Sample rules
Though we do not have time for a long description of how to create custom snort rules, let us at least create a simple rule that we can use for testing. In local.rules, add the following:

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"Testing
rule"; content:"TEST"; sid:2000000; classtype:misc-activity; rev:1;)

This will throw an alert whenever the text “TEST” appears in a communication from the external network (from any port) to any host on the internal network (on any port). The SID of 2000000 is well within the range of local defined rules (greater than
1000000), and this is revision 1 of this rule.

From a host on your external network, visit make a request of a web server on your internal network for the page “TEST.html”. (It doesn’t even matter if the web server exists!) Verify that an alert was thrown.

MS08-067
What does snort do if we use metasploit to exploit MS08-067? Be sure to enable all the relevant rules, especially the file /etc/snort/so_rules/netbios.rules. Exploit a windows host using MS08-067 and metasploit. What does snort show? Dows it specifically refer to MS08-067 in the alerts? Is this a good idea?

Sourcefire has an excellent white paper on how snort signatures evolved in response to MS08-067; read the paper at http://assets.sourcefire.com/snort/vrtwhitepapers/ms08-067wp.pdf

Other exploits
You should consider running other common attacks on vulnerable hosts MS09-050 seems to be a class favorite) and determine what signatures these attacks leave in your IDS.

Tuning
It is important that your IDS is tuned for your particular network

REFERENCES

The snort manual- http://www.snort.org/assets/166/snort_manual.pdf