Firewall Rule Configuration Best Practices For PCI Compliance

When changing a firewall configuration, it is essential to consider potential security risks to prevent future problems. Protection is a complex issue and can vary from case to case, but this article outlines best practices for configuring firewall rules on the environment.

See Also: Firewall Rule Configuration Best Practices

Security administrators must strike a balance between the need for robust security and the need for fast performance when configuring network firewalls. Tuning and optimizing your firewall rules can help your firewall achieve the ideal balance between speed and security.

See Also: PCI DSS Firewall Requirements

In firewall rules, the action component decides whether traffic is allowed or not. It has a match feature action. For example, if the traffic matches a rule’s components, it is allowed to connect to the network.

It is essential to consider potential security risks when changing the firewall rule to prevent future problems. Best practices for configuring firewalls can help you maximize the effectiveness of your solution.

What are the Considerations for Firewall Rule Configuration?

Rules and policies are crucial to firewall performance. An organization typically has thousands of firewall rules, and not all of them are mutually exclusive. Most firewall rules have a direct effect on another set of rules.

As a result, even the simplest mistake can trigger a massive security loophole that allows malicious traffic to sneak in or block legitimate traffic and interrupt regular business. Therefore, it is essential to frame and adhere to robust firewall policy best practices.

See Also: Best Practices for Clean Up Your Firewall Rule Base

The process of adding, deleting, or changing firewall rules should be well planned so that the performance of the existing ruleset is not adversely affected. Not only that, but the current rule set needs to be continually optimized for speed and performance based on this carefully framed firewall rule core security best practices.

See Also: Firewall Security Controls Checklist

Certain features of a firewall need to be continuously monitored and optimized. If these are mismanaged, your network will be vulnerable. To help you detect and fix vulnerabilities in your firewall, you should follow firewall best practices.

In any organization, wall configuration changes are vital to network security, and it is critical to streamline configuration changes and remove configuration gaps. It is also crucial to record all configuration changes in real-time and trigger notifications whenever a change is made.

Standard regulation powers such as PCI DSS, ISO, NIST, SANS, and NERC help security administrators evaluate network security from a firewall configuration perspective.

See Also: Firewall Audit Tools to Ease PCI Compliance

The exact procedures for modifying your firewall settings differ depending on the make and model of your firewalls, as well as whether you’re using hardware or software-based firewall solutions. However, regardless of the technology you use, following the best practices of the firewall rules mentioned below will help you get the most out of your solution.

Develop a Formal Procedure for Firewall Rule Changes

Examining the firewall change process is usually the first technical step in a firewall audit. The purpose of this step is to ensure that the requested changes are appropriately approved, implemented, and documented. You can analyze your firewall configuration settings with a helpful tool or manually.

See Also: Firewall Policy Guidelines

Firewall rules will need to be updated for any new services and devices to be added. A systematic change process should be developed for any new changes before implementing or modifying any firewall rules.

Some guidelines for the change process are outlined in the following steps:

• Run a change request process for users to request changes to a specific firewall configuration.
• Have a review process to analyze new changes and determine the best course of action for all security practices.
• Establish a testing process for new change requests for firewall production rules.
• Establish a process for commissioning new change requests tested in production.
• Establish a new firewall settings validation process to ensure proper operation.
• Document all changes.

It would be best if you also asked the following questions to manage your change process well:

• Is the change requester saved and allowed to make changes in the firewall?
• Are there documents related to the change for business reasons?
• Are there appropriate signatures for reviewers and approvals?
• Have the approvals been saved before the change?
• Are all approvers authorized to approve changes to the firewall?
• Are changes in the exchange ticket well documented?
• Is there evidence for every fix in the risk analysis?
• Is there any change window documentation or installation date for each change?
• Will the change have an expiration date?

Make Sure Your Firewall Is Secure

Securing your firewall is the first step in configuring and managing a secure firewall. Never allow your firewall to perform unsafe actions properly.

