DNS

Domain Name System (DNS) internetin ayrılmaz bir parçasıdır. Örneğin, https://mail.google.com/ veya www.google.com gibi domain isimleri aracılığıyla, hosting sağlayıcısının bir veya daha fazla spesifik IP adresi atadığı web sunucularına ulaşabiliriz. DNS, bilgisayar adlarını IP adreslerine çözümleyen bir sistemdir ve merkezi bir veritabanına sahip değildir. Basitleştirirsek, birçok farklı telefon rehberinin bulunduğu bir kütüphane gibi düşünebiliriz. Bilgiler binlerce name server üzerinden dağıtılır. Küresel olarak dağıtılmış DNS sunucuları domain isimlerini IP adreslerine çevirir ve böylece bir kullanıcının belirli bir domain üzerinden hangi sunucuya ulaşabileceğini kontrol eder. Dünya çapında kullanılan çeşitli DNS sunucuları vardır:

DNS Root Server

DNS’nin root sunucuları üst düzey alan adlarından (TLD) sorumludur. Son örnek olarak, yalnızca name server yanıt vermezse talep edilirler. Bu nedenle root sunucusu, domain ve IP adresini birbirine bağladığı için kullanıcılar ve İnternet’teki içerik arasında merkezi bir arayüzdür. Internet Corporation for Assigned Names and Numbers (ICANN) root isim sunucularının çalışmalarını koordine eder. Dünya çapında bu tür 13 root sunucusu bulunmaktadır.

Authoritative Nameserver

Authoritative name server’lar belirli bir bölge için yetki sahibidir. Yalnızca kendi sorumluluk alanlarındaki sorgulara yanıt verirler ve bilgileri bağlayıcıdır. Yetkili bir name sunucusu bir istemcinin sorgusunu yanıtlayamazsa, o noktada root name sunucusu görevi devralır.

Non-authoritative Nameserver

Non-authoritative name sunucuları belirli bir DNS bölgesinden sorumlu değildir. Bunun yerine, belirli DNS bölgeleri hakkında bilgi toplarlar ve bunu özyinelemeli veya yinelemeli DNS sorgulaması kullanarak yaparlar.

Caching DNS Server

Caching DNS sunucuları, diğer ad sunucularından gelen bilgileri belirli bir süre için önbelleğe alır. Bu depolama süresini yetkili ad (authoritative) sunucusu belirler.

Forwarding Server (Yönlendirme Sunucusu)

Yönlendirme sunucularının tek bir işlevi vardır: DNS sorgularını başka bir DNS sunucusuna iletirler.

Resolver (Çözümleyici)

Çözümleyiciler yetkili DNS sunucuları değildir, ancak ad çözümlemesini bilgisayarda veya yönlendiricide yerel olarak gerçekleştirir.

DNS çoğunlukla şifrelenmemiştir. Bu nedenle yerel WLAN’daki cihazlar ve İnternet sağlayıcıları DNS sorgularını hackleyebilir ve gözetleyebilir. Bu bir gizlilik riski oluşturduğundan, artık DNS şifrelemesi için bazı çözümler bulunmaktadır. Varsayılan olarak BT güvenlik uzmanları burada TLS üzerinden DNS (DoT) veya HTTPS üzerinden DNS (DoH) uygular. Buna ek olarak, ağ protokolü DNSCrypt de bilgisayar ile isim sunucusu arasındaki trafiği şifreler.

Ancak, DNS yalnızca bilgisayar adları ve IP adresleri arasında bağlantı kurmaz. Aynı zamanda bir domain ile ilişkili hizmetler hakkında ek bilgileri de depolar ve çıktı olarak verir. Bu nedenle bir DNS sorgusu, örneğin hangi bilgisayarın söz konusu alan adı için e-posta sunucusu olarak hizmet verdiğini veya domainin name serverlarının ne olarak adlandırıldığını belirlemek için de kullanılabilir.

DNS sorguları için farklı DNS kayıtları kullanılır ve bunların hepsinin çeşitli görevleri vardır. Ayrıca, bir domain için posta sunucuları ve diğer sunucular kurabileceğimizden, farklı işlevler için ayrı kayıtlar mevcuttur.

SOA kaydı bir domainin bölge dosyasında bulunur ve domainin işletilmesinden kimin sorumlu olduğunu ve domain için DNS bilgilerinin nasıl yönetildiğini belirtir.

E-posta adresinde nokta (.) yerine at işareti (@) kullanılır. Bu örnekte, yöneticinin e-posta adresi awsdns-hostmaster@amazon.com’dur.

Varsayılan Yapılandırma

DNS için birçok farklı yapılandırma türü vardır. Bu nedenle, yönetimsel bakış açısından işlevsel prensibi daha iyi göstermek için sadece en önemlilerini tartışacağız. Tüm DNS sunucuları üç farklı türde yapılandırma dosyası ile çalışır:

DNS sunucusu Bind9 Linux tabanlı dağıtımlarda sıklıkla kullanılır. Yerel yapılandırma dosyası (named.conf) kabaca iki bölüme ayrılır, birincisi genel ayarlar için seçenekler bölümü ve ikincisi bireysel domain’ler için bölge girişleri. Yerel yapılandırma dosyaları genellikle:

