Zimbra Güvenlik Sertleştirme: En İyi Pratikler

Yazar:komut.io ekibi Zimbra Mail Sunucusu Kurulum ve Yönetimi
0 Yorum

Üretim ortamında Zimbra çalıştırıyorsanız ve sunucunuzu sadece kurup bıraktıysanız, şu an bir güvenlik borcu biriktiriyorsunuz demektir. Bu yazıda yıllarca Zimbra yöneten birisinin öğrendiklerini, bazılarını maalesef saldırı sonrası öğrendiği şeyleri paylaşacağım. Amacım size kontrol listesi değil, her adımın neden önemli olduğunu anlatan gerçekçi bir rehber sunmak.

Zimbra’nın Saldırı Yüzeyini Anlamak

Zimbra’yı özel yapan şey aynı zamanda onu tehlikeli kılan şeydir: tek bir pakette SMTP, IMAP, POP3, HTTP, LDAP, ve bir sürü dahili servis barındırıyor. Bir portundan sızan saldırgan, pratikte tüm mail altyapınıza erişebiliyor.

Tipik bir Zimbra sunucusunda açık olan portlara bakın:

ss -tlnp | grep -E '(zimbra|java|nginx|postfix|ldap)'

Çıktıda 25, 80, 110, 143, 389, 443, 465, 587, 636, 993, 995, 7071, 7143, 7993, 8080, 8443 gibi onlarca port görürsünüz. Her biri potansiyel bir giriş noktası. Bu yüzden sertleştirme işini katman katman yapmak gerekiyor.

İlk Adım: Erişim Kontrolü ve Firewall

Kurumsal ağlarda gördüğüm en yaygın hata, Zimbra’yı tamamen internete açık bırakmak. 7071 admin portu internete açık olmamalı, nokta.

# UFW kullanıyorsanız temel kural seti
ufw default deny incoming
ufw default allow outgoing

# Mail trafiği için zorunlu portlar
ufw allow 25/tcp    # SMTP (gelen mail)
ufw allow 465/tcp   # SMTPS
ufw allow 587/tcp   # Submission
ufw allow 993/tcp   # IMAPS
ufw allow 995/tcp   # POP3S
ufw allow 443/tcp   # HTTPS webmail

# HTTP'yi yalnızca HTTPS'e yönlendirme için açıyoruz
ufw allow 80/tcp

# Admin portu SADECE yönetim ağından
ufw allow from 10.0.1.0/24 to any port 7071

# Güvensiz portları tamamen kapat
ufw deny 110/tcp    # POP3 plaintext
ufw deny 143/tcp    # IMAP plaintext

ufw enable

iptables kullanıyorsanız aynı mantıkla:

# Yönetim portunu yalnızca belirli IP'den erişime aç
iptables -A INPUT -p tcp --dport 7071 -s 10.0.1.100 -j ACCEPT
iptables -A INPUT -p tcp --dport 7071 -j DROP

# Değişiklikleri kalıcı yap
iptables-save > /etc/iptables/rules.v4

SSL/TLS Yapılandırması

Zimbra varsayılan kurulumda self-signed sertifika kullanır. Üretimde bunu bırakmak hem kullanıcı deneyimini hem de güvenliği zedeler. Let’s Encrypt veya kurumsal CA’nızdan aldığınız sertifikayı nasıl uygularsınız:

# Zimbra kullanıcısına geç
su - zimbra

# Mevcut sertifika durumunu kontrol et
zmcertmgr viewdeployedcrt all

# Yeni sertifika deploy et (sertifika dosyalarınız hazır olduğunu varsayarak)
# commercial.crt: sunucu sertifikası
# commercial_ca.crt: ara CA sertifikaları
# commercial.key: özel anahtar

zmcertmgr deploycrt comm /tmp/commercial.crt /tmp/commercial_ca.crt
zmcertmgr deployca /tmp/commercial_ca.crt

# Servisleri yeniden başlat
zmcontrol restart

TLS versiyonunu da kontrol edin. SSLv3 ve TLS 1.0/1.1 artık güvensiz kabul ediliyor:

su - zimbra

# MTA üzerinde zayıf TLS protokollerini devre dışı bırak
zmprov mcf zimbraMtaTlsSecurityLevel may
postconf -e 'smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1'
postconf -e 'smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1'
postconf -e 'smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1'

