Blog
February 28, 2026 By Sergey

Proper Suricata Configuration for Suri Oculus

A Practical Guide to Setup, Rules, and Testing

When deploying Suri Oculus, it is not enough to simply start Suricata. It must be configured correctly to ensure:

  • Proper traffic capture
  • Full signature loading
  • Support for custom rules
  • IOC integration
  • Clean data for behavioral analysis

Below is a structured configuration approach based on real-world testing.

1. Traffic Capture: Dual Interfaces (WAN + LAN)

If Suricata runs in a virtual machine with two interfaces:

  • enp1s0 — WAN
  • enp2s0 — isolated LAN

You should capture traffic from both interfaces.

Why this matters:

  • WAN reveals external threats
  • LAN reveals internal movement and host behavior
  • Host Behavior Fingerprint (HBF) requires complete visibility

Recommended af-packet configuration:

af-packet:
– interface: enp1s0
cluster-id: 99
cluster-type: cluster_flow
defrag: yes
tpacket-v3: yes
snaplen: 65535– interface: enp2s0
cluster-id: 98
cluster-type: cluster_flow
defrag: yes
tpacket-v3: yes
snaplen: 65535
 

Important

  • tpacket-v3: yes reduces CPU overhead and packet loss
  • snaplen: 65535 prevents truncated packets
  • Each interface must have a unique cluster-id

2. The “Truncated Packet” Issue

If you see:

  • SURICATA AF-PACKET truncated packet
  • SURICATA IPv4 truncated packet

The most common cause is an insufficient snaplen.

Solution:

snaplen: 65535
 

This ensures:

  • Complete HTTP parsing
  • Correct TLS inspection
  • Reliable AI feature extraction

3. Verifying Rule Loading

After startup, the log should show something like:

48709 rules successfully loaded

48714 signatures processed

If suricata -T does not display this in the console, check:
 
/var/log/suricata/suricata.log
 

4. Critical Section: rule-files

Your Suricata configuration must contain a properly structured rule-files section:

default-rule-path: /var/lib/suricata/rules

rule-files:
– suricata.rules
– additional.rules
# – ioc_url.rules
# – ioc_ip.rules
# – ioc_domain.rules
 

This is essential.

Explanation:

suricata.rules

The main aggregated ruleset (e.g., ET Open).

additional.rules

Custom rules managed by Suri Oculus.

ioc_*.rules

Automatically generated by Suri Oculus based on IOC intelligence feeds.

5. The additional.rules File

This file contains custom DNS filtering rules using Suricata datasets.

Example:

 
drop dns $HOME_NET any -> any any (msg:”Oculus Social DNS Query”;
dns.query;
dataset:isset, social.blst, type string, load /var/lib/suricata/social.blst, memcap 10mb, hashsize 1024;
classtype:trojan-activity;
sid:2000003; rev:1;)
 

Purpose

  • Block social media domains
  • Block adult content
  • Block gambling domains
  • Block fake news sources
  • Apply custom DNS blacklists

Why use datasets?

  • High performance
  • Efficient memory handling
  • Dynamic updates without rule recompilation

Dataset files (*.blst) are updated via Oculus tools.

6. IOC Integration

The following files:

  • ioc_url.rules
  • ioc_ip.rules
  • ioc_domain.rules

Are generated automatically by Suri Oculus from its IOC database.

This ensures:

  • Threat intelligence integration
  • Automatic signature updates
  • Centralized policy control

If these lines are commented out, IOC rules will not be loaded.

7. HOME_NET — A Critical Parameter

If scan detection or FTP alerts seem weak, the most common cause is an incorrect HOME_NET.

Example:

 
vars:
address-groups:
HOME_NET: “[10.10.10.0/24]”
EXTERNAL_NET: “!$HOME_NET”
 

For lab testing only:

 
HOME_NET: “any”
 

8. Verifying Detection in Real Time

Check runtime counters:

 
suricatasc -c dump-counters
 

Monitor events:

 
tail -f /var/log/suricata/eve.json
 

9. Organizing Test Attacks

Recommended structured testing sequence:

  1. Ping
  2. nmap -sS
  3. nmap -p-
  4. siege or ab
  5. hydra (FTP test)
  6. Short hping3 burst
  7. nikto

This validates:

  • ET SCAN signatures
  • FTP detection
  • HTTP parsing
  • Flow logging
  • Threshold rules
  • HOME_NET correctness

10. Verify Traffic Visibility

Suricata must actually see the traffic.

Check with:

 
tcpdump -ni enp2s0
 

If tcpdump does not see traffic, Suricata will not see it either.

11. Why This Matters for Suri Oculus

Suri Oculus is more than a simple IDS interface. It provides:

  • Traffic visualization
  • Rule management
  • IOC integration
  • Behavioral analytics
  • Host Behavior Fingerprint
  • Baseline comparison

If Suricata is misconfigured:

  • AI receives distorted data
  • Flow statistics become unreliable
  • WAN → LAN correlation breaks

Conclusion

Proper Suricata configuration for Suri Oculus requires:

  • AF_PACKET with tpacket-v3
  • snaplen 65535
  • Correct HOME_NET
  • suricata.rules enabled
  • additional.rules enabled
  • Optional IOC rules
  • Active eve-log output
  • Confirmed traffic visibility

Only with this foundation does Suricata become a reliable IDS/IPS engine — and Suri Oculus a powerful analytical and management platform.

Before production deployment, thoroughly test your configuration.
The integrity of your entire detection system depends on it.