Is the TCP ACK bit set for things like HTTP responses?

Question

I read on this page that in TCP ACK bit filtering, only packets with the ACK bit set are allowed into a network, so that the firewall knows that those packets were requested by users within that network.

Okay, so I know that the ACK bit is set for TCP acknowledgement packets. But what else is it used for? What if users on the local intranet are requesting web pages? Will the ACK bit be set for the HTTP responses that contain the web pages requested by the users of the network? They would have to, or else the packets would be dropped by the firewall.

But HTTP and TCP work at completely different layers, so it doesn't make sense that TCP would be able to set the ACK flag for HTTP. I mean, how would it know that the packets are HTTP responses? But that's the only way I can think of that users on the local network would be able to use web services outside the network, because otherwise, the only thing the firewall would let into the network would be TCP acknowledgement packets, which are basically useless to the end user.

Can someone help me understand this? I'm very confused.

EDIT: I think my confusion stemmed from a misunderstanding of how TCP works. I thought that a separate TCP session was maintained for each message sent from one host to another, i.e. one TCP session for the HTTP request and another TCP session for the HTTP response. If this were the case, the ACK flag would not be set for the HTTP response packets, and they would be dropped. In fact, basically no useful application layer communication would be allowed into the network if this were the case. Thanks to this article, I now understand that a single connection is maintained for the entire session, including the request and the response.

Answer 1

But the problem is the ACK flag is only set on TCP acknowledgement packets, which do not carry any useful information as far as the end user is concerned, so if you only allow packets that have that flag set, you will drop all useful packets.

While ACK packets may not contain any useful data, the packets themselves are extremely useful. The ACK packet tells the other side of the connection "I received the data you sent and I'm ready for more." If the ACK is not received due to packet loss, a firewall blocking it, or any other reason, the connection sender of the ACK will keep resending that same ACK until the other side sends more data.

Now let's take a step back and discuss the Web server scenario you mentioned.

After the three way handshake completes the client will sends a request for a page. This would contain "useful" data because it tells the server what page the client wants. The server then sends an ACK to let the client know the request has been received. The server then sends back data packets which contain the requested page. The client then sends an ACK or ACKs to let the server know it has received all of the data which was sent.

Note that all of the above took place on a single TCP connection. In other words, both parties can send and receive data over the one connection, they do not need one each.

Finally, just an FYI, blocking traffic based on a TCP flag for security purposes is almost as weak as blocking on port numbers. The reason being that malicious users can craft packets any which way they like so sending all packets with the ACK bit set is no trouble at all. If you're interested in reading more about this take a look at Scapy.

Answer 2

You are right: HTTP and TCP are located at different layers. TCP will let a connection be established. When the connection is established streams are bidirectional.

The firewall will only work at the TCP layer anyway, so you can forget HTTP, completely.

Let's say you want your users to connect to the outside on port 80. You would let every IP datagram, protocol TCP, dst port 80 go to the outside. It isn't suffiscient as you must add a rule to let traffic go back from Internet to your network.

I would just let everything in but SYN only (SYN/ACK are ok). This documentation suggest letting only ACK packet return, which seems also quite correct to me (but not totally: FIN or RESET packets could be sent by the remote side first, without ACK as far as I know).

Remember that ACK is just a flag: the real data is in the TCP segment, so you would have your application data in it (here http).

Stateless filters are still in use for high traffic, low budget firewalls.