Güncel Kalmak Başlangıçtır, Tek Başına Yeterli Değildir
Son cPanel güvenlik duyuruları, hosting sunucularında sertleştirme çalışmalarının ertelenemeyeceğini gösterdi. Bir sunucunun güncel olması önemlidir fakat güvenli kabul edilmesi için yeterli değildir. Güncelleme açığı kapatır; yanlış açık portlar, zayıf parolalar, geniş API tokenları, kötü dosya izinleri, unutulmuş yedek arşivleri ve izlenmeyen loglar aynı risk ortamını sürdürür. Bu nedenle cPanel güvenliği, tek seferlik bir işlem değil düzenli işletilen bir süreç olmalıdır.
Paylaşımlı hosting ortamında riskin etkisi katlanır. Tek bir sunucuda onlarca veya yüzlerce müşteri olabilir. Bir müşterinin zayıf WordPress eklentisi, başka bir müşterinin zayıf mail parolası, reseller’ın gereksiz geniş yetkileri veya root panel portunun herkese açık kalması aynı makinede birleşir. Güvenli mimari, bu riskleri tamamen yok edemez; ancak birbirine sıçramasını ve büyümesini engeller. Sertleştirme rehberinin amacı da budur: bir açık çıktığında hasarı sınırlamak, tespiti hızlandırmak ve geri dönüşü kolaylaştırmak.
Yönetim Erişimini Daraltın
İlk adım yönetim erişimini daraltmaktır. WHM root erişimi tüm internete açık bırakılmamalıdır. 2087 portu en azından şirket ofis IP’si, VPN veya yönetim subnet’i ile sınırlandırılmalıdır. Eğer müşterilerin cPanel erişimi için 2083 açık kalacaksa bile root ve reseller tarafı ayrı değerlendirilmelidir. SSH için parola ile root login kapatılmalı, key tabanlı erişim kullanılmalı ve mümkünse farklı bir yönetici kullanıcı üzerinden sudo akışı tercih edilmelidir. SSH portunu değiştirmek tek başına güvenlik sağlamaz; asıl güvenlik yetki ve doğrulama modelindedir.
WHM’de iki aşamalı doğrulama zorunlu hale getirilmelidir. Root ve reseller hesaplarında 2FA yoksa zayıf veya sızmış parolalar büyük risk yaratır. Ayrıca eski çalışanların hesapları, geçici destek hesapları ve test resellerları temizlenmelidir. Bir incident response çalışmasında en çok zaman kaybettiren konulardan biri “bu hesap kime ait?” sorusudur. Hesap sahipliği net değilse o hesap güvenilir kabul edilmemelidir.
API Tokenlarını Envantere Alın
Modern hosting operasyonları WHM API olmadan çalışmaz. Faturalandırma paneli, lisans sistemi, bayi arayüzü, monitoring ve otomasyon scriptleri panelle konuşur. Fakat her entegrasyon için root seviyesinde geniş token kullanmak ciddi hatadır. Her sistem için ayrı token, minimum yetki ve IP kısıtı uygulanmalıdır. Token oluşturma tarihi, son kullanım amacı ve sorumlusu kayıt altına alınmalıdır. Kullanılmayan tokenlar silinmeli, kullanılanlar düzenli aralıklarla yenilenmelidir.
Token değerleri config dosyalarında düz metin olarak duruyorsa bu dosyaların izinleri çok sıkı olmalıdır. Eski backup zipleri, geliştirici kopyaları ve public_html altında unutulmuş config dosyaları token sızıntısının yaygın kaynağıdır. Token güvenliği yalnızca WHM ekranında değil, dosya sistemi ve yedek politikası içinde de düşünülmelidir.
Dosya Sistemi ve Kullanıcı İzolasyonu
Kullanıcı home dizinleri düzenli olarak kontrol edilmelidir. World-writable klasörler, yanlış sahiplikli dosyalar, public_html altında duran eski arşivler, `.env` dosyaları, `wp-config.php` izinleri ve migration kalıntıları risk oluşturur. CloudLinux kullanılıyorsa CageFS aktifliği, LVE limitleri ve PHP Selector durumları denetlenmelidir. Cage dışına çıkarılmış kullanıcılar varsa gerekçesi yazılı olmalıdır. Eski istisnalar zamanla güvenlik açığına dönüşür.
Geçici dizinler de unutulmamalıdır. `/tmp`, `/var/tmp` ve `/dev/shm` üzerinde noexec, nosuid ve nodev gibi mount seçenekleri değerlendirilmeli, web shell veya zararlı binary kalıntıları düzenli aranmalıdır. Ancak her sunucuda aynı mount ayarı doğrudan uygulanmamalıdır; bazı uygulamalar özel ihtiyaç duyabilir. Önce test, sonra kalıcı ayar yapılmalıdır.
Mail Güvenliği
cPanel sunucularında mail güvenliği, web güvenliği kadar önemlidir. Zayıf mail parolaları, spam çıkışı ve kötü ayarlanmış SPF/DKIM kayıtları IP itibarını düşürür. Exim ve Dovecot güncel tutulmalı, SMTP AUTH denemeleri izlenmeli, kullanıcı bazlı gönderim limitleri uygulanmalıdır. Bir kullanıcı hesabından olağan dışı mail çıkışı varsa otomatik uyarı üretilmelidir. Mail queue düzenli kontrol edilmeli, başarısız teslimatlar ve reject logları incelenmelidir.
Web sitelerinden çıkan mail formları da kontrol edilmelidir. Eski PHP scriptleri sınırsız mail gönderebilir veya header injection benzeri riskler taşıyabilir. Hosting firması, müşterinin uygulamasını tamamen yönetmese bile sunucu düzeyinde limit ve tespit mekanizması kurabilir. Bu, hem müşteriyi hem de sunucu IP itibarını korur.
Yedek ve Restore Gerçeği
Yedek almak kadar restore edebilmek de önemlidir. JetBackup veya başka bir sistem kullanılıyorsa periyodik test restore yapılmalıdır. Yedeklerin sadece aynı sunucuda durması yeterli değildir; ransomware, disk arızası veya root compromise durumunda offsite kopya gerekir. Yedek dizinleri web’den erişilebilir olmamalı, cpmove ve manuel zip dosyaları public_html altında bırakılmamalıdır. Eski migration kalıntıları disk doldurmanın yanında veri sızıntısı riski de taşır.
Olay sonrası geri dönüş planı yazılı olmalıdır. Hangi durumda yalnızca hesap restore yapılır, hangi durumda temiz sunucuya migration gerekir, root compromise şüphesinde kim karar verir, müşteriye nasıl bilgi verilir? Bu sorular kriz anında cevaplanmaya çalışılırsa zaman kaybedilir. Önceden hazırlanmış prosedür, teknik ekibin doğru sırayla hareket etmesini sağlar.
Log ve İzleme
Güvenlik olaylarını görmek için logların anlamlı şekilde izlenmesi gerekir. WHM access log, cPanel access log, Exim logları, SSH auth logları, ModSecurity kayıtları, Imunify/CSF uyarıları ve sistem servis restartları birlikte ele alınmalıdır. Tek bir log satırı her zaman kanıt değildir; fakat zaman çizelgesi oluşturulduğunda saldırı davranışı görünür hale gelir. Farklı ülkelerden yönetim paneli girişleri, kısa sürede çok sayıda başarısız deneme, beklenmeyen API çağrıları ve yeni SSH key eklemeleri alarm üretmelidir.
Merkezi log sistemi olmayan küçük yapılarda bile basit günlük raporlar işe yarar. En çok başarısız login alan hesaplar, en fazla mail gönderen kullanıcılar, en çok 404 üreten IP’ler ve WHM API çağrıları haftalık kontrol edilebilir. Güvenlik yalnızca saldırı anında değil, normal zamanlarda anomaliyi tanımakla güçlenir.
Kritik Roller ve Sorumluluklar
Sertleştirme çalışmasının kalıcı olması için sorumluluklar net ayrılmalıdır. Sunucu yöneticisi güncelleme ve servis sağlığından, destek ekibi müşteri iletişiminden, güvenlik sorumlusu log analizinden, muhasebe veya bayi ekibi ise otomasyon ve token kullanımından haberdar olmalıdır. Küçük firmalarda bu roller aynı kişide olabilir; yine de kontrol listesinde ayrı başlıklar halinde durmaları gerekir. Aksi halde yoğun iş gününde bir başlık kolayca unutulur.
Örneğin WHM API tokenlarını kim yenileyecek, yenilenen tokenı hangi entegrasyona kim girecek, eski token ne zaman silinecek? cPanel portlarını kim kısıtlayacak, müşteri erişimi etkilenirse kim cevap verecek? Yedek restore testi kim tarafından yapılacak? Bu soruların cevabı önceden belliyse güvenlik duyurusu geldiğinde karar süresi kısalır. Belirsizlik, teknik risk kadar operasyonel risk de üretir.
Müşteri sözleşmeleri ve hizmet açıklamaları da gerçekçi olmalıdır. Paylaşımlı hosting müşterisine limitsiz yönetim paneli erişimi vaat edilirken güvenlik nedeniyle geçici IP kısıtı gerekebileceği belirtilmelidir. Bu şeffaflık kriz anında firmanın elini güçlendirir. Güvenlik önlemi müşteriye keyfi kesinti gibi değil, hizmetin parçası olarak anlatılmalıdır.
Sertleştirme planında değişikliklerin geri dönüş yolu da bulunmalıdır. Firewall kuralı, port kısıtı, PHP handler değişimi veya mail limiti uygulanmadan önce mevcut değerler not edilmelidir. Sorun çıkarsa hangi ayarın geri alınacağı bilinmelidir. Bu kayıt disiplini, özellikle gece bakımında veya yoğun trafik alan haber/e-ticaret sitelerinde büyük fark yaratır. Güvenli değişiklik, sadece doğru ayarı yapmak değil, yanlış etki görülürse hızlı ve kontrollü dönebilmektir.
Son olarak tedarikçi ve eklenti bağımlılıkları izlenmelidir. cPanel tek başına güncel olsa bile kullanılan yedek eklentisi, güvenlik eklentisi, site builder veya özel lisans modülü eski kalabilir. Her bakımda üçüncü parti bileşenlerin sürümü ve destek durumu da kısa listede yer almalıdır.
Bu yaklaşım zamanla firmanın standart hizmet kalitesine dönüşür. Yeni sunucu kurulurken aynı checklist uygulanır, migration sonrası aynı kontroller yapılır, kritik duyuru geldiğinde aynı prosedür işletilir. Böylece güvenlik kişisel hafızaya değil, tekrar edilebilir operasyon düzenine dayanır.
Güvenlik sertleştirmesi bir defa yapılıp unutulan bir proje değildir. Her yeni müşteri, her yeni eklenti ve her yeni otomasyon bu standarda göre değerlendirilmelidir. Böyle bakıldığında cPanel sunucusu yalnızca güncel değil, yönetilebilir ve denetlenebilir hale gelir.
Denetlenebilirlik, güvenliğin pratikte sürdürülebilir olmasını sağlar.
Sonuç
cPanel sunucuları için 2026 güvenlik standardı; güncel sürüm, kısıtlı yönetim erişimi, zorunlu 2FA, minimum yetkili API tokenları, doğru dosya izinleri, sağlıklı mail izleme, güvenilir yedekler ve düzenli log analizinden oluşur. CVE duyuruları bu sürecin acil tetikleyicisidir, fakat güvenlik yalnızca CVE çıktığında yapılacak iş değildir. Bugün kurulan disiplin, bir sonraki kritik duyuruda sunucunun panikle değil prosedürle korunmasını sağlar.