Doğru SPF (Sender Policy Framework) Yapılandırması

Özellikle son on yılda Spam ile savaşmak için onlarca takla atmaya başladı insanoğlu. DKIM‘ler, DNSSEC‘ler derken SPF (Sender Policy Framework) diye bir standart daha girdi sistem yöneticisinin hayatına. Tabi hepsi yararlı şeyler, maksat istenmeyen mailler gelmesin, hayat daha kolay olsun.

Bu yazı aslında SPF’in ne olduğu ile ilgili değil. SPF’in ne olduğu ile ilgili www.openspf.org akabinde https://en.wikipedia.org/wiki/Sender_Policy_Framework adreslerini inceleyebilirsiniz.

Kısaca acıklamak gerekirse; SPF, Spam ile mücadele tekniklerinden sadece bir tanesi.
Eposta sunucusunun hangi şartlarda çalıştığını karşı SMTP sunucusuna bildiren kuralları içeren bir DNS kaydı.
Esas amaç eposta’ların gerçekten doğru yerden geldiğini teyit ederek sahte (spoof) epostaların önüne geçmek, phishing‘leri engellemek.

Çalışma mantığı gayet basit. SMTP sunucunuzda SPF kontrolünü aktif ettiğinizde. Eposta gönderen Domain’in DNS alanından TXT kaydını istiyor. İçinden “v=spf” olan kaydı dikkate alarak Domain’in bu değişkenlere uyup uymadığını doğrulunu teyit ediyor.

Aslında SPF politikasının TXT tipi yerine SPF isminde başlı başına yeni bir kayıt olarak DNS’de var olması taraftarıyım. Tabi bunu IETF‘deki elemanlarda istiyordur da durumu ne bilmiyorum. Bu arada konu RFC4408 üzerinden dönüyor.

İşin teorik kısmı bir yana gerçek hayattan bir örnek ile sadede geleyim. Aşağıdaki DNS sorgusuna bir bakalım.

nslookup -q=txt domain.com

Bu komutun çıktısı ise şu şekilde;

v=spf1 a mx ip4:77.92.136.90 mx:mail.domain.com ~all

Gördüğünüz gibi basit bir DNS sorgusu ile SPF politikasına çok kolay ulaşıyoruz. Buna ulaştıktan sonra epostayı alan SMTP sunucusu nasıl yolumluyor ve değerlendiriyor ona bir bakalım.

#1 Epostayı alan SMTP sunucusu hemen Domain’in DNS sunucsundan “domain.com” için TXT kaydını ister ve SPF politikasına ulaşır.

#2 SPF söz dizimi (syntax) analiz edilir ve hangi mekanizmalarla çalıştığı belirlenir. Yukarıdaki örnekte “a” ve “mx” mekanizmalarını doğrulama için kullanılabilir olduğu belirtildiğinden buna göre doğrulamalar işletilir.

Bu doğrulamalar “a” için;

Epostayı gönderen SMTP adresinin A kaydı sorgulanır ve döndürdüğü IP adresi, SPF’de belirtilen IP adresi ile karşılaştırılır.
Örnek SPF politikamızda domain.com’un A kaydından dönen IP ile SPF alanındaki “Ip4:77.92.136.90” değerlinin eşleşip, eşleşmediğine bakılır. Eşleşmiyorsa “Fail” olarak eposta reddedilir ve arkasından gelen mekanizmalar çalıştırılmaz.

“mx” doğrulaması için ise;

Epostayı gönderen SMTP adresinin IP adresi, SPF’de belirtilen IP adresine ait olarak değerlendirilirse “pass” olarak geçilir. Şimdi “mx” mekanizması sorgulanabilir.

Örnek SPF politikamızda domain.com’un MX kaydı sorgulanır ve dönen Host isminin hangi IP adresini döndürdüğü tespit edilir, daha sonra Ip4 alanındaki 77.92.136.90 IP’si ile eşleşiyormu diye bakılır.

Gördüğünüz gibi olay SPF direktiflerini değerlendiren DNS maymunluğu ile dönüyor.

Mantığı biraz kavradıktan sonra nasıl düzgün bir SPF kaydı oluşturmalıyız? Ona biraz kafa yoralım.

Bunun kesin bir cevabı yok her sunucunun veya ağ’ın çalışma şekilleri, iletişim kurduğu sistemler ve erişim durumlar farklılık gösterebiliyor fakat biz genelleme yaparak en azından doğru bir kaç şey söyleyebiliriz.

Tavrınızı Belirleyin

SPF’in sonundaki söz dizimine dikkat etmişsinizdir, “~all” dediğinizde SPF polikalarından birisinde eşleşme bulunmasa bile SoftFail olarak sonuç döner. SMTP sunucusu isterse alır, isterse almaz. Yani bir gri alan yaratır. Siz böyle yapmayın.

Aynı şekilde “+all” ,”?all” demekte yumuşak bir SPF kaydına sahip olmanızı sağlar.

SPF’i düzgün işletecekseniz tavrınız ne olsun “-all” yapın.

SPF’de herhangi bir eşleşmeme durumunda direkt Fail olmasını sağlamalısınız ki Spoofing ve Phising’den yırtasınız.

