Yaklaşık olarak üç ay önce tüm ISC Bind sürümlerini etkileyen bir açıklık yayınlandı.  Açıklık DNS servisini etkilediği için çok kritikti( dns’in çalismamasi ne demek? Mail alisverisinin durmasi, web sayfalarinin çalismamasi, ISP’ler için müsterilerinin internetinin gitmesi(müsteri için dns vs yoktur internet çalisiyor ya da çalismiyordur).

Bu açıklığa göre internetin %80 gibi büyük bir oranına dns hizmeti sağlayan Bind yazılımı kullananların verdikleri dns hizmeti  uzaktan tek bir dns paketiyle kapatılabiliyordu. Açıklığın çıktığı tarihlerde -tam da Türkiye’de 3G hizmetinin duyurulduğu gün- çoğu arkadaşımı bizzat arayarak sistemlerini yamalarını sağlamıştım. Kendi yöneticilerimize de konunun ciddiyetini anlatmak için exploiti düzenleyerek(uzaktan kimin gönderdiği belli olmayacak şekilde spoof ip ile) kendi sistemlerimizde test amaçlı çalıştırmıştık.

Açıklığın üzerinden iki ay geçtikten sonra klasik araştırmalarımdan birini bu konuya ayırdım. Amacım acaba Türkiye’de konu ne kadar ciddiye alınmıştı, bizlere güvenlik hizmeti satan firmalar, güvenlik eğitimi veren kurumlar, ötesinde Türkiye’nin güvenliğini (hem sanal hem sosyal) sağlamaya çalışan kurumlar kendilerini korumaya almışlar mıydı sorusunun cevabını bulabilmekti.

Geçtiğimiz yıl yine DNS sunucuları etkileyen cache  poisoning açıklığı sonrasında yaptığımız araştırmada oran bu araştırmadan daha düşük çıkmıştı. Bunda linux/unix üzerine kurulan sistemlerin daha geç güncellendiği sonucunu çıkarmıştık.

Güvenlik Firmaları ve Bind DOS Zaafiyeti

Rastgele seçilen bilgi güvenliği firmalarının dns sunucularının %80′i hala ilgili açıklık için yama yüklememiş durumda. Bize güvenlik hizmeti veren firmalar kendi güvenliklerine dikkat etmiyorsa buradan şu sonuç çıkıyor: firmalar bu işi sadece maddi kazanç için yapıyorlar, kalite vs pek dikkate alinmiyor. Bu firmalar arasında bazılarının pentest hizmeti verdiğini de düşünürsek tam bir kendi söküğünü dikemeyen terzi durumu çıkıyor karşımıza.

ISP’ler ve Bind DOS zaafiyeti

ISP’lerin hemen hepsi bu açıklığa karşı korumasız durumda. Aralarında windows kullanan azınlık grubu saymazsak Bind kullananların çoğu güncelleme yapmamış.

Hosting firmaları ve Bind DOS Zaafiyeti

Hosting firmaları da bu konuda sınıfta kalanlardan. Hosting firmalarının çoğu kendi dns sunucusunu kullanmadığı için ISP’lerdeki zaafiyet onları da doğrudan etkiliyor. Hosting firmalarında durum %70 civarlarında. Normalde bu oranın %95 olacağını tahmin ediyordum ama aralarında Windows DNS kullananlar olduğu için oran düşük çıktı.

Üniversiteler ve Bind DOS Zaafiyeti

Güzide üniversitelerimizde açıklıktan sonra sistemlerine hiç dokunmayanlardan. Rastgele seçilen üniversitelerden çıkan sonuç %85 oranında bu zaafiyete karşı korumasız oldukları.

Eğitim kurumları ve Bind DOS Zaafiyeti

İçlerinde bilgi güvenliği , linux, sistem yönetimi vs konularında çeşitli eğitimler veren firmaların da bulunduğu test grubu da güvenliği sadece konuşmak ve satmak üzerine algılayanlardan. Eğitim kurumlarında %85 oranında Bind DOS zaafiyetinden etkileniyor.

Sonuç

Sonuç olarak Türkiye bilgi güvenliği konusunda yapılacak bir kalite testinde sınıfta kalacaktır. Tek işi güvenlik olan ve firmalara ürün satmak için onları sistemlerinde çıkabilecek açıklıklarla korkutanların kendi sistemlerini hiç dikkate almadığı görülüyor.

Çoğu sistem yöneticisinin DNS sunucularımızı X firması yönetiyor nasıl olsa onlar düşünmüştür şeklinde bir yaklaşımla hiç test etme ihtiyacı hissetmemişler. Yine Linux/UNIX sistem yöneticilerinin  biraz tembellik yaptığı sonucunu da çıkarabiliriz. Bunun temel sebebi Linux kullanıyoruz, nasıl olsa güvenlidir yaklaşımı olduğunu düşünüyorum. Oysa günümüz dünyasında artık gerçekten güvenlidir diyebileceğimiz bir sistem kalmadı. İş artık daha çok sistem/network/güvenlik yöneticilerine kalıyor.

Umarım bu sonuçlar birilerini harekete geçirir ve kendi sistemlerine de bakma ihtiyacı hissederler

Not:Testlerin yapılışı kesinlikle hedef sistemlere zarar vermeyecek şekilde sıradan dns istekleri göndererek yapılmıştır.

Not: Bu yazı yayınlandıktan 3 ay sonra tekrar bir test yapıp daha detaylı sonuçlar paylaşmayı planlıyorum.

Related posts:

1. BIND 9 Dynamic Update DoS Zaafiyeti- Acil
2. BIND 9 cache poisoning zayifligi ve OpenBSD
3. Güvenligi gercekten ciddiye aliyor muyuz-DNS Cache poisoning acikligi

Internetin çalışması için gerekli en temel protokollerden birisi DNS’dir. DNS domain isimleriyle ip adresleri arasında çözümleme yaparak bizleri ulaşmak istediğimiz sitelere/sistemlere kolaylıkla ulaştırır. Bir nevi arkadaşlarımızın cep telefon numaralarını ezberlemek yerine adres defteri kullanmak gibi.

DNS çalışmadığı zaman ne olur?

E-posta sistemi çalışmaz, web sayfalarına isimlerini kullanarak (www.google.com gibi )girişler imkansız hale gelir, kısacası internet durur.

DNS Sunucu Yazılımları

DNS hizmeti veren çeşitli sunucu yazılımlar bulunmaktadır. ISC Bind, DjbDNS, Maradns, Microsoft DNS yazılımları bunlara örnektir. Bu yazılımlar arasında en yoğun kullanıma sahip olanı ISC Bind’dır. Internetin %80 lik gibi büyük bir kısmı Bind dns yazılımı kullanmaktadır.

DOS  Atakları

DOS(Denial Of Service) hizmet dışı bırakma saldırısıdır. Bir servis DOS’a maruz kalırsa çalışmaz, bir network DOS’a maruz kalırsa ulaşılamaz. DOS saldırıları risk açısından  sınıflandırıldığında acil kategorisinde yer alır.

BIND 9 Dynamic Update DoS Zaafiyeti

28/07/2009 tarihinde ISC Bind yazılım geliştiricileri tüm Bind 9 sürümlerini etkileyen acil bir güvenlik zaafiyeti duyurdular. Duyuruya göre eğer DNS sunucunuz Bind9 çalıştırıyorsa ve üzerinde  en az bir tane yetkili kayıt varsa bu açıklıktan etkileniyor demektir.

Aslında bu bind 9 çalıştıran tüm dns sunucularını etkiler anlamına geliyor. Bunun nedeni dns sunucunuz sadece caching yapıyorsa bile üzerinde localhost için girilmiş kayıtlar bulunacaktır ve açıklık bu kayıtları değerlendirerek sisteminizi devre dışı bırakabilir.

Güvenlik Açığı Nasıl Çalışıyor?

Açıklık dns sunucunuzdaki  ilgili zone tanımı(mesela:www.lifeoverip.net) için gönderilen özel hazırlanmış dynamic dns update paketlerini düzgün işleyememesinden kaynaklanıyor.

Açıklığın sonucu olarak dns servisi veren named prosesi duruyor. Yani DNS hizmeti veremez hale geliyorsunuz.

Önlem:

Güncelleme: Açıklığı gideren yeni sürüm bind paketleri yayınlandı. Güncelleme yaparak bu açıklıktan korunabilirsiniz.Aşağıdaki adresler güncel bind paketlerine ait.

http://ftp.isc.org/isc/bind9/9.6.1-P1/bind-9.6.1-P1.tar.gz

http://ftp.isc.org/isc/bind9/9.5.1-P3/bind-9.5.1-P3.tar.gz

http://ftp.isc.org/isc/bind9/9.4.3-P3/bind-9.4.3-P3.tar.gz

Güvenlik Duvarı/IPS: Güvenlik duvarı ya da Intrusion Prevention System üzerinden dns sunucularıan gelen nsupdate mesajlarını engelleyerek açıktan korunabilirsiniz.

Snort IDS İmzası:

alert udp any any -> $HOME_NET 53 (msg:"ET CURRENT_EVENTS ISC BIND9 Update DoS"; \
content:"|00 2a 08 68 6d 61 63 2d 6d 64 35 07 73 69 67 2d 61 6c 67 03 72 65 67 03 69 6e 74 00|"; \
content:"|35 99 52 00 4e|"; classtype:misc-attack; reference:url,downloads.securityfocus.com/vulnerabilities/exploits/35848.txt; reference:url,www.isc.org/node/474; sid:2009695; rev:1;)

Linux Iptables ile engelleme: Aşağıda yazan iptables kuralı ile açıklığı network seviyesinde engelleyebilirsiniz(kural denenmemiştir, debian tartışma listesinden alıntıdır).

#iptables -A INPUT -p udp –dport 53 -j DROP -m u32 –u32 ’30>>27&0xF=5′

Kötü senaryo: DNS UDP üzerinden çalışıyor, bu açıklığın exploiti de internette dolaşıyor. Hayata küsmüş kötü niyetli bir hacker internetin çalışmasını  birkaç yüz paketle sekteye uğratabilir ve dns paketlerinde rahatlıkla ip spoofing yapılabileceği için kimin yaptığı da bulunamaz.

Açıklık ile ilgili detay bilgiler: https://www.isc.org/node/474

Açıklığın testi;

Açıklığın testi için internet ortamında çeşitli exploitler dolaşıyor. Exploitlerden birinini kendi sistemlerimi test için uyarlayıp denedim, bir iki saniye içerisinde dns servisi crash oldu.

# perl dnstest.pl
;; HEADER SECTION
;; id = 51444
;; qr = 0    opcode = UPDATE    rcode = NOERROR
;; zocount = 0  prcount = 1  upcount = 1  adcount = 1

;; ZONE SECTION (1 record)
;; test.com.        IN      SOA

;; PREREQUISITE SECTION (1 record)
www.test.com.       0       IN      ANY     ; no data

;; UPDATE SECTION (1 record)
www.test.com.       0       ANY     ANY     ; no data

;; ADDITIONAL SECTION (1 record)
<key.   0       IN      ANY     ; rdlength = 0

Bu aşamadan sonra ilgili zonu barındıran dns sunucu sorgulara cevap veremez hale geliyor.

Aug  1 16:03:52 mail named[45293]: /usr/src/lib/bind/dns/../../../contrib/bind9/lib/dns/db.c:595: REQUIRE(type != ((dns_rdatatype_t)dns_rdatatype_any)) failed
Aug  1 16:03:52 mail named[45293]: exiting (due to assertion failure)
Aug  1 16:03:52 mail kernel: pid 45293 (named), uid 0: exited on signal 6 (core dumped)

Related posts:

1. Güvenliği ciddiye alıyor musunuz? Bind DOS Zaafiyeti
2. BIND 9 cache poisoning zayifligi ve OpenBSD
3. Penetration Testing Framework 0.4 yayinlandi

Bu detay bilgiler ek parametrelerle gizlenebilir.

# dig www.lifeoverip.net

; <<>> DiG 9.3.3 <<>> www.lifeoverip.net
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47172
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;www.lifeoverip.net.            IN      A

;; ANSWER SECTION:
www.lifeoverip.net.     14400   IN      A       80.93.212.86

;; AUTHORITY SECTION:
lifeoverip.net.         30637   IN      NS      ns3.tekrom.com.
lifeoverip.net.         30637   IN      NS      ns4.tekrom.com.

;; ADDITIONAL SECTION:
ns4.tekrom.com.         91164   IN      A       70.84.223.227
ns3.tekrom.com.         165971  IN      A       70.84.223.226

;; Query time: 213 msec
;; SERVER: 195.175.39.40#53(195.175.39.40)
;; WHEN: Sat Jan 24 10:56:14 2009
;; MSG SIZE  rcvd: 130

Çıktıların Detay açıklaması

Status:NOERROR

sorgulanan domain adının var olduğunu ve bu domainden sorumlu dns sunucunun sorgulara sağlıklı cevap verdiğini gösterir.

Status:SERVFAIL

domainin olduğunu fakat domainden sorumlu DNS sunucunun sorgulara sağlıklı cevap veremediğini gösterir. Yani sorun domainden sorumlu DNS sunucusundadır.

Status:NXDOMAIN

Domain ile ilgili ana DNS sunucuların bilgisinin olmadığını gösterir. Bu da ya o domain yoktur ya da bazı sebeplerden dolayı root dns sunuculara yayınlanmamıştır manasına gelir.

Olmayan bir domain sorgulandığında cevap olarak NXDOMAIN denecektir.

[root@mail ~]# dig www.huzeyfe.net

; <<>> DiG 9.3.3 <<>> www.huzeyfe.net
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 8419
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;www.huzeyfe.net.               IN      A

;; AUTHORITY SECTION:
net.                    0       IN      SOA     a.gtld-servers.net. nstld.verisign-grs.com. 1232788241 1800 900 604800 900

;; Query time: 119 msec
;; SERVER: 195.175.39.40#53(195.175.39.40)
;; WHEN: Sat Jan 24 11:02:25 2009
;; MSG SIZE  rcvd: 106

Soru Kısmı

;; QUESTION SECTION:
;www.lifeoverip.net.            IN      A

DNS sunucuya giden sorgu kısmı.

Cevap Kısmı

;; ANSWER SECTION:
www.lifeoverip.net.     14400   IN      A       80.93.212.86

DNS sunucudan dönen cevap kısmı.

;; AUTHORITY SECTION:
lifeoverip.net.         30637   IN      NS      ns3.tekrom.com.
lifeoverip.net.         30637   IN      NS      ns4.tekrom.com.

sorgulanan domainden sorumlu dns sunucu adresleri

;; ADDITIONAL SECTION:
ns4.tekrom.com.         91164   IN      A       70.84.223.227
ns3.tekrom.com.         165971  IN      A       70.84.223.226

Ek bilgiler.

;; Query time: 213 msec

Sorgulamanın ne kadar sürdüğü.

;; SERVER: 195.175.39.40#53(195.175.39.40)

sorgulanan dns sunucu

;; WHEN: Sat Jan 24 10:56:14 2009 tarih

;; MSG SIZE  rcvd: 130 boyut
–
Dns sorgularının geçtiği sunucuları izlemek(dns trace)

Dns üzerinden sorun yaşadığınızı düşünüyorsanız sorunun kaynağını bulmak için dns trace çekilmesinde fayda var. DNs trace sorgulanan domaine ait tüm adımları detaylı bir şekilde gösterir. Böylece sorunun hangi aşamada hangi sunucudan kaynaklandığı bulunabilir.

Aşağıdaki çıktı bir istemci tarafından www.kou.edu.tr adresinin sorgulanması esnasında gidilen dns sunucularını ve onların döndüğü cevapları gösterir. Görüleceği üzere ilk olarak root serverlardan .tr uzantılı adreslerin nerede tutulduğu bilgisi alınmıştır. Sonrasında bu adreslerden birine kou.edu.tr domaininden sorumlu DNS sunucu sorulmuş ve cevap alınmıştır. Son olarak da www.kou.edu.tr domaini kou.edu.tr’den sorumlu dns sunucuya sorularak işlem tamamlanmıştır.

# dig +trace www.kou.edu.tr

; <<>> DiG 9.3.3 <<>> +trace www.kou.edu.tr
;; global options:  printcmd
.                       365519  IN      NS      B.ROOT-SERVERS.NET.
.                       365519  IN      NS      C.ROOT-SERVERS.NET.
.                       365519  IN      NS      D.ROOT-SERVERS.NET.
.                       365519  IN      NS      E.ROOT-SERVERS.NET.
.                       365519  IN      NS      F.ROOT-SERVERS.NET.
.                       365519  IN      NS      G.ROOT-SERVERS.NET.
.                       365519  IN      NS      H.ROOT-SERVERS.NET.
.                       365519  IN      NS      I.ROOT-SERVERS.NET.
.                       365519  IN      NS      J.ROOT-SERVERS.NET.
.                       365519  IN      NS      K.ROOT-SERVERS.NET.
.                       365519  IN      NS      L.ROOT-SERVERS.NET.
.                       365519  IN      NS      M.ROOT-SERVERS.NET.
.                       365519  IN      NS      A.ROOT-SERVERS.NET.
;; Received 500 bytes from 193.254.252.30#53(193.254.252.30) in 1 ms

tr.                     172800  IN      NS      NS2.NIC.tr.
tr.                     172800  IN      NS      NS3.NIC.tr.
tr.                     172800  IN      NS      NS4.NIC.tr.
tr.                     172800  IN      NS      NS5.NIC.tr.
tr.                     172800  IN      NS      NS-TR.RIPE.NET.
tr.                     172800  IN      NS      NS1.NIC.tr.
;; Received 250 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 217 ms

kou.edu.tr.             43200   IN      NS      ns.ulak.net.tr.
kou.edu.tr.             43200   IN      NS      bim.kou.edu.tr.
;; Received 92 bytes from 144.122.95.52#53(NS2.NIC.tr) in 11 ms

www.kou.edu.tr.         3600    IN      A       194.27.72.123
kou.edu.tr.             3600    IN      NS      bim.kou.edu.tr.
;; Received 82 bytes from 193.140.83.251#53(ns.ulak.net.tr) in 10 ms

–

dig ile recursive olmayan dns sorguları

dig , öntanımlı olarak recursive dns sorguları gönderir. Eğer non-recursive dns sorgulaması yaptırılmak istenirse +norec parametresi kullanılır.

# dig +norec @195.175.39.40 www.lifeoverip.net.uk

; <<>> DiG 9.3.3 <<>> +norec @195.175.39.40 www.lifeoverip.net.uk
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41339
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 11, ADDITIONAL: 13

;; QUESTION SECTION:
;www.lifeoverip.net.uk.         IN      A

;; AUTHORITY SECTION:
uk.                     1981    IN      NS      ns7.nic.uk.
uk.                     1981    IN      NS      nsc.nic.uk.
uk.                     1981    IN      NS      nsd.nic.uk.
uk.                     1981    IN      NS      nsb.nic.uk.
uk.                     1981    IN      NS      nsa.nic.uk.
uk.                     1981    IN      NS      ns2.nic.uk.
uk.                     1981    IN      NS      ns1.nic.uk.
uk.                     1981    IN      NS      ns6.nic.uk.
uk.                     1981    IN      NS      ns4.nic.uk.
uk.                     1981    IN      NS      ns5.nic.uk.
uk.                     1981    IN      NS      ns3.nic.uk.

;; ADDITIONAL SECTION:
ns5.nic.uk.             6790    IN      A       213.246.167.131
ns2.nic.uk.             6790    IN      A       217.79.164.131
nsa.nic.uk.             6790    IN      A       204.74.112.44
nsa.nic.uk.             28562   IN      AAAA    2001:502:d399::44
nsd.nic.uk.             6790    IN      A       199.7.67.44
nsd.nic.uk.             158281  IN      AAAA    2001:502:100e::44
ns4.nic.uk.             6790    IN      A       194.83.244.131
ns6.nic.uk.             6790    IN      A       213.248.254.130
nsc.nic.uk.             6790    IN      A       199.7.66.44
ns3.nic.uk.             6790    IN      A       213.219.13.131
nsb.nic.uk.             160677  IN      A       204.74.113.44
ns1.nic.uk.             6790    IN      A       195.66.240.130
ns7.nic.uk.             6790    IN      A       212.121.40.130

;; Query time: 8 msec
;; SERVER: 195.175.39.40#53(195.175.39.40)
;; WHEN: Sat Jan 24 22:43:10 2009
;; MSG SIZE  rcvd: 473

–
Dns sunucu versiyon Belirleme

DNS sunucu versiyon belirleme için standart bir yöntem yoktur. Üzerinde Bind çalışan sistemler için version.bind sorgusu işe yarar fakat başka dns sunucuları bu isteğe cevap vermezler.

# dig @ns1.tekrom.com txt chaos version.bind

; <<>> DiG 9.3.3 <<>> @ns1.tekrom.com txt chaos version.bind
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52098
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;version.bind.                  CH      TXT

;; ANSWER SECTION:
version.bind.           0       CH      TXT     “9.3.4-P1″

;; AUTHORITY SECTION:
version.bind.           0       CH      NS      version.bind.

;; Query time: 334 msec
;; SERVER: 70.84.223.230#53(70.84.223.230)
;; WHEN: Sat Jan 24 22:44:28 2009
;; MSG SIZE  rcvd: 65

Dig ile Zone Transferi

dig aracı kullanılarak zone transferine açık bir sunucudan ilgili domaine ait tüm bilgiler edinilebilir.

# dig axfr huzeyfe.net @1.2.3.4

; <<>> DiG 9.3.3 <<>> axfr huzeyfe.net @mail.lifeoverip.net
; (1 server found)
;; global options:  printcmd
huzeyfe.net.            86400   IN      SOA     ns1.gezginler.net. uyduruk.gmail.com. 2008100701 86400 7200 3600000 86400
huzeyfe.net.            14400   IN      MX      0 huzeyfe.net.
huzeyfe.net.            86400   IN      NS      ns1.gezginler.net.
huzeyfe.net.            86400   IN      NS      ns1.softlayer.com.
huzeyfe.net.            86400   IN      NS      ns2.gezginler.net.
huzeyfe.net.            86400   IN      NS      ns2.softlayer.com.
huzeyfe.net.            14400   IN      A       208.43.98.28
cpanel.huzeyfe.net.     14400   IN      A       208.43.98.28
ftp.huzeyfe.net.        14400   IN      A       208.43.98.28
localhost.huzeyfe.net.  14400   IN      A       127.0.0.1
mail.huzeyfe.net.       14400   IN      CNAME   huzeyfe.net.
webdisk.huzeyfe.net.    14400   IN      A       208.43.98.28
webmail.huzeyfe.net.    14400   IN      A       208.43.98.28
whm.huzeyfe.net.        14400   IN      A       208.43.98.28
www.huzeyfe.net.        14400   IN      CNAME   huzeyfe.net.
huzeyfe.net.            86400   IN      SOA     ns1.gezginler.net. uyduruk.gmail.com. 2008100701 86400 7200 3600000 86400
;; Query time: 18 msec
;; SERVER: 80.93.212.86#53(80.93.212.86)
;; WHEN: Sat Jan 24 11:01:31 2009
;; XFR size: 16 records (messages 1)

Değişken kaynak port  ve XID değeri testi

Rekursif DNS sunucular başka dns sunuculardan istekde bulunurken kaynak port numarasını değiştirmeyebilirler. Bu, dns protokolünün kötüye kullanılmasına sebep

olabilir. DNS sorgulamaları UDP üzerinden çalıştığı için IP spoofing yapmak kolaydır. Bu sebeple dns protokolünün güvenliği kaynak port numarası ve transaction ID

(XID) değişkenine bağlıdır. Bu iki değişken ne kadar kuvvetli olursa dns üzerinden yapılacak cache poisoning türü ataklar o kadar başarısız olacaktır.

Kaynak port değeri yeterli derecede kuvvetli olan dns sunucunun verdiği cevap

# dig +short @195.175.39.40  porttest.dns-oarc.net txt
porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
“195.175.39.228 is GREAT: 26 queries in 6.3 seconds from 26 ports with std dev 16123″

Kaynak port  değeri yeterli derecede kuvvetli olmayan dns sunucunun verdiği cevap

# dig +short @vpn.lifeoverip.net  porttest.dns-oarc.net txt
porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
“80.93.212.86 is POOR: 26 queries in 5.5 seconds from 1 ports with std dev 0″

Dig ile sorgulama zamanı (DNS yavaşlık göstergersi)

DNS sorgularınızda yavaşlık hissediyorsanız bunu dig komutunun çıktısındaki Query time değerinden öğrenebilirsiniz. Aynı adresi farklı iki dns sunucuya sorgulatıp “Query time “değerleri kontrol edilerek hangisinin daha hızlı cevap verdiği öğrenilebilir.

;; Query time: 4131 msec

Yavaş bir dns sunucu

# dig @4.2.2.1 www.bilgiguvenligi.org

; <<>> DiG 9.3.3 <<>> @4.2.2.1 www.bilgiguvenligi.org
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59504
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
…

;; Query time: 256 msec
;; SERVER: 4.2.2.1#53(4.2.2.1)
;; WHEN: Sat Jan 24 23:00:40 2009
;; MSG SIZE  rcvd: 56

Hızlı bir DNS sunucu

# dig @195.175.39.40 www.bilgiguvenligi.org

; <<>> DiG 9.3.3 <<>> @195.175.39.40 www.bilgiguvenligi.org
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46228
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

…

;; Query time: 8 msec
;; SERVER: 195.175.39.40#53(195.175.39.40)
;; WHEN: Sat Jan 24 23:00:27 2009
;; MSG SIZE  rcvd: 136

Related posts:

1. DNS Sorgularini izlemek
2. Bir sorun giderme anısı
3. DNSSEC sonrası yaşanabilecek muhtemel sorunlar

İçinde birden fazla DNS sunucu barındıranların kendi sistemlerini test etmeleri için buraya Nmap ile testlerin nasıl yapılacağını yazayım belki birilerine faydası dokunur.
Dns cache poisoning açıklığını test etmek için hedef sistemde iki değer kontrol edilir. Birincisi dns sorgulamalarında kaynak portun değiştirilmesi, diğeri de dns sorgularındaki TXID değerinin yeteri kadar random/rastgele olması. Nmap ile bu iki değeri de kontrol edebiliriz. Hatta tek bir taramada her ikisi de kontrol edilebilir.

Önce kaynak port rastgeleliğini test edelim.

# nmap -P0 -sU -p 53 –script dns-random-srcport 100.100.100.2 -vv

Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-12 11:14 GMT
Initiating Parallel DNS resolution of 1 host. at 11:14
Completed Parallel DNS resolution of 1 host. at 11:14, 0.00s elapsed
Initiating UDP Scan at 11:14
Scanning (100.100.100.2) [1 port]
Completed UDP Scan at 11:14, 2.02s elapsed (1 total ports)
SCRIPT ENGINE: Initiating script scanning.
Initiating SCRIPT ENGINE at 11:14
Discovered open port 53/udp on 100.100.100.2
Completed SCRIPT ENGINE at 11:14, 5.83s elapsed
Host host- (100.100.100.2) appears to be up … good.
Scanned at 2009-01-12 11:14:39 GMT for 8s
Interesting ports on (100.100.100.2):
PORT STATE SERVICE
53/udp open domain
|_ dns-random-srcport: 100.100.100.2 is POOR: 52 queries in 108.6 seconds from 1 ports with std dev 0

Read data files from: /usr/local/share/nmap
Nmap done: 1 IP address (1 host up) scanned in 8.04 seconds
Raw packets sent: 2 (56B) | Rcvd: 0 (0B)

Benzer şekilde txid üretecinin tahmin edilebilirligini test etmek için

# nmap -P0 -sU -p 53 –script dns-random-txid 100.100.100.2 -vv
komutu kullanılabilir.

bt scripts # nmap -P0 -sU -p 53 –script dns-random-txid 100.100.100.5 -vv

Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-12 11:50 GMT
Initiating Parallel DNS resolution of 1 host. at 11:50
Completed Parallel DNS resolution of 1 host. at 11:50, 0.10s elapsed
Initiating UDP Scan at 11:50
Scanning 100.100.100.5 [1 port]
Completed UDP Scan at 11:50, 2.02s elapsed (1 total ports)
SCRIPT ENGINE: Initiating script scanning.
Initiating SCRIPT ENGINE at 11:50
Discovered open port 53/udp on 100.100.100.5
Completed SCRIPT ENGINE at 11:50, 5.80s elapsed
Host 100.100.100.5 appears to be up … good.
Scanned at 2009-01-12 11:50:48 GMT for 8s
Interesting ports on 100.100.100.5:
PORT STATE SERVICE
53/udp open domain
|_ dns-random-txid: x.y.z.t is GREAT: 26 queries in 5.3 seconds from 26 txids with std dev 17822

Read data files from: /usr/local/share/nmap
Nmap done: 1 IP address (1 host up) scanned in 8.09 seconds
Raw packets sent: 2 (56B) | Rcvd: 0 (0B)

Her iki testi de tek bir Nmap taraması ile gerçekleştirmek için scriptler arasına “, ” koyulması yeterli olacaktır.

Nmap tarafından dns ile ilgili yapılabilecek diğer taramalar.

bt scripts # ls dns*
dns-random-srcport.nse dns-random-txid.nse dns-recursion.nse dns-test-open-recursion.nse dns-zone-transfer.nse

Related posts:

1. Nmap’i zayıflık tarama aracı olarak kullanma-NSE
2. Nmap, Unicornscan ve Hping ile performans testleri
3. Güvenligi gercekten ciddiye aliyor muyuz-DNS Cache poisoning acikligi

Verilen servisin ne kadar saglikli ciktilar urettigini test etmek isterken aklima acaba son acikliktan sonra hala dns sunucularinda gerekli onlemleri almamis birileri var mi diye merak ettim ve sonuc gercekten korkuttu. Aralarinda  devlet/özel üniversite Turkiye’nin en hassas kurumlari, telco sirketleri , medya sirketleri ve guvenlik uzerine is yapan sirketler ve bu konuda bilincli olacagini dusundugum arkadaslarin sistemleri olmak uzere 10-15 sisteme baktim .Cogu hala gerekli onlemi almamis gorunuyordu. Buradan benim cikardigim sonuc: guvenlik isini hakettigi kadar ciddiye almadigimizdir. Ne demis atalarimiz “bir musibet bin nasihatten evladir”. Henuz bizdeki hacker tayfasinin teknik kapasitesi web sayfalarini deface etmenin uzerine cikamadigi icin simdilik musibet konusunda rahatiz fakat ilerde bu bakis acisi degisecek ve web sayfalarindan istedigini elde edemeyeneler daha komplike saldiri yontemlerine basvuracak.

Aciklik ciktiktan sonra bunu duymamis olma ihtimalimiz yok ama nedense kendi sistemimize bir bakip bu zaafiyetten etkileniyor mu kontrol etmiyoruz -edenleri tenzih ederim-. Belki usengenclik belki “adam sendecilik” ne dersek diyelim  bir yerler eksiklik kaliyor hep…

Related posts:

1. Güvenliği ciddiye alıyor musunuz? Bind DOS Zaafiyeti
2. Nmap NSE kullanarak DNS Cache Poisoning Zafiyeti Testleri
3. BIND 9 cache poisoning zayifligi ve OpenBSD

Birkac gun once detaylarina buradan -ve teknik olarak buradan-erisebileceginiz bir DNS protokolu zaafiyeti yayinlandi. Zaafiyetin kotuye kullanilmasi sonucu bu acigi barindiran (Internetin %99′u diyebiliriz) dns sunucularin cachelerinin zehirlenmesi ihtimali var.

Yukarıda verdigim adreste zaafiyet icin onerilen maddelerden biri de DNS sunucularin sorgulama yaparken rastgele kaynak port kullanmalari idi. Bildigim kadari ile DJBdns haric bunu native saglayan dns sunucu/istemci yazilimi yok.

Packet Filter gibi Nat yaparken kaynak portlari degistirebilen(cogu Firewall bunu yapar) bir Firewall kullaniyorsaniz DNS sunucunuzun udp 53 cikislarini nat yaparak cikarirsaniz kaynak port numalari rastgele secilmis olur.

Asagidaki ornekleme OpenBSD named ve PF ile gerceklenmistir.

PF ile NAT yapmadan cikis yapan bir DNS sunucudan yapilan sorgulamalar

# nslookup
> server 127.0.0.1
Default server: 127.0.0.1
Address: 127.0.0.1#53
> www.google.com
Server: 127.0.0.1
Address: 127.0.0.1#53

Non-authoritative answer:
www.google.com canonical name = www.l.google.com.
Name: www.l.google.com
Address: 74.125.39.103
Name: www.l.google.com
Address: 74.125.39.147
Name: www.l.google.com
Address: 74.125.39.99
Name: www.l.google.com
Address: 74.125.39.104
> www.lifeoverip.net
Server: 127.0.0.1
Address: 127.0.0.1#53

Non-authoritative answer:
Name: www.lifeoverip.net
Address: 80.93.212.86
> set q=a
> www.huzeyfe.net
Server: 127.0.0.1
Address: 127.0.0.1#53

Non-authoritative answer:
Name: www.huzeyfe.net
Address: 80.93.212.86
> www.cnn.com
Server: 127.0.0.1
Address: 127.0.0.1#53

Non-authoritative answer:
Name: www.cnn.com
Address: 64.236.91.23
Name: www.cnn.com
Address: 64.236.16.20
Name: www.cnn.com
Address: 64.236.16.52
Name: www.cnn.com
Address: 64.236.24.12
Name: www.cnn.com
Address: 64.236.29.120
Name: www.cnn.com
Address: 64.236.91.21
> exit

Bu isteklerin cikisini tcpdump ile izledigimizde asagidaki sonuclari aliriz.

# tcpdump -ttnn udp port 53
tcpdump: listening on vic0, link-type EN10MB
1214527060.000368 192.168.2.23.26926 > 192.33.14.30.53: 52135% [1au] A? www.huzeyfe.net. (44)
(43)
1214527060.202598 192.168.2.23.26926 > 70.84.223.230.53: 26205% [1au] AAAA? jet.tekrom.com. (43)
1214527060.202728 192.168.2.23.26926 > 70.84.223.230.53: 45553% [1au] A? ns3.tekrom.com. (43)
1214527060.202918 192.168.2.23.26926 > 70.84.223.230.53: 9887% [1au] AAAA? ns3.tekrom.com. (43)
1214527060.203064 192.168.2.23.26926 > 70.84.223.230.53: 19219% [1au] A? ns4.tekrom.com. (43)
1214527060.203171 192.168.2.23.26926 > 70.84.223.230.53: 9937% [1au] AAAA? ns4.tekrom.com. (43)
1214527060.478490 70.84.223.230.53 > 192.168.2.23.26926: 23575*- 1/2/3 A 74.52.0.226 (127) (DF)
1214527060.479070 192.168.2.23.26926 > 70.84.223.226.53: 5700% [1au] A? www.huzeyfe.net. (44)
1214527060.483016 70.84.223.230.53 > 192.168.2.23.26926: 26205*- 0/1/1 (91) (DF)
1214527060.487206 70.84.223.230.53 > 192.168.2.23.26926: 45553*- 1/2/2 A 70.84.223.226 (107) (DF)
1214527060.492574 70.84.223.230.53 > 192.168.2.23.26926: 9887*- 0/1/1 (87) (DF)
1214527060.496554 70.84.223.230.53 > 192.168.2.23.26926: 19219*- 1/2/2 A 70.84.223.227 (107) (DF)
1214527060.501199 70.84.223.230.53 > 192.168.2.23.26926: 9937*- 0/1/1 (91) (DF)
1214527060.756220 70.84.223.226.53 > 192.168.2.23.26926: 5700- 0/13/1 (252) (DF)
1214527060.756753 192.168.2.23.26926 > 70.84.223.227.53: 58800% [1au] A? www.huzeyfe.net. (44)
1214527061.031910 70.84.223.227.53 > 192.168.2.23.26926: 58800- 0/13/1 (252) (DF)
1214527061.032272 192.168.2.23.26926 > 74.52.0.226.53: 54605% [1au] A? www.huzeyfe.net. (44)
1214527061.309713 74.52.0.226.53 > 192.168.2.23.26926: 54605*- 1/2/3 A 80.93.212.86 (138) (DF)
1214527081.550135 192.168.2.23.26926 > 192.26.92.30.53: 48697% [1au] A? www.cnn.com. (40)
1214527081.694272 192.26.92.30.53 > 192.168.2.23.26926: 48697- 0/4/5 (203) (DF)
1214527081.695022 192.168.2.23.26926 > 205.188.146.88.53: 10679% [1au] A? www.cnn.com. (40)
1214527081.851653 205.188.146.88.53 > 192.168.2.23.26926: 10679- 0/2/3 (123) (DF)

Dikkat edilecek olursa tum dns istekleri ayni kaynak porttan cikiyor…

Packet Filter ile cikis yonundeki UDP 53 ler icin NAT islemi uyguladiktan sonra ayni islemleri tekrarlayalim

Sorgulamalar

# nslookup
> server 127.0.0.1
Default server: 127.0.0.1
Address: 127.0.0.1#53
> set query=a
> www.lifeoverip.net
Server: 127.0.0.1
Address: 127.0.0.1#53

Non-authoritative answer:
Name: www.lifeoverip.net
Address: 80.93.212.86
> www.linux.com
Server: 127.0.0.1
Address: 127.0.0.1#53

Non-authoritative answer:
www.linux.com canonical name = linux.com.
Name: linux.com
Address: 216.34.181.51
> www.fazlamesai.net
Server: 127.0.0.1
Address: 127.0.0.1#53

Non-authoritative answer:
Name: www.fazlamesai.net
Address: 82.222.181.125
> netsec.lifeoverip.net
Server: 127.0.0.1
Address: 127.0.0.1#53

Non-authoritative answer:
Name: netsec.lifeoverip.net
Address: 80.93.212.86

Sorgualamarin tcpdump ciktisi

# tcpdump -ttnn udp port 53
tcpdump: listening on vic0, link-type EN10MB
1214527500.423316 192.168.2.23.55819 > 192.42.93.30.53: 15093% [1au] A? www.linux.com. (42)
1214527500.692729 192.42.93.30.53 > 192.168.2.23.55819: 15093- 0/3/4 (168) (DF)
1214527500.694008 192.168.2.23.63085 > 12.31.165.79.53: 8055% [1au] A? www.linux.com. (42)
1214527500.991152 12.31.165.79.53 > 192.168.2.23.63085: 8055*- 2/0/0 CNAME linux.com., (61) (DF)
1214527500.995350 192.168.2.23.60810 > 216.34.181.21.53: 732% [1au] A? linux.com. (38)
1214527501.165336 216.34.181.21.53 > 192.168.2.23.60810: 732*- 1/0/0 A 216.34.181.51 (43) (DF)
1214527515.105501 192.168.2.23.63168 > 192.54.112.30.53: 38190% [1au] A? www.fazlamesai.net. (47)
1214527515.176086 192.54.112.30.53 > 192.168.2.23.63168: 38190- 0/2/1 (97) (DF)
1214527515.177442 192.168.2.23.52894 > 199.19.57.1.53: 13823% [1au] A? ns1.fazlamesai.org. (47)
1214527515.177701 192.168.2.23.52894 > 199.19.57.1.53: 63052% [1au] AAAA? ns1.fazlamesai.org. (47)
1214527515.177963 192.168.2.23.52894 > 199.19.57.1.53: 52497% [1au] A? ns2.fazlamesai.org. (47)
1214527515.178148 192.168.2.23.52894 > 199.19.57.1.53: 19103% [1au] AAAA? ns2.fazlamesai.org. (47)
1214527515.251261 199.19.57.1.53 > 192.168.2.23.52894: 13823- 0/2/3 (111) (DF)
1214527515.251972 192.168.2.23.57625 > 195.33.233.59.53: 64528% [1au] A? ns1.fazlamesai.org. (47)
1214527515.256090 199.19.57.1.53 > 192.168.2.23.52894: 63052- 0/2/3 (111) (DF)
1214527515.256721 192.168.2.23.57625 > 195.33.233.59.53: 19139% [1au] AAAA? ns1.fazlamesai.org. (47)
1214527515.260952 199.19.57.1.53 > 192.168.2.23.52894: 52497- 0/2/3 (111) (DF)
1214527515.261360 192.168.2.23.57625 > 195.33.233.59.53: 2367% [1au] A? ns2.fazlamesai.org. (47)
1214527515.265682 199.19.57.1.53 > 192.168.2.23.52894: 19103- 0/2/3 (111) (DF)
1214527515.266223 192.168.2.23.57625 > 195.33.233.59.53: 19193% [1au] AAAA? ns2.fazlamesai.org. (47)
1214527515.695411 192.168.2.23.57625 > 195.33.233.59.53: 22141% [1au] A? www.fazlamesai.net. (47)
1214527515.764586 192.168.2.23.61756 > 82.222.181.125.53: 51328% [1au] A? ns1.fazlamesai.org. (47)
1214527515.764749 192.168.2.23.61756 > 82.222.181.125.53: 60964% [1au] AAAA? ns1.fazlamesai.org. (47)
1214527515.764895 192.168.2.23.61756 > 82.222.181.125.53: 48058% [1au] A? ns2.fazlamesai.org. (47)
1214527515.779404 82.222.181.125.53 > 192.168.2.23.61756: 51328* 1/2/2 A 82.222.181.125 (111) (DF)
1214527515.779909 192.168.2.23.61756 > 82.222.181.125.53: 11798% [1au] AAAA? ns2.fazlamesai.org. (47)
1214527515.785161 82.222.181.125.53 > 192.168.2.23.61756: 60964* 0/1/1 (94) (DF)
1214527515.789313 82.222.181.125.53 > 192.168.2.23.61756: 48058* 1/2/2 A 212.175.237.162 (111) (DF)
1214527515.794834 82.222.181.125.53 > 192.168.2.23.61756: 11798* 0/1/1 (98) (DF)
1214527516.215004 192.168.2.23.61756 > 82.222.181.125.53: 54317% [1au] A? www.fazlamesai.net. (47)
1214527516.228870 82.222.181.125.53 > 192.168.2.23.61756: 54317* 1/2/3 A 82.222.181.125 (145) (DF)
1214527540.838462 192.168.2.23.62275 > 70.84.223.227.53: 2944% [1au] A? netsec.lifeoverip.net. (50)
1214527541.105514 70.84.223.227.53 > 192.168.2.23.62275: 2944*- 1/2/3 A[|domain] (DF)

Gorulecegi uzere nat yapinca kaynak portlar rastgele olarak degisiyor…

Ek:

http://blogs.iss.net/archive/morednsnat.html

https://www.dns-oarc.net/

Related posts:

1. OpenBSD Packet Filter Guvenlik Zaafiyeti
2. OpenBSD Packet Filter Web Arabirimi
3. OpenBSD Packet Filter yük dengelemede FTP kullanımı

OpenDNS’e uye oluyorsunuz -> Uyelik sayfasindan ip araliginizi belirtiyorsunuz->Hangi kategorilerdeki iceriklerin bloklanacagini seciyorsunuz(Klasik icerik filtreleme sistemlerindeki gibi)->Sonra aginizda DNS sunucu olarak OpenDNS’în adreslerini veriyorsunuz ve boylece ek bir islem, yatirim yapmadan hizli bir icerik filtreleyiciye sahip oluyorsunuz.

OpenDNS’i kullanan istemci sayisinin 5 milyon oldugu ve bu sayinin hergecen gun arttigi dusunulurse yakin gelecekte piyasada dolasan icerik filtreleme sistemlerine ciddi bir rakip geliyor demektir.

Icerik filtreleme sistemlerde en onemli iki husus performans ve bloklanacak site veritabanidir.(Buna bir de loglama ve raporlama ekleyebiliriz). Performans konusunda OpenDNS’i gececek bir uygulama olmayacaktir zira daha dns sorgulama esnasinda istekler filtrelenecektir. Bu sistemi Spam engelleme icin kullandigimiz RBL Listelerine benzetebiliriz.

OpenDNS’în site veritabani henuz cok gelismis degil ama gonullu kullanicilar tarafindan her gecen gun siteler kategorilendiriliyor ve veritabani buyuyor.

Genel olarak dusunuldugunde hem ucretsiz olmasi hem de kurulum, bakim gibi kaynak gerektirecek islemleri olmamasi benim gozumde OpenDNS’i gelecegin icerik filtreleme sistemi olarakust siralara yerlestiriyor. Buyuk sirketler icin degil fakat orta olcekli ve kucuk olcekli sirketler icin denenesi bir cozum.

Tabi burada gozden kacirilmamasi gereken durum OpenDNS’in sizin tum DNS trafiginize hakim olmasi ki bu da sizin trafiginiz uzerinde istenilen islemin OpenDNS tarafindan yapilabilecegi manasina geliyor.

Related posts:

1. TIB tarafindan Onaylanan Icerik Filtreleme Yazilimlari
2. Google & Yahoo kullanarak icerik filtreleyicileri atlatmak
3. Anonim proxyler ve Icerik filtreleme sistemleri

Konsol erisimimi oldugu zaman genelde dig komutu(arabirimde gorulen sorgulamalarin hemen  hepsini dig komutu ile basarmak mumkun) ile halledebiliyorum fakat her zaman her yerden konsola direkt erisimi mumkun olmuyor, dahasi sonuclarini baskalari ile paylasmak gerektiginde web uzerinden goruntulemek daha kolay oluyor.

Kisa bir arastirma sonrasi kullanilabilecek 3 site belirledim. Bunlar gibi onlarcasi var ama cogu ise yaramaz ya da benim istedigim ozelliklerin azini sagliyor.

http://www.freednsinfo.com/

http://www.iptools.com/ Cok amacli dns sorgulamalari icin
http://www.intodns.com/ DNS hatalarini raporlama icin

Simdilik benim tercihim www.iptools.com.

No related posts.

Yani kotu niyetli sahis kendisine bir dns sunucu kuruyor ve Turkiye’de cesitli siteler yasaklandiginda kendisi uzerinen insanlari o sitelere eristiriyor. Kotu niyetli sahis belli bir zaman bu sekilde calisip guven kazaniyor ve dns adresleri iyice populer oluyor, gazetelere, forum sitelerine haber oluyor.

Sonra kendisi uzerinden yapilan dns sorgulamalarinin onbinlerce/yuzbinlerce oldugu gun geliyor ve harekete geciyor. Istedigi site icin dns kayitlari girerek kendisini DNS sunucu olarak goren sistemlerin trafigini istedigi gibi yonetiyor. Buradan artik uzerinden dns trafigini gecirdigi kullanicilarin banka hesaplarina mi ulasir yoksa tum trafigi istedigi bir siteye yonlendirerek dos saldirisi mi olusturur, phishing saldirilarinda mi kullanir tamamen kisinin insiyatifine ve bilgisine kalmis.

Sonuc olarak bilmediginiz, guvenmediginiz sistemlerin DNS adreslerini kullanmamak lazim. Ic aglardan disariya DNS isteklerine izin vermemek-kullanicilarin baska dns sunucularini kullanmasini engellemek icin- ve dns forwarder olarak belirli, guvenilir adresleri kullanmak sirket politikasi olarak belirlenmeli.

Vakti zamaninda bunun sıkıntısını cekmistim. Guvenerek forwarder olarak kullandigim bir dns sunucusu kendi uzerinde hostingi birakan bir firmanin kayitlarini hala kendisinde gosterince ve sorumlu oldugum sistemlerden giden maillerin baska ellere gittigini ogrenince sok olmustum ama bana ders olmustu:)

