Suricata IDS Baseline Tuning & Alert-Triage Dashboard for a College Lab Network (Python/MySQL)

LabNet Sentry is an advanced, measurement-driven study of an intrusion detection system in a college teaching lab — deployed, baselined, tuned and re-tested on lab-owned virtual machines, with written permission and an instructor present for the controlled test traffic.

A Suricata sensor on an Ubuntu gateway VM watches the isolated lab segment; week one captures a baseline of what a default ruleset shouts on ordinary lab traffic (student browsing, lab exercises, software updates). Because every byte of test traffic in the lab is generated by the student, every alert can be labelled honestly — the expected scan alerts during the controlled window are true positives, everything else is noise — turning "false positive" from an opinion into a measurable ratio.

A Python pipeline tails Suricata's eve.json and batch-inserts alerts into MySQL (with rule and host dimension tables); a Flask dashboard shows alert volume, top rules, top talkers and the false-positive ratio before and after tuning. The tuning workbench applies the three standard levers from NIST SP 800-94 — thresholds, suppressions and rule selection — each versioned and reversible, and never a rule deletion that silently drops detection coverage.

The final deliverable is a before/after table proving noise fell, coverage held (a controlled port scan between lab VMs still fires the same signatures), and every suppressed rule is justified in writing. Python, MySQL, web technology and data-structures work map onto the University of Madras CBCS courses; Suricata and Wireshark are standard, legal, lab-safe tooling for defensive monitoring.

College teaching labs generate exactly the traffic that makes a default IDS unusable: scanner exercises, packet-crafting assignments, DHCP churn and broadcast storms, all on flat subnets. Deploy a stock Suricata ruleset there and it produces thousands of alerts a day, almost none of which are real incidents — and an alert stream nobody reads is worse than no sensor, because it creates the appearance of monitoring without the substance. The literature and NIST SP 800-94 agree that IDPS tuning is essential, yet it is almost never taught: students learn rule syntax but not how to baseline a network, classify alerts against ground truth, or prove that a tuning change did not silently destroy detection coverage. The college needs a repeatable, measurable tuning procedure for its own lab network — one that captures a baseline, labels alerts against controlled test traffic, reduces the false-positive ratio with versioned, reversible changes, and verifies after every pass that the signatures that matter still fire.

Abstract

An intrusion detection system (IDS) is only as useful as its signal: an untuned sensor buries real events under thousands of false alarms — most IDS deployments fail from noise, not from missing signatures. This project runs the full deploy → baseline → tune → verify lifecycle on a Suricata sensor guarding a realistic fictional college teaching lab (Cauvery Institute of Technology), with every claim reported as a before/after measurement.

Introduction

CERT-In's advisories ask institutions to detect and monitor, but a college lab is hostile to a default IDS: packet-crafting exercises, DHCP churn, broadcast traffic and vulnerability-scanner labs all look exactly like attacks. The result is the classic failure NIST SP 800-94 warns about: analysts drown in alerts and stop reading them. Tuning is not an optional chore; it is the core operational skill of defensive monitoring.

Existing System

• The lab has no sensor at all: incidents are discovered by accident, if at all.
• Where an IDS is demonstrated in class, it runs on default settings for one lecture and is switched off — nothing baselined, nothing measured.
• Security teaching covers signature syntax but not operations: nobody shows students how to judge a true positive or reduce noise without losing coverage.
• Limitations: no baseline traffic profile, no alert archive, no metrics, no defensible tuning policy.

Proposed System

• An isolated lab deployment: Suricata on an Ubuntu gateway VM inspecting only the lab segment — no personal devices, no production network, and a signed permission note.
• A one-week baseline of stock-ruleset alerts on unmodified traffic: alerts per hour, unique signature IDs, top talkers.
• A ground-truth labelling scheme made possible by the closed lab: every alert is expected (it fires during controlled scan windows between two lab VMs) or unexpected, so the false-positive ratio FP / (TP + FP) is computed, not guessed.
• A Python ingestion pipeline that tails eve.json and batch-inserts events into MySQL with rule and host dimension tables.
• A Flask triage dashboard: alert volume, top rules, top talkers, FP ratio per iteration, CSV export.
• A tuning workbench applying thresholds, suppressions and rule selection — versioned, reversible changes, never deleting a rule the verification scan proves still needed.
• Controlled verification after each pass: a documented port scan and a benign replay rerun; detection coverage must hold while noise falls.

Feasibility Study

• Technical: Suricata, Wireshark, Python 3, MySQL and Flask are free and run on one lab PC with two VMs; the event pipeline is plain JSON parsing — a data-structures exercise, not a research problem. Everything maps to CBCS courses: Python (120C1A), RDBMS (320C5B), Web Technology (320C5C), Data Structures (220C3A).
• Economic: ₹0 licence cost; the lab hardware already exists.
• Operational & legal: the sensor watches only lab-owned VMs on an isolated segment, test traffic runs with the instructor's knowledge, and the report carries a signed permission note — defensible because its boundaries are written down.

In scope

• One isolated lab segment (two VMs plus the gateway sensor); no production or personal devices.
• Baseline capture, alert labelling, FP-ratio computation, three tuning iterations, verification scans.
• Python ingestion pipeline, MySQL alert store with dimensions, Flask triage dashboard, CSV export.
• Controlled test traffic: a documented port scan between two lab VMs and a benign traffic replay, run with the instructor present.
• Versioned Suricata configuration and rules with an undo path; a written runbook.

