> For the complete documentation index, see [llms.txt](https://docs.layeronecloud.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.layeronecloud.com/network-monitor/operations/ddos-monitoring.md). # DDoS monitoring Enable DDoS detection only on WAN capture domains. Enable DDoS detection only on WAN capture domains. The configuration page shows three target sets for each WAN: * **Automatic targets** are public addresses in the shared WAN binding, including addresses owned by its bridge. A WAN identified only by its default route behind a NAT gateway has none: its private probe source is never a target, and the detector reports `no_targets` until a routed public range is added manually. They are protected as exact `/32` or `/128` hosts and cannot be edited. * **Additional protected CIDRs** are operator-managed public ranges routed or bridged through the capture point but not assigned directly to it. * **Effective targets** are the deduplicated union actually sent to the sensor. The resolved public IPv4 source remains included within the automatic bound. An enabled detector needs at least one effective target. After deployment it first reports `learning`; adaptive thresholds become available only after enough clean, high-coverage samples. Absolute thresholds operate throughout the learning period. `degraded` means packet-capture coverage is too low for adaptive decisions, while `no_targets` means the capture cannot classify an inbound destination until inventory or manual CIDRs supply one. Legacy sensors remain visible as `legacy` during a server-first rollout. An incident requires three confirmations. Each must include sufficient new traffic in the latest completed two-second packet bucket or a new qualifying authoritative interface sample; the same interface sample counts only once. The overlapping ten-second detection windows cannot reuse one brief burst as three confirmations. Adaptive thresholds are at least 50% of the corresponding absolute threshold, and adaptive detection must meet its minimum source count even for a large learned-threshold multiple. The static path still permits its source-count exception at 2× the absolute threshold and uses authoritative interface rates when packet coverage is poor. While an incident waits to resolve after its signal subsides, newly observed sources are no longer attributed to it. Common public DNS resolver addresses are automatically excluded from DDoS detection using exact IPv4 and IPv6 host matches. The built-in list covers [Google Public DNS](https://developers.google.com/speed/public-dns/docs/using), [Cloudflare](https://developers.cloudflare.com/1.1.1.1/infrastructure/network-operators/) including its family-filtering services, [Quad9](https://docs.quad9.net/services/) secured and unsecured services with and without ECS, [OpenDNS and FamilyShield](https://umbrella.cisco.com/blog/enhancing-support-dns-encryption-with-dns-over-https), and [AdGuard DNS](https://adguard-dns.io/en/public-dns.html) default, family-protection, and non-filtering services. An inbound packet is exempt when either its source or destination matches a listed address, on any port or protocol. Exempt traffic remains in general traffic totals and the DDoS **Other observed** series. It does not contribute to detection windows, adaptive learning, suspected sources, incident destinations, or packet evidence. Captured exempt bytes and packets are also subtracted from the interface-counter volumetric safeguard; unidentified RX traffic still contributes, so the safeguard remains active when capture loss prevents the sensor from identifying resolver traffic. Upgrade sensors to apply these exclusions. Existing historical incidents are retained. Adaptive baselines relearn after the upgrade because older samples included resolver traffic; absolute thresholds remain active during learning. The rollout order is mandatory: migrate and restart the control plane before deploying agent 0.1.8 or newer. A v2 agent can report capture- or protocol-wide incidents without a target IP; an older server rejects that envelope and its sequence cannot advance. The new server continues to accept legacy agents, so verify its migrations and health first, then upgrade sensors. Agent 0.1.15 removes the incident-wide destination IP limit, including for capture-wide and protocol-wide detections across entire subnets. Deploy the control plane through `0035_ddos_destination_rows` first, then upgrade sensors. The sensor uses disk-backed exact destination tracking and incremental uploads; the server deduplicates individual IPv4/IPv6 rows without a per-incident count ceiling. Uploads contain at most 1,024 destinations per update and the console loads at most 100 per page. The 64-address summary is only a preview, not a retention limit, and pagination never implies lost evidence. Incident resolution does not discard queued destination uploads. Pending destination pages are exempt from the spool's age/byte eviction until server acknowledgement; ordinary telemetry can still expire without skipping those pages. The configured spool size is therefore a soft limit while destination evidence is pending. Allow disk headroom and monitor storage health during long outages. Actual disk exhaustion or capture loss can still prevent complete observation; reported destination loss stays explicitly marked partial. Normal server-side DDoS retention also applies to the stored destination rows. Destination addresses are incident context, not verified source-to-destination pairs. NIC/scope remains separate and correlation identity is unchanged. Existing exact-target incidents and retained 0.1.14 destination lists are migrated; an older truncated list cannot recover addresses that were never recorded. Broad incidents without destination telemetry remain unavailable. Configured protected CIDRs and WAN addresses are never substituted as observed victims. The DDoS page offers Live, 6-hour, 24-hour, and 7-day ranges. Its bandwidth and packet-rate charts share a time axis and incident bands. Live points show the time-weighted average over the preceding 10 seconds, refreshed on 10-second boundaries, rather than the highest short-interval rate. Missing intervals stay gaps instead of being averaged as zero. Mirrored sensors still count only once per correlated incident. Historical views retain their 1-minute (6/24-hour) or 5-minute (7-day) averages because retained minute counters cannot reconstruct 10-second history. Incident peak statistics and detection thresholds are unchanged. **Suspected DDoS** is traffic assigned to confirmed detector incidents; **Other observed** is the rest of the inbound packets the sensor observed. It is intentionally not called normal or clean traffic. The thin total-inbound line comes from kernel interface counters. Treat low coverage and chart gaps as missing evidence, not zero traffic, and treat source addresses as suspects because spoofing and NAT can make source attribution uncertain. The DDoS page groups overlapping detection windows into events, including different destinations and attack types at the same site. Unresolved windows include the detector's existing 90-second freshness allowance; separate windows have no additional grouping gap. Events start collapsed. Expand an event to inspect its destinations, individually paginated sources, confidence reasons, and packet evidence. These display groups do not change sensor correlation or incident delivery to other services. Event confidence is an evidence assessment, not a probability of malicious traffic. It uses the strongest supported sensor detection in the event: **high** requires both static and adaptive triggers at opening, a recorded threshold multiple of at least 2×, latest coverage of at least 90%, at least 20 observed sources, at least 1,000 packets/s at opening, and complete tracking evidence. Generic UDP floods and volumetric detections cannot exceed **medium** because traffic rate or volume alone does not establish malicious traffic. Other complete evidence is **medium**, or **low** below 80% coverage, two observed sources, or 100 packets/s at opening. Missing or legacy evidence is **unknown** if no complete detection remains; partial event evidence caps a supported rating at medium. Opening triggers and packet rates, maximum exceedance/source count, and latest coverage can describe different moments and are labeled accordingly. The assessment method is `event_evidence_v2`. The source tables separately show **Source activity**, not attack confidence. **Medium activity** requires at least 100 packets spanning six seconds, an average of at least 10 packets/s, at least 1% of tracked source bytes, and at least 80% capture coverage. **High activity** requires at least 1,000 packets spanning ten seconds, an average of at least 100 packets/s, at least 5% of tracked source bytes, at least 90% coverage, and no source or detector tracking truncation. The average divides packet count by the observed span, with a minimum denominator of ten seconds. Sources below these minimums remain visible as **Observed**; their raw packet and byte counts are retained. Activity describes the evidence of a source's traffic contribution, not a probability that the address is malicious or an instruction to block it. Deploy the control plane to apply the revised event assessment, source activity labels, and evidence caps to historical source rows. Each sensor's stored source rating is capped before sources are grouped, so seven historical packets cannot retain a high activity rating or borrow another sensor's duration or coverage. The cap never promotes an old rating; original update-level traffic share cannot be reconstructed from cumulative counters. Upgrade installed sensors to apply the fresh-confirmation, adaptive, quiet-interval attribution, and source activity rules to new observations. A control-plane deployment alone does not upgrade sensors. Historical incidents and raw source counts remain available. Detection opens one correlated alert per matching site-level flood. It does not call or text the offline-agent on-call list, and it does not install firewall rules. Review the target, trigger mode, threshold multiple, baseline context, coverage, contributing sensors, and suspected sources before taking manual mitigation action. Configure a private S3-compatible bucket before enabling DDoS packet evidence: ``` L1_PCAP_S3_BUCKET=network-monitor-pcaps L1_PCAP_S3_REGION=us-east-1 L1_PCAP_S3_ENDPOINT=https://s3.example.com L1_PCAP_S3_ACCESS_KEY_ID=... L1_PCAP_S3_SECRET_ACCESS_KEY=... # Optional: use KMS rather than AES-256 managed encryption. L1_PCAP_S3_KMS_KEY_ID=... ``` The bucket must reject public access and permit signed PUT, HEAD, GET, and DELETE operations for the configured identity. Configure an eight-day object lifecycle as a cleanup backstop; the application normally removes captures after seven days. If object storage is unavailable, incident detection continues and the agent retains completed evidence within its local 1 GiB cap until upload succeeds. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.layeronecloud.com/network-monitor/operations/ddos-monitoring.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.