Mail Sunucusu Güvenlik Sertleştirme Kontrol Listesi

Kendi mail sunucunuzu kurmak bir öğleden sonra işidir; onu güvenli tutmak ise sürekli bir disiplin. Kurulum rehberlerinin sonunda "artık mail gönderip alabilirsiniz" yazar ve orada biter — oysa gerçek iş tam o noktada başlar. Mail sunucusu güvenliği söz konusu olduğunda karşınızda üç ayrı tehdit vardır: sunucunuzu spam rölesi olarak kullanmak isteyenler, kullanıcı şifrelerini kaba kuvvetle deneyenler ve sizin adınıza sahte mail gönderenler. Bu üçü birbirinden bağımsızdır ve her biri ayrı bir savunma katmanı ister.

Bu yazı, Postfix + Dovecot tabanlı bir posta sunucusunu üretime çıkarmadan önce baştan sona geçmeniz gereken bir kontrol listesidir. Ağ katmanından başlayıp TLS zorunluluğu, kimlik doğrulama sertleştirmesi, röle ve hız kontrolü, kimlik doğrulama DNS kayıtları, içerik filtreleme ve izleme sırasıyla ilerleyeceğiz. Her maddede sadece "şunu yap" demeyeceğim; neyi engellediğini ve doğru çalıştığını nasıl kanıtlayacağınızı da göstereceğim. Sonunda hepsini tek tabloda toplayacağız.

Önce Tehdit Modelini Netleştirin#

Sertleştirme, ne olduğunu bilmediğiniz bir şeye karşı ayar yapmak değildir. Bir posta sunucusuna yönelen saldırıları dört başlıkta toplayabilirsiniz ve her birinin karşı önlemi farklıdır:

Bu tabloyu aklınızda tutun, çünkü sık yapılan hata tek bir katmana aşırı yatırım yapıp diğerlerini boş bırakmaktır. Röleyi mükemmel kapatmış ama şifre politikası olmayan bir sunucu, ele geçirilmiş tek bir hesap yüzünden aynı kara listeye düşer.

Ağ Katmanı: Yalnızca Gereken Portlar Açık#

İlk adım, sunucunun internete gösterdiği yüzeyi küçültmektir. Bir posta sunucusunda gerçekten açık olması gereken portlar sınırlıdır ve gerisi kapatılmalıdır.

# Hangi servis hangi portu dinliyor
sudo ss -tlnp | grep -E ':(25|110|143|465|587|993|995)\b'

# UFW ile yalnizca gerekli portlari ac
sudo ufw default deny incoming
sudo ufw allow 22/tcp     # SSH (kendi IP'nize kisitlamak daha iyi)
sudo ufw allow 25/tcp     # MTA-MTA teslimat
sudo ufw allow 587/tcp    # Submission (kullanici gonderimi)
sudo ufw allow 993/tcp    # IMAPS
sudo ufw enable
sudo ufw status numbered

Kapatılması gerekenlere dikkat edin: şifreleme yapmayan 110 (POP3) ve 143 (IMAP) portlarını STARTTLS zorunluluğu olmadan açık bırakmayın; kullanıcı şifreleri düz metin olarak ağa çıkar. 465 portunu yalnızca eski istemcileriniz varsa açın. Ayrıca yönetim panellerini (webmail, phpMyAdmin, izleme araçları) mail sunucusuyla aynı makinede tutuyorsanız, onları da güvenlik duvarında kısıtlayın.

İkinci ağ önlemi kaba kuvvete karşıdır. fail2ban, log dosyalarını izleyip belirli sayıda başarısız girişten sonra IP'yi güvenlik duvarında engeller:

# /etc/fail2ban/jail.local
[DEFAULT]
bantime  = 3600
findtime = 600
maxretry = 5

[sshd]
enabled = true

[postfix-sasl]
enabled  = true
port     = smtp,submission,465
logpath  = /var/log/mail.log

[dovecot]
enabled  = true
port     = pop3,pop3s,imap,imaps,submission,465
logpath  = /var/log/mail.log

