Önceki yazıda, Censys’te boşa düşmemek için sorgu kurma mantığından ve savunma bakışıyla işe yarayan dork örneklerinden bahsetmiştik. Bu bölümde aynı çizgiyi bir adım ileri taşıyorum: internetin sizi nasıl “isimden” hatırladığını ve bunun güvenlik ekibi için neden kritik olduğunu.
Niçin sertifika? Çünkü birçok kurumda envanter Excel’de, DNS yaşlandı, panel bir yerlere taşındı ama TLS sertifikası veya HTTP tarafındaki izler hâlâ eski dünyayı fısıldıyor. Censys, bu fısıltıları toplu halde duyabileceğiniz nadir yerlerden biri.
1. “İsim listesi” fiilen envanterdir
Modern TLS dünyasında sertifika, sırf “kilit simgesi” değil; çoğu zaman hangi hostname’lerin kamuya açık şekilde konuştuğunun yan listesi gibidir. Özellikle wildcard ve SAN (Subject Alternative Name) alanları dolu sertifikalarda, kontrollü gözle bakıldığında şu sorunun cevabına yaklaşırsınız:
Kurum dışına hangi isimler gerçekten servis veriyor ve bunların hangisi hâlâ canlı?
Savunma tarafında hedefim “yeni sıfır gün bulmak” değil; taşan yüzeyi kapatmak ve doğru sahiplendirmek.
2. Sorgu kurarken: önce daralt, sonra genişlet
Önceki yazıdaki prensip burada da geçerli: gürültüyü indiren filtre → anlamlı alan → gerekiyorsa genişletme.
Pratik akış:
- Kurum/alan adı kökü ile başlayın (kendi organizasyonunuz veya müşteri tarafında yetkiniz olan sınır içinde).
- Sonuç çok kalabalıksa belirli servis (ör.
HTTP,HTTPS,SSH) veya belirli port ile daraltın. - “Garip” bir şey görürseniz aynı IP / aynı sertifika parmak izi üzerinden ikinci bir gezinti yapın; amaç pivot değil, ilişkisel doğrulama.
Burada sihirli bir “tek satır” yok; önemli olan, elinizdeki envanter dilini (ASN, netblock, org adı, domain kökü) Censys’in anlayacağı deterministik filtreye çevirmek.
3. Sertifikadan çıkan “unutulan isimler”
Gerçek hayatta sık karşılaştığım desenler:
- Eski bir alt alan adı DNS’ten silinmiş görünür ama başka bir yerde hâlâ cevap verir.
- Test / staging hostname’leri üretim sertifikasında yaşamaya devam eder.
- Wildcard yüzünden “teoride var” ama fiilen açık olan servisler listesi şişer; burada iş güvenlik ekibine düşer: wildcard kolaylığı, iz sürme maliyetini artırır.
Savunmacı okuma: Bu bulgular çoğu zaman “hack” değil; operasyonel borç + DNS/sertifika yaşam döngüsü zayıflığı.
4. Zaman: “şimdi”den çok “ne zaman görüldü” önemli
Tek anlık görüntü yanıltıcı olabilir. En değerli soru şudur:
Bu servis/hizmet yeni mi belirdi, uzun süredir aynı mı, yoksa yakın zamanda mı değişti?
Censys’i periyodik kullanan ekipler için asıl güç, tek seferlik tıklamadan çok; aynı sorguyu zaman içinde tekrar etmek ve farkı insan diline çevirmektir. Bunu ileride API veya küçük bir otomasyonla beslemek mümkün; bu serinin devamında oraya da değineceğim.
5. Yanlış pozitif ve etik çizgi
İki uyarıyı net yazayım:
Yanlış pozitif: Aynı IP’de sanal host çoklaması, CDN, yönlendirme ve paylaşımlı barındırma yüzünden “bu kesin bizim” sonucuna zıplamak kolaydır. Bulgu = DNS’ten ters kontrol + dahili envanter + gerekirse sahiplenen ekip ile kapanır.
Etik ve yetki: Kamu verisini tarayıp iç içe geçmiş izleri okumak ile “izinsiz sistemlere dokunmak” arasında dünya kadar fark var. Bu yazıdaki her örnek, yetkiniz olan sistemlerde görünürlük yönetimi içindir.
6. Okuyucuya ödev (5 dakikalık)
Bu yazıyı kapatmadan önce şunu yapın (kendi sınırlarınız içinde):
- Organizasyonunuz için bir kök domain ve mümkünse bir ASN / netblock tanımlayın.
- Censys’te o sınırda bir dar sorgu çalıştırın.
- Çıkan listeden en az üç kaydı seçin ve her biri için şu soruyu cevaplayın: “Bu isim hâlâ bize mi ait ve beklenen servis mi?”
Üç “evet” çıkarsa bile kazanmışsınızdır; çünkü kanıtlı self-skor her zaman varsayımdan iyidir.
Özet: Bir önceki yazıda dorkların “nasıl düşünüleceğini” konuşmuştuk. Burada ise aynı düşünceyi sertifika ve isim düzlemine taşıdım: Censys’te asıl değer, tek bir sorgu değil; envanterle konuşabilen, tekrarlanabilir ve savunmaya hizmet eden bir bakıştır.
Bir sonraki bölümde planım, bu tekrarlanabilirliği API ve küçük otomasyon kalıpları ile somutlaştırmak — ama her zamanki gibi yine “savunma masasında işe yarayan” dille.