[ Bölgesel gereksinimler ]

Açık varlık ve etki alanı sınırlarıyla banka etki alanı kimlik doğrulamasını araştırın

Örneklenen web sitelerini tüm gönderen mülkü olarak ele almadan, açık kurum, marka, yan kuruluş ve şube eşlemelerini kullanarak banka alan adlarını araştırın.

EmailAuth araştırma ekibi tarafından · 8 dakikalık okuma

[ Anahtar noktalar ]

  • Yetki alanına uygun bir bankacılık popülasyonu kullanın ve sınırlarını koruyun.
  • Paylaşılan markalar ve şubeler de dahil olmak üzere ayrı kurumsal ve etki alanı ağırlıklandırması.
  • Yalnızca genel DNS müşteri riski veya uyumluluğu sonucunu çıkarmayın.
Bu sayfada

Etki alanını ölçmeden önce bankacılık kuruluşunu tanımlayın

Banka alanı araştırması, lisanslı kurum, holding şirketi, marka, şube ve teknoloji hizmet sağlayıcısını birbirinden ayırmalıdır. Bu birimler bir web sitesini paylaşabilir veya farklı alanları yönetebilir ve ilişkileri birleşme veya yeniden markalama yoluyla değişebilir. Bir markanın halka açık web sitesindeki DNS gözlemi, yasal kurumun tüm e-posta varlığını otomatik olarak tanımlamaz. Dolayısıyla varlık-alan eşlemesi, atılacak bir ön ayrıntı değil, kanıtın bir parçasıdır.

Bu yazı, banka popülasyonu toplamadan veya etki alanlarını taramadan bir yöntem önermektedir. Gerçek bir kurumun güvenliği, uyumluluğu, ödeme gücü veya müşteri riski hakkında herhangi bir iddiada bulunmaz. Amaç, belirsiz marka isimlerinden oluşan bir lig tablosu yerine tekrarlanabilir bir haritalama ve teknik olarak sınırlı bir sonuç üretmektir.

Seçilen yetki alanına uygun bir otorite kullanın

ABD sigortalı banka kapsamı için, FDIC BankFind API belgeleri kurum verilerini konum veya şube verilerinden ayırır. Bu, tüm bankaların veya finansal hizmetlerin küresel bir listesi değil, yararlı bir resmi kaynak yapısıdır. Başka bir yetki alanını kapsayan bir çalışma, ilgili otoriteyi ve kapsamını korumalıdır. Farklı düzenleyici toplulukları tek bir niteliksiz bankacılık paydası altında karıştırmayın.

FDIC belgelerinde ayrıca birincil internet adreslerinin kurumlar tarafından bildirildiği ve bağlantılı sitelerin FDIC'nin kontrolü dışında olduğu belirtilmektedir. Sorumluluk reddi beyanı yorum açısından önemlidir: Listelenen bir web sitesi, kaynak destekli bir haritalama ipucudur, her sayfanın onaylanması veya gönderen etki alanlarının kapsamlı bir envanteri değildir. Web sitesi alanını tam bir güvenlik beyanı olarak ele almak yerine, alanın menşeini ve doğrulama tarihini saklayın.

Sabit bir isim listesi yerine bir ilişki modeli oluşturun

Kurum, ilgili olduğu yerde ana grup, şube veya konum ve genel marka için ayrı tanımlayıcılar oluşturun. Örneklenen her etki alanını belirli bir varlığa ve bu ilişkiyi destekleyen kaynağa bağlayın. Birleşmeler, yeniden adlandırılan markalar ve kullanımdan kaldırılan alan adları için geçerlilik tarihlerini kaydedin. Tanıdık bir bankacılık grubuyla etiketlenen tek bir satır, birçok lisanslı kuruluşu ve farklı operasyonel sorumlulukları gizleyebilir.

Paylaşılan alanların nasıl ağırlıklandırılacağını tanımlayın. Her şubeyi ayrı bir kimlik doğrulama dağıtımı olarak saymak, büyük bir şube ağına orantısız bir etki verebilir. Yalnızca ana alan adının sayılması, bağımsız gönderme düzenlemelerine sahip yan kuruluşları hariç tutabilir. Her iki yaklaşım da doğası gereği her soru için doğru cevap değildir; Çalışma herhangi bir metriği hesaplamadan önce bir birim seçmeli ve sonuçlarını açıklamalıdır.

Örneklenen web sitelerini gönderenin mülkünden ayırın

