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

    DNS resolver protection rules

    Scheduled Pinned Locked Moved Firewalling
    3 Posts 2 Posters 811 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.
    • M
      michaelschefczyk
      last edited by

      Dear All,

      After reading previous posts on converting iptables rules to pf, many questions do remain open. In some cases, my impression is that it is difficult to reach the same functionality, thus it may be required to use port forwarding towards a machine in the LAN running iptables. One such candidate seems to be protecting publicly resolving DNS servers. Good practice iptables rules do include:

      -p udp –dport 53 -m string --from 50 --algo bm --hex-string '|0000FF0001|' -m recent --set --name dnsanyquery
      -p udp --dport 53 -m string --from 50 --algo bm --hex-string '|0000FF0001|' -m recent --name dnsanyquery --rcheck --seconds 60 --hitcount 4 -j DROP

      -p udp -m hashlimit --hashlimit-srcmask 24 --hashlimit-mode srcip --hashlimit-upto 30/m --hashlimit-burst 10 --hashlimit-name DNSTHROTTLE --dport 53 -j ACCEPT
      -p udp -m udp --dport 53 -j DROP

      The first rules look for the particular type of an "ANY" request recognized by a string of dots and rate limits this based on a hitcount. The second rules uses hashlimits on /24 source subnets and limits it while allowing burst peaks.

      In pfsense it seems that there is no string matching and rate limiting seems to be possible for TCP traffic only.

      Is this correct or did I overlook an elegant way to achieve this in pfsense?

      Regards,

      Michael Schefczyk

      1 Reply Last reply Reply Quote 0
      • W
        wussupi83
        last edited by

        Gonna be honest, I'm having a little trouble understanding why you need these rules. Could you explain it a little more for me?

        Are you worried a host on your network is going to be compromised and attempt to communicate with many networks at once, like participating in a botnet style attack on some targets? Or are you worried it's going to be trying to essentially flood your network with erroneous DNS requests? Again, I don't really understand. Thank you for any light you can provide.

        1 Reply Last reply Reply Quote 0
        • M
          michaelschefczyk
          last edited by

          Dear wussupi83,

          Thank you very much for questioning the purpose. The rules are from this source:

          https://wiki.opennic.org/opennic/tier2security

          My understanding is that the rules do intend both: Prevent too many "ANY" queries, which might be a DOS attack against the entity running a resolver AND prevent high levels of regular requests coded into botnet victims when the authors determined that the protection via limiting is lower than at average open resolvers.

          My experience from just running a package bind open resolver with standard rate limiting at four public IPs was the following: A botnet code obviously used one of the four IPs. It did receive many queries for a US authority. My network performance or security was not at risk, but I did receive a letter from the provider of that IP pointing out abuse in such an attack.

          Rules like the rules quoted should at least reduce such risks. The opennic resolvers are in a similar situation and therefore, I do just assume that their rules will meet the purpose and lead to an average performance, which should not be overly attractive for botnets. My question is, if I need to shift it to linux behind my firewall if I am unable to create similar rules in pf or if I can get the same functionality in pfsense.

          Regards,

          Michael

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