IP Aralığını Kısıtlayın

SMTP sunucusunun çalıştığı Ağ’ın Subnet’lerinide SPF sözdiziminde belirtebilirsiniz.
Örneğin: ip4:198.2.128.0/24 ip4:198.2.132.0/22 gibi.

Bu çok tercih edilen bir şey değildir. Aynı subnet’den başka bir sunucu başkasına tahsis edilmiş veya hacklenmiş olabilir. SMTP sunucusunun çalıştığı IP’leri olabildiğince /32 veya /28 vererek yüzeyini daraltacak hareketler yapın.

Neyin Sorgulanması Gerektiğini Belirleyin

SPF’de a, mx, ptr, exists (ip4, ip6’yı saymıyorum) gibi mekanizmalara göre sorgulamalar yapılır. SMTP sunucunuzun host ismini veya Domain’e ait olan MX ismini sorgulamak çoğu zaman daha etkilidir. Özellikle MX üzerinden bir değerlendirme SPF’in daha kesin bir eleme yapılmasını sağlar. O nedenle SPF politikanızdaki host ismini MX’e göre düzenleyebilirsiniz.

PTR Kullanmaktan Kaçının

RFC7208 Section 5.5‘de artık kullanmayın diyorlar. Bunu gözden kaçırsanız bile zaten SPF’de bir yavaşlık hisettikten sonra kenizde kaldıracaksınız. PTR mekanizması haddinden fazla yavaş çalışıyor ve genelde DNS sunucularının adam gibi PTR yapılandırması olmadığından kesin bir çözüm getirmiyor. Kullanmayın.

İdeal SPF

Yukarıdaki genellemeler doğrultusunda bir kaç karşılaştığım senaryoya göre SPF’leri sıralayalım.

Sadece bir sunucunuz var ve olay hep tek bir SMTP sunucusundan dönüyorsa. Aşağıdaki politika işinizi görür. Fazla abartmaya gerek yok.

v=spf1 mx ip4:77.92.136.90 -all

Bu en temiz SPF politikalarından biri. SPF’i değerlendiren sunucu direkt domain.com’un MX’ine bakar. Eğer mail.domain.com Ip4 alanındaki değer ile eşleşmiyorsa Fail verir. Eşleşiyorsa eposta kabul edilir.

Örnek olması açısından şu senaryo da işletilebilir. Bir “a” mekanizması ekleyip MX’den önce değerlendirilmesini sağlayabilirsiniz.

v=spf1 a mx ip4:77.92.136.90 ip4:77.92.136.91 -all

Önce domain.com’un A kaydına baklır, eğer domain.com’un döndürdüğü IP adresi 91 veya 90 IP’lerinden biri ile eşleşiyorsa MX mekanizmasına hiç bakılmadan “Pass” olarak değerlendirilir, eşleşmiyorsa “mx” mekanizmasına geçilir.

Bonus

Şimdi politikamızı biraz daha sıkılaştırıp herhangi bir DNS Black List’e bağlayarak güçlendirebiliriz, ayıktırayım. Bunu yaparkan “exists” mekanizmasını kullanıyoruz.

v=spf1 exists:%{d}.dbl.spamhaus.org a mx ip4:77.92.136.90 ip4:77.92.136.91 -all

Domain için “a” ve “mx” mekanizmaların değerlendirilmeden önce “exists” mekanizması dikkate alınıyor. “exists” mekanizmasında çeşitli host isimleri oluşturabileceğiniz makrolar bulunuyor. Bunları kullanarak host isimleri oluşturabilir ve Black List servislerine uydurabilirsiniz.

Spamhaus’dan DNS Black List sorgusu aşağıdaki gibi yapılıyor.

nslookup -q=TXT domain.com.dbl.spamhaus.org

biz;

exists:%{d}.dbl.spamhaus.org

direktifinde %{d} makrosunu kullanarak

exists:domain.com.dbl.spamhaus.org

gibi bir kayıt’ın var mı yok mu olduğunu sorguluyoruz.

Eğer varsa Black List’de olmuş oluyor.

Lazım Olursa Genişletin

Internet sürekli evriliyor, gelişyor bunun sonucunda da sürekli yeni sernaryolar ortaya çıkıyor. Şuraya bağlayacağım. Sendloop, Mandrill, MailGun gibi üçüncü parti SMTP servisleri var piyasada hem kendi SMTP sunucunuzu işletip hem de buradan mail göndereceğiniz senaryolarla karşılaşabiliyorsunuz. Bu aşamada “include” mekanizmasını kullanıyoruz.

v=spf1 a mx ip4:77.92.136.90 ip4:77.92.136.91 include:spf.mandrillapp.com -all

Include mekanizmasını kullanarak spf.mandrillapp.com TXT kaydındaki SPF politikasını da kendi politikamızın içine dahil edebiliyoruz.
Burada sırası ile “a”, “mx” mekanizmaları çalışır bunlardan herhangi birinde eşleşen IP bulunmaz ise “include” mekanizmasına bakılır ve oradaki politikada yine eşleşme aranır.

Sonuç

SPF kullanın, net olun, sert olun :)