Anti-DDoS and WAF for High-Traffic Websites

🌐 This is the English edition of an article first published in Persian: Anti-DDoS و WAF برای سایت‌های پرترافیک؛ چهار لایه و برنامهٔ آمادگی پیش از روز پیک

A few weeks before a major sales campaign, one of our colleagues met the technical team of a high-traffic online store. Their answer to "What do you do if you are attacked?" was: "We call the data center so they filter the traffic, and we also have a WAF." When we walked through the scenario on paper, it turned out that reaching the data center takes at least twenty minutes, the WAF was in report-only mode, and nobody knew how much load the servers could take from heavy search requests. The tools were not missing. A layered design and a response plan were.

In this guide I explain how high-traffic websites and services (online stores, internet banking, news portals, registration systems and public portals) can combine Anti-DDoS and a WAF so that on peak day attacks are stopped and real customers still get in.

According to Cloudflare's DDoS threat report for the first half of 2026, 90.6 percent of network-layer attacks ended in under ten minutes, out of 23.2 million attacks mitigated in that period. By the time someone picks up the phone, the attack is over and the damage is done. Defense has to be automatic and always on.

🚨 Why high-traffic sites are the first target

• Every minute of downtime is expensive: on sale or registration days, every minute offline means lost orders and lost trust, and extortion crews know it.
• Attacks are no longer only about volume: next to UDP floods and DNS reflection, layer-7 attacks use normal-looking requests (search, cart, login) to exhaust application servers and databases without filling the bandwidth.
• Bots are always there: even without DDoS, credential stuffing, price scraping and fake inventory holds are part of daily traffic on these sites.
• Attacks are short and repeated: waves of a few minutes, one after another, to wear the team down and find the layer that reacts too slowly.

🧩 Four layers, one job each

A common mistake is to expect one appliance to do everything. In designs that have worked in practice, traffic passes four stations from the outside in:

1. Upstream scrubbing: for volumetric attacks larger than your internet link, only your ISP or a cloud scrubbing service can help. Finalize the contract, the activation threshold and the emergency contact before peak day.
2. On-premises Anti-DDoS at the network edge: a dedicated appliance in front of the firewall that stops SYN and UDP floods, DNS/NTP/CLDAP reflection and low-and-slow attacks within seconds and without human action. DPTech Anti-DDoS is built for this role and works from a baseline of each service's normal traffic. A stateful firewall should not be the first barrier against a SYN flood; its session table fills before the link does.
3. ADC and load balancing: BIG-IP LTM or the DPTech ADX proxies connections, terminates TLS, applies per-path rate limits and takes unhealthy servers out of rotation. In virtualized environments, Avi Load Balancer adds automatic scaling.
4. WAF and bot management: at layer 7, F5 Advanced WAF, FortiWeb or the DPTech WAF go beyond injection and XSS and separate layer-7 DDoS from real users with behavioral detection, JavaScript challenges and browser fingerprinting.

To compare the modules and see which capability sits in which license, see the F5 BIG-IP module comparison.

🔬 The WAF on peak day: three settings that matter most

• Move from report-only to blocking while things are quiet: run the WAF policy in learning mode for two to four weeks, fix false positives on sensitive paths (payment, login, search) and switch to blocking before the campaign. Attack day is not the day to test a new policy.
• Rate limits per path, not for the whole site: the home page can take thousands of requests per second, but search, login and "add to cart", which reach the database, need separate and stricter thresholds.
• Behavior-based layer-7 DDoS protection: features that watch server latency and challenge only suspicious sources when responses slow down work far better than blindly blocking a country or an IP range; your real customers sit behind the same carrier NAT.

⚠️ Four common mistakes

1. Relying on "we will call someone": when most attacks end in under ten minutes, a manual response is always too late.
2. Exposing the origin server's IP: if the origin can be found through an old DNS record, a test subdomain or outbound email, attackers bypass the front layers. Allow only traffic from the protection layer to reach the origin.
3. Forgetting DNS: a site whose name server is under attack is effectively offline; include secure DNS and GSLB in the design.
4. Never testing capacity: without a load test and a controlled drill, nobody knows where the bottleneck is. It is usually the database, not the bandwidth.

🗺️ A five-stage readiness plan before a campaign

1. Six weeks before: list public services, sensitive paths and current capacity; scan the web application with a web and API scanner so the WAF does not have to cover known holes.
2. Four weeks before: a normal-traffic baseline in the Anti-DDoS, the WAF policy in learning mode, per-path rate limits.
3. Two weeks before: a load test and a controlled attack drill coordinated with your ISP; close direct access to the origin server.
4. One week before: the WAF in blocking mode, a shared dashboard and alerts in your SIEM, and a one-page response runbook with an owner for every step.
5. Peak day and after: live monitoring, a post-incident report and retuned thresholds for the next campaign.

If you are not sure which model and license fit your traffic and number of services, the license finder asks a few short questions and suggests options with reasons. To design the layers around your own architecture and budget, you can also talk to our team.

💬 What do you think? If your site came under a layer-7 attack right now, which layer would react automatically first, and how many minutes would it take?

• Kazem Mortazavi, independent network-security consultant

Originally published at https://symantecland.com on October 15, 2026.