sudo systemctl restart fail2ban
sudo fail2ban-client status postfix-sasl
# Status for the jail: postfix-sasl
# |- Currently failed: 3
# `- Currently banned: 17

Engellenen IP sayısının sürekli yüksek olması normaldir; posta portları internette durmadan taranır. Anormal olan, bu sayının aniden yüzlere fırlaması ve aynı hesap adının tekrar tekrar denenmesidir — o zaman o hesabın şifresini derhal değiştirin.

TLS Zorunluluğu ve Sertifika#

Şifresiz kimlik doğrulamaya izin veren bir posta sunucusu, kullanıcı şifrelerini ilk açık Wi-Fi ağında kaybeder. Hem Postfix hem Dovecot tarafında TLS'i zorunlu kılın:

# /etc/postfix/main.cf
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.firmaniz.com/fullchain.pem
smtpd_tls_key_file  = /etc/letsencrypt/live/mail.firmaniz.com/privkey.pem

# Sunucudan sunucuya teslimatta firsatci TLS (zorunlu degil, yoksa mail dusmez)
smtp_tls_security_level = may
# Kullanici gonderiminde ise TLS zorunlu (master.cf submission blogunda)
smtpd_tls_security_level = may

# Eski ve kirik protokolleri kapat
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_mandatory_protocols  = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
tls_preempt_cipherlist = yes
smtpd_tls_loglevel = 1

# /etc/dovecot/conf.d/10-ssl.conf
ssl = required
ssl_cert = </etc/letsencrypt/live/mail.firmaniz.com/fullchain.pem
ssl_key  = </etc/letsencrypt/live/mail.firmaniz.com/privkey.pem
ssl_min_protocol = TLSv1.2
ssl_prefer_server_ciphers = yes

# /etc/dovecot/conf.d/10-auth.conf
# Sifreler asla duz metin olarak kabul edilmesin
disable_plaintext_auth = yes
auth_mechanisms = plain login

Buradaki incelik şudur: sunucudan sunucuya (25 portu) teslimatta TLS'i zorunlu tutmayın. smtp_tls_security_level = encrypt yazarsanız, TLS desteklemeyen bir alıcı sunucuya mailiniz hiç gitmez. Fırsatçı TLS (may) doğru tercihtir. Zorunluluk kullanıcı gönderimi olan submission portunda uygulanır, orada karşı taraf sizin kendi kullanıcınızdır. Sertifikayı Let's Encrypt ile alıyorsanız yenilendikten sonra servislerin yeni sertifikayı okuması gerektiğini unutmayın; certbot yenileme kancasına systemctl reload postfix dovecot ekleyin. Sertifika seçenekleri ve doğrulama yöntemleri için SSL sertifikası sayfasına bakabilirsiniz.

Röle, Kimlik Doğrulama ve Gönderim Sınırları#

Röle kontrolü sertleştirmenin kalbidir ve tek başına ayrı bir konudur; adım adım yapılandırma ve testi open relay testi ve kapatma yazısında ayrıntılı anlattım. Burada kontrol listesi maddesi olarak asgari doğru değerleri hatırlatayım:

# /etc/postfix/main.cf
mynetworks = 127.0.0.0/8 [::1]/128
mynetworks_style = host
relay_domains =

smtpd_relay_restrictions =
    permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination

# Kaba HELO/EHLO filtreleri: bot trafiginin buyuk kismini eler
smtpd_helo_required = yes
smtpd_helo_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname

# Baglanti ve mesaj hizi tavanlari (anvil)
smtpd_client_connection_count_limit = 20
smtpd_client_message_rate_limit = 60

reject_invalid_helo_hostname ve reject_non_fqdn_helo_hostname kuralları, kendini geçerli bir alan adı olarak tanıtamayan istemcileri kapıda çevirir; bu tek başına bot trafiğinin ciddi bir bölümünü keser. Ele geçirilmiş bir hesabın saatte on binlerce mail atmasını engelleyen asıl mekanizma ise gönderim hız limitidir — kullanıcı başına tavan koymanın yollarını Postfix gönderim hız limiti yazısında anlattım ve bu maddeyi atlamamanızı özellikle öneririm.

