Apache ve Ubuntu 18.04 Kullanarak Alan Adınız İçin MTA-STS ve TLS Raporlamasını Yapılandırma Rehberi

Apache ve Ubuntu 18.04 Kullanarak Alan Adınız İçin MTA-STS ve TLS Raporlamasını Yapılandırma Rehberi

Giriş

Günümüzün dijital dünyasında e-posta, iş iletişiminin ve kişisel etkileşimin temel taşlarından biridir. Ancak, e-postaların güvenliği, siber suçluların ve kötü niyetli aktörlerin sürekli hedefi olmaya devam etmektedir. E-posta trafiğini hedef alan saldırılar, hassas bilgilerin ele geçirilmesine, kimlik avı saldırılarına ve itibar kaybına yol açabilir. Bu tehditlerle mücadele etmek için DMARC, SPF ve DKIM gibi protokoller uzun süredir kullanılmaktadır. Ancak, bu protokoller bile e-posta sunucuları arasındaki aktarım sırasında iletişimin şifrelenmesini garanti edemez. İşte tam bu noktada MTA-STS (Mail Transfer Agent Strict Transport Security) ve TLS Raporlama devreye girer.

MTA-STS, e-posta sunucuları arasındaki iletişimin her zaman şifreli (TLS üzerinden) ve kimliği doğrulanmış bir şekilde gerçekleşmesini sağlamak amacıyla geliştirilmiş bir güvenlik standardıdır. Geleneksel olarak, STARTTLS komutu e-posta sunucularının şifreli bir bağlantı kurmasını sağlar, ancak bu komut bir saldırgan tarafından engellenebilir (STARTTLS stripping) veya düşürülebilir (downgrade attack), bu da iletişimin şifresiz olarak devam etmesine neden olabilir. MTA-STS, bu tür saldırıları önleyerek e-posta trafiğinin güvenliğini önemli ölçüde artırır. TLS Raporlama ise, MTA-STS politikalarınızın nasıl uygulandığına dair geri bildirim almanızı sağlayarak, olası yapılandırma hatalarını veya saldırı girişimlerini tespit etmenize yardımcı olur.

Bu makalede, bir Ubuntu 18.04 sunucusu üzerinde Apache web sunucusunu kullanarak alan adınız için MTA-STS ve TLS Raporlamasını adım adım nasıl yapılandıracağınızı detaylı bir şekilde açıklayacağız. Bu rehber, sistem yöneticileri ve e-posta güvenliği konusunda bilgi sahibi olmak isteyen herkes için faydalı olacaktır.

MTA-STS Nedir ve Neden Önemlidir?

MTA-STS, e-posta aktarım aracıları (MTA’lar) arasında güvenli ve şifreli iletişimi zorunlu kılan bir internet standardıdır. Temel amacı, e-posta sunucuları arasındaki bağlantıların her zaman TLS (Transport Layer Security) kullanılarak şifrelenmesini ve kimlik doğrulamasının yapılmasını sağlamaktır.

MTA-STS’nin çözdüğü temel sorun, STARTTLS stripping ve pasif downgrade saldırılarıdır. Bir e-posta sunucusu (gönderen MTA), başka bir e-posta sunucusuna (alıcı MTA) bağlanmaya çalıştığında, genellikle önce şifresiz bir bağlantı kurar ve ardından STARTTLS komutunu kullanarak bağlantıyı şifreli hale getirmeye çalışır. Ancak, bir saldırgan bu STARTTLS komutunu araya girerek engelleyebilir veya bağlantıyı şifresiz olarak devam etmeye zorlayabilir. Bu durumda, e-postanın içeriği saldırgan tarafından okunabilir veya değiştirilebilir hale gelir.