Related posts:

1. Youtube yasagi ve saksiya dikilen cam agaci?
2. Devlet Sitelerine Yönelik DDoS Saldırıları
3. Protokoller arasi yonlendirme- tcp2udp forwarding

ihtiyacim oldu. Cok uzun zaman önce benzer bir ihtiyac icin ISC bind kullanmistim ve nasil yapildigi aklimda kalmamisti. Bind kitabimi elime alarak anahtar kelime “view” ile ilgili konulara bir gözattim(burdan herseyi bilmek yerine anahtar kelimeleri bilerek is cikarmanin faydasini goruyoruz. tipki pointerlar misali)… Sonuclarini burda paylasmayi uygun gordum.

Amacimi biraz daha acayim:

DMZ bolgesinde bir adet DNS sunucunuz var ve bu dns sunucu hem sizin sahip oldugunuz domainler icin yetkili durumda(yani internetten example.com’a gelecek sorgulari karsilayan) hem de ic agda bulundurdugunuz cache-only dns sunucunuz icin forwarder görevi görüyor.

Intranet.example.com adli bir alan adini sadece ic aga acmak istiyorsunuz. Bunun icin DMZ bolgesinde gireceginiz kayit tüm internete açik olacaktir. Bu sebeple ya intranetteki DNS sunucuya bir sekilde ek kayitlar girmenin yolunu bulacaksiniz ya da DNS sunucunuzda bazi domainler icin sadece belirli(Yerel ag ip bloklari)iplerden gelen istekler icin cevap vermesini saglayacaksiniz.

