Network Intrusion Detection Plugin with Suricata

Configurable NIDS Plugin

Suricata was developed for the United States Department of Homeland Security (DHS) by the Open Information Security Foundation (OSIF). It was chosen due to simplicity of configuration and high performance. Suricata is deployed using VNS3’s plugin system.

Please be familiar with the VNS3 Plug-In Configuration Guide.

VNS3 NIDS Plugin Overview

The VNS3 NIDS plugin preconfigured to utilise the built in rule management feature Suricata-Update. This will download and manage the ET Open Ruleset provided by Emerging Threats on a free of charge basis.

Accessing the Basic NIDS Plug-In

The Suricata plugin can be found at the following URL:

This is a read-only Amazon S3 storage location. Only Cohesive Networks can update or modify files stored in this location.

This URL can be used directly in the Web UI or API to import an image into a VNS3 Controller (detailed steps can be found here:

Uploading an image and launching a Container

In the VNS3 UI, from the Container menu —> Images menu item, choose Upload Image. You will be asked to:

  1. Name your image - this will be the display name of the uploaded image.
  2. Provide a Description - The description should reflect the purpose of the image, it is a template for all containers created from it.
  3. Select what type of upload in the dropdown box - choose Image File URL.
  4. Paste the URL above into the last box. Select Upload

Get the Default NIDS Plug-In

When the Image has imported it will say Ready in the Status Column.

To launch a Suricata container instance from an image choose Allocate from the Action menu.

Get the Default NIDS Plug-In

After selecting Allocate from the Actions menu you will be asked to:

  1. Name your container - this will be the display name of the running container.
  2. Provide the Command to run your container - The command to run the Suricata container is:/usr/bin/supervisord
  3. Provide a Description - The description should reflect the containers purpose, e.g.“Database server protection”.

Launching a NIDS Container

Confirming the NIDS Container is running

After executing the Allocate operation you will be taken to the Container Display page.

You should see your NIDS Container with the name you specified. The Status should be Running and it should have been given an IP address on your internal plug-in subnet (in this case

Confirming a NIDS Container is Running

Working with the NIDS Plugin

Accessing the NIDS Container

Accessing your container from the Internet or your internal network will require additional rules in your cloud security groups, as well as VNS3 firewall rules to access the running container.

To access your Suricata plugin via SSH listening on port 22 you will need to do the following:

  1. Add a port to your VNS3 security group from your source IP or internal network (e.g “44”) - this will be used to port forward to the SSH server running on your container.
  2. Add these rules to your VNS3 firewall:
#Let the Container Subnet Access the Internet via the VNS3 Controller’s Outer or Public IP
MACRO_CUST -o eth0 -s <NIDS Container Network IP> - j MASQUERADE
#Port forward incoming traffic on port 44 to the NIDS Container port 22
PREROUTING_CUST -i eth0 -p tcp -s --dport 44 -j DNAT --to <NIDS Container Network IP>:22

You can now access your running Suricata container via the Internet, using this command:

ssh container_admin@<Public IP of VNS3> -p 44

To access via your local network substitute with the appropriate IP address.

Accessing the NIDS Container

Securing the NIDS container

By default the NIDS container has the following accounts configured.

“root” - The root account is locked. The root account is not allowed to remote shell into the container. This is our recommended approach. However, if you wish to, you can use the “container_admin” account to unlock root, provide a root password, and edit /etc/ssh/sshd_config to allow remote login by root.

“container_admin” - The default password is container_admin_123! PLEASE change this password The account “container_admin” has “sudo” or superuser privileges, and is allowed to remote shell into the container.

Files to configure the container

These are the files for configuring the container, Suricata is explained below:

/etc/supervisor/conf.d/supervisord.conf - This file defines what services are started when the container is started. Looking at the default you will see Suricata, SSH, rsyslog.

Note: The rsylog component can be configured to copy information logged by the NIDS to an external syslog server.

Configuring Suricata

The plugin is partially configured which will allow you to start using it immediately. However Suricata has a comprehensive feature set, familiarisation with the suricata.yaml file is highly recommended.

Detailed information can be found here:

Lines 15 - 47 determine the IP address ranges that will be considered internal or external traffic.

It is preconfigured to use the following:

# more specific is better for alert accuracy and performance

    HOME_NET: "[,,,]"



    HTTP_PORTS: "80"
    ORACLE_PORTS: 1521
    SSH_PORTS: 22
    DNP3_PORTS: 20000
    FILE_DATA_PORTS: "[$HTTP_PORTS,110,143]"
    FTP_PORTS: 21
    VXLAN_PORTS: 4789

Lines 73 - 529 should be reviewed as they determine what output and which format they will be in. The default can be used but may produce unecessary amounts of data for your usecase.

It is preconfigured to use the following:

/var/log/suricata/suricata.log - Logs general information about Suricata.

/var/log/suricata/stats.log - Logs IP packets that have been processed.

/var/log/suricata/fast.log - Logs all alerts actvity in text format.

/var/log/suricata/eve.json - Logs all alerts and stats activity in JSON format.

Lines 529 - 1806 are considered advanced settings for performance tuning. Advanced users may find these useful but the default can be used.

Lines 1809 - 1819 are related to the rulesets being employed. Suricata now has an embedded rule managment option which is preconfigured.

Rule Management

Suricata Rule Management

Suricata comes with it’s own rule management utility “suricata-update”, with this utility you can update and maintain your rulesets. By default Suricata uses the Emerging Threats Open Ruleset. Detailed information can be found here:

The Emerging Threats Open ruleset was installed at the time this plugin was created, by default Suricata saves them here /var/lib/suricata/rules.

You should update to the latest ruleset by running:

sudo suricata-update

Suricata will download, merge, clean and install the latest version of the ET Open ruleset.

Suricata-Update can also manage other rulesets, to list the available sources, run:

sudo suricata-update update-sources
sudo suricata-update list-sources

To enable an additional ruleset run

sudo suricata-update enable-source <name> 
sudo suricata-update

For example, to enable the OISF’s traffic id ruleset ‘oisf/trafficid’ you would run:

sudo suricata-update enable-source oisf/trafficid

Rule Selection

Suricata-Update merges all rules into a single file which can be found here /var/lib/suricata/rules.

Two seperate files are used to control which rules are active or inactive: enable.conf is used to enable inactive rules /etc/suricata/enable.conf disable.conf is used to disable active rules/etc/suricata/disable.conf

You can enable/disable rules based on sid, rule group and strng match.

2019401                   # enable/disable this sid
group:emerging-icmp.rules # enable/disable this rulefile
re:trojan                 # enable/disable all rules with this string


Suricata has four main output files:

/var/log/suricata/suricata.log - Logs general information about Suricata.

/var/log/suricata/stats.log - Logs IP packets that have been processed.

/var/log/suricata/fast.log - Logs all alerts actvity in text format.

/var/log/suricata/eve.json - Logs all alerts and stats activity in JSON format.

Testing Suricata

To test Suricata IDS you can use the ET Open ruleset signature 2100498 which has been written for this purpose.

"alert ip any any -> any any (msg:"GPL ATTACK_RESPONSE id check returned root"; content:"uid=0|28|root|29|"; classtype:bad-unknown; sid:2100498; rev:7; metadata:created_at 2010_09_23, updated_at 2010_09_23;)"

This will will be triggered if it has "uid=0|28|root|29|" within it’s payload.

There are two ways to see the output, fast.log and eve.json using jq. We will start with fast.log.

First tail fast.log in a separate terminal window.

sudo tail -f /var/log/suricata/fast.log

Then trigger the rule using curl.


If successful this output will be in the fast.log output. [1:2100498:7] GPL ATTACK_RESPONSE id check returned root [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} ->

To test using eve.json and jq run:

tail -f /var/log/suricata/eve.json | jq 'select(.event_type=="alert")'

Re-trigger the rule using curl.


The output will be a formatted JSON object.

Detailed steps can be found here:

Getting traffic to your web servers via the VNS3 NIDS Plugin

NIDS Container Flow

NIDS Container FLow

User or interior traffic arrives at the VNS3 Controller. Firewall rules can filter and send a subset of traffic to the Suricata plugin for analysis

Forwarding Web Traffic to the NIDS Container

Forwarding traffic to the container uses the same technique as was shown for accessing the container via Remote Shell.

VNS3 Firewall

Enter rules to send a copy of either incoming traffic (arriving on eth0 or tun0) or outgoing traffic (leaving eth0 or tun0).

#EXAMPLE: Copy all incoming tun0 (Overlay Network) traffic to the NIDS container.
MACRO_CUST -j COPY --from tun0 --to <Container Network IP> --inbound
#EXAMPLE: Copy all outgoing tun0 (Overlay Network) traffic to the TCP Tools Container
MACRO_CUST -j COPY --from tun0 --to <Container Network IP> —outbound
NOTE: At this time analyze inbound OR outbound at any given time in order to prevent accidental traffic loops. It IS POSSIBLE to create a traffic cycle which could “brick” your controller if you create simultaneous inbound AND outbound rules with improper parameters.

Forwarding WEB Traffic to the NIDS Container

For Developers / DevOps

The Docker image source is distributed as a Dockerfile along with accompanying config files.

To get the source:

git clone

Contact for more information regarding the DevOps approach to deploying plugins