Real-Time Alerting with Snort
18 - 36 min read
Jan 28, 2022
Real-time alerting is a feature of an IDS or any other monitoring application that notifies a person of an event in an acceptably short amount of time. The amount of time that is acceptable is different for every person.
Snort is built to perform one task and perform it very well. It does a magnificent job of detecting intrusions. Anything beyond intrusion detection is left up to the IDS analyst to handle. It is expected that you will add the features that make the IDS a truly pragmatic application. You have traveled down this road already, with the creation of an intrusion database to store alerting information and the installation of ACID to manage the collected data. Another powerful feature that should be added to Snort is real-time alerting.
Real-time alerting is a feature of an IDS or any other monitoring application that notifies a person of an event in an acceptably short amount of time. The amount of time that is acceptable is different for every person. Factors from the importance of the monitored system to the job duties of the responsible person can influence what is considered "real time". For some IDS analysts, checking ACID a few times each day will suffice. Other IDS analysts require real-time alerting that notifies them of a critical security event within seconds. It is this type of real-time alerting that is covered in this chapter.
Even if you do not plan to make use of real-time alerting at this point, you may want to deploy the capability for real-time alerting. If a critical situation presents itself, it is beneficial to be able to notify the right person. Although you may not want to be notified for each critical alert, there will likely be a point where a unique circumstance presents itself. When a vulnerability is released and an exploit is in use in the wild before a vendor has released a patch, you would probably want to be notified of suspicious activity on hosts that are known to be affected. Real-time alerting can be useful in incident response because you would want to be notified of possible new security breaches during the course of an incident. Installing the capability for real-time alerting assures you that you can deploy real-time alerting quickly in an emergency situation.
An Overview of Real-Time Alerting with Snort
Real-time alerting with Snort is highly customizable. You can pick and choose which alerts to be notified of in real time. Assigning a priority to each rule or classification of rule enables you to do this. Each rule can have an individual priority attached to it, and every rule can be included in a classification of rules that has a priority attached to it.
Rules can be prioritized so that one priority of rule can be sent to one person while a different priority is sent to another. You can set up a thirdparty Snort application to notify yourself of malicious remote buffer overflow activity, while alerting an entirely different person to inappropriate Internet activity. With the customizable prioritization of alerts, you can notify yourself of different rules in different manners. One priority of rules can be sent to an email address that notifies you via pager while another can simply send you an email.
The most popular method of deploying real-time alerting capability on a Snort IDS is with swatch (Simple Watcher)or syslog-ng (syslog-next generation). Swatch and syslog ng monitor Snort syslog output for a predetermined string. When they find the string, they execute a command. The command can be any available command on the system. Typically, a command is executed that sends an email. Other popular options include pager applications and audible alerts. Using swatch and syslog for real-time alerting is an ideal solution for a hybrid server/sensor installation. The syslog daemon is probably installed by default on the hybrid, meaning you merely have to set up swatch, configure Snort or Barnyard to log to syslog, and install an application for mailing alerts.
syslog-ng is the better choice for the distributed threetier Snort setup. If you have Snort installed in a distributed threetier setup, you will want to collect syslog alerts in a central location. Logically, the Snort server is the ideal location for collecting alerts from the sensors. The server then monitors for critical alerts and emails them to the appropriate person. Installing a mailing application and swatch on each sensor creates a lot of unnecessary work, so syslog-ng is used to collect alerts. The syslog-ng client accepts alerting data from Snort and passes it to a centralized syslog-ng logging server. Stunnel is used to encrypt the clienttoserver syslog-ng sessions. From the logging server, syslog ng calls a simple shell script that passes alerts on to the mailing application.
Prioritization of Alerts
Before getting into the details of deploying real-time alerting capability for Snort, you must decide which alerts are critical enough for you to be notified of. Snort is versatile in the prioritization of alerts;you can select individual rule categories for which you want to be notified. You can also select individual rules to be notified of as well. A prior ity specified in a rule overrides any specified in the rule's category.
The alerting application, be it syslog-ng or swatch, monitors the log for a specific string. When this string is found, it executes the mailing application and sends an email with data from the actual alert. The string for which you should set these applications to search is the priority level of the alert. You can configure what action to take based on the priority of alert. For example, alerts with a priority of 1 could execute a paging program. Alerts with a priority of 2 could be sent to an email account that is checked frequently. A subsequent priority level of 3 could be sent to a network abuse admin. The exact rule classifications and rules to be alerted of in real time are different for each Snort installation. You, the IDS Analyst, should make the decision concerning what is important enough to be notified of in real time. That being said, there are some general guidelines that you can use to determine what type of alerts you should be notified of in real time.
Incidents
Alerts deserving of a high priority and real-time alerting are usually those that are likely to indicate a security incident. If a rule triggers on remote control Trojan traffic, it is likely that a host has been compromised and requires immediate attention. Attack response traffic, such as pages or commands that are commonly called when a black hat successfully tests for an exposure, is a prime candidate for real-time alert. Any type of rule that is likely to result in a compromised host, such as an attack that is perpetrated against a known unpatched host, should generate immediate notification.
Targeted Attacks
Other possible categories of alerts to be notified of in real time are those that signify an attack is underway that could compromise a host. If a hacker is attempting specific attacks against certain versions of software residing on hosts that exist at your organization, you may want to include these rules in a real-time alerting strategy. This follows the logic that an attacker may have developed some prior knowledge of your network to determine the correct hosts to attack. Although the hacker could simply be guessing, it is likely that the hacker is determined to penetrate your network and is worthy of action. These attacks have a greater chance of success. In these cases you should identify rules that match existing hosts, services, and software versions and assign them a high priority.
Custom Rules
Other custom rules you have developed for your local environment, such as suspicious TFTP sessions from an external host, should be configured for real-time alerting. Custom rules are often created to bring greater monitoring coverage to a particular host, which implies that alerts generated are of a high priority. Custom rules created for these situations are ideal for real-time alerting. After you have decided on what rules to alert, you need to make a decision on who to alert and which types of alerts the appropriate persons should receive. If you are going to notify a single person or group of persons to security events, set all the rules and rule categories that require real-time alerting to the same priority level. If you have more than one group or person to notify, you should assign a priority level to each person or group.
Alerting a Group
When a group of people is on the distribution list for Snort alerts, you must be careful to spell out responsibilities ahead of time. A clear alerting strategy can prevent numerous problems when alerting to a group. All too often a group of people receives an alert, and then one person acts on it without notifying others. The first analyst to act on the alert could take corrective action that would confuse and frustrate the other analysts. I have been witness to an analyst on the third shift who deleted alerts before others could react, totally confusing the rest of the IDS team. The IDS team suspected for a time that a Snort server had been compromised. Another, far worse, scenario is that members of a group receiving real-time alerts will assume that another member has already taken action and will ignore a critical alert. It is important to establish these job responsibilities ahead of time to avoid this type of confusion.
If you are planning on installing more than one real-time alerting method, such as via email and pager, you need to further divvy up the rules between the different alerting methods. After you have this squared away, you can move on to implementing your alerting strategy in Snort.
Prioritizing with classification.config
You can edit the priority levels for rule categories in the classification. config file. Open the file, located at /etc/snort/conf/, and examine the different categories of rules. In the following examples, real-time notification is set for any rule with a priority level of 1. Change any of the classifications that you want to be notified of in this file to a priority of 1. For example, if you want to be notified of all successful DoS attacks, change the following line:
config classification: successfuldos, Denial of Service, 2
To:
config classification: successfuldos, Denial of Service, 1
If the classifications are not granular enough, you can create your own. Simply create the rule classification in classification. config and assign it a priority like so:
config classification: attackresponse, Successful Attack Response, 1
Note Notice the classification keyword contains no spaces, and there are no spaces between the delimiting commas.
Next you need to insert the new classification keyword into the rules that correspond to your new category. In this example the classtype option is changed in the following two rules:
alert tcp $HTTP_SERVERS $HTTP_PORTS >$EXTERNAL_NET any (msg:"ATTACK RESPONSES http dir listing ";content:"Volume Serial Number "; flow:from_server, established;classtype:attackresponse;)
alert tcp $HTTP_SERVERS $HTTP_PORTS >$EXTERNAL_NET any (msg:"ATTACK RESPONSES command completed ";content:"Command completed "; nocase;flow:from_server, established;classtype:attackresponse;)
You would now be alerted to these types of successful attack responses in real time.
The priority Option
You can also change the classification for individual rules. Assigning a priority option to the rule changes the priority for the specified rule. If you assign a priority to a rule and the rule has a classtype option with a different priority assigned to it, the priority option takes precedence. If you wanted to assign a different priority for the previous HTTP directory listing rule, you could make the following change:
alert tcp $HTTP_SERVERS $HTTP_PORTS >$EXTERNAL_NET any (msg:"ATTACK RESPONSES command completed ";content:"Command completed "; nocase;flow:from_server, established;classtype:attackresponse;priority:2 )
This would set the priority level to 2. Using the priority option method is useful in identifying rules that are critically important to your environment.
Alerting with the Hybrid
Deploying real-time alerting with the hybrid server/sensor is relatively easy. You need to install a mailing application, such as sendmail, to use real-time alerting via email. If you want to install another application, such as a pager or SMS gateway, you should do so. There are numerous resources online and in print for installing and configuring send mail. The documentation included with the source distribution is fairly detailed and should get you up and running. You can get the sendmail application and associated documentation at:
https://www.proofpoint.com/us/products/email-protection/open-source-email-solution
After you have deployed sendmail, you should take care to secure it. Sendmail has a relatively miserable history of security exposures and should be properly hardened. After sendmail is secure, you need to configure Snort to send alerts to syslog. Sending alerts to syslog is accomplished via the output plugin, alert_syslog. Open up snort.conf or barnyard.conf and enable the alert_syslog output plugin by uncomenting the configuration line. If you have Barnyard installed, you should make the changes to Barnyard rather than Snort. Your configuration line should read as follows:
output alert_syslog: LOG_AUTH LOG_ALERT
Now you should generate some suspicious traffic either manually or with NMAP. Check to make sure Snort is logging to syslog by opening the following file:
/var/log/snort/alert
You should see a list of alerts with a priority assigned to each one.You should see alerts similar to the following:
[1:1704:1 ] WEBCGI cal_make.pl directory traversal attempt [Classification: Web Application Attack ] [Priority:1 ] 09/1610:04:15.816116 192.168.1.1:3140 >192.168.1.2:80 TCP TTL:128 TOS:0x0 ID:12817 IpLen:20 DgmLen:131 DF ***AP***Seq:0xDEFC8E6D Ack:0x1A519F30 Win:0x4470 TcpLen:20 [Xref => ] [Xref => ]
[1:1122:2 ] WEBMISC /etc/passwd [Classification: Attempted Information Leak ] [Priority:2 ] 09/1610:04:15.826116 192.168.1.1:3143 >192.168.1.2:80 TCP TTL:128 TOS:0x0 ID:12832 IpLen:20 DgmLen:149 DF ***AP***Seq:0xDEFF5454 Ack:0x1A51AF74 Win:0x4470 TcpLen:20
[1:1730:1 ] WEBCGI ustorekeeper.pl directory traversal [Classification: Web Application Attack ] [Priority:1 ] 09/1610:04:15.836116 192.168 1.1:3144 >192.168.1.2:80 TCP TTL:128 TOS:0x0 ID:12837 IpLen:20 DgmLen:141 DF ***AP***Seq:0xDEFFEE00 Ack:0x1AB7B107 Win:0x4470 TcpLen:20
[1:1721:1 ] WEBCGI adcycle access [Classification:sid ] [Priority:2 ] 09/1610:04:15.846116 192.168.1.1:3148 >192.168 1.2:80 TCP TTL:128 TOS:0x0 ID:12857 IpLen:20 DgmLen:76 DF ***AP***Seq:0xDF035110 Ack:0x1A9AEFA4 Win:0x4470 TcpLen:20
Installing Swatch
Now that you are logging alerts, you need to install swatch to monitor syslog. Swatch requires four Perl modules in order to function. They are:
Date::Calc Date::Parse File::Tail Time::HiRes
Most Linux distributions include these modules. In case your flavor does not, you can get these modules from
https://metacpan.org/
To install them, run through the following list of commands to compile and install the modules:
perl Makefile.PL make make test make install make realclean
After you have the modules installed, you can download swatch. It is located at:
You can install swatch by using the same commands you used to install the Perl modules.
Configuring Swatch
Swatch is controlled from commandline arguments and configuration files, much like Snort and Barnyard. The configuration file for swatch is named .swatchrc. In the .swatchrc file you specify a string for swatch to monitor the log for and the action to take.
Some of the commands you could use to build real-time alerting include the following:
.watchfor This is the required command that tells swatch what string to monitor for in the log. You can specify any string. For the purposes of this book we will search only for strings that match a certain priority number. The following example is a watchfor command to monitor for alerts with a priority of 1.
watchfor /Priority \:1/
You can find a tutorial on building regular expressions that are used in pattern matching at .
echo The echo command echoes the matched line. This can be used to append alerting information into the body of the email, or to a text field in a pager .
exec This command is used to execute an external program. If you have a paging program or any other script you want to execute, use the exec followed by the full path to the program. You can add a $N or $0 to the exec command, which appends N lines or the entire alert to the executed command.
mail The mail option sends an email either to the local system or to a specified email address. You can store a group of email addresses in the alias file located at /etc/aliases , and use the alias to represent the group of email addresses.
throttle This command limits the number of alerts to be acted on. When the throttle is set, alerts that match the string are not acted on in the specified time. You can use this to avoid stressing your mail server and overloading your account.
You can use other commands for more advanced features of swatch, but the preceding are all you will need to send alerts via email or pager. With these commands you can install real-time alerting in many different manners. Open up the .swatchrc file for editing and add the following commands:
watchfor /Priority \:1/ echo=normal mail=user \@domain.com, subject=Snort Security Alert!
Note You must escape the @symbol with a backslash.
This configuration watches for any alert with a priority of 1 and emails
http://www.qpage.org
To send emails via QuickPage to a text pager, you could add these commands:
watchfor /Priority \:1/ echo=normal exec /usr/local/bin/qpage f
This command calls the QuickPage program and sends a page to IDS_admin, from the email address
watchfor /Priority \:2/ bell 5
This command rings the PC bell five times for each alert with a priority of 2.
Note This is sure to ruin any rapport you have developed with your coworkers.
You are not limited to one command set; you could implement all three if you wanted to. After you have the .swatchrc file configured to alert you in a manner you see fit, you can move on to running swatch. Swatch has a few commandline options you should be made aware of.
-c This option specifies the location of the .swatchrc file.
--input-record-separator With this commandline option you can specify the delimiting boundary for each alert. By default it is the newline character, \n.
-p The p is used to read information outputted directly from a command. You can use this to monitor the output of a command for specific events.
-t This option specifies the file to be monitored for security events.
--daemon Append this switch to enable daemon mode.
A sample swatch startup command follows:
./swatch c /usr/local/.swatchrc /var/log/snort/alert daemon
This command runs swatch in daemon mode using the configuration file located at /usr/local/.swatchrc . It will monitor the syslog file at /var/log/. If you run this command, you will notice that swatch sends only the first line of the alert, as follows:
[1:1704:1 ] WEBCGI cal_make.pl directory traversal attempt
It does so because the default input record separator is used, \n. If you would like to see additional meta information, such as IP addresses, time, TCP flags, and so on, you need to append additional lines of the alert.
To send the entire alert, make use of the tail command and swatch 's piping feature:
./swatch c /usr/local/.swatchrc inputrecordseparator="\n \n" p="tail f /var/log/snort/alert" daemon
The p switch watches the alert file with the tail command for new data. It uses a double carriage return, \n \n , for record separation. You should now receive the entire alert:
[1:1704:1 ] WEBCGI cal_make.pl directory traversal attempt [Classification:Web Application Attack ] [Priority:1 ] 09/1610:04:15.816116 192.168.1.1:3140 >192.168.1.2:80 TCP TTL:128 TOS:0x0 ID:12817 IpLen:20 DgmLen:131 DF ***AP***Seq:0xDEFC8E6D Ack:0x1A519F30 Win:0x4470 TcpLen:20 [Xref => ] [Xref => ]
This completes the swatch installation and real-time monitoring for hybrid server/sensors.
Alerting with Distributed Snort
To deploy real-time monitoring capability in a threetier Snort setup you use a different method than with the hybrid. It would be a waste of time and resources to install a mail ing application (such as sendmail)and swatch on each sensor. But making a single change to swatch and sendmail configurations across multiple sensors is bound to create confusion and possibly mistakes. To solve this problem, you can make use of syslog-ng and Stunnel to forward alerts securely from the sensors to the Snort server. You could optionally install another server to handle the alert collection and mailing functionality, in which case you would forward alerts to this new server.
syslog-ng is a replacement for the syslog logging facility used by many different applications on Unix systems. Error messages and security alerts from applications or the operating system are posted to syslog. The original syslog has only 20 possible event types, which are known as facilities. Each facility has a priority assigned to it. The facilities are generic and are used by many different applications, so you will have many different applications reporting events to syslog with the same facility. With many applications reported as the same facility, it becomes difficult to search for events generated by a specific application. Filtering is difficult when you have a large amount of data stored in a syslog file. syslog-ng solves this problem by making the filtering process much more granular. With syslog-ng, you can filter events based on the content of the event as well as the facility and priority. You can make use of regular expressions to filter events, which is not possible with the original syslog.
syslog-ng supports some additional features that make it ideal for the Snort environment. The source of alerts from the original syslog can be obscured if the alerts are for warded over more than one host or forwarded with Stunnel. If you collect alerts from many different machines on one host, syslog reports the correct logging host. But if you forward these syslog alerts again to a master host, the alerts appear to come from the second host. In a large Snort environment, where multiple logging servers are used, this can make determining the source of the alert difficult. syslog-ng solves this problem by storing the complete hostname, along with time the alert was generated on the local host. The original syslog sends alerts via UDP. This is problematic, because Stunnel does not currently support the encryption of UDP traffic. You could install a UDP tunneling package specifically for syslog sessions, such as Zebedee, to fix this problem. It is easier to upgrade to syslog-ng, which uses TCP, and make use of the Stunnel package you have already installed.
syslog-ng also has native support for emailing alerts. You can add lines in the configuration file to automatically mail alerts that match a particular string. This eliminates the need to install swatch.
Configuring Snort and Installing Sendmail
You need to install a mailing application, such as sendmail, to use real-time alerting via email. If you want to install another application, such as a pager or SMS gateway, you should do so. There are numerous resources online and in print for installing and configuring sendmail. The documentation included with the source distribution is fairly detailed and should get you up and running. You can get the sendmail application and associated documentation at
https://www.proofpoint.com/us/products/email-protection/open-source-email-solution
After you have deployed sendmail, you should take care to secure it. Sendmail has a relatively miserable history of security exposures and should be properly hardened. After sendmail is secure, you need to configure Snort to send alerts to syslog. Sending alerts to syslog is accomplished via the output plugin, alert_syslog. Open up snort.conf and enable the alert_syslog output plugin by uncommenting the configuration line. Your configuration line should read:
output alert_syslog: LOG_AUTH LOG_ALERT
The stage is now set for the installation of syslog-ng.
Installing syslog-ng on a Sensor
The first step to deploying syslog-ng is to install and configure the package on the sensors. syslog-ng is dependent on the libol package. You must install it before attempting to install syslog-ng. Download the latest version of libol at:
https://www.oneidentity.com
Run the familiar configure , make , and make install commands to install the libol package. After you have this completed, download syslog-ng from
https://www.oneidentity.com
You can run through the usual configure, make, and make install commands to install the package.
Configuring syslog-ng for the Sensor
syslog-ng is controlled via a configuration file, syslog-ng.conf . You will be writing this file from scratch. The examples in this book use the ports typically used by rservices (512, 513, 514) for syslog-ng. You should not be using any of the rservices on the Snort tiers because they are insecure. If you want to use ports other than those specified in the examples, you are free to do so.
To begin to configure syslog-ng for the sensor you must create a configuration file. Create a syslog-ng configuration file located at
/etc/syslog-ng/syslog-ng.conf
Note You want to create a new file, not use one of the default or sample syslog-ng.conf files included with the package.
The purpose of the syslog-ng.conf file is to let syslog-ng know where to look for syslog information and what to do with it after it is discovered. You do so by adding sources and destinations and then associating a source with a destination. The sources are potential locations from which syslog-ng can receive alerts, and destinations are areas to which they should be output.
Associating a source with a destination tells syslog-ng exactly where to look for alerts and where to send them. The two actions are not mutually exclusive;after you define a source you can associate it with as many destinations as your heart desires. The same holds true for sources.
The first line you need to build is a source line. It is used to identify the source of the syslog-ng alerts to the syslog-ng application. You need to name the source with an identifier as well. A good guideline for naming is to use the name of the sensor, then an underscore, and finally the integer the sensor uses in ACID.
Note This is only to help you remember what you have done at a later date; it is not required that you follow this guideline.
The following format provides an example:
source identifier {sourcedriver(parameter);};
The sourcedriver is where you want syslog-ng to look for alerts. The source driver can be the local machine, a TCP port, or even a file. You can specify as many sourcedrivers as you wish. For the sensor installation of syslog-ng, you should accept alerts from the local system. Use the following configuration line to accept alerts from the local system:
source sensor_7 {unixstream("/dev/log ");internal();};
The name of the sensor is sensor, which corresponds with the integer of 7 in ACID, so the identifier is sensor_7. The unixstream("/dev/log ")sourcedriverunixdgram("/dev/log"). The internal command tells syslog-ng to also listen for messages generated internally in syslog-ng.
The next line to create is the destination to which the alerts are to be sent. On the sensor, all alerts should be forwarded directly to the Snort server. This is specified with a destination line, which has the following format:
destination identifier {destinationdriver(parameter);};
The identifier is the name of the Snort server. The destination is the IP address and port that corresponds to the syslog-ng service that will be installed on the server. You should insert a line similar to the following:
destination snort_server { tcp("Snort_Server_IP " port (514)); };
This line sends alerts to a syslog-ng daemon listening on port 514/TCP located at Snort_Server_IP . The final configuration line you need to add, log, lets syslog-ng know which sources you want to correspond to which destinations. In this case there is only have one source and one destination, so only a single configuration line is needed. The log configuration line has the following format:
log {source(source_name); filter(filter_name); destination(destination_name) };
Because we are not using any filters at this point, we can ignore the filter options. We will need to filter syslog alerts later on to support real-time alerting. To construct the log line you simply utilize the source and destination lines you created previously:
log {source(sensor_7); destination(snort_server); };
This completes the configuration of syslog-ng on the sensor. We will have to revisit this file later to enable Stunnel. To start syslog-ng, run the following command:
/usr/local/sbin/syslog-ng
Installing syslog-ng on the Server
You can follow the same process for installing syslog-ng on the server as you did for the sensors. Download and install libol, then install syslog-ng.
Configuring syslog-ng for the Server
Configuring syslog-ng for the Snort server is relatively painless now that you understand how to configure a syslog-ng.conf file. Create a syslog-ng configuration file located at
/etc/syslog-ng/syslog-ng.conf
Open this file for editing. The first step is to create a source line that listens to both a TCP port and the local syslog-ng application. We want to see alerts that are incoming from the sensors, as well as any related to the syslog-ng application itself. Use the follow ing source line:
source sensors {unixstream("/dev/log "); internal(); tcp(ip(Snort_Server_IP ) port(514) maxconnections(7) };
This command listens for alerts generated locally by syslog-ng. It also listens for alerts via TCP to port 514 to the interface with the IP address of Snort_Server_IP assigned to it. You should change this IP address to match the IP of the management NIC you use to control the sensors. The maxconnections()option sets the maximum number of sensors that can connect to the syslog-ng server.
The next line to create is the destination configuration line. You should send alerts to a logfile local to the server. Do so with this line:
destination localhost { file("/var/log/snort.log ")); };
This writes all the logs from the sensors to the log file located where specified. To complete the posting of alerts to a local file, add a log statement to associate the source and destination:
log {source(sensors); destination(localhost); };
You should now test Snort by sending traffic to generate alerts and by checking the /var/log/snort.log file. If everything is working correctly, you can move on to configuring real-time alerting with syslog-ng.
Configuring syslog-ng for real-time Alerting
Configuring the syslog-ng to send alerts via email or pager involves creating a simple shell script that is executed by syslog-ng when a string is matched. The shell script in turn executes the mailing or paging application. Some additional configuration lines are required as well.
The first thing is to add the configuration lines, and then create the shell script. Open the syslog-ng.conf file for editing. You will use the source line that is used to log to the local snort.log file, so you need not create a new source line. The destination for the alerts is the shell script you have yet to create. Use this destination line to execute the script:
destination email_alert_script {program ("/usr/local/bin/alert_mail.sh "); };
The program option specifies the command to be executed that will receive the alerts. Be sure to include the full path.
Next, you need to create a filter that matches only your highpriority Snort alerts. If you want to match all Snort alerts with a priority of 1, you create this filter line:
filter high_priority {match ("\\[Priority:1 \\]"); };
Notice that you must escape the bracket symbols with a double backslash, \\. Create filters for each of the priorities on which you want to alert.
Now you must add the final log statement to tie the source, destination, and filter lines together.
log {source(sensors); filter(high_priority); destination(email_alert_script); };
This completes the setup of the syslog-ng.conf file. Exit and restart syslog-ng.
The final piece of the puzzle is to write the simple shell script that syslog-ng is to execute. Open /usr/local/bin/alert_mail.sh for editing. Enter the following script:
#!/bin/sh while read line; do echo $line |mail s "High Priority Snort Alert"
This script emails the alert to
Encrypting syslog-ng Sessions with Stunnel
You should already have Stunnel installed and configured on the Snort sensors and server. If you have yet to install Stunnel, you should revisit Chapters 6 and 7 for the installation instructions. To make use of Stunnel you have to make changes to the syslog ng.conf files on both the sensors and the server.
Open the syslog-ng.conf file on the sensor for editing. The first step is to include a global option that preserves the correct name of the local syslog-ng machine. If you do not set this option, all the alerts will have the hostname set as localhost , making it difficult to determine which sensor has generated the alert.
options { keep_hostname(yes); };
Next you will need to create a new destination line. You want to route traffic from syslog-ng so that Stunnel can read it, encrypt it, and forward the traffic on to the server. Add a new destination line that reads as follows:
destination stunnel {tcp("127.0.0.1" port (513)) ;};
This destination sends alerts to the localhost (127.0 0.1) on port 513. Next, you need to change the existing log line to use the new destination. Change it to
log { source(sensor_7); destination(stunnel); };
Save and exit the syslog-ng.conf file. Restart the syslog-ng process so that syslog-ng recognizes the new configuration file.
Now you must start a Stunnel daemon to handle the encrypted syslog-ng traffic. Run the following command:
/usr/local/stunnel/sbin/stunnel c d 127.0.0.1:513 r Snort_Server_IP :512 s stunnel_user g stunnel_group &
This command sets Stunnel in client mode with the c switch. It forwards syslog-ng traffic sent to port 513 on the localhost to the Snort server located at Snort_Server_IP . It also runs the daemon as stunnel_user , which is a member of stunnel_group. Stunnel is now configured for the sensor.
Moving to the Snort server, you need to make similar changes to the syslog-ng configuration file. Open the syslog-ng. conf file for editing. On the server, Stunnel accepts the traffic and forwards it to the local syslog-ng TCP port. The first step is to cre ate a new source line that reflects the change. Add the following source line:
source stunnel { unixstream("/dev/log "); internal(); tcp(ip(127.0.0.1) port(514) maxconnections(7) };
Now you need to alter the log line to reflect the new source. Change your existing log line to the following:
log {source(stunnel); destination(localhost); };
Save and exit, and restart the syslog-ng daemon. You are now ready to log from Stunnel to the local syslog-ng service. The final step is to start the Stunnel daemon on the server by using the following command line:
/usr/local/stunnel/sbin/stunnel d 512 r 127.0.0.1:514 p /usr/local/ssl/certs/stunnel.pem &
This command starts Stunnel listening on port 512 for incoming syslog-ng traffic. It then forwards traffic to the local syslog-ng server running on port 514. This completes the configuration of Stunnel. Alerts will now traverse the network encrypted.
Closing the Loop The distributed Snort setup you have is relatively resistant to sessionbased attacks. The MySQL connection is encrypted, the syslog-ng session is encrypted, and the ACID browser session is encrypted. Although the setup you have installed is by no means bulletproof, it should make the interception and modification of alerts relatively difficult for most intruders. The only major hole you could possibly have in the system is the real-time alerting emails. If you have bothered to encrypt all these connections, you should close the loop and encrypt the real-time email alerts. Check the documentation for your mailing application for instructions on installing an encrypt ed email system.
Summary
This chapter contains both an overview of real-time alerting strategies with Snort and how to configure them. Real-time alerting with Snort is highly customizable. You can pick and choose which alerts to be notified of in real time. Rules can be prioritized so that one priority of rule can be sent to one person while a different priority is sent to another.
Priority levels are managed through rule categories in the classification. config file. If the classifications are not granular enough, you can create your own. You can also change the classification for individual rules. Assigning a priority option to the rule changes the priority for the specified rule.
Deploying real-time alerting with the hybrid server/sensor is accomplished with syslog, swatch, and a mailing application such as sendmail. The installation and configuration of swatch is covered in this chapter. The configuration file for swatch is named .swatchrc . In the .swatchrc file you specify a string for swatch to monitor the log for and the action to take. Swatch can be configured to alert via pager, email, or audible alert.
To deploy real-time monitoring capability in a threetier Snort setup you use a different method than you do with the hybrid. It would be a waste of time and resources to install sendmail and swatch on each sensor. syslog-ng and Stunnel are used to forward alerts securely from the sensors to the Snort server. syslog-ng is a replacement for the syslog logging facility used by many different applications on Unix systems. syslog-ng supports some additional features that make it ideal for the Snort environment. The first step to deploying syslog-ng is to install and configure the package on the sensors. The chapter walks through an example that details creating the appropriate source, destination, and log lines that are used to configure syslog-ng on the sensor. After the sensors are installed and configured, the Snort servers are configured. The installation and configuration for the server is similar to the sensor.
Configuring the syslog-ng to send alerts via email or pager involves creating a simple shell script that is executed by syslog-ng when a string is matched. The shell script in turn executes the mailing or paging application. Configuration lines, including a source, destination, and log line, are used. A new configuration line, filter, is used to monitor for a specific string.
Stunnel should have been installed and configured on the Snort sensors and server in Chapters 6 and 7. To make use of Stunnel you have to make changes to the syslog ng.conf files on both the sensors and the server. The first step is to include a global option that preserves the correct name of the local syslog-ng machine. New source, destination, and log lines are required to enable Stunnel. The final step is to start Stunnel daemons that encrypt and decrypt the syslog-ng sessions.
Jack Koziol has been working in network security since 1998. He has contributes to Information Security Magazine, teaches "Hack and Defend" and CISSP review sessions courses, and speaks on various information security topics. Jack has held senior management positions in the ecommerce, healthcare and financial industries, where he has architected large scale Snort-based Intrusion Detection Systems for production environments. He is currently the Manager of Information Security at a national health benefits company headquartered in the western suburbs of Chicago.
The above is an exerpt of Chapter 11 from Jack Koziol's book entitled Intrusion Detection with Snort. It is available from Barnes and Noble or Amazon.com.
