How to best test/verify firewall rules?
-
Hi,
I am in the process of setting up a Netgate 2100/pfSense for the first time and wonder how you guys test your firewalls, most interested about internal testing, to begin with anyways, i.e what's allowed/blocked between vlans, what can reach internet, ping and whatnot. Is there a tool for this, or all manual?
I mean, it is great to closely read the rule, but sometimes things still don't do exactly as planned or thought out and a nasty bug or error sneaks in... Just want to make sure that the rules I will use are good ones, at the correct position in the chains. Thoughts?
Thanks
-
@furom
Don't discount walking the rules by hand with pen and paper.I start with drawing a block diagram of the network, and list the desired behavior is plain English (or whatever your native language). Things like:
Default deny in on WAN
Allow any from LANNET to any
Block any port NETBIOS to anyThe "desired behavior" is "your requirements".
then take the applied rules (you can get them from pfctl -sr either console/ssh or GUI) and pick a packet from wherever and follow the rules.
Just remember that pfSense is "last match wins", a rule with "quick" means "if the packet matches here, don't process any following rules".
After doing a hand walkthrough, then if you have the ability (time and equipment) you do the same thing:
start with the desired behavior, then inject a packet and see where it goes. -
@mer said in How to best test/verify firewall rules?:
@furom
Don't discount walking the rules by hand with pen and paper.I start with drawing a block diagram of the network, and list the desired behavior is plain English (or whatever your native language). Things like:
Default deny in on WAN
Allow any from LANNET to any
Block any port NETBIOS to anyYes, totally agree. As always, planning usually pays off. I haven't been that thorough yet (drawn some diagrams though), but will for sure try this method :)
The "desired behavior" is "your requirements".
then take the applied rules (you can get them from pfctl -sr either console/ssh or GUI) and pick a packet from wherever and follow the rules.
Wow! Had no idea of the pfctl utility, that should be very useful. Found the docs for it too, so will start trying it out! :)
Just remember that pfSense is "last match wins", a rule with "quick" means "if the packet matches here, don't process any following rules".
This surprises me a bit, and is in fact what made me want to test the rules. I have been told rules act according to "quick", that first match wins, but experienced otherwise when testing a bit with a simple raspberry pi, I could reach stuff I thought were already handled, so great to know this is the default. I will see if I can find what makes a rule "quick" to know where and when to perhaps use it.
After doing a hand walkthrough, then if you have the ability (time and equipment) you do the same thing:
start with the desired behavior, then inject a packet and see where it goes.Well, absolutely. This is what I'd really like, and kind of was hoping for existed in a ready form... Set a expected outcome and then inject a packet to see if it meets the criteria or not. Not that I believe I really need it, but for the fun of it, perhaps something to think about a rainy day. :)
-
@furom said in How to best test/verify firewall rules?:
This surprises me a bit, and is in fact what made me want to test the rules. I have been told rules act according to "quick", that first match wins, but experienced otherwise when testing a bit with a simple raspberry pi,
Well, that's what the GUI hides a little from you, hence me saying "pfctl".
Under the hood, pfSense uses pf (originally from OpenBSD) to implement firewalling and NAT. pf has always been last match wins, but other keywords change that behavior. Think of an old HP calculator using RPN and you're thinking "correctly" ;)
If you look closely at the rules you'll see how the "as applied" order matches with the "floating", "per interface", etc ordering in the GUI.
Basically, rules you define in the GUI always have the "quick" added, which makes them effectively "first match wins" because "quick" aborts processing of the rules (there are a few exceptions, but for the most part this applies; I think floating rules you may have to actually check something to get quick applied).
This is a handy bookmark:
https://docs.netgate.com/pfsense/en/latest/If you have other packages enabled, it may affect what rules are evaluated and when, so I'm just talking about base install, nothing else enabled.
The pf book by Peter Hansteen is a little old but the concepts and fundamentals still apply to "how pf works".
Disclaimer: take anything I write here as my opinion, not an official "pfSense position" and like any thing else engineering/networking more than one way to get your result.
-
@mer said in How to best test/verify firewall rules?:
@furom said in How to best test/verify firewall rules?:
This surprises me a bit, and is in fact what made me want to test the rules. I have been told rules act according to "quick", that first match wins, but experienced otherwise when testing a bit with a simple raspberry pi,
Well, that's what the GUI hides a little from you, hence me saying "pfctl".
Under the hood, pfSense uses pf (originally from OpenBSD) to implement firewalling and NAT. pf has always been last match wins, but other keywords change that behavior. Think of an old HP calculator using RPN and you're thinking "correctly" ;)
If you look closely at the rules you'll see how the "as applied" order matches with the "floating", "per interface", etc ordering in the GUI.
Basically, rules you define in the GUI always have the "quick" added, which makes them effectively "first match wins" because "quick" aborts processing of the rules (there are a few exceptions, but for the most part this applies; I think floating rules you may have to actually check something to get quick applied).
Ah... That clears the woe around that, makes sense now. :)
This is a handy bookmark:
https://docs.netgate.com/pfsense/en/latest/Definitively! Thanks, had found it already, but a great resource - almost a bit daunting... But what I have seen so far, really good and comprehensive!
If you have other packages enabled, it may affect what rules are evaluated and when, so I'm just talking about base install, nothing else enabled.
Got it, I haven't come to addons or anything like that yet, but will have that in mind when time comes.
The pf book by Peter Hansteen is a little old but the concepts and fundamentals still apply to "how pf works".
Disclaimer: take anything I write here as my opinion, not an official "pfSense position" and like any thing else engineering/networking more than one way to get your result.
For sure. I read a lot and try to compute what I can from it... :) Good thing there is a great backup feature, so there's most often a way back to where I started if messing things up too much :)