|
BIND, DNS`in bir implementasyonu olan Berkeley Internet Name Domain sistemidir. DNS bir yazilim degil color=#0000cc RFC 1034/U`de belirtilen ve color=#0000cc RFC 1035/U`de tanimlanan bir protokol spesifikasyonudur. Host isimlerinin IP adreslerine eslenmesini ve bunun tersinin etkili olarak yapilabilmesini saglayan ve Internet`teki sitelerin sistem yöneticileri tarafindan bakimi yapilan, Host isimleri ve IP adreslerinin tutuldugu dagitik (distributed) veritabanlarindan olusan bir sistemdir. BIND, DNS`i uygulayan bir yazilim pakedidir. Günümüzde Internet`te DNS servisi saglamada en çok kullanilan yazilim BIND`dir. Hemen hemen tüm Unix çesitlerinde (BSD`ler ve Linux gibi ücretsiz olanlar dahil) çalisir. Bir Windows sürümüde mevcuttur. BIND`i hiç Windows`da kullanmadigim için tamamen Unix-tabanli implementasyonlari üzerinde duracagim. Tabi fikirler ve bazi durumlarda prosedürler Windows`a da uymaktadir.
Bunu yazarken, DNS sunucularinin güvenligi ile ilgili bazi konularda (tecrübelerime göre ya atlanan ya da gözardi edilen) detaylara inmek istedim. Amacim kisa bir altyapi bilgisi vermek, BIND`in tarihsel olarak karsilastigi saldirilari tanimlamak ve BIND kurulumunuzu tamamen güvenli hale getirebilecek bazi detaylari anlatmak. Ayrica BIND`i güvenli hale getirmede isletim sistemi ile etkilesmesine de deginecegim ve BIND`in kendi güvenlik özelliklerinin disina çikacagim. Bu özellikleri (ör. named(8) ve named.conf(5) zone transferlerinin neden ve nasil belirli hostlara kisitlanabilecegini anlatir) uzun olarak anlatan çesitli dokümanlar var.
’ color=#0000cc TSIG/SPAN’ yazisinda, Richard Biever bu metodlardan birinden bahsediyor ve kendi implementasyonunda bulunan bir hafiza tasmasini tanimliyor. Bazilari tarafindan Unix sistem yönetiminin incili olarak düsünülen Evi Nemeth`in ’The Unix System Administration Handbook’unda da BIND için DNSSec güvenlik uzantilari anlatilmakta ve BIND`in sorgulari güvenli kilmak için uyguladigi diger mekanizmalardan bahsediliyor. TSIG takas mekanizmasinda bir hafiza tasmasi bulundu fakat bu fix edildi ve kullanilmamasi için bir sebep degil. Tabi BIND`in en son sürümünü kullanmaniz için geçerli bir sebep.
Saldirilar Neler?
Kendimizi korumadan önce, kendimizi neye karsi koruyacagimizi bilmemiz gerekir. Tarihsel olarak, BIND`in çesitli saldirilara karsi zayifliklari vardi. Bunlarin çogu servisin devamliligina ya da bütünlügüne yapilan saldirilardi. Önce bunlardan bahsedecegim.
Servisin Engellenmesi (Denial of Service)
Bir servis engelleme (çogu zaman DoS olarak geçer) saldirisi, genelde, bir saldirganin, herkese açtiginiz servisinize erisimi engellemesidir. Bir DoS saldirisinin BIND sunucusuna etkili olabilmesi için ya bir hafiza tasmasi exploit`inin (saldirilan makinadaki beklenmeyen bir konfigürasyon veya durum sonucunda) basarasizliga ugramasi ya da kodunun, saldirida hafiza tasmasinda uzaktan erisim saglayacak bir exploit`e izin vermeyecek sekilde yazilmis olmasi gerekmektedir. Sonuçta genel olarak named daemon kapanir (killed). Bir DoS saldirisini etkilemek için daha pek çok yol vardir.
BIND`a karsi gerçeklestirilen örnek bir DoS saldirisi color=#0000cc Security Focus/U`da detayli olarak yayinlanmistir. Etkilenen BIND sürümlerine sikistirilmis zone transferleri sorgusu yapildiginda named daemon çöküyor ve DoS saldirisi ile sonuçlaniyor. Bu tip saldirinin çözümü (pek çok zayiflikta oldugu gibi) etkilenmeyen bir sürüme güncellemek veya etkilenen sürüme yama (patch) geçmek.
Hafiza Tasmasi/Uzaktan Exploit etmek
Tarihsel olarak BIND, saldirganin bir islemin execution stack`i üzerine yazmasina ve ele geçirilen islemin (process) sahip oldugu imtiyazlarla istedigi kodu çalistirabilmesine izin veren çesitli hafiza tasmasi problemlerinden etkilenmistir. Aleph One tarafindan yazilmis olan ’ color=#0000cc The Stack For Fun And Profit/U’ bu islemleri detayli olarak anlatmaktadir. Richard Biever`in yazisinda (yukarida belirtildi) bahsedilen zayiflik bu tip saldirilara izin veriyor.
Cache Zehirleme
Cache zehirleme saldirganin uzaktaki DNS sunucusunun DNS cache`ine dogru olmayan IP adresi bilgileri ekleyebilmesine izin verir ve spoof edilen siteye gitmesi gereken trafik, saldirganin sitesine yada rastgele bir hedefe yönlendirilir. Daha detayli bilgi Doug Sax`in ’ color=#0000cc DNS Spoofing Malicious Cache Poisoning’ yazisindan edinilebilir. Bazi cache poisoning saldirilarindan daha kisitlayici konfigürasyonlarla korunulabilir fakat bazilari için etkilenmeyen sürümlere güncelleme gerekir.
Domain ele geçirme (Hijack)
Cache zehirleme saldirisina benzer olarak, domain ele geçirme, saldirganin 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 kayit edenleri saldirganin hedef siteden sorumlu olduguna inandirmakla gerçeklestirilir. Doug Sax`in DNS Spoofing yazisinda bundan da bahsediliyor.
Saldirilari nasil durdurursunuz?
DNS sunucunuzun saglam ve güvenli durumda olduguna emin olmak için alinabilecek bazi önlemler vardir. Hepsi birlikte kullanildiginda makinanizin güvende olduguna emin olabilirsiniz (en azindan BIND`in su an bilinen açiklarindan etkilenmedigine emin olabilirsiniz). En kötü durum senaryosunda, rapor edilmemis (ve bu sebeple fix edilmemis) bir zayifliga saldiran bir saldirgan sunucunuza karsi bir DoS saldirisi gerçeklestirip etkileyebilir.
root-olmayan kullanici ile çalistirmak
Çogu isim sunucusuna büyük zarar verilebilmesinin sebebi named`in varsayilan olarak root yetkisiyle çalistirilmasidir. Fakat, root olarak çalismasina gerek yoktur ve gerçekten root olarak çalistirmak için geçerli iyi bir sebep yoktur. Sistem yöneticisinin named`i çalistirmada kullanici ve grup seçebilmesi için iki seçenek sunulmustur:
-u named`in çalistirilacagi kullaniciyi belirleme
-g named`in çalistirilacagi grubu belirleme
Örnegin, ’named’ adinda bir kullanici ve ’named’ adinda bir grup yarattiysaniz, named`i (genelde /etc/rc.* içindeki bir init script`ten) asagidaki gibi çalistirirsiniz:
/usr/sbin/named -u named -g named
named`i root olarak çalistirmayarak bir saldirganin isim sunucusunu ele geçirince verebilecegi hasari (root olmak için baska bir yol bulmadiklarini varsayarak) büyük ölçüde azaltmis olursunuz.
Not: BIND 9 -g seçenegini desteklemiyor. Eger BIND 8`den BIND 9`a güncelliyorsaniz init script`inizde named`i baslatmada (-g yi kullanmayacak sekilde) degisiklik yapmaniz gerekli.
Dosya ve dizin haklari
DNS güvenligi hakkinda okudugum yazi ve kitaplarin çogu bu konuyu gözardi ediyorlardi. Ayrica meslektaslariminda DNS güvenligi konularindaki tartismalarinda dosya haklarindan bahsettiklerine nadiren rastladim. Fakat, DNS sunucunuzun ilgili dosyalarinin izinlerini ve sahipliklerini dikkatlice ayarlayarak (ve DNS sunucunuzu root olmayan bir kullanici ile çalistiriyorsaniz) bir saldirganin verebilecegi hasari büyük ölçüde sinirlayabilirsiniz. Eger bir saldirgan DNS sunucunuza erisim saglarsa ve dosyalarinizin sahibi named`i çalistiran kullanici ise, hala pek çok zarar verebilir. Trafigi sitenizden baska bir siteye yönlendirecek sekilde verileri degistirebilir veya verileri |
