How does inbound port blocking work on a firewall?

Question

Something is unclear to me about inbound traffic and firewalls.

My first assumption is that a firewall - say for a home router - should block all inbound ports. If you don't block all inbound ports, then surely hackers on the Internet can send packets to the devices on your network?

But if all inbound ports are blocked, how does any traffic get in?

For example, my understanding is that a browser sets up a connection to a web server - talking to port 80 on the web server, and some randomly assigned port number on the browser/client end - say for example port 30222. Browser asks for a page, web server sends it back addressed to the clients ip address/port 30222.

If the web server can send data to port 30222, then why couldn't any random hacker send data to port 30222?

How does the firewall view this? Should it be configured to permit all inbound connections?

I understand that there are stateful firewalls that examine the connection request from the client and can therefore selectively allow traffic on precisely that combination of client/port -> server/port - that make sense. In that context I can see you could block all inbound firewall ports on the home router because the home router is able to ensure traffic that it lets in is only between devices for a connection initiated internally - it is not possible in such context for a random hacker to send packets to a device on the internal network.

BUT - I don't think all firewalls are stateful are they? What about non-stateful firewalls - do they require allowing all inbound traffic?

So it is not clear to me if a home firewall should block all inbound ports or not. And if it does block all inbound ports, how does any data get in if it is not a stateful packet inspection firewall?

Answer 1

The term firewall is loosely defined. My answer to your question is that not all firewalls are stateful. However, I might use the term "packet filter firewall", to describe one type of stateless firewall. For a stateless firewall, there is still a lot of protection that can be achieved but not as much as a stateful firewall.

For example, a stateless firewall could be told to let all packets go out to the Internet (e.g. your web browser packets going to the web server). But it would be configured to only allow packets inbound if they appeared to be part of an already established connection. For this we get into the details of how TCP/IP works. There are flags (SYN, SYN+ACK, ACK in case you wanted to look them up) in the TCP packet which indicate if a packet is an initiating packet or a response packet. The stateless firewall would only allow response packets back into your client browser. Could a bad guy on the Internet simply send a packet that looked like a response (i.e. had the response flag set) back to your client? Yes. However, it's unlikely that your client would accept that connection even if it got past the packet filter firewall. This is a very basic answer and I'm skipping over many details and scenarios but hopefully it provides the level of detail that you were looking for.

In this above context, we are using the term "stateful" and "stateless" to describe what the firewall is keeping track of. Stateful means that once the first packet from your browser gets to the firewall, the firewall notes that a web connection is being activated and the firewall is then expecting the response packet from the web server. It keeps tracking information for the duration of the connection. In a "stateless" scenario, the firewall evaluates each packet as they pass through it but does not keep track of anything in between. The TCP/IP connection has "state" information inside of it (e.g. the flags) regardless of whether the firewall is keeping track of it or not.