Sunucuyu ihtiyaçlarımıza göre özelleştirebileceğimiz ilişkili RFC’yi ve farklı domainler için ayrı bölgelerle domain yapımızı içerir. named.conf yapılandırma dosyası, name server’ın davranışını kontrol eden çeşitli seçeneklere ayrılmıştır. Global seçenekler ve bölge seçenekleri arasında bir ayrım yapılır.

Global seçenekler geneldir ve tüm bölgeleri etkiler. Bir bölge seçeneği yalnızca atandığı bölgeyi etkiler. named.conf dosyasında listelenmeyen seçeneklerin varsayılan değerleri vardır. Bir seçenek hem global hem de bölgeye özgü ise, bölge seçeneği önceliklidir.

Local DNS Configuration

Bu dosyada farklı bölgeleri tanımlayabiliriz. Bu bölgeler, çoğu durumda yalnızca bir domain için tasarlanmış olan ayrı dosyalara bölünmüştür. İstisnalar ISP ve genel DNS sunucularıdır. Ek olarak, birçok farklı seçenek işlevselliği genişletir veya azaltır. Bunlara Bind9'un belgelerinden bakabiliriz.

Zone dosyası, bir DNS bölgesini BIND dosya biçimiyle tanımlayan bir metin dosyasıdır. Başka bir deyişle, DNS ağacında bir temsilci noktasıdır. BIND dosya biçimi, sektörde tercih edilen bölge dosyası biçimidir ve DNS sunucu yazılımında artık iyice yerleşmiştir. Bir bölge dosyası bir bölgeyi tamamen tanımlar. Tam olarak bir SOA kaydı ve en az bir NS kaydı bulunmalıdır. SOA kaynak kaydı genellikle bir bölge dosyasının başında yer alır. Bu global kuralların temel amacı bölge dosyalarının okunabilirliğini artırmaktır. Bir sözdizimi hatası genellikle tüm bölge dosyasının kullanılamaz olarak kabul edilmesine neden olur. Name sunucusu, bu bölge yokmuş gibi benzer şekilde davranır. DNS sorgularına SERVFAIL hata iletisiyle yanıt verir.

Kısacası burada tüm forward kayıtları BIND formatına göre girilir. Bu, DNS sunucusunun IP adreslerinin hangi domain, hostname ve role ait olduğunu belirlemesini sağlar. Basit bir ifadeyle, bu, DNS sunucusunun aradığı domainler için adresleri aradığı telefon defteridir.

Zone Files

IP adresinin Fully Qualified Domain Name’den (FQDN) çözümlenebilmesi için DNS sunucusunun bir reverse lookup dosyasına sahip olması gerekir. Bu dosyada, bilgisayar adı (FQDN) bir PTR kaydı kullanılarak ilgili ana bilgisayara karşılık gelen bir IP adresinin son sekizlisine atanır. PTR kayıtları, yukarıdaki tabloda daha önce gördüğümüz gibi IP adreslerinin isimlere ters çevrilmesinden sorumludur.

Reverse Name Resolution Zone Files

Tehlikeli Ayarlar

Bir DNS sunucusunun saldırıya uğrayabileceği birçok yol vardır. Örneğin, BIND9 sunucusunu hedef alan güvenlik açıklarının bir listesi CVEdetails adresinde bulunabilir. Buna ek olarak, SecurityTrails DNS sunucularına yönelik en popüler saldırıların kısa bir listesini sunmaktadır.

Aşağıda görebileceğiniz bazı ayarlar, diğerlerinin yanı sıra bu güvenlik açıklarına da yol açmaktadır. DNS çok karmaşık hale gelebildiğinden ve hataların bu hizmete sızması çok kolay olduğundan, bir yöneticiyi kesin bir çözüm bulana kadar sorunun etrafında çalışmaya zorlar. Bu durum genellikle altyapının bazı kısımlarının planlandığı ve istendiği gibi çalışması için unsurların serbest bırakılmasına yol açar. Bu gibi durumlarda, işlevsellik güvenlikten daha yüksek bir önceliğe sahiptir ve bu da yanlış yapılandırmalara ve güvenlik açıklarına yol açar.

Footprinting the Service

DNS sunucularındaki ayak izi, gönderdiğimiz isteklerin bir sonucu olarak yapılır. Yani öncelikle DNS sunucusunun başka hangi name serverları bildiği sorgulanabilir. Bunu NS kaydını ve @ karakterini kullanarak sorgulamak istediğimiz DNS sunucusunun belirtimini kullanarak yaparız. Bunun nedeni, başka DNS sunucuları varsa, onları da kullanabilir ve kayıtları sorgulayabiliriz. Ancak, diğer DNS sunucuları farklı yapılandırılmış olabilir ve ayrıca diğer bölgeler için kalıcı olabilir.

Bazen CHAOS sınıfı bir sorgu ve TXT türü kullanarak bir DNS sunucusunun sürümünü sorgulamak da mümkündür. Ancak, bu girdinin DNS sunucusunda mevcut olması gerekir. Bunun için aşağıdaki komutu kullanabiliriz:

