On this page
Key points
- Locate the exhausted resourceA busy link, a full connection table and a slow application require different evidence and responses.
- Keep useful firewall policyDDoS protection complements access control; disabling the firewall is not an incident strategy.
- Measure the configured systemA headline throughput figure does not describe every packet mix, inspection feature or connection rate.
A firewall has a position and a finite capacity
A firewall can enforce access policy, reject unwanted traffic and, depending on the product and configuration, provide dedicated DDoS functions or hardware acceleration. Saying that every firewall fails against every DDoS attack is inaccurate. The useful question is which resource an incident exhausts and whether the device can act before that resource is lost.
A filter behind a saturated access link cannot recover legitimate packets discarded upstream. Conversely, a link with spare bandwidth can still feed more packet decisions or new states than a particular system can sustain. These cases can look similar to the user but need different remedies.
Distinguish four limits before changing rules
Collect these measurements over the same time interval and label the observation point. Firewall ingress, firewall egress and an upstream flow sample are not interchangeable views. Compare a known healthy period with the incident before treating a single graph as the diagnosis.
| Resource | Evidence to collect | What the evidence does not prove |
|---|---|---|
| Access capacity | Offered and received bit rates, upstream drops and interface errors. | Low received traffic does not exclude loss before the firewall. |
| Packet processing | Packets per second, receive-queue drops and per-core load. | Low average CPU does not exclude a saturated queue or worker. |
| Connection state | New connections, allocated entries, limits and allocation failures. | An entry count alone does not identify malicious sessions. |
| Application work | Successful requests, latency, connection failures and backend load. | An HTTP error alone does not establish a network DDoS attack. |
Place each control where it can protect a resource
When the access path is the bottleneck, investigate upstream filtering or a protected delivery path. When the device itself is the bottleneck, a narrowly scoped stateless rule, a supported early filtering path or specialist mitigation may reduce work before expensive processing. Application abuse may require authentication, request controls or a compatible proxy as well as network protection.
Preserve required access rules, management access and control traffic. Modern firewalls differ in their state handling, acceleration and DDoS features, so inspect the actual configuration and feature-specific measurements. Neither an appliance label nor a software label tells you which workload will fit.
Read state counters without guessing at a fix
On Linux, nf_conntrack_count reports allocated flow entries and nf_conntrack_max defines the configured limit. Read them alongside allocation-failure evidence and traffic behavior. A rising count can be legitimate growth; a low count does not prove the rest of the network stack is healthy.
Do not blindly raise connection limits or shorten every timeout. Memory consumption, established sessions and protocol behavior are part of the decision. Likewise, enabling a log for every packet during a flood can create additional work and hide useful events in volume. Prefer bounded counters and the logging facilities your implementation supports.
Example: 12 Mpps is not automatically a full 10 Gbit/s link
Consider a hypothetical stream of 12 million minimum-size Ethernet frames per second. With 64 bytes per frame including FCS, plus 20 bytes for preamble and inter-frame time, the nominal one-way wire rate is 8.064 Gbit/s. That alone does not fill a 10 Gbit/s link. Larger frames, other traffic and the actual accounting method can change the result.
This calculation also says nothing about whether a particular firewall can inspect the stream. Its configured packet path and state workload must be measured. It is a sizing example, not a customer incident or a product benchmark. A firewall advertised at 40 Gbit/s cannot be declared either safe or overloaded from that number alone.
Define success beyond a drop counter
Establish a baseline
Record legitimate peak traffic, packet sizes, new connections and successful application transactions. Include monitoring and administrative access.
Reproduce the relevant limit safely
Use an authorized isolated test path and the intended rule set. Report offered load, delivered legitimate traffic, loss and latency; do not stress a shared production link to discover its limit.
Check the protected handoff
After filtering, confirm that residual traffic fits the receiving link, firewall and application. Observe both new connections and existing sessions.
Test the reversal
Identify the owner, change scope and removal procedure. Verify that withdrawing a rule restores the expected policy without exposing unrelated services.
Avoid changes that conceal the real failure
- Do not equate a large drop count with restored service: check successful client actions.
- Do not disable the entire firewall to bypass an unexplained performance problem.
- Do not compare a large-frame forwarding benchmark with small-packet stateful inspection.
- Do not assume upstream filtering removes every unwanted application request.
- Do not treat a short incident average as the highest packet or connection rate.
Document the boundary of each protection layer
Write down which component owns access policy, packet reduction, route changes and application controls. Record its capacity evidence and recovery procedure. This gives operations a useful escalation path when the next incident affects a different resource.
Questions and answers
Can a firewall stop some DDoS attacks?
Yes, when its placement, available resources and supported controls fit the attack. A local device cannot recover traffic already lost on a saturated upstream path.
Should the connection table always be increased?
No. Confirm allocation pressure, memory cost and legitimate session requirements before changing limits. A larger table does not solve every packet-processing or application bottleneck.
Does protected transit replace firewall policy?
No. Upstream reduction and local access control address different responsibilities. Keep and validate the policy required by the service.
