Threat Response - Integration with Suricata

This document covers all aspects of Threat Response integration with Suricata. There are multiple ways to exchange log information between Suricata and Threat Response. Suricata has its own simple integrated logging facility, or you can leverage common syslog clients that come packaged with your operating system, like rsyslog and syslog-ng. In this document, we will cover how to configure each model.

Forwarding Alerts to Threat Response

Suricata can forward alerts to Threat Response so that they can be managed using Threat Response’s incident response workflow. This chapter will detail the process of both configuring an alert listener in Threat Response, as well as configuring Suricata to forward alerts to Threat Response via syslog.

Creating an Alert Source in Threat Response

You must first create an event source in Threat Response to receive alerts from Suricata. The steps below outline the source creation process.

To create a Suricata alert source:

  1. Log in to Threat Response.
  2. Navigate to the Sources page.
  3. Click the blue Add (+) button next to Sources to bring up the New Source panel.
  4. Set the following fields:
    • Type: Suricata
    • Name: <alert_source_name>
    • Description: <description>
    • Link Events: <checked>
    • b: limit sources to certain IP addresses or hostnames
  5. Save changes

small

With the source configured, Threat Response is now ready to receive alerts from Suricata. The remainder of the configuration lies in Suricata.

Note

Due to the syslog nature of these alerts, Threat Response only allows the creation of a single Suricata event source.

Configuring Suricata Event Logging

To begin the configuration in Suricata, we will need to configure Suricata’s syslog settings. Before you can configure your Suricata sensor to send logs via syslog, you must determine which syslog package your system has. On *nix platforms, this is usually one of the following: rsyslog, syslogd, or syslog-ng.

To determine which syslog package you are running:

  • Use the ‘ps’ command to look for running instances of syslog:
# ps aux | grep syslog
  • The resulting output will include the syslog service running on your system.

With the appropriate syslog service for your machine identified, you can begin configuring Suricata for event logging. In the example below, we assume the suricata.yaml file is located in /etc/suricata/, and use local5 as our logging facility.

To prepare Suricata for event logging:

  • Open the Suricata configuration file in a text editor:
vi /etc/suricata/suricata.yaml
  • In the configuration file, locate the syslog section, and update the items in bold below to the appropriate values:
syslog:
    enabled: yes
    # reported identity to syslog. If omitted the program name (usually
    # suricata) will be used.
    identity: "suricata"
    facility: local5
  • Save the file
  • Restart Suricata.

Now that we have configured Suricata to log malicious activity to the local syslog facility, we must configure the individual syslog daemon to forward the logs in the next section.

Configuring Syslog Forwarding to Threat Response

Now that we have configured Suricata to log alerts locally to facility local5, we can now leverage a common syslog package such as syslog or rsyslog to send the logs to Threat Response. The configuration from syslog is identical for our purposes; it is just a matter of the file and service names. We will cover both scenarios here.

Rsyslog Configuration

Assuming that the rsyslog package is already installed on your system, it is very easy to configure rsyslog to log alerts.

To configure rsyslog:

  • Edit the rsyslog.conf file with your favorite text editor. This file is typically located under /etc/.
vi /etc/rsyslog.conf
  • Add a statement which maps the local5 facility to logs that will be sent to your syslog host. The format is facility.severity @<host ip or name>:<port-optional>. For this example we will log all logs received by local5 to our syslog server at 10.1.1.56 which listens on TCP and UDP ports 514. Simply add the following statement into your configuration.
local5.* @10.1.1.56:514
  • Now that you have applied the configuration, your syslog server must be restarted. This will vary depending on the OS that you are running. 
Centos 6: service rsyslog restart
Centos 7: systemctl restart rsyslog
Ubuntu: sudo service rsyslog restart

Syslog Configuration

Assuming that the syslog package is already installed on your system, it is very easy to configure syslog to log alerts.

To configure syslog:

  • Edit the syslog.conf file with your favorite text editor. This file is typically located under /etc/.
vi /etc/syslog.conf
  • Add a statement which maps the local5 facility to logs that will be sent to your syslog host. The format is facility.severity @<host ip or name>:<port-optional>. For this example we will log all logs received by local5 to our syslog server at 10.1.1.56 which listens on TCP and UDP ports 514. Simply add the following statement into your configuration.
local5.* @10.1.1.56:514
  • Now that you have applied the configuration, your syslog server must be restarted. This will vary depending on the OS that you are running.
Centos 6: service syslog restart
Centos 7: systemctl restart syslog
Ubuntu: sudo service syslog restart

With the appropriate syslog settings in place, the configuration is complete, and Suricata will begin forwarding alerts to Threat Response.