Out of scope (v1)

• Inline prevention (IPS mode with drops) — the sensor stays detect-only; dropping packets in a teaching lab breaks the lab itself.
• TLS-inspection or deep payload analysis; encrypted traffic is treated as metadata (flows, TLS handshake fields).
• Multi-sensor or multi-campus deployment, and any link to the college's real network operations.
• Machine-learning alert classification (listed as future scope); the labelling here is rule-based and calendar-driven by design.
• Real-time paging or mobile alerts — the dashboard is intentionally post-hoc triage.

The study follows a six-week iterative, measurement-driven loop structured around the IDPS lifecycle in NIST SP 800-94 (deploy → baseline → tune → verify), with each iteration closing on numbers rather than impressions.

Measurement discipline: every claim in the report cites a query against the alert store (for example, "alerts/hour fell from 1,842 to 210 while the scan signatures in the verification table still fired"), and the numbers the student reports are their own run's values — the runbook shows exactly how to reproduce them. Testing approach: golden-file tests for the JSON parser (valid, malformed and truncated lines), a fixed replay capture whose expected alert counts are asserted, integration tests for batch inserts, and a manual black-box pass over every dashboard view.

LabNet Sentry has four parts: the sensor, the pipeline, the store and the dashboard — plus the tuning workbench that acts on the sensor.

1. Sensor — Suricata on an Ubuntu 22.04 gateway VM, running in IDS mode on the lab-facing interface, with eve.json as its single output and HOME_NET scoped to the lab subnet.
2. Pipeline — a Python 3 ingestor tails eve.json (handling rotation and truncated lines), filters for alert events, enriches each with the rule message and host labels, and flushes batch inserts to MySQL every five seconds inside one transaction.
3. Store — MySQL 8 with a fact table of alerts and two dimension tables (rules, hosts), a traffic-calendar table for labelling, and a tuning-change table recording every configuration edit.
4. Dashboard — Flask serving HTML/CSS/JavaScript with charts (volume over time, top rules, FP-ratio trend) and CSV export; the tuning workbench writes versioned config snapshots with an undo command.
5. Controlled traffic generator — a documented script that runs the port scan and benign replay between lab VMs and stamps the calendar, making labelling mechanical.

flowchart LR
  LM["Lab VMs (isolated segment)"] -->|"mirrored traffic"| SEN["Suricata sensor on Ubuntu gateway VM"]
  SEN -->|"eve.json"| ING["Python ingestor: tail, parse, batch"]
  CTG["Controlled traffic generator: scan + benign replay"] --> LM
  CTG -->|"stamps window"| CAL[("traffic calendar")]
  ING --> DB[("MySQL 8: alerts, rules, hosts, changes")]
  LAB["Labelling job: expected vs unexpected"] --> DB
  TW["Tuning workbench: thresholds, suppressions (versioned)"] -->|"config snapshots"| SEN
  DB --> DASH["Flask dashboard + CSV export"]

ER diagram

erDiagram
  RULE_DIM ||--o{ ALERT : "classifies"
  HOST_DIM ||--o{ ALERT : "is source or dest of"
  ALERT }o--|| TEST_WINDOW : "falls in"
  TUNING_CHANGE ||--o{ ALERT : "precedes"

  ALERT {
    int id PK
    datetime timestamp
    string sid FK
    string srcIp FK
    string destIp FK
    string category
    bool expected
  }
  RULE_DIM {
    string sid PK
    string message
    string category
    bool active
  }
  HOST_DIM {
    string ip PK
    string role
    bool labOwned
  }
  TEST_WINDOW {
    int id PK
    datetime startAt
    datetime endAt
    string trafficType
  }
  TUNING_CHANGE {
    int id PK
    datetime appliedAt
    string changeType
    string targetSid
    string justification
  }

Study design

flowchart TD
  A["Deploy sensor, scope HOME_NET"] --> B["Baseline: 5 days stock ruleset"]
  B --> C["Label alerts via traffic calendar"]
  C --> D["Tune I: scope + thresholds"]
  D --> E["Verify: controlled scan still fires"]
  E --> F["Tune II: justified suppressions"]
  F --> G["Verify again + measure FP ratio"]
  G --> H["Dashboard, results, runbook"]

The FP ratio after each iteration is a single SQL join: alerts inside a test window count as expected; everything outside it counts as unexpected, and the ratio unexpected / total becomes the noise metric the report tracks from baseline to final.

• Anomaly-assisted labelling: a lightweight statistical model that flags alerts whose features deviate from the labelled history, reducing manual labelling as the corpus grows.
• Grafana front-end over the same MySQL store for labs that want an operations-grade view alongside the teaching dashboard.
• Multi-sensor federation: a second sensor on the hostel-lab segment with cross-sensor correlation in the store.
• TLS metadata triage: SNI/JA3-style fingerprint fields from Suricata's TLS records added to the host dimensions for encrypted-traffic awareness without decryption.
• Semester-over-semester comparison: archived baselines that let the lab show whether its traffic profile and tuning hold across student batches.
• Campus SOC bridge: a documented, permissioned export of the tuned ruleset and FP-ratio history to the college's real IT team, closing the loop between teaching and operations.