# Zayıf cipher'ları devre dışı bırak
postconf -e 'smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, KRB5-DES-CBC3-SHA'

zmcontrol restart

Postfix ve SMTP Güvenliği

Open relay olmak email dünyasında en kötü şeylerden biri. Spam listelerine girdiğinizde çıkmak saatler bazen günler alıyor.

su - zimbra

# Open relay testini yapmadan önce mevcut durumu kontrol et
postconf mynetworks
postconf smtpd_recipient_restrictions

# Relay kısıtlamalarını sıkılaştır
zmprov mcf zimbraMtaMyNetworks "127.0.0.0/8 [::1]/128"

# SMTP AUTH olmadan relay'e izin verme
postconf -e 'smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination'

# HELO/EHLO kontrolü ekle
postconf -e 'smtpd_helo_required = yes'
postconf -e 'smtpd_helo_restrictions = permit_mynetworks, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname'

# Geçersiz alıcıları SMTP seviyesinde reddet
postconf -e 'smtpd_reject_unlisted_recipient = yes'

Brute force koruması için Postfix rate limiting:

# /opt/zimbra/conf/postfix_header_checks dosyasına ekle
# Aynı IP'den çok fazla bağlantıyı engelle
postconf -e 'smtpd_client_connection_count_limit = 50'
postconf -e 'smtpd_client_connection_rate_limit = 30'
postconf -e 'smtpd_client_message_rate_limit = 100'
postconf -e 'anvil_rate_time_unit = 60s'

Spam ve Phishing Koruması

SPF, DKIM ve DMARC üçlüsü artık zorunlu. Sadece gelen mailler için değil, giden mailler için de bu kayıtların doğru yapılandırıldığından emin olun.

DKIM imzalamayı etkinleştirmek:

su - zimbra

# DKIM anahtarı oluştur
/opt/zimbra/libexec/zmdkimkeyutil -a -d sirket.com.tr

# Oluşturulan DNS kaydını al
/opt/zimbra/libexec/zmdkimkeyutil -q -d sirket.com.tr

# Çıktıdaki TXT kaydını DNS'e eklemeyi unutmayın
# Genellikle şöyle bir şey görürsünüz:
# _domainkey.sirket.com.tr TXT "v=DKIM1; k=rsa; p=MIGfMA0G..."

SpamAssassin skorlarını Zimbra üzerinden ayarlayabilirsiniz:

su - zimbra

# Spam eşik değerlerini ayarla
zmprov mcf zimbraSpamKillPercent 75
zmprov mcf zimbraSpamTagPercent 33

# SpamAssassin kural güncellemesi
/opt/zimbra/bin/zmspamcontrol update

# Amavis spam filtresi durumunu kontrol et
zmamavisdctl status

Zimbra Admin Paneli Güvenliği

7071 portuna olan brute force saldırıları gerçek ve sürekli. Bunu deneyimledim; log dosyalarına baktığımda Rusya, Çin, Brezilya gibi onlarca farklı ülkeden gün içinde binlerce başarısız deneme görürdüm.

# Fail2ban kurulumu ve Zimbra için jail yapılandırması
apt-get install fail2ban  # Debian/Ubuntu için

# /etc/fail2ban/jail.local dosyasına ekle
cat >> /etc/fail2ban/jail.local << 'EOF'
[zimbra-admin]
enabled = true
port = 7071,7072
filter = zimbra-admin
logpath = /opt/zimbra/log/mailbox.log
maxretry = 3
bantime = 3600
findtime = 600

[zimbra-smtp]
enabled = true
port = smtp,465,587
filter = zimbra-smtp
logpath = /var/log/zimbra.log
maxretry = 5
bantime = 7200
findtime = 600
EOF

Fail2ban filtre dosyasını oluşturun:

cat > /etc/fail2ban/filter.d/zimbra-admin.conf << 'EOF'
[Definition]
failregex = [ip=<HOST>].*authentication failed
            security - cmd='AdminAuth'.*error='authentication failed'.*ip=<HOST>
ignoreregex =
EOF

systemctl restart fail2ban
fail2ban-client status zimbra-admin

LDAP Güvenliği

Zimbra’nın LDAP bileşeni çok kritik çünkü tüm kullanıcı bilgileri ve konfigürasyon buraya yazılıyor. Varsayılan LDAP şifresini değiştirmek ihmal edilen konuların başında geliyor.

