0x00 Introduction

A small team with limited security investment, insufficient intrusion detection capabilities, and asymmetric offensive and defensive capabilities requires effective Security Data Analysis.

Here are some personal records and thoughts on tinkering with Suricata. They are not very mature and may even contain errors, but I am sharing them in case they resonate with someone.

0x01 Introduction to Suricata

Suricata is a security data analysis engine based on the TCP/IP protocol stack:

• 
  

  Capable of real-time intrusion detection (IDS), inline intrusion prevention (IPS), network security monitoring (NSM), and offline PCAP processing, fully supporting Snort rules;

  
  
• 
  

  Suricata uses a powerful and extensive rule and signature language to inspect network traffic and has robust Lua script support to detect complex threats;

  
  
• 
  

  Uses standard input and output formats (such as YAML and JSON), making it easy to integrate with existing tools like SIEM, Splunk, Logstash/Elasticsearch, Kibana, and other databases;

  
  
• 
  

  Active rule updates with strong community support.

  
  

Supports packet decoding:

• 
  

  IPv4, IPv6, TCP, UDP, SCTP, ICMPv4, ICMPv6, GRE

  
  
• 
  

  Ethernet, PPP, PPPoE, Raw, SLL, VLAN, QINQ, MPLS, ERSPAN

  
  
• 
  

  HTTP, SSL, TLS, SMB, DCERPC, SMTP, FTP, SSH, DNS, Modbus, ENIP/CIP, DNP3, NFS, NTP, DHCP, TFTP, KRB5, IKEv2

  
  

0x02 Reasons for Choosing Suricata

For network layer intrusion detection and traffic analysis, Snort, Suricata, and Bro are the mature open-source solutions in the industry. Many security companies prefer candidates familiar with Suricata, which is also very ‘excellent’.

• 
  

  Snort started in 1998 and is a good solution for moderate traffic scenarios;

  
  
• 
  

  Suricata started in 2009. I personally understand it as an extension of Snort for large-scale networks. In high-traffic environments, the packet loss rate is lower than Snort, and performance is better;

  
  
• 
  

  Bro is a passive open-source network traffic analyzer that can inspect all traffic on the link for signs of suspicious activity. It performs well in high-traffic environments. Bro supports various traffic analysis tasks beyond security domains, including performance measurement and troubleshooting. Its powerful scripting capabilities offer a significant advantage over rule sets in Snort or Suricata.

  
  

References:

https://blog.csdn.net/yrx0619/article/details/81267236

https://bricata.com/resources/white-paper/bro-vs-snot-or-suricata

Ultimately, I chose Suricata because it is easy to get started with, similar to Snort, and has more community resources. Bro has fewer resources and requires time to learn scripting, which is not proportional to the effort and reward.

0x03 DIY Suricata

In actual business environments:

• 
  

  Data centers are distributed, and the traffic mirrored for analysis is scattered;

  
  
• 
  

  Border traffic is large (the smallest data center has 7-8Gb per minute), and deploying Suricata directly is useless as it cannot handle such traffic;

  
  
• 
  

  How to store and display analysis results?

  
  
• 
  

  Who will look at the large number of alerts?

  
  

Therefore:

• 
  

  Distributed deployment of Suricata, adapting to multi-data center business scenarios, and reporting data statistics to ES;

  
  
• 
  

  If traffic cannot be handled, use dumpcap to split the mirrored traffic before analyzing it with Suricata;

  
  
• 
  

  Store Suricata’s analysis logs in Elasticsearch (ELK) for big data analysis;

  
  
• 
  

  DIY a security analysis backend to correlate existing HIDS data and log system data to identify more valuable and urgent attack events;

  
  
• 
  

  Block the identified attack events using hardware FW and system iptables.

  
  

0x04 Deployment

Suricata Deployment for Security Data Analysis

Deployment on CentOS 7, version: Suricata 4.0.5

•  

 yum install epel-release  yum install suricata  yum install wget libpcap-devel libnet-devel pcre-devel gcc-c++ automake autoconf libtool make libyaml-devel zlib-devel file-devel jansson-devel nss-devel

ELK Deployment

I deployed version 6.2. Download it online and follow the deployment instructions. The specific process is omitted.

•  

 elasticsearch-6.2.0.rpm  logstash-6.2.0.rpm  kibana-6.2.0-x86_64.rpm

