Snort Reporting and Alerting

The Snort Network Intrusion Detection System (NIDS) continues to grow in popularity among institutions of all sizes. An open-source, low-cost platform for detecting anomalous and suspicious network traffic, Snort boasts a strong support community of end users who help answer questions and developers who create ancillary services and applications that enhance Snort's core features. A Snort mailing list available at http://www.snort.org serves as a great resource.

Before you begin to use Snort, you'll want to know about some of the more popular and effective reporting and alerting tools available, including the Analysis Console for Intrusion Databases (ACID) and Silicon Defense's SnortSnarf reporting tools, as well as tips about how to send realtime alerts when events trigger specific signatures. You can download the latest version of Snort, several reporting and alerting add-ons, and several good step-by-step white papers that describe how to configure and run Snort at Snort.org. If you haven't used Snort before, I recommend that you read these white papers. To kick things off, let's review a sample Snort topology. Then we'll look at some Snort reporting and alerting options.

Sample Snort Topology
Snort is available for both the Windows and UNIX/Linux platforms. Although the Linux version has a wider following and offers many feature-enriching add-on tools, support for the Windows version is growing. The latest version for Windows, Snort 2.0, supports most of the functions that the latest version for Linux, Snort 2.0.0, offers. In the past, I've run several Snort sensors on a Windows platform. Recently, however, I've switched to running Snort on Linux because of the additional TCP/IP tools and flexibility available for the Linux OS. However, in most cases, you can adapt the solutions I present in this article to either environment.

