SSH genelde “çalışıyor” kabul edilir. Sunucu kurulur, bağlantı yapılır, bir daha bakılmaz. Aylar geçer. Kimse SSH’ye dokunmaz çünkü görünürde bir sorun yoktur. Oysa SSH, internete açık her sunucuda en çok yoklanan, en çok zorlanan ve en sık istismar edilen servistir. Çoğu zaman bu fark edilmez, çünkü saldırılar sessizdir.
SSH güvenliği genellikle bir şeyler ters gittikten sonra gündeme gelir. Sunucu yavaşlar, garip işlemler başlar ya da servis sağlayıcı “sunucunuzdan anormal trafik çıkıyor” diye uyarı gönderir. O ana kadar herkes “bizim SSH zaten güvenli” diye düşünmüştür.
Bu yazı tanım anlatmaz. Sahada yaşanan problemlerden yola çıkar. Çünkü SSH güvenliği teorik bir konu değil, doğrudan pratik bir hayatta kalma meselesidir.
SSH Neden Saldırıların İlk Durağıdır?
Bir sunucu internete bağlandığı anda otomatik taramalar başlar. Bu insanlar değil, botlardır. SSH portlarını, kullanıcı adlarını ve varsayılan ayarları denerler. Özellikle port 22 açık olan sistemler, dakikalar içinde yüzlerce deneme alır.
Sahada en sık gördüğüm tablo şudur:
- SSH portu değiştirilmemiştir
- Root ile giriş açıktır
- Şifreyle kimlik doğrulama aktiftir
- Fail2Ban veya benzeri bir mekanizma yoktur
Bunların hiçbiri “ileri seviye hata” değildir. Ama birlikte olduklarında, saldırgan için son derece elverişli bir ortam yaratırlar.
Gerçek Bir Saha Senaryosu
Bir ajans sunucusu düşün. Aynı makinede birden fazla müşteri sitesi barındırılıyor. Her şey yolunda. Bir sabah ajans “sunucu çok yavaşladı” diye destek ister.
İlk bakışta servisler ayakta. Ama CPU sürekli yüksek. İnceleme derinleştirildiğinde:
- Haftalardır binlerce SSH denemesi
- Bir noktada başarılı giriş
- Root yetkisiyle çalışan arka plan prosesleri
Sunucu düşmemişti. Ama kontrol artık ajansın elinde değildi. En tehlikeli senaryo budur: sistem çalışıyor gibi görünürken başkası tarafından kullanılıyor olması.
Bu olayda şifre zayıf değildi. Ama kırılabilir bir şifreydi. SSH key yoktu. Root login açıktı. Fail2Ban hiç kurulmamıştı.
SSH Güvenliğinde İlk Yapılması Gereken Nedir?
İlk ve en kritik adım, varsayılan ayarları bozmak. Varsayılanlar saldırganların ezberidir. Portu, kullanıcıyı, doğrulama yöntemini otomatik olarak denerler.
Başlangıç için olmazsa olmazlar:
- Root ile SSH girişini kapatmak
- Şifreyle SSH girişini devre dışı bırakmak
- SSH key tabanlı kimlik doğrulamaya geçmek
Bunlar yapılmadan SSH’nin “güvenli” olduğu söylenemez.
Root Login Neden Bu Kadar Risklidir?
Root, sistemin tamamıdır. SSH üzerinden root erişimi açık olduğunda, tek bir hesap ele geçirilirse sunucunun tamamı gider. Dosyalar, veritabanları, yedekler… Her şey.
Doğru yaklaşım:
- Normal bir kullanıcı oluşturmak
- SSH ile bu kullanıcıyla bağlanmak
- Yetki gerektiğinde sudo kullanmak
Bu yöntem erişimi sınırlar, logları anlamlı hale getirir ve hatalı işlemlerin etkisini azaltır.
Şifre mi SSH Key mi?
Bu noktada gri alan yoktur.
| Kriter | Şifre | SSH Key |
|---|---|---|
| Brute force riski | Yüksek | Çok düşük |
| Otomatik saldırılar | Etkili | Etkisiz |
| Yetki kontrolü | Zayıf | Güçlü |
| Profesyonel kullanım | Hayır | Evet |
SSH key kullanımı bir kere kurulduktan sonra şifreden daha pratiktir. Şifreyle SSH girişini tamamen kapatmak, güvenlikte ciddi bir eşik atlatır.
Çoğu Kişinin Bilmediği Teknik Bir Detay
SSH saldırılarında asıl problem, başarısız denemeler değil bağlantı kurulabilen denemelerdir. Bir bot SSH bağlantısını kurabiliyorsa, CPU ve RAM tüketir, logları şişirir ve sistem performansını düşürür.
Bu yüzden sadece “şifrem güçlü” demek yeterli değildir. Bağlantıyı zorlaştırmak gerekir. Port değiştirme burada devreye girer. Güvenliği tek başına sağlamaz ama otomatik taramaların büyük kısmını keser.
SSH Portunu Değiştirmek Gerçekten İşe Yarar mı?
Port değiştirmek mucize değildir. Ama sahada etkilidir. Port 22, tüm botların ilk denediği yerdir. Farklı bir port, hedefli saldırıyı durdurmaz ama otomatik taramaların çoğunu engeller.
Doğru yaklaşım nettir: portu değiştir, ama asıl güvenliği key, firewall ve erişim kısıtlarıyla sağla.
Fail2Ban SSH Güvenliğinde Neden Kritik?
Fail2Ban, SSH güvenliğinin bel kemiğidir. Belirli sayıda başarısız denemeden sonra IP’yi otomatik olarak engeller. Ancak sahada sık görülen bir hata vardır: Fail2Ban kurulur ve unutulur.
Yanlış regex, yanlış süre veya eksik yapılandırma Fail2Ban’i etkisiz hale getirir. Kurulduktan sonra mutlaka test edilmelidir.
IP Bazlı SSH Kısıtlaması Ne Zaman Mantıklıdır?
Eğer sabit IP’lerden bağlanıyorsan, bu en temiz çözümlerden biridir. Sadece belirli IP’lere SSH izni verilir, diğer tüm dünya kapatılır. Bu yöntem saldırı yüzeyini neredeyse sıfırlar.
SSH Güvenliği Sunucu Yönetiminden Ayrı Düşünülebilir mi?
Hayır. Güncellenmeyen bir sistemde SSH ne kadar kilitli olursa olsun risk vardır. OpenSSH, kernel ve bağımlılıkların güncel olması gerekir. SSH güvenliği aktif sunucu yönetiminin bir parçasıdır.
Özellikle izole ve yüksek kaynaklı yapılarda bu daha kritiktir. Nested Dedicated Sunucu gibi altyapılarda hem ana fiziksel sunucunun hem de alt sanal katmanların SSH politikaları doğru kurgulanmalıdır.
Bu altyapıyı incelemek isteyenler için doğal bir referans:
https://perminet.com/nested-dedicated-sunucu
SSH Güvenliğinde En Sık Yapılan Hatalar
- Root login’i açık bırakmak
- Şifreyle SSH girişini kapatmamak
- Fail2Ban’i kurup test etmemek
- Logları düzenli kontrol etmemek
- “Bir şey olmadı” diyerek önlem almamak
SSH Güvenliği Nasıl Bir Rutine Oturtulmalı?
- Düzenli SSH log kontrolü
- Güncelleme sonrası bağlantı testleri
- Kullanıcı ve SSH key denetimi
- Gereksiz erişimlerin silinmesi
- Firewall ve Fail2Ban durum kontrolleri
FAQ – SSH Güvenliği Hakkında Sık Sorulan Sorular
SSH portunu değiştirmek tek başına yeterli değildir.
SSH key kullanımı zor değildir, alışınca daha pratiktir.
Fail2Ban internete açık sunucular için gereklidir.
SSH güvenliği dolaylı olarak SEO’yu etkiler çünkü hacklenen veya yavaşlayan sunucular sıralama kaybı yaşar.
Küçük projeler de saldırıya uğrar, botlar proje boyutuna bakmaz.
Bir yanıt yazın