Kısa cevap: Linux sunucu güvenliği; tek bir firewall kuralı veya SSL sertifikasıyla tamamlanmaz. Güvenli bir yapı için desteklenen işletim sistemi, zamanında güncelleme, anahtar tabanlı SSH, en az yetki, yalnız gerekli portlar, uygulama ve veritabanı izolasyonu, uçtan uca TLS, doğru CDN/origin ayarı, merkezi log, izleme ve test edilmiş harici yedek birlikte uygulanmalıdır. Önce varlık ve risk envanteri çıkarın, sonra değişiklikleri aşamalı ve geri dönüş planıyla devreye alın.
İnternete açık bir sunucunun saldırı yüzeyi; işletim sistemi, kontrol paneli, web sunucusu, PHP veya uygulama çalışma zamanı, veri tabanı, yönetim portları, DNS, CDN ve üçüncü taraf eklentilerden oluşur. Bu nedenle sunucu güvenliği bir ürün değil, sürekli işletilen bir süreçtir. Aşağıdaki rehber, VPS/VDS, dedicated veya cloud sunucuda uygulanabilecek savunma katmanlarını soru-cevap mantığıyla açıklar.
İlk adım, sunucuda neyin çalıştığını ve kimin eriştiğini bilmektir. İşletim sistemi sürümü, açık portlar, çalışan servisler, alan adları, sertifikalar, yönetici hesapları, veri tabanları, yedek hedefleri ve dış entegrasyonlar belgelenmelidir. Sahibi bilinmeyen servis güvenli biçimde güncellenemez; amacı bilinmeyen port ise kapatılamaz.
İnternete açık varlıkları önem sırasına koyun. Müşteri verisi, ödeme veya kimlik bilgisi işleyen sistemler; yalnızca tanıtım sayfası sunan makinelerden daha sıkı kontrol ister. Geliştirme, test ve üretim ortamlarını ayırın. Aynı parola, özel anahtar veya veri tabanı hesabını ortamlar arasında kullanmayın.
Güvenlik güncellemesi almayan bir dağıtımda yeni açıklar bilinse bile düzeltme paketi gelmeyebilir. Bu nedenle destek yaşam döngüsü devam eden bir LTS veya eşdeğer kararlı sürüm seçin ve bitiş tarihini takvime ekleyin. Büyük sürüm yükseltmesini son haftaya bırakmak; uygulama, panel ve paket uyumsuzluğu riskini büyütür.
Ubuntu’nun resmî belgelerine göre
İnternete açık sistemlerde güvenlik yamalarının gecikmesi ciddi risktir; buna rağmen üretimde kontrolsüz yeniden başlatma da kesinti yaratabilir. Kritik uygulamalarda yamayı önce benzer test ortamında doğrulayın, yedek ve geri dönüş planını hazırlayın, ardından belirlenmiş bakım penceresinde uygulayın. Güncelleme politikası “otomatik mi manuel mi” sorusundan çok, ne kadar sürede güvenle uygulanacağıyla ölçülmelidir.
Günlük yönetim için doğrudan root hesabı yerine adı ayrı, yetkisi sınırlı bir kullanıcı oluşturun; yalnız gerekli komutlar için kontrollü yetki yükseltin. Parola yerine güçlü anahtar tabanlı kimlik doğrulama kullanın. Özel anahtarı cihazda koruyun, ekipten ayrılan kişinin anahtarını gecikmeden kaldırın ve yönetici erişimlerini periyodik olarak gözden geçirin.
SSH portunu değiştirmek otomatik tarama gürültüsünü azaltabilir, fakat temel güvenlik kontrolü değildir. Asıl savunma; parola girişini kısıtlamak, root ile doğrudan oturumu kapatmak, erişimi izinli IP/VPN ağıyla sınırlandırmak, başarısız girişleri oranlamak ve loglamaktır. Kontrol paneli ve sağlayıcı hesabında destekleniyorsa phishing’e dayanıklı MFA kullanın.
Mevcut oturumu kapatmadan ikinci bir terminalde yeni ayarı test edin. Firewall kuralını, SSH yapılandırmasını ve sağlayıcının konsol/kurtarma erişimini birlikte doğrulayın. Tek çalışan oturumu kapatıp sonra denemek, uzaktan erişimi kaybetmenize yol açabilir.
Varsayılan yaklaşım, ihtiyaç duyulmayan inbound trafiği reddetmek ve yalnız belgelenmiş servisleri açmaktır. Web sunucusunda genellikle 80 ve 443; yönetimde ise sınırlandırılmış SSH erişimi gerekir. Veri tabanı, Redis, kontrol paneli ve izleme portlarını zorunlu değilse doğrudan internete açmayın.
Ubuntu belgeleri, host tabanlı firewall için
Firewall kuralı eklemeden önce geri dönüş erişimini doğrulayın. Kural listesini periyodik denetleyin; geçici bakım için açılan portları kalıcı bırakmayın. IPv6 etkinse kuralların IPv4 kadar IPv6 trafiğini de kapsadığını kontrol edin.
Her uygulama ayrı sistem kullanıcısıyla çalışmalı, dosya ve dizin izinleri yalnız gerekli okuma-yazma yetkisini vermelidir. Web sunucusu kullanıcısına tüm proje üzerinde yazma izni tanımak; bir uygulama açığını sistem geneline taşıyabilir. Yükleme dizini, uygulama kodu, gizli yapılandırma ve log dizinleri farklı izinlerle yönetilmelidir.
Veri tabanında uygulama hesabına yalnız kullandığı şema ve işlemler için yetki verin. Yedekleme hesabı, uygulama hesabı ve insan yöneticisi aynı kullanıcı olmamalıdır. API anahtarlarını ve parolaları kaynak koduna ya da herkese açık depoya koymayın; sır yönetim sistemi veya erişimi sınırlı ortam değişkenleri kullanın.
Hayır. SSL/TLS, istemci ile sunucu arasındaki veriyi şifreler ve doğru sertifika kullanıldığında bağlanılan alan adını doğrular. Zararlı eklentiyi, zayıf parolayı, SQL injection’ı veya yetki hatasını çözmez. HTTPS güvenli taşıma katmanıdır; uygulama güvenliğinin yerine geçmez.
Sertifika alan adını kapsamalı, güvenilir otorite tarafından verilmiş olmalı, zinciri eksiksiz sunulmalı ve süresi dolmadan yenilenmelidir. HTTP isteklerini HTTPS’e yönlendirin; mixed content, eski TLS sürümleri ve hatalı yönlendirme döngülerini test edin. Otomatik yenilemeyi kurmak yeterli değildir: yenileme denemesini, sertifika yükleme işlemini ve son kullanma tarihini dışarıdan izleyin.
HSTS, tarayıcıya alan adına yalnız HTTPS üzerinden bağlanmasını söyler. OWASP güvenlik başlıkları rehberinde HSTS yanında Content-Security-Policy ve çerçeveleme kontrolleri gibi başlıklar da ele alınır. HSTS’yi tüm alt alan adlarına ve preload seçeneğine yaymadan önce her alt alanın kalıcı HTTPS desteğini doğrulayın; aceleci ayar geri dönüşü zor erişim sorunları yaratabilir.
CDN mimarisinde iki ayrı bağlantı vardır: ziyaretçiden CDN kenarına ve CDN’den origin sunucuya. Yalnız ilk bağlantıyı şifrelemek yeterli değildir. Cloudflare’ın resmî belgeleri, mümkün olduğunda origin sertifikasını doğrulayan Full (strict) modunu önerir; origin sertifikası geçerli, süresi dolmamış ve hedef alan adıyla eşleşmiş olmalıdır.
Flexible benzeri yalnız kenarda şifreleme yapan modlar, origin’e giden trafiği açık bırakabilir ve HTTPS yönlendirme döngülerine neden olabilir. CDN kullanmak origin sunucuyu otomatik olarak gizlemez. Eski DNS kayıtları, e-posta başlıkları veya doğrudan servisler origin IP’yi açığa çıkarabilir.
Origin yalnız CDN ağlarından gelen web trafiğini kabul edecek şekilde sınırlandırılabilir. Sağlayıcı destekliyorsa Authenticated Origin Pulls veya benzeri mTLS mekanizması, isteğin CDN’den geldiğini ayrıca doğrular. Doğrudan yönetim erişimi VPN, bastion veya izinli IP üzerinden yapılmalıdır. CDN IP listeleri değişebileceği için kural güncelleme yöntemi belgelenmelidir.
Hayır. CDN statik veya uygun dinamik içeriği kenarda önbelleğe alarak origin yükünü azaltır. WAF, HTTP isteklerini kurallara göre inceler. DDoS koruması ise hacimsel veya protokol tabanlı saldırı trafiğini soğurmayı ve filtrelemeyi hedefler. Hizmet sağlayıcının paketinde hangi katmanların, ne kapasite ve hangi kural yönetimiyle sunulduğu okunmalıdır.
Yanlış cache ayarı kişiye özel sayfaların başka kullanıcılara gösterilmesine yol açabilir. Oturum, sepet, yönetim ve API uçlarında cache anahtarlarını dikkatle tanımlayın. WAF kurallarını önce log veya simülasyon modunda gözlemleyip yanlış pozitifleri azaltın; sonra engellemeyi kademeli açın.
CPU, RAM ve disk kullanımının yanında disk gecikmesi, inode, ağ hatası, HTTP 5xx, uygulama istisnası, veri tabanı bağlantısı, sertifika süresi, yedek sonucu ve yetkisiz giriş denemeleri izlenmelidir. Sadece “sunucu ayakta mı?” kontrolü, yavaşlama veya veri bütünlüğü sorununu kaçırabilir.
Logların saati senkron olmalı ve kritik kayıtlar saldırganın kolayca silemeyeceği merkezi hedefe gönderilmelidir. Hassas veri, parola, token veya oturum çerezi loglanmamalıdır. Alarm eşikleri normal trafik profilinden türetilmeli; her uyarı için sorumlu, iletişim yolu ve ilk müdahale adımı tanımlanmalıdır.
Yedek, aynı sunucudaki başka klasör veya yalnızca anlık snapshot değildir. CISA’nın ransomware rehberi; kritik verilerin çevrimdışı veya saldırgandan ayrı tutulabilen, şifreli yedeklerini ve düzenli geri yükleme testini önerir. Veritabanı tutarlılığı, dosyalar, yapılandırma, sertifika bilgileri ve gerekli sırlar ayrı ayrı planlanmalıdır.
Yedekleme başarısı, dosyanın oluşmasıyla değil geri yüklemenin çalışmasıyla kanıtlanır. RPO ile ne kadar veri kaybının kabul edileceğini, RTO ile hizmetin ne sürede dönmesi gerektiğini belirleyin. Farklı yetki alanında kopya, değiştirilemez saklama, sürümleme ve silme koruması fidye yazılımına karşı dayanıklılığı artırabilir.
1. İşletim sistemi, servis, port, alan adı, kullanıcı ve veri envanterini çıkarın.
2. Desteklenen sürüm kullanın; yamaları risk ve bakım penceresine göre zamanında uygulayın.
3. Root günlük kullanımını bırakın; SSH anahtarı, en az yetki ve MFA uygulayın.
4. Yalnız gerekli portları açın; veri tabanı ve yönetim panellerini internete doğrudan sunmayın.
5. Uygulama kullanıcılarını, dosya izinlerini ve sırları birbirinden ayırın.
6. HTTPS’i uçtan uca kurun; sertifika yenilemesini ve süresini izleyin.
7. CDN origin’ini doğrulayın, doğrudan erişimi sınırlandırın ve cache/WAF kurallarını test edin.
8. Merkezi log, performans izlemesi ve eyleme dönük alarmlar oluşturun.
9. Harici, şifreli ve tercihen değiştirilemez yedek tutun; geri yüklemeyi düzenli test edin.
10. Olay müdahalesi, iletişim, izolasyon ve kurtarma adımlarını yazılı hâle getirin.
Desteklenen sistemi güncellemek, SSH erişimini anahtar ve en az yetkiyle sınırlandırmak, firewall’da yalnız gerekli portları açık bırakmak güçlü bir başlangıçtır. Ardından izleme ve test edilmiş yedek kurulmalıdır.
Panel yönetimi kolaylaştırır ve bazı güvenlik özellikleri sağlar; fakat panelin kendisi de güncellenmesi, erişimi sınırlandırılması ve MFA ile korunması gereken bir bileşendir. Varsayılan ayarlar her iş yükü için yeterli kabul edilmemelidir.
Güvenilir bir sertifika otoritesinden alınmış ve doğru kurulmuş ücretsiz sertifika, bağlantı şifrelemesi ve alan adı doğrulaması açısından yeterli olabilir. Güvenlik, fiyat yerine anahtar koruması, zincir, yenileme ve doğru TLS yapılandırmasına bağlıdır.
Hayır. Eski DNS kayıtları, e-posta servisleri veya yanlış yapılandırılmış alt alanlar origin IP’yi açığa çıkarabilir. Origin firewall’u yalnız CDN ağlarını kabul etmeli ve doğrudan erişim ayrıca sınırlandırılmalıdır.
Genellikle hayır. Snapshot aynı hesap veya altyapı arızasından etkilenebilir ve uygulama açısından tutarlı olmayabilir. Ayrı konumda, farklı yetkiyle korunan ve geri yüklemesi denenmiş yedek gerekir.
Güvenli sunucu; tek sefer sertleştirilip unutulan değil, envanteri güncel tutulan, değişiklikleri kontrollü yapılan, yamaları geciktirilmeyen ve davranışı izlenen sunucudur. SSL/TLS, CDN, WAF ve DDoS koruması savunmayı katmanlandırır; fakat zayıf kimlik doğrulama, fazla yetki veya test edilmemiş yedek gibi temel açıkları telafi etmez.
En iyi güvenlik planı önleme, tespit, müdahale ve kurtarmayı birlikte tasarlar. Her değişiklikten önce yedek ve geri dönüş yolunu doğrulayın; kritik olay yaşanmadan önce kimin ne yapacağını belirleyin.
Ubuntu Server: Security Suggestions
Ubuntu Server: Automatic Updates
Ubuntu Server: Firewall
Cloudflare: Full (strict) SSL/TLS
OWASP Secure Headers Project
CISA: StopRansomware Guide
İnternete açık bir sunucunun saldırı yüzeyi; işletim sistemi, kontrol paneli, web sunucusu, PHP veya uygulama çalışma zamanı, veri tabanı, yönetim portları, DNS, CDN ve üçüncü taraf eklentilerden oluşur. Bu nedenle sunucu güvenliği bir ürün değil, sürekli işletilen bir süreçtir. Aşağıdaki rehber, VPS/VDS, dedicated veya cloud sunucuda uygulanabilecek savunma katmanlarını soru-cevap mantığıyla açıklar.
Linux sunucu güvenliği nereden başlamalı?
İlk adım, sunucuda neyin çalıştığını ve kimin eriştiğini bilmektir. İşletim sistemi sürümü, açık portlar, çalışan servisler, alan adları, sertifikalar, yönetici hesapları, veri tabanları, yedek hedefleri ve dış entegrasyonlar belgelenmelidir. Sahibi bilinmeyen servis güvenli biçimde güncellenemez; amacı bilinmeyen port ise kapatılamaz.İnternete açık varlıkları önem sırasına koyun. Müşteri verisi, ödeme veya kimlik bilgisi işleyen sistemler; yalnızca tanıtım sayfası sunan makinelerden daha sıkı kontrol ister. Geliştirme, test ve üretim ortamlarını ayırın. Aynı parola, özel anahtar veya veri tabanı hesabını ortamlar arasında kullanmayın.
Desteklenen işletim sistemi neden önemlidir?
Güvenlik güncellemesi almayan bir dağıtımda yeni açıklar bilinse bile düzeltme paketi gelmeyebilir. Bu nedenle destek yaşam döngüsü devam eden bir LTS veya eşdeğer kararlı sürüm seçin ve bitiş tarihini takvime ekleyin. Büyük sürüm yükseltmesini son haftaya bırakmak; uygulama, panel ve paket uyumsuzluğu riskini büyütür.Ubuntu’nun resmî belgelerine göre
unattended-upgrades
Otomatik güncelleme her sunucuda açılmalı mı?
İnternete açık sistemlerde güvenlik yamalarının gecikmesi ciddi risktir; buna rağmen üretimde kontrolsüz yeniden başlatma da kesinti yaratabilir. Kritik uygulamalarda yamayı önce benzer test ortamında doğrulayın, yedek ve geri dönüş planını hazırlayın, ardından belirlenmiş bakım penceresinde uygulayın. Güncelleme politikası “otomatik mi manuel mi” sorusundan çok, ne kadar sürede güvenle uygulanacağıyla ölçülmelidir.
SSH erişimi nasıl güvenli hâle getirilir?
Günlük yönetim için doğrudan root hesabı yerine adı ayrı, yetkisi sınırlı bir kullanıcı oluşturun; yalnız gerekli komutlar için kontrollü yetki yükseltin. Parola yerine güçlü anahtar tabanlı kimlik doğrulama kullanın. Özel anahtarı cihazda koruyun, ekipten ayrılan kişinin anahtarını gecikmeden kaldırın ve yönetici erişimlerini periyodik olarak gözden geçirin.SSH portunu değiştirmek otomatik tarama gürültüsünü azaltabilir, fakat temel güvenlik kontrolü değildir. Asıl savunma; parola girişini kısıtlamak, root ile doğrudan oturumu kapatmak, erişimi izinli IP/VPN ağıyla sınırlandırmak, başarısız girişleri oranlamak ve loglamaktır. Kontrol paneli ve sağlayıcı hesabında destekleniyorsa phishing’e dayanıklı MFA kullanın.
SSH ayarı değişirken kilitlenme nasıl önlenir?
Mevcut oturumu kapatmadan ikinci bir terminalde yeni ayarı test edin. Firewall kuralını, SSH yapılandırmasını ve sağlayıcının konsol/kurtarma erişimini birlikte doğrulayın. Tek çalışan oturumu kapatıp sonra denemek, uzaktan erişimi kaybetmenize yol açabilir.
Firewall ve açık port yönetimi nasıl yapılır?
Varsayılan yaklaşım, ihtiyaç duyulmayan inbound trafiği reddetmek ve yalnız belgelenmiş servisleri açmaktır. Web sunucusunda genellikle 80 ve 443; yönetimde ise sınırlandırılmış SSH erişimi gerekir. Veri tabanı, Redis, kontrol paneli ve izleme portlarını zorunlu değilse doğrudan internete açmayın.Ubuntu belgeleri, host tabanlı firewall için
ufwFirewall kuralı eklemeden önce geri dönüş erişimini doğrulayın. Kural listesini periyodik denetleyin; geçici bakım için açılan portları kalıcı bırakmayın. IPv6 etkinse kuralların IPv4 kadar IPv6 trafiğini de kapsadığını kontrol edin.
En az yetki ilkesi sunucuda nasıl uygulanır?
Her uygulama ayrı sistem kullanıcısıyla çalışmalı, dosya ve dizin izinleri yalnız gerekli okuma-yazma yetkisini vermelidir. Web sunucusu kullanıcısına tüm proje üzerinde yazma izni tanımak; bir uygulama açığını sistem geneline taşıyabilir. Yükleme dizini, uygulama kodu, gizli yapılandırma ve log dizinleri farklı izinlerle yönetilmelidir.Veri tabanında uygulama hesabına yalnız kullandığı şema ve işlemler için yetki verin. Yedekleme hesabı, uygulama hesabı ve insan yöneticisi aynı kullanıcı olmamalıdır. API anahtarlarını ve parolaları kaynak koduna ya da herkese açık depoya koymayın; sır yönetim sistemi veya erişimi sınırlı ortam değişkenleri kullanın.
SSL sertifikası siteyi tamamen güvenli yapar mı?
Hayır. SSL/TLS, istemci ile sunucu arasındaki veriyi şifreler ve doğru sertifika kullanıldığında bağlanılan alan adını doğrular. Zararlı eklentiyi, zayıf parolayı, SQL injection’ı veya yetki hatasını çözmez. HTTPS güvenli taşıma katmanıdır; uygulama güvenliğinin yerine geçmez.Sertifika alan adını kapsamalı, güvenilir otorite tarafından verilmiş olmalı, zinciri eksiksiz sunulmalı ve süresi dolmadan yenilenmelidir. HTTP isteklerini HTTPS’e yönlendirin; mixed content, eski TLS sürümleri ve hatalı yönlendirme döngülerini test edin. Otomatik yenilemeyi kurmak yeterli değildir: yenileme denemesini, sertifika yükleme işlemini ve son kullanma tarihini dışarıdan izleyin.
HSTS ne zaman açılmalıdır?
HSTS, tarayıcıya alan adına yalnız HTTPS üzerinden bağlanmasını söyler. OWASP güvenlik başlıkları rehberinde HSTS yanında Content-Security-Policy ve çerçeveleme kontrolleri gibi başlıklar da ele alınır. HSTS’yi tüm alt alan adlarına ve preload seçeneğine yaymadan önce her alt alanın kalıcı HTTPS desteğini doğrulayın; aceleci ayar geri dönüşü zor erişim sorunları yaratabilir.
CDN kullanırken SSL/TLS nasıl ayarlanmalı?
CDN mimarisinde iki ayrı bağlantı vardır: ziyaretçiden CDN kenarına ve CDN’den origin sunucuya. Yalnız ilk bağlantıyı şifrelemek yeterli değildir. Cloudflare’ın resmî belgeleri, mümkün olduğunda origin sertifikasını doğrulayan Full (strict) modunu önerir; origin sertifikası geçerli, süresi dolmamış ve hedef alan adıyla eşleşmiş olmalıdır.Flexible benzeri yalnız kenarda şifreleme yapan modlar, origin’e giden trafiği açık bırakabilir ve HTTPS yönlendirme döngülerine neden olabilir. CDN kullanmak origin sunucuyu otomatik olarak gizlemez. Eski DNS kayıtları, e-posta başlıkları veya doğrudan servisler origin IP’yi açığa çıkarabilir.
Origin sunucu nasıl korunur?
Origin yalnız CDN ağlarından gelen web trafiğini kabul edecek şekilde sınırlandırılabilir. Sağlayıcı destekliyorsa Authenticated Origin Pulls veya benzeri mTLS mekanizması, isteğin CDN’den geldiğini ayrıca doğrular. Doğrudan yönetim erişimi VPN, bastion veya izinli IP üzerinden yapılmalıdır. CDN IP listeleri değişebileceği için kural güncelleme yöntemi belgelenmelidir.
CDN, WAF ve DDoS koruması aynı şey mi?
Hayır. CDN statik veya uygun dinamik içeriği kenarda önbelleğe alarak origin yükünü azaltır. WAF, HTTP isteklerini kurallara göre inceler. DDoS koruması ise hacimsel veya protokol tabanlı saldırı trafiğini soğurmayı ve filtrelemeyi hedefler. Hizmet sağlayıcının paketinde hangi katmanların, ne kapasite ve hangi kural yönetimiyle sunulduğu okunmalıdır.Yanlış cache ayarı kişiye özel sayfaların başka kullanıcılara gösterilmesine yol açabilir. Oturum, sepet, yönetim ve API uçlarında cache anahtarlarını dikkatle tanımlayın. WAF kurallarını önce log veya simülasyon modunda gözlemleyip yanlış pozitifleri azaltın; sonra engellemeyi kademeli açın.
Sunucu logları ve izleme sistemi neyi takip etmeli?
CPU, RAM ve disk kullanımının yanında disk gecikmesi, inode, ağ hatası, HTTP 5xx, uygulama istisnası, veri tabanı bağlantısı, sertifika süresi, yedek sonucu ve yetkisiz giriş denemeleri izlenmelidir. Sadece “sunucu ayakta mı?” kontrolü, yavaşlama veya veri bütünlüğü sorununu kaçırabilir.Logların saati senkron olmalı ve kritik kayıtlar saldırganın kolayca silemeyeceği merkezi hedefe gönderilmelidir. Hassas veri, parola, token veya oturum çerezi loglanmamalıdır. Alarm eşikleri normal trafik profilinden türetilmeli; her uyarı için sorumlu, iletişim yolu ve ilk müdahale adımı tanımlanmalıdır.
Sunucu yedeği nasıl güvenli planlanır?
Yedek, aynı sunucudaki başka klasör veya yalnızca anlık snapshot değildir. CISA’nın ransomware rehberi; kritik verilerin çevrimdışı veya saldırgandan ayrı tutulabilen, şifreli yedeklerini ve düzenli geri yükleme testini önerir. Veritabanı tutarlılığı, dosyalar, yapılandırma, sertifika bilgileri ve gerekli sırlar ayrı ayrı planlanmalıdır.Yedekleme başarısı, dosyanın oluşmasıyla değil geri yüklemenin çalışmasıyla kanıtlanır. RPO ile ne kadar veri kaybının kabul edileceğini, RTO ile hizmetin ne sürede dönmesi gerektiğini belirleyin. Farklı yetki alanında kopya, değiştirilemez saklama, sürümleme ve silme koruması fidye yazılımına karşı dayanıklılığı artırabilir.
Sunucu güvenliği kontrol listesi
1. İşletim sistemi, servis, port, alan adı, kullanıcı ve veri envanterini çıkarın.2. Desteklenen sürüm kullanın; yamaları risk ve bakım penceresine göre zamanında uygulayın.
3. Root günlük kullanımını bırakın; SSH anahtarı, en az yetki ve MFA uygulayın.
4. Yalnız gerekli portları açın; veri tabanı ve yönetim panellerini internete doğrudan sunmayın.
5. Uygulama kullanıcılarını, dosya izinlerini ve sırları birbirinden ayırın.
6. HTTPS’i uçtan uca kurun; sertifika yenilemesini ve süresini izleyin.
7. CDN origin’ini doğrulayın, doğrudan erişimi sınırlandırın ve cache/WAF kurallarını test edin.
8. Merkezi log, performans izlemesi ve eyleme dönük alarmlar oluşturun.
9. Harici, şifreli ve tercihen değiştirilemez yedek tutun; geri yüklemeyi düzenli test edin.
10. Olay müdahalesi, iletişim, izolasyon ve kurtarma adımlarını yazılı hâle getirin.
Sık sorulan sorular
Linux sunucu güvenliği için ilk üç adım nedir?
Desteklenen sistemi güncellemek, SSH erişimini anahtar ve en az yetkiyle sınırlandırmak, firewall’da yalnız gerekli portları açık bırakmak güçlü bir başlangıçtır. Ardından izleme ve test edilmiş yedek kurulmalıdır.
cPanel veya Plesk kullanmak sunucuyu güvenli yapar mı?
Panel yönetimi kolaylaştırır ve bazı güvenlik özellikleri sağlar; fakat panelin kendisi de güncellenmesi, erişimi sınırlandırılması ve MFA ile korunması gereken bir bileşendir. Varsayılan ayarlar her iş yükü için yeterli kabul edilmemelidir.
Ücretsiz SSL sertifikası güvenli midir?
Güvenilir bir sertifika otoritesinden alınmış ve doğru kurulmuş ücretsiz sertifika, bağlantı şifrelemesi ve alan adı doğrulaması açısından yeterli olabilir. Güvenlik, fiyat yerine anahtar koruması, zincir, yenileme ve doğru TLS yapılandırmasına bağlıdır.
CDN sunucunun gerçek IP adresini tamamen gizler mi?
Hayır. Eski DNS kayıtları, e-posta servisleri veya yanlış yapılandırılmış alt alanlar origin IP’yi açığa çıkarabilir. Origin firewall’u yalnız CDN ağlarını kabul etmeli ve doğrudan erişim ayrıca sınırlandırılmalıdır.
Snapshot yedek yerine geçer mi?
Genellikle hayır. Snapshot aynı hesap veya altyapı arızasından etkilenebilir ve uygulama açısından tutarlı olmayabilir. Ayrı konumda, farklı yetkiyle korunan ve geri yüklemesi denenmiş yedek gerekir.
Sonuç: Güvenli sunucu nasıl yönetilir?
Güvenli sunucu; tek sefer sertleştirilip unutulan değil, envanteri güncel tutulan, değişiklikleri kontrollü yapılan, yamaları geciktirilmeyen ve davranışı izlenen sunucudur. SSL/TLS, CDN, WAF ve DDoS koruması savunmayı katmanlandırır; fakat zayıf kimlik doğrulama, fazla yetki veya test edilmemiş yedek gibi temel açıkları telafi etmez.En iyi güvenlik planı önleme, tespit, müdahale ve kurtarmayı birlikte tasarlar. Her değişiklikten önce yedek ve geri dönüş yolunu doğrulayın; kritik olay yaşanmadan önce kimin ne yapacağını belirleyin.
Resmî kaynaklar
Ubuntu Server: Security SuggestionsUbuntu Server: Automatic Updates
Ubuntu Server: Firewall
Cloudflare: Full (strict) SSL/TLS
OWASP Secure Headers Project
CISA: StopRansomware Guide