New to Firewalling
-
I picked up the book Firewalls with OPENBSD to get me started but I am wondering from experience if anyone has a good rule of thumb of what ports to start out on. The book basically tells you to start by Deny Everything and slowly add ports and such, but to me this causes too many probelms headaches between tech support and clients being upset.
I know 445 is good one to block as that's microsofts server messenger that is annoying as hell.
-
You want happy clients and less headaches and some damn good ruleset? Than do exactly what it is in that book - start with deny all. Only than you are absolutely clear what is happening at the gates of your network. If you do sth. like - allow any traffic from inside - have fun with the first trojan, worms and viruses. I've had many customers whining at first about "None is working! Blah… Fix it!", but you have to make sure they (you) understand the approach, to make that thing as tight and safe as possible. You can start good with "deny all" and step by step allow services to pass the firewall rulesets or start with the bad one "allow all" and hope to make the best of it.
Think about an airport and guards. If you wanna be real sure about the plane leaving, would you allow all passengers to pass and only "filter out" a few suspecting ones or would you filter them all and adapt your "rules" while watching their luggage?
My hint: Do a deny all and log into the wall with ssh and start pflog. Now test your services and if traffic won't go out, you can immediatly see which ip/port combination is the problem. Inform yourself about the services that have to pass and their needs for your rulesets and do them as tightly as you can. You're better of with a boss mocking around a bit, that his favourite music software won't work (at the moment) as with a furious one, 'cause he got a call why the hell you're sending spam and worms from your network. :)
-
thanks
-
well pfsense works diferent
if it finds a rulle it will stop and don't look any more
the trick is to make rules for acepting ports
and then block the restlike
alow port 20
alow port 21
alow port 80
alow port 443
block allthis will give you ports 20,21,80 and 443 and block all the rest of the ports
-
might be nitpicking ;) but: No, it doesn't. pfSense makes use of OpenBSDs PF packet filter which currently accepts rules in "both worlds". If you write your rule with the "quick" keyword - as all rules you create in the pfsense webgui are - it works like you describe. If a rule is matched, further processing is skipped and the rule will be taken. If you create your rules without that keyword, pf behaves differently. Than the rules are parsed further and if another rule matches, its action is taken. That game is played until 1) the end of the rules are reached, then the last action from a rule matching that packet is taken or 2) the parser stumbles upon a rule with the "quick" keyword. So it is technically possible to write a ruleset in which a packet runs through something like "pass-block-block-pass-pass-pass-block-pass'quick".
So currently in pfsense you have to carefully watch the ordering of your rules in your ruleset so that the matching packet gets what it is supposed to get :) But I personally hope, that some developing angel will insert the "quick" option into the rule creation and editing dialogue, so that you can make full use of it ;)
-
might be nitpicking ;) but: No, it doesn't. pfSense makes use of OpenBSDs PF packet filter which currently accepts rules in "both worlds". If you write your rule with the "quick" keyword - as all rules you create in the pfsense webgui are - it works like you describe. If a rule is matched, further processing is skipped and the rule will be taken. If you create your rules without that keyword, pf behaves differently. Than the rules are parsed further and if another rule matches, its action is taken. That game is played until 1) the end of the rules are reached, then the last action from a rule matching that packet is taken or 2) the parser stumbles upon a rule with the "quick" keyword. So it is technically possible to write a ruleset in which a packet runs through something like "pass-block-block-pass-pass-pass-block-pass'quick".
It's probably worth mentioning that the last rules we put in the rule set 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."If you don't explicitly allow the traffic, it will get blocked (except on LAN where by default we have a rule that allows all - it can be removed at the users discretion.)
So currently in pfsense you have to carefully watch the ordering of your rules in your ruleset so that the matching packet gets what it is supposed to get :) But I personally hope, that some developing angel will insert the "quick" option into the rule creation and editing dialogue, so that you can make full use of it ;)
I don't think we'll be doing that any time soon. I can see why it's wanted, but we're limited by PF syntax right now and allowing the use of non-quick would very quickly screw up the shaper (which relies on it being the only thing that doesn't use quick) - I'm working on a fix for that, but it won't make 1.0 as it's going to need kernel changes.
–Bill
-
Hey Bill,
thanks for your notes on my comment :)
I didn't expect, that non-quick rules will come that soon, but it is sure wait the worth and you light my day in mentioning, that work on that is work in progress, even if it doesn't have a high priority ;) I didn't think about the traffic shaper while thinking 'bout the rules, mainly because I did not use it for that long of a time. Thank you for pointing that out :) -
So how exactly do we write deny all in LAN ?
Block Interface LAN Protocol ANY source LAN SUBNET destination LAN SUBNET log packets checked
I do so I have nothing that has port 3283 & 5900 open on TCP/UDP and I still don't see this port closed . I open Apple Remote Desktop and it all works … when it should not.
Is there a way to log a port to see if it is passing and what rules are allowing it too ?
Thanks
-
Just remove all rules at LAN and it is blocking everything except the webgui port due to the webGUI anti-lockout rule. You can disable this at system>advanced but beware that you might shut out yourself from accessing the webgui if you don't have another rule in place allowing access.
You also can add the log checkbox to your rules. This way you can even send pass traffic to the logs (for example if you want to know which IP is accessing the webgui) or for troubleshooting. -
Could I just disable the rule instead of removing them ? It would be annoying to remove and recreate or backup and restore ….
-
Could I just disable the rule instead of removing them ? It would be annoying to remove and recreate or backup and restore ….
Same difference.
–Bill