Bir kurum, çalışan postaları, müşteri bildirimleri, kart hizmetleri, anketler, pazarlama, işe alım ve dış kaynaklı iletişimler için farklı alanlar kullanabilir. Herkese açık bir web sitesi örneği genellikle bunların hepsini tanımlamaz. Yetkili bir araştırma kapsamı olmadan bu boşluğu doldurmak için makul alt alanlar oluşturmayın veya müşteri mesajları aramayın. Eşleme, bir alan adının örneklenmiş bir web sitesi mi, bağımsız olarak kanıtlanmış bir gönderen mi yoksa çözümlenmemiş bir aday mı olduğunu belirtmelidir.

RFC 7208 değerlendirir SPF ilgili SMTP kimliğini kullanarak. RFC 9989 değerlendirir DMARC hizalama görünür Kimden etki alanına gider ve politika keşfini tanımlar. Bu kurallar sınırlamayı somut hale getirir: bir web etki alanında yayın yapmak, başka bir etki alanı veya tedarikçi tarafından kontrol edilen bir yol aracılığıyla gönderilen mesajların kimlik doğrulamasını sağlayamaz.

Kontrol ve ilişkilendirme belirsizliğini koruyun

Kayıt bilgileri bir alan adı ilişkisinin belgelenmesine yardımcı olabilir ancak mevcut operasyonel kontrolün kanıtı olarak değerlendirilmemelidir. RFC 9083 RDAP nesnelerini, rollerini ve olaylarını tanımlar; RFC 9537 Uygulandığı yerde redaksiyon bilgilerini açıklar. Gizlilik korumalı veya eksik bir yanıt, bir bankanın mülkiyeti gizlediği iddiası değil, görünürlük sınırı olarak kalmalıdır.

Benzer şekilde, paylaşılan bir DNS ana bilgisayarı veya gönderen sağlayıcı, kurumların bir güvenlik politikasını veya idari hesabı paylaştığını belirlemez. Gözlemlenen bağımlılığı, çıkarılan kontrolden ayrı olarak kaydedin. Sahiplik veya gönderenin niteliği desteklenemiyorsa, ilişkiyi çözülmemiş olarak işaretleyin ve tanıdık bir hizmet adından kesinlik iddia etmek yerine, beyan edilen bir kural kapsamında hariç tutun.

DNS ölçümünü bağımsız olarak tasarlayın

Eşlenen etki alanı listesini dondurun ve tam sahip adlarını, kayıt türlerini, çözümleyici bağlamını, zaman damgalarını, yeniden denemeleri ve ayrıştırıcı sürümlerini belirtin. Tam ad aramasını geçerli geçerli politika keşfinden ayırt edin. Başka bir analistin sonucu yeniden üretebilmesi için ham yanıtları ve hata kategorilerini saklayın. Başarısız bir sorgu, ilgili kanıt ve kapsam olmadan kimlik doğrulaması olmayan bir banka olarak tanımlanmamalıdır.

Yetkili ve özyinelemeli gözlemleri toplandıkları yerde ayrı tutun. Birden fazlasını koru TXT kayıtları ve protokol seçiminden önce dizeler. Bir sınıflandırma, tüm kurumun başarılı veya başarısız olduğunu değil, örneklenen isimde neyin gözlemlendiğini tanımlamalıdır. Bu çalışmada hiçbir DNS sorgusu, SMTP araştırması veya alınan ileti örneği toplanmadı.

Tüketici riski ve uyumluluk çıkarımlarından kaçının

DNS yayını tek başına müşterinin mali bilgilerinin açığa çıkıp çıkmadığını, dolandırıcılığın meydana gelip gelmediğini veya bir kurumun yasal bir gerekliliğe uyup uymadığını göstermez. Bu sonuçlar farklı kanıtlar ve nitelikli inceleme gerektirir. Eksik veya geçersiz bir politika gözlemi, banka hizmetlerinin güvenliğine ilişkin bir iddia haline gelmeksizin, çalışma kapsamındaki teknik bir bulguyu haklı gösterebilir.

Ölçü, ağırlıklandırma ve sınırlamalar şeffaf ve gerekçeli olmadığı sürece kurumları basit bir kimlik doğrulama puanına göre sıralamayın. Uygulanmasını talep eden bir politika, her meşru akışın uyumlu olduğunu veya tüm kimliğe bürünmelerin önlendiğini kanıtlamaz. Çalışma, daha düşük gözlemlenen bir ortamın doğrudan müşterinin mali kaybını öngördüğünü ima etmekten kaçınmalıdır.

Varlık-etki alanı eşleme çalışma sayfası

