Open Relay Testi ve Kapatma

Bir sabah sunucunuzun IP'sinin kara listeye düştüğünü, giden kuyruğunda tanımadığınız on binlerce mesaj biriktiğini ve müşterilerinizin maillerinin hiçbir yere ulaşmadığını fark ederseniz, ilk bakacağınız yerlerden biri open relay yani açık röle durumudur. Açık röle, SMTP sunucunuzun kimlik doğrulaması yapmadan, kendisine ait olmayan alan adlarına posta iletmeyi kabul etmesi demektir. Spam gönderenler internet üzerinde sürekli bu tür sunucuları tarar ve bulduklarında dakikalar içinde bant genişliğinizi ve itibarınızı tüketirler.

Bu yazıda önce açık rölenin ne olduğunu ve neden hâlâ önemli olduğunu, sonra kendi sunucunuzu güvenilir biçimde nasıl test edeceğinizi anlatacağım. Ardından Postfix'te relay kararını veren parametreleri satır satır açacağım, güvenli bir yapılandırma vereceğim, kimlik doğrulamalı gönderim için 587 portunu doğru kuracağız ve kara listeye düştüyseniz nasıl çıkacağınızı adım adım göreceğiz. Son bölümde, bugün spam sızıntılarının çoğunun aslında açık röleden değil başka bir yerden geldiğini de göstereceğim.

Open Relay Tam Olarak Nedir#

Bir SMTP sunucusunun iki meşru işi vardır: kendi alan adlarına gelen postayı kabul etmek ve kendi kullanıcılarının gönderdiği postayı dışarı iletmek. Sorun, bu ikisinin kesişiminde başlar. Sunucunuza dışarıdan bağlanan bir istemci, alıcı olarak sizin alan adınıza ait olmayan bir adres verirse — örneğin [email protected] — bu bir "röle" (relay) isteğidir. Doğru davranış, isteği yalnızca gönderen kimlik doğrulaması yapmışsa ya da güvenilir bir iç ağdan geliyorsa kabul etmek, aksi hâlde reddetmektir.

Açık röle, bu kontrolün hiç yapılmaması ya da yanlış yapılmasıdır. Sonuç sadece "birileri sizin üzerinizden spam atar" değildir; zinciri şöyle işler: IP'niz Spamhaus, Barracuda ve benzeri kara listelere düşer, kara liste kaydı yayıldıkça meşru maillerinizi de kimse kabul etmez, hosting sağlayıcınız kötüye kullanım bildirimleri (abuse report) almaya başlar ve sunucunuz askıya alınabilir. Bir alan adının itibarı yıllarda kurulur, açık röle onu bir gecede sıfırlar. Gönderici itibarının teslimatı nasıl belirlediğini görmek için Gmail'e mail gitmiyor yazısındaki teslimat zincirine bakmak faydalı olur.

Sunucunuzu Test Etme: Telnet ile Elle Deneme#

En güvenilir test, sunucuya dışarıdan bağlanıp bir röle isteğinde bulunmaktır. Bunu kendi sunucunuzun dışındaki bir makineden yapmalısınız; sunucunun kendi üzerinden bağlanırsanız mynetworks sizi zaten güvenilir sayar ve test yanıltıcı çıkar.

# Sunucu DISINDAKI bir makineden
telnet mail.firmaniz.com 25

Bağlantı açıldıktan sonra şu diyaloğu elle yazın. Kritik satır, alıcının sizin alan adınıza ait olmayan bir adres olmasıdır:

EHLO test.ornek.com
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>

RCPT TO satırına gelen yanıt her şeyi söyler:

Test bitince QUIT yazıp çıkın. Elle yazmak yerine tek komutla denemek isterseniz swaks çok pratiktir:

# Rolenin reddedildigini dogrulayan tek satirlik test
swaks --server mail.firmaniz.com --port 25 \
      --from [email protected] --to [email protected]

