Admin Server ( DNS Security )

DNS

DEFINISI DNS

DNS merupakan sistem database yang terdistribusi yang digunakan untuk pencarian

nama komputer di jaringan yang menggunakan TCP/IP. DNS mempunyai kelebihan

ukuran database yang tidak terbatas dan juga mempunyai performa yang baik. DNS

merupakan aplikasi pelayanan di internet untuk menterjemahkan domain name ke

alamat IP dan juga sebaliknya. DNS dapat dianalogikan sebagai pemakaian buku

telefon dimana orang yang ingin kita hubungi, berdasarkan nama untuk

menghubunginya dan menekan nomor telefon berdasarkan nomor dari buku telefon

tersebut. Hal ini terjadi karena komputer bekerja berdasarkan angka, dan manusia

lebih cenderung bekerja berdasarkan nama. Misalkan domain name yahoo.com

mempunyai alamat IP 202.68.0.134, tentu mengingat nama komputer lebih mudah

dibandingkan dengan mengingat alamat IP.

STRUKTUR DNS

Domain Name Space merupakan hirarki pengelompokan domain berdasarkan nama.

Domain ditentukan berdasarkan kemampuan yang ada di struktur hirarki yang disebut

level yang terdiri dari :

• Root-Level Domains : merupakan level paling atas di hirarki yang di

ekspresikan berdasarkan periode dan dilambangkan oleh “.”.

• Top-Level Domains : berisi second-level domains dan hosts yaitu :

- com : organisasi komersial, seperti IBM (ibm.com).

- edu : institusi pendidikan, seperti U.C. Berkeley

(berkeley.edu).

- org : organisasi non profit, Electronic Frontier Foundation

(eff.org).

- net : organisasi networking, NSFNET (nsf.net).

- gov : organisasi pemerintah non militer, NASA (nasa.gov).

- mil : organisasi pemerintah militer, ARMY (army.mil).

- xx : kode negara (id:Indonesia,au:Australia)

• Second-Level Domains : berisi host dan domain lain yang disebut

subdomain.

• Host Name : domain name yang digunakan dengan host

name akan menciptakan fully qualified domain name (FQDN) untuk setiap

kompueter. Contohnya, jika terdapat fileserver1.wijaya.com, fileserver1

adalah host name dan wijaya.com adalah domain name.

SERVER NAMA dan ZONA

Program yang menyimpan informasi tentang domain name space disebut server nama

(name server). Server nama biasanya mempunyai informasi yang lengkap mengenai

bagian-bagian dari domain name space yang disebut zona (zone), yang biasanya

diambil dari file atau dari Server nama lainnya. Server nama mempunyai otoritas

(authority) untuk zona tersebut, dan Server nama juga dapat mempunyai otoritas

untuk banyak zona.

Perbedaan antara sebuah zona dan sebuah domain adalah penting. Semua top-level

domain, dan banyak second-level domain dibagi menjadi unit-unit yang lebih kecil.

Unit-unit tersebut disebut zona.

DNS SECURITY

There are many facets to DNS security, ranging from relatively simple to implement to brutally complex. This chapter divides security into four topics:

• Administrative security: This part of the chapter covers the use of file permissions, server configuration, BIND configuration, and sandboxes (or chroot jails). All of these techniques are relatively simple to implement, and can (and should) be applied to stand-alone DNS servers or to servers that run DNS as one of a number of services. Administrative security is a base-line topic. All the fancy cryptographic techniques in the world are useless if the base system is unstable or has world read-and-write privileges on all the interesting files.

• Zone transfers: Unless a multimaster configuration system is being used, zone transfers are essential to normal operation. Limiting and controlling both the source and destinations of zone transfer operations using physical security, BIND parameters, or external firewalls is always prudent. Secure authentication of the source and destinations of zone transfer operations may or may not be worth the effort.

• Dynamic updates: Dynamic updates expose a master zone file to possible corruption, destruction, or poisoning. Not taking sensible precautions to limit access through either good system design, BIND parameters, firewalls, or authentication probably constitutes a misplaced reliance on the essential goodness of mankind.

• Zone integrity: If it is essential that the zone data used by either another DNS or an end host be correct (that is, query responses have not been tampered with and the returned data could only have come from the zone owner), then DNSSEC is required. DNSSEC has been the subject of considerable experimentation and subsequent change over the past three or four years.

DNS Normal Data Flow

Security Classification

The security classification is a means to allow selection of the appropriate remedies and strategies for avoiding the implied risk.

• Local threats (1): Local threats are usually the simplest to prevent, and are typically implemented simply by maintaining sound system-administration policies. All zone files and other DNS configuration files should have appropriate read and write access, and should be securely backed up or maintained in a CVS repository. Stealth (or Split) DNS servers can be used to minimize public access, and BIND can be run in a sandbox or a chroot jail (described in the section “BIND in a Chroot Jail” later in the chapter).

• Server–server (2): If an organization runs slave DNS servers, it needs to execute zone transfers. As noted earlier, it is possible to run multiple-master DNS servers rather than master–slave servers, and thus avoid any associated problems. If zone transfers are required, BIND offers multiple configuration parameters that can be used to minimize bthe inherent risks in the process. TSIG and Transaction KEY (TKEY) also offer secure methods for authenticating requesting sources and destinations. Both methods are described in detail in the section “Securing Zone Transfers” later in the chapter. The physical transfers can be secured using Secure Sockets Layer (SSL) or Transport Layer Security (TLS).

• Server–server (3): The BIND default is to deny Dynamic DNS (DDNS) from all sources. If an organization requires this feature, then BIND provides a number of configuration parameters to minimize the associated risk; these are described in detail later in the chapter. Network architecture design—that is, all systems involved are within a trusted perimeter—can further reduce the exposure. TSIG and SIG(0) can be used to secure the transactions from external sources.

• Server–client (4): The possibility of remote cache poisoning due to IP spoofing, data interception, and other hacks is likely quite low with modest web sites. However, if the site is high profile, high volume, open to competitive threat, or is a high revenue earner, then the costs and complexity of implementing a full-scale DNSSEC solution may be worthwhile. Significant effort is being invested by software developers, Registry Operators, the RIRs, and root-server operators, among many others, into DNSSEC. We are likely to see significant trickle-down effects within the near term in the public domain, as well as within controlled groups such as intranets and extranets. Indeed, Sweden will be the first country in the world to offer DNSSEC support for the .se domain starting in late 2005.

• Client–client (5): DNSSEC.bis standards define the concept of a security aware resolver—a currently mythical entity—that can elect to handle all security validation directly, with the local name server acting as a passive communications gateway.

REFERENSI

1. http://www.oreilly.com/catalog/dns3/chapter/ch02.html

2. http://www.net-security.org/dl/articles/Attacking_the_DNS_Protocol.pdf

3. http://www.insan.co.id/tutor.eng/dns.html

4. Attacking the DNS Protocol – Security Paper v2, ESA Certification,

Sainstitute.org

5. http://www.ilmukomputer.com/umum/diding-dns.php

6. http://www.sainstitute.org/articles/tools/Dns1.pl

7. http://www.sainstitute.org/articles/tools/Hds0.pl

8. http://www.sainstitute.org/articles/tools/Dnsflood.pl

9. http://www.sainstitute.org/articles/tools/DNS Hijacker