If you do not configure ports and policies correctly, the firewall will not protect your environment as it should. But which ports should you block, and how should the firewall rule configurations be? This is a question every system and network administrator asks themselves from time to time.
When it comes to safeguarding new or current firewall rules, firewalls have a sensible procedure to follow. Whether you’re upgrading hardware or establishing a whole new environment, the order of the procedures will differ.
Before we move on to firewall rule configuration best practices, let’s look at how firewall rules work:
Firewall access policy rules provide access control because they define which packets are allowed and denied. A firewall access policy consists of a set of rules. First, each package is analyzed from top to bottom, and its items are compared to items in the policy rules. Then, the configured action of the first rule that matches the packet is executed, and all the steps specified in the configured options of the rule are performed.
Each firewall rule has a standard set of rule elements against which packet properties are compared. These rule elements, displayed as fields in the rule, include the packet’s source address (Source), destination address (Destination), protocol and port numbers (Service), interface through which it passes (Interface), the direction of travel (Direction), and time of arrival (Time).
For example, suppose a packet entering the firewall has a source address that matches the object in the Source field of the rule. The destination address matches the Target domain object, the protocol and port numbers match the Service domain object, and the interface it travels through matches the Interface domain interface object. The firewall takes and executes the actions specified in the Action field. A field with a value of “Any” or “All” will match all packages for that rule item.
By default, a rule matches the specified Source, Destination, and Service rule elements that match all interfaces and traffic directions. If you want to limit the rule’s effect to specific interfaces or traffic aspects, you must specify the restriction in the rule.
- You can match a packet to a rule using the Source and Destination rule elements based on the packet’s source and destination IP addresses.
- The service rule item maps packets based on the packet’s IP service as defined by the protocol and port numbers.
- The interface rule element maps packets according to the firewall interface they transit.
- The direction rule element matches a packet’s direction as it traverses the interface. There are three traffic direction settings for policy rules:
- Inbound direction corresponds to traffic entering through a firewall interface.
- The outbound direction matches traffic, leaving a firewall interface.
- The direction of both matches the traffic entering or leaving the firewall.
- Action is performed on a matching rule in the Source, Destination, Service, Interface, Direction, and Time fields. A policy rule action can be any Accept or Reject action type.
What Are the Best Practices for Firewall Rule Configuration?
When establishing a firewall, you should follow the best practice of least privileges, which implies banning anything that isn’t used for a specified and allowed business function. The least privilege lowers your risk, offers you more control over your network traffic, and restricts cross-network communication.
1. Document your firewall rules
Anyone working on your network security team should be able to very quickly tell from your documentation what each of your firewall rules wants to do. As a minimum, you need to keep track of the following data:
- Purpose of firewall rule
- Services it affects
- Affected users and devices
- The date the rule was added
- When the rule will expire if the rule is temporary
- The rule’s creator’s name
Likewise, you can use categories or section titles to group similar rules together. This way, you can determine the best order for your rules.
As you begin to fine-tune and optimize your firewall rules, go over your current ones and make sure you have all the appropriate paperwork for each.
2. Create a change procedure for the firewall configuration
Before you start changing any of your existing firewall rules, if you don’t already have a change management process, you should create a formal process that you will use for any changes. The following steps may be included in a standard change procedure:
- A change request method for business users to seek firewall configuration changes.
- An evaluation process where the firewall team analyzes the risk and determines the best course of action to balance the needs of business users with their security needs
- A procedure for ensuring that any modifications to firewall rules have the intended result.
- A deployment process to move the new rule into production after testing
- A verification process to ensure new firewall settings are working as intended
- A system for keeping track of the changes that have been done.
If your security team is small, it may be tempting to make changes informally. However, strict monitoring of the change process will help prevent security disruptions caused by poor firewall configuration.
3. Use least privilege policies
Make firewall rules as strict as possible regarding match criteria and allowing traffic. For example, allow only your organization policy and deny all other traffic. This applies to both ingress and egress traffic, i.e., traffic from the Internet to internal sources and traffic from internal sources to the Internet. The least privileged security policy helps minimize the attack surface, making other controls more effective.
To correctly manage the number and type of firewalls, it is recommended to keep them as small as possible. In addition, depending on the risk factor, it’s good to standardize your firewall policies. You can use central management and monitoring tools to achieve this.
It’s also essential to ensure you have appropriately trained and dedicated personnel. Finally, regardless of the advent of new security technologies, remember that firewalls are still the gateways to your network.
4. Monitor network traffic with Monitoring Mode
Monitor current traffic using IP addresses and ports and verify that they are required. Remember that not everything necessitates the use of the Internet. You can determine this by creating a propagation port or looking at old firewall logs if you’re replacing a firewall. Compile a list of source IP, destination IP, and destination port and start grouping them into categories for easier firewall rule creation.
5. Don’t Use Any/Any Rule
Deny all create the first inbound and outbound firewall rule and last processed. This firewall rule is also known as “Explicit Deny” it ensures that any rules created after initial rejections are fit for purpose.
6. When it comes to rules, be specific and purposeful
Establish separate groups of IPs and ports that make sense if possible. Grouping will enable you to establish a set of firewall rules and, in most cases, use groups to add and remove individual components.
Make sure your rules specify the destination and source IP addresses, or sometimes ranges, and destination port whenever possible. E.g.:
- Custom applications accessing and writing to the database over port 1433 (MSSQL). In a rule like ‘Explicit-Deny,’ this group of IP addresses can be added to another group. When you want to make sure that specific devices do not have internet access, even if they are unintentionally joined to other groups.
- Financial systems and wire transfer endpoints are high-value targets. Opening only required ports only to external websites and IP addresses that are needed make these endpoints harder to hack.
- Grouping external financial services will allow this group to be used elsewhere if other desktops or groups need special access. Restricting with port 443 ensures that if something in the external service turns to a less secure protocol, you can plan accordingly and be aware of the change.
- Endpoints joining an Active Directory domain have their required ports to get past the firewall.
- Every host should use your internal DNS and not use another random internet DNS server. Default denial should take care of this because you will only allow port 53 to a group of DNS servers.
The network access rules you apply should be as detailed as possible. This method follows the concept of least privilege and imposes network traffic control. As a result, include as many parameters in the rules as possible.
In the rule that defines network access, include as many parameters as feasible. Unfortunately, there are only a few occasions when any of these areas would be helpful.
7. Use address and service sets whenever possible
Address sets simplify the management of firewall policies. A security policy allows you to extensive group collections of objects to treat them as a single object. Because most companies contain logical items that may be grouped, the more rules you can reference to address sets, the easier it is to make adjustments.
For source and destination addresses, use single prefixes. Instead of using /32 addresses and manually adding each address, create a big subnet that covers most of the IP addresses you require. Also, because IPv6 addresses take up more RAM, utilize fewer of them.
Firewall policies may be managed more efficiently with service sets. They let you group huge groups of things in a security policy and treat them as single entities. Use the “any” service whenever possible. Each time you define a service in the policy, you can use additional memory.
8. Use Drop Rules
Place any drop rule under the context of each security zone, along with a general policy, to ensure that unsolicited traffic does not infiltrate through a security policy. This doesn’t mean you shouldn’t define your firewall rules; it just provides a catch-all mechanism to capture unclassified traffic.
It’s a good idea to block all inbound traffic to the network by default. Significantly, you should only offer access to certain known services to specific traffic. As a result, you gain command control over who has access to your network.
9. Protect the Perimeter
Never leave open remote management directly from the Internet. Instead, specify down to IP addresses and use centralized authentication with multi-factor authentication (MFA) whenever possible. Check your public IP addresses regularly.
10. Review firewall rules regularly
Your network and firewall rules are constantly changing. New users and new devices are being added to your network. These users and devices are accessing new apps and new services. And apps and devices that once made up a high percentage of network traffic may become much less popular over time.
All these changes may mean you need new firewall rules or delete some firewall rules that are no longer required. Nevertheless, your firewalls are crucial to a reactive approach.
You don’t want to update your firewall rules under duress because you’ve been hacked or people are moaning about how slow the network is. Instead, it is much better to establish a regular maintenance schedule to make changes proactively.
11. Remove unused or conflicting firewall rules
As you review your list of firewall rules and update your documentation, you may find that you have multiple rules that serve the same purpose. Therefore, it is possible to speed up your network by eliminating one or combining many rules to make them more effective.
Similarly, you may discover that some of your rules are never enforced since none of your traffic satisfies the rules’ specific criteria. Again, consider whether the rule is vital. If not, deleting it may lead to performance improvements.
12. Check your firewall logs
Every firewall has reporting features built-in that provides information about your traffic. Another firewall guideline is to review these logs regularly for any changes or anomalies that might indicate that your firewall settings need to be adjusted.
This log data will be an essential source of information regarding which firewall rules are used the most and which aren’t. Both types of information are critical to optimizing your firewall.
Log data can also identify “false positives” in traffic that should not be triggering security controls but are. Changing your firewall rules can help reduce these false positives and improve service to end-users.
Which Ports on Your Firewall Should You Block?
Depending on the brand and type of your firewall, as well as whether you’re utilizing hardware or software-based solutions, the specific steps for altering your firewall settings will differ. But whatever technology you use, following the firewall guidelines below can help you maximize the effectiveness of your solution.
For those looking for a list of ports to block, the SANS Institute recommends at least blocking outbound traffic using the following ports:
- MS RPC TCP, UDP Port 135
- NetBIOS/IP TCP, UDP Port 137-139
- SMB/IP TCP Port 445
- Trivial File Transfer Protocol (TFTP) UDP Port 69
- System log UDP Port 514
- Simple Network Management Protocol (SNMP) UDP Port 161-162
- Internet Relay Chat (IRC) TCP Port 6660-6669
A firewall is a crucial component of the security stack, but deploying a firewall is not enough protection for a business. Threat actors can easily bypass a firewall using various techniques, such as social engineering and application exploitation.
Dangerous Firewall Rule Configuration Examples
When you change a firewall configuration, it’s essential to consider potential security risks to avoid future problems. Of course, security is a broad topic that varies depending on the situation, but this article explains how to set up perimeter firewall rules.
- Allow IP ANY ANY – Allows all traffic on any port from any source to any destination. Broad definition firewall rules are the worst type of access control rule. Denying traffic by default contradicts security concepts and the principle of least privilege. The destination port should always be specified, and the destination IP address should be set when appropriate. The source IP address must be specified unless the application is built to receive clients from the Internet, such as a web server. Allowing TCP of any WEB-SERVER HTTP is a solid general guideline.
- Allow IP to ANY WEB SERVER – Allows all traffic to a web server from any source. Only specific ports should be allowed. In the case of a web server, it is appropriate to allow ports 80 (HTTP) and 443 (HTTPS). Allow ANY WEB-SERVER HTTP is a solid general rule to follow.
- TCP ANY WEB-SERVER 3389 – Allows RDP access to the webserver from any source. Allowing anyone to access your management ports is a dangerous practice. Be clear about who has access to server administration. Allow TCP IP 3389 WEB-SERVER as a basic guideline. (IP is the administrator’s computer’s IP address on the Internet).
- TCP ANY DB-SERVER 3306 – Permits MySQL to connect to the database from any location. The full Internet should never be exposed to database servers. If you need database queries to be run over the public Internet, specify the complete source IP address. Allowing TCP IP DB-SERVER 3306 is a decent rule of thumb. The best practice would be to enable database traffic over the public Internet over a VPN and not in cleartext.