Best Practices for Firewall Rules

Now that we have described how to add a firewall rule, it may be a good time to articulate a set of best practices for firewall rules. As with the rules for pfSense, some of these rules might be obvious, but some may not be so obvious.

  • The principle of least privilege should apply to our rules. In many cases, our firewall rules have become too permissive. You should avoid creating rules with any in the destination field (these are known as pass-through rules). At the very least, you should limit the range of ports on which these rules apply. OPNsense blocks all traffic by default, and we want to take advantage of that. This leads us to a corollary:
  • Block by default. Block all traffic by default and explicitly enable only specific traffic to known services, which will provide good control over the traffic and reduce the possibility of a breach because of service misconfiguration.
  • Firewall rules should be periodically checked, and obsolete rules should be deleted. For example, at one time we had a printer on the LAN network that workstations on other network would need permission to access; therefore rules had to be created granting access to this resource. If the printer were subsequently decommissioned or moved to another network, then the rule granting permission to the printer’s IP address would have to be deleted (or modified). In a corporate environment, you may have to be proactive, since different departments may not communicate this information. Nevertheless, it is an important practice, as deleting firewall rules eliminates a potential attack vector.
  • Firewall rules should be properly documented. Even if you remember why a rule was added a a rule change was made, others may not remember, especially if the rule change was made in response to an emergency. Documenting rule changes makes firewall management easier and can be helpful in a troubleshooting scenario.
  • Firewall rules should be backed up. This can be done in OPNsense by navigating to the left sidebar menu, clicking on System,, clicking on Configuration, and clicking on Backups. [A separate article on configuring backups will be posted soon.] In a corporate environment, such backups should be maintained offsite. Such backups may prove to be of value if you ever have to recover from a firewall crash or some other catastrophe.
  • Create your rules in a manner consistent with the company’s security policy. When you are done creating them, you should review them to make sure they are consistent with such policy.
  • Eliminate redundant and unnecessary rules. Try to keep your ruleset as simple as possible.
  • Patch the firewall. Patch it with the latest updates on a regular basis.
  • Maximize CPU cycles. To this end, you should limit the number of applications running on the firewall. Any applications that can be run on a dedicated machine (e.g. a proxy server) should be moved to another system either behind or in front of the firewall.
  • Test your firewall. It is important that you perform regular security tests on your firewall. New exploits are being found and the firewall should be tested on a regular basis. This should include testing every interface on both sides of the firewall.
  • Comply with PCI DSS, if necessary. You will want to review your policies to make sure you are in compliance with this standard. For example, PCI requirement 1.1.6 requires a complete firewall review every six months. PCI DSS is constantly being updated – as of this writing, Version 4.0 was scheduled for release in March 2022– so you need to review the latest version of the standard to see if there are any new requirements that affect firewall implementation.
  • Enable logging. You should only do this if you are going to read the logs. Otherwise, maintaining logs is a waste of both disk space and CPU usage.
  • Implement posture assessment. If you have remote users, you should require that they run a personal firewall and/or intrusion detection system on their computer. You can’t trust every computer, and some computers may be running questionable applications. If possible, you should implement a system that performs a health check on remote computers. Is the computer running anti-virus? If so, which version? What kind of personal firewall are they running? It would behoove you if you have a posture assessment that applies to all platforms (e.g. Windows, Linux, Mac OS, Android, iOS).
  • Enable Syslog. You may also consider running a remote syslog server for logging, to make it more difficult for potential hackers to modify the log files and thus cover their tracks.

You may possibly add to these general principles, but it’s a good set of guidelines for creating firewall rules.