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(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 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.
Alıntıdı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(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 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.
Alıntıdır