What is a network anomaly?
A network anomaly is a flow that is carrying significantly more traffic than it normally does. That's the simple version. The important word is "normally" — because Flintnet has to learn what normal looks like before it can spot what isn't.
Every unique combination of source IP, destination IP, source port, destination port, and protocol is tracked as a flow. Over time, Flintnet builds a statistical baseline for each flow — a picture of how much traffic it typically carries. When the current measurement deviates sharply above that baseline, the flow is flagged as anomalous.
How the baseline works — EWMA
Flintnet uses a technique called Exponentially Weighted Moving Average (EWMA) to maintain the baseline for each flow. Rather than a simple rolling average, EWMA gives more weight to recent measurements and progressively less weight to older ones. This means the baseline adapts naturally as traffic patterns evolve over time.
When a new batch of packets arrives for a flow, Flintnet compares the current byte count against the stored EWMA. If the current traffic deviates significantly above the baseline — beyond a configured threshold — the flow is flagged, an anomaly event is published to the event bus, and the alert store, SSE stream, and email alerter are all notified.
Legitimate vs suspicious anomalies
Not every anomaly is a threat. In practice, the majority of anomalies on a healthy network are completely benign spikes from expected activity. The detector's job is not to make a verdict — it's to surface the signal so a human can make one.
- Large file transfer or backup job running overnight
- Software update being pushed to multiple devices
- Video call starting on a normally quiet flow
- Database replication or sync after a period of inactivity
- Log aggregation pipeline catching up after a delay
- Internal device sending large volumes to an external IP it rarely contacts
- Compromised host scanning or flooding internal devices
- Malware phoning home in high-volume bursts
- Device participating in a DDoS attack
- Lateral movement spreading across the network
The key question when investigating an anomaly is: is this flow expected to carry this much traffic at this time? The source and destination IPs, the port number, and the protocol will usually tell you whether the answer is yes or no.
The baseline matures over time
When Flintnet first starts monitoring a network, its baselines are immature. There is very little historical data, so the EWMA has not yet settled to a stable value. This means the first few hours of operation may produce more false positives than usual — particularly for flows that naturally carry bursty traffic.
As the agent runs continuously, the baselines become increasingly accurate. After a few days of normal operation, the detector has a much clearer picture of what each flow typically looks like — and deviations become genuinely meaningful rather than just noise from an unstable baseline.
For this reason, we recommend running Flintnet for at least 48–72 hours before treating anomaly alerts as high confidence signals.
EWMA-based detection has no concept of what the traffic is — only how much. It cannot distinguish between a legitimate nightly backup and data exfiltration if both produce a similar traffic spike on the same flow. Anomaly alerts in Flintnet are always signals to investigate, not definitive verdicts. They should be treated as one input among several, not as a standalone security response trigger.
How Flintnet surfaces anomalies
When a flow is flagged, Flintnet publishes an anomaly event containing the full flow detail — source and destination IPs and ports, protocol, byte count, packet count, EWMA value, and flow duration. This event flows through the system in three ways simultaneously:
Real-time SSE push — the anomaly appears immediately on the Anomalies screen in the Flutter UI without a page refresh, via the persistent server-sent events connection.
REST API — the GET /anomalies endpoint returns all currently detected anomalies, including the full flow detail for each.
Email alert — if SMTP alerting is configured, an email is dispatched to the configured recipient with the flow detail. A 5-minute per-flow cooldown prevents repeated alerts for the same sustained anomaly from flooding your inbox.