MTA-STS, bu senaryoyu önlemek için iki ana bileşen kullanır:
1. DNS TXT Kaydı: Alan adının DNS kayıtlarında _mta-sts alt alan adı için bir TXT kaydı bulunur. Bu kayıt, alıcı MTA’nın MTA-STS politikasına sahip olduğunu ve politikanın nerede bulunacağını belirtir.
2. HTTPS Üzerinden Sunulan Politika Dosyası: Politika dosyası, mta-sts.yourdomain.com gibi belirli bir alt alan adında, HTTPS üzerinden güvenli bir şekilde sunulur. Bu dosya, alan adının e-posta sunucularının (MX kayıtları) hangi TLS güvenlik seviyesini gerektirdiğini ve politikanın ne kadar süreyle geçerli olduğunu belirtir.

Bir gönderen MTA, bir alan adına e-posta göndermeden önce şu adımları izler:
1. Alıcının alan adının _mta-sts TXT kaydını sorgular.
2. TXT kaydı varsa, mta-sts.yourdomain.com adresinden HTTPS üzerinden MTA-STS politika dosyasını indirir. Bu dosyanın HTTPS üzerinden sunulması kritik öneme sahiptir, çünkü bu, politikanın bütünlüğünü ve kimliğini doğrular.
3. Politika dosyasını analiz eder ve belirtilen MX kayıtları için TLS bağlantısının zorunlu olduğunu anlar.
4. E-postayı gönderirken, alıcı MX sunucularıyla TLS bağlantısı kurmaya çalışır. Eğer TLS bağlantısı kurulamıyorsa veya sertifika doğrulanamıyorsa, e-postayı göndermeyi reddeder (politikanın mode değerine bağlı olarak).

Bu mekanizma sayesinde, e-posta trafiği her zaman şifreli ve güvenli bir kanal üzerinden iletilir, bu da ortadaki adam (man-in-the-middle) saldırılarına karşı önemli bir koruma sağlar.

TLS Raporlama Nedir ve Neden Önemlidir?

TLS Raporlama (TLSRPT), MTA-STS ile birlikte çalışan tamamlayıcı bir protokoldür. Amacı, MTA-STS politikalarınızın nasıl uygulandığına dair geri bildirim almanızı sağlamaktır. Başka bir deyişle, e-posta gönderen sunucuların, sizin alan adınıza e-posta gönderirken karşılaştıkları TLS bağlantı sorunlarını (veya başarılarını) size raporlamasını sağlar.

TLS Raporlama, aşağıdaki nedenlerden dolayı kritik öneme sahiptir:
* İzleme ve Hata Ayıklama: MTA-STS politikanızı testing modunda başlattığınızda, raporlar size olası yapılandırma hatalarını veya eksiklikleri gösterir. Örneğin, MX kayıtlarınızda bir hata varsa veya sertifikalarınızda bir sorun varsa, raporlar size bu durumu bildirecektir.
* Saldırı Tespiti: Eğer bir saldırgan STARTTLS stripping veya downgrade saldırısı yapmaya çalışıyorsa, raporlar size başarısız TLS bağlantı girişimlerini gösterebilir. Bu, potansiyel güvenlik ihlallerini erken tespit etmenizi sağlar.
* Politika Doğrulama: enforce moduna geçmeden önce, TLS Raporları sayesinde politikanızın doğru çalıştığından ve meşru e-postaların engellenmediğinden emin olabilirsiniz.
* Uyumluluk Sağlama: Kurumsal uyumluluk gereksinimleri için, e-posta güvenliğinizin sürekli olarak denetlendiğini ve raporlandığını göstermeniz gerekebilir.

TLS Raporlama, alan adınızın DNS kayıtlarında _smtp._tls alt alan adı için bir TXT kaydı ile yapılandırılır. Bu kayıt, raporların hangi e-posta adresine gönderileceğini belirtir. Gönderen MTA’lar, belirli aralıklarla (genellikle günlük) bu adrese JSON formatında raporlar gönderir. Bu raporlar, bağlantı denemeleri, başarılı ve başarısız bağlantı sayıları, TLS sürümleri, sertifika hataları gibi bilgileri içerir. Bu raporları analiz ederek e-posta güvenliğinizin durumunu sürekli olarak izleyebilirsiniz.

Ön Gereksinimler

