What are Best Practices for Firewall Rules Configuration
A secure network is critical to a company's success. A network administrator must design a security policy that describes all of the network resources within a company and the required security level for those resources in order to safeguard the network.
Having a firewall security best practice guide for securing the network can help you explain your company's security policy goals to security stakeholders, assure compliance with industry laws, and improve your security posture overall.
When establishing a firewall, the best practice is to block everything that isn't being used for a specific and allowed business function. This lowers your risk, offers you greater control over your traffic, and restricts cross-network communication.
To get you started on your way to a stronger security posture, we described eight firewall rules configuration best practices below.
1. Set Firewall Rules
The most explicit firewall rules should be placed at the top of the rule base. This is where traffic is matched at the beginning. A rule base is a set of rules that governs what is and isn't allowed to pass through a firewall. In most rule bases, the first rule in the list executes the action first. This is done to ensure that the traffic allowed by the first rule is never subjected to the rest of the restrictions.
You can use the SANS Institutes Firewall Checklist as a model;
- Filters that prevent spoofing (blocked private addresses, internal addresses appearing from the outside)
- Permit Rules for users (e.g. allow HTTP to the public webserver)
- Permit rules for management (e.g. SNMP traps to network management server)
- Noise is reduced (e.g. discard OSPF and HSRP chatter)
- Alert and Deny (alert systems administrator about traffic that is suspicious)
- Log and deny (log remaining traffic for analysis)
Because firewalls work on a first-match basis, the above structure is critical for keeping suspicious traffic out rather than mistakenly allowing them in by failing to follow the appropriate sequence.
2. Set Explicit Drop Rules
Place an any-any-any drop rule at the bottom of each security zone context (for example, source zone to destination zone) coupled with a global policy to guarantee that unwanted traffic does not leak past the security policy. This does not negate the need to set firewall rules; rather, it serves as a catch-all method for unclassified traffic.
The cleanup rule for the firewall is as follows:
Source = ANY
Destination = ANY
Service / Application = ANY
Action = DROP
Logging = Enabled
3. Keep Audit Logs
Another recommended practice for firewall rules is to examine audit logs on a regular basis for any changes or anomalies that could indicate that your firewall settings need to be revised. Logging keeps track of all network activity, which is useful for troubleshooting and diagnostics.
This log data will be a valuable source of information about which firewall rules are utilized the most frequently, and which ones aren't used at all. Both sorts of data are necessary for firewall optimization.
Log data can also aid in the detection of "false positives", or traffic that should not be triggering security rules but is still doing so. Changing your firewall rules might help you reduce false positives and enhance end-user service.
If your network is particularly large or busy, you may require log analysis tools other than those offered by the firewall vendor to make sense of your log data. Artificial intelligence or machine learning skills are among the most advanced technologies, and they may help you notice vital details that you might otherwise overlook.
4. Block Default Traffic
By default, all traffic is blocked, and only particular traffic to recognized services is specifically enabled. This method gives you strong traffic management and decreases the risk of a breach due to a service misconfiguration.
This is accomplished by making the last rule in an access control list deny all traffic. Depending on the platform, you can accomplish this directly or implicitly.
5. Create Secure User Accounts
Access to your firewall's administrative console should be restricted to only those you trust. Make sure your firewall is guarded by at least one of the following configuration measures to keep out any potential attackers:
- Change all default passwords and delete, deactivate, or rename any default user accounts. Make careful to choose passwords that are both complex and safe.
- Create extra accounts with limited access based on responsibilities if the firewall will be managed by several persons. Never utilize a user account that has been shared. Keep track of who made what modifications and why they were done. Accountability encourages caution while making adjustments.
- To decrease your attack surface, limit where people may make modifications; for example, updates can only be done from trusted subnets inside your business.
- Set up multi-factor authentication (MFA) and/or a strong password policy (complex passwords with upper and lower case letters, special characters, and numbers, 12 characters or longer, prevent password reuse)
- For firewall administrators, use role-based access control (RBAC). Delegate and limit access based on the user's requirements (i.e., allow only read-only access
6. Specify Source and Destination IP Addresses
You should be as detailed as possible when defining network access restrictions. The idea of least privilege is used in this method, which necessitates network traffic regulation. In the rules, include as many parameters as feasible.
For an access rule, a packet filtering firewall employs the following parameters:
- IP address of the source (or range of IP addresses)
- IP address of the destination (or range of IP addresses)
- Port of destination(or range of ports)
- The traffic protocol (TCP, ICMP, or UDP)
In the rule that defines network access, provide as many parameters as feasible. There are just a few circumstances in which any of these fields are used.
Any source IP address is the best option if the service should be available to everyone on the Internet. In all other circumstances, the source address should be specified. When defining source IP addresses for network management is impracticable, you could consider a compensating control like remote access VPN to provide the access necessary while still protecting your network.
The destination IP address is the server's IP address that hosts the service you wish to authorize access to. Specify which server(s) are available at all times. The usage of any as a destination value might result in a security breach or server compromise of an underused protocol that is available by default. If the firewall has just one IP address, destination IPs with a destination value of any can be utilized. If you want both public and private network access to your configuration, you may use the value any.
7. Test the Firewall
To guarantee that new firewalls perform effectively, they should be tested and reviewed prior to deployment.
Testing should be carried out on a separate network from the production network. This test network should try to duplicate the production network as closely as possible, including network topology and network traffic passing through the firewall. The following are some of the aspects of the answer to consider:
- Application Compatibility
- Security of the Implementation
- Component Interoperability
- Policy Synchronization
Test your Firewall policy on a regular basis to ensure that it finds unused and duplicate items as intended. It can be difficult to imagine how a bigger security policy might handle a new link with a larger security policy. Path analysis tools are available, and rules searching and finding tools may be available in the security management system.
In addition, some security management systems issue a warning when a duplicate item is created or refuse to install a policy with a rule that conceals another object.
Top hit rules can be moved farther up in the inspection sequence to optimize firewall policies that are generally enforced in a top-down fashion. To improve your firewall's performance, examine the policy on a regular basis.
Finally, do frequent penetration testing to uncover any threats that may necessitate the implementation of extra security measures.
8. Update Firewall
Patches and firmware for the firewall device should be kept up to date at all times. If it isn't, it will be exposed to attacks, rendering the firewall rules worthless. If your firewall contains a known vulnerability that hasn't been fixed, the best set of firewall rules in the world won't stop an attack.
Many processes have gotten faster and easier due to technological advancements. Firewall administrators may not always be able to check for and install updates on a regular basis. As a result, security breaches are a possibility on the network.
You can automate the process instead to avoid any lapses in firewall updates. An automatic system can be set up to check for and install updates as they become available. This eliminates the need for manual intervention and ensures that the firewall is always secure and reliable.
What are Examples of Dangerous Configurations
This section explains several potentially problematic firewall rules, as well as some excellent alternatives to follow when establishing firewall rules.
- permit ip any any : Allows all traffic to go to any destination from any source on any port. The worst form of access control rule is this one. It goes against both the security notions of banning traffic by default and the least privilege principle. When possible, the target port should always be supplied, as should the destination IP address.
- permit ip any any WEB-SERVER1: Allows all traffic to a web server from any source. Only specified ports should be authorized, such as 80 (HTTP) and 443 (HTTPS) in the case of a web server (HTTPS). Otherwise, the server's management is at risk.
- permit tcp any WEB-SERVER1 3389: Allows RDP access to the web server from any source. Allowing everyone accesses to your management ports is a risky habit. Make it clear who has access to the server management.
- permit tcp any DB-SERVER1 3306 : Allows MySQL access to the database from any source. The entire Internet should never be accessible to database servers. Specify the actual source IP address if you need database queries to run across the public Internet.
In addition to those above explained you should limit which IP addresses are allowed access to the administrative interface.
Using non-standard authentication techniques puts your company in danger of a data breach. When you don't employ a conventional technique, you're relying solely on the competence of the person who set up the firewall, or, worse, the firewall's default settings. To provide your computer network security on a firmer basis, it's better to follow a recognized standard.
When employees try to log in from different devices and places without using a single standard authentication technique, difficulties can develop. A non-standard authentication technique, for example, could allow for weaker passwords or less stringent limits on the number of login attempts. As a result of these security flaws, attackers can get access to your network.
Allowing unneeded services to run on the firewall jeopardizes security. Dynamic routing and rogue DHCP servers, which distribute IP addresses and can cause IP conflicts, are common culprits.
The solution is to follow the idea of allowing the least amount of privileges necessary for the services to work once more. Allowing too many services to run has a negative impact on performance and increases network traffic, therefore configure devices based on the functions you need them to perform.
What kind of Rules does a Firewall Need?
In contrast to the above given dangerous misconfigurations you can apply the rules as follows:
- Unless the program is designed to receive clients from the Internet, such as a web server, the source IP address should be given.
permit tcp any WEB-SERVER1 httpis a useful guideline to follow.
permit ip any WEB-SERVER1 httpis an excellent rule to follow.
permit tcp 18.104.22.168 3389 WEB-SERVER1(where 22.214.171.124 is the IP address of the administrator's machine on the Internet) is a suitable rule to follow.
permit tcp 126.96.36.199 DB-SERVER1 3306is an excellent rule to follow (where 188.8.131.52 is the IP address of the host on the Internet that needs access to the database). Allowing database traffic through a VPN rather than in clear text across the public Internet is a best practice.
- At the network perimeter, communication with an invalid source address for incoming traffic or an invalid destination address for outgoing traffic (an invalid "external" address) should be prevented. Malware, spoofing, denial-of-service attacks, and misconfigured equipments are all common causes of this traffic. An IPv4 address within the ranges defined in RFC 1918, Address Allocation for Private Internets, that are reserved for private networks is the most common type of incorrect external address. These are the ranges
10.255.255.255 (10.0.0.0/8 in CIDR notation),
172.31.255.255 (172.16.0.0/12), and
- Allow only traffic from the IP space you use. Apply proper subnet masks to internal networks, i.e. masks that are long enough to identify only the IP network number fragment you're using. If you're utilizing an RFC 6761 Private Address from
172.16.0.0and only assigning numbers from
172.16.1.x, your subnet mask should be
255.255.255.0 (or /24)rather than
255.255.0.0 (or /16). (The same rule applies to RFC 4913 IPv6 Private Addresses.)