Wednesday, 16 April 2008

Has the security of the DNS Infrastructure Improved? (Part 1)

Introduction and objectives
With the suggestion that pharmming[1] attacks are on the increase (Leon, 2005), the security of the DNS infrastructure has come into question again.

Using qualitative research, the following questions have been investigated in this paper serial;

  1. If the Levels of Security (based on patching practices) has improved since 2000,
  2. How the TLD[2]’s and Australian servers compare to the general population of DNS Servers worldwide,
  3. How security the Internet is based on the overall level of DNS Security.
A short account of the Domain Naming Service
BIND, the Berkeley Internet Name Domain service was created by a team of computer scientists at the University of California at Berkeley. The US Defence Advanced Research Projects Administration (DARPA) funded a graduate student project to enable this research. Bind versions up to and including 4.8.3 were maintained by the Computer Systems Research Group (CSRG) at UC Berkeley. The initial BIND project team included Douglas Terry, Mark Painter, David Riggle and Songnian Zhou.

Ralph Campbell and Kevin Dunlap, continued the original work at the CSRG for 2 years--from 1985 to 1987. BIND maintenance was subsequently handled by Mike Karels and O. Kure.
BIND Version 4.9.2 was sponsored by Paul Vixie of Vixie Enterprises who became the principal architect and programmer of BIND. ISC, the Internet Software Consortium, have subsequently taken over support of BIND.

What is DNS?
DNS or the domain name system the methodology used on the Internet to translate domain names into IP (Internet Protocol) addresses. The process of maintaining a central list of domain name/IP address correspondences by host file was found to be impractical.

DNS was developed as a service to enable this process over the distributed Internet as seamlessly as possible. Every name of every computer on the Internet is translated using a DNS server.

The Basics of making a DNS server secure
DNS queries operate over UDP port 53 and Zone transfers (and certain other longer queries) operate over TCP port 53. Using security enforcing devices, such as packet filters and firewalls to filter traffic allowing only query access to the DNS server over these ports is the first step in securing your DNS.

Next, the operating system of the server running the DNS software must be secured. To do this, restrict access to authorised users only and prevent access from unauthorised users. This may seem like an oblivious statement but it is one that seems to be missed on numerous occasions (Dept. of Commerce, 2004).

Also, operating system should have the bare minimum of functionality installed, that is, no other services should run on the DNS server – it should be a bastion host. Further, file and directory permissions should be the leanest possible for normal operation.

These points are just a start; which is why many organisations have taken to outsourcing DNS (Booth, 2004).

The version of software you should run on your DNS is the latest supported version available at the time. Make sure you have all of the latest applicable security patches applied.
Securely configuring your DNS software is a must, without this important step, the integrity of your DNS will be compromised. A general rule of thumb when configuring DNS (as with most other Internet Systems) is to “Enable on that which is required, from only the locations it is required, and disable the rest” (Ashbury, 2000).

Primary DNS
The DNS software needs to be configured in such a manner as to allow:
  • Anyone, anywhere, to resolve the names of your externally visible hosts to IP Addresses and vice versa,
  • A primary DNS to forward queries for hosts it does not know to a root server (or ideally not handle forwarded requests), and
  • The primary DNS for your domain to update the configuration of the secondary DNS servers for your domain.
Secondary DNS
The software on the secondary DNS needs to be configured in such a manner as to allow:
  • Anyone, anywhere, to resolve the names of your externally visible hosts to IP Addresses and vice versa,
  • The DNS to forward queries for hosts it does not know to a root server, and
  • The primary DNS for your domain to update the configuration of the secondary DNS servers for your domain.
The threats of an insecure DNS
The threats are many, we do not plan to cover all of them in this document series and they are as limitless as one’s imagination. We will briefly cover a few in the following sections. See tomorrow for more. The threats mentioned will be broken down into the categories of those against Confidentiality, Availability and Integrity.

[1] Pharming – Attacks designed to compromise a DNS Server and use it for the attackers purpose
[2] TLD, Top Level Domains

No comments: