Mastering Alert Generation with Snort: A Comprehensive Guide

The most valuable aspect of Snort is its ability to analyze and monitor real-time traffic as a NIDS (Network Intrusion Detection System). Ultimately, the alerts it generates are what we care about the most. Using Snort effectively means obtaining alert information and integrating it with other software modules. No one would sit around watching the terminal for alerts all day. Let’s introduce the alert information generated in NIDS mode. First, let’s look at the formats of alerts that can be generated and the methods through which they are produced when running in alert mode. The command is configured using the -A parameter, and there are six methods in total:

Parameter	Function
-A fast	Fast alert mode. Writes alerts in a simple format using a timestamp, alert message, source, and destination IP/port.
-A full	Full alert mode. This is the default alert mode if no mode is specified.
-A unsock	Sends alerts to a UNIX socket that another program can listen to.
-A none	Disables alerts.
-A console	Sends “fast-style” alerts to the console (screen).
-A cmg	Generates “cmg-style” alerts.

Now let’s look at how the alerts are generated one by one. For testing, first add the following two lines to snort.conf to make the operation simpler:

  Add interface
config interface:enp1s0
# Add log storage path
config logdir:/var/log/snort

You also need to configure the rules. Currently, we have enabled SCADA rules by adding include $RULE_PATH/protocol-scada.rules in snort.conf. The triggered rule is:

 alert tcp $EXTERNAL_NET any -> $HOME_NET 502 (msg:"PROTOCOL-SCADA Modbus read holding registers from external source"; flow:to_server,established; modbus_func:read_holding_registers; metadata:policy max-detect-ips drop; reference:url,www.modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf; classtype:protocol-command-decode; sid:17790; rev:5;)

Finally, we provide a pcap file /tmp/all.pcap as an analysis sample. It contains Modbus protocol data that triggers the above rule.

Fast Alert

Let’s test the fast alert generation by executing the command:

 snort -c /etc/snort/rules/etc/snort.conf -A fast -r /tmp/all.pcap 

Then, an alert file and a log file will be generated under /var/log/snort. The alert file stores the alert information, and snort.log.xxxx is the pcap file of the recorded alert packets. Isn’t it simple?

Now let’s look at the data in the alert file:

 [root@localhost ~]# cat /var/log/snort/alert 
08/03-13:47:59.825270  [**][1:17790:5] PROTOCOL-SCADA Modbus read holding registers from external source[**][Classification: Generic Protocol Command Decode][Priority: 3]{TCP}192.168.8.1:49695 -> 192.168.8.3:502
08/03-13:48:00.836034  [**][1:17790:5] PROTOCOL-SCADA Modbus read holding registers from external source[**][Classification: Generic Protocol Command Decode][Priority: 3]{TCP}192.168.8.1:49695 -> 192.168.8.3:502
08/03-13:48:01.862030  [**][1:17790:5] PROTOCOL-SCADA Modbus read holding registers from external source[**][Classification: Generic Protocol Command Decode][Priority: 3]{TCP}192.168.8.1:49695 -> 192.168.8.3:502

Let’s break down the first alert:

Field	Meaning
08/03-13:47:59.825270	Timestamp
[**]	Separator
[1:17790:5]	These three parts are GID|sid|rev, corresponding to Generator ID, the sid field in the rule, and the rev field. The gid can be looked up in the gen-msg.map file.
PROTOCOL-SCADA Modbus read holding registers from external source	The msg field in the rule
[**]	Separator
[Classification: Generic Protocol Command Decode]	Classification: Generic Protocol Command Decode
[Priority: 3]	Priority
{TCP}	TCP type
192.168.8.1:49695 -> 192.168.8.3:502	Source and destination addresses and ports

So, using the -A fast method, we can obtain the data as shown above.

Full Alert

Replace -A fast with -A full:

 snort -c /etc/snort/rules/etc/snort.conf -A full -r /tmp/all.pcap 

This will generate the following alert:

 [**][1:17790:5] PROTOCOL-SCADA Modbus read holding registers from external source[**][Classification: Generic Protocol Command Decode][Priority: 3] 
08/03-13:47:59.825270 192.168.8.1:49695 -> 192.168.8.3:502
TCP TTL:128 TOS:0x0 ID:60237 IpLen:20 DgmLen:52 DF
AP Seq: 0xA2229E72  Ack: 0x34FEC424  Win: 0x1400  TcpLen: 20[Xref =>  http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf]

