Güvenlik Değerlendirmeleri
Önceki Epostada Alanların Kullanım Yetkilendirilmesi için Gönderici Politik Çerçevesi (SPF), 1. Sürüm Sonraki
Güvenlik Değerlendirmeleri
İşlem Sınırları
Eposta ile ilgili pekçok şey gibi, kötü niyetlilerin protokolü hizmet reddi (DoS) saldırıları için bir bulvar olarak kullanabileceği bazı yöntemler vardır. Burada anahatlarıyla ele alınacak olan işlem sınırları şu tür saldırılardan korunmak için tasarlanmıştır:
  • Kötü niyetli biri, mağdurun alanına atıflarda bulunan bir SPF kaydı oluşturabilir ve farklı SPF istemcilerine çok sayıda posta gönderebilir; bu SPF istemcileri bir hizmet reddi saldırısı oluştururlar. Aslında, SMTP oturumunda DNS sorgularında kullanılandan daha az bayt kullanılmasını sağlayarak, SPF istemcileri saldırganın band genişliğini arttırmakta kullanılmış olurlar.
  • DNS sorgularının sayısını sınırladığı varsayılan check_host() gerçeklenimlerinin olduğu yerlerde, kötü niyetli alanlar posta gönderdikleri zaman, hedeflerinde boş hesaplama çabasına yol açarak bu sınırların aşılmasına sebep olan kayıtlar yayınlayabilirler. Kötü niyetli alanlar ayrıca, bazı gerçeklenimlerin üşırı bellek ve işlemci kullanmasına veya hataların tetiklenmesine yol açan SPF kayıtları tasarlayabilirler.
  • Kötü niyetli alanlar, geniş çaplıa meşru posta konaklarından geliyormuş gibi görünen büyük hacimde posta gönderebilirler. Bu meşru makineler ilgili kayıtları almak isterken aşırı bir DNS yükü oluşmasına sebebiyet verirler.
Bunlardan dolayı, SPF kaydında bir üçüncü tarafa atıfta bulunulması durumu bir hizmet reddi saldırısı için en kolay istismar edilen durumdur. Sonuç olarak, tek başına bir posta sunucusu için makul görünebilen sınırlar, çok sayıda konak bir araya geldiğinde kabul edilemez miktarda band genişliği harcanmasını sebep olabilir. Bu bakımdan, işlem sınırlarının oldukça düşük tutulmasına ihtiyaç duyulur.
SPF gerçeklenimleri, DNS sorgusuna yol açan mekanizmaların ve değiştiricilerin sayısını SPF sınaması başına en fazla 10 sorgu olabilecek şekildi sınırlamalıdır. Bunlara, kullanımları ek sorgulara yol açan "include" mekanizması ve "redirect" değiştiricisi dahildir. Bir sınama sırasında bu miktar aşılırsa, bir "PermError" dönmelidir *ZORUNLU*. "redirect" değiştiricisinden başka "include", "a", "mx", "ptr" ve "exists" mekanizmaları da bu sınırla ilgilidir. "all", "ip4" ve "ip6" mekanizmaları DNS sorgusu gerektirmezler ve dolayısıyla bu sınırla ilgili sayıya dahil edilmezler. "exp" değiştiricisi de bu sayıya dahil edilmez, çünkü bunun DNS sorgusu SPF kaydı değerlendirildikten sonra yapılır.
"mx" ve "ptr" mekanizmaları veya %{p} makrosu değerlendirilirken 10'dan fazla MX ve PTR kaydı sorgusu ve sınaması yapılamaması için bir sınırlama olmalıdır *ZORUNLU*.
SPF gerçeklenimleri, DNS sorgularından sağlanacak toplam veri miktarını sınırlamalıdırlar *ÖNERİ*. Örneğin, TCP üzerinden DNS veya EDNS0 mümkün olduğunda, aşırı band genişliği veya bellek kullanımından veya hizmet reddi saldırılarından kaçınmak için ne kadar veri kabul edilebileceği ile ilgili açıkça bir sınırlama koymak ihtiyacı ortaya çıkabilir.
MTA'lar veya işlemciler ayrıca, check_host() işlevinin işlem yapma süresine bir sınırlama getirebilirler. Böyle bir sınırlamanın en azından 20 saniyelik bir süre sağlaması gerekir *ÖNERİ*. Bu sınır aşıldığında, sınama sonucu "TempError" olmalıdır *ÖNERİ*.
Kayıt yayınlayan alanlar "include" mekanizması sayısını ve "redirect" değiştiricisi zincirini olası en düşük miktarda tutmaya çalışmalıdırlar *ÖNERİ*. Alanlar ayrıca, bir kaydın değerlendirilme ihtiyacını ortaya çıkaran DNS bilgisi mitarını da azaltmaya çalışmalıdırlar *ÖNERİ*. Bu, daha az DNS bilgisi gerektiren yönergeler seçilerek ve SPF kayıtlarına ucuz maliyetli mekanizmalar yerleştirilerek yapılabilir.
Örneğin, şöyle bir alan ayarlaması yapılmış olsun:
   example.com.      IN MX   10 mx.example.com.
   mx.example.com.   IN A    192.0.2.1
   a.example.com.    IN TXT  "v=spf1 mx:example.com -all"
   b.example.com.    IN TXT  "v=spf1 a:mx.example.com -all"
   c.example.com.    IN TXT  "v=spf1 ip4:192.0.2.1 -all"
