This section covers general best practices for firewall rule configuration.
Default Deny¶
There are two basic philosophies in computer security related to access control:default allow and default deny. A default deny strategy for firewall rules isthe best practice. Firewall administrators should configure rules to permit onlythe bare minimum required traffic for the needs of a network, and let theremaining traffic drop with the default deny rule built into pfSense® software.In following this methodology, the number of deny rules in a ruleset will beminimal. They still have a place for some uses, but will be minimized in mostenvironments by following a default deny strategy.
In a default two-interface LAN and WAN configuration, pfSense software utilizesdefault deny on the WAN and default allow on the LAN. Everything inbound fromthe Internet is denied, and everything out to the Internet from the LAN ispermitted. All home grade routers use this methodology, as do all similar opensource projects and most similar commercial offerings. It’s what most peopleexpect out of the box, therefore it is the default configuration. That said,while it is a convenient way to start, it is not the recommended means oflong-term operation.
pfSense software users often ask “What bad things should I block?” but that isthe wrong question as it applies to a default allow methodology. Noted securityprofessional Marcus Ranum includes default permit in his “Six Dumbest Ideas inComputer Security” paper, which is recommended reading for any securityprofessional. Permit only what a network requires and avoid leaving the defaultallow all rule on the LAN and adding block rules for “bad things” above thepermit rule.
Keep it short¶
The shorter a ruleset, the easier it is to manage. Long rulesets are difficultto work with, increase the chances of human error, tend to become overlypermissive, and are significantly more difficult to audit. Utilize aliases tokeep the ruleset as short as possible.
Review Firewall Rules¶
The best practice is a manual review of the firewall rules and NAT configurationon a periodic basis to ensure they still match the minimum requirements of thecurrent network environment. The recommended frequency of such reviews variesfrom one environment to another. In networks that do not change frequently, witha small number of firewall administrators and good change control procedures,quarterly or semi-annually is usually adequate. For fast changing environmentsor those with poor change control and several people with firewall access,review the configuration at least on a monthly basis.
Quite often when reviewing rules with customers, Netgate TAC asks about specificrules and they respond with “We removed that server six months ago.” Ifsomething else would have taken over the same internal IP address as theprevious server, then traffic would have been allowed to the new server that maynot have been intended.
Document The Configuration¶
In all but the smallest networks, it can be hard to recall what is configuredwhere and why. The best practice is to use the Description field in firewalland NAT rules to document the purpose of the rules. In larger or more complexdeployments, create and maintain a more detailed configuration documentdescribing the entire pfSense software configuration. When reviewing thefirewall configuration in the future, this will help determine which rules arenecessary and why they are there. This also applies to any other area of theconfiguration.
It is also important to keep this document up to date. When performing periodicconfiguration reviews, also review this document to ensure it remains up-to-datewith the current configuration. Ensure this document is updated wheneverconfiguration changes are made.
Reducing Log Noise¶
By default, pfSense software logs packets blocked by the default deny rule. Thismeans all of the noise getting blocked from the Internet will be logged.Sometimes there will not be much noise in the logs, but in many environmentsthere will inevitably be something incessantly spamming the logs.
On networks using large broadcast domains – a practice commonly employed bycable ISPs – this is most often NetBIOS broadcasts from clue-deficientindividuals who connect Windows machines directly to their broadbandconnections. These machines will constantly pump out broadcast requests fornetwork browsing, among other things. ISP routing protocol packets may also bevisible, or router redundancy protocols such as VRRP or HSRP. In co-locationenvironments such as data centers, a combination of all of those things may bepresent.
Because there is no value in knowing that the firewall blocked 14 millionNetBIOS broadcasts in the past day, and that noise could be covering up logsthat are important, it is a good idea to add a block rule on the WAN interfacefor repeated noise traffic. By adding a block rule without logging enabled onthe WAN interface, this traffic will still be blocked, but no longer fill thelogs.
The rule shown in Figure Firewall Rule to Prevent Logging Broadcasts isconfigured on a test system where the “WAN” is on an internal LAN behind an edgefirewall. To get rid of the log noise to see the things of interest, we addedthis rule to block – but not log – anything with the destination of thebroadcast address of that subnet.
Firewall Rule to Prevent Logging Broadcasts¶
The best practice is to add similar rules, matching the specifics of any lognoise observed in an environment. Check the firewall logs under Status >System Logs, Firewall tab to see what kind of traffic the firewall isblocking, and review how often it appears in the log. If any particular trafficis consistently being logged more than 5 times a minute, and the traffic is notmalicious or noteworthy, add a block rule for it to reduce log noise.
Logging Practices¶
Out of the box, pfSense software does not log any passed traffic and logs alldropped traffic. This is the typical default behavior of almost every opensource and commercial firewall. It is the most practical, as logging all passedtraffic is rarely desirable due to the load and log levels generated. Thismethodology is a bit backwards, however, from a security perspective. Blockedtraffic cannot harm a network so its log value is limited, while traffic thatgets passed could be very important log information to have if a system iscompromised. After eliminating any useless block noise as described in theprevious section, the remainder is of some value for trend analysis purposes. Ifsignificantly more or less log volume than usual is observed, it is probablygood to investigate the nature of the logged traffic. OSSEC, an open sourcehost-based intrusion detection system (IDS), is one system that can gather logsfrom a firewall via syslog and alert based on log volume abnormalities.
