A hybrid intrusion detection engine paired with a playbook-driven response orchestrator that detects network threats and acts on them automatically, backed by a real-time dashboard and an integrated LLM security assistant.
Master of Engineering in Cyber Security (LK473) · Final Project
Department of Electronics and Computer Engineering, University of Limerick
Author: Romy Savin Peter (24072753) · Supervisor: Dr. Reiner Dojen · Academic Year: 2024-2025
A full walkthrough and live demo is on YouTube (unlisted). Click the thumbnail to watch:
For the full technical detail, methodology, and results behind everything below, see the project report and presentation slides included in this repository, and the demo video above.
- What this project does
- Key features
- System architecture
- Network topology and VM configuration
- How it works
- The system in action
- Results
- Repository layout
- Getting the source code
- Running the system
- Configuration
- Limitations and future work
- Acknowledgements and references
Modern attacks are automated. Botnets and "as-a-service" platforms can scan a network, find a service, and start hammering it within minutes of a host coming online. A human analyst reading firewall logs, correlating events, and writing a new rule by hand cannot keep pace, and the damage happens in that gap between an attack starting and a defender catching up.
This project closes that gap by making the firewall act on its own. It is a proof-of-concept system that watches live network traffic, decides in real time whether something is malicious, and executes a response without waiting for a person. The response is not a simple block-or-allow switch. A scoring engine chooses, per event, between two strategies:
- Block the source outright when the threat is high-impact and there is nothing to learn from it (a SYN flood, an SMB exploit).
- Redirect the source to a honeypot when the activity looks like reconnaissance or a first offense, so the system can gather intelligence while the real servers stay untouched.
Detection uses two engines running side by side. A rule-based analyzer catches known, noisy attacks in well under a second. A Convolutional Neural Network (the pre-trained SecIDS-CNN model, reported at 97.72% accuracy) scores completed network flows for anomalies that no signature would catch. The whole thing is driven from a web dashboard that shows events, performance, and system health as they happen, with an LLM assistant you can query in plain English.
Everything was built with open-source tools (Python, Scapy, TensorFlow, Flask, nftables, SQLite) and validated in a four-machine virtual lab.
| Capability | What it means |
|---|---|
| Hybrid detection | Rule-based heuristics for known floods, scans, and web attacks, plus a CNN for flow-based anomaly detection. |
| Intelligent response | A per-event scoring algorithm picks between blocking and honeypot redirection instead of a fixed reaction. |
| Playbook-driven | Responses are defined in JSON playbooks, so you can change behaviour without touching Python. |
| nftables backend | Containment rules are applied atomically and in batches through the Linux kernel's nftables framework. |
| Deception network | Cowrie, OpenCanary, and custom decoys receive redirected attackers and log their behaviour. |
| Real-time dashboard | Flask + Socket.IO push live charts, event feeds, and resource meters to the browser. |
| LLM assistant | An OpenAI-backed assistant answers natural-language questions about the current system state. |
| IDS / IPS modes | Switch between monitor-only detection and active blocking from the dashboard. |
| Measured | Mean Time to Detect (MTTD) and Mean Time to Contain (MTTC) are tracked and plotted continuously. |
The system runs across four virtual machines, one each for the attacker, the firewall, the victim, and the honeypot. Keeping them separate forces every packet between the attacker and the internal network to pass through the firewall, where it can be inspected and acted on.
High-level system architecture across the four VMs.
- Attacker VM (Kali Linux) originates all malicious traffic through a custom Python attack suite (DoS floods, brute force, port scans, SQLi/XSS, SMB attacks, with optional IP spoofing).
- Firewall VM (Ubuntu 22.04) runs the core of the system. It captures packets on both interfaces, runs the hybrid detection engine and the playbook engine, manipulates the live
nftablesruleset, and serves the dashboard. - Victim VM (Ubuntu 22.04) stands in for a protected production server. It runs deliberately vulnerable services (SSH, FTP, Apache, MySQL, Samba, and more) plus monitoring scripts that measure attack impact.
- Honeypot VM (Ubuntu 22.04) provides the deception layer: Cowrie, OpenCanary, and custom low-interaction decoys that mimic the victim's services and log every interaction.
Three virtual networks segment the lab. Traffic from the "untrusted" attacker network can only reach the "protected" LAN by being routed through the firewall.
How a packet travels through the kernel's Netfilter hooks and the IDS/IPS analysis path.
Networks and addressing
| Network | Subnet | Hosts |
|---|---|---|
ATTACKNET (untrusted / "internet") |
192.168.32.0/24 |
Attacker 192.168.32.2, Firewall external enp0s8 192.168.32.1 |
LAN (protected internal) |
192.168.64.0/24 |
Victim 192.168.64.2, Honeypot 192.168.64.3, Firewall internal enp0s9 192.168.64.1 |
NAT Network (internet access) |
n/a | Firewall enp0s3, which masquerades traffic from both internal networks |
The firewall enables IP forwarding (net.ipv4.ip_forward=1) and uses nftables to forward traffic between the two segments and to masquerade (NAT) outbound traffic through enp0s3.
Virtual machine specifications
| Role | Hostname | OS | Resources | Key software |
|---|---|---|---|---|
| Attacker | kali |
Kali Linux | 2 vCPU, 4 GB RAM | Python 3, Scapy, custom attack suite |
| Firewall | firewall-vm |
Ubuntu 22.04 LTS | 4 vCPU, 8 GB RAM | Python 3, Scapy, nftables, TensorFlow, Flask |
| Victim | victim-vm |
Ubuntu 22.04 LTS | 2 vCPU, 4 GB RAM | Apache2, Nginx, MySQL, vsftpd, Samba, OpenSSH |
| Honeypot | honeypot-vm |
Ubuntu 22.04 LTS | 2 vCPU, 4 GB RAM | Cowrie, OpenCanary, custom decoys, dnsmasq |
The lab was built in Oracle VirtualBox. This README covers the software and how to run it; the report describes the VM build in more detail.
Packet capture and analysis are decoupled so that a burst of traffic never blocks inspection. A Scapy sniffing thread drops every captured packet into a thread-safe in-memory buffer, and a separate worker thread pulls from that buffer and analyzes it.
Component interaction and data flow inside the firewall application.
Two detection paths run in parallel:
Rule-based analysis (detection/analyzer.py) checks each packet against thresholds and signatures for an immediate, low-latency verdict. The thresholds that ship in core/config.py:
| Attack | Trigger |
|---|---|
| SYN flood | > 100 SYN packets to a destination in 5 s |
| UDP flood | > 200 UDP packets in 5 s |
| ICMP flood | > 100 ICMP packets in 5 s |
| Port scan | > 15 unique ports from one source in 3 s |
| Brute force | Per-service attempt counts over a 300 s window (SSH 30, FTP 25, MySQL 20, and so on) |
| Web attacks | Regex signatures for SQLi and XSS in HTTP payloads |
Machine-learning analysis (detection/ml_engine.py) tracks each network flow by its 5-tuple (source IP, destination IP, source port, destination port, protocol). Once a flow goes idle, ten statistical features (duration, packet count, byte total, mean and standard deviation of packet size, packet and byte rates, and so on) are extracted, normalized, and fed to the SecIDS-CNN model. A score above 0.85 flags the flow as anomalous, which is how the system catches subtle or novel behaviour that no signature describes.
Threat detection sequence: packets handled in parallel by the rule-based and ML engines.
The core modules and their relationships:
UML class diagram of the firewall system's core Python modules.
When either engine detects a threat it produces an AttackEvent, which is handed to the PlaybookEngine (playbook/engine.py). The engine loads the matching JSON playbook and works through its prioritized actions.
The interesting part is the choice between containment and deception. Rather than a fixed rule, the engine computes a score for each event from four factors, then redirects to the honeypot if the score is positive and blocks if it is not:
| Factor | Effect on the score |
|---|---|
| Attack type | Recon, SSH brute force, web probe raise it (good to observe); SYN flood, SMB exploit lower it (block on sight). |
| Severity | Low or medium raises it; high or critical lowers it. |
| Attacker history | A first offender raises it (worth watching); a repeat offender with many prior hits lowers it (escalate to block). |
| System load | CPU above 80% lowers it, favouring the cheaper block over redirection. |
The playbook execution state machine, from event ingestion to action execution.
Actions such as block_ip and honeypot_redirect generate nft commands, which are batched and applied atomically so the ruleset is never left in an inconsistent state. Blocking adds the source to a timed nftables set; redirection installs a DNAT rule that transparently forwards the attacker to the honeypot. Here is a trimmed playbook so the structure is clear:
{
"id": "pb_syn_flood",
"name": "SYN Flood DDoS Response",
"trigger": "syn_flood",
"mitre_technique": "T1499.001",
"actions": [
{ "type": "block_ip", "params": { "duration": 1800, "scope": "global" }, "priority": 1 },
{ "type": "syn_cookies","params": { "enable": true }, "priority": 2 },
{ "type": "rate_limit", "params": { "limit": "50/second", "per_ip": true }, "priority": 3 },
{ "type": "alert", "params": { "severity": "critical" }, "priority": 5 }
],
"severity": "critical"
}Ten playbooks ship with the firewall, covering SYN/UDP/ICMP floods, port scans, brute force, SMB attacks, web attacks, DNS tunneling, ML anomalous flows, and a default fallback.
Every event, metric, and diversion is written to a SQLite database through a connection pool and an asynchronous writer thread, so the detection threads never block on disk I/O.
Entity-relationship diagram of the SQLite logging schema.
The dashboard is deliberately decoupled from the monitor. The core monitor (fw_monitor_v2.py) never touches the web layer directly; it posts events and metrics to the dashboard's API through a small client module. The dashboard backend (dashboard.py) is a Flask app that exposes a REST API for control actions and hosts a Socket.IO server that pushes live data to the browser.
REST and WebSocket endpoints connecting the monitor, backend, and browser.
Screenshots below are grouped by machine. There are more in the Screenshots/ folder, and the demo video walks through all of it live.
The attack suite is a menu-driven Python tool. It separates spoofable attacks (floods and scans that use randomized source IPs) from non-spoofable ones (brute force and exploitation, which need a real connection), and it can verify that spoofing actually works in the virtual network.
The attack suite main menu on the Kali VM.
 A quick spoofed-only attack burst. |
 A combined attack mixing real and spoofed traffic. |
 Verifying that IP spoofing works. |
 The spoofing configuration menu. |
