Suricata IPS SBC Gateway

Inline IDS/IPS gateway for Raspberry Pi, Orange Pi, and other Debian-based single board computers, powered by Suricata in NFQUEUE mode.

---

Overview

This project deploys a small-form-factor network security gateway that inspects forwarded traffic with Suricata and enforces IPS decisions inline. It is designed for security lab environments where a single board computer sits between a WAN network and a protected LAN.

The repository includes:

• Ansible playbooks for gateway, Suricata, and rule deployment.
• Foundation shell scripts for step-by-step manual setup.
• A Kali-based IDS/IPS validation harness for attack generation, evidence collection, scoring, and reporting.
• Shared inventory and environment configuration for repeatable lab builds.

Architecture

Internet / WAN
     |
     v
+-----------------------------+
| SBC Gateway                 |
| - LAN/WAN routing           |
| - iptables NFQUEUE          |
| - Suricata IDS/IPS          |
| - Modular rule sets         |
+-----------------------------+
     |
     v
Protected LAN / IoT Devices

Suricata receives forwarded packets through NFQUEUE, evaluates enabled rules, and can alert or drop traffic depending on the configured rule action and mode.

Repository Layout

.
├── ansible_deployment/       Gateway, Suricata, and rules playbooks
├── basic_ids_ips_evaluation/  LAN-side rule validation harness for 20/30/40/50
├── foundation/               Manual setup scripts
├── ids_ips_evaluation/       WAN-side Kali validation harness and reports
├── images/                   Project icon assets
├── inventory.yaml            Lab inventory and deployment variables
├── main.sh                   Ansible orchestration entry point
├── motd.txt                  Optional login banner content
├── README.md                 Project overview and architecture
└── TECHNICAL_REPORT          Technical report
├── motd.txt                  Optional login banner content
└── LICENSE

Requirements

Gateway target:

• Debian-based Linux on Raspberry Pi, Orange Pi, or similar SBC.
• Two network interfaces for WAN and LAN forwarding.
• sudo privileges.
• Internet access during package and rule installation.

Controller machine:

• Ansible.
• SSH access to the gateway.
• A configured .env file containing required local secrets such as trusted_mac.

Validation machine:

• Kali Linux or a compatible attacker host.
• basic_ids_ips_evaluation/ is intended for local LAN-side rule testing of Suricata modules 20, 30, 40, and 50.
• ids_ips_evaluation/ is intended for broader WAN/external validation, evidence collection, scoring, and reporting.
• Python dependencies from ids_ips_evaluation/requirements.txt.
• Attack tools such as nmap, hping3, hydra, swaks, tcpdump, curl, dig, and netcat.

Deployment Assumptions

The default lab configuration assumes:

• The SBC has an Ethernet NIC named eth0 for the protected LAN.
• The SBC has a WLAN interface named wlan0 for the upstream WAN.
• wlan0 receives its upstream address through DHCP and remains reachable for SSH during deployment.
• eth0 is dedicated to the protected LAN and is configured as 10.10.10.1/24.
• LAN clients receive DHCP leases from the SBC in the 10.10.10.100 - 10.10.10.200 range.
• No other DHCP server is active on the protected LAN segment.
• The deployment is IPv4-focused; IPv6 routing and inspection are not part of the default setup.
• The target system uses Debian/Ubuntu-style networking, systemd services, Netplan, iptables, and netfilter-persistent.
• The controller has SSH key access to the SBC and the remote user can use sudo.
• A local .env file provides TARGET_IP, ANSIBLE_USER, ANSIBLE_SSH_KEY, WIFI_SSID, WIFI_PASSWORD, and trusted host values.
• Suricata runs inline through NFQUEUE queue 0; encrypted TLS payloads are not decrypted, so TLS rules rely on metadata such as SNI or certificate subjects.

Quick Start

1. Review and edit the lab variables:

vi inventory.yaml
vi .env

2. Run the full gateway deployment:

chmod +x main.sh
sudo ./main.sh

3. Validate the Suricata configuration on the gateway:

sudo suricata -T -c /etc/suricata/suricata.yaml
sudo systemctl status suricata

4. Run one of the validation harnesses from Kali:

# Local protected LAN rule tests for modules 20/30/40/50
cd basic_ids_ips_evaluation
sudo ./run_eval.sh

# Broader WAN-side validation, scoring, and reporting
cd ../ids_ips_evaluation
pip install -r requirements.txt
vi config/lab.conf
vi config/targets.conf
sudo ./validation_harness.sh

Deployment Paths

The main orchestration script runs these playbooks in order:

ansible_deployment/gateway_setup_playbook.yaml
ansible_deployment/suricata_setup_playbook.yaml
ansible_deployment/rules_setup_playbook.yaml

For manual or educational use, the equivalent shell scripts live in foundation/:

foundation/gateway_setup.sh
foundation/suricata_setup.sh
foundation/rules_setup.sh

Validation Harness

The project contains two validation harnesses:

• basic_ids_ips_evaluation/ runs local LAN-side tests from Kali within the protected network and validates Suricata rule modules 20, 30, 40, and 50.
• ids_ips_evaluation/ provides a more extensive WAN/attacker-side validation harness with modular attacks, evidence collection, scoring, and reports.

See basic_ids_ips_evaluation/README.md for the local rule evaluation workflow, and ids_ips_evaluation/README.md for the full external validation harness workflow.

License

This project is licensed under the BSD 3-Clause License. See LICENSE for details.

BSD 3-Clause License

Copyright (c) 2026, Mosudi Isiaka, IoT and Smart Systems, FH Technikum Wien
All rights reserved.

---

Author

Mosudi Isiaka O.

• Email: mosudi.isiaka@gmail.com
• FH Technikum Wien: io24m006@technikum-wien.at
• Website: https://mioemi.com
• GitHub: https://github.com/imosudi