587 ve 465'i Kilitlemek: Submission Portunda Zorunlu Kimlik Doğrulama ve TLS ile Yetkisiz Gönderimi Durdurmak
587'yi açıp STARTTLS'i "destekliyorum" demek yetmez. AUTH'u TLS'ten önce sunan, kimliği zarftan ayrık bırakan bir submission portu ilk gecede IP'nizi Spamhaus'a düşürür. Postfix master.cf üzerinde bu kapıları tek tek kapatan bir sertleştirme rehberi.
EvilMail Team27 Temmuz 202613 dk okuma
Sahne şu: 587 açık, smtpd_sasl_auth_enable=yes, STARTTLS "destekleniyor". Kurulum çalışıyor gibi görünüyor, test maili gidiyor, herkes evine gidiyor. Gece 02:00'de birisi çalınmış bir parolayla — ya da hiç parola olmadan, çünkü relay kısıtı gevşek — porta bağlanıp saatte 40.000 mesaj bastırıyor. Sabah IP'niz Spamhaus SBL ve CBL'de, PTR kaydınız temiz olsa bile Gmail 421 ile kapıyı yüzünüze kapatıyor. Listelerden çıkmak günler, itibarın toparlanması haftalar sürüyor.
Bu felaketin kaynağı çoğu zaman karmaşık bir zafiyet değil. Bir portun "TLS'i destekliyor" olmasıyla "TLS'i zorunlu kılıyor" olması arasındaki farktır. Submission portunda şifreleme ve kimlik doğrulama opsiyonel değildir; ikisi de zorunludur ve kimliği doğrulanmış bir kullanıcı bile kendi adresinden başkası gibi gönderemez. Aşağıda saldırganın gerçekten hangi kapıdan girdiğini gösterip o kapıları Postfix master.cf üzerinde tek tek kapatıyoruz.
587, 465 ve 25 farklı işler için var
Üç portu aynı kefeye koymak, sorunun yarısıdır. Rolleri net ayıralım:
Port 25 — MTA↔MTA relay (RFC 5321). Komşu posta sunucuları buraya bağlanıp _size ait_ domainlere teslimat yapar. Kimlik yoktur, olmaz da — dünyanın herhangi bir MTA'sı size mesaj getirebilmelidir. Bu yüzden 25'te
asla
AUTH
sunulmaz. 25'te SASL açık bırakmak, klasik open relay reçetesidir.
Port 587 — submission / MSA (RFC 6409). Sizin kullanıcılarınızın istemcilerinin (Thunderbird, telefon, uygulama) bağlandığı port. STARTTLS ile şifrelenir ve zorunlu kimlik doğrulama ister. Burada teslimat değil, gönderim yapılır.
Port 465 — submissions / implicit TLS (RFC 8314). Bağlantının ilk baytından itibaren TLS içindedir; STARTTLS pazarlığı yoktur. "Obsolete" değildir — RFC 8314 tam tersine cleartext submission'ı deprecate etmiş, 465'i modern tercih olarak öne çıkarmıştır. Yeni kurulumda 465'i birincil, 587'yi uyumluluk için tutun.
MSA (submission) ile MTA (relay) ayrı sorumluluklardır. Birini diğerinin ayarlarıyla yönetmeye kalkarsanız ya 25'i fazla sıkıp inbound teslimatı kırarsınız ya da 587'yi fazla gevşetip spam topuna dönüşürsünüz.
Submission servisini Postfix'te kilitlemek
Sertleştirmeyi main.cf içindeki global ayarlarla yapmayın. Port 25 gevşek kalmalı (smtpd_tls_security_level=may, çünkü şifreleme yapamayan eski MTA'lar hâlâ var), submission ise katı olmalı. Ayrımı master.cf üzerinde servis bazlı -o override'larıyla kurarsınız:
Kritik satırlar: smtpd_relay_restrictions=permit_sasl_authenticated,reject bir beyaz liste yaklaşımıdır — kimliği doğrulanmışı geçir, geri kalan _her şeyi_ reddet. reject en sonda olduğu için varsayılan davranış "hayır"dır. SASL için Dovecot soketine bağlanıyoruz (smtpd_sasl_type=dovecot, smtpd_sasl_path=private/auth); evilmail.pro tarafında Dovecot parola şeması PLAIN, vhost'lar 5000:5000 sahipliğinde ve Postfix bu sokete private/auth üzerinden erişir. smtps bloğundaki smtpd_tls_wrappermode=yes, 465'in implicit TLS doğasını verir — STARTTLS pazarlığı yoktur.
AUTH'u yalnızca şifreli kanalda sunmak
smtpd_tls_auth_only=yes bu kurulumun kalbidir. Bu satır olmadan sunucu, istemci daha STARTTLS demeden EHLO yanıtında 250-AUTH LOGIN PLAIN reklamını yapar. İstemci de gördüğü şeye uyar ve parolayı cleartext gönderir. Pasif bir dinleyici — aynı ağdaki bir makine, ele geçirilmiş bir switch, kötü bir Wi-Fi — parolayı ham olarak yakalar. Daha kötüsü STARTTLS komut enjeksiyonu sınıfıdır (CVE-2011-0411 ve türevleri): istemcinin TLS handshake'inden _önce_ tampona yazdığı komutlar, şifreli oturum başladığında sunucu tarafından işlenmeye devam eder. Saldırgan böylece kurbanın kimliğine iliştirilmiş komutlar enjekte edebilir.
tls_auth_only=yes ile EHLO çıktısı iki farklı hâl alır: TLS öncesinde AUTH satırı _görünmez_, sadece STARTTLS sunulur; TLS kurulduktan sonra yeni EHLO'da AUTH belirir. 465'in implicit TLS'i bu tuzağı tümden eler — ilk bayttan itibaren şifreli olduğu için "öncesi" diye bir aşama yoktur.
Çoğu kurulum buraya kadar gelir ve durur; oysa en sık atlanan katman tam da budur. permit_sasl_authenticated sadece "bu kişi geçerli bir kullanıcı mı?" sorusunu yanıtlar. [email protected] olarak giriş yapan biri, MAIL FROM satırına [email protected] yazıp kurum içi phishing atabilir — Postfix umursamaz, çünkü kimlik ile zarf birbirinden ayrıktır. Bu boşluk, ele geçirilen bir hesabın en zararlı silahıdır.
Çözüm smtpd_sender_login_maps ile login↔envelope-from eşlemesidir. Bir hash map hazırlayın:
master.cf'teki -o smtpd_sender_restrictions=reject_sender_login_mismatch,... bu haritayı devreye alır: giriş yapılan SASL kullanıcısı, MAIL FROM adresinin haritadaki sahibiyle eşleşmiyorsa mesaj 553 5.7.1 Sender address rejected: not owned by user ile reddedilir. Çok adresli veritabanı kurulumlarında hash: yerine mysql: map kullanıp doğrudan virtual_users tablonuza bağlayabilirsiniz. Bir kullanıcının birden fazla adresten göndermesi gerekiyorsa, aynı login için map'e birden çok satır (veya sorgu sonucu) eklersiniz.
TLS'i gerçekten sıkılaştırmak
"Zorunlu TLS" sadece encrypt demek değildir; hangi protokol ve cipher'la şifrelediğiniz de önemlidir. TLS 1.0/1.1 ve SSLv3 hâlâ pazarlık edilebiliyorsa, downgrade saldırısı için kapı aralık kalır. main.cf'te tabanı çekin:
Sertifikada fullchain.pem kullanın, yalnız cert.pem değil — ara sertifika zinciri eksikse bazı istemciler doğrulamayı reddeder. Let's Encrypt yenilemesinden sonra Postfix yeni sertifikayı kendiliğinden okumaz; certbot deploy hook'una postfix reload ekleyin. Inbound tarafı bu yazının kapsamı dışı, ama not düşeyim: giden TLS'i sertleştirmenin yanına gelen tarafta MTA-STS politikası ve DANE/TLSA kayıtları ekleyerek "başkası bize gönderirken de şifrele" garantisini tamamlarsınız — bu, HSTS'in SMTP dünyasındaki karşılığıdır.
Doğrulama: kapı gerçekten kapalı mı?
Config yazmak yarı iş. Kapının kapalı olduğunu kanıtlayın:
openssl çıktısında, STARTTLS çağrılmadan önceki EHLO yanıtında hiçbir 250-AUTH satırı bulunmamalı — varsa smtpd_tls_auth_only=yes devreye girmemiştir. Log tarafında son kontrol:
Kullanıcı başına _günlük gönderim kotası_ (ele geçirilen bir hesabın verebileceği hasarı 500 mesajla sınırlamak gibi) Postfix'in kendisinde yoktur; bunun için postfwd ya da bir policy servisi devreye alırsınız. Ele geçirilen hesap senaryosunda bu kota, felaketle sıradan bir olay arasındaki farktır.
Devreye alma kontrol listesi
Port 25'te smtpd_sasl_auth_enablekapalı — relay kimliksiz, AUTH sunulmuyor.
587'de smtpd_tls_auth_only=yes ve smtpd_tls_security_level=encrypt aktif.
465 smtpd_tls_wrappermode=yes ile implicit TLS olarak çalışıyor.
Her iki submission servisinde permit_sasl_authenticated,reject beyaz listesi var.
smtpd_sender_login_maps + reject_sender_login_mismatch ile authenticated spoofing kapalı.
smtpd_tls_mandatory_protocols ve smtpd_tls_protocols ile TLS 1.2 altı devre dışı.
fail2ban postfix-sasl jail çalışıyor; anvil rate limitleri set edildi.
Loglarda hem sasl_username başarıları hem reject satırları görünüyor.
certbot deploy hook'u sertifika yenilemesinden sonra postfix reload çalıştırıyor.
Bu on maddeyi geçmiş bir submission portu, çalınmış tek bir parolayla bile spam topuna dönüşmez; en kötü ihtimalle o hesabı kilitler, IP itibarınızı değil. evilmail.pro altyapısını bu prensiple işletiyoruz: submission portunda TLS ve SASL opsiyonel değil, mimarinin kendisi.
