Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    New to Firewalling

    Scheduled Pinned Locked Moved Firewalling
    11 Posts 6 Posters 5.4k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • JeGrJ
      JeGr LAYER 8 Moderator
      last edited by

      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. :)

      Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

      If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

      1 Reply Last reply Reply Quote 0
      • G
        g0dsp33d
        last edited by

        thanks

        1 Reply Last reply Reply Quote 0
        • J
          jeroen234
          last edited by

          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 rest

          like
          alow port 20
          alow port 21
          alow port 80
          alow port 443
          block all

          this will give you ports 20,21,80 and 443 and block all the rest of the ports

          1 Reply Last reply Reply Quote 0
          • JeGrJ
            JeGr LAYER 8 Moderator
            last edited by

            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  ;)

            Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

            If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

            1 Reply Last reply Reply Quote 0
            • B
              billm
              last edited by

              @Grey:

              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.)

              @Grey:

              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

              pfSense core developer
              blog - http://www.ucsecurity.com/
              twitter - billmarquette

              1 Reply Last reply Reply Quote 0
              • JeGrJ
                JeGr LAYER 8 Moderator
                last edited by

                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 :)

                Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

                If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

                1 Reply Last reply Reply Quote 0
                • A
                  Aderium
                  last edited by

                  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

                  Anthony Palermo

                  1 Reply Last reply Reply Quote 0
                  • H
                    hoba
                    last edited by

                    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.

                    1 Reply Last reply Reply Quote 0
                    • A
                      Aderium
                      last edited by

                      Could I just disable the rule instead of removing them ? It would be annoying to remove and recreate or backup and restore ….

                      Anthony Palermo

                      1 Reply Last reply Reply Quote 0
                      • B
                        billm
                        last edited by

                        @Aderium:

                        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

                        pfSense core developer
                        blog - http://www.ucsecurity.com/
                        twitter - billmarquette

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.