Series · 5 partsExternal Perimeter IntelligencePart 4 · You are here
- 1Dış Çevre İstihbarat Grafiği: Varlık İlişkilerini Haritalandırmak
- 2Domain Sahipliği ve Varlık Atıf Kanıtı: Dış Yüzeyde Yanılgılar
- 3Üretici Kapsam Dışıydı. Güven Sınırı Değildi: 3. Taraf Entegrasyonları
- 4Servis Gözlemlendi. Uygulama Hâlâ Bilinmiyordu: Dış KeşifYou are here
- 5Giriş Sayfası Kamusaldı. Kimlik Sınırı Başka Bir Yerdeydi
60 saniyede servis gözlemi
Pasif bir internet platformu, 203.0.113.42:8443 adresinin dün TLS konuştuğunu raporlar. Sertifika tanıdık bir domain içermektedir. Yanıt bir uygulama sunucusuna benzemektedir. Bu değerli bir istihbarattır —ancak henüz bir uygulama, bir varlık (asset), bir zafiyet ya da test izni anlamına gelmez.
Bu gözlem oldukça dar bir soruyu yanıtlar:
Belirli bir harici bakış açısından, kaydedilmiş belirli bir zamanda, bu adres ve port; söz konusu protokol ve bu yanıt özellikleriyle tutarlı bir kanıt üretmiştir.
Şu soruları otomatik olarak yanıtlamaz:
- Adresi şu anda kim kontrol ediyor;
- Servis hangi hostname’i bekliyor;
- Sertifika adı aktif miydi, varsayılan mıydı, geçerliliğini yitirmiş miydi yoksa paylaşımlı mıydı;
- Yanıtı hangi virtual host veya kiracı (tenant) üretti;
- Endpoint bir edge mi, proxy mi, origin mi, aygıt mı, API mi yoksa sıradan bir web sitesi mi;
- Arkasında hangi kimlik mekanizması ve iş akışı (business workflow) var;
- Gözlemlenen endpoint mevcut Test Kuralları (Rules of Engagement) kapsamında mı.
Modern bir harici sızma testi (external pentest), bu nedenle pasif servis verilerini aktif çalışmalardan önce belirsizliği azaltmak için kullanır. Belirsizliğin yerine araç çıktısı koymaz. İş akışı şöyledir:
gözlemi kaydet → endpoint’e atıfta bulun (attribute) → beklenen isim ve protokol bağlamını ortaya çıkar → kapsamı doğrula → mevcut en küçük doğrulamayı gerçekleştir → uygulamayı haritalandır.
Zafiyet testinin anlamlı bir hedefe sahip olması ancak bundan sonra mümkündür.
Bir servis kaydı bir isim değil, bir ölçümdür
“Bir HTTPS servisi mevcuttur” ifadesi, ifadenin faydalı kalıp kalmadığını belirleyen alanları gizler. Savunulabilir bir gözlem kaydı en azından şunlara ihtiyaç duyar:
| Alan | Koruduğu soru |
|---|---|
observed_at | Servis bu kanıtı ne zaman üretti? |
vantage | Hangi tarayıcı veya ağ perspektifinden gözlemlendi? |
ip / port | Hangi taşıma endpoint’i yanıt verdi? |
transport | TCP, UDP, QUIC veya başka bir taşıma protokolü mü? |
service_name | Tarayıcı hangi protokolü tespit etti? |
service_confidence | Bir handshake ile kanıtlandı mı yoksa porttan tahmin mi edildi? |
banner_or_response | Sınıflandırmayı destekleyen en küçük yanıt hangisidir? |
tls_names | Gözlemlenen sertifikada hangi isimler yer aldı? |
redirect_target | Servis bir hostname’e veya uygulamaya yönlendirme yaptı mı? |
source_record | Başka bir analist orijinal gözleme ulaşabilir mi? |
scope_state | Mevcut etkileşim onaylandı mı, hariç mi tutuldu yoksa kararlaştırılmadı mı? |
Censys, sürekli servis keşfi, otomatik protokol tespiti, protokole özgü handshake’ler ve takip eden sınıflandırmaları dokümante etmektedir. Ayrıca internet taramalarının bilgi toplama amaçlı olduğunu ve kimliği doğrulanmış bir giriş denemesi yapmadığını belirtir. Bu da söz konusu veriyi harici olarak gözlemlenen servis kanıtları için mükemmel bir kaynak haline getirir.
Aynı dokümantasyon, sonucun neden hâlâ bağlama ihtiyaç duyduğunu da açıklar. Servisler standart ve standart dışı portlarda bulunur; bazıları UNKNOWN kalır; HTTP gözlemleri yerel yönlendirmeleri takip edebilir; bilinen servisler her an sürekli değil, belirli bir periyotta yenilenir. Kayıt, tarayıcının davranışının ve zaman aralığının ürettiği bir ölçümdür —test uzmanı için açık tutulan canlı bir soket değildir.
Ham gerçekleri zenginleştirmeden önce koruyun. Bir analist hedef listesine yalnızca IP:port kopyalarsa; zaman damgası, protokol kanıtı, hostname ipuçları ve belirsizlik yok olur. Sonraki aktiviteler kaynağının hak ettiğinden daha yetkin görünür.
Beş katmanı birbirinden ayrı tutun
Gözlemlenen bir servis, birbirini izleyen atıf (attribution) katmanları aracılığıyla faydalı hale gelir. Bir katmanı atlamak, harici sızma testlerindeki en yaygın yanlış pozitifleri (false positives) üretir.
Gözlem (Observation). Bir tarayıcı bir adres ve port üzerinde bir yanıt kaydetti. Ham zaman damgası ve yanıt buraya aittir.
Endpoint. Routing, ASN, sağlayıcı, adres geçmişi, load balancer, CDN, NAT ve paylaşımlı barındırma (shared-hosting) bağlamı, adresin neyi temsil ettiğini açıklar. Bu katman atfı güçlendirebildiği kadar kolayca zayıflatabilir de.
İsim ve protokol bağlamı (Name and protocol context). DNS, SNI, HTTP Host, TLS sertifikası, yönlendirme, uygulama protokolü ve yanıt varyasyonu; servisin beklediği ismi tanımlar. Doğru isim olmadan verilen bir IP yanıtı, hiçbir gerçek kullanıcının ziyaret etmediği varsayılan bir virtual host gösterebilir.
Uygulama (Application). Sayfa aileleri, API kökleri, kimlik doğrulama başlangıç noktaları, statik varlıklar, header’lar, hata davranışı ve görsel kimlik; bir uygulama sınırını diğerinden ayırır.
İş akışı (Business flow). Roller, nesneler, eylemler, durum geçişleri, entegrasyonlar ve veri hassasiyeti; uygulamanın neden önemli olduğunu ve hangi güvenlik hipotezlerinin test edilmeyi hak ettiğini açıklar.
Port yalnızca ilk iki katmana aittir. Zafiyet etkisi ise son iki katmana aittir.
Pasif kapsama alanı işin sırasını değiştirir
Geniş kapsamlı aktif tarama sıklıkla teknik olarak doğru ancak operasyonel olarak zayıf büyük miktarda sonuç üretir: WAF yanıtları, paylaşımlı CDN edge noktaları, genel bulut adresleri, honeypot’lar, eski varlıklar ve yinelenen servisler. Hız limitleri ve savunma kontrolleri tekrarlanan taramaların tutarsız görünmesine de neden olabilir; yüksek hacimli doğrulama ise asıl önemli uygulamalar anlaşılmadan önce testin gürültü bütçesini tüketir.
Pasif platformlar bu iş akışını tersine çevirir. Atfedilen grafikte güncel servisleri, protokolleri, sertifikaları, banner’ları ve geçmiş değişiklikleri arayın; ardından ilişkisi ve potansiyel iş rolü mevcut doğrulamayı haklı çıkaran daraltılmış kümeyi seçin. Platform geniş kapsamlı gözlemi zaten gerçekleştirmiştir. Test uzmanının görevi hangi gözlemlerin ilgili, güncel, atfedilebilir, yetkilendirilmiş ve dokunmaya değer olduğunu belirlemektir.
Bu “taramadan tarama yapmak” değildir. İnternet ölçümü yine de paketler gerektirmiştir; başka bir taraf bunları kendi yayımlanmış metodolojisi kapsamında göndermiştir. Ayrım, testin müşteri hedefiyle olan aktif etkileşimiyle ilgilidir. Müşterinin, değerlendirme herhangi bir şeye temas etmeden önce hangi kanıtların var olduğunu anlaması için pasif kaynağı ve toplama davranışını kaydedin.
Güncellik görünür kalmalıdır. Censys, bilinen servislerin sürekli olarak değerlendirildiğini ve eski kayıtların kendi periyoduna göre yeniden tarandığını belirtir; ancak bir organizasyon gözlemler arasında bir bulut adresini yeniden dağıtabilir, bir origin’i değiştirebilir veya bir dinleyiciyi kaldırabilir. Dünden kalan bir kayıt, triyaj için ideal bir kanıt olabilir ancak şu an için geçerliliğini yitirmiş olabilir.
Üç zaman durumunu kullanın:
observed— pasif platformun kendi zaman damgasında ölçtüğü durum;current-unverified— onaylanmış güncel hiçbir kontrolün doğrulamadığı veya çürütmediği durum;current-verified— sınırlandırılmış bir değerlendirme kontrolünün söz konusu davranışı doğruladığı ve zamanını kaydettiği durum.
observed değerinin üzerine asla current-verified yazmayın. Tarihsel sapma; maruziyet pencerelerini, taşınmaları ve iki analistin neden farklı sonuçlara ulaştığını açıklayabilir.
Web servisini yargılamadan önce ismi ortaya çıkarın
Modern barındırma mimarileri “tek adres, tek uygulama” varsayımını çürütür. OWASP’ın saldırı yüzeyi belirleme rehberi, domain’leri, virtual host’ları, standart dışı portları, sertifikaları ve tek bir IP’nin birden çok uygulamayı barındırabileceği gerçeğini açıkça vurgular.
HTTPS için beklenen isim iki ayrı aşamayı etkileyebilir. RFC 6066 tarafından tanımlanan TLS server_name uzantısı (SNI), istemcinin anlaşma sırasında sunucu adını belirtmesine izin verir. TLS’ten sonra, RFC 9110 tarafından tanımlanan HTTP hedef URI’si ve Host bilgisi, sunucunun hedeflenen kaynağı ve virtual host’u seçmesine yardımcı olur. Yalnızca https://IP:port/ hedefine yapılan bir kontrol, bu nedenle yanlış sertifikayı müzakere edebilir, varsayılan bir siteye ulaşabilir veya uygulamayı tamamen kaçırabilir.
İsim kurtarma (name recovery) bağımsız ipuçlarını birleştirmelidir:
- Atfedilen domain’lerden adrese doğru güncel forward DNS kayıtları;
- Gözlemlenen sertifika SAN’ları, geçerlilik süresi ve toplanma zamanı;
- Onaylanan isim SNI olarak kullanıldığında mevcut sertifika davranışı;
- Servisten kanonik bir hostname’e yapılan yerel yönlendirmeler;
- Resmi uygulama bağlantıları ve dokümantasyon;
- Müşteriyle bağlantılı içerik, API ve kimlik ilişkileri;
- Teknik sinyaller belirsiz olduğunda müşterinin teyidi.
Her sertifika adını her adrese karşı denemeyin. Çok kiracılı (multi-tenant) bir sertifika, paylaşımlı bir edge veya sağlayıcı joker karakteri (wildcard), muazzam büyüklükte kapsam dışı bir test matrisi yaratabilir. Atfedilen müşteri isimlerinden adaylar üretin, yazılı kapsamı uygulayın ve yalnızca uygulama sınırını çözmek için gereken kesin kombinasyonları doğrulayın.
Wildcard DNS bir negatif kontrole ihtiyaç duyar. Rastgele hostname’ler çözümleniyor ve aynı yanıtı dönüyorsa, görünürdeki keşif gerçek bir uygulama değil bir catch-all olabilir. Yanıt durumunu, sertifikayı, başlığı, gövde parmak izini (body fingerprint), yönlendirmeyi ve sunucu davranışını; atfedilen isim, rastgele bir etiket ve yalın IP adresi genelinde karşılaştırın. Amaç gizli kiracıları paylaşımlı altyapıda numaralandırmak değil, sahte isimleri elemektir.
Servis tespiti, bir güven düzeyine sahip kanıttır
Port numaraları birer uzlaşıdır (convention), protokol kanıtı değildir. Bir uygulama 8443 üzerinde HTTPS, yüksek bir portta SSH veya başka bir şeyle ilişkilendirilmiş bir portta özel bir servis sunabilir. Tamamlanmış protokole özgü bir alışverişi gösteren pasif veri, yalnızca porttan türetilen bir etiketten çok daha güçlüdür.
Nmap’in servis ve sürüm tespiti dokümantasyonu, sürüm tespitinin açık bir servisi nasıl sorguladığını, yanıtları proplarla nasıl eşleştirdiğini ve beklenmeyen portlardaki protokolleri nasıl tanımlayabildiğini anlatır. Ayrıca önemli bir güvenlik dersini de ortaya koyar: Propların etkileri vardır. Nmap, sürüm tespitinde TCP 9100’ü varsayılan olarak hariç tutar çünkü bazı yazıcılar prob verilerini yazdırabilir. Bir “banner grab” işlemi kendiliğinden zararsız değildir.
Aktif doğrulama yoğunluğunu çalıştırmadan önce sınıflandırın:
| Seviye | Doğrulama davranışı | Tipik kullanım |
|---|---|---|
V0 | Yeni hedef etkileşimi yok | Pasif kayıt ve kaynak koruma |
V1 | Tek bir taşıma bağlantısı veya güvenli protokol selamlaması | Dinleyiciyi ve temel protokolü teyit etme |
V2 | Yönlendirmeleri yerel olarak sınırlandırılmış tek bir isimli TLS/HTTP isteği | Hostname’i, virtual host’u ve güncel yanıtı teyit etme |
V3 | Onaylanmış küçük, protokole özgü handshake | Servis ailesini veya güvenlik yapılandırmasını teyit etme |
V4 | Kimliği doğrulanmış veya durum bilgisi içeren (stateful) uygulama yolculuğu | Test verileriyle rolleri, nesneleri, API’leri ve iş akışını haritalandırma |
Her servis türünün kendi tavan sınırına ihtiyacı vardır. Bir HTTP GET / isteği; bir yazıcıya, mail relay’ine, endüstriyel protokole, veritabanına veya mesaj kuyruğuna (message broker) bayt göndermekle eşdeğer değildir. Mevcut bir prob çok az değer kattığında veya etkisi belirsiz olduğunda platformun mevcut gözlemini kullanın. Test Kuralları (Rules of Engagement); yasaklanan protokolleri, maksimum istek sayılarını, zaman aşımlarını, kaynak adresleri ve durma koşullarını açıkça tanımlamalıdır.
HTTP yanıt verilerini bir uygulama kimliğine dönüştürün
Bir 200, 401, 403 veya 302 yanıtı bir uygulama sınıflandırması değildir. Durum kodları genellikle origin’den ziyade sınır politikasını (edge policy) tanımlar. WAF engelleme sayfaları, genel reverse proxy hataları, varsayılan sunucu sayfaları ve kimlik yönlendirmeleri, birbiriyle ilgisiz uygulamaları tamamen özdeş gösterebilir.
Açıklanabilir alanlardan oluşan küçük bir uygulama parmak izi kullanın:
- Nihai onaylanmış URL ve yönlendirme zinciri;
- Durum kodu ve içerik türü (content type);
- Sayfa başlığı ve kararlı bir gövde parmak izi;
- Sertifika kimliği ve güncel geçerlilik;
- Yanıt header’ları, çerezler ve önbellek davranışı;
- Uygulamaya özgü statik varlıklar veya manifest;
- Kimlik doğrulama başlangıç ve callback hedefleri;
- Bağlantılı API origin’leri, WebSocket endpoint’leri ve yükleme/indirme host’ları;
- Organizasyona özgü yasal, ürün veya hesap bağlamı;
- Zaman damgası ve görüntü alanı (viewport) içeren ekran görüntüsü.
Bir ekran görüntüsü harika bir triyaj kanıtıdır. Unutulmuş bir yönetici konsolunu genel bir sunucu sayfasından saniyeler içinde ayırabilir. Ancak sahipliği, yetkilendirmeyi, teknoloji sürümünü veya bir zafiyeti kanıtlayamaz. Logolar ve başlıklar kopyalanabilir; görsel benzerliğin arkasında DNS, sertifika, kimlik, API veya müşteri kanıtı bulunmalıdır.
Bir uygulamayı tanımladıktan sonra, zafiyet sınıflarından önce giriş noktalarını (entry points) listeleyin. OWASP’ın giriş noktası belirleme rehberi; isteklerin, parametrelerin, metotların, kimlik doğrulama durumunun, taşıma korumasının ve çok adımlı davranışların kaydedilmesini önerir. Bu kaydı rol, nesne, durum geçişi, güven sınırı, kanıt referansı ve veri hassasiyeti ile genişletin.
Artık çıktı “8443 üzerinde HTTPS” değildir. Şudur:
Bu hostname ve edge üzerinden ulaşılan, bu kimlik akışını kullanan, kimlik doğrulaması gerektirmeyen ve gerektiren şu giriş noktalarını sunan ve bu roller altında şu iş nesnelerini kontrol eden, müşteri tarafından işletilen bir iş ortağı yönetim uygulaması.
Bu cümle bir test planını destekleyebilir. Bir port listesi ise destekleyemez.
Sınırlandırılmış bir kabul boru hattı kullanın
Her gözlem açık kapılardan (gates) geçerek ilerlemeli ya da bir gerekçe belirtilerek durdurulmalıdır.
Boru hattı doğrulama yanlılığına (confirmation bias) karşı koruma sağlar. Güncel DNS pasif sertifikayla uyuşmuyorsa veya onaylanan hostname genel bir sağlayıcı sayfası üretiyorsa, analist adayın önceliğini düşürmeli ve çelişkiyi açıklamalıdır. Bir şeyler tanıdık gelene kadar tarama yoğunluğunu artırmak atıf sorununu çözmez.
Her kapı için kararı ve gerekçeyi kaydedin:
- Kaynak kapısı (Source gate): Orijinal kayıt geri alınabilir, zaman damgalı ve kullanılacak kadar spesifik mi?
- Atıf kapısı (Attribution gate): Hangi güncel ve geçmiş olgular endpoint’i müşteriye bağlamaktadır?
- Paylaşımlı altyapı kapısı (Shared-infrastructure gate): Sinyal bir edge’e, sağlayıcıya veya ilgisiz bir kiracıya ait olabilir mi?
- Kapsam kapısı (Scope gate): Tam olarak hangi isim, adres, port, protokol ve eylem onaylanmıştır?
- Güncellik kapısı (Freshness gate): İlgili güncel davranışı hangi en küçük istek doğrulayabilir?
- Uygulama kapısı (Application gate): Bir güvenlik hipotezi oluşturmak için yeterli giriş noktası, kimlik, API ve iş akışı bağlamı mevcut mu?
Reddedilen kayıtlar da önemlidir. Eski bir sertifika emekliye ayrılmış bir markayı açığa çıkarabilir. Taşınmış bir servis, yönetilmeyen bir hizmetten çıkarma (decommissioning) sürecini ortaya çıkarabilir. Paylaşımlı bir edge bir tedarikçi ilişkisini tanımlayabilir. Bunlar istihbarat çıktılarıdır; eski adresi veya sağlayıcıyı test etme izni değildir.
Kurgusal bir servisten uygulamaya inceleme süreci
Pasif bir kaydın on sekiz saat önce 203.0.113.42:8443 üzerinde TLS gözlemlediğini varsayalım. Sertifika partners.meridian.example içeriyordu ve yanıt /login rotasına yönlendiriliyordu.
- Analist pasif kaydı, zaman damgasını, sertifika parmak izini, SAN’ı, yönlendirmeyi ve tarayıcı kaynağını kaydeder. Aday durumu
livedeğil,observedolarak belirlenir. - Güncel RDAP ve yönlendirme verileri adresin bir bulut sağlayıcısına ait olduğunu gösterir. Bu durum Meridian sahipliğini değil, barındırma bağlamını destekler.
partners.meridian.exampleiçin güncel DNS gözlemlenen adrese çözümlenir. Hostname Meridian’ın resmi tedarikçi dokümantasyonunda bağlantılanmıştır. Atıf durumuprobableolur, ancak paylaşımlı bulut barındırma bir kısıt olarak kalmaya devam eder.- Müşteri iş ortağı portalını teyit eder ve değerlendirme adresinden bu hostname’e 8443 portu üzerinden tek bir isimli HTTPS isteğini onaylar. Bulut sağlayıcı IP aralığı, diğer isimler ve origin keşfi kapsam dışı kalır.
- Onaylanan SNI ve hostname ile yapılan bir
V2isteği beklenen sertifikayı döner, yerel olarak yönlendirir ve bir Meridian iş ortağı giriş ekranını yükler. Yalın IP adresi ise genel bir varsayılan site döner. Aradaki fark, isim bağlamının neden önemli olduğunu kanıtlar. - Analist oturum açma başlangıcını, kimlik sağlayıcı (IdP) yönlendirmesini, callback’i, çerezleri, herkese açık JavaScript’i, API origin’ini, kimlik doğrulaması gerektirmeyen kurtarma rotasını ve sağlanan iki test hesabına görünür olan rol terminolojisini kaydeder.
- Test planı ancak bu aşamada hipotezler içerir: Tedarikçiler arası kiracı izolasyonu (tenant separation), SSO sonrası rol dönüşümü, partner API’sindeki nesne yetkilendirmesi ve fatura onayı etrafındaki iş akışı denetimi. Her biri onaylanmış bir hesap, nesne, endpoint ve beklenen etkiyle ilişkilendirilir.
Pasif platform sinyali buldu. Atıf onu bir aday yaptı. Dar kapsamlı bir istek onu güncel kıldı. Uygulama haritalaması ise onu test edilebilir hale getirdi.
Kanıt matrisi (Evidence matrix)
| Sinyal veya sonuç | Neyi destekler | Neyi kanıtlayamaz | Gerekli sonraki adım |
|---|---|---|---|
| Pasif IP ve açık port gözlemi | Belirtilen bir bakış açısından ve zamanda bir dinleyicinin yanıt verdiğini | Güncel erişilebilirliği, mülkiyeti, protokolü veya uygulamayı | Kaynağı koruyun ve güncel atıfla karşılaştırın |
| Protokole özgü pasif handshake | Yanıt davranışının bir servis sınıflandırmasıyla eşleştiğini | Ürün sürümünün doğruluğunu, güvenliğini veya müşteri kontrolünü | Güven seviyesini kaydedin ve güncel kanıta ihtiyaç olup olmadığına karar verin |
| Sertifika müşteri hostname’ini içerir | Sertifika veya gözlem anında isimlendirme kanıtının mevcut olduğunu | Dağıtımı, münhasırlığı, güncel DNS’i, sahipliği veya kapsamı | DNS, resmi bağlantılar, routing ve müşteri girdilerini birbiriyle ilişkilendirin |
| Güncel DNS hostname’i gözlemlenen adrese yönlendirir | Mevcut bir isim-adres ilişkisini | Hangi virtual host’un, kiracının, origin’in veya iş uygulamasının yanıt verdiğini | Kesin hostname ve protokol bağlamı için kapsam izni alın |
| Yalın IP bir giriş veya admin sayfası gösterir | Varsayılan virtual host’un bu içeriği sunduğunu | Gerçek kullanıcıların buna ulaştığını veya müşteriye ait olduğunu | Onaylanmış hostname’i ortaya çıkarın; paylaşımlı/varsayılan yanıtları reddedin |
| İsimli TLS/HTTP isteği beklenen uygulamayla eşleşir | Onaylanan tek bir isim ve zaman damgası için güncel davranışı | Tüm yolları, origin’leri, rolleri veya zafiyet sınıflarını | Giriş noktası ve güven sınırı modelini inşa edin |
| Ekran görüntüsü müşteri markasıyla eşleşir | Faydalı görsel korelasyon ve triyaj kanıtını | Sahipliği, teknoloji sürümünü, yetkilendirmeyi veya güvenliği | Teknik ve müşteri düzeyinde teyit arayın |
| Servis banner’ı bir ürün ve sürüm belirtir | İfşa edilen yanıt verilerinden yola çıkan bir ürün hipotezini | Yama seviyesini, zafiyetli yapılandırmayı veya istismar edilebilirliği | Güvenli şekilde doğrulayın, ardından CVE eşleştirmesi yerine gerçek kontrolü test edin |
| Uygulama giriş noktası haritası yeterince eksiksizdir | İsteklerin, rollerin, nesnelerin ve akışların hipotezleri destekleyebileceğini | Herhangi bir hipotezin istismar edilebilir olduğunu | Sınırlandırılmış pozitif ve negatif testleri çalıştırın |
Müşterinin alması gerekenler
Nihai çıktı, gözlemden uygulamaya dönüşümü korumalıdır:
Gözlem defteri (Observation ledger). Ham servis gerçekleri, kaynak, zaman damgası, tarayıcı davranışı, yanıt kanıtı ve başlangıçtaki belirsizlik.
Atıf kararları (Attribution decisions). Çelişkiler ve güven durumuyla birlikte DNS, sertifika, routing, barındırma, resmi bağlantı ve müşteri kanıtları.
Doğrulama planı ve sonucu. Onaylanmış hostname, adres, port, protokol bağlamı, istek bütçesi, kaynak adres, beklenen yanıt, gözlemlenen yanıt, zaman damgası ve durma koşulu.
Uygulama haritası (Application map). Giriş noktaları, kimlik yolu, roller, nesneler, API’ler, durum geçişleri, üçüncü taraf bağımlılıkları, veri sınıfları ve kanıt referansları.
Ret sicili (Rejection register). Eski servisler, paylaşımlı edge’ler, varsayılan virtual host’lar, ilgisiz kiracılar, sağlayıcı altyapısı, wildcard sonuçları ve desteklenmeyen sürüm eşleşmeleri.
Değişim sinyali (Change signal). Önceki pasif veya test gözleminden farklı olan durumlar: Yeni servis, taşınan adres, sertifika değişikliği, yeniden adlandırılan uygulama, yeni kimlik sınırı veya kullanımdan kaldırılan rota.
Bu yapı savunuculara bir port listesinin asla veremeyeceği bir şey sunar: Bir servisin neden önemli olduğu, aksiyon alabilecek uygulama sahibi, test edilmesi gereken kesin kontrol ve bunu yeniden test etmek için gereken kanıtlar.
Pasif keşif tam olarak değerlendirmenin daha sessiz ve daha seçici olmasını sağladığı için değerlidir. Amacı uzaktan zafiyet ilan etmek değildir. Aktif doğrulamayı yalnızca güncel, atfedilebilir ve yetkilendirilmiş bir uygulama sınırının ortaya çıktığı yerlerde harcamaktır.
Bir sonraki makale bu modelde bulunan en yaygın yüksek değerli sınırı takip etmektedir: giriş sayfası herkese açıktı ancak kimlik sınırı başka bir yerdeydi.
Bu teknik not ne kadar güncel?
En son kaynak incelemesi, içerik güncellemesi veya yayın tarihi gösterilmektedir.
Birincil kamu kayıtları kontrol edildi. Ortama özgü davranış, ayrıca yeniden üretilmedikçe iddianın dışındadır.