Bu rehberi takip edebilmek için aşağıdaki ön gereksinimlere sahip olmanız gerekmektedir:
* Ubuntu 18.04 LTS yüklü bir sunucu: Makaledeki komutlar ve yapılandırmalar bu işletim sistemi sürümüne göre optimize edilmiştir.
* Apache web sunucusu kurulu ve çalışır durumda: MTA-STS politika dosyasını HTTPS üzerinden sunmak için Apache’ye ihtiyacımız olacak.
* Alan adınıza ait bir SSL/TLS sertifikası: mta-sts.yourdomain.com alt alan adı için geçerli bir sertifikaya sahip olmanız gerekmektedir. Let’s Encrypt, ücretsiz ve otomatikleştirilmiş sertifikalar sağladığı için şiddetle tavsiye edilir.
* Alan adınızın DNS kayıtlarına erişim yetkisi: MTA-STS ve TLS Raporlama için DNS TXT kayıtları oluşturmanız gerekecektir.
* Temel Linux komut satırı ve Apache bilgisi: Komutları anlama ve temel yapılandırma dosyalarını düzenleme yeteneği.
* Yönetici (sudo) ayrıcalıklarına sahip bir kullanıcı hesabı: Sunucu üzerinde gerekli değişiklikleri yapabilmek için.
* (İsteğe Bağlı ama Önerilen) DMARC, SPF ve DKIM yapılandırması: MTA-STS bu protokollere ek bir güvenlik katmanı sağlar ve mevcut e-posta güvenliği altyapınızla birlikte çalışır.

Adım 1: Apache Web Sunucusunu Hazırlama

MTA-STS politika dosyasının HTTPS üzerinden sunulması gerektiği için, öncelikle Apache web sunucunuzu doğru şekilde yapılandırmanız gerekmektedir.

Apache Kurulumu ve Temel Yapılandırma

Eğer sunucunuzda Apache kurulu değilse, aşağıdaki komutlarla kurabilirsiniz:

sudo apt update
sudo apt upgrade
sudo apt install apache2

Apache kurulduktan sonra, güvenlik duvarınızı (UFW) yapılandırarak HTTP (80) ve HTTPS (443) trafiğine izin vermeniz gerekmektedir:

sudo ufw app list
sudo ufw allow 'Apache Full'
sudo ufw enable # Eğer UFW etkin değilse

Apache servisinin çalıştığını kontrol etmek için:

sudo systemctl status apache2

Tarayıcınızda sunucunuzun IP adresini ziyaret ederek Apache’nin varsayılan hoş geldiniz sayfasını görmeniz gerekir.

SSL/TLS Sertifikası Kurulumu (Let’s Encrypt ile)

MTA-STS politika dosyasını mta-sts.yourdomain.com adresinden HTTPS üzerinden sunacağımız için, bu alt alan adı için geçerli bir SSL/TLS sertifikasına ihtiyacımız var. Let’s Encrypt, Certbot aracı ile bu süreci oldukça basitleştirir.

Öncelikle Certbot’u ve Apache eklentisini kurun:

sudo apt install certbot python-certbot-apache

Ardından, mta-sts.yourdomain.com alt alan adınız için bir sertifika alın. Bu adım için, mta-sts.yourdomain.com adresinin sunucunuzun IP adresine işaret eden bir DNS A kaydına sahip olması gerekmektedir.

sudo certbot --apache -d mta-sts.yourdomain.com

Certbot size e-posta adresi, hizmet şartlarını kabul etme ve sertifika yenileme tercihleri gibi birkaç soru soracaktır. Soruları yanıtladıktan sonra, Certbot otomatik olarak sertifikayı alacak, Apache sanal host yapılandırmanızı güncelleyecek ve HTTPS’yi etkinleştirecektir.

Eğer Certbot, mta-sts.yourdomain.com için ayrı bir sanal host dosyası oluşturmadıysa veya mevcut bir dosyayı güncellemediyse, bunu daha sonra manuel olarak yapmamız gerekecektir. Ancak genellikle otomatik olarak halleder.