# Kimlik dogrulamali gonderimin CALISTIGINI dogrula (587)
swaks --server mail.firmaniz.com --port 587 --tls \
      --auth-user [email protected] --auth-password 'SIFRE' \
      --from [email protected] --to [email protected]

İki testi birlikte yapmak önemlidir: birincisi kapının kapalı olduğunu, ikincisi meşru kullanıcının hâlâ girebildiğini kanıtlar. Yalnızca birincisini yapıp "tamam" derseniz, farkında olmadan kendi kullanıcılarınızın gönderimini de kapatmış olabilirsiniz. Port ve TLS uyumsuzluklarını hızlıca teşhis etmek için SMTP test aracı hangi portta hangi şifreleme modunun beklendiğini ve komutları hazır olarak verir.

Postfix'te Relay Kararını Kim Verir#

Postfix'te açık röleye yol açan ayarlar birkaç tanedir ve çoğu zaman sorun bunlardan sadece birinin yanlış yazılmasından çıkar. Mevcut durumu görmek için varsayılandan farklı ayarları listeleyin:

# Varsayilandan farkli tum ayarlar
postconf -n

# Relay ile dogrudan ilgili olanlari sec
postconf -n | grep -E 'mynetworks|relay_domains|relay_restrictions|recipient_restrictions|mydestination|inet_interfaces'

İlgili parametreler ve doğru değerleri şöyle:

En tehlikeli iki hata şunlardır. Birincisi mynetworks = 0.0.0.0/0 yazmaktır; bu satır kelimenin tam anlamıyla "tüm interneti güvenilir say" demektir ve sunucuyu anında açık röleye çevirir. İkincisi mynetworks_style = class bırakmaktır: bu değer, sunucunuzun IP'sinin ait olduğu tüm A/B/C sınıfı bloğunu güvenilir sayar; paylaşımlı bir veri merkezinde bu, binlerce yabancı sunucuya röle izni vermek anlamına gelir. Varsayılanı host yapın.

Güvenli Yapılandırmayı Uygulama#

Aşağıdaki blok, kendi kullanıcılarınızın gönderim yapabildiği ama dışarıdan kimsenin röle yapamadığı bir yapılandırmadır. /etc/postfix/main.cf dosyasına uygulayın:

# /etc/postfix/main.cf

# Yalnizca kendi makinesi guvenilir. Ofis IP'nizi buraya EKLEMEYIN;
# gezici kullanicilar icin dogru cozum 587 + SASL kimlik dogrulamasidir.
mynetworks = 127.0.0.0/8 [::1]/128
mynetworks_style = host

# Yerel teslimat yapilacak alan adlari
myhostname = mail.firmaniz.com
mydestination = $myhostname, localhost.$mydomain, localhost

# Bu sunucu baskasi adina role YAPMAZ
relay_domains =

# Role karari: once guvenilir ag, sonra kimlik dogrulamis kullanici,
# geri kalan her sey reddedilir.
smtpd_relay_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    defer_unauth_destination

smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    reject_unknown_recipient_domain,
    reject_non_fqdn_recipient

# SASL kimlik dogrulamasi Dovecot uzerinden
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous

Değişikliği yazdıktan sonra söz dizimini kontrol edip yeniden yükleyin ve testi tekrarlayın:

sudo postfix check
sudo systemctl reload postfix
sudo tail -f /var/log/mail.log

smtpd_relay_restrictions parametresi Postfix'in modern sürümlerinde ayrı bir aşama olarak vardır ve varsayılanı zaten güvenlidir. Bu yüzden bugün gördüğüm açık rölelerin neredeyse tamamı varsayılanın bozulmasından kaynaklanıyor: birisi bir sorunu çözmek için permit ekliyor, reject_unauth_destination satırını siliyor ya da listenin sonundaki reddi kaldırıyor. Kural listelerinde sıra önemlidir ve liste bir reddediciyle bitmelidir.

Kimlik Doğrulamalı Gönderim: 587 Portunu Doğru Kurmak#

