Can a Firewall Stop a DDoS Attack?

A firewall can block some malicious traffic and reduce your attack surface, but it cannot stop a DDoS attack on its own. If an attack saturates the connection upstream, the traffic may never reach the firewall. Stateful firewalls can also become bottlenecks when floods exhaust their connection tables or processing capacity.

Most organisations already have several controls they associate with DDoS protection: a network firewall, a Web Application Firewall (WAF), and basic protection included with a cloud or hosting plan. Each has a legitimate role, but none provides complete coverage by default. The practical question is not whether these controls exist, but which attacks they can stop, where their protection ends, and what remains exposed.

Key Takeaways

• A firewall is one layer, not a complete DDoS solution. It can close unnecessary ports, restrict protocols, and block known sources, but it cannot protect a saturated upstream connection and may itself be vulnerable to resource exhaustion.
• A WAF adds application-layer protection, but placement and configuration matter. Rate limits, bot controls, and custom rules help only if traffic passes through the WAF and the controls activate before the application is overwhelmed.
• Hosting-included protection is not the same as end-to-end coverage. The included protection varies by provider and plan and may not cover every asset, traffic path, or application-layer threat.
• The protection stack must be validated as deployed. Controlled DDoS testing establishes whether the different controls work together, where their limits sit, and whether legitimate users can still reach the service during mitigation.

What Can a Firewall Stop During a DDoS Attack – and Where Are Its Limits?

A firewall remains an important part of DDoS defence, but its effectiveness depends on where it sits, what traffic it can inspect, and how much traffic it can process. It should reduce exposure and enforce network policy, not be treated as the only control standing between an attacker and the service.

What a Firewall Can Block

A network firewall can prevent access to ports, protocols and services that the organisation does not need to expose. It can apply access control lists, reject traffic from known malicious sources and enforce connection or packet-rate limits where supported. Closing an unused UDP port, restricting administrative interfaces or blocking an unnecessary HTTP method removes opportunities that an attacker might otherwise exploit.

These controls provide real value. Reducing the number of reachable services makes the environment easier to defend and leaves fewer policies to monitor and maintain. More advanced firewalls may also inspect application traffic and identify certain anomalous patterns, although those capabilities vary by product, placement, and configuration.

The limitation is not that a firewall does nothing against DDoS. It is that the firewall protects only the traffic and capacity it can see and process.

Three Reasons a Firewall Is Not Enough on Its Own

First, the attack may exhaust the connection before reaching the firewall. An on-premises firewall normally sits behind the organisation’s internet circuit. If a volumetric attack fills that circuit, legitimate traffic cannot get through – even if the firewall would have rejected every malicious packet. Mitigation must therefore occur upstream, where a provider, CDN or scrubbing service has enough capacity to filter the traffic before it reaches the constrained link.

Second, the firewall can become the target. Stateful firewalls track active connections so they can make informed decisions about each packet. Connection floods may consume the firewall’s state table, CPU, or memory without using all the available bandwidth. The circuit remains operational, but the device responsible for protecting it can no longer accept legitimate connections.

Third, not all malicious requests look malicious at the network layer. An HTTPS request to a login page, search function, or API may use a valid protocol and follow an allowed path. A network firewall may pass it even when thousands of distributed clients are collectively exhausting the application. These scenarios require application-aware controls, such as an appropriately placed and configured WAF, alongside network-layer protection.

The right architecture depends on where services are hosted, which attack layers need to be covered and where capacity constraints exist. Red Button’s guide to DDoS protection topology options explains how firewalls, cloud services, ISPs and scrubbing centres fit into that wider defence.

What About a WAF?

A Web Application Firewall adds protection that a network firewall usually cannot provide. It inspects HTTP and HTTPS requests at the application layer and can apply rate limits, managed challenges and custom rules to specific hosts, paths, methods or client behaviours. This makes it useful against attacks targeting login pages, search functions, APIs and other resource-intensive application services.

But a WAF is not automatically a complete DDoS solution. Its effectiveness depends first on where it is deployed. An edge-based WAF or CDN can filter requests before they reach the organisation’s infrastructure. A host-based WAF deployed alongside the application may share the same bandwidth, CPU, or memory constraints as the service it protects. Under sufficient load, both can become unavailable at the same time.