Şifre politikası da bu başlığın altındadır. Posta hesabı şifreleri genellikle yıllarca değişmez ve kullanıcılar bunları başka sitelerde tekrar kullanır. Yeni hesap açarken rastgele üretilmiş uzun şifreler dağıtın; şifre üretici aracıyla saniyeler içinde üretebilirsiniz. Ele geçirildiğinden şüphelendiğiniz hesapların şifresini gecikmeden yenileyin.

Kimlik Doğrulama Kayıtları: SPF, DKIM, DMARC#

Buraya kadar olan maddeler sunucunuzu kötüye kullanılmaktan korur. SPF, DKIM ve DMARC ise sizin alan adınızın başkası tarafından taklit edilmesini engeller ve aynı zamanda maillerinizin karşı tarafta spam sayılmamasını sağlar. Minimum bir kayıt seti şöyle görünür:

; SPF — bu alan adi adina hangi sunucular gonderebilir
firmaniz.com.            3600 IN TXT "v=spf1 mx a:mail.firmaniz.com -all"

; DKIM — imza dogrulama anahtari (selector: mail)
mail._domainkey.firmaniz.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

; DMARC — SPF/DKIM basarisiz olursa ne yapilsin ve rapor nereye
_dmarc.firmaniz.com.     3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; fo=1"

-all ile biten katı bir SPF kaydı, listede olmayan hiçbir sunucunun sizin adınıza gönderemeyeceğini söyler. DMARC politikasını doğrudan p=reject ile başlatmayın; önce p=none ile raporları toplayıp kimlerin sizin adınıza gönderdiğini görün, sonra kademeli olarak sıkın. Bu üç kaydın nasıl birlikte çalıştığını ve tipik kurulum hatalarını e-posta spoofing önleme yazısında ele aldım.

Bir madde daha: rDNS (PTR) kaydı. Gönderdiğiniz IP'nin ters DNS kaydı, HELO adınızla ve mail alan adınızla tutarlı olmalıdır. Büyük sağlayıcıların çoğu PTR kaydı olmayan IP'lerden gelen postayı doğrudan reddeder.

# PTR kaydini dogrula
dig -x 185.12.34.56 +short
# mail.firmaniz.com.

# HELO adiyla tutarli mi
dig mail.firmaniz.com A +short
# 185.12.34.56

İçerik Filtreleme ve Erken Uyarı#

Gelen tarafta iki katman kurun. Birincisi bağlantı düzeyinde eleme: Postfix'in postscreen bileşeni, mesaj gövdesi hiç alınmadan, bağlantı davranışına ve DNS kara listelerine bakarak botları eler. İkincisi içerik düzeyinde tarama: spam ve zararlı yazılım filtresi. İkinci katmanın Amavis + ClamAV ile nasıl kurulacağını Amavis ve ClamAV ile mail virüs taraması yazısında adım adım anlattım. Gecikmeli teslimat yaratan ama spam'i ciddi biçimde azaltan greylisting yöntemi de düşünmeye değer; yan etkilerini greylisting ve mail gecikmesi yazısı açıklıyor.

Son ve en çok atlanan madde izlemedir. Sertleştirme, bir şeyin ters gittiğini fark edebiliyorsanız işe yarar. Günlük olarak bakmanız gereken üç sayı var:

# 1) Kuyruk uzunlugu — ani artis sizinti isaretidir
postqueue -p | tail -1

# 2) Kimlik dogrulama hatalari — sozluk saldirisi
grep -c 'authentication failed' /var/log/mail.log

# 3) Kullanici basina gonderim sayisi — ele gecirilmis hesabi ele verir
grep -o 'sasl_username=[^ ,]*' /var/log/mail.log \
  | sort | uniq -c | sort -rn | head

