The Ins and Outs of Bi-directional Firewall Rules

When I look at firewalls rule sets maintained by other companies, I often notice the same common mistakes. The one I see most often is potentially the worst. I can speculate on a number of reasons how these rules actually get defined and implemented, but it all comes down to the same thing.  They way traffic is evaluated and processed by a firewall is not always understood correctly.  The result is a rule that looks like this.

The thinking being that the client needs a way to connect to the web server and that the web server needs a way to connect back to the client.  Let me explain why this rule is bad and some of it unnecessary.

Dissecting a Firewall Rule

The very essence of a firewall is to limit or restrict unwanted traffic, it does this by evaluating specific criteria. At its most basic, a firewall rule consists of 5 objects:

• Source IP address
• Source Port
• Destination IP address
• Destination Port
• Protocol

For a TCP rule such as HTTP, the following three step handshake applies:

1. The source or client  is the computer initiating the conversation with a SYN packet. A port is dynamically allocated on the source machine and the request is sent to the destination on the predefined static service port.
2. The destination or server is the computer receiving the SYN conversation request on the specified static service port. The destination machine sends back a SYN-ACK packet.
3. The client machine receives the SYN-ACK packet from the destination and sends back a final ACK packet.

This completes the three-way handshake. At this point you have a TCP socket or conversation pair.  During the lifespan of the socket, the port number on the source and destination will not change.  This socket is now a two way pathway or channel through which traffic moves between client and server.

Example scenario

To use a very simple example, let's look at the firewall rule required to allow a Source or Client machine to request a website from a web-server or destination:

Allow   to

This would allow the client to initiate the conversation and receive the data back.  There is no need for a second outbound rule to allow the web server to talk back to the client.

This is because there is an existing socket that can be, and is used. It is a reasonable mistake to assume you need a rule to allow the traffic back to the client.  The rules would look like this:

The Inbound rule is correct as it allows for the client to initiate the two way conversation. The outbound rule is not required at all and actually opens up undesired access.  The Managed Server Computers can now initiate connections to the external network and surf the Internet, which is not intended or required.

Inexperienced administrators may also simply combine the two rules resulting in the first example at the top of this article. In this scenario you actually have the following access:

• External to Managed Server Computers
• Managed Server Computers to External
• External to External
• Managed Server Computers to Managed Server Computers

This really is not the desired outcome, and this is why it is such a bad access rule.  All that is required is the correct inbound rule to initiate and establish the conversation socket.

When you need bi-directional firewall rules

Of course, bi-direction firewall rules may be required for certain situations when either side needs to initiate a connection.

For example, there may be a requirement for computers in the Managed Servers Computers group to initiate conversations with each other to communicate heartbeat or load balancing information.  If there is no internal route for this traffic, such as servers located both inside and outside the DMZ segment, then a Bi-directional rule is needed

That bi-directional rule firewall, if indeed required, would look like this:

I like the think of these bi-directional rules as symmetrical rules, where the requirement on the source and destination are the same.

Having considered all of the criteria and applying the logic above, the requirements can be met with these two simple rules.

Conclusion

Understanding how traffic flows and is processed by a firewall is very important when requesting or implementing firewall rules.

Extra care should be take when the source and destination are not single computers or IPs as computer groups or network objects can significantly change the scope of the rule.

If are still not sure how a rule will impact your network, break it into multiple rules and track their use (or non-use) with tools such a TMG Reporter or Webspy Vantage.  They are not only great at reporting, they can really help tighten up security rules by giving you full visibility of firewall rule activity.