Detecting a Network-based Intrusion

Attackers use application vulnerabilities to gain unauthorized access to systems. We saw in the preceding section how tools such as Nessus help identify vulnerable services and, when possible, recommend ways to remedy the problem. Before attackers can exploit a vulnerable system, they must know it exists.

The following sections examine a number of different methods that can be used to protect a network environment. We also examine techniques that can be used to detect the presence of unwanted guests.

Know Your Traffic, Tune Your Firewall

Applications and users require a transport mechanism for communicating with each other. In a standard network environment, this is handled by using a number of network protocols such as TCP/IP, ICMP, and UDP. For each of these, applications require predefined ports over which the communications will take place.

The file /etc/services contains a number of well-known, predefined protocol-port pairs and the applications they support. If you know the applications that are being run within your environment, you should be able to generate a list of required ports. /etc/services is a static ASCII file used for referencing ports and applications. It does not prevent the binding of services to any specific port. Restricting network traffic flow to only these select ports will reduce your overall exposure. In addition, a proper review of requirements may identify that some services can be restricted to specific clients. Further constraints can be placed on network flow to allow only these conversations.

As an extra level of complexity, some applications initiate conversations only on a specific port. After the appropriate handshake has been performed, the communications exchange is shifted to a different, sometimes random, port.

When you are finished with the application-port mapping exercise, you will have a list of valid client/server/port relationships that are required to support your applications. Layered on top of the business list of ports is the more transparent layer. Protocols such as DHCP, DNS, and NNTP are often forgotten in the application lists. If they are not included at this step in the process, a number of critical applications may fail. The availability of each of these relationships on the network can be controlled by placing the services in question behind an appropriately configured firewall.

Knowing which ports are in use on your network allows you to identify unsanctioned traffic more readily. Keyloggers and password-stealing Trojans often use IRC channels to report their findings to a remote server. If your network doesn't allow chat traffic, you will quickly be able to identify potentially infected machines that use this mechanism.

A properly configured firewall should monitor not only incoming traffic, but it also should be able to monitor and control the port and contents of both inward-and outward-bound packets. If this can be achieved, the first step in mitigating a successful attack has been taken.

Network Intrusion Detection Systems

The preceding section explained how a properly configured firewall allows clients to access only specific target servers. Using such a firewall, coupled with stateful packet inspection, you can be fairly confident that packets reaching the servers contain data that is valid for the target service.

STATEFUL PACKET INSPECTION

A number of firewalls filter traffic based only on the ports used in the conversation. A number of exploits, however, occur when malformed packets are sent to a server over allowed ports.

Stateful Packet Inspection is a tool used to examine information passed between a client and a host. When this tool is enabled, all the packets that make up a single transmission are assembled by the firewall. Once they are assembled, the original message is checked for consistency and correctness of all the appropriate headers. When a packet is considered safe, it is passed along to the target server.

Stateful Packet Inspection also monitors the current state of a conversation between two hosts. If a packet attempts to traverse a firewall claiming to be part of a specific conversation, it is checked against a known list of current connections. If the conversation is active and the packet was expected, it is allowed through.

This process should not be confused with Application Layer packet filtering. Such filtering actually examines the content of the data portion of packets looking for known application-level exploits.

The issue at hand now becomes determining whether the traffic sent to a server is a valid request, and not an attempt to exploit a known vulnerability of the service. Services are exploited when they are sent specially crafted streams of data that cause them to malfunction in predictable ways. As they malfunction, they inadvertently give an attacker access to resources that, in turn, can lead to a system compromise.

A Network Intrusion Detection System (NIDS) is a service that monitors network traffic flow looking for known exploit attempts. In some cases, NIDS is implemented as an appliance; in other cases, as a piece of software. In either case, because NIDS requires access to all network conversations, it must be placed in a network where it can be allowed to intercept all traffic. In most cases, it will therefore require the programming of a switch to allow one port to listen to all traffic.