Açık röleyi kapattığınızda dışarıdaki kullanıcılarınız 25 portundan gönderim yapamaz — bu doğru davranıştır. Onların doğru kapısı 587 (submission) portudur ve orada TLS ile birlikte kimlik doğrulaması zorunlu tutulur. /etc/postfix/master.cf içindeki submission bloğu şöyle olmalı:

# /etc/postfix/master.cf
submission inet n       -       y       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_tls_auth_only=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING

Buradaki smtpd_client_restrictions=permit_sasl_authenticated,reject satırı, 587 portuna bağlanan ama kimlik doğrulamayan herkesi kapıda çevirir. smtpd_tls_security_level=encrypt ise TLS'i zorunlu kılar, yani şifre asla düz metin olarak ağa çıkmaz. Kullanıcılarınıza vereceğiniz ayar bilgisi de buna göre olmalı: sunucu mail.firmaniz.com, port 587, şifreleme STARTTLS, kimlik doğrulama açık. İstemci tarafındaki adım adım kurulumu Outlook e-posta istemci kurulumu yazısında bulabilirsiniz.

Portların hangi amaçla kullanıldığını netleştirelim, çünkü bu karışıklık çok sık yaşanır:

Kara Listeye Düştüyseniz Ne Yapmalı#

Sızıntıyı kapattınız diyelim; IP'nizin kara listelerden çıkması ayrı bir iştir ve sırası önemlidir. Önce kuyruğu temizleyin, aksi hâlde kapıyı kapatsanız bile birikmiş spam çıkmaya devam eder:

# Kuyrukta kac mesaj var
postqueue -p | tail -1
mailq | grep -c '^[A-F0-9]'

# Sadece bir gonderene ait olanlari incele
postqueue -p | grep -B1 '[email protected]'

# TUM kuyrugu sil (dikkat: mesru mailler de gider, once inceleyin)
sudo postsuper -d ALL

Sonra sızıntının kaynağını kanıtlayın. Loglarda hangi kimlikle gönderildiğine bakın:

# En cok gonderim yapan SASL kullanicilari
grep 'sasl_username=' /var/log/mail.log | awk -F'sasl_username=' '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -rn | head

# Web sunucusundan cikan mailler (PHP mail fonksiyonu)
grep 'uid=33' /var/log/mail.log | head

Bu ikinci komut çok önemli bir noktaya işaret ediyor: bugün karşılaştığım spam sızıntılarının büyük çoğunluğu açık röleden değil, ele geçirilmiş bir posta hesabının şifresinden ya da ele geçirilmiş bir web uygulamasının PHP tarafından mail göndermesinden kaynaklanıyor. Yani sunucunuz open relay testinden temiz geçebilir ve yine de spam kaynağı olabilir. Bu yüzden röleyi kapattıktan sonra tüm posta hesaplarının şifresini yenileyin (e-posta şifresi değiştirme adımlarını izleyin) ve gönderim hızına bir tavan koyun; nasıl yapılacağını Postfix gönderim hız limiti yazısında anlattım.

Kuyruk temiz, kaynak kapalı ve şifreler yenilendiyse artık delist başvurusu yapabilirsiniz. Her kara listenin kendi çıkış formu vardır; başvuruda "sorunu nasıl çözdüğünüzü" kısa ve somut yazın. Aynı IP'den ikinci kez kara listeye düşerseniz çıkış süresi ciddi biçimde uzar, bu yüzden aceleyle başvurmak yerine önce temizlediğinizden emin olun. Sunucunuzun genel güvenlik ayarlarını topluca gözden geçirmek için mail sunucusu sertleştirme kontrol listesi yazısındaki maddeleri sırayla uygulamanızı öneririm.

Sık Yapılan Hatalar#

Bu konuda yıllardır tekrar eden birkaç hata var ve hepsi iyi niyetle yapılıyor. Birincisi, bir müşteri "mailim gitmiyor" dediğinde sorunu hızlıca çözmek için smtpd_relay_restrictions listesine bir permit eklemek ya da satırı tamamen yorum satırına almaktır. Bu, tek bir kullanıcının sorununu çözerken kapıyı herkese açar. Doğru refleks, o kullanıcının neden kimlik doğrulayamadığını bulmaktır: genellikle istemcide "sunucum kimlik doğrulaması gerektiriyor" kutusu işaretsizdir ya da yanlış port seçilmiştir.