Sertifikanın başarıyla alındığını ve Apache’nin yeniden yüklendiğini doğrulayın.

Adım 2: MTA-STS Politikası Dosyasını Oluşturma

MTA-STS politika dosyası, alan adınızın e-posta sunucuları için TLS gereksinimlerini tanımlayan basit bir metin dosyasıdır. Bu dosya, /.well-known/mta-sts/mta-sts.txt yolunda sunulmalıdır.

Dizin Yapısını Hazırlama

Öncelikle, politika dosyasını barındıracak dizin yapısını oluşturmanız gerekmektedir. Varsayılan Apache DocumentRoot‘unuz /var/www/html ise, bu dizini kullanabilirsiniz. Eğer alan adınız için özel bir DocumentRoot‘unuz varsa, o yolu kullanın. Bu örnekte, yourdomain.com için /var/www/yourdomain.com/public_html kullandığımızı varsayalım.

sudo mkdir -p /var/www/yourdomain.com/public_html/.well-known/mta-sts/

Dizin izinlerinin web sunucusu kullanıcısı (genellikle www-data) tarafından erişilebilir olduğundan emin olun:

sudo chown -R www-data:www-data /var/www/yourdomain.com/public_html
sudo chmod -R 755 /var/www/yourdomain.com/public_html

Politika Dosyasını Yazma

Şimdi mta-sts.txt dosyasını oluşturup içeriğini yazalım:

sudo nano /var/www/yourdomain.com/public_html/.well-known/mta-sts/mta-sts.txt

Dosyanın içine aşağıdaki içeriği yapıştırın ve kendi alan adınıza göre düzenleyin:

version: STSv1
mode: testing
mx: mail.yourdomain.com
mx: *.yourdomain.com
max_age: 86400

Bu dosyanın içeriğini açıklayalım:
* version: STSv1: Politika dosyasının sürümünü belirtir. Şu anda sadece STSv1 mevcuttur.
* mode: testing: Politikanın uygulama modunu belirtir.
* testing: Politika ihlalleri raporlanır ancak e-postalar yine de teslim edilir (STARTTLS stripping olsa bile). Bu mod, yapılandırmanızı test etmek için kritik öneme sahiptir.
* enforce: Politika ihlalleri durumunda e-postalar teslim edilmez ve raporlanır. Bu, tam koruma sağlar.
* none: MTA-STS devre dışı bırakılır.
Önemli: Her zaman testing moduyla başlayın ve raporları inceledikten sonra enforce moduna geçin.
mx: mail.yourdomain.com: Alan adınızın MX kayıtlarını listeler. Buradaki değerler, alan adınızın DNS MX kayıtlarındaki değerlerle tam olarak eşleşmelidir. Birden fazla MX kaydınız varsa, her birini ayrı bir mx: satırı olarak ekleyin. Örneğin, mx: mail.yourdomain.com ve mx: mail2.yourdomain.com. Wildcard (.yourdomain.com) kullanımı, tüm alt alan adlarını kapsayan MX kayıtları için faydalı olabilir, ancak genellikle spesifik MX kayıtları tercih edilir. Bu kısım çok önemlidir ve doğru MX kayıtlarını belirtmezseniz e-posta akışınızda kesintiler yaşanabilir.
* max_age: 86400: Politikanın saniye cinsinden geçerlilik süresini belirtir. Bu örnekte 86400 saniye = 24 saat. Genellikle ilk başta kısa bir süre (örneğin 86400) kullanmak ve her şeyin yolunda gittiğinden emin olduktan sonra daha uzun bir süreye (örneğin 604800 saniye = 7 gün veya 2592000 saniye = 30 gün) yükseltmek iyi bir uygulamadır. Bu süre boyunca, gönderen MTA’lar politikayı önbelleğe alır.

Dosyayı kaydedin ve kapatın (Ctrl+O, Enter, Ctrl+X).

Adım 3: Apache Sanal Host Yapılandırması

