-
Notifications
You must be signed in to change notification settings - Fork 0
Dashboard
The web console runs on port 8000 of the gateway. Every page requires a login, and sessions expire after ten minutes of inactivity.
The landing page has two tabs.
Overview shows the whole gateway: total packet rate, the count of blocked and rate limited addresses, engine status, and the most recent mitigation actions. The rate figure here is the most recent window from whichever protected host reported last, so under load it moves constantly.
Target Monitor narrows to one protected host. Pick it from the selector and the charts, boundaries, and classification all become specific to that host.
Beside the target table, the Overview tab lists the addresses that were blocked for attacking a protected host, with the target they went after, the rate that got them blocked, and when. This is the answer to "which of these addresses was actually hostile" for someone who does not already know the network.
Rate limited addresses are deliberately absent. Throttling is also applied as a precaution during a flash crowd, and when an attack is distributed enough that no single sender can be held responsible, it is applied to every address currently talking to the host. Its membership therefore includes bystanders, and listing them here would accuse them.
The panel shows only addresses still under enforcement, so entries disappear as blocks expire. Under a large attack it shows the busiest and says how many more there are.
Each chart draws three lines: the measured value, the boundary the sensor is currently using, and the learned baseline.
The gap between baseline and boundary is the sensor's tolerance, set by the k
multiplier. When the measured line crosses the boundary, that window is flagged.
Two things are being watched.
Rate is packets per second, smoothed. It crossing above its boundary means more traffic than this host normally receives.
Entropy measures how spread out the traffic is across source addresses. High entropy means many sources contributing evenly. Low entropy means a few sources dominating. It crossing below its boundary means traffic has become concentrated, which is what a flood from a bounded set of sources looks like.
Neither alone is conclusive, which is why the classifier looks at both together along with protocol mix and source concentration.
Each window is labelled:
| Label | Meaning |
|---|---|
| Normal | Traffic consistent with the learned baseline |
| Flash Crowd | A genuine surge, high volume but well distributed |
| DDoS | High volume and concentrated |
| Anomalous | Doesn't look like an attack, but doesn't look like anything the model has seen either |
The distinction between the middle two rows is the point of the project. A flash crowd has many sources sending moderately. An attack has few sources sending heavily. Volume alone cannot tell them apart.
Anomalous comes from a second model, an Isolation Forest, running alongside the classifier on every window. It answers a different question: not what class does this traffic look like, but does it look like anything the training data contained at all. A window the classifier reads as Normal or Flash Crowd, but that looks unlike anything either model was shown, is relabelled Anomalous for display and logging. It does not drive blocking or rate limiting on its own; it is a flag for a human to look at, not an enforcement decision.
If an egress interface is configured, the overview also shows what arrived against what was forwarded. The difference is what enforcement actually dropped.
Without an egress interface this reads as unavailable rather than zero, because nothing was measured.
Every source currently sending to a protected host, with its rate, destination, port, protocol, and enforcement status.
The filter narrows to Normal, Flash Crowd, or DDoS. A flow's classification is its destination's classification, since the classifier scores traffic per protected host rather than per individual flow. Flows toward a host with no metrics yet stay unclassified and appear only under All. An Anomalous destination shows its own badge here too, though it has no dedicated filter button; it appears under All.
Each row has actions to block, rate limit, or whitelist that source immediately.
A live graph of what is talking to what. Nodes are addresses, edges are flows, and edge weight follows rate. Node colour shows role and enforcement state.
Positions persist across refreshes, so the graph animates as traffic changes rather than rearranging itself every few seconds. Nodes can be dragged.
The same data as the network map in table form, sortable, showing source, destination, port, protocol, rate, and status. Easier than the graph when you want to read exact numbers or find one specific address.
An attack can involve more senders than any screen can usefully show, and both views redraw continuously. Each one therefore draws the busiest flows rather than all of them, and says so in its header when it has left anything out.
How many that is depends on the size of the panel, so a large display shows proportionally more than a laptop rather than both being held to the same budget. Flows are combined per source and destination before ranking, so an address spread across many ports is judged on its total rather than on whichever single flow happened to be largest.
If you need an address that is not shown, the Traffic table sorts, and the Event Log holds every address that was actually actioned.
Every network interface on the gateway with its address, MAC, link state, and whether it is in promiscuous mode.
The interfaces the sensor is actually capturing on are identified from the service unit, so this reflects what is configured rather than what is assumed.
Three things live here.
Blocked addresses, dropped outright, with time remaining on each entry. Entries expire on their own so a mistake heals without intervention.
Rate limited addresses, throttled to the configured cap rather than dropped.
The whitelist, never enforced against at any tier.
The enforcement tuning described in Configuration is editable here too.
Everything shown is read directly from the kernel ipsets, not from a cached copy, so it is what is actually in force.
The protected hosts. Adding one tells Stage 2 to track and report on that address.
This does not change what the sensor captures. The capture filter comes from the service unit, and a target added here that the sensor is not filtering for will simply never show traffic. The two need to stay in step.
Every enforcement action: what was done, to which source, on behalf of which protected host, at what rate, and how the window was classified.
The rate recorded is that individual source's own rate, not the window total.
Discord webhook and email configuration, with a test button for each.
The stored app password is never sent back to the browser. The field shows whether one is set, and typing a new value replaces it.
Since 1.3.0. Every completed confidence-gated labeling run with rows to review shows up here as a timestamped alert, with the count also badged on every other page's sidebar. A table below shows the actual staged rows.
Merge appends every staged row into the configured training CSV and
clears the queue; Discard clears it without merging anything. The staged rows
are shown 500 to a page (since 1.6.0), with Previous and Next buttons under
the table and a "Rows 1 to 500 of N" line. Paging changes only what is
displayed, and Merge and Discard still apply to every staged row. Both act
on the whole staged file at once, not a selection, since every pending
alert points at the same shared queue. See
Configuration for TRAINING_CSV_PATH,
required for Merge to be available at all.
Add accounts, change passwords, remove accounts.
The last remaining account cannot be deleted, since that would lock everyone
out with no recovery path short of running setup_admin.py on the machine.
Changing a password or deleting an account immediately invalidates that user's active sessions.
Generates a PDF report for a time window you choose (the last hour, six hours, a day, or a week): traffic volume by classification per window, packet rate and entropy against the current baseline, a plain summary of what happened during the window, the classification breakdown, the busiest sources and targets, and any addresses currently blocked.
The report is built entirely from what the server already has on hand, the stored event log and the live block list, so nothing is uploaded from the browser to generate it.
All timestamps in the report are UTC.
The dashboard polls every two seconds, and the sensor reports on a matching heartbeat, so a quiet host's figures are never more than a couple of seconds behind. A host under attack updates faster still, because every flagged window reports immediately.
If a page shows stale data or stops updating, see Troubleshooting.