You can ensure the basic security of your firewall by taking the following steps:

• Disable the simple network management protocol (SNMP).
• Rename, disable or delete any default user account.
• Change all your default passwords.
• Create additional administrator accounts based on responsibilities, especially if multiple administrators will manage your firewall.

Firewall Audit Logs

A built-in reporting tool with detailed information about your traffic is included in every firewall today. The reporting tool will help audit logs find any changes or irregularities that might imply changes in your firewall settings. When optimizing the firewall, the logs’ data will show which firewall rules are not used and which are disabled.

Data from the logs also show all “false positives” about traffic that do not need to trigger security rules but do so in any way. Based on the reports’ information, you can change the firewall rules to reduce false positives and improve service.

Review Firewall Rules

Networks are constantly evolving as they gain new users and new applications and access to new technologies and new software that require new firewall rules. If possible, old rules in the firewall should be checked and removed. It is best practice to establish a routine maintenance schedule to allow revised adjustments to firewall rules.

See Also: Firewall Rule Reviews for PCI Compliance

Over time, the basics of firewall rules begin to expand and become problematic. They also include rules that are either partially or entirely unused or obsolete or shady. If many administrators have made changes or several firewalls in the company, the problem worsens.

When the firewall rule base grows and clutters, it starts to affect the firewall’s performance as well. When rules multiply, the firewall is challenging to maintain and can hide real security risks.

PCI DSS requests the following actions to clean up unused rules and objects:

• Delete any unhelpful and unused firewall rules.
• Delete expired firewall rules and objects.
• Disable unused connections and unused source/destination/service paths in firewall rules.
• Apply object naming conventions that make the firewall rule base easier to understand.
• Delete old policies that are not used. For example, remove duplicate objects, a service, or a network host with different names defined twice.
• Reduce the shading as much as possible.
• Divide long rules into legible sections with no more than 20 rules.
• Document guidelines, objects, and changes to policies for future reference.
• Strengthen permissive rules.
• Define and follow a compliance policy by region.
• Identify and reduce unsafe rules.

Make Sure Your Firewall Is Up To Date

Firewall devices should always have updated patches and firmware. If your firewall is out of date, it is vulnerable to attacks, and the firewall’s rules won’t work.

See Also: What are the PCI DSS Firewall and Router Configuration Requirements

When you update your firewall rules, it’s also a good time to make sure you have all the latest patches installed on your firewall. If your firewall has a known unpatched vulnerability, even the most extensive list of firewall rules in the world cannot stop the attack.

Firewall vendors usually release software updates regularly. These updates address any new potential security threats by making minor changes to the software. It is essential to keep updating your firewall software to ensure your network is secure and there are no potential security gaps in the system. You should check from time to time if your firewall software is updated to the latest version.

Add Block Rule by Default

Start blocking all traffic by default and allow specified services to only have limited traffic. By default, the block approach provides traffic quality control and reduces the likelihood of breaches. The default block behavior can be achieved by configuring the last rule to deny all traffic in an access control list. It can be made explicitly or implicitly, depending on the platform.

See Also: Firewall Rule Baseline Review and Security Checklist

Blocking all traffic by default and allowing only specific traffic to explicitly known services will enable you to accept only the requested and permitted traffic. This strategy provides reasonable traffic control and reduces the likelihood of a breach due to service misconfiguration.

Allow Certain Traffic

The rules you use to define access to the network should be as specific as possible. This strategy is the least privilege principle and enforces control of network traffic. In the rules, include as many parameters as possible.

The layer four firewall uses the following parameters for the access rule:

• Source IP Address
• Destination IP address
• Destination port
• Traffic protocol

In the rule used to determine network access, define as many parameters as possible. There are limited scenarios in which any of these areas are used. It would be best if you determined which ports your applications need to allow specific traffic.

Specify Source IP Addresses

If the service is accessible to anyone on the internet, the correct option is any source IP address. In all other cases, the source address must be specified.