The first three lines are similar to the fast alert, except the timestamp position has changed. The next two lines contain TCP protocol data such as TTL, TOS, Seq, and Ack. The last line is the reference field from the rule.

Socket Transmission Alert

Use the -A unsock parameter and execute the command:

 snort -c /etc/snort/rules/etc/snort.conf -A full -r /tmp/all.pcap 

This means Snort will create an IPC socket and send alert information to this socket. Other processes can listen to this local socket to receive alert information.

The socket file is snort_alert, located in the log path you used, which is /var/log/snort.

The socket API was originally designed for network communication, but later an IPC mechanism was developed on the socket framework, known as UNIX Domain Socket. Although network sockets can also be used for inter-process communication on the same host (via the loopback address 127.0.0.1), UNIX Domain Socket is more efficient for IPC: it does not need to go through the network protocol stack, does not need to pack and unpack, calculate checksums, maintain sequence numbers, and acknowledgments, just copying application layer data from one process to another. This is because the IPC mechanism is inherently reliable communication, whereas network protocols are designed for unreliable communication. UNIX Domain Socket also provides stream-oriented and packet-oriented API interfaces, similar to TCP and UDP, but message-oriented UNIX Domain Socket is also reliable; messages are neither lost nor out of order.

It is worth noting that the sent message only contains the msg field from the rule, i.e., “PROTOCOL-SCADA Modbus read holding registers from external source,” and no other information, making this method somewhat limited.

Disable Alerts

Sometimes users just want some peace and quiet. …

 snort -c /etc/snort/rules/etc/snort.conf -A none -r /tmp/all.pcap 
 

Console Output Alerts

This is mainly used to debug and view alert information directly in the terminal.

 snort -c /etc/snort/rules/etc/snort.conf -A console -r /tmp/all.pcap 

CMG Mode

This will output results in the console, including link layer data and subsequent data segment content.

 snort -c /etc/snort/rules/etc/snort.conf -A cmg -r /tmp/all.pcap 

The results are as follows

 08/03-13:47:59.825270  [**][1:17790:5] PROTOCOL-SCADA Modbus read holding registers from external source[**][Classification: Generic Protocol Command Decode][Priority: 3]{TCP}192.168.8.1:49695 -> 192.168.8.3:502
Stream reassembled packet
08/03-13:47:59.825270 C8:F7:50:F6:5F:D4 ->  A4:BB:6D:AA:2E:45 type:0x800 len:0x42
192.168.8.1:49695 -> 192.168.8.3:502 TCP TTL:128 TOS:0x0 ID:60237 IpLen:20 DgmLen:52 DF
AP Seq: 0xA2229E72  Ack: 0x34FEC424  Win: 0x1400  TcpLen: 204179 00 00 00 06 01 03 00 00 00 0A              Ay..........=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Finally, let’s add a high-speed processing method

Storing Alerts in Unified2 Format

Configure snort.conf, enable unified2, output unified2:filename snort.log,limit 128

By executing the command

 snort -c /etc/snort/rules/etc/snort.conf -r /tmp/all.pcap 

You can generate results in the log path. This result is no longer a pcap file but binary data. To view it, use the command

 u2spewfoo /var/log/snort/snort.log.1637217363 

Then you can use the Barnyard2 tool to slowly write the data into MySQL.

The purpose of Barnyard2 is to read the binary event files generated by Snort and store them in MySQL. Snort’s configuration file itself contains plugins that allow Snort alerts to be recorded in MySQL, but this causes a surge in system data. When the IDS system detects malicious behavior, it uses INSERT statements to write data into the database, causing updates to be very slow. Therefore, if Snort outputs directly to the database, the efficiency of this solution is not high when the data volume increases. Hence, an external agent is used to output alerts to Barnyard2.

This won’t be detailed here. If interested, you can search for “snort barnyard” on Google.

Back to the main point, the results are meant to serve other software. By using these methods, Snort can be integrated as a key module into the system, which is the right way. Recently, I found that studying and writing blogs can be addictive, just like when I used to go to the gym years ago. I would go to the gym right after work and wouldn’t skip weekends. The way to make something addictive is to see immediate results, no matter how small. Once you get through the first few days, you can’t stop. Another reason is: boredom.