Statistics on the spoofed IP addresses used during a campaign.
The dashboard is a single-page app that updates over a WebSocket. The top of the page is a grid of key metrics; the rest is a set of widgets for events, attackers, performance trends, and system health.
Key performance indicators at the top of the dashboard.
 Attack distribution by type. |
 Top attacker IPs. |
Live, auto-updating feed of detected security events.
 Currently blocked IP addresses. |
 Honeypot diversion tracker showing redirected attackers. |
 Performance metrics over time. |
 MTTD and MTTC trend visualization. |
 Network interface TX/RX rates. |
 Firewall CPU and memory usage. |
The LLM assistant sits alongside the widgets. You can ask it about the current state of the system in plain English and it answers from live data.
The integrated LLM security assistant.
Operators can also test honeypot connectivity, export data, and clear logs or rules directly from the interface.
 Honeypot connectivity test result. |
 Export menu. |
 Clear data and rules menu. |
Exports come in several formats:
 Metrics and firewall log as JSON. |
 Firewall log as a text file. |
 Metrics as CSV. |
Redirected attackers land on a set of low-interaction honeypots that impersonate the victim's real services. A test script confirms every service is up, and an analysis script summarizes what the honeypots captured.
The firewall maps real service ports to honeypot ports like this:
| Real service | Real port | Honeypot port | Handler |
|---|---|---|---|
| SSH | 22 | 2222 | Cowrie |
| Telnet | 23 | 2223 | Cowrie |
| FTP | 21 | 2121 | OpenCanary |
| MySQL | 3306 | 3307 | OpenCanary |
| RDP | 3389 | 3390 | OpenCanary |
| HTTP | 80 | 8080 | OpenCanary |
| SMB | 445 | 4445 | Custom Python decoy |
| DNS | 53 | 5353 | dnsmasq / iptables redirect |
 Honeypot service test suite output. |
 Honeypot log analysis and report generation. |