Yargı yetkisi, yetki kaynağı, kaynak tarihi, kurum tanımlayıcı, varlık türü, ana ilişki, marka, şube ilişkisi ve örnek alan adı için sütunlar oluşturun. Etki alanı bağlantısı kanıtlarını, geçerlilik tarihlerini, eşleme güvenini, etki alanı rolünü, sorgu planını ve hariç tutmaları ekleyin. Bire çok eşlemeler tek satırda aslına uygun olarak temsil edilemediğinde ilişki tablosunu koruyun.

Sürüm paketi eşlemeyi, kaynak kaynağını, normalleştirilmiş sorgu girişlerini, ham gözlemleri ve sınıflandırma kurallarını içermelidir. Bir incelemeci, hangi markanın veya alt kuruluşun tasarlandığını tahmin etmeden, yayınlanmış bir bulguyu kuruma ve tam alana kadar takip edebilmelidir. Hassas müşteri verileri, hesap ayrıntıları ve özel çalışan bilgileri bu yöntem için gereksizdir ve onu süslemek için toplanmamalıdır.

Kurgusal teşhis: Bir grup web sitesi her yan kuruluş haline gelir

Kurgusal bir araştırmacı, bir bankacılık grubunun halka açık web sitesini seçer ve gözlemlediği politikayı her bağlı kuruluş için sonuç olarak rapor eder. Haritalama incelemesi, kaynak listesinin birkaç kurumu birbirinden ayırdığını, alan kanıtlarının ise yalnızca grup web sitesini desteklediğini ortaya koyuyor. Önerilen düzeltme, daha dar web sitesi gözlemini yayınlamak ve daha geniş gönderen mülkünü ölçülmemiş olarak işaretlemektir.

Ekip daha sonra yetkili yan alan adı kanıtlarını elde edebilir ve gözden geçirilmiş bir veri kümesi sürümü altında kapsamı genişletebilir. Boşlukları tahmin edilen isimlerle doldurmamalı veya eşlemenin eksik olması nedeniyle bir güvenlik kusurunu ima etmemelidir. Bu senaryo kurgusaldır ve gerçek bir banka, alan adı, tarama veya uyumluluk iddiası içermez.

Sürüm durumu

Katalog, varlık-alan eşlemesinin yayınlanmasını ve örneklenen web etki alanları ile daha geniş gönderen alanı arasında bir ayrım yapılmasını gerektirir. Bu orijinal haritalama açık kalır. Gerçek kişi tarafından yapılan uzman incelemesi, kaynağın uygulanabilirliği, üretim yolları, erişilebilirlik ve sahibinin serbest bırakılması da açık kalacaktır. Bu taslak, kurumlarla ilgili doldurulmuş bir veri seti veya bulgular değil, bankaya özgü bir araştırma tasarımı sunmaktadır.

[ Götürmek ]

Bir banka-etki alanı kimlik doğrulama gözlemini yorumlamadan önce varlık-etki alanı ilişkisini ve kapsamını yayınlayın.

[ Role göre ]

Bu sizin için ne anlama geliyor?

Sonraki pratik adımlar için rolünüzü seçin.

Bankacılık araştırmacısı

Düzenlenen kuruluşu tanımlayın

Bir marka veya şubenin mutlaka bir kurumla aynı sayma birimi olması gerekmez.

Sonraki adımlar

  1. Yetki tanımlayıcılarını koruyun.
  2. Birleşmeyi takip edin ve tarihleri ​​yeniden adlandırın.

Etki alanı analisti

Web alanı örneğini ciltleme

Birincil web sitesi tam bir posta envanteri değildir.

Sonraki adımlar

  1. Etki alanı rollerini etiketleyin.
  2. Çözümlenmemiş ilişkilendirmeyi görünür tutun.

Editoryal incelemeci

Desteklenmeyen risk iddialarından kaçının

DNS sonuçları mali kayıp veya uyumluluk başarısızlığı tespit etmez.

Sonraki adımlar

  1. İddialara duyarlı dili inceleyin.
  2. Daha geniş gönderici mülkiyeti iddiaları için kanıt isteyin.

[ SSS ]

Sık sorulan sorular

FDIC verileri dünya çapındaki her bankayı kapsıyor mu?

Hayır. Kurumu ve konum verileri yargı alanına özgü bir örnektir; diğer popülasyonların uygun kaynaklara ihtiyacı vardır.

FDIC BankFind Suite: API Belgeleri

FDIC web sitesi bağlantıları tam bir gönderen envanteri midir?

Hayır. Belgeler, birincil internet adreslerinin kurum tarafından rapor edildiğini ve bağlantılı sitelerin sorumluluğuna ilişkin sınırlamalar içerdiğini söylüyor.

FDIC BankFind Suite: API Belgeleri

