BIND`i güvenli hale getirme: DNS sunucunuzun hack`lenmesini nleyin. c: 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 yneticileri tarafından bakımı yapılan, Host isimleri ve IP adreslerinin tutulduğu dağıtık 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 ç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 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(8) 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 ynetiminin 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 Bir servis engelleme 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 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 . 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ü etkilenmeyen bir sürüme güncellemek veya etkilenen sürüme yama 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 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 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 ynlendirilir. 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 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 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 ktü durum senaryosunda, rapor edilmemiş (ve bu sebeple fix edilmemi&#351 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 yneticisinin 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 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ı 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 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 gzardı 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 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 ynlendirecek ş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 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 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 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' 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 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 ynlendiren '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 alıntı www.powerdarbe.com/Enigma