BIND, DNS`in bir implementasyonu olan Berkeley Internet Name Domain sistemidir. DNS bir yazılım değil RFC 1034/U`de belirtilen ve RFC 1035/U`de tanımlanan bir protokol spesifikasyonudur. Host isimlerinin IP adreslerine eşlenmesini ve bunun tersinin etkili olarak yapılabilmesini sağlayan ve Internet`teki sitelerin sistem yöneticileri tarafından bakımı yapılan, Host isimleri ve IP adreslerinin tutulduğu dağıtık (distributed) veritabanlarından oluşan bir sistemdir. BIND, DNS`i uygulayan bir yazılım pakedidir. Günümüzde Internet`te DNS servisi sağlamada en çok kullanılan yazılım BIND`dir. Hemen hemen tüm Unix çeşitlerinde (BSD`ler ve Linux gibi ücretsiz olanlar dahil) çalışır. Bir Windows sürümüde mevcuttur. BIND`i hiç Windows`da kullanmadığım için tamamen Unix-tabanlı implementasyonlari üzerinde duracağım. Tabi fikirler ve bazı durumlarda prosedürler Windows`a da uymaktadır.
Bunu yazarken, DNS sunucularının güvenliği ile ilgili bazı konularda (tecrübelerime göre ya atlanan ya da gözardı edilen) detaylara inmek istedim. Amacım kısa bir altyapı bilgisi vermek, BIND`ın tarihsel olarak karşılaştığı saldırıları tanımlamak ve BIND kurulumunuzu tamamen güvenli hale getirebilecek bazı detayları anlatmak. Ayrıca BIND`ı güvenli hale getirmede işletim sistemi ile etkileşmesine de değinecegim ve BIND`ın kendi güvenlik özelliklerinin dışına çıkacağım. Bu özellikleri (ör. named( ve named.conf(5) zone transferlerinin neden ve nasıl belirli hostlara kısıtlanabileceğini anlatır) uzun olarak anlatan çeşitli dokümanlar var.
‘TSIG/SPAN’ yazısında, Richard Biever bu metodlardan birinden bahsediyor ve kendi implementasyonunda bulunan bir hafıza taşmasını tanımlıyor. Bazıları tarafından Unix sistem yönetiminin incili olarak düşünülen Evi Nemeth`in ‘The Unix System Administration Handbook’unda da BIND için DNSSec güvenlik uzantılari anlatılmakta ve BIND`ın sorguları güvenli kılmak için uyguladığı diğer mekanizmalardan bahsediliyor. TSIG takas mekanizmasında bir hafıza taşması bulundu fakat bu fix edildi ve kullanılmamasi için bir sebep değil. Tabi BIND`in en son sürümünü kullanmanız için geçerli bir sebep.

Saldırılar Neler?
Kendimizi korumadan önce, kendimizi neye karşı koruyacağımızı bilmemiz gerekir. Tarihsel olarak, BIND`ın çeşitli saldırılara karşı zayıflıkları vardı. Bunların çoğu servisin devamlılığına ya da bütünlüğüne yapılan saldırılardı. Önce bunlardan bahsedeceğim.

Servisin Engellenmesi (Denial of Service)
Bir servis engelleme (çogu zaman DoS olarak geçer) saldırısı, genelde, bir saldırganın, herkese açtığınız servisinize erişimi engellemesidir. Bir DoS saldırısının BIND sunucusuna etkili olabilmesi için ya bir hafıza taşması exploit`inin (saldırılan makinadaki beklenmeyen bir konfigürasyon veya durum sonucunda) başarasızlığa uğraması ya da kodunun, saldırıda hafıza taşmasında uzaktan erişim sağlayacak bir exploit`e izin vermeyecek şekilde yazılmış olması gerekmektedir. Sonuçta genel olarak named daemon kapanır (killed). Bir DoS saldırısını etkilemek için daha pek çok yol vardır.
BIND`a karşı gerçekleştirilen örnek bir DoS saldırısı Security Focus/U`da detaylı olarak yayınlanmıştır. Etkilenen BIND sürümlerine sıkıştırılmış zone transferleri sorgusu yapıldığında named daemon çöküyor ve DoS saldırısı ile sonuçlanıyor. Bu tip saldırının çözümü (pek çok zayıflıkta olduğu gibi) etkilenmeyen bir sürüme güncellemek veya etkilenen sürüme yama (patch) geçmek.

Hafıza Taşması/Uzaktan Exploit etmek
Tarihsel olarak BIND, saldırganın bir işlemin execution stack`i üzerine yazmasına ve ele geçirilen işlemin (process) sahip olduğu imtiyazlarla istediği kodu çalıştırabilmesine izin veren çeşitli hafıza taşmasi problemlerinden etkilenmiştir. Aleph One tarafından yazılmış olan ‘The Stack For Fun And Profit/U’ bu işlemleri detaylı olarak anlatmaktadır. Richard Biever`in yazısında (yukarıda belirtildi) bahsedilen zayıflık bu tip saldırılara izin veriyor.

Cache Zehirleme
Cache zehirleme saldırganın uzaktaki DNS sunucusunun DNS cache`ine doğru olmayan IP adresi bilgileri ekleyebilmesine izin verir ve spoof edilen siteye gitmesi gereken trafik, saldırganın sitesine yada rastgele bir hedefe yönlendirilir. Daha detaylı bilgi Doug Sax`ın ‘DNS Spoofing Malicious Cache Poisoning’ yazısından edinilebilir. Bazı cache poisoning saldırılarından daha kısıtlayıcı konfigürasyonlarla korunulabilir fakat bazıları için etkilenmeyen sürümlere güncelleme gerekir.

Domain ele geçirme (Hijack)
Cache zehirleme saldırısına benzer olarak, domain ele geçirme, saldırganın bir sitenin tümü için DNS`i kontrol edebilmesine izin verir. Bu saldiri genelde sitenin ana DNS sunucusunu tamamen ele geçirerek yada social engineering (sosyal mühendislik) ile domain`i kayıt edenleri saldırganın hedef siteden sorumlu olduğuna inandirmakla gerçekleştirilir. Doug Sax`ın DNS Spoofing yazısında bundan da bahsediliyor.

Saldırıları nasıl durdurursunuz?
DNS sunucunuzun sağlam ve güvenli durumda olduğuna emin olmak için alınabilecek bazı önlemler vardır. Hepsi birlikte kullanıldığında makinanızın güvende olduğuna emin olabilirsiniz (en azından BIND`ın şu an bilinen açıklarından etkilenmediğine emin olabilirsiniz). En kötü durum senaryosunda, rapor edilmemiş (ve bu sebeple fix edilmemiş) bir zayıflığa saldıran bir saldırgan sunucunuza karşı bir DoS saldırısı gerçekleştirip etkileyebilir.

