Thursday, October 17, 2013

Basic Public Facing DNS securing tips from socpuppets


Securing DNS bind named servers . Here’s a few tips on how to properly secured and lock down a DNS server.

DNS is a crucial element in any organization, And both interior and exterior name-servers, need proper care and design to prevent problems.

In this blog we will look at some of our options and means for securing a name server.

Here’s a typical named.conf format that I like to use


include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
include "/etc/bind/named.conf.reverse";
include "/etc/bind/rndc.key";

acl dns-server {  192.168.122.78/32;
                  192.168.122.67/32;
                  127.0.0.1/32;
                 };
acl internal {

        127.0.0.1/32;
        10.2112.0/24;
        10.2113.0/24;
        192.168.122.0/24;
        192.25.218.0/24;
        192.25.219.0/24;
        192.25.222.0/24;
        192.25.223.0/24;

};

acl blacklist {



              0.0.0.0/8;
              10.0.0.0/8;
#            127.0.0.0/8;
              172.16.0.0/12;
              192.168.0.0/16;
              192.0.2.0/24;
              169.254.0.0/16;
              127.0.0.0/8;
              224.0.0.0/4;
              240.0.0.0/4;
              255.255.255.255/32;
};

#

acl transfer {
            12.23.34.35;
            196.1.5.1;
            192.168.122.67;
            69.16.11.18;
            192.5.3.9; 
            33.23.33.83;

};


controls {
         // inet 127.0.0.1  allow { localhost; 192.168.122.67; } keys { rndc-key
; };
        inet * port 953 allow { dns-server; } keys { rndc-key; };
};

server 19.1.3.49 {
        keys { rndc-key; };
};

looks intimidating ? Will not at all.

DNS needs securing  for numerous reasons & to avoid becoming a victim and/or being compromised or becoming  reflector in a DNS reflection attack.

****************************************************************************
One of the 1st security rule that should be followed  if  & you do nothing else; 

" close-off your dns server from being an open-resolver". 
****************************************************************************


What  this means, We only want resolution for prefixes ( ip address ) that are our clients. The rest of the world  can not use my server local and precious dns-server resources. If do little in deploying security practices around your dns-server, this is the one most important step.

Some DNS servers are open-resolvers ( GooglePublid DNS, DNScloud, OPpenDNS,etc...). But they are intended so , & by design and function.

You can follow  openresolver tracking at the follow website;

http://openresolverproject.org/

< make sure you don't become, yet another statistics >

I'm consulting with 3 ISP currently ( 1 outside of the USA and one in EMEA  region ) and on how to combat and close down open-resolvers. Here's a snapshot of just one of 64 class Cs from my USA ISP provider that I'm working with;



The above link is a good tool to generate quick information for tackling open-resolvers. Use it and audit your address space on some periodical schedule.


A quick means to control recursive routing  is; " via the ACLs concept" . In the above cfg we have have a few ACLs defined.

A: We blacklist martians or address that should never hit our dns server from the outside;


acl blacklist {

              0.0.0.0/8;
              10.0.0.0/8;
#              127.0.0.0/8;
              172.16.0.0/12;
              192.168.0.0/16;
              192.0.2.0/24;
              169.254.0.0/16;
              127.0.0.0/8;
              224.0.0.0/4;
              240.0.0.0/4;
              255.255.255.255/32;
};

Notice how  I have 127.0.0.0/8 allowed? I was testing locally on this particular dns and querying against localhost so I had to allow this action. All of these address are bogus if entering from the internet and your DNS-server would not be successful in delivering the response. So why waste time responding to these "martians"?

Keep in mind a lot of IT/networks leaks rfc1918 private or worst APIPA ranges etc....... So this is a ongoing problem,  and you should NOT  treat this as an attack or abuse of your name-server. Also don't get excited,  or waste your time diagnosing why a 169.254.22.33 is querying for a resource-record :)

Just filter it!


B: Next, we set the trusted space that we will allow recursive lookups from;

