Sunucunuza giden kapı yalnızca bir şifreyle korunuyorsa, o kapı zaten aralıktır. Şifre tahmin edilebilir, sızdırılmış bir listede bulunabilir veya deneme yanılmayla kırılabilir. Anahtar tabanlı erişimde ise bu üç yolun hiçbiri işlemez.
Kısa cevap: sunucu erişimi nasıl güvene alınır?
Sunucu erişiminin temel kuralı şudur: şifreyle giriş kapatılır, yerine SSH anahtarı kullanılır; kök (root) kullanıcıyla doğrudan giriş devre dışı bırakılır; erişim mümkünse belirli IP adreslerine sınırlandırılır ve tekrarlayan başarısız denemeler otomatik olarak engellenir. Bu dört ayar, sunucuya yönelik otomatik saldırıların neredeyse tamamını etkisiz kılar. Hiçbiri ek ürün gerektirmez; hepsi mevcut yapılandırma üzerinde bir kez yapılan değişikliklerdir.
Şifre yerine anahtar: neden fark eder?
| Kriter | Şifreyle giriş | SSH anahtarıyla giriş |
|---|---|---|
| Deneme yanılma saldırısı | Mümkün; sürekli denenir | Pratikte anlamsız |
| Sızdırılmış şifre listeleri | Doğrudan risk | Etkisiz |
| Paylaşım riski | Şifre kolayca paylaşılır ve yayılır | Anahtar kişiye bağlıdır |
| İptal edilebilirlik | Şifre değişince herkes etkilenir | Tek kişinin anahtarı kaldırılır |
| İzlenebilirlik | Kimin girdiği belirsiz olabilir | Anahtar başına ayrı kayıt |
Tablodaki en pratik fark, dördüncü satırdadır. Ortak şifreyle çalışan ekiplerde bir kişi ayrıldığında şifreyi herkes için değiştirmek gerekir; bu da genellikle ertelenir ve erişim açık kalır. Anahtar tabanlı yapıda ise yalnızca o kişinin anahtarı kaldırılır ve kimse etkilenmez.
8 sertleştirme ayarı
- Şifreyle kimlik doğrulamayı kapatın. Anahtar tabanlı erişim çalıştığı doğrulandıktan sonra yapılmalıdır; sıralamayı ters yapmak kendinizi dışarıda bırakır.
- Kök kullanıcıyla doğrudan girişi devre dışı bırakın. Yetkili bir kullanıcıyla girip yetki yükseltmek, hem izlenebilirlik hem güvenlik sağlar.
- Erişimi IP ile sınırlayın. Sabit IP'niz varsa yönetim erişimini yalnızca ona açın. Sabit IP yoksa VPN üzerinden erişim aynı işlevi görür.
- Deneme sınırlaması kurun. Belirli sayıda başarısız denemeden sonra kaynağı geçici olarak engelleyen bir mekanizma, log kirliliğini de belirgin biçimde azaltır.
- Kullanılmayan servisleri kapatın. Sunucuda çalışan her açık servis bir yüzey üretir; ihtiyaç duyulmayanlar durdurulmalıdır.
- Güvenlik duvarı kurallarını daraltın. Varsayılan politika "kapalı" olmalı, yalnızca gerekli portlar açılmalıdır.
- Otomatik güvenlik güncellemelerini etkinleştirin. En azından güvenlik yamaları için; kritik açıkların çoğu yayınlandıktan kısa süre sonra taranmaya başlar.
- Erişim kayıtlarını ayrı bir yerde tutun. Sunucu ele geçirildiğinde kayıtlar da değiştirilebilir; ayrı tutulan kayıt, olay sonrası analizin tek güvenilir kaynağıdır.
Bir not: port numarasını değiştirmek gürültüyü azaltır ancak tek başına bir güvenlik önlemi değildir. Yararlıdır, fakat yukarıdaki maddelerin yerine geçmez.
Panel erişimi nasıl korunur?
Yönetim panelleri (hosting paneli, içerik yönetim sistemi, veritabanı arayüzü) çoğu zaman sunucudan daha kolay hedeftir; çünkü tarayıcıdan erişilebilirler ve genellikle şifreyle korunurlar.
- İki faktörlü doğrulamayı zorunlu kılın. Panel erişimi, kritik hesap kategorisindedir — yöntem seçimi için 2FA yazımıza bakın.
- Yönetim adreslerini genel erişime kapatın. IP kısıtlaması veya ek bir kimlik doğrulama katmanı, otomatik denemeleri panelin önünde durdurur.
- Kullanıcıları rol bazlı tanımlayın. Herkesin yönetici olduğu bir panel, tek bir hesap ele geçtiğinde tamamen kaybedilir.
- Varsayılan kullanıcı adlarını kullanmayın. "admin" gibi tahmin edilebilir adlar, saldırının yarısını hazır sunar.
- Oturum süresini sınırlayın ve açık oturumları düzenli olarak sonlandırın.
- Kullanıcı listesini çeyrekte bir gözden geçirin. İhtiyacı bitmiş erişimler en sık atlanan açıktır.
Netişlem uzman görüşü: sertleştirme bir kez yapılır, erişim listesi sürekli bakılır
Sunucu sertleştirme çoğu ekipte iyi yapılıyor; asıl sorun sonrasında başlıyor. Bir proje için açılan geçici erişim kapatılmıyor, bir geliştiriciye verilen anahtar kaldırılmıyor, test için gevşetilen bir kural kalıcı hâle geliyor. İncelediğimiz olayların önemli bir kısmında kullanılan kapı, saldırganın bulduğu bir açık değil; unutulmuş meşru bir erişim oluyor.
İkinci gözlemimiz, yapılandırma değişikliklerinin kayıt altına alınmaması. "Bu kural neden gevşetilmiş" sorusunun cevabı yoksa, kimse geri almaya cesaret edemiyor ve gevşeklik kalıcılaşıyor. Değişikliğin yanına tek satırlık bir gerekçe yazmak, bu döngüyü kırıyor.
Üçüncüsü, kilitlenme korkusuyla sertleştirmenin ertelenmesi. Bu korku yerinde ama çözümü basit: değişiklikten önce ikinci bir erişim yolu (konsol erişimi veya ikinci bir yetkili anahtar) hazır tutulur. Bu tek önlem, sertleştirmeyi risksiz hâle getiriyor.
Doğrulama kontrol listesi
- Anahtar tabanlı giriş çalışıyor ve şifreyle giriş kapatıldı.
- Kök kullanıcıyla doğrudan giriş kapalı.
- Yönetim erişimi IP veya VPN ile sınırlandırıldı.
- Başarısız deneme engelleme mekanizması aktif ve test edildi.
- Güvenlik duvarında yalnızca gerekli portlar açık.
- Kullanılmayan servisler durduruldu.
- Otomatik güvenlik güncellemeleri açık.
- Erişim kayıtları ayrı bir konumda saklanıyor.
- Panel hesaplarında iki faktörlü doğrulama zorunlu.
- Yetkili kullanıcı ve anahtar listesi çeyrekte bir gözden geçiriliyor.
- İkinci bir erişim yolu (konsol/yedek anahtar) hazır.
- Yapılandırma değişiklikleri gerekçesiyle kayıt altına alınıyor.
Sık sorulan sorular
Paylaşımlı hosting kullanıyorum, bunların hangisi beni ilgilendirir?
Sunucu seviyesindeki ayarlar sağlayıcının sorumluluğundadır; ancak panel erişimi, kullanıcı yönetimi, iki faktörlü doğrulama ve şifre hijyeni tamamen sizde kalır. Paylaşımlı ortamda en yaygın olay, sunucunun değil hesabın ele geçirilmesidir.
SSH portunu değiştirmek işe yarar mı?
Otomatik tarama gürültüsünü azaltır ve kayıtları okunur hâle getirir, ancak hedefli bir saldırıyı durdurmaz. Faydalıdır fakat anahtar tabanlı erişim ve IP kısıtlamasının yerine geçmez.
Anahtarımı kaybedersem sunucuya erişemez miyim?
Bu yüzden ikinci bir erişim yolu şarttır: sağlayıcının konsol erişimi veya güvenli saklanan ikinci bir yetkili anahtar. Sertleştirmeden önce bu yolun çalıştığını doğrulamak, kilitlenme riskini ortadan kaldırır.
Ekipteki herkese ayrı anahtar vermek zahmetli değil mi?
İlk kurulumda birkaç dakikalık ek iş getirir, karşılığında ise iki büyük kolaylık sağlar: kimin ne zaman giriş yaptığı ayrı ayrı görünür ve bir kişi ayrıldığında yalnızca onun anahtarı kaldırılır. Ortak şifre yönetmek, uzun vadede çok daha zahmetlidir.
Sertleştirme sonrası nasıl doğrulama yaparım?
Şifreyle giriş denemesinin reddedildiğini, kök kullanıcıyla doğrudan girişin çalışmadığını ve izin verilmeyen bir IP'den erişimin engellendiğini tek tek test edin. Ayrıca başarısız deneme engellemesinin gerçekten devreye girdiğini kontrol edin — bu mekanizma sıklıkla kurulu görünür ama çalışmaz.
Sonuç
Sunucu erişimini güvene almak, karmaşık bir güvenlik mimarisi kurmayı gerektirmez. Dört temel karar — anahtar tabanlı giriş, kök girişinin kapatılması, erişim kısıtlaması ve deneme engelleme — otomatik saldırıların neredeyse tamamını dışarıda bırakır. Geriye kalan iş ise sertleştirme değil, erişim listesini güncel tutmaktır.
Sunucu yapılandırmanızı denetlememizi isterseniz bize ulaşın. Sunucu yönetimi, VPS sunucu ve güvenli hosting çözümlerimizi inceleyebilirsiniz.