su - zimbra

# LDAP admin şifresini kontrol et
zmlocalconfig -s zimbra_ldap_password

# Eğer basit bir şifreyse değiştir
# Önce mevcut şifreyi öğren, sonra değiştir
zmldappasswd -r    # root LDAP şifresi
zmldappasswd       # zimbra LDAP şifresi

# LDAP'ın dışarıdan erişilebilir olmadığını kontrol et
# 389 ve 636 portları sadece localhost'ta dinlemeli
netstat -tlnp | grep -E ':(389|636)'

# Eğer 0.0.0.0:389 görüyorsanız bu bir sorundur
# /opt/zimbra/conf/ldap/slapd.conf dosyasını inceleyin

LDAP şifre politikasını güçlendirin:

su - zimbra

# Minimum şifre uzunluğu
zmprov mcf zimbraPasswordMinLength 12

# Karmaşıklık gereksinimleri
zmprov mcf zimbraPasswordMinUpperCaseChars 1
zmprov mcf zimbraPasswordMinLowerCaseChars 1
zmprov mcf zimbraPasswordMinPunctuationChars 1
zmprov mcf zimbraPasswordMinNumericChars 1

# Şifre geçmişi (son 5 şifreyi hatırla)
zmprov mcf zimbraPasswordEnforceHistory 5

# Maksimum başarısız giriş denemesi
zmprov mcf zimbraMaxLoginAttempts 5

# Hesap kilitleme süresi (dakika)
zmprov mcf zimbraFailedLoginLockoutDuration 30m

Log İzleme ve Anomali Tespiti

Güvenliği sadece engellemek değil, tespit etmek de oluşturur. Zimbra logları çok ayrıntılı ama dağınık. Temel log dosyaları:

  • /var/log/zimbra.log: SMTP ve genel Zimbra logları
  • /opt/zimbra/log/mailbox.log: Webmail ve admin erişimleri
  • /opt/zimbra/log/audit.log: Güvenlik olayları

Basit bir anomali tespit scripti yazabilirsiniz:

#!/bin/bash
# /usr/local/bin/zimbra-security-check.sh
# Günlük güvenlik raporu için cron'a ekleyin

LOG_FILE="/var/log/zimbra.log"
AUDIT_LOG="/opt/zimbra/log/audit.log"
REPORT="/tmp/zimbra-security-$(date +%Y%m%d).txt"

echo "=== Zimbra Güvenlik Raporu $(date) ===" > $REPORT

echo -e "n[!] Başarısız Admin Girişimleri (son 24 saat):" >> $REPORT
grep "authentication failed" $AUDIT_LOG | grep "$(date +%Y-%m-%d)" | wc -l >> $REPORT

echo -e "n[!] Engellenen SMTP Bağlantıları:" >> $REPORT
grep "NOQUEUE: reject" $LOG_FILE | grep "$(date +%b %e)" | tail -20 >> $REPORT

echo -e "n[!] En Çok Başarısız Giriş Yapan IP'ler:" >> $REPORT
grep "authentication failed" $AUDIT_LOG | grep -oP 'ip=K[0-9.]+' | sort | uniq -c | sort -rn | head -10 >> $REPORT

echo -e "n[!] Büyük Boyutlu Gönderilen Mailler (>10MB):" >> $REPORT
grep "size=" $LOG_FILE | awk -F'size=' '{print $2}' | awk '{print $1}' | awk '$1 > 10485760' | wc -l >> $REPORT

# Raporu mail at
cat $REPORT | mail -s "Zimbra Günlük Güvenlik Raporu" [email protected]

Scripti cron’a ekleyin:

echo "0 7 * * * root /usr/local/bin/zimbra-security-check.sh" >> /etc/cron.d/zimbra-security
chmod +x /usr/local/bin/zimbra-security-check.sh

Yedekleme Güvenliği ve Veri Koruma

Bir güvenlik olayı yaşandığında temiz bir yedeğe sahip olmak hayat kurtarır. Zimbra’nın dahili yedekleme mekanizması var ama bunun sağlıklı çalıştığını düzenli test etmek gerekiyor.

su - zimbra

# Yedekleme durumunu kontrol et
zmbackupquery -lb

# Manuel tam yedek al
zmbackupctl start -f

# Yedek bütünlüğünü doğrula
zmbackupquery -lb | grep "Status"