NIDS inspects each packet and compares the content against a set of known exploits. If a match is found, an alert is generated and the packet is logged. One of the major difficulties in tuning an NIDS environment is determining which alerts are real and which are false positives. There is a fine balance between defining the parameters of an exploit attempt and the necessary resources required to implement a 100% match. Since NIDS must be running in real-time, the processing load of deep inspection of all packet content is not possible. Packet rules configured to recognize particular exploits are therefore potentially prone to incorrectly identify innocent packets as attacks. When they are tuned to an existing environment, however, it is possible to reduce the error rate to an acceptable level. Caution must be taken to find a proper balance between too many alerts versus insufficient protection.

Snort

Bundled with SLES, is an NIDS called Snort. Originally designed as a lightweight NIDS, Snort has become one of the most widely used systems for detecting intrusions. Snort rules are constantly being developed by the Snort community and shared through their website. In addition to using community rules, you also can create your own rules.

Before looking at results from Snort in action, let's first examine how it can be configured to suit your environment. The Snort software can be found in /etc/snort. Table 12.2 lists the files found in this directory.

Table 12.2. Snort Configuration Files in /etc/snort

FILENAME	DESCRIPTION
snort.conf	Main Snort configuration file. Used to define network configuration and which rules are loaded at runtime.
threshold.conf	Used to control the logging of rules that are triggered on a frequent basis. Used to reduce the number of alerts from such rules without losing the trigger information.
reference.config	Used to provide URLs for important resources.
classification.config	Definitions of the different alert classes.
gen-msg.map	Text descriptions of the different alert IDs.
sid-msg.map	Text definitions of the different SIDs.
*.rules	Rule definition files.

Though there are many files in the snort directory, most of the configuration of Snort is done through snort.conf. This file is split into four major sections:

• Network definition This section allows you to define a set of variables that describe the networking environment within which the Snort sensor finds itself. These variables are applied to the rules files as they are loaded. Definitions in this section include the identification of valid servers for specific types of traffic such as SMTP, HTTP, DNS, and so on.

• Preprocessors This section allows you to define if and how related packets are treated. It also allows for the configuration of the way the packets are inspected for content.

• Logging options This section allows you to define where the Snort alerts are to be placed. By default, the alerts go to the system log facility. You can change the behavior here to log to /var/log/snort and/or to a database.

• Rules This section allows you to control which rules are activated by the system. Each family of rules is maintained in a separate file. Variables defined in the first section are interpreted and inserted into the rules.

You can activate Snort by running its script in /etc/init.d. To have Snort initialized at boot time, you need to use YaST and configure the Runlevel Editor option. By default, the SUSE implementation of Snort can see only network traffic destined to the local host server. You can change this by modifying the Snort startup script in /etc/init.d and defining a variable called SNORT_PROMISC and setting its value to yes. When this is done, Snort will change the mode of the network card to promiscuous. In this mode, Snort can monitor all traffic seen by the network card, and not just the traffic destined for its host system.

When a packet arrives on the interface card that Snort is listening on, Snort intercepts it for analysis. When a packet is found to satisfy the requirements of one of the rules, an alert is issued. An example of such an alert is shown in Listing 12.1.

