Request configurability of default catch-all block rules

[rcarr]

The default catch-all rules at the end of rules.debug are:

block in log quick all label "Default block all just to be sure."
block out log quick all label "Default block all just to be sure."

Silently dropping unauthorized packets is a good idea when we want our net to remain invisible (as much as possible) to the outside world.  But if we're hosting services to the internet (www, smtp, etc), then we probably want to block unauth TCP packets with return-rst, block unauth UDP packets with icmp-as-dest(port-unr) – to mislead outsiders into thinking there's no packet-filter in place.

It would be great if a future version of pfsense let one customize these catch-all rules.

[sai]

You could just add your own rules at the bottom of the ruleset to do all these things. The catchall is a safety net, and its good to know that its there even if you make a mistake.

[rcarr]

I thought about that, but user-defined rules aren't the last set of rules in rules.debug.  If I add my own catch-all, I'll block the VPN rules section, as well as IMSpector uPnPd and possibly other sections in the future.

[sullrich]

While I really appreciate your previous suggestions I do not understand the need for this.  Simply add a rule at the bottom of each screen's rule list to override it.

However, if you are willing to submit a patch I will consider it.

[rcarr]

Is there a resource you can point me to for the formal process of creating a pfsense patch?  Is there a resource which documents how your XML configuration system works so I can investigate which files to make the changes in?  Or should I just go spelunking around?

[hoba]

http://wiki.pfsense.com/wikka.php?wakka=SubmittingPatches

[rcarr]

Simply add a rule at the bottom of each screen's rule list to override it.
<<

Here's what happens in rules.debug when I add my own custom catch-all-block to the bottom of Firewall->Rules->WAN:

User-defined rules follow

.
.
.
pass in quick on $lan from 172.19.1.0/24 to any keep state  label "USER_RULE: Default LAN -> any"
pass in quick on $enc0 from any to any keep state  label "USER_RULE: Permit IPSEC traffic."
===> block return-rst in quick on $wan proto tcp from any to any flags S/SA  label "USER_RULE: test return-rst block-all rule" <====

VPN Rules

pass in quick on fxp1 inet proto tcp from any to $loopback port 8021 keep state label "FTP PROXY: Allow traffic to localhost"
pass in quick on fxp1 inet proto tcp from any to $loopback port 21 keep state label "FTP PROXY: Allow traffic to localhost"
–-> pass in quick on fxp0 inet proto tcp from port 20 to (fxp0) port > 49000 user proxy flags S/SA keep state label "FTP PROXY: PASV mode data connection" <---

enable ftp-proxy

pass in quick on fxp2 inet proto tcp from any to $loopback port 8022 keep state label "FTP PROXY: Allow traffic to localhost"
pass in quick on fxp2 inet proto tcp from any to $loopback port 21 keep state label "FTP PROXY: Allow traffic to localhost"

IMSpector

anchor "imspector"

uPnPd

anchor "miniupnpd"

My custom catch-all block rule for the $wan interface (denoted with '===>') appears before the VPN Rules, IMSpector and uPnPd sections.  It now interferes with one of the VPN rules (denoted with '--->').  I don't know what goes in IMSpector or uPnPd, but it's likely any catch-all block rules I'd add to the User-Defined section would interfere with them, as well as any future work you do adding additional sections to rules.debug after the user-defined section.

By definition, catch-all block rules like your "Default block all just to be sure" rules must appear at the end of the pf ruleset.  The WebGUI does not give you the ability to modify them, nor position these kinds of rules at the end.

I'll investigate creating a patch.