WAF vs Firewall: Which One Stops Layer 7 DDoS Attacks?

The WAF vs firewall question becomes urgent when a website is timing out even though ports, connections and network rules all look normal. A network firewall may be doing its job perfectly while thousands of permitted HTTPS requests keep PHP workers, application threads or database queries busy. Layer 7 DDoS protection depends on understanding that difference before choosing where to enforce a rule.

WAF vs firewall: the practical difference

A firewall controls traffic between networks or hosts according to policy. The NIST firewall glossary describes it as a control over the flow of network traffic between systems with different security postures. In normal server operation, that means allowing the services you intend to publish, denying unnecessary ports and restricting sensitive services to trusted sources.

A Web application firewall works deeper in the request path. It inspects HTTP traffic after a connection has been accepted and, where HTTPS is used, after TLS has been terminated somewhere that can read the request. The OWASP Web Security Testing Guide notes that a WAF can inspect request content and apply controls such as blocking, rate limiting or browser verification.

Why Layer 7 DDoS traffic passes ordinary firewall rules

A public Web server must accept connections to HTTP or HTTPS. Once the firewall has allowed that connection, its basic decision is complete. The request may fetch a tiny cached file, or it may start a search, generate a report, call PHP and run several database queries. Those requests can look identical at the network layer while having completely different costs inside the application.

That is why simply closing a port is not a Layer 7 defence. Closing port 443 stops the attack by stopping every customer too. Limiting concurrent connections can reduce pressure from a small group of sources, but modern clients reuse connections and distributed attacks can keep each address below a simple threshold.

What the network firewall should still stop

The firewall remains the first boundary around the server. It should expose only required services, limit management access, reject obviously unwanted networks when that policy is justified and protect non-Web services from direct access. During an incident, it can quickly drop a confirmed abusive source before the connection reaches the Web stack. That is cheap and useful, but it is a source decision rather than an application decision.

ss -lntup
nft list ruleset

On systems managed by another firewall frontend, use its supported command to inspect the effective policy. Do not mix rule managers during an active incident.

• Keep databases, internal APIs and administration ports unavailable to arbitrary Internet sources.
• Apply source restrictions to SSH and control-panel access where operations permit them.
• Use temporary address or subnet blocks only when evidence is strong and the collateral impact is understood.
• Keep connection tracking and anti-spoofing controls, but do not mistake them for HTTP inspection.

What the WAF adds for Layer 7 DDoS protection

A WAF can make a narrower decision because it sees the request the application is about to process. Instead of blocking every visitor from a network, it can monitor or contain repeated requests to a costly route, reject a forbidden method, identify malformed clients or verify a suspicious browser before the request reaches application code. This is where Web application firewall DDoS protection differs from a port rule.

Rate limits need a measured baseline. A copied requests-per-second value can block a legitimate sale, API client or crawler while still allowing a slow but expensive endpoint to exhaust workers. NGINX provides limit_req_dry_run, which counts excessive requests without enforcing the limit. Its request limiting documentation is a useful model for testing impact before changing live traffic.

limit_req_zone $binary_remote_addr zone=per_client:20m rate=10r/s;

server {
    location /expensive-route/ {
        limit_req zone=per_client burst=30 nodelay;
        limit_req_dry_run on;
        limit_req_log_level notice;
    }
}

Treat the numbers as placeholders. Set them from normal peak traffic for the specific route, validate the complete configuration, then review dry-run matches.

Where BashEdge fits between the request and the Web server

The manual controls are effective when the attack pattern is clear and one administrator can keep watching it. BashEdge brings the server firewall, Web application firewall and Layer 7 request evidence into one server-wide view. It connects sources with hosts, paths, request rates and attack rules, then lets the operator monitor, verify or contain the traffic before it becomes application work. You can inspect the workflow safely in the interactive BashEdge demo.

Use both controls without duplicating every rule

1. 1

   Reduce network exposure

   Publish only required services and restrict administrative access at the firewall.

2. 2

   Inspect permitted Web traffic

   Reserve WAF rules for decisions that require routes, methods, content, rates or coordinated behaviour.

3. 3

   Measure before enforcement

   Start new rules in monitor or dry-run mode, then review legitimate matches.

4. 4

   Escalate at the correct layer

   Block sources at the firewall, request behaviours at the WAF and bandwidth floods upstream.

Verify the protection instead of trusting the configuration

A successful reload proves only that the syntax was accepted. Verify that unwanted requests stop before expensive application work, legitimate journeys still complete and server pressure returns toward its normal baseline. Compare the same measurements from before and after the rule, then keep watching long enough to see whether the campaign changes sources or routes.

• Confirm that required ports remain reachable and unnecessary services remain closed.
• Check WAF or rate-limit logs for the host, path, action and reason that matched.
• Test normal browsing, login, checkout, API and monitoring flows from outside the server.
• Compare Web worker CPU, request latency, queue depth, error rate and database activity with the pre-change sample.
• Review false positives before turning a temporary incident rule into permanent policy.