Firewalls are one of the most common defense mechanisms in modern cybersecurity models. From the most seasoned professional to new IT technicians, they have all encountered firewall rules or policies at some point in their career. No matter the vendor, firewalls follow the same general concept of allowing or denying traffic, from a source to a destination, on a certain protocol. All too often, however, simplicity outweighs security best practices, and rules are written in a manner that expose organizations to risk. Whether rules are for inbound, outbound, or for internal network communication, it is important for organizations to narrow their firewall rules to allow only traffic that is necessary and approved.
In this short series on firewall rules, we will review a few scenarios that may help to strengthen the security posture in your organization. We intend to shed light on the pitfalls of firewall rules that are written too broadly in what they allow and provide recommendations to tighten down these rules to improve your organization’s security posture.
Note: This is not an exhaustive list of all best practices relating to firewalls, but just touches on one of the most common issues with lax firewall rules.
Example 1: “The Outbound Trap”
Let’s take an example of an outbound traffic rule:
Rule: From = Inside Interface, To = Outside Interface, Source = All, Destination = All, Protocol = All
This example is something that we have found to be prevalent among production firewall configurations across many business segments. The basic premise here is to allow any device in your network to communicate with any device outside your network as long as the request is initiated internally. Some organizations have the mindset that their network is trusted and anything going outbound is safe; one of the primary problems with this line of thinking is that even though an organization may “trust” what’s on the inside, they shouldn’t.
There are two reasons for this:
- First, with the expanding world of BYOD and IoT, organizations may already have an infected device on their network and not know it, unless they are controlling who joins their network via a network access control (NAC) solution. For brevity sake, we will cover NAC on another blog post.
- Secondly, in some cases, malware on an infected device will attempt to communicate outbound to a command and control (C&C) IP, letting an attacker know that the malware was successfully installed. In other cases, when the internal firewall rules are too wide-open, the attacker can gain a foothold and move laterally throughout the network. Once they gain access, they can begin exfiltrating data, carry out a ransomware attack, or even lay dormant until they decide they want to act.
Addressing “The Outbound Trap”
So, how do we fix the problem in the example above? One way is to have multiple outbound traffic rules that limit traffic, based on source address(es), destination address(es), and function. For example, if an organization utilizes a public DNS resolver for name resolution, they could write a rule to allow traffic destined to the IP of the DNS resolver on TCP and UDP port 53. This same concept can be applied to many other protocols like NTP, SMTP, HTTP, HTTPS, etc. The idea is to try to limit the sources, destinations, and protocols to only what is needed for the organization.
This task of limiting traffic, however, is easier said than done. The task often requires the firewall administrators to work closely with other groups within the organization to understand how applications communicate.
Another helpful method in tightening firewall rules is to look at your existing traffic logs prior to embarking on narrowing down your rules. This will allow you to see what devices on your network are communicating with one another and the protocols these devices are using. It can be particularly helpful if your firewall allows filtering for certain protocols so you can exclude some from the view as you account for them.
Additionally, the more your teams can work together to understand where traffic needs to go, the better. For example, organizations may determine that international outbound traffic is not necessary for business. This information will allow a firewall administrator to insert a policy blocking outbound traffic to other countries.
Of course, tightening down firewall rules doesn’t only apply to outbound rules. In the next segment of this series, we will look at an example for configuring inbound rules to properly build a stronger defense.
VENYU is here
As always if you have additional questions, would like someone to review your firewall settings with you, or need assistance with a change, please open a support case using the customer portal.
