This article is excerpted from the new book Intrusion Detection with Snort by Jack Koziol.
Real-time alerting is a feature of an intrusion detection system (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.”
Real-time alerting with Snort is highly customizable. You can pick and choose which alerts to be notified of in real time by assigning a priority to each rule or classification of rule. 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 third-party 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 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 — typically, a command that sends 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 a distributed three-tier Snort setup. If you have Snort installed in a distributed three-tier 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 client-to-server 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 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 priority specified in a rule overrides any specified in the rule’s category.
The string for which you should set syslog-ng or swatch 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.
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.
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 job responsibilities ahead of time to avoid this type of confusion.
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: successful-dos, Denial of Service, 2
To:
config classification: successful-dos, 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: attack-response, Successful Attack Response, 1
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:attack-response;)
alert tcp $HTTP_SERVERS $HTTP_PORTS ->$EXTERNAL_NET any
(msg:"ATTACK RESPONSES command completed ";content:"Command completed ";
nocase;flow:from_server, established;classtype:attack-response;)
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:attack-response;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.
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. We’ll talk about that tomorrow.
Jack Koziol is manager of
information security at a national health benefits company
headquartered in the western suburbs of Chicago.
He has been working in network security since
1998. He 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 has contributed to Information Security
Magazine, teaches “Hack and Defend” and CISSP review
sessions courses, and speaks on various information
security topics.
Category:
- Security