# Hesap bazlı yedek al (kritik kullanıcılar için)
zmmailbox -z -m [email protected] getRestURL '//?fmt=tgz' > /backup/kritikkullanici-$(date +%Y%m%d).tgz

Yedekleri ayrı bir lokasyona kopyalamayı unutmayın. Aynı sunucudaki yedekler ransomware saldırısında işe yaramaz.

Zimbra Güvenlik Güncellemeleri

Zimbra’yı güncel tutmak can sıkıcı ama kaçınılmaz. Özellikle 2022’de yaşanan Log4j krizi ve ardından gelen Zimbra zero-day’leri bu gerçeği acımasızca gösterdi.

# Mevcut Zimbra versiyonunu kontrol et
su - zimbra -c "zmcontrol -v"

# Patch seviyesini kontrol et
rpm -qa | grep zimbra | head -5    # RHEL/CentOS için
dpkg -l | grep zimbra | head -5    # Debian/Ubuntu için

# Zimbra güvenlik bültenlerini takip etmek için:
# https://wiki.zimbra.com/wiki/Security_Center

# Güncelleme öncesi yedek almayı unutmayın
zmbackupctl start -f

# Güncelleme sonrası servis durumu kontrolü
zmcontrol status

Güncelleme stratejisi olarak şunu öneririm: Önce bir test ortamında uygulayın, 48 saat izleyin, sorun yoksa üretime alın. Acele güncelleme de bazen iş durdurucu olabiliyor.

Zimbra Çalışma Zamanı Sertleştirme

Zimbra’nın kendi içinde de bazı güvenlik parametreleri var. Bunları doğru ayarlamak önemli:

su - zimbra

# Webmail oturum zaman aşımı (dakika)
zmprov mcf zimbraWebClientSessionTimeout 30m

# Admin konsol oturum zaman aşımı
zmprov mcf zimbraAdminConsoleSessionTimeout 10m

# Şüpheli aktivite durumunda oturumu sonlandır
zmprov mcf zimbraEnforceSingleClientLoginSession TRUE

# Two-factor authentication'ı etkinleştir (Zimbra 8.7+)
zmprov mcf zimbraFeatureTwoFactorAuthAvailable TRUE
zmprov mcf zimbraFeatureTwoFactorAuthRequired FALSE  # Zorunlu yapmak istiyorsanız TRUE

# Güvenli olmayan protokolleri devre dışı bırak
zmprov mcf zimbraImapCleartextLoginEnabled FALSE
zmprov mcf zimbraPop3CleartextLoginEnabled FALSE

# Zimlet güvenliği
zmprov mcf zimbraZimletLoadSynchronously TRUE

HTTP Security Header’larını da yapılandırmak gerekiyor. Bu kısım çoğunlukla atlanıyor ama XSS ve clickjacking saldırılarına karşı önemli:

# Zimbra Proxy (nginx) konfigürasyonunu düzenle
# /opt/zimbra/conf/nginx/includes/nginx.conf.web.https.default dosyasına
# veya özel include dosyasına eklenebilir

cat >> /opt/zimbra/conf/nginx/includes/nginx.conf.web.https.default << 'EOF'
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
EOF

# Değişiklik sonrası proxy'yi yeniden başlat
zmproxyctl restart

Sonuç

Zimbra güvenliği tek seferlik bir iş değil, sürekli devam eden bir süreç. Bu yazıda anlattıklarımı özetlersek; firewall ile saldırı yüzeyini küçültün, TLS yapılandırmasını güncel tutun, open relay olmadığınızı düzenli kontrol edin, brute force koruması için fail2ban kullanın, LDAP şifrelerini güçlendirin, log izlemeyi otomatize edin ve asla güncellemeyi ertelemeyin.

Şunu da ekleyeyim: Güvenlik olayı yaşamak için beklemek zorunda değilsiniz. Ayda bir kez /opt/zimbra/log/audit.log dosyasına bakın, başarısız giriş denemelerini sayın, açık portları kontrol edin. Bu basit alışkanlık çoğu sorunu erken tespit etmenizi sağlar.

Bazı şeyleri maalesef saldırı sonrası öğrenirim demek zorunda kaldım. Umarım bu yazı sizin için o aşamayı atlatır. Herhangi bir adımda takılırsanız ya da ortamınıza özgü bir senaryo yaşarsanız yorumlarda tartışabiliriz.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir