by
Etienne Liebetrau
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.
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:
For a TCP rule such as HTTP, the following three step handshake applies:
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.
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:
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.
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.
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.
Download our FREE 30-day trial, or schedule a demo and we'll show you how it works.
How to Enable Dark Mode in Fortinet FortiGate (FortiOS 7.0)
Sophos XG - How to Block Searches and URLs with Specific Keywords