Suricata Rules and Configuration:

• 
  

  Rule introduction reference:

  
  

  https://www.secpulse.com/archives/71603.html

  
  
• 
  

  Default rule explanation reference:

  
  

  https://www.jianshu.com/p/d81db4c352af

  
  

1. Direct update and replacement

•  

 wget https://rules.emergingthreats.net/open/suricata-4.0/emerging.rules.tar.gz

2. Suricata rule updates can be performed using suricata-update

•  

 yum install python-pip python-yaml  pip install --pre --upgrade suricata-update

 

Enter suricata-update to automatically update the rules, showing how many rules have been updated and enabled.

3. Suricata.yaml configuration file

Network configuration can be tailored to the actual network architecture for targeted detection:

Select the detection rules to load. Some default rules can be removed to reduce false positives. Here are the rules I enabled:

Reference:

https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Suricatayaml

Logstash Configuration

suricata_logstash.conf, to collect Suricata intrusion detection data into ES:

•  

 input {  file {      path =>  ["/var/log/suricata/eve.json*"]      codec =>   "json"      type =>  "SuricataIDS"  }    }    filter {  if [type] == "SuricataIDS" {      date {      match =>  [ "timestamp", "ISO8601" ]      }      ruby {      code =>  "          if event.get('[event_type]') == 'fileinfo'          event.set('[fileinfo][type]', event.get('[fileinfo][magic]').to_s.split(',')[0])          end      "      }        ruby{      code =>  "          if event.get('[event_type]') == 'alert'          sp = event.get('[alert][signature]').to_s.split(' group ')          if (sp.length == 2) and /Ad+z/.match(sp[1])              event.set('[alert][signature]', sp[0])          end          end 

0x05 Data Analysis

1) Suricata Data

Creating a Kibana dashboard for data analysis is the simplest method. You can download the necessary JSON files for the Kibana dashboard and add them to Kibana:

•  

https://aka.ms/networkwatchersuricatadashboard https://aka.ms/networkwatchersuricatavisualization https://aka.ms/networkwatchersuricatasavedsearch

After starting Suricata for network intrusion detection, an eve.json file is generated. Use the ELK stack to process this file and display alerts in Kibana. The specific interface is shown below:

2) Comprehensive Correlation Analysis

Comprehensive correlation analysis involves linking current data, such as HIDS, WAF (based on ELK), CMDB, etc.

For example:

Scenario 1: Suricata detects a large number of scanning and brute-force attempts. By correlating the source IP of this event with CMDB data, if a match is found, it is highly likely that an internal machine has been compromised and is initiating further scanning attacks. The urgency of the event is high, and immediate response is required!

Scenario 2: Suricata detects a large number of system-level attacks. By correlating with HIDS logs, if there is a significant match, the likelihood of a successful attack is high, requiring heightened security attention.

…

The correlation analysis mentioned here is relatively straightforward and crude. The main goal is to reduce the false positive rate of individual alerts. After correlation analysis, the accuracy will improve to some extent (no data to support this claim, just saying).

After analysis, the attacking IP can be pushed to the hardware firewall for blocking. For services not passing through the firewall, the IP can be blocked using iptables on the server.

0x06 Challenges (Pitfalls)

• 
  

  Suricata rules are primarily dependent on community contributions, with no manpower for rule maintenance.

  
  
• 
  

  High traffic at data center exits, multiple locations, and data centers. Mirrored traffic for Suricata detection engine performance can become a bottleneck (server costs are significant).

  
  
• 
  

  Mirrored traffic may experience packet loss. No good solution has been found yet.

  
  
• 
  

  A large number of alerts, with no one to review them (overwhelming).

  
  
• 
  

  This setup might end up being a half-finished product.

  
  
• 
  

  In conclusion, having something is better than nothing. At least we can tell the boss that we have security awareness, haha.

  
  

Original article published on WeChat public account (TaqiSec): Using Suricata to Build Network Layer Intrusion Detection

Disclaimer: The programs (methods) mentioned in the article may be offensive and are for security research and educational purposes only. Readers are responsible for any legal and associated liabilities if they use the information for other purposes. This site does not assume any legal or associated liabilities. If you have any questions, you can contact us via email (it is recommended to use a corporate or valid email to avoid being blocked, contact information is on the homepage). Please be aware.

Like https://cn-sec.com/archives/603977.html

Security Articles