root-olmayan kullanıcı ile çalıştırmak
Çoğu isim sunucusuna büyük zarar verilebilmesinin sebebi named`in varsayılan olarak root yetkisiyle çalıştırılmasıdır. Fakat, root olarak çalışmasına gerek yoktur ve gerçekten root olarak çalıştırmak için geçerli iyi bir sebep yoktur. Sistem yöneticisinin named`i çalıştırmada kullanıcı ve grup seçebilmesi için iki seçenek sunulmuştur:
-u named`in çalıştırılacaği kullanıcıyı belirleme
-g named`in çalıştırılacağı grubu belirleme
Örneğin, ‘named’ adında bir kullanıcı ve ‘named’ adında bir grup yarattıysanız, named`i (genelde /etc/rc.* içindeki bir init script`ten) aşağıdaki gibi çalıştırırsınız:
/usr/sbin/named -u named -g named
named`i root olarak çalıştırmayarak bir saldırganın isim sunucusunu ele geçirince verebileceği hasarı (root olmak için başka bir yol bulmadıklarını varsayarak) büyük ölçüde azaltmış olursunuz.
Not: BIND 9 -g seçeneğini desteklemiyor. Eğer BIND 8`den BIND 9`a güncelliyorsanız init script`inizde named`i başlatmada (-g yi kullanmayacak şekilde) değişiklik yapmanız gerekli.

Dosya ve dizin hakları
DNS güvenliği hakkında okuduğum yazı ve kitapların çoğu bu konuyu gözardı ediyorlardı. Ayrıca meslektaşlarımında DNS güvenliği konularındaki tartışmalarında dosya haklarından bahsettiklerine nadiren rastladım. Fakat, DNS sunucunuzun ilgili dosyalarının izinlerini ve sahipliklerini dikkatlice ayarlayarak (ve DNS sunucunuzu root olmayan bir kullanıcı ile çalıştırıyorsanız) bir saldırganın verebileceği hasarı büyük ölçüde sınırlayabilirsiniz. Eğer bir saldırgan DNS sunucunuza erişim sağlarsa ve dosyalarınızın sahibi named`i çalıştıran kullanıcı ise, hala pek çok zarar verebilir. Trafiği sitenizden başka bir siteye yönlendirecek şekilde verileri değiştirebilir veya verileri tamamen silerek siz yedeklerden tekrar açana kadar sunucunuzu kapatabilir.
Eğer DNS sunucunuz kendi domain`iniz yada bir başkasının domain`i için yedek sunucu (slave) ise, izinler ana sunucuda olduğundan daha az kısıtlayacı olmalıdır. Bunun sebebi, ana sunucudan indirdikleri zone dosyalarının kopyalarını yazabilmeye ihtiyaç duyarlar fakat ana sunucuda bir zone dosyası yazmasına gerek yoktur.
Sadece Ana Sunucu
Ana (Master) sunucu durumunda, zone`larınızın üzerine saldırganlar tarafından yazılmaması için izinleri olabildiğince kısıtlamalısınız.
NameD2i çalıştıran kullanıcının dosyaların üzerine yazamadığına emin olmak için dosyalara ve bulundukları dizinlere bakmalısınız. zone dosyalarının tutulduğu dizin genelde ‘/var/named’ dir fakat sizin sisteminizde farklı yerde de olabilir. Ben örneğimde /var/named kullanacağım:
/var/named`in sahiplik ve izin bilgileri aşağıdaki gibi olmalı:
drwxr-x— 3 root named 1024 Mar 13 16:49 /var/named
root kullanıcısı dosyaların sahibi ve sadece root`un bu dizine yazma izni var. Bu başka bir kullanıcının o dizin içerisinde dosyalar yaratabilmesini yada içindeki dosyaları silebilmesini engeller. Dizinin ‘named’ grubu tarafından hem okuma hemde çalıştırma izinleri olmalıdırki named daemon dosyaları okuyabilsin. Eğer dosyaları okuyamazsa sorgulara cevap veremez! Dizinin grup olarak sahibini ‘named’ yapmak named daemon`un (yukardaki örneğimizde named grubu olarak çalışıyordu) o dizindeki dosyalara erişebilmesini sağlar fakat kendisinin yada onun kontrolüne sahip bir saldırganın dizin içerisinde dosya yaratıp silebilmesine izin vermez. named grubunda olmayan ve root olmayan kullanıcılar bu dizine ve içerisindeki dosyalara erişemez.
Diğer kullanıcıların bu dosyaları root olmadan veya named grubunda olmadan okuyabilmelerini istiyorsanız dizine diğer kullanıcılar için okuma/çalıştırma izinlerini vermede çok büyük bir zarar yoktur. Fakat makinede güvenilmeyen kullanıcılar varsa bu kullanıcıların erişimini engellemek için ‘diğer’ (other) kategorisi için izinleri kapalı tutmalısınız.
zone dosyaları bu dizin içerisinde bulunur ve dizininkine benzer fakat sıradan bir dosya için daha uygun izinlere sahiptirler:
-r–r–r– 1 root root 19484 Apr 10 16:59 db.yourdomain
-r–r–r– 1 root root 2835 Aug 31 2000 named.ca
-r–r–r– 1 root root 488 Aug 31 2000 named.local
-r–r–r– 1 root root 577 Dec 20 19:18 rev.1.2.3
Yine, bu dosyaların herkes tarafından okunabilir olması fakat yazılamıyor olması gereklidir. Bu dosyalarda, dosyalar yazılabilir olsa da olmasa da, root olarak değişiklikler yapabilirsiniz. Sistemde hiçbir dosyanın named kullanıcısı için yazma iznine sahip olması gerekmemektedir. Hakları bu şekilde set ederek, saldırgan named`deki yaması geçilmemiş bir açıktan yararlanarak sisteme girse dahi, burdaki dosyalara yazamayacaktır.

Yedek (Slave) sunucu
Eğer yedek sunucunuzu konfigür ediyoranız seçenekleriniz biraz daha kısıtlı. Problem şu ki, named kullanıcı hem zone transferi esnasında geçici zone dosyalarını yazabiliyor olmalı hemde transfer bittikten sonra zone dosyalarını yazabiliyor olmalı. Buna izin vermenin riskleri bahsettiğimiz tekniklerle azaltılabilir fakat yinede riski fazladır ve başka şansınız da yok. Hakları aşağıdakine benzer bir şekilde ayarlamak zorundasınız:
drwxrwx–T 3 root named 1024 Mar 13 16:49 /var/named
Aşina olmayanlar için, sondaki ‘T’ ‘sticky bit’tir. Bir dizinde set edildiğinde kullanıcı o dizindeki dosyanın sahibi değilse silemez. Tabi dosyanın kendisine yazma izinleri varsa, dosyanın üzerine yazabilir yada boyutunu ‘0’ yapabilir. Niye ‘sticky bit’i set ettiğimizi birazdan açıklayacağım. İşte dizine bu izinleri set edecek olan komut:
# chmod 1770 /var/named
Burdaki ‘1’ ‘sticky bit’i temsil etmektedir.
Çoğu durumda bu dizindeki dosyaların izinleri için endişelenmenize gerek yok. Bu değişikliği yaptığınızda ikincil zone dosyalarınız zaten bulunuyorsa, sahiplerinin named grup ve kullanıcısı olduğuna emin olmalısınız. Örneğin:
-rw-r–r– 1 named named 2835 Aug 31 2000 db.secondary
Eğer yoklarsa, birşey yapmanıza gerek yok çünkü yedek sunucunuz ihtiyacı olan dosyaları uygun izinlerle yaratacaktır. İki dosya dışında. Biri sunucuyu root isim sunucularına yönlendiren ‘cache’ dosyası, diğeri de isim sunucusunun 127.0.0.1 adresini localhost ismine çözmesini sağlayan ‘local’ dosyası. Bu dosyaları ana sunucudan indirmek gerekmediğinden yazılabilir olmalarına gerek yoktur. Onların sahibini root yapıp diğer kullanıcılar tarafından salt-okunabilir yaparak koruyabiliriz.
-r–r–r– 1 root root 2835 Aug 31 2000 named.ca
-r–r–r– 1 root root 488 Aug 31 2000 named.local
İşte sticky bit burda işe yarıyor. Eğer set etmeseydik, named grubundan herhangi biri bu dosyaları silip yenilerini yazabilirdi. Named kullanıcısı bu dosyaların sahibi olmadığından, sticky bit bunun gerçekleşmesini engeller.

Ana/Yedek sunucu kombinasyonu
Sadece yedek sunucu durumundaki kuralların aynısı dizin için geçerlidir. Dizinin named daemon tarafından yazılabilir olması gerekmektedir. Mümkün olduğunda, dizindeki dosyaların sahibi root olmalı ve salt-okunur olmalıdır. Sadece ‘slave’ domain`lerin zone dosyalarının yazılabilir olması (ve named daemon bunları yaratacak) gerekmektedir.