Her şube bağımsız bir dağıtım olarak sayılabilir mi?

Yalnızca açıkça dal ağırlıklı bir tasarım altında; aksi takdirde paylaşılan alanlar tekrarlanan teknik gözlemlere neden olur.

Ana web sitesi ikincil kimlik doğrulaması sağlıyor mu?

Hayır. Eşlemenin, hak talebinde bulunulan her varlığı ve etki alanı ilişkisini desteklemesi gerekir.

RDAP mevcut operasyonel sahipliği kanıtlayabilir mi?

Tek başına değil. Roller, olaylar ve redaksiyon sınırları görünür kalmalıdır.

RFC 9083 : RDAP için JSON Yanıtları

Eksik bir politika müşterinin finansal riskini kanıtlar mı?

Hayır. DNS kanıtları ifşa edilmeyi, dolandırıcılığı veya yasal uyumu kanıtlamaz.

Bankalar tarandı mı veya sıralandı mı?

Hayır. Hiçbir orijinal kurum veri seti veya teknik gözlem toplanmadı.

Hangi yayın kanıtları açık kalıyor?

Varlık-alan eşlemesi ve web alan adları ile daha geniş gönderen alanı arasındaki açık ayrım açık olmaya devam etmektedir.

[ Kaynaklar ]

Kaynaklar

  1. RFC 9989: DMARC

    Bölümler §4.7 DMARC Politika Kaydı Formatı · §4.8 Resmi Tanım · §4.10 DNS Ağacı Yürüyüşü · §5.3.2 DMARC Mekanizmasının Geçerli Olup Olmadığını Belirleme · §4.4 Tanımlayıcı Hizalamasının Açıklaması · A.6 pct Etiketinin Kaldırılması

  2. RFC 7208 : Gönderen Politikası Çerçevesi

    Bölümler §2.4 Kimlikten Gelen Posta · §3.2 Çoklu DNS Kayıtları · §4.5 Kayıtları Seçme · §4.6.4 DNS Arama Sınırları · §5.2 şunları içerir · §6.1 yönlendirme · §8 Sonuç İşleme

  3. RFC 9083 : RDAP için JSON Yanıtları

    Bölümler §4 Ortak Veri Yapıları · §5.1 Varlık Nesne Sınıfı · §5.3 Etki Alanı Nesne Sınıfı

  4. RFC 9537 : RDAP Yanıtlarında Düzenlenmiş Alanlar

    Bölümler §3 Redaksiyon Yöntemleri · §4 Düzenlenmiş RDAP Yanıtı

  5. FDIC BankFind Suite: API Belgeleri

    Bölümler Genel Bakış · API Tanım Dosyaları: Kurum ve Konum API tanımları · FDIC.gov'dan ayrılmak üzeresiniz: birincil internet adresi sorumluluk reddi beyanı

[ Sözlük ]

Sözlük

Kurum birimi
Şube veya markadan farklı, seçilen yetkili tarafından tanımlanan bankacılık kuruluşu.

FDIC BankFind Suite: API Belgeleri

Birincil web sitesi eşlemesi
Tam bir gönderen mülkiyeti iddiası değil, genel bir web sitesine kaynak tarafından desteklenen bir bağlantı.

FDIC BankFind Suite: API Belgeleri

Gönderen mülkü
Ayrı yetkili kanıtlar gerektiren gerçek gönderme iş akışları ve kimlikleri kümesi.
İlişkilendirme belirsizliği
Kamuya açık bir alanın veya bağımlılığın operasyonel kontrole bağlanmasındaki sınırlama.

RFC 9537 : RDAP Yanıtlarında Düzenlenmiş Alanlar

Kurumsal menşe

Neden en iyi finans kurumları ve hükümetler e-posta güvenlik kontrol panellerini kullanımdan kaldırdı.

Geleneksel e-posta kimlik doğrulama platformları size bir gösterge tablosu satar ve mühendislerinizden bu işi yapmalarını ister. Riskli ortamlarda, manuel gözetim, gecikmeli uygulama, konfigürasyon kayması ve izlenmeyen gölge alanlar anlamına gelir.

EmailAuth aracılı e-posta kaynak platformudur. Temsilcilerimiz uyguluyor p=reject, üçüncü taraf gönderenleri uyumlu tutun ve alan adlarınızı tam sürüme taşıyın RFC 9989 döngüdeki insan tarafından denetlenebilirliğe sahip yeni DMARC standardı uyumluluğu.

Hükümetler Büyük işletmeler 1. Seviye finans kurumları

SaaS · Özel kiracılık · Şirket içi hava boşluklu · BYOK şifrelemesi

Bilgi Bankası