Signature-based detection checks every packet's byte pattern against a database of known-bad signatures and flags a close-enough match. It catches known attacks with near-zero false positives — but a novel attack that has never been catalogued sails straight through, because nothing matches.
Anomaly-based detection instead learns a rolling baseline of "normal" traffic (mean packet size ± spread) and flags anything that deviates past a z-score threshold. It can catch a brand-new attack purely because it looks statistically odd — but ordinary bursty-but-legitimate traffic can look odd too, so it runs a higher false-positive rate.
signature: flag if matchScore(pkt, db) > threshold
anomaly: flag if |size(pkt) − baselineMean| / baselineStd > threshold
- Threshold / sensitivity — lower it and the sensor flags more aggressively: true-positive rate climbs, but so does the false-positive rate as benign traffic gets swept in.
- Attack traffic mix — this stream carries two attacker types: known attacks (orange) match a cataloged signature but keep a normal-looking packet size; novel attacks (purple) have no matching signature but an unusually large/odd payload. That split is exactly why real deployments run both engines together.
- IPS blocking — off, a flagged packet is only logged (IDS: passive, out-of-band tap). On, a flagged packet is dropped at the sensor before it reaches the far side (IPS: inline, active enforcement) — but every false positive is now a legitimate packet you just dropped.
Real-world relevance: this is the core tradeoff every SOC tunes daily — tighten the dial and you catch more real intrusions at the cost of drowning analysts (or users, in IPS mode) in false alarms.