Web Figure 1 (http://www.secadministrator.com, InstantDoc ID 39235) shows a sample Snort deployment for two offices. Both offices connect to the Internet independently through a firewall and use a VPN to connect directly to each other. The main office Internet connection terminates at a router that connects to an external switch, which in turn connects to the firewall's external interface. The firewall's internal interface connects to an internal switch that serves the rest of the systems in the main office. The satellite office's Internet connection terminates at a firewall/router network device (because no external subnet or Ethernet device exists to plug the sensor into, we'll use an internal sensor). Like the main office, the satellite office connects the internal interface of its firewall/router device to an internal switch that serves the rest of the office.

Keep in mind that the location and type of network switches or hubs you use are important when designing a NIDS. A Snort NIDS typically consists of multiple sensors around the perimeter and at other sensitive areas of your network. These sensors percolate alerts up to a central reporting server (e.g., a database or event-monitoring system). The sensors each run the Snort software and operate more or less independently of one another. Snort sensor management typically consists of tweaking rule files that you can then copy to the remote sensors. (Open-source tools such as Activeworx's IDS Policy Manager help you manage your Snort configuration by letting you centrally manage multiple sensors.) Because the purpose and placement of sensors is to detect inbound threats, you need to protect your sensors from becoming targets themselves.

To isolate and protect each sensor, you should prohibit the sensor from transmitting on the interface connected to the span port and configure the span port to send data only to the Snort sensor. A span port is a hardware feature on a network switch that you can configure to mirror and copy to the span port any or all traffic on other switch ports. Many switches offer port spanning (some vendors call this port mirroring).

Taking these steps will enable your sensor to receive data only from the span port. You can also use a hub instead of a switch so that every port sees the traffic on every other port. In this case, you can physically modify the network cable between the Snort sensor and the hub to prevent the sensor from transmitting data.

In our sample Snort topology, the main office sensor is triple-homed (i.e., it has three network interfaces). The first interface connects to a span port on the external switch, and the second interface connects to a span port on the internal switch. I've configured the span ports to receive all traffic seen by the internal and external firewall interfaces.

The internal sensor lets us detect whether any suspicious traffic breeches the firewall. In addition, if the firewall uses Network Address Translation (NAT), then placing an internal sensor can help expose the IP address of any internal machines that might generate suspicious traffic, such as a worm-infected machine. True-source IPs are beneficial when reviewing alert reports. However, be prepared for a deluge of information because alerts will likely bombard the external interface, giving you a sense of just how many attacks are hitting your firewall.

The third and last interface on the main office Snort sensor connects to the main office LAN. This interface is the management interface and possesses an IP address on the inside network for communicating with the Snort database or reporting server.

The configuration of the satellite office Snort sensor is similar to that of the main office except that no switch or hub is available to sniff external traffic. This sensor is dual-homed, and the first interface monitors for anomalous traffic inside the firewall only. The second interface is on the same VPN as the database or reporting server. Alerts received by the satellite office are sent across the VPN to the main office. In all, this sample topology consists of three Snort sensors and a Snort database server. You should size the computers running the Snort sensors according to the size of the network and the anticipated traffic.

Reporting and Alerting
You use the Snort configuration file, labeled snort.conf by default, to configure each sensor to forward data to your reporting or alerting service. This configuration file defines Snort variables, preprocessors, output plugins, and the locations and names of the rules files. Snort variables are used in rule processing to define network objects such as your home network or the location of your Web or DNS servers. The preprocessors provide additional built-in functionality to Snort and often store auxiliary or experimental features. For example, the portscan preprocessor specifically watches for and reports on the occurrence of port scans, and the streams4 preprocessor provides stateful inspection to Snort in an attempt to reduce false positives. The streams4 preprocessor inspects all traffic and forwards only traffic that has negotiated a three-way handshake to the rules processor. Current Snort versions contain more than 14 preprocessors.

The output plugins define how and where the Snort sensor should send alerts and logs. Snort supports sending output in Syslog, tcpdump, MySQL, PostgreSQL, Microsoft SQL Server, XML, and SNMP formats, as well as a proprietary binary format. Last, the configuration file contains the location and names of the rules that you want to enable on that sensor.

After a default installation and without any specific output plugins enabled, Snort logs all alerts to a file named Alert in the default log directory /var/log/snort. (You can use the -l command-line switch to specify a log directory other than the default.) Snort appends new alerts to a file named alert and also logs each alert independently to a directory named for the alert originator's source IP address. The logs provide quick, file-level access to the alerts on each sensor. However, if you want to aggregate alerts across multiple sensors, consider the database output plugin or syslog output plugin.

The database output plugin lets Snort forward alerts to a centralized database. Current Snort versions support MySQL, PostgreSQL, unixODBC, and SQL Server output. However, many Snort add-on tools support only MySQL and PostgreSQL. As a result, if you choose to use SQL Server as your Snort database server, you might not be able to run some of the reporting tools. (Be aware that if you run your sensors with the database output plugin enabled, some local alert logging will be suppressed, which might affect your ability to use other tools that rely on detailed log files.) You can also develop your own database or front-end application to review the Snort alerts. The schema for the Snort database is available on the Snort.org Web site.

Reporting with ACID
One of the most successful Snort reporting systems is a freely available program called ACID that provides a Web browser interface to manage Snort alerts. ACID is written in PHP and natively supports MySQL, PostgreSQL, and SQL Server. To learn how to configure Snort and ACID for use with MySQL and PostgreSQL, visit Snort.org and http://acidlab.sourceforge.net/acid_config.html. Limited instructions that describe how to install Snort and ACID in a SQL Server environment are also available at these Web sites. You don't need to deploy ACID on the same server or OS as the alert log database. For example, you can deploy your sensors on Linux, run MySQL on Windows 2000, and host the PHP pages from an Apache or Microsoft IIS Web server that has PHP support. As a result, you can deploy your sensors on a mix of platforms and connect each sensor to a database that you can maintain on a system separate from the Web server.

To trigger an alert, a sniffed packet must match a signature that you've defined in a Snort rule. The main ACID Web browser interface, which Figure 1 shows, gives a big picture of the Snort alerts received. Hyperlinks on this page let you drill down into an alert to examine which sensor sent it, type, source or destination IP address, and the unique qualities of the alert, as Figure 2 shows (although the IP addresses do appear in the software, I've removed this information in these sample images). Additionally, you can graph alerts over time to look for spikes and trends. ACID includes graphs that show time versus number of alerts, source or destination IP address by alerts, TCP or UDP port by alerts, signature by alerts, and sensor by alerts. Additionally, you can view alerts based on classification, such as attempted-recon, misc-activity, attempted-dos, attempted-admin, and successful-admin, among others. These classifications provide a convenient way of organizing alerts while bringing attention to those of most interest. To find a specific alert or range of alerts matching known criteria, ACID supports flexible searching of alerts based on sensor, signature, time, IP properties, and payload.

ACID supports several options for alert management. You can email alerts to others, archive alerts, or categorize alerts into your own Alert Groups (i.e., user-defined collections of alerts). For example, you might create an Alert Group to store all alerts pertaining to a specific investigation. In addition, Alert Groups offer an easy way to recall or graph previously received alerts.

ACID is a fantastic tool for viewing alerts, but it can't notify you in real time of new alerts and it can't act upon an alert. However, other tools do provide real-time alert monitoring, which I discuss a little later.

Prerendered Reporting with SnortSnarf
SnortSnarf is a Perl-based reporting tool that you can schedule to run repeatedly to create basic, prerendered HTML pages summarizing Snort data, one of which Figure 3, page 4, shows. You can configure SnortSnarf to read each sensor's log file, or if you already use the database output plugin, you can configure SnortSnarf to pull all aggregated data from a MySQL or PostgreSQL Snort database.

Although SnortSnarf's reporting isn't as robust as ACID's, the prerendered reporting tool offers some advantages. Because SnortSnarf stores alert data in flat HTML files, it gives you quick access to archived alerts. For example, you can burn your SnortSnarf-generated HTML files to a CD-ROM, which makes reviewing the alerts as simple as opening the HTML pages from the CD-ROM on any computer with a Web browser.

Because SnortSnarf uses a Perl script to preprocess the data, navigating through the alerts is very quick, although your data is only as current as the last time you ran the script. SnortSnarf speeds the process of scanning for top source and top destination IP addresses and then drilling down into them to review the severity of the alerts. For example, if any of the top source IP addresses are in your internal network, you might have a problem. You can drill down into such an IP address and quickly review what alert was triggered, perhaps revealing that one of your internal machines is infected with a worm. Figure 4 shows a sample SnortSnarf-generated alert page. From this page, you can click a summary link to get more information about a particular alert as well as links to many popular reverse and whois lookup engines to assist you in identifying the intruder.

The SnortSnarf installation documentation assumes you have a working knowledge of UNIX. The installation procedure isn't as step-by-step as an ACID or Snort installation, but the steps are short. For complete instructions, visit the Silicon Defense Web site at http://www.silicondefense.com/software/snortsnarf.

Realtime Alert Monitoring with Syslog
Snort generates alerts about suspicious traffic, but what alerts you about Snort's alerts? Reporting tools such as ACID and SnortSnarf are, by their nature, typically latent and require that you actively inspect them for alerts. Fortunately, you can configure Snort to alert you in realtime whenever an action generates a specific alert. One such realtime alert monitoring tool is Syslog.

You can use Syslog, UNIX's native event-logging system (similar to Windows' event-logging system), to email Snort-generated alerts. First, configure Snort to forward alerts to the sensor's Syslog daemon and define the messages with a unique facility that differentiates them from messages generated by other applications that also use Syslog. The Syslog daemon examines the alert message, and depending on the alert's characteristics (priority and facility), the daemon writes the alert to a file or forwards it to another Syslog daemon. Second, a parsing routine examines the file and uses its own set of rules to initiate an action such as emailing an administrator or executing a program.

