A Checklist for Developing Defenses

Step

Description

Use role accounts with registrars.

Contact information on file at domain and IP registrars should reflect only role-based information. For example, "John Doe <john.doe@mydomain.com>" should be replaced by "Domain Registrar Contact <hostmaster@mydomain.com>." By using role-based accounts instead of linking these functions to individuals, information assets and critical communications may be more reliable during changes in management and/or personnel. The best reference for role-based mailboxes and account names is RFC 2142 (Mailbox Names for Common Services, Roles and Functions).

Select a trustworthy registrar and lock your domains.

Use only trustworthy registrars for your domains (cheaper doesn't mean better and they're not all functionally equivalent). Once you're comfortable with your registrar, set the REGISTRAR-LOCK attribute on your domains, protecting them from non-incumbent-registrar-initiated transfers.

Use split-horizon or split-split DNS.

Generally speaking, split-horizon or split-split DNS should be used at all times. People outside your organization looking up public DNS records inside your organization should use completely segregated servers from those your internal users rely upon as caching nameservers to answer their recursive or local queries. We often recommend to our clients that they completely outsource public-facing DNS and mind their own DNS internally. Public- facing DNS can simply be allowed to zone transfer the necessary information you provide, and therefore you still remain in control of your DNS records.

Restrict recursive DNS queries.

Filters should restrict recursive DNS usage outside of your organization. Only your recursive/caching nameservers should be able to make DNS queries outside of your network. Likewise, outside DNS servers should only be allowed to transmit DNS responses or queries to your public-facing DNS servers or to your local caching/recursive nameservers that asked them a question (using stateful filtering)

Use best practices for high availability.

Your DNS servers should be redundant and diverse in terms of network topology and physical location. Redundant nameservers are never two nameservers that share a common LAN or IP network segment.

Consider RFC 2870 (Root Name Server Operational Requirements).

Suggestions from RFC 2870 (Root Name Server Operational Requirements) should be considered and implemented wherever possible.

Don't provide recursive service to the public.

Public-facing nameservers should not allow the recursion on behalf of the general public under any circumstances. This invites cache- poisoning attacks.

Restrict zone transfers and unnecessary information disclosure.

Nameservers should allow DNS zone transfers only from the servers (specified by unique IP address) that are their proper secondary servers. This is especially important to note if you have outsourced DNS completely to a third party or if you're using a third party as a backup DNS server. Chances are they're your weakest link.

Monitor your DNS infrastructure and model queries.

Monitoring for extraneous similar requests can deliver a number of false positives, but often indicates attempted cache-poisoning attempts. Until DNSSEC or another zone-signing system prevails, this will be a concern. Monitoring for zone transfers or version requests (using some form of intrusion detection (IDS) technology) will give you insight into those attempting to map your network and a heads-up that often signals the beginning of some form of attack.

Consider alternatives to your current DNS software. Double-check your existing DNS software configuration to ensure best practices for security are followed.

There are many "secure" configuration templates available for BIND software, but our favorite is that provided by Rob Thomas and the Cymru Team at http://www.cymru.com/Documents/secure-bind-template.html.
Consider using djbdns by D.J. Bernstein as it has proven a reliable and secure alternative to BIND. See http://cr.yp.to/djbdns/. According to Bernstein, "All the work in a typical ˜secure configuration template for BINDsetting up a chroot jail, for example, and limiting recursionis handled automatically by the standard djbdns configuration."
There are other, less-known DNS server software options out there that deserve your consideration.

Recommended Reading

  • RFCs 1034, 1035, 2065, 2142, 2373, 2535, 2671, 2870, and 2929

  • http://www.root-servers.org

  • ftp://ftp.internic.net/domain/named.cache

  • http://www.iana.org/gtld/gtld.htm

  • http://www.iana.org/cctld/cctld-whois.htm

  • http://www.lurhq.com/cachepoisoning.html

  • http://ftp.cerias.purdue.edu/pub/papers/christoph-schuba/schuba-DNS-msthesis.pdf

  • http://www.geocities.com/fryxar/

  • http://cr.yp.to/djbdns/

  • http://www.icann.org/transfers/policy-12jul04.htm

  • http://www.cymru.com/Documents/secure-bind-template.html

  • http:// sourceforge .net/projects/ dnswalk /



Extreme Exploits. Advanced Defenses Against Hardcore Hacks
Extreme Exploits: Advanced Defenses Against Hardcore Hacks (Hacking Exposed)
ISBN: 0072259558
EAN: 2147483647
Year: 2005
Pages: 120

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net