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

    PCI compliance scans - The remote name server allows recursive queries to be …

    General pfSense Questions
    6
    6
    7.7k
    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.
    • S
      superwormy
      last edited by

      We're going through a PCI compliance scan with SecurityMetrics.com, and running into a problem. SecurityMetrics says:

      "Synopsis : The remote name server allows recursive queries to be performed by the host running the test server. Description : It is possible to query the remote name server for third party names. If this is your internal nameserver, then the attack vector may be limited to employees or guest access if allowed. If you are probing a remote nameserver, then it allows anyone to use it to resolve third party names (such as www.securitymetrics.com). This allows attackers to perform cache poisoning attacks against this nameserver. If the host allows these recursive queries via UDP, then the host can be used to 'bounce' Denial of Service attacks against another network or system. See also : http://www.cert.org/advisories/CA-1997-2 2.html http://technet.microsoft.com/en-us/libra ry/cc787602%28WS.10%29.aspx Solution: Restrict recursive queries to the hosts that should use this nameserver (such as those of the LAN connected to it). If you are using bind 8, you can do this by using the instruction 'allow-recursion' in the 'options' section of your named.conf. If you are using bind 9, you can define a grouping of internal addresses using the 'acl' command. Then, within the options block, you can explicitly state: 'allow-recursion { hosts_defined_in_acl }' If you are using another name server, consult its documentation. Risk Factor: Medium  / CVSS Base Score : 5.0 (CVSS2#AV:N/AC:L/Au:N/C:N/I:P/A:N) CVSS Temporal Score : 4.3 (CVSS2#E:U/RL:U/RC:C) Public Exploit Available : false CVE : CVE-1999-0024 BID : 136, 678 Other references : OSVDB:438 "

      and

      "Synopsis : The remote DNS server is vulnerable to cache snooping attacks. Description : The remote DNS server responds to queries for third-party domains that do not have the recursion bit set. This may allow a remote attacker to determine which domains have recently been resolved via this name server, and therefore which hosts have been recently visited. For instance, if an attacker was interested in whether your company utilizes the online services of a particular financial institution, they would be able to use this attack to build a statistical model regarding company usage of that financial institution. Of course, the attack can also be used to find B2B partners, web-surfing patterns, external mail servers, and more. Note: If this is an internal DNS server not accessable to outside networks, attacks would be limited to the internal network. This may include employees, consultants and potentially users on a guest network or WiFi connection if supported. See also : http://www.rootsecure.net/content/downlo ads/pdf/dns_cache_snooping.pdf Solution: Use another DNS software. Risk Factor: Medium  / CVSS Base Score : 5.0 (CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:N) "

      Now, I realize that a firewall rule could be used to stop this. HOWEVER, SecurityMetrics requires us to have a rule which allows all traffic from them through- i.e. I can't just put a deny rule to reject UDP port 53 from the WAN.

      Is there a way to turn this off in pfSense 2.x so that we can pass our PCI scans? How do others get around this?

      1 Reply Last reply Reply Quote 0
      • Cry HavokC
        Cry Havok
        last edited by

        They're doing this remotely? Then you shouldn't be giving them any access that you wouldn't give to any other remote system. Anything else generates a false result. If they won't change on that I'd suggest you find somebody with a clue do do your PCI compliance testing.

        The pfSense DNS server is doing exactly what it's supposed to do, since it's only intended to be used from the LAN.

        1 Reply Last reply Reply Quote 0
        • C
          Cino
          last edited by

          I don't use pfSense at work but we have to run internal PCI scans every quarter. Every network switch/device, unix/ms server has to meet their needs to be PCI compliance…Even if there is no PCI info going thru the equipment, we still have to meet it..BS... I have gray hairs because of PCI audits.. This team runs scans in-house... We get the report with the recommended fixes... Ask them how to fix it and they don't have a clue...They tell us to follow whats on the report..

          I know my post isn't helpfully but I'm bitter towards PCI... I understand the need but for crying out loud, have real network/system security admins do the audits.. Not someone who took a test and thinks they know IT security.

          1 Reply Last reply Reply Quote 0
          • jimpJ
            jimp Rebel Alliance Developer Netgate
            last edited by

            Like Cry Havok said, if they are doing this scan from outside your network, they shouldn't need any special rules, if they do, the scan is worthless as it isn't testing anything useful.

            The DNS Forwarder can be disabled if you don't use it, but if you do use it, then it's not an external vulnerability. Of course it allows recursive DNS queries because that is its job, to be a recursive DNS resolver/cache for internal hosts.

            And the second bit is worthless because scanning for a remote vulnerability in a DNS server and yours is local, not remote. It's only "remote" because of their BS rule to allow traffic from them into your network.

            The scans themselves are useful when done properly and done in a meaningful way, but you also can object to what they find if it's a false positive, or in this case, total BS from a worthless scan. :-)

            You should be more interested in what they'd find without a special rule in place because that is really what your normal remote exposure is.

            Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

            Need help fast? Netgate Global Support!

            Do not Chat/PM for help!

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

              @jimp:

              Like Cry Havok said, if they are doing this scan from outside your network, they shouldn't need any special rules, if they do, the scan is worthless as it isn't testing anything useful.

              The only thing my provider RECOMMENDS is that they be included on any port forwards that exist for other systems.  For example, if I open the ports necessary for OpenVPN connections so that I can access it from my home, they should be included on that port forward.

              I can break anything.

              1 Reply Last reply Reply Quote 0
              • D
                dlebs
                last edited by

                @superwormy:

                Now, I realize that a firewall rule could be used to stop this. HOWEVER, SecurityMetrics requires us to have a rule which allows all traffic from them through- i.e. I can't just put a deny rule to reject UDP port 53 from the WAN.

                Is there a way to turn this off in pfSense 2.x so that we can pass our PCI scans? How do others get around this?

                I also got the same errors on SecurtityMetrics scan, but I don't see anywhere where they dissallow firewall rules that apply to everyone.  You have to exempt them from any IDS/IPS system which makes sense, but they are testing the firewall as well as everything else.  Deny rules are how firewall's work.

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