Configuration matters just as much as placement. Generic rate limits may be too permissive to protect a smaller backend or so restrictive that they block legitimate users. Limits based mainly on individual IP addresses can also struggle with distributed attacks originating from many residential or otherwise reputable addresses: the traffic from each source may remain below the threshold while the combined request volume exhausts the application. Red Button’s analysis of why rate limits fail under distributed attacks sets out where that counting problem comes from.

Coverage must also be verified. Depending on the product and deployment, the WAF may not inspect every API, protocol, or alternate route to the origin. Direct-to-origin traffic can bypass an edge WAF entirely, while newer or less common application protocols may require additional configuration and support.

A WAF therefore fills an important gap between network filtering and the application, but only when it sees the relevant traffic and its policies reflect the backend’s actual capacity. Red Button’s guide to application-layer DDoS attacks explains why these attacks require different controls from volumetric and protocol attacks. The remaining question is whether those controls activate early enough to protect the service without rejecting legitimate users.

Is DDoS Protection Included With Most Hosting Plans?

Sometimes – but “included” does not mean the same thing across providers, and it should not be treated as proof that an application is protected.

Some major cloud and edge platforms provide automatic baseline protection. AWS Shield Standard is included for all AWS customers at no additional charge and covers common network- and transport-layer attacks. Azure applies default infrastructure-level DDoS protection that defends against common network-layer attacks, while noting that Layer 7 protection for web applications requires a WAF offering in addition. Cloudflare states that its DDoS protection is available on all plans across layers 3, 4 and 7.

That does not establish that most hosting plans provide equivalent coverage. A provider may be protecting the availability of its shared infrastructure without offering customer-specific thresholds, application-layer policies, attack analytics, or direct incident support. The word “protection” might therefore describe anything from general platform safeguards to a dedicated service configured around an individual workload.

The distinction matters because the provider and the customer protect different things. The provider may have enough capacity to keep its network operational, while a customer’s public IP, origin server, API, or database remains vulnerable. Basic protection may also operate with generic thresholds that do not reflect how much traffic the application can safely process.

Before relying on hosting-included protection, confirm:

• Which IP addresses, domains and services are covered?
• Does the protection cover only network and transport layers, or also HTTP/S and API attacks?
• Can thresholds and mitigation policies be tuned to the application?
• Are alerts, attack reports, and specialist support included?
• Does protection follow every production and failover traffic path?
• Who is responsible for configuring and monitoring the application layer?

Upgrading within the same provider does not close these questions on its own. In one engagement, Red Button ran seven DDoS simulations for a European government agency protected by the Azure DDoS IP Protection plan, a paid tier above Azure’s default protection. Only three of the seven attacks were fully detected and mitigated; three were not mitigated at all and disrupted the service. The network-layer protection worked as designed. The gaps sat in application-layer protection, rate limiting and detection.

Included protection can provide a valuable baseline. Whether it is sufficient depends on the service’s architecture, availability requirements, and tolerance for disruption – not simply on whether a DDoS feature appears in the hosting plan. The same holds for every other control in the stack.

What Does Each Control in Your DDoS Protection Stack Actually Do?

DDoS protection is not a single product. Each control sees different traffic, protects different resources, and has its own failure point. Exact capabilities vary by provider, service tier, placement, and configuration. For a more in-depth discussion of protection options, see Red Button’s paper, Understanding DDoS Protection Options.

