Bir Haftada Birden Fazla Güvenlik Başlığı
Mayıs 2026’nın ilk haftası cPanel yöneten ekipler için yoğun geçti. Panel tarafındaki CVE duyurularına ek olarak Exim bileşeniyle ilişkili güvenlik başlıkları da gündeme geldi. Bu tablo, hosting operasyonlarında “ayda bir güncelleme yaparız” anlayışının artık yeterli olmadığını gösteriyor. cPanel sunucusu tek bir yazılımdan oluşmaz; WHM, cPanel, webmail, DNSOnly, EasyApache, Exim, Dovecot, PHP paketleri, AutoSSL, yedek sistemi ve üçüncü parti eklentiler birlikte çalışır. Bu zincirde zayıf kalan halka, tüm sunucunun risk seviyesini belirleyebilir.
Exim özellikle önemlidir çünkü cPanel sunucularında posta trafiğinin merkezindedir. Web sitelerinden çıkan formlar, müşterilerin e-posta hesapları, otomatik bildirimler, fatura e-postaları ve şifre sıfırlama mesajları bu katmandan geçer. Mail servisine yönelik bir açık veya yanlış yapılandırma, hem güvenlik hem de itibar açısından zarar verir. IP kara listeye düşebilir, spam çıkışı artabilir, müşteri e-postaları gecikebilir veya yetkisiz relay denemeleri oluşabilir. Bu yüzden panel güncellemesi yapılırken mail bileşenleri de aynı ciddiyetle izlenmelidir.
Güncelleme Disiplini
cPanel güncellemelerinde temel komut bilinse de süreç disiplinli yürütülmelidir. Önce mevcut build, işletim sistemi, lisans durumu, disk doluluğu ve kritik servislerin durumu kaydedilir. Ardından `/scripts/upcp --force` ile güncelleme uygulanır. İşlem sonunda `/usr/local/cpanel/cpanel -V` ile build doğrulanır; cpsrvd, Exim, Dovecot, PHP-FPM ve web server servisleri kontrol edilir. Bazı sunucularda güncelleme başarılı görünür fakat bir servis eski prosesle devam eder. Bu yüzden sadece “completed” çıktısı değil, aktif servis durumu önemlidir.
Exim güncellemelerinde mail queue ayrıca kontrol edilmelidir. Kuyrukta olağan dışı artış varsa güncelleme sonrası bunun sebebi incelenmelidir. Çok sayıda başarısız teslimat, tek bir kullanıcıdan yoğun çıkış, şüpheli scriptlerden mail gönderimi veya yanlış SPF/DKIM yapılandırması olabilir. Güvenlik güncellemesini performans ve itibar kontrolüyle birleştirmek, hosting firmaları için daha sağlıklı sonuç verir.
Panel Portları Herkese Açık Olmalı mı?
WHM, cPanel ve webmail portlarının tüm internete açık olması pratik görünür ama güvenlik açısından zayıf bir varsayımdır. 2083, 2087, 2095 ve 2096 portları saldırgan taramalarında sık hedeflenir. Güncel bir panel bile brute force, credential stuffing ve exploit taramalarına maruz kalır. Kritik CVE dönemlerinde bu portlar özellikle taranır. En güvenli model, yönetim erişimini VPN, ofis IP’si veya belirlenmiş müşteri IP bloklarıyla sınırlamaktır. Tüm müşteriler için tam IP kısıtı mümkün değilse bile WHM root erişimi ve reseller yönetimi mutlaka daraltılmalıdır.
Webmail tarafında karar daha hassastır. Bazı hosting müşterileri webmail’i farklı ağlardan kullanır. Bu durumda tamamen kapatmak yerine rate limit, country filtering, 2FA destekleri, güçlü parola politikası ve şüpheli login izleme uygulanabilir. WHM ve root yönetimi ise son kullanıcı konforu gerekçesiyle açık bırakılmamalıdır. Yönetim paneli, web sitesi gibi herkesin dolaşacağı bir alan değildir; güvenilir idari ağlardan erişilmesi gerekir.
Service Subdomains ve Saldırı Yüzeyi
Service Subdomains, kullanıcıya kolaylık sağlar: cpanel.domain.com, whm.domain.com ve webmail.domain.com gibi adresler akılda kalıcıdır. Ancak bu kolaylık aynı zamanda görünür saldırı yüzeyi oluşturur. Bir saldırgan domain listesi üzerinden service subdomainleri tarayarak panel endpointlerine ulaşabilir. CVE dönemlerinde bu durum daha risklidir. Güncelleme gecikecekse service subdomain erişimini geçici olarak kapatmak veya firewall ile sınırlamak akıllıca olur.
Bu karar müşteriye anlatılırken net olmak gerekir. “Güvenlik bakımı süresince panel erişimi yalnızca ana adres veya VPN üzerinden sağlanacaktır” gibi kısa bir bildirim yeterlidir. Belirsiz kapatmalar destek yükünü artırır. Panel erişimi kısıtlandığında normal web sitelerinin çalışmaya devam ettiğinden emin olunmalı, DNS ve SSL yenileme süreçleri etkilenmemelidir.
Exim İçin Sağlıklı Kontroller
Exim güvenliği için yalnızca paket sürümüne bakmak yeterli değildir. Mail queue, outgoing mail limitleri, SMTP AUTH denemeleri, başarısız loginler, DKIM/SPF/DMARC yapılandırmaları ve kullanıcı bazlı gönderim istatistikleri izlenmelidir. Bir web sitesindeki zafiyet spam çıkışına sebep oluyorsa Exim güncel olsa bile IP itibarınız zarar görür. Bu nedenle cPanel güvenlik kontrolleri ile mail abuse kontrolleri aynı bakım listesinde yer almalıdır.
Kritik bir duyuru sonrası `/var/log/exim_mainlog`, `/var/log/exim_rejectlog` ve cPanel mail delivery raporları incelenebilir. Kısa sürede çok sayıda alıcıya mail gönderen kullanıcılar, sürekli auth denemesi yapan IP’ler ve başarısız relay girişimleri not edilmelidir. Gerekiyorsa kullanıcı bazlı mail limitleri düşürülür, zayıf parolalar sıfırlanır, şüpheli scriptler devre dışı bırakılır. Bu işlemler müşteriye zarar vermeden ve kanıt kaybetmeden yapılmalıdır.
Eski İşletim Sistemleri
Mayıs 2026 güvenlik gündemi, eski işletim sistemleriyle panel yönetmenin ne kadar yorucu olduğunu bir kez daha gösterdi. CentOS 6/7 veya eski CloudLinux tabanları güncelleme kanalı, paket uyumluluğu ve destek süresi açısından risk oluşturur. Bu sistemlerde güvenlik duyurusu geldiğinde normal update akışı her zaman beklendiği gibi çalışmaz. Teknik ekip, “bir sonraki CVE’de ne yapacağız?” sorusunu bugünden cevaplamalıdır. Kalıcı çözüm genellikle yeni ve destekli bir işletim sistemi üzerine temiz migration planıdır.
Migration planı yalnızca hesap taşıma değildir. PHP sürümleri, ionCube, özel Apache/LiteSpeed ayarları, DNS cluster, mail IP’leri, SSL sertifikaları, yedek politikası, CloudLinux limitleri ve Imunify/CSF kuralları birlikte aktarılmalıdır. Eski sunucuyu ayakta tutmak kısa vadede kolay görünür; ancak güvenlik duyuruları sıklaştıkça bakım maliyeti ve risk yükselir.
Haftalık Bakım Rutini Nasıl Olmalı?
Bu yoğun güvenlik gündeminden sonra hosting firmalarının haftalık bakım rutini daha somut hale gelmelidir. Pazartesi yalnızca disk ve servis durumuna bakmak yeterli değildir. cPanel build sürümü, Exim ve Dovecot paketleri, EasyApache güncellemeleri, CloudLinux paketleri, Imunify/CSF kuralları ve yedek görevleri aynı listede kontrol edilmelidir. Ardından panel loglarında olağan dışı yönetim girişleri, mail loglarında spam davranışı ve web loglarında exploit taramaları özetlenmelidir. Bu iş birkaç saatlik karmaşık analiz olmak zorunda değildir; düzenli ve kısa rapor yeterlidir.
Müşteri destek ekibi de bu rutine dahil edilmelidir. Teknik ekip güncelleme yaparken destek ekibi müşteriye ne söyleyeceğini bilmezse gereksiz panik oluşur. Kısa bir bakım notu, beklenen etkiler ve tamamlandı bildirimi hazır olmalıdır. Güvenlik duyurusunda müşteriye “hangi CVE, hangi sürüm, hangi etki” ayrıntısını uzun uzun anlatmak yerine, alınan önlemleri sade dille aktarmak daha sağlıklıdır.
En değerli alışkanlık ise eski notları saklamaktır. Bir sonraki güvenlik duyurusunda geçmişte hangi komutların çalıştığı, hangi müşterilerin etkilendiği, hangi eklentinin sorun çıkardığı biliniyorsa ekip çok daha hızlı hareket eder. Kurumsal güvenlik hafızası pahalı bir ürün değil, düzenli tutulmuş bakım notudur.
Haftalık bakımın bir diğer ayağı kapasite gözlemidir. Güvenlik güncellemesi yapılırken CPU, RAM, disk I/O ve MySQL yükü zaten izleniyorsa anormal artışlar daha kolay fark edilir. Bir exploit taraması çoğu zaman yalnızca logda değil, kaynak tüketiminde de iz bırakır. Panel portlarına gelen taramalar, webmail brute force denemeleri veya mail queue şişmesi tek tek küçük görünebilir; birlikte okunduğunda saldırı hazırlığına işaret edebilir.
Bu nedenle güvenlik ve performans izleme ayrılmamalıdır. Hızlı çalışan ama log üretmeyen bir sunucu, olay anında kördür. Çok log üreten ama kimsenin okumadığı bir sunucu da aynı derecede zayıftır. Doğru bakım rutini, ölçülebilir veriyi kısa ve karar alınabilir rapora dönüştürür.
Raporun hedefi uzun belge üretmek değildir. Teknik ekip haftalık olarak “güncel sürüm, açık risk, bekleyen bakım, şüpheli trafik, mail itibarı, yedek durumu” gibi beş altı satırlık bir özet çıkarsa yöneticiler de karar verebilir. Güvenlik bilgisinin okunabilir olması, teknik doğruluğu kadar önemlidir.
Bu rapor müşteriye aynen gönderilmek zorunda değildir; iç karar mekanizması için tutulur. Müşteriye gidecek metin daha sade olur. Ancak içeride ayrıntı saklanırsa sonraki bakımda aynı sorular tekrar sorulmaz ve ekip zaman kazanır.
Ölçülen sistem daha kolay korunur; ölçülmeyen sistem ise ancak sorun çıkınca fark edilir.
Bu yüzden haftalık rapor kısa da olsa düzenli kalmalıdır.
Sonuç
Mayıs 2026 cPanel güvenlik takvimi, panel yöneten herkes için net bir mesaj veriyor: güncel build, kontrollü panel portları, sağlıklı mail izleme, service subdomain farkındalığı ve eski işletim sistemlerinden çıkış planı artık lüks değildir. CVE duyurularına tek tek tepki vermek yerine standart bir bakım prosedürü oluşturulmalıdır. Her duyuruda aynı kontrol listesi çalışırsa ekip hızlı karar verir, müşteriye doğru bilgi verir ve saldırı yüzeyini büyümeden kapatır.