chroot ortamda (environment) çalıştırma
Yukardaki tavsiyeleri takip ederek, bir saldırganın gerçekleştirebileceği zararı named`i ‘chroot-ed’ bir ortamda çalıştırarak daha da azaltabilirsiniz. Unix chroot(2) sistem çağrısı bir işlemin (process) ana dizinini, işlemin dosya-sistemi hiyerarşisinde o dizin dışındaki dosyalara erişimini kapatacak şekilde, değiştirir. Named`i çalıştırmak için gerekli olan önemli dosyalar (ve sanal olarak tüm programlar) bu dizinlerde bulunduğundan bazı ayarlamalar yapmak gerekmektedir.
Scott Wunsch, Linux dokümantasyon projesinin bir parçası olarak ‘Chroot-BIND HOWTO’ adında mükemmel bir yazı hazırlamış. Doküman BIND`ı chroot ortamda çalıştırma ayarlarını adım-adım detaylı olarak anlatıyor. LDP Linux üzerine yoğunlaşmış olsa da bu doküman genel olarak named için geçerli. (Bazı dizinleri ve diğer bazı detayları kendi işletim sisteminize göre ayarlamanız gerekli).
Bu dokümanda yazar BIND`ın kaynak kodundan tekrar derlenmesini gerektiren bazı değişiklikler öneriyor. Aşağıdaki öneriler takip edildiğinde tekrar derlemek gerekli değil. Aşağıdakiler o dokümanın, BIND`ı tekrar derlemenizi gerektirmeyecek uygun değişiklerle ve benim görüşümle yazarın değinmediği bir iki ek ile, kısa bir özeti. Named`i chroot ortamda çalıştırmak için gerekli tüm bilgileri bu bölümde edinebilirsiniz. Zaten çalışan bir BIND kurulumunuz olduğunu ve zone dosyalarınızın /var/named dizininde olduğunu varsayıyorum.
1. Dizin yapısını yaratın
chroot ortamınız için bir dizin seçin. Ben kendi named ana dizinim için /var/nroot u seçtim. Sonra içerisinde aşağıdakilerin hepsini yaratın:
# cd /var/nroot
# mkdir bin
# mkdir dev
# mkdir etc
# mkdir lib
# mkdir -p usr/sbin
# mkdir -p var/named
# mkdir var/run
2. Gerekli dosyaları kopyalayın
Chroot ayarlı named dosyasisteminin geri kalanına erişemeyeceğinden ihtiyacı olan tüm dosyaların yeni ana dizine kopyalanması gerekmektedir. /dev/null u kendiniz yaratmalısınız (yada sistem yönetimi araçlarını kullanarak bir kopyasını yaratmalısınız), ve named`in ihtiyaç duyduğu paylaşılan kütüphane ve binary`leri kopyalamalısınız. Yeni bir /var/nroot/dev/null yaratmanın tam komutu sisteminize göre, eğer Linux çalıştırmıyorsanız cihazınızın major ve minor numaraları yüzünden, değişebilir. Ayrıca /dev/zero nun bir kopyasını yaratmanız gerekebilir. Detaylar için man sayfalarına bakın.
Önce yeni /dev/null u yapın:
# mknod /var/nroot/dev/null c 1 3
# chmod 666 /var/nroot/dev/null
Şimdi kütüphaneleri ve diğer gerekli dosyaları kopyalayın. named`in sisteminizde hangi kütüphanelere linkli olduğunu bulmak için ldd kullanmanız gerekebilir. Yada named`i The Internet Software Consortium (ISC) anasayfasında mevcut olan kaynak kodlarından statik olarak tekrar derleyebilirsiniz. Ayrıca named`in log mesajlarında doğru zamanı loglayabilmesi için (eğer sisteminizde varsa) /etc/localtime dosyasını kopyalamanız gerekebilir. Çoğu Linux sistemde aşağıdakiler yeterlidir:
# cp /etc/localtime /var/nroot/etc/
# cp /sbin/ldconfig /var/nroot/bin/
# cp /usr/sbin/named /var/nroot/usr/sbin/
# cp /usr/sbin/named-xfer /var/nroot/usr/sbin/
# cp -p /lib/libc*.so /var/nroot/lib
# cp -p /lib/ld*.so /var/nroot/lib
Son iki komut kütüphaneleri kopyalar. Kütüphaneleri ayrıca ‘genel’ (common) isimlerine sembolik linklemeniz gerekli. Örneğin, yeni bir Linux sistemde, standart C kütüphanesinin libc.so.6 isminde olması bekleniyor, bu sebeple onu gerçek kütüphane dosyasına sembolik linklemeniz (symlink) lazım. Ayrıca kopyaladığınız ld*.so dosyasının ismine dynamic link loader için sembolik link yaratmanız lazım. Bu aşamayı gerçekleştirmeden önce, /lib dizinizde varolan sembolik linklerin nasıl yaratıldığına bakın ve chroot ortamında sembolik linkleri uygun olarak yarattığınıza emin olun. Benim sistemimde komutlar aşağıdaki gibi:
# cd /var/nroot/lib
# ln -s libc-2.1.3.so libc.so.6
# ln -s ld-2.1.3.so ld-linux.so.2
GNU ld veya benzerini kullanan sistemlerde, linkleyiciyi etc/ld.so.cache dosyasını yaratarak konfigür etmeniz gerekebilir. Bunu yeni ortamda ldconfig`i çalıştırarak yapabilirsiniz:
# chroot /var/nroot /bin/ldconfig
Son olarak, içinde named grubunun olduğu bir grup dosyası yaratmalısınız. Bu named`i çalıştırdığınız -g seçeneğinde belirlediğiniz ile aynı grup. Aşağıdaki bunun için yeterli:
# grep `^named:` /etc/group > /var/nroot/etc/group
# chmod 444 /var/nroot/etc/group
3. named verilerini kopyalayın.
Named verilerini yeni ortama kopyalamalısınız. Çoğu sistemde bu veriler /var/named de tutulur. Dizin yapımızı yarattığımızda bu dizini yaratmıştık (/var/nroot/var/named). Verileri yeni yerlerine aşağıdaki gibi kopyalıyoruz:
# cp /etc/named.conf
# cp -rp /var/named/* /var/nroot/var/named/
4. Loglama
Çoğu sistemde, programlar mesajları syslog`a bir socket ile loglarlar, /dev/log. Sisteminizde syslog`un başka bir socket`te mesajları dinlemesini söylemeniz mümkün olmayabilir fakat yeni BSD-tipi syslog daemon`larda -a seçeneği ile ek socket`ler belirlemek mümkün. Bu tip bir syslogd`ye sahipseniz, chroot named`iniz için loglamayı ayarlamak kolay. Syslog`u tekrar başlatırken chroot dizin ağacında bir yerlerde bulunan ek soketi aşağıdaki gibi belirleyin:
# syslogd -a /var/nroot/dev/log
Eğer bu tip bir syslogd varsa, named`i yerel dosyalara loglayacak şekilde konfigür edebilirsiniz. Bunu named.conf dosyasındaki logging{} alanında belirleyebilirsiniz. Detaylı bilgi için named.conf(5) man sayfalarına bakın.
5. ndc kullanımı (seçime bağlı)
BIND named`i kontrol için ndc (name daemon control) isimli bir program içerir. Kişisel olarak, ben hiç ndc kullanmadım, kill komutu kullanmayı tercih ederim. Eğer ndc kullanacaksanız kontrol soketinin chroot dizin ağacında nerede olduğunu söylemeniz gerekir. Named`i çalıştırdığınızda /var/nroot/var/run da yaratılmış olması gerekir. Bu yüzden, ndc`yi çalıştırırken aşağıdaki yazımı kullanmalısınız:
# ndc -c /var/nroot/var/run/ndc [seçenekler] [komut]
Eğer kontrol soketinin yerini belirlemek istemiyorsanız, kaynak kodunu edinip Scott Wunsch`un ‘Chroot-BIND HOWTO’ yazısında belirttiği değişiklikleri yaptıktan sonra tekrar derlemeniz gerekli. Eğer ndc komutunu sık olarak kullanıyorsanız anlatılanları yapmanız önemli.
Hepsi bu kadar. Artık saldırganların chroot ana dizini dışındaki dosyaları değiştirebilmesini engelleyen, chroot ortamda çalışan bir BIND`ınız var.

Yama, yama, yama
Bunu defalarca söylemek gerekiyor: Hem BIND için hemde çalıştırdığınız tüm diğer yazılımlar için güncel yamaları geçmelisiniz. Çoğu zaman, bir saldırgan sisteme girdiğinde, güvenlik açığı eski, bilinen bir açık oluyor. Bu tuzağa düşmeyin! ISC`nin web sitesini ziyaret ederek BIND`da bulunan güvenlik açıklarından haberdar olabilirsiniz. Genelde güvenlik açıklarını fix`i ile birlikte anons ederler.
Ayrıca, BIND`ın üzerinde çalıştığı makinenin sadece DNS sunucusu olarak kullanılmasıda önemli. üzerinde güvenlik açıkları olabilecek çeşitli programlar kurulu olabilir. Kurduğunuz programları bilin; eğer özellikle o yazılıma ihtiyacınız yoksa kaldırın! En kötü kod bile eğer sistem değilse zararsızdır. İhtiyacınız olan programların güncel olduğuna emin olun.

Savunmayı derinlemesine kullanın
Kriptografi uzmanı ve Secrets and Lies`ın yazarı Bruce Schneier`in dediği gibi ‘Güvenlik bir işlemdir (process), ürün değildir’. Yukarda anlatılan önlemleri uyguladığınızda BIND kurulumunuz (en azından günümüz için) çok güvenli hale gelse de DNS sunucunuzu güvenli hale getirmek için daha yapılacak çok şey vardır. Örneğin, makinanın kendisi. İyi bir savunma SANS/GIAC Security Essentials yazarlarının ‘derinlemesine savunma’ dedikleri, çoklu-bağlayıcı (multi-tiered) yaklaşım kullanır.
BIND`ın kendisini güvenli hale getirmeye ek olarak, tüm güvenlik resmine bir bakın. Bir sunucuyu güvenli hale getirmek bir evi güvenli hale getirmeye çok benzer. Sunucunuzun ağınıza izinsiz girilmesini zorlaştıracak iyi konfigür edilmiş bir güvenlik duvarı arkasında olmasını sağlayın. Evinizin çevresindeki çit gibi. Dış savunma sistemlerinizi geçmeyi başaranları durdurmak için host-tabanlı güvenlik duvarı kullanın. Bir evde güvenlik sistemi kullanmak gibi.
Şifreler bir sistemin anahtarlarıdır; sizin (ve kullanıcılarınızın!) iyi, güvenli şifreler seçmesi önemli. Kapılarınız için güçlü kilitler kullanmanız gibi. Tüm bu savunma sistemlerini , saldırı tespit sistemleri ile (IDS), SAINT gibi host-tabanlı zayıflık tarayıcıları ile, nmap gibi ağ zayıflık tarayıcıları ile ve lOphtcrack veya John the Ripper gibi şifre denetleme araçları ile düzenli olarak denetleyin.
İşletim sisteminizi ve yazılımlarınızın yamalarını düzenli olarak geçin. Evinizdeki bozuk kilitleri onarmak gibi. Ve aile bireylerini evin güvenliği konusunda uyardığınız gibi güvenlik konusnuda kendinizi, iş arkadaşlarınızı ve kullanıcılarınızı eğitmelisiniz. Güvenlik açıklarının duyurulduğu Bugtraq gibi mesaj listelerine üye olabilirsiniz. Ayrıca güvenlik açıkları, exploitler, güvenlik araçları, ticari ürünler ve daha fazlasını bulabileceğiniz güvenlik konusunda mükemmel bir site olan Security Focus/U web sitesine göz atabilirsiniz. BIND`ın tarihsel zayıflıklarını araştırırken çoğunlukla ordan yararlandım.
Ayrıca, yazımda anlatmadığım, BIND`ın daha iyi güvenlik sağlayan, zone transferlerini kısıtlayan bir kaç dahili metodu var. Bunlar IP-tabanlı kimlik tanılama ile veya TSIG (simetrik kriptolama tabanlı) ile veya DNSSEC (asimetrik kriptolama tabanlı) kimlik tanılaması ile yapılabilir.