Postfix ve Dovecot Yamalarını Kesintisiz Uygulamak: CVE Takibinden Sıfır Düşen Bağlantıya
Postfix 3.9.1 çalıştırıyorsun, bugün yeni bir CVE çıktı — seni ilgilendiriyor mu? "Bilmiyorum, restart atayım" cevabı hem gereksiz kesinti hem gerçek açığı kaçırma riski. CVE takibini haber okumaktan çıkarıp sürüm-eşleştirmeli envanter, otomatik uyarı ve kesintisiz reload disiplinine dönüştürüyoruz.
EvilMail Team28 Temmuz 202612 dk okuma
Postfix 3.9.1 çalıştırıyorsun. Bugün yeni bir Postfix CVE'si duyuruldu. Seni ilgilendiriyor mu?
Çoğu operatörün dürüst cevabı: "bilmiyorum, en iyisi bir restart atayım." Bu cevap iki yönden de yanlış. Bir yandan belki hiç etkilenmediğin bir açık için canlı SMTP oturumlarını riske atıyorsun; diğer yandan gerçekten pre-auth ve uzaktan sömürülebilir bir açık varken "sürüm numaram değişmemiş, demek ki güvendeyim" diyerek onu tamamen kaçırıyorsun.
Bu yazının işi net: CVE takibini bir "haber okuma" refleksi olmaktan çıkarıp üç parçalı bir disipline dönüştürmek — sürüm envanteri, isabetli CVE eşleştirme ve kesintisiz reload. evilmail.pro tarafında aynı anda binlerce SMTP ve IMAP oturumu dönüyor; "bakım penceresi ilan edelim" lüksümüz yok. Hedef, yamayı sıfır düşen bağlantıyla uygulamak.
Saldırı yüzeyini önce haritala: neyi yamalayacağını bilmek
Postfix ve Dovecot tek bir binary değil, ayrı ayrı CVE geçmişi olan daemon kümeleridir. Postfix tarafında master süreci smtpd, smtp, cleanup, qmgr, tlsproxy
çocuklarını doğurur. Dovecot tarafında
imap
,
pop3
,
lmtp
,
auth
,
submission
süreçleri koşar. Bir CVE "Dovecot'u etkiliyor" dediğinde asıl soru hangi daemon'u vurduğu ve o daemon'un senin sunucunda aktif olup olmadığıdır.
Önce gerçek çalışan durumu çıkar — tahminle değil:
bash
# Postfix: derlenmiş sürüm ve aktif override'lar
postconf mail_version
postconf -n # varsayılandan sapan ayarlar
postconf -d | grep -i version
# Dovecot: sürüm ve normalize edilmiş aktif config
dovecot --version
doveconf -n
# Dışarıya bakan portlar ve onları dinleyen süreç
ss -tlnp | grep -E ':(25|465|587|993|995|110|143)\b'
systemctl status postfix dovecot --no-pager
doveconf -n çıktısındaki protocols = satırı kritik: eğer pop3 orada yoksa, POP3 daemon'unu vuran bir CVE seni ilgilendirmez. Aynı şekilde submission aktif değilse submission'a özgü açıklar öncelik listenin dışına düşer.
İnternete bakan her port bir CVE kaynağıdır: 25 (smtpd), 587/465 (submission/smtps), 993/995 (imaps/pop3s), 143/110 (STARTTLS ile). Buna TLS kütüphanesini de ekle. OpenSSL'deki bir açık ya da STARTTLS'in yanlış implementasyonu doğrudan mail açığıdır — STARTTLS command injection sınıfı (CVE-2011-0411 mirası) tam olarak buradan doğar: TLS el sıkışmasından önce tampona yazılan plaintext komutlar, şifreli oturuma taşınıp orada işlenir. "Bu bir OpenSSL bug'ı, mail'imle ilgisi yok" demek bu yüzden yanlış.
CVE'yi doğru kaynaktan, gürültüsüz takip et
NVD ve genel CVE feed'leri gürültülüdür; bir mail operatörü için asıl otorite upstream'dir.
Postfix: Wietse Venema'nın postfix-announce posta listesi ve postfix.org üzerindeki release notes. Güvenlik düzeltmeleri buradan, çoğu zaman NVD'den önce ve net etki açıklamasıyla duyurulur.
Dovecot: dovecot.org/security sayfası ve dovecot-news listesi.
Dağıtım katmanı: Debian Security Tracker (security-tracker.debian.org) ve Ubuntu Security Notices (USN). Bunlar backport gerçeğini gösterir.
Backport gerçeği burada en çok hata yapılan yerdir. Debian ve Ubuntu bir CVE'yi yamaladığında upstream sürüm numarasını değiştirmez.postconf mail_version hâlâ 3.9.1 der ama paket revizyonu 3.9.1-1+deb12u2'ye yükselir. Yani "mail_version 3.9.1, upstream 3.9.2'de düzeltmiş, ben açıktayım" mantığı Debian'da yanlıştır — düzeltme senin 3.9.1 paketine geri taşınmış olabilir. Doğru referans paket revizyonudur:
Triyajda CVSS skoruna körü körüne güvenme. 9.8'lik bir skor, açığın senin sunucunda erişilemeyen bir kod yolunda olması durumunda anlamsızdır; tersine "orta" etiketli bir açık, internete açık pre-auth yüzeyde felaket olabilir. Gerçek öncelik filtresi üç kapıdan geçer: uzaktan erişilebilir mi, pre-auth (kimlik doğrulaması gerektirmiyor) mu, ve senin sunucunda o daemon internete açık mı? Üçü de "evet" ise aynı gün yamalarsın. Aşağıdaki karar akışı bu triyajı görselleştiriyor.
Envanteri otomatikleştir: elle takip ölçeklenmez
Üç sunucun varken sürümleri gözle takip edebilirsin. On beş sunucu ve iki dağıtım karışımında bu imkânsızdır. Her node'un çalışan sürümünü merkezi bir yere yazan basit bir cron yeterli:
debsecan --suite bookworm --format detail, kurulu paketlerine karşı hâlâ düzeltilmemiş CVE'leri listeler — yani "bu sunucuda şu an bekleyen güvenlik borcu ne" sorusunu doğrudan cevaplar. Bunu haftalık cron'la operatöre e-postalamak, feed okumaktan çok daha isabetlidir çünkü çıktı senin gerçek paket setine göredir.
Otomatik yamada tek kural var: mail sunucusunda sadece security origin'ini otomatik güncelle. Feature upgrade'lerini asla otomatiğe bırakma — yeni bir minor sürüm sessizce yeni default'lar getirip HELO/TLS davranışını değiştirebilir ve deliverability'ni bozabilir.
Bu kanca, paket güncellemesi config'e dokunduğunda Postfix'i düşürmeden yeniden yükler. Binary'nin kendisi değiştiğinde dpkg zaten servisi restart eder; kanca sadece config-only durumlarda gereksiz kesintiyi önler.
İşin kalbi burası. reload ile restart arasındaki farkı bağlantı seviyesinde bilmezsen, gereksiz yere oturum koparırsın.
Postfix:postfix reload master süreci ayakta tutar. Şu an akan smtpd child'ları oturumlarını bitirene kadar yaşamaya devam eder; yeni bağlantılar yeni config ile açılır. In-flight bir e-posta kaybolmaz. Paket upgrade binary'yi değiştirdiğinde Debian servisi restart eder — ama bu bile veri kaybı demek değil: kuyruk /var/spool/postfix altında diskte durur, restart onu düşürmez, master geri geldiğinde qmgr kaldığı yerden devam eder. postfix reload yeterliyken postfix stop && postfix start yapmak sadece gereksiz risktir.
Dovecot: Config değişikliği için doveadm reload yeterlidir ve mevcut oturumları korur. Ama binary upgrade systemctl restart dovecot gerektirir — ve burada IMAP IDLE oturumları kopar. Sorun değil: düzgün yazılmış her IMAP istemcisi otomatik reconnect eder, kayıp birkaç saniyeyle sınırlıdır. Soğuk başlangıç gecikmesini de azaltabilirsin:
# dovecot.conf
service imap {
process_min_avail = 4 # restart sonrası hazır bekleyen process
}
Çok-node kurulumda bunu rolling yaparsın: node'u load balancer'dan çek, yamala, smoke test geç, geri al. Böylece tek bir node bile kullanıcıya kesinti göstermez. Tek node'da restart penceresi birkaç saniyedir ve kuyruk kaybı yoktur.
Her yamadan sonra üç şeyi doğrula: config farkı, portlar ve gerçek bir oturum.
Yamadan sonra: doğrula, geri alma planı hazır olsun
Her yeni sürüm yeni default'lar getirebilir. postconf -d ile derlenmiş varsayılanları karşılaştır — özellikle smtpd_tls_* ve smtpd_relay_restrictions gibi güvenlik-kritik anahtarlarda sessiz bir davranış değişikliği deliverability'ni vurabilir.
Geri alma prosedürünü önceden hazırla, panik anında değil. İstenmeyen bir upgrade'i durdur, gerekirse önceki revizyona in:
bash
apt-mark hold postfix dovecot-core # otomatik upgrade'i dondur
apt-mark showhold # neyi neden hold'ladığını dokümante et
apt install --allow-downgrades postfix=3.9.1-1+deb12u1 # önceki revizyona downgrade
apt-mark unhold postfix # düzeltilmiş sürüm gelince serbest bırak
Eski .deb dosyalarını /var/cache/apt/archives altında sakla; downgrade'in en garantili yolu paketin kendisini elde tutmaktır. Log tarafında yamadan hemen sonra:
TLS handshake hatalarında ani artış (yanlış sertifika zinciri), auth-fail spike'ı (auth backend değişikliği) ya da fatal satırları, yamanın bir şeyi kırdığının ilk sinyalidir. Bunları ilk 10 dakikada yakalarsan geri alma penceresi hâlâ açıktır.
Pratik kontrol listesi
Envanter script'i (dpkg -l + debsecan) her node'da haftalık cron'da mı, çıktı operatöre gidiyor mu?
unattended-upgradesyalnızca-security origin'iyle mi sınırlı, feature upgrade kapalı mı?