Certbot genellikle sertifikayı alırken mta-sts.yourdomain.com için bir sanal host yapılandırması oluşturur veya günceller. Ancak, politika dosyasının doğru Content-Type başlığıyla sunulduğundan emin olmak için bu yapılandırmayı kontrol etmemiz ve gerekirse düzenlememiz gerekebilir.

Yeni Bir Sanal Host Dosyası Oluşturma veya Mevcut Olanı Düzenleme

Certbot’un oluşturduğu sanal host dosyası genellikle /etc/apache2/sites-available/mta-sts.yourdomain.com-le-ssl.conf yolunda bulunur. Bu dosyayı düzenleyin:

sudo nano /etc/apache2/sites-available/mta-sts.yourdomain.com-le-ssl.conf

Dosyanın içeriği aşağıdaki gibi olmalıdır (Certbot’un eklediği SSL ile ilgili satırlarla birlikte):

    ServerName mta-sts.yourdomain.com
    DocumentRoot /var/www/yourdomain.com/public_html

    
        Require all granted
        # MTA-STS politika dosyasının Content-Type'ını metin olarak ayarlayın
        
            Header set Content-Type "text/plain"
        
    

    # Certbot tarafından eklenen SSL/TLS yapılandırması
    SSLCertificateFile /etc/letsencrypt/live/mta-sts.yourdomain.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/mta-sts.yourdomain.com/privkey.pem
    Include /etc/letsencrypt/options-ssl-apache.conf
    # Diğer Certbot satırları...

Önemli Not: DocumentRoot yolunun ve ServerName değerinin kendi yapılandırmanıza uygun olduğundan emin olun. bloğu, mta-sts.txt dosyasının doğru Content-Type başlığıyla sunulmasını sağlar. Bu başlık, dosyanın düz metin olarak yorumlanması için kritik öneme sahiptir. Eğer mod_headers modülü etkin değilse, etkinleştirmeniz gerekir:

sudo a2enmod headers

Dosyayı kaydedin ve kapatın.

Sanal Host’u Etkinleştirme ve Apache’yi Yeniden Yükleme

Eğer Certbot zaten etkinleştirmediyse, sanal host dosyasını etkinleştirin:

sudo a2ensite mta-sts.yourdomain.com-le-ssl.conf

Apache yapılandırmanızda herhangi bir hata olup olmadığını kontrol edin:

sudo apache2ctl configtest

Syntax OK çıktısını alırsanız, Apache’yi yeniden yükleyebilirsiniz:

sudo systemctl reload apache2

Politika Dosyasının Erişilebilirliğini Test Etme

Politika dosyasının HTTPS üzerinden doğru bir şekilde sunulup sunulmadığını kontrol etmek için curl kullanabilirsiniz:

curl -v https://mta-sts.yourdomain.com/.well-known/mta-sts/mta-sts.txt

Çıktıda HTTP 200 OK durum kodunu ve Content-Type: text/plain başlığını görmelisiniz. Ayrıca, mta-sts.txt dosyasının içeriği de gösterilmelidir. Eğer bir hata (örneğin 404 Not Found) alıyorsanız, DocumentRoot yolunuzu, dizin izinlerini veya Apache sanal host yapılandırmanızı kontrol edin.

Adım 4: DNS Kayıtlarını Yapılandırma

MTA-STS ve TLS Raporlamanın çalışması için DNS kayıtlarınıza iki adet TXT kaydı eklemeniz gerekmektedir. Bu kayıtları, alan adınızın DNS yönetim panelinden (alan adı sağlayıcınız veya DNS barındırıcınız) eklemeniz gerekecektir.

MTA-STS TXT Kaydı

_mta-sts.yourdomain.com alt alan adı için bir TXT kaydı oluşturmanız gerekmektedir. Bu kayıt, diğer e-posta sunucularına alan adınız için bir MTA-STS politikasının mevcut olduğunu bildirir.

