What a stateless filter cannot do, and the rule that does it

Can a stateless filter block all outside hosts from opening a connection?

The honest answer is yes — for connection initiation. It is a common mistake to say no, and it costs marks.

Here is why it works. In TCP, exactly one segment opens a connection: the one with SYN set and ACK clear. Every other segment in the conversation carries ACK, because it is acknowledging something. So initiation is not something a filter has to infer — it is a flag combination visible in a single packet, which is exactly the kind of thing a stateless filter is good at.

Suppose an internal web server sits at 192.168.7.56 and policy says no outside host may open a TCP connection to it. The ruleset is four lines:

1. deny inbound to 192.168.7.56, TCP, SYN set and ACK clear;
2. permit inbound to 192.168.7.56, TCP, ACK set — these are replies to connections the server itself opened outbound;
3. permit outbound from 192.168.7.56, TCP;
4. deny everything else.

Rule 1 is the whole answer to the question. Rule 2 is what keeps the server usable: without it, blocking initiation would also break the server's own outbound sessions, since their replies arrive from outside. Rule 4 states the default policy.

And here is what it cannot do

Rule 2 trusts the ACK bit. A stateless filter has no memory, so when a packet arrives with ACK set it has no way to ask which connection? An attacker who forges an ACK-set segment aimed at 192.168.7.56 gets past rule 2 even though no such connection ever existed. Nothing is established by the forgery — TCP will drop it, and the attacker cannot complete a handshake this way — but the packet reaches the host, which is precisely what the firewall was supposed to prevent, and probing and stack-level attacks live in that gap.

So the accurate answer to the assignment question is in two parts: a stateless filter CAN block connection initiation with the SYN/ACK test, and it CANNOT verify that an ACK-set packet belongs to a real connection. Give both.

Stateful inspection — the table that closes the gap

The deeper reason state was invented is arithmetic. In a client/server session, the server port is well known and below 1024, but the client port is chosen dynamically between 1024 and 65535 and matters only for that connection's lifetime. A stateless filter therefore has to leave the entire high-port range open inbound for TCP to work at all. That is a very large hole to defend with a flag test.

A stateful inspection firewall keeps a directory of established connections — source address, source port, destination address, destination port, connection state — with one entry per live connection. An outbound SYN creates an entry; an inbound segment is admitted only if it matches one. The high-port range is no longer open; it is open per connection. Some implementations go further, tracking sequence numbers to frustrate session hijacking, and inspecting a little application data for protocols like FTP so that a related data connection can be recognised and admitted.

The two gateways

A stateful filter still never reads the application data. Two more types do.

An application-level gateway, or application proxy, relays traffic at the application layer. The client talks to the gateway, the gateway authenticates the request and opens a second connection of its own to the real server, and it relays application data between the two. The two spliced connections are the point: the gateway is a participant, not a bystander, so it can read and rewrite what passes. Consequences worth remembering:

• If the gateway implements no proxy for an application, that service simply cannot cross the firewall. Default-deny by construction.
• It is more secure than a packet filter because it only has to scrutinise a few allowable applications instead of reasoning about every combination of addresses, ports and flags.
• Application-level logging and auditing are easy, because the gateway sees the request, not just the packet.
• Its cost is processing overhead on every connection, in both directions.

A circuit-level gateway also splices two TCP connections, so there is no end-to-end connection either — but it relays segments without examining their contents. Its entire security function is deciding which connections to allow. A common arrangement trusts inside users: application-level proxying inbound, circuit-level outbound, so the expensive inspection is paid only on incoming traffic. SOCKS (v5, RFC 1928, TCP port 1080) is the named implementation, described as a shim between the application and transport layers.

So, in one line each: a packet filter reads one packet; stateful inspection reads one packet plus a table of connections; an application gateway understands the protocol and terminates both sides; a circuit-level gateway terminates both sides but understands nothing.

Host firewalls and ufw

A personal or host-based firewall is a software module on the machine itself — netfilter on Linux, pf on BSD and macOS, Windows Firewall — or, in a home, a function of the router. Its default posture is all inbound connections denied except those explicitly permitted, outbound generally allowed, and it also watches outbound activity for signs of worms and malware. On Linux, ufw is a front end to netfilter, and the same two decisions apply.

Worked example. Policy: only hosts on the local network may reach TCP port 80 on this machine. Two commands, and the order in which you think about them matters more than the order you type them:

sudo ufw default deny incoming
sudo ufw allow from 192.168.0.0/16 to any port 80 proto tcp

The second line is the rule everybody writes. The first line is what makes it mean anything. With default allow incoming, the permit rule adds nothing at all — every host on the Internet could already reach port 80, and the rule merely restates permission that was already granted. The default policy carries as much of the security as the rule does. Adapt the CIDR block to your own network (192.168.0.0/16 covers the private range; 192.168.1.0/24 is one typical home subnet) and the port to your service, then confirm with sudo ufw status numbered, which prints each rule with the index you would use to delete it.

Web proxies — the security case and the enforcement problem

A web proxy is an application-level gateway for HTTP, and it is worth being precise about what it buys.

The security case. All outbound web traffic passes one place, so there is a single point of control and a single log covering every request the organisation makes. Because the proxy terminates the connection, it can inspect content — scan downloads for malware, block categories or specific URLs, strip active content. It can authenticate the requesting user, tying a request to a person rather than an address. It hides internal addresses from the sites being visited, so external servers see only the proxy. And it caches, which is a performance benefit that also reduces the number of external fetches an attacker could observe.

The enforcement problem. Every one of those benefits assumes all web traffic actually goes through the proxy, and that assumption is the hard part:

• Users can reconfigure their browser to bypass it, or use an application that ignores the system proxy setting entirely.
• Direct routing to port 80 or 443 defeats it, as does a service on a non-standard port.
• HTTPS limits what an intercepting proxy can see, and certificate pinning breaks TLS interception outright for the applications that use it.
• Non-HTTP tunnels — a VPN, SSH forwarding, DNS-over-HTTPS — carry web traffic inside something the proxy does not handle.
• Personal and BYOD devices, and a phone acting as a hotspot, are not managed at all.

The technical answer is a network-level default deny on egress: the boundary firewall permits outbound 80 and 443 only from the proxy's address, so a client that tries to go direct is simply dropped, and transparent interception redirects the rest. The administrative answer is managed device configuration and an acceptable-use policy, because the technical control stops at the edge of the devices you own. And TLS interception must be argued honestly: it restores content inspection at the cost of the organisation reading its employees' encrypted traffic, and of installing a certificate authority on every device — a real privacy cost, a real new target, and in some jurisdictions a legal question.