It is acceptable to allow access to your HTTP server through all source addresses. However, it is not appropriate to allow access to your server management ports or database ports by all source addresses. Below is a list of common ports and database ports for server management:

• Server management ports:
  • Linux SSH: Port 22
  • Windows RDP: Port 3389
• Database ports:
  • SQL Server: Port 1433
  • Oracle: Port 1521
  • MySQL: Port 2206

Be clear about who can reach these ports. Suppose specifying source IP addresses for network management is impractical. In that case, you can use other solutions such as remote access VPN as a compensatory control to allow necessary access and protect your network.

Specify the Destination IP Address

The IP address of the destination is the server’s IP address running the service you want to allow access to. Always specify which server to access. Configuring the target value of either could result in a security breach or server compromise in an unused protocol that default can be accessed.

However, target IPs with any target value can only be used if an IP is assigned to the firewall. You can also use any target value if you want to access your configuration both publicly and from the service network.

Specify Destination Port

The service that can be accessed is represented by the destination port. This value should never be one of this field. The target port defines the service running on the server that needs to be accessed, and only this port should be allowed. Allowing all ports affects server protection by allowing dictionary attacks and vulnerabilities of any port and protocol configured on the server.

Avoid using an extensive selection of ports. When using dynamic ports, firewalls sometimes provide control policies that allow them to pass through securely.

First Set All Explicit Rules in Firewall

Set the most open firewall rules at the top of the rule base. Explicit rules are the departure point where the traffic matches. Firewall rule bases are rules designed to manage what is allowed and not allowed through a firewall.

Usually, firewall rule foundations work according to a top-down protocol where the first rule in the list executes its action first. This is done so that the rest of the rules do not evaluate the first rule’s traffic.

The following sequence is recommended for firewall rules enforcement:

• Anti-spoof filters
• User permission rules
• Rules regarding management permissions
• Noise drops
• Reject and warn suspicious traffic
• Deny and log traffic to analyze

Set Explicit Rules for Traffic Drops as a Cleaning Rule

The primary purpose of firewalls is to intercept all traffic that is not explicitly allowed. To prevent uninvited traffic from passing through the firewall, place a Cleanup Rule under each security zone background. The cleanup rule will provide an all-encompassing mechanism for traffic capture.

The cleaning rule for a firewall is defined as follows:

• Source = ANY
• Target = ANY
• Service / Application = ANY
• Action = DROP
• Logging = Enabled

Remove “Accept All” Rules

Accept all rules can cause traffic bottlenecks. This rule should not be a policy for firewalls.

Examples of Dangerous Firewall Configurations

Below are some risky examples of firewall rules. However, the examples below also show some useful alternatives to adopt when configuring rules for the firewall.

• Allow any IP – Enables all traffic from any source to any destination on any port. It is the worst form of the rule regarding access control, and the default denial of traffic conflicts with security concepts and the least privileged principle. The destination port must always be specified, and if possible, the destination IP address must be specified. If the application is configured to accept clients from the internet, the source IP address, such as a web server, must be specified. Any WEBSERVER HTTP that makes TCP is a strong rule of thumb.
• Allow IP to any WEBSERVER – Allows all traffic to a web server from any source. Only unique ports should be allowed; for example, in the case of a web server, you can define ports 80 (HTTP) and 443 (SSL) (HTTPS). Otherwise, server management will be vulnerable. A good rule of thumb allows any HTTP from WEB-SERVER to be attached as IP.
• Allow any WEBSERVER 3389 TCP – Enables RDP access to the webserver from any source. Getting everyone to access your management ports is a dangerous practice. Be clear about who can access the server.
• Allow any DB-SERVER 3306 TCP – Enables MySQL access to the database from any source. Database servers should never be fully public. If you need queries in the database to run over the public internet, provide the resource’s full IP address. A better practice would be to enforce database traffic via a VPN rather than over the public internet in plain text.