Listing 12.1. A Snort Alert Found in /var/log/snort/alert

 [**] [1:1256:7] WEB-IIS CodeRed v2 root.exe access [**] [Classification: Web Application Attack] [Priority: 1] 04/16-19:32:41.639229 10.0.131.168:4105 -> 192.168.1.240:80 TCP TTL:113 TOS:0x0 ID:40087 IpLen:20 DgmLen:112 DF ***AP*** Seq: 0x8721649F  Ack: 0x95199331  Win: 0x4470 TcpLen: 20 [Xref => http://www.cert.org/advisories/CA-2001-19.html] 

In this listing, you see that Code Red attacks are still happening on the Internet. As you can see from this example, Snort registers a fair amount of information in the local log file. Scanning through the log file manually can be a tedious task and prone to missing important information.

Analysis Console for Intrusion Databases

A more flexible tool is required to quickly look at the events triggered by Snort. There are a number of tools for reviewing Snort logs. In this section, we implement a tool called Analysis Console for Intrusion Databases (ACID). This tool can be used to review logged events and present the summarized findings on a web page. Through the web environment, it is possible to drill down using a number of different avenues to obtain event-specific information.

As its name implies, ACID relies on having Snort events collected in a database. The following will help you set up a MySQL repository for your Snort logs as well as implement the ACID tool.

To get ACID running on your system, you need to install the following packages:

• Snort An NIDS tool

• MySQL A logging database

• PHP A web interface scripting language

• ADODB A database access interface

• JPGRAPH A tool that creates charts for websites

• PCRE PERL Compatible Regular Expression library

• ACID An analysis tool

Both Snort and MySQL are included in the original distribution media for your SLES server. If they were not included in the original install, you can add them to your system using the YaST software option. Newer versions of the software are available from their respective websites.

As mentioned earlier, configuring Snort requires making changes to /etc/snort/snort.conf. The version of this file supplied with the default install will suffice for the original install. You may, however, want to modify the /etc/init.sd/snort startup script as mentioned previously to monitor events beyond the local server.

Once snort has been configured and is logging alerts to /var/log/snort/alert, you can proceed with the configuration of MySQL. Similarly to Snort, installing the MySQL database does not enable the startup of the database when the machine starts. To enable this feature and the associated clean shutdown, you must use the YaST Runlevel Editor.

By default, MySQL does not set a local administrator password. To set a password to protect the database, use the following command:

 Athena:~ # mysqladmin u root password newpassword 

The results of a Snort scan should be stored in a Snort-specific database. To create such a database within MySQL, sign into MySQL using the root account just defined and use commands similar to these:

 use mysql; create database snort; use snort; grant ALL on snort.* to [e-mail] identified by 'mspiggy'; grant ALL on snort.* to snort@localhost  identified by 'mspiggy'; exit 

These commands create an empty database for the Snort alerts. Before you can make Snort point to MySQL, you need to create the tables it is expecting. In the original installation of Snort, a script is provided to create all the required structures. The file containing the script is /usr/share.docs.packages.snort/ create_mysql. Enter MySQL using the Snort account this time and execute the preceding script:

 Athena:~ # mysql -u snort -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 14 to server version: 4.0.18 Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> use snort; Database changed mysql> \. /usr/share/doc/packages/snort/create_mysql 

This script creates a MySQL database to contain the Snort alerts. You can now proceed to configure Snort to enable logging to MySQL. In the snort.conf file, you need to find the section that contains a number of lines beginning with output database. In this section, you create a new entry like this:

 output database: log, mysql, user=snort password=mspiggy dbname=snort host=localhost 

This allows Snort to log to both /var/log/snort/alert as well as the MySQL Snort instance. With this change in place, it is now possible to restart Snort to activate the new logging feature:

 Athena:~ # /etc/init.d/snort restart 

The next step is to validate that you are logging events into MySQL. You can verify this by entering the MySQL Snort database and looking for entries in the tables of the Snort instance.

The configuration of the other components can be done quite easily. The PHP install is done through YaST and must include the PHP modules for Apache and MySQL. The ACID tool can be found at the following URL: http://www.andrew.cmu.edu/user/rdanyliw/snort/snortacid.html.

ACID REQUIREMENTS

The ACID tool is a great addition to Snort. It's easier to detect patterns graphically than to scan pages of logs visually. The graphical representation of alerts within ACID, coupled with the ability to drill down through the data to a specific event, allows an administrator to quickly determine the source of a threat.

The drawback, however, is that configuring all the components of ACID can be quite challenging. The distribution kit for ACID identifies a number of dependencies. ACID is written in PHP, but specific application hooks must be compiled into the executable. If you want to upgrade your version of PHP, you need to verify that dependencies such as gd and MySQL must be satisfied at compile time.

Though they are a bit tricky to set up, Snort and ACID are essential tools in your NIDS strategy.

Before proceeding any further, you need to secure your MySQL database. By design, database servers are network aware. With MySQL, a listener is created looking for network connections on port 3306. If your Snort sensor is co-located on the same server as your MySQL server, port 3306 need not be made available to the network. You can secure this port by ensuring it is blocked at the firewall level. Snort can log events to the database using the localhost network.

If you deploy a number of Snort sensors throughout your network, you will have to open port 3306 on the firewall. In the preferred scenario, only specific static IP addresses will be allowed to connect through the firewall. In addition, when granting permission to the Snort database, MySQL allows you to specify allowed client hostnames.

Included in the install kit for ACID is the necessary documentation for accessing the other required components. ACID, ADODB, and JPGRAPH are simple to un-tar and move into the default web root, /srv/www/htdocs. It is prudent to trim out all the sample and documentation folders that are not required for the proper functioning of the application. PCRE, on the other hand, requires a compiler environment and must be built through the .configure and make stages. All of this is well documented inside each package.

When all these packages are installed, you should find acid, adodb, and jpgraph-1.16 directories.

The ACID tool relies on a configuration file called acid_conf.php that resides in /srv/www/htdocs/acid. You must edit this file and customize it for your environment. The following variables must be defined to match your installation:

 $DBlib_path = "/srv/www/htdocs/adodb"; $DBtype = "mysql"; $alert_dbname   = "snort"; $alert_host     = "localhost"; $alert_port     = ""; $alert_user     = "snort"; $alert_password = "mspiggy"; $ChartLib_path = "/srv/www/htdocs/jpgraph-1.16"; 

After saving the modifications for the ACID configuration, you should be able to view your Snort alerts through the web. You can access the web page through http://localhost/acid/acid_main.php. An example of this page is shown in Figure 12.6.

Figure 12.6. The ACID main menu.

NOTE

Visibility is an important factor to keep in mind when you are deploying web-based tools. When you deploy an ACID website, ask yourself who has access to it. By default, websites are available to anyone who finds them.

Is it acceptable for you to show the world which events tripped your Snort sensor? If an attacker can also monitor your monitoring of network activity, could he change his approach and become more stealthy?

There are a number of steps you might want to take to secure your website:

• You can set up a firewall rule to accept connections only from specific TCP/IP addresses.

• You can also set up a robots.txt file. This keeps spiders from adding your website to Google and other search engines. It does not, however, prevent spiders that do not obey robots.txt files.

• You can enable SSL on the site and configure your web browser to support .htaccess files. This encrypts your HTTP conversations and adds a simple level of challenge-response protection to your site's content.

Keep in mind that the tools you deploy, unless secured, can be used against you.

On this page, you immediately get a significant amount of information not immediately apparent from the flat log files. You can quickly see the alert distribution across the various protocols (TCP, UDP, or ICMP). ACID also summarizes the alerts by category, alert type, ports, source, destination, and links.

Figure 12.7 represents the alerts broken down by category. You can see the five separate types of alerts as well as the number of alerts, the number of sources/destinations, and the time span over which the alerts were generated.

Figure 12.7. The ACID alert by category menu.

If you want to drill down further, you can find the alert used earlier in Listing 12.1. If you select the 36 members of the web-application-attack category, you can further refine the view of the Snort database down to the event level. After doing this, you can examine the details of the alert in a slightly more readable manner, as shown in Figure 12.8.

Figure 12.8. The ACID version of the Code Red example.

The ACID tool allows for a number of additional features unavailable directly through the log file. Since all of the data used by ACID is in MySQL, a number of queries can be launched directly on the database from the Search menu. In addition, it is possible to configure an archive database to keep specific events on file for future reference.

In this section, we discussed the importance of knowing what traffic is flowing across your network. It is important to understand the characteristics of your application-generated traffic. This allows for the appropriate firewall implementations. Traffic that is out of these norms should be refused. If a valid business requirement exists for this new format of traffic, the appropriate changes will have to be made at the firewall level. Measuring out-of-the-normal traffic permits the identification of potentially compromised systems.

For traffic that does fit within the allowed patterns of traffic, it is still important to remain vigilant. Application exploits will use an application's default port settings when attacking a service. Monitoring the content of the traffic can help determine whether it is malicious.

It is important to also note that, just as in the case for the Nessus tool, many corporate policies may prevent the application of network monitoring tools that actually capture packets.