I can't read their page, but here's a very simple guide if you want to avoid using a CDN: 0. Tune your kernel settings to prepare for attacks. Syn floods, conn

I can't read their page, but here's a very simple guide if you want to avoid using a CDN: 0. Tune your kernel settings to prepare for attacks. Syn floods, connection exhaustion, junk packets, timeouts. Disable all open internet ports you don't need, disable icmp, etc. 1. If you want/need to use HTTP3 (may be more efficient depending on your traffic), install Nginx or Caddy as caching reverse proxies. Other tools don't have robust HTTP3 support yet (or so it seems?). Aggressively cache unauthenticated content, do not allow dynamic content through without authentication. 2. If you don't need HTTP3, install and configure HAproxy and Vinyl Cache. Both can help track and defend against traffic spikes and DDoS. HAproxy terminates the TLS as well as load baancing. It can be configured to track multiple metrics about the requests to efficiently identify and rate-limit connections and requests. Vinyl is an insanely fast cache, and includes an extra tool (Iocaine) which poisons DDoS requests with junk traffic at a slow rate. Aggressively cache unauthenticated content, do not allow dynamic content through without authentication. 3. If none of those are an option, use iptables rules to rate-limit any TCP network service. Below is an example of a tiered network rate-limit. You need to tune this to your specific situation: first performance-test your stack from a remote host, then change the limits here to be under your max limit. It won't help as much as caching, but you can combine it with the above solutions. ####### Tier 1: Aggressive per-IP limit on >50 new connections/sec per source IP iptables -A INPUT -p tcp --dport 443 -m state --state NEW -m hashlimit --hashlimit-name https_t1 --hashlimit-upto 50/sec --hashlimit-burst 100 -m hashlimit ! --hashlimit-mode srcip -j DROP 2>/dev/null ####### Tier 2: Sustained per-IP limit on >10 conn/sec per source IP iptables -A INPUT -p tcp --dport 443 -m state --state NEW -m hashlimit --hashlimit-name https_t2 --hashlimit-above 10/sec --hashlimit-burst 30 -m recent --name abusers --set -j DROP ####### Tier 3: Temporary blackhole with `recent`. IPs recorded as abusers are blocked for 60s on ANY packet (not just NEW) iptables -I INPUT 1 -p tcp --dport 443 -m recent --name abusers --rcheck --seconds 60 --hitcount 1 -j DROP ####### Tier 4: Global ceiling with `limit`. Server-wide cap on 500 new conn/sec, bursts at 1000 iptables -A INPUT -p tcp --dport 443 -m state --state NEW -m limit --limit 500/sec --limit-burst 1000 -j ACCEPT ####### Tier 5: Anything NEW to 443 that got this far without matching ACCEPT is dropped iptables -A INPUT -p tcp --dport 443 -m state --state NEW -j DROP If you google around you can find more examples for more advanced DDOS-mitigation (https://github.com/scriptzteam/anti-DDoS-iptables https://github.com/scriptzteam/anti-DDoS-iptables, https://github.com/gamemann/XDP-Firewall https://github.com/gamemann/XDP-Firewall, etc). A sufficiently large or advanced DDOS will require either a much more sophisticated detection/mitigation mechanism, or more bandwidth and processing power. If you can turn on more nodes on different internet backhauls, that's probably the simplest way to help lessen load.