Syslog is typically installed on every UNIX system, and several UNIX-based scripts and applications support the realtime parsing and notification of Syslog messages. The Windows platform doesn't natively use Syslog; however, several third-party shareware versions of Syslog daemons are available. A popular shareware Syslog daemon for Windows is Kiwi Enterprises' Kiwi Syslog Daemon (http://www.kiwisyslog.com). This full-featured application supports advanced Syslog event manipulation, including emailing alerts. An easy-to-implement cross-platform Syslog solution is to install UNIX Snort sensors and forward all Syslog alerts to Kiwi Syslog Daemon running on Windows, which then generates the email alerts.

Snort can bombard you with alerts, and you probably won't want to receive an email message or page every time there's a new alert. To filter out some of this alert information, you can configure a Snort rule type to specify only those rules that you want to forward to Syslog. Then, you can decide whether Syslog needs to perform further parsing before emailing you an alert.

Configuring a New Rule Type
By default, Snort contains five rule actions (aka rule types): alert, log, pass, activate, and dynamic. Snort determines what action to take depending on the rule action. For example, Snort.org defines all rules as an alert action, which means Snort processes them as alerts. Snort sends all alerts to enabled output plugins, which is what you want for reporting. However, if you want to escalate a specific alert to an email message or page, you must differentiate that alert from its brethren. One way to do this is to create a custom rule type in the snort.conf file. The default snort.conf file contains a template that lets you create new rule types. For example, the sev1 rule type:

ruletype sev1{   type alert   output alert_syslog:     LOG_LOCAL5   output database: log, mysql,      user=snort dbname=snort     host=dbserver.domain.com     sensor_name=External}

defines an alert type that overrides any previous output plugins in favor of those listed in its definition. This sev1 rule type sends alerts to Syslog and logs the alerts to a database.

Next, you must update the /etc/syslog.conf file to recognize inbound Syslog messages from the local5 facility (this example assumes that the local5 facility is being used only for Snort logging). The line

local5.*        /var/log/snort

writes any received alerts from the local5 facility to the /var/log/snort text file.

Next, you must define the sev1 rule type in a Snort rules file. For example, you can update local.rules with the following two custom rules.

sev1 tcp any any -> any any  (msg:"Severity One rule-  Test Rule for Snort";  content:"sev1"; nocase; ) alert tcp any any -> any any  (msg:"Severity Two rule-  Test Rule for Snort";  content:"normal"; nocase; )

Snort typically stores custom rules in the local.rules file. The first rule begins with the sev1 rule type instead of the action alert. As a result, when Snort identifies a packet matching the sev1 signature, it processes the packet according to the previously defined sev1 rule type. The Severity Two rule represents any custom rules you've defined for your Snort environment. The Severity Two rule is defined as an alert rule type, and Snort processes it in the same manner as it processes other default Snort rules. (Remember, Snort.org classifies all its downloaded rules as alert rule types.)

When you define rule types, you're using Snort to filter for higher-sensitivity realtime alerts rather than filtering downstream in Syslog. This approach reduces traffic and maximizes Syslog performance because Syslog handles only alerts that Snort determines are worthy of an email message or page. If you use the above configuration settings, Snort will forward any sev1 alert to Syslog as a local5 facility message. Syslog will write these messages to the /var/log/snort text file. Alternatively, you can send all alerts to Syslog, then use a sophisticated Syslog filter to look for specific alerts. Whether you filter alerts within Snort or downstream with an add-on realtime monitoring tool like Syslog depends on what software you have available and where you want to focus your processing and data manipulation.

Parsing the Syslog Text File
If Snort is sending sev1 alerts to Syslog, you need another tool to read these alerts in the /var/log/snort text file. Several text-file parsers can monitor a file and email any new alert messages based on a variety of criteria. One popular product is simple watchdog (SWATCH), a UNIX tool designed to continuously monitor a log file (e.g., a Syslog output file) and take actions when specific events occur. For example, if you want a sev1 alert to trigger an email message, you can configure SWATCH as follows:

watchfor / Severity One/   echo   mail addresses=     ,     subject=IDS   throttle 00:10:00

SWATCH supports regular expressions (e.g., /TCP 143[34]/ to look for either TCP 1433 or TCP 1434), which adds flexibility to your query. For example, the above entry instructs SWATCH to echo the message to the console and send an email message anytime the phrase Severity One appears in the Syslog text file. The throttle command limits consecutive actions based on recurring alerts. Throttle 00:10:00 means that after SWATCH makes a match and sends one email message, it won't send another email message for 10 minutes. Unfortunately, I had difficulty getting the throttle command to work reliably.

An alternative to parsing the Syslog text file on every sensor is to forward each sensor's Syslog alerts to a central Syslog daemon (e.g., Kiwi Syslog Daemon) that has built-in filtering and actions. This approach requires another application on possibly another system, but it's easy to configure and offers more functionality than many UNIX script-based Syslog parsers. To use a central Syslog daemon to aggregate your Syslog events, add the IP address of the central aggregation server to each sensor's Syslog.conf file. For example, in the syslog.conf file for one of the Snort sensors, you would include instructions to forward all local5 alerts to another Syslog server located at 192.168.0.110, like so

local5.*    @192.168.0.110

The local Syslog daemon on the computer running Snort will forward crucial alerts to the centralized Syslog daemon, such as the Kiwi Syslog Daemon that Figure 5, page 6, shows. You can then use the central Syslog daemon to provide daily statistics or customize the formatting of the alert email messages that it sends.

Many More Snort Add-Ons
Although open-source software (OSS) varies widely in the quality of its documentation and in its ease of configuration, you'll find a wide range and large quantity of available solutions. The open-source Snort NIDS is a fantastic system that its end-user community is continually improving. Whether you use ACID, SnortSnarf, Kiwi Syslog Daemon, SWATCH, a combination of these tools, or any other Snort-related reporting and alerting products, you probably won't have a question that someone before you hasn't asked or that hasn't already been answered on the Internet. Be sure to visit Snort.org and check out the new and old add-ons for Snort. Many more are out there that I didn't mention.