* Host/Ad/İsim: _mta-sts.yourdomain.com (Bazı DNS sağlayıcıları sadece _mta-sts yazmanızı isteyebilir, yourdomain.com otomatik olarak eklenir.)
* Değer/Metin: v=STSv1; id=20231027100000;

id alanı çok önemlidir: Bu, politikanızın bir sürüm kimliğidir. Politika dosyanızda (mta-sts.txt) herhangi bir değişiklik yaptığınızda (örneğin mode‘u testing‘den enforce‘a değiştirdiğinizde veya max_age‘i güncellediğinizde), bu id değerini de güncellemeniz gerekmektedir. Genellikle YYYYMMDDHHMMSS formatında bir tarih ve saat damgası kullanmak iyi bir uygulamadır (örneğin 20231027100000 27 Ekim 2023, saat 10:00:00 anlamına gelir). Gönderen MTA’lar, bu id değerini kontrol ederek politikanızın değişip değişmediğini anlar ve yeni politikayı tekrar indirir.

TLS Raporlama TXT Kaydı

_smtp._tls.yourdomain.com alt alan adı için bir TXT kaydı oluşturmanız gerekmektedir. Bu kayıt, raporların hangi e-posta adresine gönderileceğini belirtir.

* Host/Ad/İsim: _smtp._tls.yourdomain.com (Bazı DNS sağlayıcıları sadece _smtp._tls yazmanızı isteyebilir.)
* Değer/Metin: v=TLSRPTv1; rua=mailto:rapor@yourdomain.com;

rua alanı: Bu, TLS Raporlarının gönderileceği e-posta adresidir. rapor@yourdomain.com yerine kendi rapor e-posta adresinizi yazın. Birden fazla e-posta adresine rapor göndermek isterseniz, virgülle ayırarak ekleyebilirsiniz: rua=mailto:rapor1@yourdomain.com,mailto:rapor2@anotherdomain.com;.

DNS Yayılımını Bekleme

DNS kayıtlarınızdaki değişikliklerin dünya genelindeki DNS sunucularına yayılması biraz zaman alabilir (birkaç dakika ile birkaç saat arasında değişebilir, TTL değerinize bağlı olarak). Kayıtlarınızın doğru bir şekilde yayıldığını kontrol etmek için dig komutunu kullanabilirsiniz:

dig TXT _mta-sts.yourdomain.com +short
dig TXT _smtp._tls.yourdomain.com +short

Bu komutlar, DNS kayıtlarınızın değerlerini göstermelidir.

Adım 5: Politikayı İzleme ve “Enforce” Moduna Geçiş

MTA-STS ve TLS Raporlama yapılandırmasının en kritik aşamalarından biri, politikanızı testing modunda izlemek ve her şeyin yolunda gittiğinden emin olmaktır.

“Testing” Modunda İzleme

Politikanızı testing modunda başlattığınızda, diğer e-posta sunucuları sizin MTA-STS politikanızı uygulayacak ancak herhangi bir ihlal durumunda e-postaları engellemek yerine size rapor gönderecektir. Bu raporlar, TLS Raporlama TXT kaydınızda belirttiğiniz rua adresine gelecektir.

* Raporları İnceleme: Gelen raporlar genellikle JSON formatında ve sıkıştırılmış (gzip) olarak gelir. Bu raporlar, gönderen sunucuların sizin alan adınıza e-posta gönderirken karşılaştıkları TLS bağlantı girişimlerinin özetini içerir. Raporda, başarılı bağlantılar, başarısız bağlantılar, TLS sürümleri, sertifika hataları ve diğer ilgili bilgiler yer alır.
* Analiz Araçları: Gelen JSON raporlarını manuel olarak okumak ve analiz etmek zor olabilir. Bu nedenle, Postmark, Mailhardener, OnDMARC gibi üçüncü taraf hizmetler veya açık kaynaklı araçlar kullanarak bu raporları daha anlaşılır bir formatta görüntüleyebilirsiniz. Bu hizmetler, raporları ayrıştırır ve size kolayca okunabilir grafikler veya özetler sunar.
* Hataları Giderme: Raporlarda herhangi bir hata (örneğin, sertifika doğrulama hataları, MX kayıt uyuşmazlıkları, TLS bağlantı sorunları) görürseniz, ilgili sorunları gidermeniz gerekmektedir. Bu, genellikle Apache yapılandırmanızı, sertifikalarınızı veya DNS MX kayıtlarınızı kontrol etmeyi içerir.