İkinci hata, güvenilir IP listesini zamanla şişirmektir. Bir ofis IP'si, bir izleme sunucusu, bir eski web sitesi derken mynetworks satırı yirmi bloğa çıkar ve kimse hangisinin neden orada olduğunu hatırlamaz. Bu listeyi altı ayda bir gözden geçirin; kaynağı belirsiz her kayıt bir risktir. Gerçekten röle gereken bir uygulama varsa ona IP güveni yerine kendi SMTP kullanıcı hesabını verin — böylece kimin gönderdiğini loglardan görebilirsiniz.

Üçüncü hata, testi yalnızca tek yönde yapmaktır. Röleyi kapattıktan sonra "reddediyor, tamam" deyip geçerseniz meşru kullanıcılarınızın da gönderemediğini ilk müşteri şikâyetinde öğrenirsiniz. Her değişiklikten sonra iki testi birlikte çalıştırın: dışarıdan gelen röle denemesi reddedilmeli, 587 üzerinden kimlik doğrulamalı gönderim başarılı olmalı. Bu ikisini tek bir betiğe koyup değişiklik sonrası otomatik çalıştırmak en sağlam alışkanlıktır.

Dördüncü ve en sinsi hata, inet_interfaces = all bırakıp güvenlik duvarında 25 portunu her yere açık tutmaktır. Sunucunuz röleye kapalı olsa bile açık 25 portu sürekli sözlük saldırısı ve tarama trafiği çeker; loglarınız şişer, gerçek sorunları görmek zorlaşır ve CPU boşuna harcanır. Gerçekten dışarıdan posta almanız gerekmiyorsa 25 portunu güvenlik duvarında sınırlayın, yalnız iç servisler için dinleyin. Aynı mantıkla, kullanılmayan 465 ve 110 gibi portları da kapatın: açık bırakılan her port bakımı gereken bir yüzeydir.

Sıkça Sorulan Sorular#

Open relay testini nasıl güvenle yaparım#

Testi mutlaka sunucunuzun dışındaki bir makineden yapın; sunucunun kendi üzerinden bağlanırsanız mynetworks sizi güvenilir sayar ve sonuç yanıltıcı çıkar. Bir bulut makinesinden ya da evinizdeki bilgisayardan telnet mail.firmaniz.com 25 ile bağlanıp kendi alan adınıza ait olmayan bir alıcı adresi deneyin. RCPT TO satırında Relay access denied yanıtı alıyorsanız sunucunuz güvenlidir; 250 Ok alıyorsanız röle açıktır ve derhal kapatmanız gerekir.

Ofis IP adresimi mynetworks içine eklemem doğru mu#

Genellikle hayır. mynetworks içine eklenen her IP, kimlik doğrulamadan röle yapabilir hâle gelir. Ofis internetiniz dinamik IP kullanıyorsa ve IP başkasına geçerse o kişi sizin sunucunuz üzerinden mail gönderebilir. Doğru çözüm, kullanıcıları 587 portu üzerinden kullanıcı adı ve şifreyle göndermeye yönlendirmektir; böylece nereden bağlandıkları önemli olmaz ve her gönderim bir kimliğe bağlanır.

Sunucum kara listeye düştü, çıkması ne kadar sürer#

Kara listeye ve sorunu ne kadar hızlı kapattığınıza bağlıdır. Bazı listeler siz başvurmadan, gönderim durduktan birkaç gün sonra otomatik olarak kaydı düşürür; bazıları elle başvuru ister ve birkaç saat ile birkaç gün arasında değerlendirir. Asıl sorun teknik kayıt değil itibar puanınızdır: kayıt silinse bile büyük sağlayıcılar sizi bir süre daha spam klasörüne atmaya devam edebilir, bu yüzden gönderim hacmini kademeli olarak artırın.