The victim runs background monitors that record service uptime, resource use, and connection statistics during an attack. Stopping the monitor (Ctrl+C) triggers a report generator that turns the raw logs into a text security report and a set of graphs.
The victim's live monitoring dashboard.
 Report generation in progress. |
 Report generation complete. |
Log files produced by the monitoring scripts.
 The generated text-based security report. |
 The generated performance graphs. |
The system was put through two attack scenarios from the Kali VM:
- Scenario A (spoofed burst): a 60-second reconnaissance and DoS burst from 417 unique spoofed IP addresses across 77 attack vectors.
- Scenario B (sustained combined attack): a 150-second campaign mixing the attacker's real IP with 290 spoofed IPs (504 addresses in total), combining network floods with a targeted SSH brute-force.
Across both scenarios the system processed 5,379 detected attack events, executed 891 IP-block actions, performed 100+ honeypot redirections, and the honeypots logged 703 diverted connections.
Response times by attack type:
| Attack type | Detection method | Avg MTTD (s) | Avg MTTC (s) | Primary response |
|---|---|---|---|---|
| SYN flood | Rule-based | 1.8 | 0.9 | Block IP |
| UDP flood | Rule-based | 2.1 | 1.1 | Block IP |
| Port scan | Rule-based | 3.5 | 2.4 | Honeypot redirect |
| SSH brute force | Rule-based | 8.2 | 4.1 | Honeypot / Block |
| SQL injection | Rule-based | 0.5 | 0.3 | Block IP & port |
| Anomalous flow | ML (CNN) | 8.3 | 5.2 | Honeypot / Block |
Conceptual timeline from the first malicious packet to detection and containment.
The trade-off is visible in the table. Rule-based detection on individual packets is near-instant; the CNN is slower because it waits for a flow to complete, but it catches things a signature never would. Even at peak load during the combined attack, MTTD topped out at 10.6 s and MTTC at 8.9 s.
The cost to the protected server stayed low. On the victim VM during the attacks, CPU averaged 5.6% (peaking at 34.6%) and memory averaged 60.4%, which shows the firewall absorbed the brunt of the traffic instead of letting it exhaust the victim.
.
├── Source Code/
│ ├── firewall_machine/ # Core IDS/IPS, playbook engine, dashboard (firewall-vm)
│ │ ├── fw_monitor_v2.py # Main monitor: capture + detect + respond
│ │ ├── dashboard.py # Flask + Socket.IO backend
│ │ ├── ai/assistant.py # LLM security assistant
│ │ ├── core/ # config, models, metrics, utils
│ │ ├── detection/ # analyzer.py, detector.py, ml_engine.py
│ │ ├── playbook/engine.py # Response orchestrator
│ │ ├── playbooks/*.json # Per-attack response playbooks
│ │ ├── database/ # SQLite manager + queries
│ │ ├── models/SecIDS-CNN.h5 # Pre-trained CNN model
│ │ ├── monitoring/ # Dashboard client + metrics
│ │ ├── templates/dashboard.html
│ │ └── requirements.txt
│ ├── attacker_machine/ # Modular attack suite (kali)
│ │ ├── attack_engine_v2.py # Interactive CLI
│ │ ├── attack_launcher.sh # Scenario launcher menu
│ │ ├── scripts/ # dos, bruteforce, recon, web, smb, ip_spoofer ...
│ │ ├── configs/ # attack_config.json, wordlists.json
│ │ └── requirements.txt
│ ├── victim_machine/ # Vulnerable services + impact monitoring (victim-vm)
│ │ ├── start_monitoring.sh # Launch monitors; report on exit
│ │ ├── verify_services.sh # Service + security audit
│ │ ├── monitoring/scripts/ # connection_monitor, service_monitor, generate_report
│ │ └── data/ # Decoy credentials, SQL dump, documents (honeytokens)
│ └── honeypot_machine/ # Deception network (honeypot-vm)
│ └── scripts/ # web_honeypot, smb_honeypot, tarpit, log_aggregator,
│ # analyze_honeypot_logs, test_honeypots ...
├── Diagrams/ # Architecture and design diagrams
├── Screenshots/ # Attacker / Firewall / Honeypot / Victim screenshots
├── Firewall Logging & Incident Response - MEng Project Report.pdf
├── Firewall Logging & Incident Response - MEng Project Presentation.pdf
├── Report (Text Version).txt
└── Presenation (Text Version).txt
Clone the repository:
git clone https://github.com/rsvptr/firewall-logging-incident-response.git
cd "firewall-logging-incident-response"Each machine gets its own folder under Source Code/. Copy the relevant folder to the matching VM (for example, Source Code/firewall_machine/ goes to the firewall VM). Set up the four VMs and the three virtual networks as described in the network topology section and in the report.
Python 3.10 and a virtual environment per machine are assumed throughout.
Start the machines in this order: firewall first (it routes and defends), then the honeypot and victim (the things being protected), then the attacker. Adjust the IP addresses, interface names, and file paths below to match your own environment.
It needs root for packet capture and for editing nftables.
# On the firewall VM, from the firewall_machine folder
python3 -m venv venv && source venv/bin/activate
pip install -r requirements.txt
# Enable routing between the two internal networks
sudo sysctl -w net.ipv4.ip_forward=1
# Create nftables.conf from the annotated ruleset in the report (Listing 4.1);
# it is not shipped in the repo. It defines the zones, the blocklist sets, and
# the NAT/DNAT chains the response engine manipulates. Then load it:
sudo nft -f nftables.conf
# (Optional) enable the LLM assistant
export OPENAI_API_KEY="sk-..."
# Start the dashboard backend (binds 0.0.0.0:5000)
python dashboard.py
# In a second terminal, start the monitor (needs root for sniffing + nft)
sudo -E python fw_monitor_v2.pyOpen the dashboard at http://192.168.64.1:5000 from the victim or honeypot VM (or via an SSH tunnel from the attacker). Switch between IDS (monitor-only) and IPS (active blocking) from the dashboard.
The default deployment path in
core/config.pyis/home/firewall/firewall_project, with logs and the SQLite database under/var/log/firewall/. Either deploy there or override theDB_PATHandLOG_PATHenvironment variables.
Cowrie, OpenCanary, and dnsmasq run as their own services (typically under systemd), and the custom decoys run from scripts/. Once everything is up, verify it:
# On the honeypot VM, from the honeypot_machine folder
./scripts/test_honeypots.sh # Checks every honeypot service and port
# After a test run, summarize what the honeypots captured
python3 scripts/analyze_honeypot_logs.pyscripts/log_aggregator.py tails each honeypot's log and centralizes new entries into the aggregated log that the analysis script reads.
The honeypot scripts assume the code is deployed under
/home/honeypot/honeypot_system/. The aggregated log path (/home/honeypot/honeypot_system/logs/combined/all.json) is hardcoded inlog_aggregator.pyandanalyze_honeypot_logs.py, so adjust it if you deploy elsewhere.
# On the victim VM, from the victim_machine folder
python3 -m venv venv && source venv/bin/activate
pip install -r requirements.txt
# Confirm the vulnerable services and see a quick security audit
./verify_services.sh
# Start monitoring (needs sudo). Press Ctrl+C to stop and auto-generate
# the report and graphs under monitoring/reports and monitoring/graphs
sudo ./start_monitoring.shDeploy the attacker folder to
~/attacker_project. Theattack_launcher.shmenu hardcodescd ~/attacker_projectand activates avenvthere, so the environment has to live at that path. The directattack_engine_v2.pycommands use relative paths and run from the code folder.
# On the Kali VM, in ~/attacker_project
python3 -m venv venv && source venv/bin/activate
pip install -r requirements.txt
# Interactive scenario menu (spoofed storm, stealth, combined, utilities)
sudo ./attack_launcher.sh
# Or run a scenario directly
sudo python attack_engine_v2.py --scenario spoofed --duration 60
sudo python attack_engine_v2.py --scenario quick
python attack_engine_v2.py --scenario stealthSpoofable scenarios (floods, scans) use randomized source IPs; stealth and credential attacks use the attacker's real IP because they need a real connection. Watch the firewall dashboard while an attack runs to see detection and containment happen live.
Most behaviour is centralized in Source Code/firewall_machine/core/config.py and can be overridden with environment variables:
| Variable | Default | Purpose |
|---|---|---|
OPENAI_API_KEY |
none | Enables the LLM assistant (falls back to a local rule-based responder if unset). |
FLASK_HOST / FLASK_PORT |
0.0.0.0 / 5000 |
Dashboard bind address and port. |
DB_PATH / LOG_PATH |
/var/log/firewall/... |
Database and log locations. |
HONEYPOT_IP |
192.168.64.3 |
Redirection target for the deception network. |
ENABLE_ML |
true |
Turns the CNN anomaly engine on or off. |
BLOCK_INTERNAL |
false |
Whether to act on attacks that originate inside the LAN. |
Detection thresholds, the honeypot port map, the ML anomaly threshold (0.85), and the OpenAI model (gpt-5-mini) are all set in the same file. Response behaviour lives in the JSON files under playbooks/, so you can retune a response without editing Python.
This is a proof-of-concept, tested in a controlled four-VM lab rather than on a production network. Known limits and where they lead next:
- Lab-only validation. It has not faced enterprise-scale traffic or the noise of real application traffic. Next: benchmark on a high-throughput network.
- Static ML model. The SecIDS-CNN model is pre-trained with no online learning, so accuracy can drift as traffic evolves. Next: a retraining pipeline fed by confirmed-malicious honeypot data, closing the loop.
- Evasion. It was not tested against fragmentation, obfuscation, encrypted channels, or slow-and-low attacks that stay under the thresholds. Next: packet reassembly and more adaptive, stateful rules.
- External LLM dependency. The assistant's full capability needs the OpenAI API, which rules it out of air-gapped environments. Next: a locally hosted model.
- IPv4 only. IPv6 traffic is not analyzed. Next: extend the analysis, rule generation, and data models to IPv6.
For hardening steps toward real-world use (packaging as a service, SIEM integration, role-based access control, a higher-performance capture path), see the discussion chapter of the report.
This project was completed under the supervision of Dr. Reiner Dojen at the University of Limerick. It builds on a number of open-source frameworks: Scapy, TensorFlow/Keras, Flask, nftables, Cowrie, and OpenCanary.
The anomaly engine uses the SecIDS-CNN model by Keyvan Hardani:
K. Hardani, SecIDS-CNN (Revision 5daf4a4). Hugging Face, 2024. doi: 10.57967/hf/3351. Available: https://huggingface.co/Keyven/SecIDS-CNN
The full literature review, methodology, evaluation, and complete reference list are in the project report. For a condensed overview see the presentation slides, and for a live demonstration watch the video.
Built for the LK473 Master of Engineering in Cyber Security · University of Limerick · 2024-2025