Çoğu işletme sahibi sunucu güvenliğini barındırma firmasının işi sanır. "Güvenlik duvarı var mı?" diye sorar, "var" cevabını alır ve konuyu kapatır. Oysa sana teslim edilen makine, üzerinde varsayılan ayarlar duran, her portu dinleyen, kök kullanıcıya şifreyle giriş kabul eden bir kutudur. Firmanın sorumluluğu kablonun ucunda biter; o kutunun içi senin.
İkinci yaygın yanılgı şudur: "kodum güvenliyse sunucu önemsizdir." Tam tersi. Mükemmel yazılmış bir e-pin satış scripti, aynı sunucuda duran eski bir test dosyası yüzünden ele geçirilebilir. Saldırgan senin sipariş mantığını kırmakla uğraşmaz; yan kapıdan girer, veri tabanı bağlantı bilgilerini okur ve stokunu doğrudan tablodan boşaltır. Bu yazıda dijital kod satan bir sistemin altındaki sunucuyu sertleştirmek için sırayla uygulanacak adımları, her adımın neyi durdurduğunu söyleyerek veriyorum.
Erişim kapısını hâlâ şifreyle mi açıyorsun?
Sertleştirmenin ilk maddesi her zaman erişimdir, çünkü diğer kırk maddenin hepsi bu kapı açıksa boşa gider. Sunucuya şifreyle SSH girişi kapatılır, yerine anahtar tabanlı kimlik doğrulama konur. Kök kullanıcının doğrudan girişi kapatılır; kendi kullanıcınla girip yetki yükseltirsin. SSH portu değiştirilir; bu tek başına güvenlik değildir ama kayıtlarını gürültüden temizler, böylece gerçek saldırıyı görürsün.
Yönetim panelin ve veri tabanı arayüzün internete açık durmamalı. Bunlar ya IP kısıtlı olmalı ya da bir tünelin arkasında durmalı. Bir de terk edilmiş kullanıcılar var: eski çalışanın, eski geliştiricinin, kurulum sırasında açılan test hesabının hâlâ yaşıyor olması en sık atlanan maddedir. Üç ayda bir kullanıcı listesini okumak, pahalı hiçbir ürünün sağlayamadığı bir koruma sağlar.
Sunucun kaç kapıyı boşuna dinliyor?
Varsayılan kurulumda makinen ihtiyacın olmayan bir sürü servisi dinler. Kural nettir: ne kullanmıyorsan kapat, kullandığını da yalnız gereken yere aç. Web trafiği dışarıya açık; veri tabanı yalnız yerel arayüze; önbellek servisi yalnız yerel arayüze; yönetim erişimi yalnız senin IP bloğuna.
Güvenlik duvarını kurarken varsayılan politikayı "reddet" yapıp istisnaları tek tek eklemek, "kabul et" deyip yasakları saymaktan kat kat güvenlidir. Bunun üstüne önbelleğe alan bir ara katman koyup asıl sunucunun IP adresini gizlersen, doğrudan hedefli taramaların önemli kısmını hiç karşılamazsın. Dijital ürün satış scripti çalıştıran sistemlerde bu adım özellikle önemlidir; çünkü tedarikçi API'sine giden trafiğin kaynağı belliyse saldırgan taklit etmeyi de kolay bulur.
| Sertleştirme alanı | Yapılacak | Neyi durdurur | Süre | Öncelik |
|---|---|---|---|---|
| SSH erişimi | Anahtar zorunlu, kök girişi kapalı | Kaba kuvvet ve şifre sızıntısı | 20 dk | 1 |
| Güvenlik duvarı | Varsayılan reddet, istisna listesi | Açık servis taraması | 30 dk | 1 |
| Veri tabanı bağlantısı | Yalnız yerel arayüz, dar yetkili kullanıcı | Doğrudan tablo okuma | 25 dk | 1 |
| Dosya izinleri | Yazılabilir dizin sayısını en aza indirmek | Yüklenen dosyanın çalıştırılması | 40 dk | 2 |
| PHP yapılandırması | Tehlikeli fonksiyonları kapatmak, hata gösterimini kapatmak | Komut çalıştırma ve bilgi sızması | 30 dk | 2 |
| Yedekleme | Sunucu dışına şifreli kopya | Fidye ve toplu silme | 60 dk | 1 |
| Kayıt izleme | Merkezî kayıt ve uyarı kuralları | Fark edilmeyen uzun süreli erişim | 90 dk | 2 |
| Gereksiz dosyalar | Test, yedek arşivi, kurulum dizini silme | Unutulmuş yan kapı | 20 dk | 1 |
Yazılabilir dizinler neden en sessiz felaket?
Dosya izinleri sıkıcı bir konudur ve tam bu yüzden kimse dokunmaz. Kod satan bir panelde yüklenen görsellerin, fatura çıktılarının, geçici dosyaların durduğu dizinlerin yazılabilir olması gerekir; ama yazılabilir olan dizinde çalıştırma yetkisi bulunmamalıdır. Bu iki şeyi ayırmazsan, dosya yükleme alanına sızan tek bir betik sunucunun tamamına komut çalıştırma imkânı verir.
Aynı mantık kaynak koda da uygulanır. Uygulama dosyalarının web sunucusu kullanıcısı tarafından yazılabilir olması, güncelleme kolaylığı gibi görünen ama kalıcı bir açık bırakan bir tercihtir. Yapılandırma dosyası, özellikle veri tabanı ve API anahtarlarını tutan dosya, web kökünün dışında durmalı ve yalnız gereken kullanıcı tarafından okunabilmelidir. İyi kurulmuş bir e-pin yazılımı bu ayrımı kurulum aşamasında zorlar; zorlamıyorsa sen elle yapmak zorundasın.
Sunucu ele geçirme yollarının dağılımı
- Zayıf SSH veya panel erişimi 40%
- Güncellenmemiş servis 30%
- Gereksiz açık servis ve port 20%
- Hatalı dosya izinleri 10%
Sırlarını nerede tutuyorsun?
E-pin işinde sırlar sadece şifre değildir: tedarikçi API anahtarı, ödeme sağlayıcı gizli anahtarı, webhook imza anahtarı ve varsa kod şifreleme anahtarı. Bunların hepsi tek bir dosyada, web kökü içinde, sürüm kontrolüne de girmiş halde duruyorsa ihlal bir zaman sorunudur. Sırlar web kökü dışında, dar izinli bir dosyada veya ortam değişkenlerinde tutulur; sürüm kontrolüne asla girmez.
Bir de rotasyon var. Bir çalışan ayrıldığında, bir geliştiriciye geçici erişim verildiğinde veya bir yedek dosyası dışarı çıktığında anahtarların değiştirilmesi gerekir. Bunun için önce bir liste tutman şart: hangi anahtar nerede duruyor, ne zaman oluşturuldu, kim biliyor. Liste yoksa rotasyon da yapılamaz, çünkü neyi değiştireceğini bilemezsin.
Bugün beş dakika ayır ve web kökünde şu uzantıları ara: yedek arşivleri, veri tabanı dökümleri, eski kurulum dizinleri ve bilgi yazdıran test dosyaları. Bulduğun her birini sil veya dışarı taşı; bu tek tarama çoğu sitede en az bir ciddi bulgu verir.
Bir şey olduğunu nasıl fark edeceksin?
Sertleştirme, saldırıyı imkânsız kılmaz; zorlaştırır ve gürültü çıkarır. O gürültüyü duyacak bir kulak kurmadıysan sertleştirmenin yarısını yapmış olursun. En az şunlar izlenmeli: başarısız giriş denemeleri, yönetim paneline yapılan başarılı girişler, uygulama dosyalarındaki değişiklikler, beklenmedik giden ağ bağlantıları ve sipariş-bakiye kayıtlarındaki sıra dışı hareketler.
Uyarıları tek bir yere, örneğin bir mesajlaşma kanalına düşürmek işi sürdürülebilir kılar. Kural sayısını az tut ki uyarıya duyarsız kalmayasın: gece yarısı yönetim girişi, bir saatte beşten fazla iade, yeni bir kök yetkili kullanıcı, uygulama dosyasında değişiklik. Dört kural, kimsenin okumadığı kırk kuraldan iyidir. Kullandığın e-pin satış yazılımı bakiye ve sipariş hareketleri için değiştirilemez bir kayıt tutuyorsa bu uyarıları kurmak çok daha kolaydır; tutmuyorsa olaydan sonra ne olduğunu asla tam çözemezsin.
| Kontrol maddesi | Durum ölçütü | Sıklık | Atlanırsa |
|---|---|---|---|
| Şifreli SSH girişi kapalı | Yapılandırmada parola girişi kapalı | Bir kez + denetim | Kaba kuvvet kapıyı bulur |
| Kullanılmayan servisler kapalı | Dinleyen port listesi beklenenle aynı | Aylık | Tarama yan kapı bulur |
| Yapılandırma web kökü dışında | Anahtar dosyası tarayıcıdan erişilemez | Her kurulumda | Anahtarlar okunur |
| Yazılabilir dizinde çalıştırma kapalı | Yüklenen betik çalışmıyor | Her kurulumda | Uzaktan komut çalıştırma |
| Yedek sunucu dışında ve şifreli | Geri yükleme testi başarılı | Üç aylık | Fidye karşısında seçenek yok |
| Yönetim paneli IP kısıtlı | Dış IP'den erişim reddediliyor | Aylık | Panel doğrudan hedef olur |
| Kayıt uyarıları çalışıyor | Test uyarısı kanala düşüyor | Aylık | İhlal aylarca görünmez |
| Web kökünde artık dosya yok | Arama sonucu boş | Üç aylık | Unutulmuş dosya sızdırır |
Bu listeyi kim, hangi sırayla uygulayacak?
Kırk maddeyi bir hafta sonunda bitirmeye çalışmak genellikle yarım kalmış bir yapılandırma ve çalışmayan bir site üretir. Doğru yol maddeleri üç dalgaya bölmektir. İlk dalga erişim, güvenlik duvarı, sırların yeri ve yedek: bir günde biter, riskin büyük kısmını kapatır. İkinci dalga dosya izinleri, PHP ayarları ve artık dosya temizliği: bir haftaya yayılır. Üçüncü dalga kayıt izleme, uyarı kuralları ve düzenli denetim takvimi: kalıcı bir alışkanlığa dönüşür.
Her dalgadan sonra siteyi gerçek bir siparişle test et. Sertleştirme adımlarının en sinsi yan etkisi, teslimatı sessizce bozmasıdır: kapattığın bir fonksiyon yüzünden kod üretilmez, kısıtladığın bir çıkış yüzünden tedarikçi API'sine ulaşılmaz. Bu yüzden her dalga sonunda küçük tutarlı bir satış yapıp kodun eline geçtiğini gör. Altyapı tarafında hangi ayarların zaten çekirdekte geldiğini görmek için özellikler bölümüne, lisans ve destek kapsamı için fiyat tablosuna bakabilirsin.
Sertleştirmesi kolay bir çekirdekle başla
Yapılandırmasını web kökü dışında tutan, yazılabilir dizinleri ayıran ve bakiye hareketlerini kayıt altına alan bir altyapı, bu listenin yarısını sana bırakmıyor.
Paylaşımlı barındırmada bu maddelerin hangilerini yapabilirim?
SSH ve güvenlik duvarı seviyesindekileri yapamazsın ama dosya izinleri, yapılandırmayı web kökü dışına alma, artık dosya temizliği, yönetim yolunu gizleme, iki adımlı doğrulama ve sunucu dışı yedek maddelerini uygulayabilirsin. Ciron büyüdüğünde kendi sunucuna geçmeyi planla.
Güvenlik duvarı varsa ek katmana gerek var mı?
Sunucu güvenlik duvarı portları yönetir, uygulama katmanındaki istekleri ayırt etmez. Önünde önbellekleyen ve filtreleyen bir katman kullanmak, hem asıl IP'yi gizler hem otomatik trafiğin bir kısmını hiç sana ulaştırmaz. İkisi birbirinin yerine geçmez.
Sertleştirme sitemi yavaşlatır mı?
Doğru yapılırsa hayır, bazı adımlar hızlandırır bile. Yavaşlama şikâyeti genelde aşırı agresif istek sınırlama kurallarından veya yanlış yapılandırılmış önbellekten gelir; kuralları kademeli ekleyip ölçerek ilerlemek bunu engeller.
Yedeği aynı sunucuda tutmak yeterli değil mi?
Değil. Sunucu ele geçirilirse veya diske fidye yazılımı bulaşırsa yedek de kaybolur. Yedek en az bir kopya olarak farklı bir sağlayıcıda, şifreli ve geri yükleme testi yapılmış halde durmalı.
Sunucu sertleştirme, bir kez yapılıp bitirilen bir proje değil; erişimi daraltıp, gereksizi kapatıp, sırları saklayıp, olanı duyabildiğin bir düzen kurmaktır. İlk on iki maddeyi bu hafta bitirirsen riskin büyük kısmı kapanır, kalanı takvime yayılır. Çekirdeğin bu maddeleri sana ne kadar kolaylaştırdığını görmek istersen canlı demo üzerinden panele girip yönetim, bayi ve sipariş ekranlarını sırayla gezmeni öneririm.