Sunucuyu yeni ayağa kaldırdınız, ssh root@IP ile giriyorsunuz ve her şey çalışıyor. Sonra /var/log/auth.log dosyasını açıyorsunuz ve son 24 saatte 190 farklı IP'den 4.300 başarısız giriş denemesinin kaydedildiğini görüyorsunuz. İşte burada /etc/ssh/sshd_config dosyasını ciddiye almanız gerekiyor. Bu makale, saldırı yüzeyine gerçekten etki eden seçeneklerin listesi, her birinin önerilen değeri ve pratikte neyin bozulduğudur.
Herhangi bir değişiklikten önce: yedek bir oturum açık bırakın
sshd_config dosyasını her düzenlediğinizde, başka bir terminal açık tutun ve orada oturum açık kalsın. Yapılandırma hatalıysa ve servis yeniden başlatılırsa, mevcut oturum kesilmez ancak yeni oturum kurulamayabilir. Yeniden başlatmadan önce her zaman test edin:
sshd -t
systemctl reload sshdsshd -t çıktısı boşsa sözdizimi doğrudur. Hata varsa, orada durun. reload komutu aktif bağlantıları kesmez; restart keser. sshd_config değişiklikleri için neredeyse her zaman reload yeterlidir.
Saldırı yüzeyini gerçekten azaltan seçenekler
PermitRootLogin
Önerilen değer: prohibit-password veya no. Bu ikisi arasındaki fark önemlidir. prohibit-password root'un parolayla girişini kapatır ancak açık anahtarı kabul eder. no root için her türlü girişi kapatır ve normal bir kullanıcıyla giriş yapıp ardından sudo kullanmanız gerekir. Önceden sudo erişimli ve anahtarı kurulu bir kullanıcınız varsa no'yu tercih ederim. Yoksa, önce onu oluşturun, sonra bu satırı değiştirin.
PasswordAuthentication ve ChallengeResponseAuthentication
Önerilen değer: her ikisi için no. Parolayla giriş açık olduğu sürece, SSH üzerinde sözlük saldırısı işe yarar ve hiçbir güvenlik duvarı bunu engelleyemez çünkü 22 numaralı porttaki trafik meşrudur. Bu ikisini no yaparak, parola saldırısı tamamen etkisiz hale gelir. Bedeli şudur: özel anahtarı kaybederseniz erişimi kaybedersiniz ve sunucuyu konsoldan veya rescue modundan geri getirmeniz gerekir. Bu risk sizin için kabul edilebilir değilse, en azından root için PasswordAuthentication no bırakın ve belirli bir kullanıcı için açık tutun.
PubkeyAuthentication ve AuthorizedKeysFile
Önerilen değer: PubkeyAuthentication yes ve AuthorizedKeysFile .ssh/authorized_keys. Dosya izinlerine karşı hassas olun: chmod 700 ~/.ssh ve chmod 600 ~/.ssh/authorized_keys. authorized_keys izni açık olursa, sshd onu sessizce yok sayar ve logda Authentication refused: bad ownership or modes gibi bir şey görürsünüz. Bu hatayı çok gördüm ve neredeyse her zaman sorun anahtar değil, izinlerdir.
Port
Varsayılan portu 22'den başka bir şeye değiştirmek gerçek güvenlik eklemez; yalnızca otomatik tarayıcıların log hacmini azaltır. Güvenlik duvarı veya fail2ban arkasındaysanız, buna değer. Değilseniz, sadece ek karmaşıklık eklemiş olursunuz. Ben portu değiştiririm ancak ana güvenlik katmanı olarak ona güvenmem.
AllowUsers ve DenyUsers
Önerilen değer: AllowUsers deploy admin. Bu seçenek bir beyaz listedir; içinde olmayan her kullanıcı, geçerli bir anahtarı olsa bile reddedilir. Sunucunun birden fazla kullanıcısı varsa ve www-data veya mysql gibi servis hesaplarının asla SSH yapmadığından emin olmak istiyorsanız, bu satırı koyun. Dikkat edin: AllowUsers ve AllowGroups birbirinin yerine geçmez, birleşirler.
MaxAuthTries ve LoginGraceTime
Önerilen değer: MaxAuthTries 3 ve LoginGraceTime 30. MaxAuthTries varsayılanı 6'dır. 3 ile, her bağlantı üç başarısız denemeden sonra kapatılır ve sözlük saldırısının maliyeti artar. LoginGraceTime varsayılanı 120 saniyedir; 30 saniye yeterlidir ve yarı açık bağlantı sayısını azaltır.
X11Forwarding ve AllowTcpForwarding
Önerilen değer: gerçekten SSH tüneline ihtiyacınız yoksa X11Forwarding no ve AllowTcpForwarding no. SSH'ı proxy olarak veya veritabanı tüneli için kullanıyorsanız, AllowTcpForwarding değerini yes yerine local yapın. Bu kısıtlama, sunucunun röle olarak kötüye kullanılmasını engeller.
ClientAliveInterval ve ClientAliveCountMax
Önerilen değer: ClientAliveInterval 300 ve ClientAliveCountMax 2. Bu ikisi birlikte şu anlama gelir: istemci 10 dakika yanıt vermezse bağlantı kapatılır. Terk edilmiş oturumları çok olan sunucular için faydalıdır. Kalitesiz bir bağlantı üzerinde çalışıyorsanız, bu sayıyı yükseltin yoksa işin ortasında bağlantınız kesilir.
Burada hata yapıyorlar
Gördüğüm en yaygın hata şudur: kullanıcı dosyanın sonuna PasswordAuthentication no ekler, ancak aynı dosyada daha yukarıda zaten bir PasswordAuthentication yes satırı vardır. sshd_config'te her anahtar için okunan ilk değer kazanır, sonuncusu değil. Sonuç şudur: servis yeniden başlatılır, log hiçbir hata göstermez, ancak parolayla giriş hâlâ çalışır ve kullanıcı ayarın uygulandığını sanır. Doğru yol: eski satırı yorumlayın veya silin, sonra yeni satırı koyun. Emin olmak için etkin çıktıyı görün:
sshd -T | grep -i passwordauthsshd -T komutu, tüm kurallar uygulandıktan sonraki nihai yapılandırmayı yazdırır. Orada passwordauthentication no görürseniz, ayar gerçekten uygulanmıştır.
Varsayılan ve önerilen değer karşılaştırması
| Seçenek | Varsayılan | Önerilen | Etki |
|---|---|---|---|
| PermitRootLogin | prohibit-password | no | Root girişinin tamamen kapatılması |
| PasswordAuthentication | yes | no | Parola saldırısının etkisiz hale gelmesi |
| MaxAuthTries | 6 | 3 | Bağlantı başına deneme sayısının azaltılması |
| LoginGraceTime | 120 | 30 | Yarı açık bağlantının azaltılması |
| X11Forwarding | yes | no | Kullanılmayan saldırı yüzeyinin kaldırılması |
| AllowTcpForwarding | yes | no veya local | Sunucunun röle olmasının engellenmesi |
SSH kapatıldıktan sonra sıra ne
Parolayla giriş kapatıldığında, fail2ban'ın artık yapacak fazla işi kalmaz çünkü tahmin edilecek bir şey kalmamıştır. Ancak aynı sunucuda başka servisleriniz varsa, MySQL güvenliğini ciddiye alın; anonim kullanıcıyı silmek ve erişimi localhost ile sınırlamak bu işin bir parçasıdır. Web sunucusu olarak çalışan sunucular için SSL sertifikası kurulumu da mantıklı bir sonraki adımdır. ServerNet bulut sunucusu veya özel sunucusu üzerinde çalışıyorsanız, bu ayarlar her ikisinde de aynı şekilde uygulanır ve erişim kilitlenirse yönetim konsolundan rescue modunu kullanabilirsiniz.
Pratik bir not: değişiklikleri uygulamadan önce dosyanın bir yedeğini alın ve sunucu dışında bir yerde saklayın. cp /etc/ssh/sshd_config /root/sshd_config.bak yeterlidir, ancak sunucu erişilemez hale gelirse o yedek de erişilemez olur. scp ve rsync ile dosya aktarımı, yedeği yerel makineye çekmenin hızlı yoludur.
Sık sorulan sorular
PasswordAuthentication no yaptıktan sonra neden hâlâ parolayla giriş yapıyorum?
Çünkü muhtemelen aynı dosyada daha yukarıda bir PasswordAuthentication yes satırı vardır ve sshd ilk değeri okur. sshd -T | grep -i passwordauth ile etkin değeri kontrol edin. yes ise, eski satırı silin veya yorumlayın ve servisi reload edin.
PermitRootLogin'de prohibit-password ile no arasındaki fark nedir?
prohibit-password root'un parolayla girişini kapatır ancak açık anahtarı kabul eder. no root için her türlü giriş yöntemini kapatır ve normal bir kullanıcıyla giriş yapıp ardından sudo kullanmanız gerekir. Anahtarı kurulu bir sudo kullanıcınız varsa, no daha güvenli bir seçimdir.
SSH portunu değiştirmek güvenliği artırır mı?
Gerçekte hayır. Portu değiştirmek yalnızca otomatik tarama hacmini azaltır ve logda daha temiz görünür. Gerçek güvenlik, parolayla girişi kapatmaktan, izin verilen kullanıcıları sınırlamaktan ve anahtar kullanmaktan gelir. Güvenlik duvarı arkasındaysanız, portu değiştirmek ek bir katmandır, onun yerine geçmez.
SSH anahtarını kaybedersem ne olur?
Parolayla girişi kapatmışsanız, SSH erişimini kaybedersiniz. Bu durumda authorized_keys dosyasını düzeltmek veya parolayı geçici olarak açmak için sunucu yönetim konsolunu veya rescue modunu kullanmanız gerekir. Bu nedenle her zaman yedek yol olarak ayrı anahtarlı ikinci bir kullanıcı bulundurun.