Bu izleme süreci, genellikle birkaç gün veya bir hafta sürebilir. Bu süre zarfında, tüm meşru e-posta akışınızın sorunsuz çalıştığından ve raporlarda önemli bir hata görmediğinizden emin olmanız önemlidir.

“Enforce” Moduna Geçiş

Tüm raporlar temiz olduğunda ve MTA-STS uygulamanızın doğru çalıştığından emin olduğunuzda, politikanızı enforce moduna geçirebilirsiniz. Bu, e-posta güvenliğiniz için tam koruma sağlayacaktır.

1. MTA-STS Politika Dosyasını Güncelleme: mta-sts.txt dosyasındaki mode değerini enforce olarak değiştirin:

sudo nano /var/www/yourdomain.com/public_html/.well-known/mta-sts/mta-sts.txt

İçeriği şu şekilde güncelleyin:

version: STSv1
    mode: enforce
    mx: mail.yourdomain.com
    mx: *.yourdomain.com
    max_age: 86400

Dosyayı kaydedin ve kapatın. Apache’yi yeniden yüklemenize gerek yoktur, çünkü sadece bir dosya içeriğini değiştirdiniz.
2. DNS TXT Kaydındaki id Değerini Güncelleme: Bu adım kritik öneme sahiptir. _mta-sts.yourdomain.com TXT kaydındaki id değerini yeni bir tarih/saat damgası ile güncelleyin. Örneğin:
* Host/Ad/İsim: _mta-sts.yourdomain.com
* Değer/Metin: v=STSv1; id=20231027143000;
Bu, gönderen MTA’lara politikanızın değiştiğini ve yeni politikayı tekrar indirmeleri gerektiğini bildirir.

Bu değişiklikleri yaptıktan sonra, TLS Raporlarını izlemeye devam edin. Artık enforce modunda olduğunuz için, herhangi bir TLS bağlantı ihlali durumunda e-postalar teslim edilmeyecektir. Bu nedenle, herhangi bir yeni hata raporu, acil müdahale gerektiren ciddi bir sorunu gösterebilir.

“Max_Age” ve Periyodik Güncellemeler

max_age değeri, gönderen MTA’ların politikanızı önbellekte ne kadar süreyle tutacağını belirler. İlk başta kısa bir max_age (örneğin 24 saat) kullanmak, hızlı değişiklik yapma esnekliği sağlar. Her şeyin yolunda gittiğinden emin olduğunuzda, bu değeri artırabilirsiniz (örneğin 7 gün veya 30 gün). Daha uzun bir max_age, daha az DNS sorgusu ve daha iyi performans anlamına gelir, ancak politika değişikliklerinin yayılması daha uzun sürer.

id değerini, mta-sts.txt dosyasında yaptığınız her değişiklikte güncellemeniz gerektiğini unutmayın. Bu, diğer sunucuların her zaman en güncel politikanızı kullandığından emin olmanın tek yoludur.

Sık Karşılaşılan Sorunlar ve Çözümleri

MTA-STS yapılandırması sırasında karşılaşılabilecek bazı yaygın sorunlar ve bunların çözümleri şunlardır:

