Alt alan adı bulma, bir şirketin yalnızca ana web adresine bakarak göremediği internet varlıklarını anlamanın yollarından biridir. api.example.com, panel.example.com, staging.example.com veya eski-kampanya.example.com farklı ekipler, farklı teknoloji ve farklı risk seviyeleri taşıyabilir. Türkiye'de "subdomain bulma", "alt alan adlarını listeleme" ve "bir sitenin alt domainleri nasıl bulunur" aramaları çoğu zaman güvenlik denetimi, ajans teslimi veya yeni bir şirket devralması öncesinde yapılır. Amaç herkese açık bir listeyi saldırı için kullanmak değil, yetkili olduğunuz varlıkların kim tarafından yönetildiğini ve beklenen yüzeyin nerede eksik kaldığını görmektir.
Keşif sonuçları doğaları gereği farklı kanıt seviyelerine sahiptir. DNS'te hâlâ çözümlenen bir kayıt güncel bir gözlemdir. Bir sertifika içindeki hostname, sertifikanın bir zamanda o isim için düzenlendiğini gösterir, fakat servisin hâlâ çalıştığını kanıtlamaz. Arşivlenmiş veya pasif veriler araştırma ipucu olabilir. Bu ayrımı yapmadan bütün isimleri canlı sistem gibi raporlamak hem güvenlik ekiplerini gereksiz alarma sokar hem de eski bir varlık için yanlış risk atamasına yol açar.
Pasif keşif ve DNS doğrulaması
Pasif keşif, hedef sisteme yoğun istek göndermeden daha önce gözlemlenmiş alan adı, sertifika ve DNS sinyallerini bir araya getirir. Bu yaklaşım ilk envanter için daha naziktir ve geniş kapsamı hızlıca görmeye yardım eder. Ancak her adayın DNS sorgulama ile A, AAAA, CNAME veya diğer kayıtlar üzerinden doğrulanması gerekir. DNS yanıtı yoksa isim silinmiş, geçici olarak kapatılmış veya yalnızca belirli bir iç çözümleyicide tanımlı olabilir. NXDOMAIN, timeout ve SERVFAIL gibi sonuçları aynı "yok" kategorisinde birleştirmeyin.
- Kök alan adını ve izinli alt alan adı kapsamını kesin biçimde tanımlayın.
- Pasif kaynaklardan gelen adayları ilk bulgu olarak etiketleyin.
- Adayları güncel DNS çözümlemesi ve gerektiğinde sertifika gözlemiyle doğrulayın.
- Wildcard kayıtların gerçek servis sayısını olduğundan fazla gösterebileceğini kontrol edin.
- İç, staging ve müşteri verisi taşıyan alan adlarını ayrı risk seviyesinde değerlendirin.
- Bulgunun zamanı, kanıt türü ve sorumlu ekibini envantere yazın.
Sertifika şeffaflığı sinyalini doğru okuma
Kamuya açık TLS sertifikaları, sertifikada yer alan DNS isimleri hakkında keşif ipucu verebilir. Bu kayıtlar api, mail, dev veya bölgesel hostname'leri ortaya çıkarabilir. Fakat sertifikada bir ismin bulunması, o adın bugün erişilebilir veya işletmenin hâlâ kontrolünde olduğunu göstermez. Süresi dolmuş sertifika, devreden çıkarılmış alan adı veya yanlışlıkla geniş SAN listesi görülebilir. SSL sertifika kontrolü ile mevcut sunum ve tarih bilgisini karşılaştırın. Eski ipucunu güncel varlık olarak raporlamak yerine "geçmişte gözlendi, güncel DNS doğrulanmadı" yazmak daha doğrudur.
Wildcard DNS ve sahte kapsam algısı
*.example.com gibi wildcard kayıtlar, tanımlanmamış birçok alt alan adı için aynı cevabı üretebilir. Bu, listede gördüğünüz her ismin ayrı bir uygulama olduğu anlamına gelmez. Kök kaydın, wildcard'ın ve daha özel kayıtların önceliğini anlayın. Bir aday hostname aynı IP'ye çözülse bile uygulama katmanında farklı davranış, TLS SAN kapsamı veya HTTP yönlendirmesi olabilir. Wildcard ile eşleşen adları keşif notunda ayrı işaretleyin ve iş sahibi tarafından onaylanmayan isimleri üretim varlığı kabul etmeyin. Bu özellikle müşteri portalı ve çok kiracılı SaaS sistemlerinde yanlış güven hissini azaltır.
Hangi alt alan adları ticari açıdan kritiktir?
Alt alan adlarının değeri yalnızca güvenlik açısından ölçülmez. api ve webhook adresleri entegrasyonların çalışması için gereklidir. app, login ve account müşteri erişimini taşır. status ve support marka deneyiminin parçasıdır. staging, dev ve test adları ise yanlışlıkla herkese açık hale gelirse yayınlanmamış kod veya hassas yapılandırma riski yaratabilir. Eski kampanya ve yönlendirme adları SEO, marka ve sertifika yönetimini karmaşıklaştırabilir. Envanterde her hostname için kullanım amacı, veri hassasiyeti, iş sahibi, son gözlem, DNS hedefi ve kapatma planı bulunmalıdır.
Keşfedilmiş bir hostname, sahipliği belirlenmiş bir varlık değildir; envanter ve doğrulama adımları gerekir.
Saldırı yüzeyi yönetimi ilkesi
Yetkili keşif için güvenli çalışma akışı
Önce kapsamı ve yazılı yetkiyi belirleyin. Müşterinin yalnızca ana alan adını mı, iştirakleri ve kampanya alanlarını da mı yönettiğini sorun. Sonra Alt alan adı bulma aracı ile adayları toplayın, her aday için DNS ve SSL kanıtı alın, son olarak iş sahibiyle listeyi doğrulayın. Uygulama katmanına istek gönderecekseniz hız, timeout, yanıt boyutu ve erişim politikalarına uyun. Kimlik doğrulamasını aşmaya, gizli servislere erişmeye veya sonuçları üçüncü taraflara yaymaya çalışmayın. Amaç, müşterinin kendi internet yüzeyini görünür kılmaktır.
- Kapsamı ve yetkiyi yazılı hale getirin.
- Aday hostname'leri pasif, DNS ile doğrulanmış veya bilinmiyor olarak sınıflandırın.
- Wildcard ve CNAME zincirlerini ayrı not edin.
- Sertifika tarihini ve SAN kapsamını güncel gözlemle karşılaştırın.
- İş sahibi, kritik seviye ve kapatma kararını envantere ekleyin.
- Yalnızca gerektiğinde sınırlı ve güvenli uygulama doğrulaması yapın.
Subdomain API ile envanter güncelleme
Ajanslar, güvenlik ekipleri ve SaaS platformları yeni varlıkları düzenli gözlemlemek için Subdomain API sonucunu mevcut varlık envanterine bağlayabilir. Her çalışmada yeni, kaybolmuş, değişmiş ve doğrulanamayan adları ayrı olay türü yapın. Yeni bir hostname'in görünmesi otomatik olarak tehdit değildir; lansman, bölgesel hizmet veya müşteri entegrasyonu olabilir. Bir adın kaybolması da kesin kapanma kanıtı değildir; timeout veya geçici DNS sorunu olabilir. Bu nedenle değişiklikleri insan onayına, kayıt sistemine ve gerektiğinde SSL veya teknoloji gözlemine bağlayın. Sonuçların tazeliğini ve kontrol zamanını kullanıcıya gösterin.
Eski ve unutulmuş alt alan adlarını temizleme
Keşif sonrası en değerli adımlardan biri eski alt alan adlarını temizlemektir. Bir kayıt artık kullanılmayan sunucuya işaret ediyorsa, ekip sahibiyle kapatma veya yönlendirme kararı verin. Sertifika otomasyonundan kaldırılmayan isimleri, DNS'te kalan CNAME kayıtlarını ve üçüncü taraf hizmetlere yönelen kopuk alias'ları inceleyin. Bir kaydı silmeden önce e-posta, API, webhook, müşteri bağlantısı ve SEO bağımlılıklarını kontrol edin. Temizlik kararı değişiklik yönetimiyle kaydedilmeli, geri dönüş için gerekli bilgiler saklanmalıdır. Hızlı silme kadar, sahipsiz bir kaydı yıllarca bırakmak da operasyonel risktir.
Alt alan adı bulma, güvenlik ekiplerine sürpriz isimler vermek için değil, bilinen varlıkların kimlik ve yaşam döngüsünü netleştirmek için yapılmalıdır. Pasif sinyali güncel DNS ve sertifika kanıtından ayırın, wildcard etkisini açıklayın, hostname'leri iş sahibi ve kritik seviye ile envantere alın. Yetkili kapsam içinde, hız ve erişim sınırlarına uyarak otomasyonu kullanın. Bu yaklaşım hem yeni bir saldırı yüzeyinin fark edilmesini hem de gereksiz eski kayıtların güvenli biçimde kapatılmasını sağlar.
Keşif sonuçlarını sahiplik tablosuna dönüştürme
Keşif listesinin kullanılabilir olması için her hostname'i bir ekibe ve iş amacına bağlayın. Örneğin api adı ürün ekibine, mail adı bilgi işlem ekibine, kampanya adı pazarlama ekibine ait olabilir. Sahibi bulunamayan adlar özel bir inceleme kuyruğuna alınmalıdır. Alan adının aynı IP adresine çözülmesi ortak sahiplik veya ortak servis anlamına gelmez. CNAME hedefi üçüncü taraf bir hizmete gidiyorsa sözleşme, hesap erişimi ve kapatma süreci de kontrol edilmelidir. Bu tablo, güvenlik uyarısının doğru kişiye gitmesini ve eski adların rastgele silinmemesini sağlar.
Alt alan adı isimlerini işlevlerine göre sınıflandırmak da risk önceliğini iyileştirir. Giriş, ödeme, müşteri verisi veya webhook taşıyan adlar yüksek önem taşırken, eski bir kampanya adı daha düşük olabilir. Staging ve dev adları üretim kadar önemli görünmeyebilir, fakat yayınlanmamış kod veya varsayılan kimlik bilgisi barındırabilir. Sınıflandırma yaparken adın ismine değil, gerçekten çözümlendiği hedefe ve iş sahibinin açıkladığı kullanıma bakın. Her sınıf için beklenen kontrol sıklığı ve kapanma yolu belirleyin.
- Hostname ve normalleştirilmiş alan adı.
- Güncel DNS cevabı ve CNAME hedefi.
- Sertifikada görülen SAN ve bitiş tarihi.
- İşlev, veri hassasiyeti ve önem seviyesi.
- İş sahibi, teknik sahip ve son doğrulama zamanı.
- Planlanan kapatma, taşıma veya yenileme tarihi.
Yanlış pozitif ve eksik keşif yönetimi
Keşif aracının listesinde bulunan her aday için aynı güven düzeyini kullanmayın. Bir isim yalnızca geçmiş bir sertifika kaydında görünüyor ve DNS'te çözümlenmiyorsa geçmiş ipucu olarak saklanabilir. DNS yanıtı alınıyor fakat uygulama doğrulanamıyorsa teknik varlık, uygulama durumu bilinmiyor olarak işaretlenebilir. Bir yöntem sonuç üretmediğinde eksik keşif ihtimali devam eder. Yeni kayıtlar, iç DNS adları, wildcard kapsamı ve erişim kontrollü servisler pasif kaynaklarda görünmeyebilir. Raporun kapsamını ve kör noktalarını yazmak, müşterinin listeyi eksiksiz envanter sanmasını önler.
Kapsamı müşteriye raporlama
Bir subdomain raporunun başında kullanılan yöntemleri ve sınırlamaları açıklayın. Pasif keşif, güncel DNS doğrulaması ve sertifika gözlemi farklı sütunlarda yer almalıdır. Müşteri yalnızca doğrulanmış canlı adları görmek istiyorsa adayları ayrı ek olarak sunun. İç ağ adlarının ve kimlik doğrulamalı panellerin görünmeyebileceğini yazın. Rapor tarihi, kontrol edilen kök alan adı, wildcard etkisi ve sonraki tarama zamanı da belirtilmelidir. Bu yapı, güvenlik ekibinin eksik keşfi yanlışlıkla temiz bir yüzey olarak yorumlamasını engeller.
- Kapsam ve yetki.
- Kullanılan kanıt türü.
- Son gözlem zamanı.
- Canlı, geçmiş, bilinmiyor veya wildcard durumu.
- İş sahibi ve önem seviyesi.
- Önerilen sonraki kontrol.
Keşif tamamlandığında müşteriye yalnızca isim listesi vermeyin. Hangi adın canlı DNS'e, hangisinin yalnızca sertifika geçmişine dayandığını; wildcard nedeniyle hangi adayların aynı cevabı aldığını ve hangi adların sahibinin bulunamadığını açıklayın. Bu ayrım, ekibin bir sonraki taramada gerçek değişikliği fark etmesini kolaylaştırır. Alt alan adı envanteri, güvenlik raporunun yanında DNS değişikliği ve varlık sahipliği sürecinde de kullanılabilecek yaşayan bir belge olmalıdır.
Bir alt alan adını kapatmadan önce DNS TTL, sertifika otomasyonu, e-posta adresleri, webhook tüketicileri ve dış müşterilerin kullandığı entegrasyonları kontrol edin. Kapatma sonrası DNS ve SSL gözlemiyle beklenen durumun oluştuğunu doğrulayın. Böylece güvenlik temizliği yeni bir iş kesintisine dönüşmez.
Keşif raporunu her çalışmada aynı alanlarla üretmek, değişiklik karşılaştırmasını kolaylaştırır. Yeni, kaybolmuş, değişmiş ve doğrulanamayan isimleri ayrı bölümlerde gösterin. Bir hostname'in kaybolması veya tekrar görünmesi tek başına olay değildir; DNS ve sertifika kanıtının zamanı ile iş sahibinin açıklaması birlikte değerlendirilmelidir. Bu düzen, otomasyonu kullanırken insan kararını korur.
Düzenli keşif sonuçlarını tek başına alarm panosu yapmak yerine değişiklik yönetimiyle birleştirin. Yeni alt alan adı, beklenmeyen sertifika, DNS hedefi değişikliği veya sahipsiz CNAME farklı riskler taşır. Her biri için kanıt, zaman, olası iş açıklaması ve sorumlu ekip gösterin. Böylece Türkiye'de farklı ekiplerin yönettiği e-ticaret, SaaS ve kurumsal alan adı portföyleri daha görünür hale gelir ve güvenlik çalışması gerçek varlık sahipliğiyle desteklenir.