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

    Major security flaw! : Invert Match rules not working as intended with DNSBL enabled

    Scheduled Pinned Locked Moved Firewalling
    10 Posts 3 Posters 1.3k 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.
    • keyserK
      keyser Rebel Alliance
      last edited by

      Hi.

      I have stubled upon what i consider a MAJOR security flaw in PFsense:

      I have been diagnosing an issue with my VLAN’s suddenly being able to access each other after I enabled DNSBL.

      After reading the below thread,

      Re: Invert match doesn't work

      it turns out it was because I’m using an inverted Match rule to allow internet access - and by that using the default deny rule to block access between Internal VLANS.
      I like the idea of a rule saying:
      PASS - Source: Any-IP/Any-Port - Destination: ! RFC1918/Any-Port
      As that is not an any any allow rule but only an allow access to public IP’s rule.
      The extra - and beautiful - catch is, since it only allows access to public IP’s, access between my internal RFC1918 subnet interfaces do not match this allow rule and falls into the default deny instead.

      This has been working fine for years, but after enabling DNSBL in PFBlockerNG and getting a VIB address for the dummy Webservice to block adds, all INVERT MATCH rules no longer works as intented as the invert part becomes an any rule instead - In my case make the rule an actual any any rule.

      This is in my opinion a MAJOR MAJOR security flaw in PFsense as rules that used to work - and logically should work - has a seemingly non related feature i PFsense that disables them without notice.

      While I can read and understand what derelict is saying - and hence why you should’nt use invert match rules, I still find that a VERY dubious argument since you need to FIND this exemption yourself as it makes no sense.
      PFsense should either remove the INVERT MATCH option all together or make it work even if you have VIB’s on your system. It’s not good practice to have the rules option available when undescribed dependencies decides if it works as intended or not.

      What is the argument to allow the invert match rules in the GUI even though they won’t work in some cases?

      Love the no fuss of using the official appliances :-)

      1 Reply Last reply Reply Quote 0
      • johnpozJ
        johnpoz LAYER 8 Global Moderator
        last edited by

        It is up to you to verify your rules you create are working as intended..

        It is also up to you to validate your rules are still working after installing new services, like a package that creates it own rules, etc.

        An intelligent man is sometimes forced to be drunk to spend time with his fools
        If you get confused: Listen to the Music Play
        Please don't Chat/PM me for help, unless mod related
        SG-4860 24.11 | Lab VMs 2.8, 24.11

        1 Reply Last reply Reply Quote 0
        • DerelictD
          Derelict LAYER 8 Netgate
          last edited by Derelict

          Complete explanation of what is happening:

          https://redmine.pfsense.org/issues/6799

          Bottom line, don't block traffic with pass ! rules. If you want to block it, block it, then pass the rest. People will still defend the use of pass ! rules for convenience's sake. I will never use them in my firewalls. Block rules block traffic, not pass rules.

          Chattanooga, Tennessee, USA
          A comprehensive network diagram is worth 10,000 words and 15 conference calls.
          DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
          Do Not Chat For Help! NO_WAN_EGRESS(TM)

          1 Reply Last reply Reply Quote 0
          • keyserK
            keyser Rebel Alliance
            last edited by

            @johnpoz: I understand it's my task to test my rules, and I do, but you have to agree it makes VERY little sense to have a very clear GUI option for a rule setting that could - depending on an unrelated service - mean something entirely different than what it clearly states.

            @Derelict: I understand that's your stance, but you have to agree that to me - and I would guess a LOT of other users - I didn't make a block rule, I made a pass rule to a subset of IP-adresses. Only thing is, because of a non related setting that subset of IP-adresses is now ANY instead.

            I'm not blocking here, I'm selectively passing.

            Love the no fuss of using the official appliances :-)

            1 Reply Last reply Reply Quote 0
            • johnpozJ
              johnpoz LAYER 8 Global Moderator
              last edited by johnpoz

              Putting a VIP from a different L3 is bad idea as well..

              The ! does what it says, if you create state that causes a problem with that by creating a VIP from a different L3 on your interface, etc.. That is where the problem is, not with the ! rule itself.

              Where there should be HUGE warnings in the package that does this..

              An intelligent man is sometimes forced to be drunk to spend time with his fools
              If you get confused: Listen to the Music Play
              Please don't Chat/PM me for help, unless mod related
              SG-4860 24.11 | Lab VMs 2.8, 24.11

              1 Reply Last reply Reply Quote 0
              • DerelictD
                Derelict LAYER 8 Netgate
                last edited by

                Except you're not.

                I do understand where you're coming from, which is why 6799 was created.

                But I had this stance BEFORE this came to light. This issue simply proved my point.

                If you want to block traffic, block it.

                Chattanooga, Tennessee, USA
                A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                Do Not Chat For Help! NO_WAN_EGRESS(TM)

                1 Reply Last reply Reply Quote 0
                • DerelictD
                  Derelict LAYER 8 Netgate
                  last edited by Derelict

                  The pfBlockerNG VIP should be on localhost. Doesn't change the fact that blocking traffic with pass rules is a BAD IDEA™

                  reject destination RFC1918
                  pass destination any

                  Is that so hard?

                  Chattanooga, Tennessee, USA
                  A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                  DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                  Do Not Chat For Help! NO_WAN_EGRESS(TM)

                  1 Reply Last reply Reply Quote 0
                  • johnpozJ
                    johnpoz LAYER 8 Global Moderator
                    last edited by

                    I do agree with Derelict point about creating specific block rules... The ! rule allowing access is a convenience, but you have to be sure to validate its doing what you think its doing.

                    An intelligent man is sometimes forced to be drunk to spend time with his fools
                    If you get confused: Listen to the Music Play
                    Please don't Chat/PM me for help, unless mod related
                    SG-4860 24.11 | Lab VMs 2.8, 24.11

                    1 Reply Last reply Reply Quote 0
                    • keyserK
                      keyser Rebel Alliance
                      last edited by keyser

                      Well. we could argue semantics all day on whether I'm blocking or passing with a pass rule to a subset of IP's.
                      But I'll bet you that ANY user interface expert would clearly agree with me that when I create a PASS rule to a subset of IP's, I should expect the firewall to handle it as a PASS rule - and not a "hidden Block everything else" rule :-)

                      I probably can't convince you on this, but my stance and point remains :-)

                      On another note I completely agree that PFblockerNG's design to add a second Layer 3 address on an existing Layer 2 Interface is VERY VERY poor design and that It should listen on Loopback instead. But that is currently not an option - I will start a new thread with @BBcan177 on this issue :-)
                      But please note the same problem seems to exist if I manually add a VIB address to an interface. So I would clearly argue it's a design flaw in how ! rules are interpreted by the rule engine.

                      I will obviously change my firewall rules now, and thanks for the discussion. I hope this will open other users eyes for this problem, and perhaps have you guys push for correcting how this is handled in PFsense.

                      You guys are doing a GREAT job, and thank you very much for what I consider the best freely available product of all time :-)

                      Happy new year!

                      Love the no fuss of using the official appliances :-)

                      1 Reply Last reply Reply Quote 0
                      • DerelictD
                        Derelict LAYER 8 Netgate
                        last edited by Derelict

                        It would require a change upstream in pf. Proper firewall rule design should be adhered to.

                        I probably can't convince you on this, but my stance and point remains :-)

                        Right, which is why I created 6799.

                        Chattanooga, Tennessee, USA
                        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                        Do Not Chat For Help! NO_WAN_EGRESS(TM)

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