How Firewalls And WAFs Use Port Numbers To Filter Malicious Traffic
Table of contents
Firewalls use port numbers to decide which traffic is allowed to reach your server. If your website only needs HTTP and HTTPS, the firewall can allow ports 80 and 443, then block everything else.
A WAF, or Web Application Firewall, works one level deeper. It usually protects traffic coming through web ports like 80 and 443, but it does not stop at the port number. It looks inside the request and checks for things like SQL injection, cross-site scripting, strange URLs, bad headers, suspicious cookies, and abusive request patterns.
So the simple version is this:
A firewall asks, “Should traffic be allowed to reach this port?”
A WAF asks, “Now that this is web traffic, is the request safe?”
That is the main difference. Firewalls use port filtering to control access to network ports. WAFs inspect the web traffic that gets through.
How Port Numbers Help Firewalls Filter Traffic
When someone connects to your server, they do not just connect to an IP address. They connect to an IP address and a port number.
Think of the IP address as the building, and the port number as the door. Your website may use one door, your database another, your admin login another, and your email service another.
That is why port numbers matter. Every open port is a possible way into a system. If a service is exposed when it does not need to be, attackers can scan it, test it, and try to exploit it.
These are some common port numbers, but you do not need to memorize all of them. The important idea is simpler: public users should only reach the services they actually need.
If your database is not meant for public users, its port should not be public. If SSH is only for admins, it should not be open to the whole internet. I like to think of it as removing unnecessary doors instead of trying to guard every door at once.
What Port Filtering Actually Does
Port filtering is the firewall’s way of allowing or blocking traffic based on the port being used.
This is where firewall ports become practical. You are not trying to inspect every possible attack payload yet. You are first asking whether the traffic should even reach that service.
If someone tries to connect to your website on port 443, the firewall may allow it.
If someone tries to connect to your database on port 3306 from the public internet, the firewall can block it before the database ever sees the request.
That matters because the safest malicious request is the one your application never has to handle.
A good firewall setup usually follows a simple rule: allow only what you need, block everything else.
How WAFs Use Port Numbers Differently
A WAF also pays attention to ports, but mostly because it is focused on web traffic.
In most setups, a WAF protects HTTP and HTTPS traffic, usually on ports 80 and 443. If your website uses a custom web port like 8080 or 8443, the WAF needs to be configured for that too.
But the WAF’s real job starts after the traffic is accepted as web traffic.
This is why a WAF is not just another firewall. A normal firewall may see that traffic is going to port 443 and allow it. The WAF looks deeper and asks whether the actual request is malicious.
For example, this request may come through HTTPS on port 443:
/product?id=1' OR '1'='1
To a basic firewall, that may look like normal web traffic because it is using the right port. To a WAF, it may look like SQL injection, so the WAF can block it before it reaches your app.
Why Firewalls Cannot Block Every Web Attack By Port Alone
Your website needs port 443 open, because that is how people reach your site securely. But attackers can also send malicious requests through port 443.
So the firewall cannot simply block port 443. If it does, your real users are blocked too.
That means port filtering is powerful, but it has limits. It can block traffic to ports that should not be public. It cannot always tell whether allowed web traffic is safe.
The firewall handles the outside boundary: “Is this port allowed?”
The WAF handles the web request: “Is this request trying to attack the application?”
Both are needed because malicious traffic often hides inside normal-looking HTTPS traffic.
How Firewalls And WAFs Work Together
The clean setup is layered.
The firewall should keep unnecessary services unreachable. The WAF should inspect the web traffic that is allowed through. Your application should still validate input, require authentication, and enforce permissions.
You do not want to ask one layer to do every job.
If your database port is exposed to the internet, the WAF probably will not protect it because database traffic is not normal web traffic.
And if your website has a SQL injection issue, a basic firewall may not catch it because the attack may come through an allowed HTTPS port.
The firewall closes unnecessary doors. The WAF watches the main public door.
A Practical Setup For A Website
For a normal website, your setup should look something like this:
This setup prevents a common mistake: letting people bypass the WAF.
If your WAF protects your domain, but your origin server is still publicly reachable by IP address, attackers may skip the WAF and hit your server directly. Your firewall should block that by allowing traffic to the origin only from the WAF or load balancer.
Firewalls use port numbers to decide which services can be reached. WAFs focus on the web ports that are allowed and inspect the requests going through them. If traffic is trying to reach a service that should not be public, the firewall blocks it. If traffic is allowed through because it is web traffic, the WAF checks whether it looks malicious.