DIG — Version Query

Mevcut tüm kayıtları görüntülemek için ANY seçeneğini kullanabiliriz. Bu, sunucunun bize ifşa etmeye istekli olduğu tüm mevcut girişleri göstermesine neden olacaktır. Bölgelerdeki tüm girişlerin gösterilmeyeceğine dikkat etmek önemlidir.

DIG — ANY Query

Zone aktarımı, DNS’de bölgelerin başka bir sunucuya aktarılması anlamına gelir ve genellikle TCP bağlantı noktası 53 üzerinden gerçekleşir. Bu prosedür Asynchronous Full Transfer Zone (AXFR) olarak kısaltılır. Bir DNS arızası genellikle bir şirket için ciddi sonuçlar doğurduğundan, bölge dosyası neredeyse her zaman birkaç name server’da aynı tutulur. Değişiklikler yapıldığında, tüm sunucuların aynı verilere sahip olduğundan emin olunmalıdır. İlgili sunucular arasındaki senkronizasyon zone transferi ile gerçekleştirilir. Başlangıçta varsayılan yapılandırmada gördüğümüz gizli bir anahtar rndc-key kullanarak, sunucular kendi master veya slave’leri ile iletişim kurduklarından emin olurlar. Zone transferi sadece dosya veya kayıtların transferini ve ilgili sunucuların veri setlerindeki tutarsızlıkların tespitini içerir.

Bir bölgenin orijinal verileri, bu bölge için primer name server olarak adlandırılan bir DNS sunucusunda bulunur. Ancak, güvenilirliği artırmak, basit bir yük dağılımı gerçekleştirmek veya birincil sunucuyu saldırılardan korumak için, pratikte hemen hemen tüm durumlarda bu bölge için sekonder name server olarak adlandırılan bir veya daha fazla ek sunucu kurulur. Bazı Üst Düzey Etki Alanları (TLD’ler) için, İkinci Düzey Etki Alanlarına ait bölge dosyalarının en az iki sunucuda erişilebilir hale getirilmesi zorunludur.

DNS girişleri genellikle yalnızca birincil sunucuda oluşturulur, değiştirilir veya silinir. Bu, ilgili bölge dosyasını manuel olarak düzenleyerek veya bir veritabanından dinamik bir güncelleme ile otomatik olarak yapılabilir. Bir bölge dosyasını senkronize etmek için doğrudan kaynak olarak hizmet veren bir DNS sunucusuna ana sunucu denir. Bölge verilerini bir ana sunucudan alan DNS sunucusuna bağımlı sunucu denir. Birincil her zaman ana sunucudur, ikincil ise hem bağımlı hem de ana sunucu olabilir.

Slave, yenileme süresi adı verilen ve genellikle bir saat olan belirli aralıklarla master’dan ilgili bölgenin SOA kaydını alır ve seri numaralarını karşılaştırır. Master’ın SOA kaydının seri numarası slave’inkinden büyükse, veri setleri artık eşleşmez.

DIG — AXFR Zone Transfer

Yönetici test amacıyla veya geçici bir çözüm olarak aktarıma izin ver seçeneği için bir alt ağ kullanırsa veya bunu herhangi biri olarak ayarlarsa, herkes DNS sunucusundaki tüm bölge dosyasını sorgulayacaktır. Buna ek olarak, dahili IP adreslerini ve ana bilgisayar adlarını bile gösterebilen diğer bölgeler sorgulanabilir.

DIG — AXFR Zone Transfer — Internal

Host isimlerinin bulunduğu A kayıtları da bir brute-force saldırısı yardımıyla bulunabilir. Bunu yapmak için, istekleri sırayla göndermek için kullandığımız olası host adlarının bir listesine ihtiyacımız var. Bu tür listeler örneğin SecLists tarafından sağlanır.

Subdomain Brute Forcing

Bunun için birçok farklı araç kullanılabilir ve bunların çoğu aynı şekilde çalışır. Bu araçlardan biri örneğin DNSenum’dur.

Makine Çözümü

Soru 1 : IP adresini kullanarak hedef DNS ile etkileşime geçin ve “inlanefreight.htb” domain’i için FQDN’sini numaralandırın.

Cevap :

Soru 2 : Bir zone transferi gerçekleştirmenin mümkün olup olmadığını belirleyin ve cevap olarak TXT kaydını gönderin. (Format: HTB{…))

Cevap :

1- Hangi domainin dnszone transferine açık olduğunu test edelim.

Soru 3 : DC1 ana bilgisayar adının IPv4 adresi nedir?

Soru 4 : Son sekizlinin “x.x.x.203” ile bittiği ana bilgisayarın FQDN’si nedir?

Cevap :

1- Önceden bulduğumuz potansiyel domainleri ek olarak brute-froce kullanalım başka subdomain keşfedebilecek miyiz ?

2- Hepsini tek tek denedikten sonra dev.inlanefreight.htb’den sonuç aldım . Öğretici de önerdiği wordlisti kullanmayın saatler sürebilir. Bunun yerine alternatif kısa wordlistler kullanabilirsiniz.