pflogsumm gibi bir özet aracını günlük çalıştırıp sonucu kendinize mail atmak, hiçbir izleme sistemi kurmadan atabileceğiniz en ucuz adımdır. Kuyruk uzunluğuna basit bir eşik alarmı koymak da öyle; bir sabah 40.000 mesaj birikmiş kuyruğu üç gün sonra öğrenmekle üç dakika sonra öğrenmek arasında dağlar kadar fark vardır.

Hızlı Kontrol Listesi#

Üretime çıkmadan önce her satırı işaretleyin:

Sık Yapılan Hatalar#

En sık gördüğüm ilk hata, sertleştirmeyi tek seferlik bir iş sanmaktır. Bugün doğru olan yapılandırma, altı ay sonra bir sorunu çözmek için eklenen bir istisna yüzünden delinir. postconf -n çıktısını sürüm kontrolüne alın ve her değişikliği bilinçli yapın; böylece "bu satır neden burada" sorusunun cevabı kayıtlı olur.

İkincisi, güvenlik önlemini kullanıcı deneyimini test etmeden uygulamaktır. TLS'i zorunlu kıldınız ama eski bir muhasebe yazılımı hâlâ şifresiz bağlanıyorsa, bunu ancak ay sonu faturaları gitmeyince fark edersiniz. Her sıkılaştırmadan sonra en az bir gerçek gönderim ve bir gerçek okuma testi yapın.

Üçüncüsü, çok agresif filtreleme ile meşru maili kaybetmektir. Kara liste sorgusu, katı SPF ve greylisting üst üste geldiğinde bazı meşru gönderenler elenir. Filtreleri reddet yerine önce işaretle kipinde çalıştırıp bir hafta gözlemleyin, sonra sıkın. Kaybettiğiniz meşru mailin maliyeti, engellemediğiniz spam'in maliyetinden çok daha yüksektir.

Dördüncüsü, yedeği güvenliğin parçası saymamaktır. Fidye yazılımı ya da yanlış bir postsuper -d ALL komutu, en iyi sertleştirilmiş sunucuda bile veri kaybettirir. Posta verisinin sunucudan bağımsız bir kopyası olmalıdır; yedekleme hizmetimiz bunu otomatikleştirir.

Sıkça Sorulan Sorular#

Mail sunucusu sertleştirmesi ne kadar sürer#

Bu yazıdaki maddelerin tamamını temiz bir kurulumda uygulamak deneyimli bir sistem yöneticisi için yarım gün, ilk kez yapıyorsanız bir gün sürer. Asıl zaman, ayarları yazmakta değil her adımdan sonra test etmekte geçer. Var olan ve üzerinde kullanıcı bulunan bir sunucuyu sertleştiriyorsanız işi bir haftaya yayın: her gün bir katman uygulayıp ertesi gün şikâyet gelip gelmediğine bakın.

fail2ban kurmak yeterli mi#

Hayır, fail2ban yalnızca kaba kuvvet saldırılarını yavaşlatır. Şifresi başka bir sitedeki sızıntıdan öğrenilmiş bir hesaba tek denemede giriş yapılırsa fail2ban hiçbir şey görmez, çünkü başarısız deneme yoktur. Bu yüzden fail2ban'ı gönderim hız limiti, güçlü şifre politikası ve gönderim izleme ile birlikte kullanmak gerekir. Tek başına hiçbir önlem yeterli değildir.

TLS'i sunucudan sunucuya teslimatta de zorunlu yapmalı mıyım#

Genellikle hayır. smtp_tls_security_level = encrypt yazarsanız TLS desteklemeyen alıcı sunuculara mailiniz hiç ulaşmaz ve bunu ancak müşteriniz "mailim gitmemiş" dediğinde öğrenirsiniz. Doğru ayar fırsatçı TLS'tir (may): karşı taraf destekliyorsa şifreli, desteklemiyorsa açık gönderilir. Belirli iş ortaklarıyla zorunlu şifreleme istiyorsanız smtp_tls_policy_maps ile yalnızca o alan adları için zorunluluk tanımlayabilirsiniz.