acl internal {

        127.0.0.1/32;
        10.2112.0/24;
        10.2113.0/24;
        38.2.22.22/32;
        192.168.122.0/24;
        192.25.218.0/24;
        192.25.219.0/24;
        192.25.222.0/24;
        192.25.223.0/24;

};

Acl entries are simple and straightforward, We list the series of ip_address and by using a CIRD prefix style & we can specify a whole range or a singlehost ip_address ( /32 )


Okay now that we have  these 2 defined,  we apply them to our dns-server;



NOTE:  This is ineffect a whitelist and blacklist,  of who we allow and who we don't answer queries for and for the allowance who we provide recursion for.

A address that matches the blacklist is drop and any client asking for recursive lookups who's not allowed would be dropped with a reject message similar to the below;


Notice how this comcast dns server does not answer recursive lookups, & sourced for my non-comcast address?




Now moving on, we should restrict zone transfer. And you guessed it, we could do this via firewall policies or within our named.conf ACLs or a combination of both. If you run into problem & with zone transfers; " make sure you check any layer3 routers/firewall  acl/policies and your named configuration files"

here's I'm only allow these slave dns-servers  to actually transfer zone  database information;

acl transfer {
            12.23.34.35;
            196.1.5.1;
            192.168.122.67;
             69.16.11.18;
            192.5.3.9; 
            33.23.33.83;

};

And we apply this in our named configuration file similar to the below;



Any hosts not listed would be denied , any  any execution of a  AXFR ( zone-transfers ) , would result in a refusal. And like the above example, a simple rejected, or refused  message similar to the below should be displayed;





Okay moving on.

Now to hide our named version, and limiting a potential attacker from  determining what your running. You  mask this very quickly  by either an ACL in some dns-instances or by placing some bogus information.


In my case I masked the version with some bogus wording called "BYE"



So from the outside, a potential hacker will not learn of your version. Here's a few example using the command dns-utilities of  host dig and nslookup , & on how one could determine the version and you will see examples of how I masked this off from  external probing sources.

And  one example of a dns-server for example.com,  that did not hide it's version details btw






and our public dns-server for example.com server , shows it's hand and provides  dns-server version details via nslookup



Okay that's the basic steps for DNS protection.  To recap;


1: do NOT  become a openresolver
2: lock down who can query against your dns-server
3: lock down  any   zone-transfer and from just ONLY your slaves dns-servers
4: mask you dns version details from any external probes

Other security measures that should be looked at,  but are  not 100% required, but is a good ideal;

1: rate-limit DNS traffic from your DNS-server to prevent becoming a flooder
2: stack your dns-server behind a load-balancer and impose limits or controls
3: deploy bind rate-limit options and set the number of queries per-second that your server attends per-source


here's some examples;


e.g ( bind rate-limit options


options {
    directory "/var/named/conf";    rate-limit { responses-per-second 10;
    };
};


e.g  ( cisco traffic policer rate-limiting traffic to  destination not trusted via a class-map and ACL )

!
!    define trust space 1st via a deny statement
ip access-list 101 deny udp any eq 53 host 1.1.1.1
ip access-list 101 deny udp any eq 53 192.0.0.0 0.255.255.255
!    apply any any for everybody else
ip access-list 101 permit udp any eq 53  any
!
class-map dns-traffic
 match access-group 101
!
!
policy-map dns-policer-at-socpuppets
 class dns-traffic
  police 768000 1000 1000 conform-action transmit exceed-action set-qos-transmit 1   violate-action drop



My general rule and just me personally, unless your a dns-hosting company  or a ISP, no more than 10% of  your outgoing traffic  should  not be DNS. If you have more than 10% of your outgoing traffic being DNS  response, you probably have something misconfigured or being a victim of a flooder  source or you have a OpenResolver on your LAN(s).

So on a 100mbps link, that;s 10mbps of dns-respsonses or on a 1gige that 100mbps of dns-responses.



Ken Felix
Freelance Network / Security Engineer
kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^
=(  @   @ )=
          o
       /     \

No comments:

Post a Comment