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.
Freelance Network / Security Engineer
kfelix ----a---t---socpuppets ---d---o---t---com