"a.example.com" alanı için check_host() işlevinin değerlendirmesi, "example.com" için MX kayıtlarını ve ardından listelenen konaklar için A kayıtlarını gerektirir. "b.example.com" için yapılan değerlendirme ise, sadece A kayıtları gerektirir. "c.example.com" için ise hiçbir şey gerekmez.
Bununla birlikte, yönetimsel değerlendirmeler sözkonusu olabilir: "ip4" yerine "a" kullanımı konakların yeniden numaralanmasını kolaylaştırır. "a" yerine "mx" kullanmak da posta konaklarında kolayca değişiklik yapılabilmesini sağlar.
SPF Yetkilendirmeli Eposta Yanlış Kimlikler İçerebilir
"MAIL FROM" ve "HELO" kimlikleri ile ilgili yetkilendirmeye olabildiğinden daha fazla anlam yüklemeye çalışılmamalıdır. Alanın SPF kaydı gönderen konağı yetkilendirdiğinden ve ileti diğer kimlikleri başlığında listeleyebildiğinden, kötü niyetli bir göndericinin SPF tarafından kullanılan kimliklerde kendi alanını kullanarak bir ileti teslim etmeye çalışması mümkündür. Kullanıcı veya MUA, yetkili kimliğin diğer varlığı bilinen kimliklerle (örn, From: başlık alanında) eşleşip eşleşmediğine dikkat etmedikçe, kullanıcı güvenlik konusunda bir yanlışa düşebilir.
Taklit Edilmiş DNS ve IP Verisi
Kötü niyetli kişiler bu protokolü, check_host() işlevinin altını oyacak şekilde iki bakımdan istismar edebilirler:
  • check_host() değerlendirmesi önemli derecede DNS'ye bağlıdır. Bir saldırgan, DNS alt yapısına saldırıp check_host() işlevinin taklit DNS verisi görmesine ve yanlış sonuçlar döndürmesine sebep olabilir. Asıl alan kaydı "Fail" ile sonuçlanacak bir <ip> değeri için "Pass" döndürülmesini sağlayabilir. DNS zayıflıkları ile ilgili bilgi edinmek için [RFC3833]'e bakınız.
  • İstenci IP adresi olarak <ip>'nin doğru olduğu varsayılır. Saldırgan TCP sıra numaralarını taklit ederek postanın bir alan için yetkilendirilmiş bir konaktan geliyormuş gibi görünmesini sağlayabilir.
Çapraz-Kullanıcı Sahtekarlığı
Tanımı gereği, SPF kuralları alan isimleri ile yetkili konakları eşler, eposta adresleri ile yetkili kullanıcıları eşlemez. "l" makrosu, belli eposta adresleri için yetkili konakları tek tek tanımlayacak bir yol sağlasa da (bkz, Makrolar), belli eposta adreslerinin aynı konağın bireysel kullanıcıları tarafından kullanıldığını SPF üzerinden doğrulamak genelde imkansızdır.
Posta hizmetleri ve onların MTA'ları doğrudan doğruya çapraz-kullanıcı sahtekarlığından korunabilir: SMTP AUTH'a ([RFC2554]) dayanarak, kullanıcılar sadece kendi denetimleri altındaki eposta adreslerini kullanmaya zorlanmalıdırlar ([RFC4409]'un 6.1. bölümüne bakınız). Başka bir anlamda kullanıcıların tek tek kimlik doğrulaması PGP ([RFC2440]) veya S/MIME ([RFC3851]) gibi bir ileti şifrelemesi ile yapılabilir.
Güvenilmez Bilgi Kaynakları
SPF, üçüncü şahıslar tarafından sağlanan bilgi kaynaklarını kullanır: "HELO" alan adı, "MAIL FROM" adresi ve SPF kayıtları gibi. Bu bilgi daha sonra "Received-SPF:" izleme alanında alıcıya aktarılır ve bir ihtimal, bir SMTP red iletisi biçiminde istemcinin MTA'sına döndürülür. Bu bilginin geçersiz karakterler ve aşırı uzunluktaki satırlar bakımından sınanması gerekir.
Yetkilendirme sınaması başarısız olduğunda, red yanıtında bir izahat dizgesi bulunabilir. Hem alıcının hem de reddedilen göndericinin bu izahatın alıcı tarafından değil, SPF kaydının yayıncısı tarafından sağlandığından haberdar edilmeleri gerekir. Bu izahat kötü niyetli URL'ler içerebileceği gibi taciz edici veya yanıltıcı olabilir.
Böyle iletiler göndericisine döndüğünden ve izahat dizgeleri göndericinin ta kendisi tarafından iddia olunan kimlikteki alan tarafından yayınlanan gönderici kurallarına göre geldiğinden bu belki de göründüğünden daha az kaygı verici olabilir. DSN asıl göndericiden başkasına yönlenmediği sürece kötü niyetli izahat dizgelerini gören kişiler, iletilerinin, böyle dizgeleri kendi SPF kayıtlarında yayınlayan alanlardan gelmesi gerektiğini iddia eden kişiler olacaktır. Uygulamada ise, DSN'ler yanlış yönlenebilir; bir MTA bir postayı kabul ettikten sonra sahte bir adrese bir DSN üretebilir veya bir eposta yönlendiricisi DSN'yi geriye özgün göndericisine yönlendirmeyebilir.
Mahremiyetin İfşası
SPF kayıtlarının sınanması DNS sorgularının alan sahibine gönderilmesine sebep olur. Bu DNS sorguları, özellikle "exists" mekanizmasından kaynaklanmışlarsa, epostayı gönderen ve epostanın gönderildiği MTA hakkında bilgi içerebilirler. Bu noktada gizlilikle ilgili bazı endişeler devreye girebilir; bunlar, yerel kanunlara ve alan sahibi ile epostayı gönderen kişi arasında ilişkiye az veya çok bağlı konular olabilir.
Önceki Üst Ana Başlık Sonraki
Etkilenimler Başlangıç Teşekkür
Bir Linux Kitaplığı Sayfası