The Role of Firewalls in Web Server Security

What a firewall actually does for a web server

A web server exists to accept connections from strangers, which makes it an unusual thing to defend. You cannot simply block everyone. What you can do is make sure that the only doors open to the public are the ones you intend to be open, usually HTTP on port 80 and HTTPS on port 443, and that everything else is either closed or reachable only by people you trust. That is the core job of a firewall: it inspects traffic against a set of rules and allows, drops or rejects each packet or request.

Firewalls do not fix vulnerable code, weak passwords or outdated software. They reduce the attack surface, so that a flaw in a service you forgot about, such as a database listening on a public interface, is not reachable from the internet in the first place. Think of a firewall as one layer in a defence-in-depth setup alongside patching, strong authentication, backups and monitoring.

Types of firewalls and where they sit

The word firewall covers several different tools. Understanding which layer each one operates on helps you decide what you need.

Most small and medium sites benefit from at least two of these: a provider-level firewall or security group plus a host firewall on the server. A WAF becomes valuable when you run applications with login forms, user input or a plugin ecosystem that is frequently targeted.

Start with a default-deny policy

The most important design decision is the default. A default-allow firewall blocks a few known-bad things and lets everything else through, which means every new service you install is exposed until you remember to block it. A default-deny firewall does the opposite: it drops everything unless a rule explicitly allows it.

For a typical public web server, the allow list is short:

• Inbound TCP 80 and 443 from anywhere, for HTTP and HTTPS.
• Inbound SSH (TCP 22 or your chosen port) only from your office IP, a bastion host or a VPN range.
• Established and related connections, so replies to traffic the server initiated can come back.
• Loopback traffic, so local services can talk to each other.
• Outbound traffic as needed for updates, DNS, mail relays and APIs. Restricting outbound traffic is stricter and more work, but it can limit what malware does if a server is compromised.

Databases such as MySQL, PostgreSQL or Redis, along with admin panels and monitoring agents, should normally listen only on localhost or a private network. If they must be reachable remotely, allow only specific source addresses.

Host firewall examples

On Ubuntu and Debian systems, ufw provides a simple front end. Always allow your SSH access before enabling the firewall, or you can lock yourself out of a remote machine.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

On modern Linux distributions, nftables is the underlying framework. An equivalent minimal ruleset looks like this:

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif lo accept
    ip saddr 203.0.113.10 tcp dport 22 accept
    tcp dport { 80, 443 } accept
    icmp type echo-request limit rate 5/second accept
    icmpv6 type { echo-request, nd-neighbor-solicit, nd-neighbor-advert, nd-router-advert } accept
  }
}

The address 203.0.113.10 is a documentation placeholder; replace it with your own. Note the IPv6 lines: if your server has an IPv6 address, your rules must cover it too. A common mistake is a careful IPv4 ruleset with IPv6 left wide open. Also be aware that container tools such as Docker can insert their own rules, so published container ports may bypass what you expect from ufw. Check the documentation for your container runtime.

Web application firewalls and what they catch

Network and host firewalls cannot see inside an HTTPS request. They know a connection arrived on port 443, but not whether it carries a SQL injection attempt or a request for a sensitive file. A WAF terminates or inspects HTTP traffic and applies rules to the request itself.

Common WAF options

• CDN or edge WAFs provided by content delivery and DNS proxy services. They filter traffic before it reaches your origin and often include rate limiting and bot management.
• ModSecurity with the OWASP Core Rule Set, an open-source combination that runs with Apache, Nginx or other proxies.
• Application-level security plugins for platforms such as WordPress, which understand the application but run on the same server they protect.

Tuning matters

WAF rules can produce false positives, blocking legitimate form submissions, API calls or editors saving content. Start in detection or logging mode, review what would have been blocked, add targeted exclusions, then switch to blocking. If you put an edge WAF in front of your origin, also restrict the origin so it accepts web traffic only from the provider’s published IP ranges; otherwise attackers can bypass the WAF by connecting to your server’s IP directly.

Firewalls, DDoS and brute-force traffic

A host firewall cannot absorb a large distributed denial-of-service attack, because the traffic saturates your network link before your rules ever see it. Volumetric protection needs to happen upstream, at your hosting provider, a CDN or a dedicated mitigation service. Our guide on preventing DDoS attacks on your website covers that side in more detail.

Firewalls are effective against smaller nuisances. Tools such as fail2ban read logs and add temporary block rules for addresses that repeatedly fail SSH or login attempts. Rate limits on login endpoints, either in the web server or at the WAF, slow down credential stuffing. These measures work best combined with key-based SSH authentication and multi-factor login for admin panels.

Logging, monitoring and change control

A firewall you never look at gradually drifts away from what you think it does. A few habits keep it honest:

1. Log dropped traffic at a sensible rate. Logging every dropped packet floods disks; rate-limited logging shows patterns without noise.
2. Document every rule. Add comments explaining why a port is open and who requested it. Many tools support rule comments directly.
3. Keep rules in version control. Store nftables files, cloud security group definitions or infrastructure-as-code templates in a repository so changes are reviewed and reversible.
4. Review on a schedule. Quarterly is a reasonable starting point for small teams. Remove temporary rules, old office IPs and ports for retired services.
5. Scan yourself from outside. Run an external port scan against your own server, with permission and only on systems you control, to confirm that what is reachable matches your intended policy.

nmap -Pn -p- your-server.example

Where firewalls fit in the bigger security picture

Firewalls protect the server, but your site also depends on things outside it: the domain registration, DNS records and TLS certificates. If a domain expires or a registrar account is taken over, the best firewall in the world will not keep your site online. It is worth tracking those assets alongside server hardening. With TLDix you can monitor domain and SSL expiry dates in your domain panel and check where a site is hosted with the hosting lookup tool, which helps confirm that DNS really points at the protected server and not at an old, unhardened one.

Related reading: how to implement HSTS and why regular malware scanning matters.

A quick firewall checklist

• Default policy for inbound traffic is deny.
• Only ports 80 and 443 are open to the world on a pure web server.
• SSH and admin panels are limited to known IPs or a VPN.
• Databases and caches listen on localhost or a private network.
• IPv6 rules mirror IPv4 rules.
• Origin servers behind a CDN or WAF accept web traffic only from that provider.
• Rules are commented, version-controlled and reviewed regularly.
• An external scan confirms the expected exposure.