140 likes | 327 Views
Enterprises / Large Companies. Typical Configuration. Vulnerable. But, where are they vulnerable?. Typical Architecture. Split-Horizon Architecture. Sounds fancy, but it really only means there are 2 distinct sets of DNS servers. External / Public DNS for resolving Internet queries
E N D
Enterprises / Large Companies Typical Configuration • Vulnerable But, where are they vulnerable?
Typical Architecture Split-Horizon Architecture Sounds fancy, but it really only means there are 2 distinct sets of DNS servers • External / Public DNS for resolving Internet queries • Internal DNS for resolving Staff / Intranet queries
Externals DNS The external DNS is most important, right? Not really. The reality is that most of these will only do Authoritative DNS resolution. (That means, it will only respond to queries for entries that are maintained in it’s own database). The new exploit is used to poison CACHED results.
Internal DNS These guys suck! (the life out of me) • They’ll typically be an OLDER BIND version than the externals (they’re inside, and “We have a secure perimeter, right?” ™ • You have to be at BIND 9.5.0 to be patched • BIND 8.x is the most common DNS server out there (at least, on externals, which can be measured) • BIND 4.x is still extremely common on Intranets (at least, in my experience) • That means at least 1, possibly 2 MAJOR version upgrades to not be vulnerable
Upgrade from BIND 4 / 8 BIND 4 / 8 to BIND 9 • Default ACLs under BIND 4/8 are permissive: • allow-query { any; }; • allow-recursion { any; }; • allow-transfer { any; }; • BIND 9 is much more restrictive: • allow-query { localhost; localnetwork; }; • allow-recursion { localhost; localnetwork; }; • allow-transfer { }; • BIND 9 introduces a ACL: • allow-query-cache { localhost; localnetwork; };
Upgrade from BIND 4 BIND 4 / 8 to BIND 9 (cont’d) • BIND 9 has a different default zone transfer mechanism (transfer-format statement) • No support for multiple-cnames: • www.mydomain.com. IN CNAME server1.mydomain.com • www.mydomain.com. IN CNAME server2.mydomain.com • BIND 9 now does round-robin lookups for PTR (reverse mapping) records. Most likely failure is JDK & Network Monitoring tools. • Multiple other (minor, I think) options that aren’t supported: roundrobin (rrset-ordering), • “BIND 9 Administrators Reference Manual” doesn’t document allow-query-cache • In fact, the manual still says the default “allow-x” ACLs are ANY
Upgrade from BIND 4 HOLLY CRAP !!! • I have how long until an exploit is out there??? • Ummmm.. July 23rd – 7 days ago
What to do? OK smart-ass, what should I do? • Build NEW servers (BIND 9.5.0+) • Don’t make them authoritative for anything (if possible) • Open port 53 between them and the Internet • Forward all of your existing DNS servers to these boxes: • options { • forwarders { 192.254.254.1, 192.238.238.1 }; • /* all your usual options */ • };
What to do? (cont’d) • Lock down the BIND 9.5.0+ boxes: • acl intranet-dns { /* list of dns IP addrs */ }; • options { • allow-query { intranet-dns; }; • allow-query-cache { intranet-dns; }; • allow-transfer { }; • allow-update { }; • allow-recursion { intranet-dns; }; • version “Bugger off”; • }; • BTW this is essentially the same thing recommended by ISC.org, they just don’t provide details on how to accomplish it
Does anything break? Are you kidding me? What good would we IT-Folk be, if stuff didn’t break • The good news is, only one thing, and it’s easy to fix – Delegation. • When you specify Forwarders for a DNS server, EVERYTHING is forwarded by default unless the DNS server is: • authoritative for the zone • has an explicit forwarding statement which contradicts the one in the options section
Fixing Delegation • Here’s my zone (domain): • zone “mydomain.com” in { • Type master; • File “db.mydomain.com”; • Allow-update { none; }; • Allow-query { allowquerylist; }; • Allow-transfer { allowtransferlist; }; • }; • And I have an entry in db.mydomain.com, to create a delegate a subdomain (either to another DNS, a load balancer): • Myapp.mydomain.com IN NS 192.240.240.3 • The intranet DNS server server will attempt to recursively resolve the name, and recursion is forced out through the earlier “forwarders” statement. It won’t, by default, follow the delegation specified.
Fixing Delegation (cont’d) • Here’s my updated zone: • zone “mydomain.com” in { • Type master; • File “db.mydomain.com”; • Allow-update { none; }; • Allow-query { allowquerylist; }; • Allow-transfer { allowtransferlist; }; • Fowarders { }; • }; • See the difference?
Fixing Delegation (cont’d) • Here’s my updated zone: • zone “mydomain.com” in { • Type master; • File “db.mydomain.com”; • Allow-update { none; }; • Allow-query { allowquerylist; }; • Allow-transfer { allowtransferlist; }; • Fowarders { }; • }; • This overrides the forwarders statement setup in DNS options. Since the server is authoritative for the zone, we never really need it to forward anyways.
Miscellaneous • Beware of applications that talk directly to the Internet root servers. Client-side is vulnerable as well, not just DNS servers. • Don’t remove the firewall rules for your Intranet DNS servers right away. This allows quick fall-back in the event of a problem, and the forwarders statement takes care of all DNS traffic (except apps running on the DNS server) • Log the queries on the new caching servers, and LOOK AT THEM: • If you’re “leaking” any queries unexpectedly (e.g. you missed a delegation), here’s where you’ll see it • This is a great place, BTW, to catch trojans/malware installed on workstations/servers