View Single Post
  #5   (View Single Post)  
Old 24th October 2013
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,975
Default

The first line blocks any incoming traffic of any kind from IP addresses listed in the table <noface> that arrive on the NIC wpi0. The drop option is used, so no response is returned to those addresses notifying them that their packets cannot reach their destination. As J65nko noted, this rule will only be tested for traffic where there is no state already established -- only stateless traffic (such as ICMP) or state-establishing requests for stateful traffic (such as unsolicited TCP) will be tested against the rule. And, as the rule uses the quick option, any matching traffic will cause PF to cease rule testing and apply the block.

The second line blocks any outgoing traffic of any kind going to IP addresses listed in the table <noface> that would exit the platform via NIC wpi0. As above, the drop and quick options are used. Other systems or local applications are not informed of a failure to reach the <noface> address and no further rule testing takes place after a packet is matched.

The third line blocks TCP protocol traffic other than on the loopback logical device -- loopback is traffic that exists completely inside the computer running PF. The rule blocks TCP traffic in any direction to a range of destination TCP ports used by X Windows for networked X traffic. This rule does not use quick, so on a match the block is not performed unless this happens to be the last matching rule for this traffic. As with the previous rules, drop is used so no notification of the block is returned to the requesting application.


Are those your complete set of filtering rules? If so, PF will pass any traffic that does not match these three rules without tracking state.

If I have any general guidance, it would be:
  • Decide on on overall policy -- whether your ruleset will block everything except what is explicitly permitted, or whether your ruleset will pass everything except what is explictly blocked. If those three rules are your complete list of pass/block rules, it appears you are using the pass everything policy.
  • If you use a pass everything policy, I recommend using an explicit pass all rule at the top of your ruleset. This will keep state, and that will reduce PF overhead as stateful traffic will not be tested against rules once established.
  • I recommend using return rather than drop on block rules where appropriate, such as with your own user(s). In this way, networking applications such as browsers will be notified of blocked traffic immediately and users won't have to sit and wait for long timeouts before getting error messages.

Last edited by jggimi; 24th October 2013 at 04:16 PM. Reason: typo which changed meaning. Correction in red.
Reply With Quote