Open relay kapalıysa spam gönderimi tamamen biter mi#

Hayır ve bu en yaygın yanılgı. Açık röle sızıntı yollarından yalnızca biridir. Bugün çok daha sık görülen iki yol var: ele geçirilmiş bir posta hesabının şifresiyle 587 üzerinden meşru görünen gönderim yapılması, ve sunucudaki güvenlik açığı bulunan bir web uygulamasının doğrudan PHP ile mail atması. Bu yüzden röleyi kapattıktan sonra hesap şifrelerini yenilemek ve gönderim hızına tavan koymak zorunludur.

cPanel sunucusunda relay ayarını nereden kontrol ederim#

cPanel/WHM sunucuları Postfix yerine Exim kullanır ve varsayılan yapılandırması röleye kapalı gelir. Kontrol için WHM içindeki Exim Yapılandırma Yöneticisi bölümüne bakın; ayrıca "Trusted SMTP IP" gibi güvenilir IP listelerine gereksiz kayıt eklenmediğinden emin olun. WHM'deki SMTP kısıtlaması özelliği, sunucudaki kullanıcıların doğrudan dışarıya 25 portundan bağlanmasını engelleyerek ele geçirilmiş betiklerin spam atmasını da zorlaştırır.

Röleyi kapattım ama kullanıcılarım artık mail gönderemiyor#

Bu, kullanıcıların hâlâ 25 portundan ve kimlik doğrulamasız gönderim yapmaya çalıştığı anlamına gelir. İstemci ayarlarını 587 portuna, STARTTLS şifrelemesine ve "sunucum kimlik doğrulaması gerektiriyor" seçeneği işaretli olacak şekilde güncelleyin. Sunucu tarafında da master.cf içindeki submission bloğunun etkin olduğunu ve smtpd_sasl_auth_enable = yes satırının bulunduğunu doğrulayın; SASL çalışmıyorsa kullanıcılar doğru portta bile giriş yapamaz.

Röle testinde 550 yerine 450 dönüyorsa sorun var mı#

Hayır, ikisi de reddetme anlamına gelir; fark kalıcılıktadır. 5xx kalıcı ret, 4xx geçici rettir ve gönderen tarafın sonra tekrar denemesi beklenir. Postfix'in defer_unauth_destination ayarı bilinçli olarak geçici ret döndürür; bu, yapılandırma hatası yüzünden meşru bir mailin kalıcı olarak kaybolmasını önler. Güvenlik açısından ikisi arasında fark yoktur, mesaj her iki durumda da rölelenmez.

Kapanış#

Açık röle, kapatılması dakikalar süren ama açık kaldığında haftalarca bedel ödeten bir yapılandırma hatasıdır. Aklınızda kalması gereken dört alışkanlık şunlar: mynetworks değerine asla geniş bir blok yazmayın ve mynetworks_style ayarını host bırakın, kural listelerinizi mutlaka bir reddediciyle bitirin, kullanıcı gönderimini 25 yerine kimlik doğrulamalı 587 portuna taşıyın, ve her değişiklikten sonra testi sunucunun dışından tekrarlayın. Röleyi kapattıktan sonra da işiniz bitmez: hesap şifrelerini yenileyin ve gönderim hızına tavan koyun.

Bu kontrolleri kendi sunucunuzda tek tek yapmak yerine hazır ve sertleştirilmiş bir gönderim altyapısı istiyorsanız, SMTP sunucu paketimiz Postfix, Dovecot ve spam filtresi kurulu, röleye kapalı ve rDNS kaydı tanımlı olarak teslim edilir. Kendi sunucunuzu yönetiyor ama bu ayarları bize bırakmak isterseniz sunucu yönetimi hizmetimiz güvenlik sertleştirmesini üstlenir; kurumsal posta kutularınızı sıfır yönetim yüküyle çalıştırmak istiyorsanız e-posta çözümlerimiz doğru başlangıç noktasıdır.