Önceki yazılarda sorgu mantığı, sınır çizimi (netblock/ASN) ve banner okuma tarafını konuştuk. Bu bölümde konuyu ölçüm teorisine indiriyorum: Censys size “internetin fotoğrafını” verir; savunmada asıl iş, bu fotoğrafın ne zaman çekildiğini ve iki koşum arasında neyin gerçekten değiştiğini ayırmaktır.
1. Temel ayrım: “host gerçeklik” ile Censys gerçekliği
Censys’te gördüğünüz kayıt, filozofik anlamda “sunucunun hakikati” değil; son başarılı gözlemin projeksiyonudur. Pratikte bu fark şunları doğurur:
- Aynı IP üzerinde servis bir gün vardır, iki gün sonra kaybolur; Censys kaydı bunu zaman içinde günceller.
- Tarama sıklığı ve erişilebilirlik (firewall, rate limit, geçici outage) “boşluk” yaratabilir.
- Bazı gözlemler servis bazlı zaman damgası taşır; host’un tamamı yerine belirli port/protokol için “ne zaman görüldü?” sorusunun cevabı ayrı ayrı olabilir.
Bu yüzden teknik okumada ilk kural şudur: Zaman damgasını tekilleştirirken hangi seviyede ölçtüğünüzü yazın (ör. “host geneli” mi, “443/TCP HTTP servisi” mi).
2. CenQL’de zaman pencereleri (relative time)
Platform tarafında tarih alanlarında aralık ve göreli zaman kullanımı dokümantasyonda netleştirilmiş durumda. Örnek olarak, son 24 saatte servis tarafı gözlemi olan host’ları düşünmek için dokümantasyonda şu tür bir ifade geçer:
host.services.scan_time > "now-1d"
(Relative now-… kullanımı ve aralık mantığı için bkz. Censys Query Language ve destek dokümanlarındaki zaman örnekleri: Writing Queries in Censys Search Language.)
Burada teknik nüans: scan_time “bu port bugünkü internet ölçümünde göründü” bilgisidir; “dün gece yapılan yanlış yapılandırma” ile bire bir “olay saati” eşlemesi her zaman yapılamaz. Yine de gürültüyü kesmek ve yeni çıkan yüzeyi yakalamak için çok işe yarar.
Sertifika veri modelinde tarih içeren alanlar (ör. cert.added_at gibi) ayrı bir “olay” boyutudur: host taramasından bağımsız olarak sertifika yaşam döngüsü izlenebilir (örnek aralık kullanımı yine resmi CenQL örneklerinde var).
3. last_updated_at düşüncesi: pratikte “en güncel servis”
Eski aramalarda sık görülen last_updated_at yaklaşımı, yeni modelde host içindeki servislerin scan zamanlarının türevi gibi düşünülür. Topluluk tartışmalarında bile çözüm yolu genelde şudur: host kaydında servisler üzerindeki scan_time değerlerinden anlamlı bir maksimum/özet çıkarmak (community thread).
Bu bölümü teknik olarak şöyle formüle ederim:
- Host HH için servis kümesi S={s1,…,sn}S={s1,…,sn}
- Her servis için ti=scan_time(si)ti=scan_time(si)
- “Host düzeyinde tazelik” gibi bir özeti raporlarken t\*=max{ti}t\*=max{ti} gibi bir türev seçebilirsiniz — ama raporda bunun maksimum servis taraması olduğunu açık yazın; aksi halde yönetim özeti yanıltıcı olur.
4. Tarihsel snapshot: at_time ve erişim koşulu
Censys Python SDK dokümantasyonunda host görüntülemede belirli bir zamandaki kaydı çekmek için at_time parametresi anlatılır:
(Bkz. Usage v2 — Censys Python.)
Burada teknik gerçek çok net: bu özellik tarihsel erişim gerektirir. Yani “her hesapta, her seviyede” varsayım yapmayın. Operasyonel tasarımda önce şunu netleştirin:
- Tarihsel görünürlük var mı?
- Yoksa “diff” işini kendi arşivlediğiniz sonuç kümeleri üzerinden mi yapacaksınız?
5. Operasyonel diff: minimum uygulanabilir model
En az mühendislikle, en çok değer:
5.1 Kimlik anahtarı seçimi
Sonuç kümesinde satır anahtarı olarak çoğu zaman (ip, port, protocol) veya platformun host kimliği + servis kimliği gibi stabil bir bileşen seçin. Sadece IP ile diff yapmak CDN ve sanal hostingte yanlış alarm üretir.
5.2 Projeksiyon (fields)
API/SQL aramasında gereksiz alan çekmeyin. Zaman analizi yapıyorsanız önce şu minimum set iyi başlangıç olur:
- IP / host kimliği
- port ve servis adı
scan_time(veya eşdeğeri)- (Varsa) sertifika parmak izi / kritik hostname alanları
Bu hem kota/limitleri korur hem diff’i deterministik yapar.
5.3 İki koşum: set farkı
AA “bu hafta” ve BB “geçen hafta” için aynı sorguyu çalıştırıp:
- BB’de olup AA’da olmayanlar: kapanmış / kaybolmuş gözlem (yanlış alarm üretmeden yorumlanmalı)
- AA’da olup BB’de olmayanlar: yeni görünen gözlem (önceliklendirme adayı)
Burada teknik kalite göstergesi, “CSV iki dosyayı diff” değil; aynı sorgu + aynı anahtar + sürümlenmiş çalıştırmadır.
6. Yaygın teknik tuzaklar (kısa)
- Paylaşımlı IP: Aynı IP’de yeni bir hostname görünmesi, sizin altyapınız olmayabilir; diff anahtarınızı hostname ile sıkılaştırırken bu risk artar.
- Yönlendirme ve katmanlı proxy: Banner/endpoint değişimi “asıl servis değişti” anlamına gelmeyebilir.
- Zaman penceresi çok dar: “Son 1 saat” gibi agresif pencereler operasyonel olaylarla uyumlu olmayabilir; pencereyi iş akışına göre seçin.
- Stale kayıt yorumu: “Taramada görünmüyor” her zaman “kapalıdır” değildir; erişim engeli de olabilir.
7. Güvenli ve ölçülebilir otomasyon çizgisi
Teknik öneri seti (etik çerçeve aynı):
- Sorguyu kod/repo içinde sabitleyin (sürüm kontrollü).
- Çıktıyı JSONLines/Parquet gibi makine dostu arşivleyin.
- Diff’i küçük bir script ile üretin; insan okuması için “özet tablo” üretin.
- Alarm üretirken eşik koyun (örn. yeni görünen yönetim portu ailesi).
Özet: Zaman boyutunda Censys kullanmak, yalnızca now-1d yazmak değil; ölçümün neyi temsil ettiğini, servis düzeyinde zamanı nasıl özettiğinizi ve diff anahtarınızı nasıl seçtiğinizi bilerek tasarlamaktır. Tarihsel at_time güçlüdür ama ürün/erişim koşullarına bağlıdır; yoksa “kendi arşivinizle diff” en sağlam günlük mühendislik modelidir.
Bir sonraki teknik bölümde (istersen) aynı disiplini Search API pagination + aggregate/raporlama ve hata ayıklama (boş hits, alan projeksiyonu, kota) üzerinden örnek Python iskeletiyle ilerletebilirim.