DDoS Protection, Firewalls and WAFs: What Protects Each Part of Your Infrastructure?
A saturated uplink, exhausted connection tables and overloaded web applications need different controls. Here is how to plan the protection layers together.
DDoS mitigation, firewalls and web application firewalls are not interchangeable products. They operate in different places: before an internet connection, between networks or directly on web requests. Before buying protection, identify which resource could fail and which legitimate activities must continue. High filtering capacity alone does not tell you whether logins will work or game servers will remain usable.
Three tasks, three perspectives
| Control | Typical purpose | Check separately |
|---|---|---|
| Network mitigation | Reduce attack traffic before the customer connection | Protocols, filtering profile and traffic paths |
| Firewall | Define allowed access between networks and services | Throughput and connection state |
| WAF / application protection | Evaluate web requests against rules | HTTP coverage and application limits |
A product name does not tell you where it is deployed. A locally operated WAF may sit behind the same uplink as the web server. An upstream web proxy creates a different traffic path. Ask for an explanation of the actual integration rather than comparing feature lists alone.
When the link is full, mitigation must happen earlier
Volumetric attacks consume bandwidth, while high packet rates can also put pressure on packet processing. If this traffic reaches the customer connection unfiltered, legitimate users and the attack compete for the same limited capacity. A blocking rule on the destination server cannot retroactively reclaim transmission capacity already used. The filtering location therefore matters.
Consider an illustrative scenario: a company operates a customer portal and a UDP service behind one internet connection. A web proxy can change the path to the portal. However, the directly reachable UDP service does not automatically pass through that proxy. The ingress paths for both services need separate consideration. This is a planning example, not evidence of any particular product's protection capabilities.
A firewall is still necessary, but has its own limits
A firewall enforces an access policy: which source may reach which service using which protocol? Stateful systems also track connections. This supports access control but requires resources. A SYN flood can put pressure on TCP connection establishment; RFC 4987 describes several mitigations and their respective limitations. It does not provide a universal setting that works equally well on every router, server or firewall.
Acceptance testing should therefore cover several measures: bandwidth, packet rate, new connections and application behaviour. An ordinary-looking bandwidth graph does not rule out a connection establishment problem. Also check whether filtering unintentionally affects legitimate clients.
Why L3/L4 protection does not automatically cover HTTP
During HTTP attacks, formally valid requests can consume resources through expensive operations such as search or login. A saturated link is not necessarily the cause. A WAF evaluates web requests using its rules. Application-specific limits, caching and a review of resource-intensive functions may also help. Whether a provider supplies these controls must be explicit in the service scope.
For HTTPS, establish where encrypted connections terminate and which component can actually inspect the HTTP requests. General network filtering should not be assumed to include a WAF or inspection of all application content. An HTTP WAF is also not the right protocol layer for an arbitrary UDP service.
Include IPv6 and additional upstreams in the same plan
List all public addresses, prefixes and ingress paths. A protected IPv4 path does not automatically answer the question for IPv6. With multiple upstreams, traffic may also arrive through another connection. Document normal operation, failover paths and the routing policies agreed with the provider. Additional redundancy is useful only when its protection implications are also understood.
Information that makes proposals comparable
- Services and user workflows: for example, login, API calls, joining a game or reconnecting.
- Reachability: IPv4/IPv6 prefixes, ports, protocols, existing upstreams and handoff location.
- Protection scope: filtering location, covered attack types, limitations and additional components required.
- Acceptance: authorised test scope, legitimate reference traffic and agreed success criteria.
- Operations: responsible contacts, escalation and procedures for changes or false positives.
AS51202 provides DDoS-protected IP transit with Standard or Premium. For an initial enquiry, start with your location, required bandwidth and a description of your services. These form the basis for agreeing a protection tier, routing and handoff. A WAF or additional application-specific service should only be included in the plan when it has been explicitly agreed.
Plan DDoS protection and connectivity with AS51202