GitHub - bardhyliis/ebpf-ddos-mitigation 路 GitHub
/" data-turbo-transient="true" />
Skip to content
Search or jump to...
Search code, repositories, users, issues, pull requests...
-->
Search
Clear
Search syntax tips
Provide feedback
--><br>We read every piece of feedback, and take your input very seriously.
Include my email address so I can be contacted
Cancel
Submit feedback
Saved searches
Use saved searches to filter your results more quickly
-->
Name
Query
To see all available qualifiers, see our documentation.
Cancel
Create saved search
Sign in
/;ref_cta:Sign up;ref_loc:header logged out"}"<br>Sign up
Appearance settings
Resetting focus
You signed in with another tab or window. Reload to refresh your session.<br>You signed out in another tab or window. Reload to refresh your session.<br>You switched accounts on another tab or window. Reload to refresh your session.
Dismiss alert
{{ message }}
bardhyliis
ebpf-ddos-mitigation
Public
Notifications<br>You must be signed in to change notification settings
Fork
Star
main
BranchesTags
Go to file
CodeOpen more actions menu
Folders and files<br>NameNameLast commit message<br>Last commit date<br>Latest commit
History<br>7 Commits<br>7 Commits
media
media
FirewallGarbageCollectionService.cs
FirewallGarbageCollectionService.cs
GameNodeShelloperations.cs
GameNodeShelloperations.cs
README.md
README.md
View all files
Repository files navigation
Bare-Metal Network Shield
A hybrid nftables + XDP/eBPF mitigation stack extracted from a game server orchestration platform after repeated issues with high-PPS UDP flood traffic affecting container performance.
The goal is not to replace enterprise DDoS mitigation services or dedicated hardware appliances, but to reduce kernel overhead during sustained flood conditions and help keep game server containers responsive in small-scale bare-metal environments.
Why This Exists
During testing and production operation, I found that relying solely on traditional firewall rules and conntrack-based filtering could still introduce enough CPU and kernel networking overhead to impact running game servers under sustained high packet rates.
This project explores a layered approach:
nftables for stateful filtering and rate limiting
XDP/eBPF for early packet drop paths
a small userspace daemon to synchronize state between them
Docker, UFW, and nftables
Docker鈥檚 iptables-based networking and UFW can introduce complexity when combined, especially in environments with heavy custom firewalling.
Rather than continuing to layer rules on top of multiple abstractions, I opted to manage filtering directly with nftables.
The ruleset uses a custom chain at a high-priority prerouting hook (-150) so traffic can be evaluated early in the networking path before reaching later firewall stages or container networking rules.
Architecture
1. Stateful Filtering (nftables)
nftables handles:
Per-protocol rate limiting
Connection tracking-based protections
Dynamic blacklist with timeout
IPs that exceed extreme thresholds are added to a blacklist set with a time-based expiration.
2. Fast-path filtering (XDP/eBPF)
In testing, nftables alone still introduced measurable CPU overhead under sustained high packet rates.
To reduce this overhead, a userspace daemon monitors the nftables blacklist and synchronizes entries into an eBPF map used by an XDP program.
When enabled, XDP allows packets to be dropped very early in the kernel networking path (at the XDP hook in the driver or generic fallback mode depending on system support).
Note: XDP mode depends on driver support. Systems without native XDP support will fall back to a generic mode in the kernel networking stack.
Implementation Notes
C# is used for orchestration and remote management of rules
nftables rules are generated per-port and deployed dynamically
XDP synchronization runs as a systemd service with a 2-second polling interval
This introduces a small window where newly flagged IPs may still reach the kernel before being added to the XDP map.
Kernel Tuning
UDP buffer sizing
Increasing rmem_max and wmem_max improves resilience under bursty traffic patterns by reducing packet drops in the kernel receive buffers.
This is especially relevant for real-time game traffic where short bursts can otherwise cause visible desynchronization.
TCP congestion control
This setup uses BBR instead of CUBIC:
CUBIC can interpret packet loss as congestion
BBR tends to behave more consistently under variable network conditions typical in game server traffic
Stress Testing
Tested on an AMD EPYC bare-metal node under synthetic UDP flood conditions reaching approximately 500,000 packets per second.
At peak load, the upstream provider eventually null-routed the box to protect their network.
This behavior is visible in the full 22-minute telemetry replay:
馃憠 Performance audit: https://ray-hosting.com/en-US/performance-audit
Observed behavior:
nftables handled initial...