A source-backed look at one compatible host-ingress layer in Cybroxa's broader protection architecture.
Published
XDP is not Cybroxa's main or complete DDoS protection system. It is a compatible host-ingress layer that can complement provider, upstream, network, application, monitoring, and response controls within the protection scope designed for a service.
The short version
Cybroxa approaches DDoS protection as a layered architecture. Depending on the environment and written scope, that can involve provider or upstream capabilities, traffic and routing controls, host filtering, application safeguards, monitoring, alerting, and operational response. XDP belongs to the host-filtering part of that design.
Linux normally receives a packet through the network interface, creates kernel networking structures, and passes the traffic through the broader network stack. XDP provides an earlier programmable hook. A small verified eBPF program can inspect supported packet metadata and return a verdict such as XDP_PASS or XDP_DROP before the packet follows the ordinary stack path.
Cybroxa's design does not treat that hook as a single permanent blocklist. It separates kernel packet handling, BPF maps, userspace detection, mode control, and operational supervision. Explicit allowlists and targeted policies stay distinct from generic attack filtering, which reduces the need to run every defensive control at full force during ordinary traffic.
One layer, not the whole service
XDP protects the compatible host path where it is attached. It does not create upstream bandwidth, replace provider or application controls, guarantee availability, or make every server compatible.
Where XDP sits in the network path
The ingress program is attached to a selected network interface. It can parse supported Ethernet and VLAN framing, IPv4 and IPv6 packets, TCP, UDP, ICMP, and fragment metadata. Bounds checks are required at every parsing step because eBPF programs must satisfy the kernel verifier before they can load.
Explicit allowlists receive priority. For other traffic, the runtime records telemetry into BPF maps before most enforcement verdicts. Targeted policies can then match exact addresses, CIDR ranges, sources, destinations, pools, ASNs, or confirmed source overrides. Mode-aware generic checks are evaluated only when the controller has enabled the applicable attack state.
A pass verdict continues into the Linux network stack and the application path. A drop verdict discards the packet at XDP, avoiding much of the later work that packet would otherwise cause. That early location is valuable, but its practical capacity still depends on hardware, driver support, attachment mode, packet mix, CPU, provider path, and the wider architecture.
Layered DDoS architecture
Protection starts with the traffic path.
Upstream capacity, network controls, host filtering, application safeguards, monitoring, and response each have a role.
Host layer
XDP evaluates compatible ingress traffic early.
On supported Linux hosts, the XDP and eBPF hook can make bounded packet decisions near the network interface.
Signal and policy
Detection and policy add context.
Telemetry, allowlists, targeted rules, and multi-signal confirmation help separate ordinary traffic from suspected abuse.
One component
Legitimate traffic continues to the service.
XDP is one compatible host-level layer. It complements the wider protection design and cannot replace upstream capacity or application controls.
Interactive network path
Trace the XDP host layer through the packet path.
This demonstration covers one host-ingress component. Actual verdicts depend on configured policy, observed traffic, confirmation state, deployment support, and the surrounding DDoS architecture.
Public networkInbound trafficIPv4 or IPv6 packets approach the protected interface.
Receive pathNetwork interfaceThe NIC and driver deliver the packet to the XDP attachment point.
Before the normal stackXDP ingress hookEthernet, VLAN, IP, transport, and fragment metadata are parsed within bounded kernel logic.
Evaluation orderAllowlist and telemetryAllowlists receive priority. Other traffic updates BPF telemetry before most enforcement verdicts.
Policy mapsTargeted controlsIP, CIDR, source, destination, pool, ASN, and confirmed-source policies remain available across modes.
Confirmed attackGeneric filtersValidation, state, fragment, protocol, and graduated rate controls activate as a coordinated bundle.
Control planePassive observation
The userspace detector reads kernel telemetry, compares it with learned behavior, and updates policy only after the applicable confirmation logic.
BPF mapsPacket, byte, protocol, source, destination, and drop signals
to
DetectorBaselines, concentration, timing, ratios, and legitimacy relief
to
Mode controllerPassive, armed quiet, or confirmed attack
Current demonstration verdictPASS
Allowlisted or ordinary traffic is observed and passed when no explicit hard rule matches. Generic attack filtering remains inactive.
PASSContinue into the Linux network stack and application path.
DROPDiscard the packet at XDP before normal stack processing.
The detection plane looks for agreement between signals
The kernel program is designed for bounded packet work. Broader interpretation happens in userspace, where the detector reads telemetry and maintains a view of current and historical behavior. It considers source and global exponentially weighted moving averages, time-of-day bandwidth patterns, packet-size uniformity, packet inter-arrival behavior, protocol deviation, destination entropy, and destination concentration.
Protocol-specific signals add context. These include SYN behavior, ACK behavior, UDP behavior, aggregate bandwidth, and observed drop activity. Destination concentration matters because a concentrated surge against one destination has a different shape from a broad flash crowd spread across many destinations.
The detector also applies legitimacy relief for traffic patterns that can resemble attacks when viewed too narrowly. The current architecture accounts for trusted CDN and cloud ranges, upload behavior, WebSocket traffic, and DNS behavior. Recidivist history can strengthen the response to sources that repeatedly return after prior confirmed abuse.
Source decisions normally pass through confirmation windows before kernel rules are written. Configured fast-track conditions can shorten that path for stronger signals. Baselines and recidivist state persist to JSON so a process restart does not always mean starting from an empty history.
Conceptual view of the host ingress path and userspace feedback loop. The interactive diagram above carries the exact labels and operating-state explanation.
Three modes separate observation from broad enforcement
Passive
Telemetry remains active. Allowlists and explicit hard policies still apply, while generic attack filters remain disabled. The reference configuration starts in a passive-only posture.
Armed quiet
The passive-only restriction is cleared. Confirmed source decisions and operator-defined policies can act, but the general attack enforcement bundle remains off while the detector continues evaluating conditions.
Attack
Multi-signal confirmation enables the generic enforcement bundle. Explicit policy remains in force, and supported packets are evaluated against the broader validation, state, fragment, and rate-control path.
This separation matters operationally. A targeted source can be blocked without declaring a general attack, and an ordinary traffic increase does not automatically enable every generic filter. The current reference configuration also uses a warm-up period before adaptive decisions. Its default is 20 detector cycles at 0.5 seconds per cycle, which is about 10 seconds, but deployments may tune that behavior.
Defence mechanisms in attack mode
The generic bundle is not one threshold. It combines several bounded checks that address different attack shapes. Exact values are deployment configuration, not public capacity guarantees.
Packet validity and route hygiene
Malformed packet rejection, bogon filtering, learned TTL profile checks, fragment controls, and supported protocol validation remove traffic that does not fit the expected packet path.
Rate control at several scopes
Token buckets can operate globally and by source, prefix, destination, or port. Packet-rate and byte-rate accounting provide different views of the same flow pressure.
TCP state and flood controls
TCP flag validation, SYN source and prefix limits, SYN-to-ACK ratio checks, strict state checks, bare ACK controls, and optional cookie-style ACK validation address several common TCP abuse patterns.
UDP, ICMP, and fragments
UDP rate and amplification-pattern controls, ICMP rate controls, and fragment policy add protocol-specific protection without assuming every packet type behaves like TCP.
Graduated limits can sample selected packets through instead of turning every threshold crossing into an immediate hard block. Large TCP payloads can bypass a packet-rate bucket while still paying the byte-rate bucket, which is intended to reduce false positives for legitimate upload-heavy traffic.
How the design protects legitimate traffic
Early filtering is only useful when it preserves the traffic the service is meant to receive. Cybroxa's runtime approaches that problem through ordered allowlists, explicit policy, learned behavior, destination concentration, confirmation windows, legitimacy relief, and mode separation.
The detector does not assume a single high packet rate proves an attack. It asks whether several observations agree, whether the traffic is concentrated, whether the protocol shape changed, whether a trusted range is involved, and whether the behavior resembles known legitimate uploads, WebSockets, or DNS. The policy layer can still enforce a confirmed hard rule when operators or source confirmation establish a narrower threat.
No tuning strategy can promise zero false positives. Production operation still requires traffic baselines, service-specific policy, logs, alerting, customer context, review procedures, and a way to change or remove a rule when conditions change.
The packet filter is backed by supervised userspace services
A Go manager coordinates the runtime lifecycle. It cleans stale attachments and pinned objects, starts the loader, supervises the Python agent, restarts it with exponential backoff, and detaches XDP while cleaning pins during an orderly shutdown.
The Python agent supervises the detector subprocess, exposes detector state, writes JSON metrics, publishes Prometheus textfile metrics, and restarts the detector if it fails. This keeps packet enforcement, detection, and operational visibility as separate responsibilities instead of hiding every task inside one long-running process.
The architecture also includes a TC clsact egress program for BCP38-style source validation. Its job is anti-spoofing on outbound traffic, not inbound DDoS filtering. It remains fail-open until legitimate source addresses are configured, which avoids blocking all egress before the source policy is ready.
Where this layer fits and stops
XDP availability depends on a compatible Linux environment, network interface, kernel, NIC driver, and permitted attachment path. Native driver mode and generic mode do not have identical performance characteristics. Virtualization, provider policy, offload behavior, routing, tunnels, and network ownership can all affect what is possible.
Host-level XDP filtering also acts after traffic has reached that host's network path. If an upstream circuit or provider edge is already saturated, the host cannot recover bandwidth it never received. Larger resilience designs may require upstream filtering, scrubbing, provider coordination, anycast or distributed capacity, origin isolation, application controls, and documented incident procedures.
For these reasons, Cybroxa confirms the protected interfaces, protocols, protection layers, responsibilities, capacity assumptions, exclusions, monitoring, response path, and any service commitment in the applicable service description or written agreement. The implementation described here is one technical layer, not the primary definition of the service or an unlimited mitigation promise.
Does XDP guarantee that a protected service will remain online?+
No. XDP can make early packet decisions on a compatible host, but it cannot guarantee immunity from every attack, prevent upstream link saturation, or replace a written service commitment.
Does attack mode block all inbound traffic?+
No. Attack mode enables a broader enforcement bundle. Each supported packet is still evaluated against allowlists, policy, protocol checks, state, and applicable limits before receiving a pass or drop verdict.
Can Cybroxa attach this XDP host layer to any server?+
No. Deployment depends on the Linux kernel, protected interface, NIC driver, attachment mode, provider, network ownership, origin design, and the operational access available for that service.
Does XDP replace upstream protection or application security?+
No. Host-level XDP filtering is one layer. Resilient deployments may also require upstream capacity, provider controls, architecture changes, application rate limits, authentication, monitoring, and incident response.