Control	What it can stop	Where it may fall short	What it still requires
Network firewall or IPS	Unnecessary ports and protocols, known malicious sources, policy violations, and some network or connection-based floods	The upstream connection may saturate first; state tables or processing capacity may be exhausted	Upstream mitigation and tested packet and connection limits
Host-based WAF	HTTP/S requests that violate application rules, including disallowed methods, paths, and request patterns	It may share bandwidth, CPU, or memory constraints with the application	Resource isolation, upstream filtering and complete route coverage
Edge WAF or CDN	Application-layer floods, rate-based abuse and known bot patterns; caching can reduce requests reaching the origin	Direct-to-origin traffic, unproxied assets and services outside its configured scope	Origin restrictions, asset coverage and application-specific policies
Hosting-included protection	Provider-defined baseline protection against common infrastructure attacks	Coverage may be limited to the provider’s platform or selected resources	Confirmation of the assets, attack layers, telemetry, and support included
Dedicated scrubbing service	High-volume network and protocol attacks, including direct-to-origin traffic when routing is configured correctly	Traffic that does not divert through the service; application-layer attacks if that capability is not included	Route coverage, clean-traffic delivery and application-layer integration

No control should be judged only by the attacks listed in its product description. Placement determines whether traffic reaches the control before a constrained link or device fails. Configuration determines when mitigation activates. Coverage determines whether an attacker can choose another route.

The same product may be adequate in one environment and insufficient in another. An edge WAF can provide strong application-layer protection when every relevant hostname and API passes through it, while leaving a directly reachable origin exposed. A firewall may correctly block unwanted protocols and still be unable to help once the connection in front of it is saturated.

The purpose of a layered architecture is not simply to deploy more controls. It is to ensure that each control covers failure modes left by the others, and that the complete chain preserves service for legitimate users.

How Can You Tell What DDoS Protection You Actually Have?

Product names alone do not establish your DDoS coverage. Start with an inventory of every public IP address, domain, API, and internet-facing service, then trace the route legitimate and malicious traffic would take to reach each one. Compare that map with your contracts, service tiers, and active security policies.

Four questions reveal most of the uncertainty:

• Which assets and attack layers are covered? Confirm whether protection applies to every public service and whether it covers network, protocol, and application-layer attacks.
• Where does the provider’s responsibility end? Identify which controls the provider operates and which configurations, assets, and response actions remain your responsibility.
• What happens to legitimate traffic during mitigation? Determine how rate limits, challenges, and filtering affect customers, mobile applications, APIs, and trusted partners.
• Has the deployed configuration been independently tested? A product may provide the advertised capability while routing, thresholds, or asset coverage leave the service exposed.

Documentation and configuration reviews can establish the intended coverage. They cannot prove how the complete stack will behave under attack or whether legitimate users will retain access. That requires evidence from a controlled simulation. Red Button’s guide to DDoS testing vs DDoS protection explains why buying protection does not, by itself, prove that it works.

Organisations that already have dedicated mitigation still uncover gaps between the product and its deployment – traffic routes that bypass the protection, thresholds set above the point where the backend fails, and escalation that begins after the service has degraded. Red Button’s analysis of why DDoS mitigation fails in practice examines each of these once protection is in place. If production services are in scope, see how Red Button approaches safe DDoS testing against production.

How Do You Know Whether Your DDoS Protection Actually Works?

Your firewall, WAF, and hosting provider may all contribute to DDoS protection. The mistake is assuming that their presence adds up to complete coverage. Each control has a defined scope, and gaps can remain between the layers even when every product performs as designed.

The only reliable measure is whether the complete service path continues to support legitimate users while attack traffic is detected and mitigated. That requires validating the controls as they are deployed, identifying where protection ends, and correcting the gaps that testing reveals.

Find out what your existing controls actually cover. Request a controlled DDoS simulation.

Frequently Asked Questions

Can a firewall stop a DDoS attack?

A firewall can block unwanted ports, protocols, known malicious sources, and some network-based attack traffic. It cannot stop every DDoS attack on its own, particularly when the attack saturates the upstream connection or exhausts the firewall’s processing or connection capacity.

Does a WAF protect against DDoS attacks?

A WAF can mitigate application-layer attacks by inspecting HTTP/S requests and applying rate limits, bot challenges, and custom rules. Its effectiveness depends on its placement, configuration, and coverage. Traffic sent directly to the origin or through an unprotected route may bypass it.

Is DDoS protection included with most hosting plans?

Many cloud and hosting providers include some form of baseline DDoS protection, but there is no standard level of coverage. Check which assets, protocols, and attack layers are protected, whether application-layer controls require additional configuration, and what monitoring or incident support the plan includes.