* mta-sts.txt dosyasına ulaşılamıyor (404 Not Found):
* DocumentRoot yolunun ve .well-known/mta-sts/ dizininin doğru olduğundan emin olun.
* Dizin ve dosya izinlerini kontrol edin (chown, chmod). Apache kullanıcısının dosyaya erişim izni olmalıdır.
* Apache sanal host yapılandırmanızda ServerName ve DocumentRoot‘un mta-sts.yourdomain.com ile eşleştiğini kontrol edin.
* mta-sts.yourdomain.com için DNS A kaydının doğru IP adresine işaret ettiğinden emin olun.
* Yanlış İçerik Türü (Content-Type):
* curl -v https://mta-sts.yourdomain.com/.well-known/mta-sts/mta-sts.txt komutunu çalıştırın ve Content-Type başlığının text/plain olduğundan emin olun.
* Apache sanal host yapılandırmanızdaki bloğunun doğru olduğundan ve Header set Content-Type "text/plain" satırının bulunduğundan emin olun.
* mod_headers modülünün etkin olduğundan emin olun (sudo a2enmod headers).
* mx kayıtlarının uyuşmaması:
* mta-sts.txt dosyasındaki mx: kayıtlarının, alan adınızın DNS MX kayıtlarıyla tam olarak eşleştiğinden emin olun. Küçük bir yazım hatası bile sorunlara yol açabilir.
* dig MX yourdomain.com komutunu kullanarak alan adınızın güncel MX kayıtlarını kontrol edin.
* id değerinin güncellenmemesi:
* Politika dosyasında her değişiklik yaptığınızda (özellikle mode veya mx kayıtlarını değiştirdiğinizde), DNS _mta-sts TXT kaydındaki id değerini de güncellemeniz gerektiğini unutmayın. Aksi takdirde, gönderen MTA’lar eski politikayı kullanmaya devam edebilir.
* Sertifika hataları:
* mta-sts.yourdomain.com için SSL/TLS sertifikasının geçerli, süresi dolmamış ve güvenilir bir sertifika yetkilisi tarafından verilmiş olduğundan emin olun.
* Certbot’un otomatik yenileme işleminin düzgün çalıştığını kontrol edin (sudo certbot renew --dry-run).
* Tarayıcınızda https://mta-sts.yourdomain.com adresini ziyaret ederek sertifika bilgilerini kontrol edin.
* DNS yayılımı sorunları:
* DNS kayıtlarınızdaki değişikliklerin global olarak yayılması zaman alabilir. dig komutuyla kontrol ettikten sonra bile, bazı sunucuların eski kayıtları önbelleğe alması mümkündür. Sabırlı olun ve birkaç saat bekleyin.
* TLS Raporlarının gelmemesi veya boş gelmesi:
* _smtp._tls.yourdomain.com TXT kaydındaki rua e-posta adresinin doğru ve çalışır durumda olduğundan emin olun.
* E-posta sağlayıcınızın spam filtrelerini kontrol edin, raporlar bazen spam olarak işaretlenebilir.
* Raporların gelmesi biraz zaman alabilir (genellikle günlük gönderilirler).

Sonuç

MTA-STS ve TLS Raporlama, e-posta iletişiminizi ortadaki adam saldırılarına ve STARTTLS stripping gibi tehditlere karşı korumak için güçlü bir mekanizma sunar. Bu makalede anlatılan adımları dikkatlice uygulayarak, Ubuntu 18.04 ve Apache kullanarak alan adınız için bu kritik güvenlik önlemlerini başarıyla yapılandırabilirsiniz.

Unutulmamalıdır ki, MTA-STS tek başına tüm e-posta güvenliği sorunlarını çözmez. DMARC, SPF ve DKIM gibi diğer e-posta kimlik doğrulama protokolleriyle birlikte kullanıldığında, e-posta güvenliğiniz için kapsamlı ve çok katmanlı bir koruma sağlar.

Başlangıçta testing modunda dikkatli bir izleme yapmak ve TLS Raporlarını düzenli olarak analiz etmek, olası sorunları önceden tespit etmenizi ve e-posta akışınızda kesinti yaşamadan enforce moduna güvenle geçmenizi sağlayacaktır. E-posta güvenliği dinamik bir alandır ve sürekli izleme ile bakım, alan adınızın ve iletişiminizin güvende kalmasını sağlamak için hayati öneme sahiptir. Bu adımlarla, e-posta güvenliği duruşunuzu önemli ölçüde güçlendirmiş olacaksınız.