Sunucumun gerçekten güvenli olduğunu nasıl kanıtlarım#

Kanıt, ayarları okumak değil davranışı test etmektir. Dışarıdan bir makineden röle denemesi yapıp reddedildiğini görün, 587 üzerinden kimlik doğrulamalı gönderimin çalıştığını doğrulayın, düz metin kimlik doğrulamasının reddedildiğini test edin, SPF/DKIM/DMARC kayıtlarını bir dış test adresine mail atarak kontrol edin ve PTR kaydınızın doğru çözüldüğünü sorgulayın. Bu beş testi bir betiğe koyup her değişiklik sonrası çalıştırmak en pratik yöntemdir.

Paylaşımlı hostingde bu ayarları yapabilir miyim#

Hayır, paylaşımlı barındırmada Postfix veya Exim yapılandırmasına erişiminiz olmaz; sunucu genelindeki güvenlik ayarları sağlayıcı tarafından yönetilir. Sizin kontrolünüzde olan kısım DNS kayıtlarınız (SPF, DKIM, DMARC) ve hesap şifrelerinizdir; bunları düzgün yapmak zaten güvenliğin önemli bir bölümünü karşılar. Sunucu düzeyinde kontrol istiyorsanız kendi sanal sunucunuza geçmeniz gerekir.

Mail sunucumu ayrı bir makinede tutmalı mıyım#

Mümkünse evet. Web sitesi ile posta sunucusunu aynı makinede tutmak iki riski birleştirir: web uygulamasındaki bir açık doğrudan posta altyapınıza erişim verir ve web sitesinden çıkan spam sizin posta IP'nizin itibarını yakar. Ayrıca yoğun bir web sitesi CPU'yu tükettiğinde posta teslimatı yavaşlar. Hacim büyüdükçe gönderimi ayrı bir SMTP sunucusuna taşımak hem güvenlik hem teslimat açısından belirgin fayda sağlar.

Hangi logları ne kadar saklamalıyım#

Posta loglarını en az 30 gün, mümkünse 90 gün saklayın. Bir kötüye kullanım bildirimi ya da "bu mail bize ulaşmadı" tartışması genellikle olaydan haftalar sonra gelir ve logu olmayan tarafın söyleyecek sözü olmaz. logrotate yapılandırmasında posta logları için saklama süresini uzatın, ancak diskin dolmaması için sıkıştırmayı açın. Logların bir kopyasını sunucu dışında tutmak, sunucu ele geçirildiğinde delillerin silinmesini de engeller.

Kapanış#

Bir posta sunucusunu güvende tutmanın sırrı egzotik ayarlarda değil, sıralı ve tekrar edilebilir bir kontrol listesinde. Aklınızda dört alışkanlık kalsın: yüzeyi küçültün (yalnız gereken portlar açık olsun), her kimlik doğrulamayı TLS arkasına alın, gönderime kullanıcı başına tavan koyun ve kuyruk uzunluğu ile kimlik doğrulama hatalarını her gün gözünüzle görün. Bu dördü yerindeyse geri kalan maddeler ince ayardır; bu dördü eksikse geri kalanı sizi kurtarmaz.

Bütün bunları kendi sunucunuzda kurmak yerine hazır ve sertleştirilmiş bir yapı istiyorsanız SMTP sunucu paketimiz Postfix, Dovecot, spam filtresi, DKIM anahtarı ve PTR kaydı tanımlanmış olarak teslim edilir. Kurulumu kendiniz yaptıysanız ve bakımını devretmek istiyorsanız sunucu yönetimi hizmetimiz güncelleme ve izleme yükünü üstlenir. Sıfır yönetimle kurumsal posta kutusu arıyorsanız e-posta çözümlerimiz, saldırı trafiğini altyapı düzeyinde emmek içinse DDoS koruma hizmetimiz uygun tamamlayıcılardır.