HomeAI & Machine LearningNetwork Intrusion Detector — Anomaly Scoring Live

🚨 Network Intrusion Detector — Anomaly Scoring Live

Simulated network traffic streams past an anomaly-detection model that scores each connection for intrusion risk, flagging port scans and data-exfiltration patterns as they emerge.

AI & Machine Learning3DAdvanced60 FPS
ai-cybersecurity-intrusion-detection ↗ Open standalone

About the Network Intrusion Detector

Modern network intrusion detection systems fall into two broad families. Signature-based systems (Snort, Suricata, most commercial firewalls) match traffic against a catalogue of known-bad patterns and can only catch what has already been seen and written into a rule. Anomaly-based systems instead build a statistical model of what "normal" traffic looks like for a network — typical packet rates, connection durations, ports touched — and flag anything that deviates strongly from it, which lets them catch genuinely novel attack patterns at the cost of a higher false-positive rate. This simulation implements the anomaly-based approach directly: a live stream of synthetic connections, each described by four flow-level features (packets/sec, bytes/packet, connection duration, and distinct destination ports touched), is scored against a baseline distribution that is itself re-estimated on the fly from recent, currently-unflagged traffic.

Each connection's anomaly score is the Euclidean norm of its four z-scores against that live baseline — a simplified, diagonal-covariance form of Mahalanobis distance. A sensitivity slider sets the score cutoff above which a connection is flagged; once flagged, the simulation inspects which features are driving the anomaly to distinguish a port scan (many distinct ports, very short duration) from data exfiltration (large bytes-per-packet moving steadily through very few ports over a long session). Because every synthetic connection secretly carries a ground-truth label, the simulation can score precision, recall, and the full confusion matrix live as you move the threshold — making the alert-fatigue tradeoff at the heart of every real security operations centre directly visible and adjustable.

Frequently Asked Questions

What is anomaly-based intrusion detection and how does it differ from signature-based IDS?

Signature-based systems such as Snort or Suricata match traffic against a database of known attack patterns — a specific byte sequence, a known-bad IP, a particular packet shape — and can only catch attacks that have been seen and catalogued before. Anomaly-based detection instead builds a statistical profile of what "normal" traffic looks like for a given network — typical packet rates, connection durations, ports touched — and flags anything that deviates strongly from that profile, regardless of whether the exact attack has ever been seen. This lets anomaly detectors catch novel or zero-day attack patterns, at the cost of a higher false-positive rate, since unusual-but-legitimate behaviour (a backup job, a new service) can also trigger a flag. Real deployments typically layer both approaches.

What features does this simulation use to describe a connection, and why these four?

Each simulated connection is described by four features: packets per second (pps), bytes per packet (bpp), connection duration in seconds, and the number of distinct destination ports touched during the session. These four were chosen because they cleanly separate the two attack families modelled here without needing deep packet inspection: a port scan shows up as many distinct ports touched in a very short duration with small packets (bpp low, pps high), while data exfiltration shows up as a long-duration session moving unusually large bytes-per-packet through very few ports. Real network intrusion detection systems use dozens to hundreds of such flow-level features (inter-arrival time variance, TCP flag ratios, byte entropy), but four is enough to make the underlying statistics — and the resulting false-positive/false-negative tradeoff — fully visible.

How is the anomaly score actually computed?

Each of the four features is converted to a z-score: zᵢ = (xᵢ − meanᵢ) / stdᵢ, using a mean and standard deviation estimated live from a rolling window of the most recent connections that are not currently flagged as anomalous. The anomaly score is then the Euclidean norm of the z-score vector, score = √(z₁² + z₂² + z₃² + z₄²) — equivalent to a Mahalanobis distance under the simplifying assumption that the four features are uncorrelated (a diagonal covariance matrix), rather than the full covariance matrix a production system would estimate. A connection is flagged the moment its score exceeds the sensitivity threshold set by the slider.

How does the simulation tell a port scan apart from data exfiltration once a connection is flagged?

Once score exceeds the threshold, the simulation looks at which individual z-scores are driving the anomaly. If the distinct-ports z-score is strongly positive while the duration z-score is strongly negative, the signature matches many ports touched in very little time — classified as a port scan. If the bytes-per-packet and duration z-scores are both strongly positive while distinct ports stays low, the signature matches a large, sustained, narrow data transfer — classified as exfiltration. Anything flagged that does not clearly match either signature is labelled a generic anomaly. This mirrors how real SOC analysts triage an alert: the raw anomaly score says something is unusual, but the feature breakdown says what kind of unusual it is.

How does the sensitivity threshold slider affect false positives and false negatives?

Lowering the threshold flags more connections: recall rises (fewer real intrusions slip through as false negatives) but precision falls (more ordinary traffic gets wrongly flagged as false positives, an effect analysts call alert fatigue). Raising the threshold does the opposite — fewer alerts, higher precision, but a growing chance that real scans or exfiltration sessions go unflagged. There is no universally correct setting: a bank's SOC might tolerate a higher false-positive rate to catch more real threats, while a service with a small security team might raise the threshold simply because it cannot triage a flood of alerts.

Why does the model recompute its baseline statistics from a live rolling window instead of a fixed training set?

Real network traffic drifts constantly — a new application rolls out, a backup schedule changes, remote work shifts the time-of-day traffic profile — a phenomenon called concept drift. A detector trained once on last month's traffic and never updated will slowly drift out of calibration: either flagging more and more normal-but-new behaviour as false positives, or (worse) treating a slow, deliberate attack as the new normal because it crept in gradually. Recomputing mean and standard deviation from a rolling window of recently-unflagged connections lets the baseline track legitimate drift while still resisting attacks that arrive as a sudden burst, at the cost of being vulnerable to attackers who deliberately ramp up slowly enough to be absorbed into the baseline — a well-known limitation sometimes called boiling-frog poisoning.

What are the limitations of this diagonal-covariance approach compared to a production intrusion detection system?

Treating the four features as uncorrelated (summing independent z-scores) ignores real correlations — for example, high packet rate and low bytes-per-packet tend to co-occur naturally in normal short requests, so a full covariance matrix would draw a tilted, elliptical normal region instead of this simulation's axis-aligned one, and would flag fewer of those naturally-correlated points as anomalous. Production systems go further still: isolation forests, autoencoders, and other machine-learning models capture nonlinear and higher-order structure across dozens of features, and are typically combined with signature rules, threat-intelligence feeds, and human analyst review rather than relying on a single statistical score in isolation.

Why do false negatives and false positives cost so differently in a real SOC?

A false negative — a missed intrusion — can mean data actually leaves the network or a foothold goes undetected, with costs measured in breach remediation, regulatory exposure, and reputational damage. A false positive costs analyst time: someone has to open the alert, pull the logs, and conclude it was benign. Because analyst time is finite and every real SOC receives far more alerts than it can fully investigate, a detector tuned only for recall (catch everything) can be self-defeating if it buries genuine alerts under a flood of false ones — which is exactly why the precision/recall tradeoff exposed by this simulation's threshold slider is the central operational decision in real intrusion detection, not just a statistical curiosity.

⚙ Under the hood

Simulated connections stream past a live anomaly detector: mean and standard deviation for four flow features are re-estimated from a rolling window of recently-unflagged traffic, each new connection is scored by the Euclidean norm of its z-scores, and flagged connections are classified as port scan, exfiltration, or generic anomaly by which features are driving the score.

Canvas 2DAnomaly DetectionPort Scan DetectionData ExfiltrationPrecision/Recall

3D · Three.js / WebGL renderer · 60 FPS target · runs fully client-side, no install

What did you find?

Add reproduction steps (optional)