The fundamental principles discussed in the previous section should help us in developing a set of best practices for creating firewall rules. Some of these will seem obvious, while others will be less so:

• The principle of least privilege should apply to our firewall rules; many firewall rules are too permissive. When possible, avoid creating firewall rules that have any in the destination, or at least limit the port range. Take advantage of the fact that pfSense blocks all network traffic by default.
• Periodically check your firewall rules, and delete rules that are no longer relevant. For example, a subnet may have a printer that is shared with other subnets. A rule is created to grant access to the printer on those subnets. If the printer is subsequently decommissioned or moved, the firewall rules should be changed accordingly. In corporate environments, obtaining information necessary to know what rules need to be deleted or changed may be difficult, as it might require interdepartmental communication. Still, it is a good idea to be proactive about such matters, as it helps keep your network as secure as possible.
• Firewall rules should be documented. This obviously becomes more important in corporate scenarios, but even in less formal settings, it is an important practice. Even if you know why a rule was implemented, others may not, and proper documentation will potentially make network management and troubleshooting much easier.
• Firewall rules should be automated, whenever possible. Human error is often the cause of firewalls not performing as they should, and when possible, this element should be minimized.
• Firewall rules should be backed up on a regular basis. In pfSense, you can perform a backup of just the firewall rules separately (we will cover how to back up and restore your pfSense system in the appendix). In a corporate environment (and this is good practice even in a home or SOHO environment), such backups should be maintained off-site. Backups can be invaluable in the case of a crash or other mishap.
• Create your rules in a manner that is consistent with your company's written security policy, if your company has one. Once you are done, you should review the rules to make sure they are consistent with said policy.
• Eliminate redundant and/or unnecessary firewall rules. Keep the ruleset as simple and concise as you can.
• Audit your rules on a regular basis.
• Keep track of when pfSense is updated, and patch the firewall with the latest updates in as timely a manner as possible.
• Limit the number of applications running on the firewall so that the firewall can consume the lion's share of CPU cycles, and network throughput should improve. Any application that can be moved onto a dedicated system should be.
• A corollary to the previous point is that the firewall rules should be organized for maximum efficiency. That means having as few evaluations as possible. Always place more specific rules first; this will minimize the number of packets later rules must evaluate.
• As new exploits are being discovered all the time, it is a good idea to routinely test your firewall. In some cases, this may take the form of a penetration test (or pen test), which is an authorized simulated attack on a computer system performed to evaluate security. Penetration tests may be done in isolation or as part of a more comprehensive security audit. In many cases, the penetration test may be performed by a third party rather than the company's network admins. In any case, it is good practice to test the firewall, and this means all interfaces.
• Speaking of security audits, if your company is required to comply with the Payment Card Industry Data Security Standard (PCI DSS), you should review your firewall policy to make sure it meets the requirements of this standard. It is outside scope of this section to provide a comprehensive overview of PCI DSS, but it’s worth mentioning that version 1.1.6 of the standard requires a complete firewall review every six months. The latest revision of the standard is version 3.2.1, released in May 2018.
• You should enable logging–at least if you are going to review the logs. If not, they are a waste of CPU and disk usage.
• Logging is generally a good idea, but hackers who have compromised the security of your firewall may delete or alter the logs to cover their tracks. Therefore, it might be a good idea to run a remote syslog server.
• If you have remote users, require that they run software to secure their computers. At a minimum, you probably want to require them to run a personal firewall.

Some of these bullet points may seem excessive if you are a home or SOHO user. In such cases, you should view most of these as just suggestions. But even in such cases, deleting outdated rules and documenting firewall rules are good practices on all networks.