Sadece bu tip istekler için degil , çok daha farkli durumlarda DNS sunucularin farkli ip/network ler için farkli cevaplar vermesi gerekebilir.

Örnek:

view “yerel_ag” {
match-clients { 192.168.0.0/24; }; // Yerel AG IP Blogu
recursion yes;
zone “lifeoverip.net” {
type master;
file “master/lifeoverip.net.in”;
};
};

view “dis_dunya” {
match-clients {“any”; };

recursion no; //Recursive sorgulamalara izin yok!

zone “lifeoverip.net” {
type master;
file “master/lifeoverip.net.out”;
};
};

NOT: Eklenecek tum zone’lar viewlar icerisinde tanimlanmis olmali.

Sonrasinda master/lifeoverip.net.in dosyasina ic agdan gelen istekler icin dondurmek istedigimiz cevabi , master/lifeoverip.net.out dosyasina da dis dunyadan gelecek sorgulamalara donmek istedigimiz cevabi uygun formatta yazarak bind’i restart etmemiz gerekir.

Bundan sonra lifeoverip.net domaini icin yapilan sorgulamalar 192′li ip blogundan geliyorsa farkli cevaplancakti, bunun haricinde bir ip araligindan geliyorsa farkli cevaplanacaktir.

Burada yapilan islemler UNIX/Linux sistemler üzerinde kullanılan bind yazılımı için geçerlidir.

Windows sistemlerle birlikte gelen DNS sunucu yazilimi kullanarak farkli ip adreslerinden(ip bloklari) gelen istekler icin farkli tanimlar yapmak mümkün degil. (Arastirmalarim ve bilgisine guvendigim Windows adminlerden aldigim cevaplara istinaden soyluyorum).

Related posts:

1. Web Sunucularda Asayis Berkemal-Webekci
2. BIND 9 Dynamic Update DoS Zaafiyeti- Acil
3. OpenBSD Packet Filter yük dengelemede FTP kullanımı