Radware Behavioral DoS (BDoS) — Behavioral, Zero-Day & Auto-Generated Signatures

① Why static thresholds fail — the false-positive vs false-negative trap

The single most important idea: a fixed rate limit forces you to pick one number, and that number is always wrong somewhere. Set it too low and a legitimate flash crowd trips it (false positives, blocked customers). Set it too high and a slow or novel flood slides underneath (false negatives, missed attack).

Static signature IPS rules have the same problem from the other side: they can only catch attacks someone already wrote a rule for. A zero-day flood — a new botnet pattern at 3 a.m. — matches no existing ACL or signature. Radware BDoS removes the guesswork: instead of a fixed number, it learns what your normal traffic looks like and treats a flood as a statistical deviation from that learned baseline.

② Learning the baseline — adaptive rates and the Degree of Attack

BDoS runs inside DefensePro and continuously learns normal inbound and outbound rates, building per-protocol baselines for TCP, UDP, ICMP and IGMP. The admin seeds it with bandwidth thresholds (Inbound/Outbound in Kbit/sec) plus protocol quotas (TCP/UDP/ICMP/IGMP, In and Out, as %). A quirk worth remembering: quotas may sum past 100% because each one is a per-protocol maximum, not a slice of a shared pie.

Tuning the learn and the score

A configurable learning response period (day / week — recommended / month) primarily weights how fast baselines adapt to traffic fluctuation, and a Suppression Threshold stops abnormally low traffic from degrading baseline accuracy in out-of-path deployments. BDoS then compares 'normal vs abnormal' using fuzzy logic, producing a continuous Degree of Attack (DoA) rather than a hard on/off line, which avoids abrupt false triggers.

③ Auto-generating the signature — from anomaly to footprint to block

When the Degree of Attack rises, BDoS moves from Normal to Analysis state and inspects the offending packets to find their common denominators — the footprint. Footprint fields include source/destination IP and port, TTL, packet size, checksum, sequence number, fragmentation, packet ID and DNS Query; checksum and sequence-number fields are always treated as High strictness. The footprint is assembled as a Boolean expression (e.g. same TTL AND same packet size AND same destination port).

Strictness and the 18-second cycle

That footprint becomes a real-time signature, constrained by Footprint Strictness: Low accepts any suggested footprint (best blocking, more false positives); Medium requires at least 2 Boolean ANDs and no more than 2 extra ORs; High requires at least 3 ANDs and no ORs (fewest false positives, more false negatives). Crucially, BDoS does not block until the final footprint is found — a deliberate few-second analysis window. Radware cites roughly 18 seconds to detect, characterize and block a zero-day flood. If no footprint meets the strictness, DefensePro alerts but does not block — the Non-strictness state.

④ Closed feedback in action — self-optimize, track mutation, auto-expire

Once DefensePro enters Blocking state, it does not freeze the signature and walk away. A closed-feedback loop continuously re-measures the live traffic and iteratively refines the signature — tightening the match to minimize collateral on legitimate users, and adapting as the attack mutates (new source ports, changed packet size). The signature surgically drops only attack-shaped packets while real traffic flows.

Clean exit, no manual cleanup

When traffic returns to baseline, the signature is automatically removed under a configurable attack-termination condition (0–45 seconds, default 10s) and the protocol returns to Normal state — no admin has to delete a rule afterwards. That is the whole advantage over static thresholds: behavioral baselines plus auto-signatures catch zero-day floods with no pre-written rule, block only attack-shaped packets, and clean up after themselves.