Sunucunuz Açık Relay mi? 5 Senaryoyla Test Edip Postfix'i Sağlamlaştırma
Açık relay eski bir sorun değil; Postfix varsayılanı değiştiği ya da mynetworks fazla genişlediği an bugün de geri geliyor. Saldırganın gerçekte denediği 5 senaryoyu elle canlandırıp her SMTP dönüş kodunu satır satır okumayı, sonra da smtpd_relay_restrictions ile kalıcı kapatmayı gösteren pratik bir laboratuvar.
EvilMail Team26 Temmuz 202611 dk okuma
Açık relay neden hâlâ sunucunuzu bir gecede kara listeye düşürür
Açık relay tanımı otuz yıldır değişmedi: kimlik doğrulaması olmadan, göndericisi de alıcısı da sizin domainlerinize ait olmayan postayı kabul edip ileten bir SMTP sunucusu. Değişen tek şey, bunun artık "90'ların sorunu" sanılması. Oysa açık relay bugün de düzenli olarak geri geliyor — çünkü sebebi kod değil, yapılandırma: Postfix 2.10 öncesinden kopyalanmış bir main.cf, teste açılıp kapatılması unutulan bir kural, ya da mynetworkse "geçici olarak" eklenip orada kalan geniş bir /16.
Sonucu abartısız anlatayım. Tek bir açık relay, bulunması için gereken saatler içinde Spamhaus SBL/XBL ve CBL'e düşer. rDNS/PTR kaydınız tertemiz, SPF/DKIM/DMARC oturmuş olsa bile Gmail ve Outlook sizi 550'lerle geri çevirmeye başlar. IP itibarınızı kurtarmak günler sürer ve bazı listelerden çıkmak için manuel başvuru gerekir. Yani mesele "posta gidiyor mu" değil, "IP'niz bir daha güvenilir sayılacak mı".
Bu yazının açısı şu: "relay açık mı, değil mi" diye tek bir teste güvenmek yanıltıcıdır. Doğru soru, "hangi senaryoda ne oluyor". Aşağıda saldırganın gerçekte denediği beş farklı durumu elle canlandırıp her birinin dönüş kodunu okumayı, sonra da Postfix'te bunu kalıcı olarak kapatmayı göstereceğim.
Açık Relay Testi: SMTP Sunucunuzu 5 Senaryoyla Doğrulama | evilmail — EvilMail Blog
Test edeceğimiz 5 senaryo
Online "open relay checker" araçlarının çoğu yanlış pozitif verir, çünkü tek bir denemeyi çalıştırıp geçer. Gerçek durum bir matristir. Neyi test ettiğimizi netleştirelim:
Senaryo 1 — Kimliksiz, dış gönderici → dış alıcı, port 25.[email protected] adresinden [email protected]'a. Bu reddedilmeli. Kabul edilirse sunucunuz açık relaydir.
Senaryo 2 — SASL kimlik doğrulamalı, dış→dış, port 587. Kullanıcı kendi hesabıyla giriş yapıp dışarı gönderiyor. Bu kabul edilmeli ve bu relay değildir; buna "submission" denir. Kullanıcılarınızın posta göndermesinin normal yolu budur.
Senaryo 3 — `mynetworks` içinden bağlantı. Güvenilen iç IP'den gelen posta kabul edilir.
Senaryo 4 — Adres oyunları. percent-hack, bang-path, tırnaklı adres. Bunlar reddedilmeli. Klasik testlerin kaçırdığı bypass vektörleri tam olarak burada.
Senaryo 5 — Yerel alıcı (kendi domaininiz). Kimliksiz bir dış gönderici sizin domaininizdeki bir kutuya yazıyor. Bu kabul edilir — sunucunuzun asıl işi budur.
"Açık relay" yalnızca senaryo 1 ve 4'ün kabul edilmesi demektir. Bu ayrımı yapamayan bir araç, submission'ı (senaryo 2) görüp "relay açık" diye bağırabilir. Aşağıdaki matris bunu tek bakışta özetliyor.
swaks ile 60 saniyede test
Bu iş için birinci sınıf araç swaks (Swiss Army Knife for SMTP). Perl'le yazılmış tek dosyalık bir istemci; her SMTP adımını sizin için sürdürür ama sunucunun ham cevabını olduğu gibi gösterir.
Burada 250 ... queued görmek doğru. Kimlik doğrulanmış kullanıcı dışarı gönderebilir. Bunu açık relay sanan araçlara güvenmeyin.
Bir tuzak: sunucuyu uzaktan test ediyorsanız ve çıktığınız IP sunucunun mynetworksünde ise, senaryo 1 permit_mynetworks yüzünden 250 döner ve yanlışlıkla "açık relay" sanırsınız — ya da tam tersine kendi sunucunuzdan test edip sahte bir "güvenli" sonucu alırsınız. Testi mutlaka mynetworksdışındaki bir hattan (ev bağlantısı, ayrı bir VPS) çalıştırın.
Telnet/openssl ile ham SMTP doğrulaması
Bazen swaks'in soyutladığı ara adımları görmek gerekir: reddin RCPT aşamasında mı yoksa DATA aşamasında mı geldiğini bilmek gibi. Bunun için diyaloğu elle sürün.
Dikkat: MAIL FROM aşaması 250 döner — bu normaldir, red genelde RCPT TO'da gelir. Yani "MAIL FROM kabul edildi" diye paniğe gerek yok; kararı RCPT TO satırında okuyun.
STARTTLS zorunlu tutan sunucularda düz telnet yetmez; TLS'i sarmak için:
Bağlantı kurulduktan sonra aynı HELO / MAIL FROM / RCPT TO diyaloğunu yazarsınız. -crlf bayrağı satır sonlarını doğru gönderir; onsuz bazı sunucular komutlarınızı yok sayar.
Adres oyunları: percent-hack, bang-path ve gömülü relay
Klasik açık relay testinin en sık kaçırdığı yer burası. Sunucu senaryo 1'i düzgün reddediyor olabilir ama alıcı adresini yeniden yazan eski kurallar açıksa, saldırgan adresi öyle biçimlendirir ki sunucu onu "kendi domaini" sanıp sonra dışarı yönlendirir.
Mantık şu: adresin yerel kısmı mail.example.com olduğu için ilk bakışta yerel görünür, ama allow_percent_hack veya swap_bangpath açıksa Postfix bunu [email protected]'a çevirir ve postayı Gmail'e yollar. Yani "yerel gibi görünen ama dışarı çıkan" bir relay. swaks'te de deneyebilirsiniz:
Modern Postfix'te bu davranışlar zaten kapalı gelir, ama devraldığınız ya da yıllardır elden geçmemiş bir sunucuda açık bulabilirsiniz. Kapatması iki satır — birazdan main.cf bölümünde.
Dönüş kodlarını okumak ve maillog'da doğrulamak
İstemci çıktısı hikâyenin yarısı. Asıl güven, sunucunun kendi logunda testinizin karşılığını görmekten gelir. Önce kod sözlüğü:
`450 4.7.1` — geçici erteleme; defer_unauth_destination kullanıyorsanız bu da güvenlidir (kalıcı ret yerine "sonra dene" der, spam botlarını yavaşlatır).
`550 5.1.1 User unknown` — alıcı yok. Relay reddi değil, ayrı durum.
`530 5.7.0 Authentication required` — port 587'de kimliksiz denendiğinde doğru cevap.
Şimdi testi sunucu tarafında doğrulayın. Ayrı bir terminalde logu canlı izleyin:
Her test komutunun log karşılığını gözünüzle eşleştirin. reject satırını gördüyseniz, sunucu gerçekten reddediyor demektir — istemci çıktısına değil, buna güvenin.
Postfix yapılandırmasını sağlamlaştırma
Şimdi kalıcı çözüm. İşte main.cfin güvenli çekirdeği:
ini
# Sadece localhost + gerçekten güvenilen iç ağ. Geniş tutmayın.
mynetworks = 127.0.0.0/8 [::1]/128
# Postfix 2.10+ ile relay kararı ayrı ve net:
smtpd_relay_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination
# Sizin domaininiz adına başkasının postasını taşımayın:
relay_domains =
# Adres yeniden yazma oyunlarını kapat:
allow_percent_hack = no
swap_bangpath = no
Neden smtpd_relay_restrictions ayrı bir parametre? Postfix 2.10 (2013) bunu özellikle kazara açık relayı önlemek için ekledi. Öncesinde relay kararı smtpd_recipient_restrictions içindeki reject_unauth_destinationa bağlıydı; biri o kuralı listeden düşürünce sunucu sessizce açık relaya dönüşürdü. 2.10 sonrası relay kararı kendi parametresinde durur ve varsayılanı güvenlidir. 2.10 öncesinden main.cf kopyalayan herkes hâlâ risk altında — ilk yapacağınız iş bu bloğu eklemek.
Postfix'in şipşak gelen varsayılanı bu parametrede reject_unauth_destination yerine defer_unauth_destination (450, geçici ret) kullanır. İkisi de güvenlidir; fark yalnızca redde verilen kodda. Yukarıda kalıcı ve okunması net bir 554 için rejecti seçtim — istemci çıktısında ve logda tereddütsüz "reddedildi" görürsünüz.
mynetworks en sık yapılan hatanın kaynağı. mynetworks = 0.0.0.0/0 yazmak anında açık relaydir; gereğinden geniş bir /16 de öyle. Ayrıca varsayılan mynetworks_style = subnet, bazı bulut sağlayıcılarında sizinle aynı subnet'teki komşu kiracıları da güvenilen ağa dahil edebilir. Bulutta çalışıyorsanız otomatik stile güvenmeyin, CIDR'leri elle yazın.
Submission (587) tarafında port 25'ten farklı olarak SASL'ı zorunlu tutun. master.cfte:
ini
submission inet n - y - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_relay_restrictions=permit_sasl_authenticated,reject
Değişiklikten sonra canlı ayarı doğrulayıp yeniden yükleyin:
Kendi testinize ikinci bir göz ekleyin. MXToolbox'ın "SMTP Open Relay" diagnostic'i (mxtoolbox.com/diagnostic.aspx) sunucunuza dışarıdan bir dizi relay denemesi yapar ve sonucu raporlar; sizin mynetworksünüzde olmadığı için senaryo 1'i dürüstçe test eder. RBL durumunuzu da Spamhaus'tan (check.spamhaus.org) SBL/XBL/CBL için kontrol edin — zaten listeye düşmüşseniz açık relay bulmanız an meselesidir.
Kapatmadan önce satır satır geçin:
mynetworks daraltıldı mı — sadece 127.0.0.0/8, [::1]/128 ve gerçekten güvenilen iç CIDR'ler? 0.0.0.0/0 veya geniş /16 yok, değil mi?
smtpd_relay_restrictions tanımlı ve sırası doğru mu: permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination?
relay_domains boş mu (başkasının postasını taşımıyorsunuz)?
5 senaryodan reddedilmesi gerekenler (1, 4 ve tüm adres varyantları) mynetworks dışı bir hattan REJECT dönüyor mu?
allow_percent_hack = no ve swap_bangpath = no mu?
tail -f ile maillog'da her reddin NOQUEUE: reject karşılığını gözünüzle gördünüz mü?
Port 25'te AUTH kapalı, port 587'de STARTTLS + SASL zorunlu mu?
Test istemcinizin IP'si sunucunun mynetworksünde değil miydi (yoksa "güvenli" sonucu sahtedir)?
Bu sekiz maddeyi geçen bir sunucu, senaryo 1 ve 4'e 554 döner, kullanıcılarınızın 587 üzerinden postası akmaya devam eder ve IP itibarınız sizin kontrolünüzde kalır. evilmail altyapısında her yeni MX'i devreye almadan önce bu checklist'in tamamını mynetworks dışından çalıştırıyoruz — çünkü kara listeden çıkmak, oraya hiç düşmemekten her zaman daha pahalıdır.
