Linux sunucu sıkılaştırma kontrol listesi; etki sırasına göre

Sunucuyu teslim aldınız, IP'yi yazıyorsunuz ve root ile giriyorsunuz. Buraya kadar kötü bir şey olmadı. Kötü şey, journalctl -u ssh komutunu açtığınızda son 24 saatte 190 farklı IP'den 4.300 başarısız giriş denemesinin kaydedildiğini gördüğünüzde başlar. Bu sayıyı 22 numaralı portu internete açık olan her sunucuda görürsünüz; özel bir hedef olduğunuz için değil, tarayıcılar tüm IPv4 uzayını taradığı için. Sunucu sıkılaştırma, tam da burada önce neyi kapatacağınıza karar vermek demektir, çünkü işlerin sırası kaç saat harcayacağınızı ve sunucuyu kaç kez kaybedeceğinizi belirler.

Doğru sunucu sıkılaştırma sırası: erişimden izlemeye

Bulduğunuz kontrol listelerinin çoğunda 30 madde vardır ve hiçbiri hangi maddenin önce olduğunu söylemez. Ben aşağıdaki sırayı, kendi sunucumun dışında birkaç kez kilitli kaldıktan sonra sabitledim. Mantığı basittir: önce erişimi güvenli hale getir, sonra saldırı yüzeyini azalt, sonra ne olduğunu anla.

1. sudo yetkili root olmayan bir kullanıcı oluşturun ve doğrudan root girişini kapatın.
2. Parola yerine genel anahtarla girişi koyun.
3. Güvenlik duvarını ayağa kaldırın ve yalnızca gerekli portları açık bırakın.
4. Otomatik güvenlik güncellemesini etkinleştirin.
5. SSH üzerinde fail2ban veya eşdeğerini koyun.
6. Log izleme ve uyarıyı devreye alın.

Bu sırayı değiştirirseniz, genellikle üçüncü adımda kendinizi dışarıda kilitlersiniz. Bunu aşağıda ayrıntılı olarak anlatıyorum.

Root olmayan kullanıcı ve root girişini kapatma

Önce bir kullanıcı oluşturun ve sudo grubuna ekleyin:

adduser deploy
usermod -aG sudo deploy
rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

Şu rsync satırını ciddiye alın. Genel anahtarı yeni kullanıcının ev dizinine kopyalamazsanız ve sonra PermitRootLogin no koyarsanız, dışarıdan sunucu konsol paneline erişimi olan biri olmadığı sürece pratikte kilitlenmiş olursunuz. Birinin bunu KVM'siz bir bulut sunucusunda yaptığını ve ticket açıp beklemek zorunda kaldığını gördüm.

Sonra /etc/ssh/sshd_config içinde şu satırları ayarlayın:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
AllowUsers deploy

systemctl restart sshd komutundan önce başka bir terminal açık bırakın ve yeni kullanıcıyla giriş yapın. O terminal çalıştıysa mevcut oturumu kapatın. Çalışmadıysa mevcut oturumu kapatmayın. Tam da bu tek alışkanlık, herhangi bir yedekten daha fazla sizi kurtarmıştır. Anahtarlar ve fail2ban hakkında daha fazla ayrıntı SSH güvenliği; port değiştirmekten fail2ban ve genel anahtara yazısında yer alıyor.

Güvenlik duvarı: hangi portlar gerçekten gerekli

Ubuntu 22.04 ve üzerinde ufw yeterlidir. Yoğun trafiği olan veya NAT ve forwarding yapan sunucularda doğrudan nftables daha iyidir çünkü ek soyutlama katmanı yoktur ve kuralları daha net görürsünüz.

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80,443/tcp
ufw enable

Çoğu kişiyi yere seren nokta: SSH portunu değiştirdiyseniz, yeni portun çalıştığından emin olana kadar 22 kuralını silmeyin. ufw enable ile port değişikliğinin sırasını yanlış yaparsanız, sonuç tamamen erişilemez bir sunucudur.

Güvenlik duvarı hacimsel saldırıyı engellemez. Sunucunuz yoğun trafiğin hedefi olursa, ufw kuralları işe yaramaz çünkü paketler sunucuya ulaşmadan önce bir yerde filtrelenmelidir. O katman için makinenin kendisinde değil, ağ düzeyinde çalışan DDoS koruması gerekir.

Otomatik güvenlik güncellemesi

Debian ve Ubuntu üzerinde:

apt install unattended-upgrades
dpkg-reconfigure --priority=low unattended-upgrades

/etc/apt/apt.conf.d/50unattended-upgrades içinde security deposunun etkin olduğundan emin olun ve belirli bir yeniden başlatma pencereniz yoksa Automatic-Reboot değerini false yapın. Çekirdek yeniden başlatma olmadan yamalanmaz ve burada hata yapılır: apt upgrade hatasız bittiği için sunucunun yamalandığını sanırlar. Sonra uname -r aynı eski sürümü gösterir ve güvenlik açığı yerinde durur.

fail2ban ve izleme

MaxAuthTries 3 ile her IP üç denemeden sonra reddedilir, ancak yine de sonsuz kez deneyebilir. fail2ban bunu güvenlik duvarı düzeyinde kapatır:

apt install fail2ban
fail2ban-client status sshd

Doğru çıktı şuna benzer: Currently banned: 47. Banlanan sayı sıfır kalıyorsa, jail yanlış log üzerinde ayarlanmış demektir; systemd sistemlerinde mevcut olmayabilecek /var/log/auth.log yolu yerine backend = systemd koymalısınız.

Uyarısız izlemenin faydası yoktur. Günlük bir logwatch veya başarılı girişleri sayan basit bir betik yeterlidir. Neyin kaydedilmesi gerektiğini ve logu nasıl bozulmadan koruyacağınızı bilmek istiyorsanız Denetim logu nedir ve nasıl bozulmadan koruruz? yazısını okuyun.

Sunucu sıkılaştırmada daha az etkisi olan şeyler

SSH portunu 22'den örneğin 22222'ye değiştirmek. Bu, tembel tarayıcıları engeller ve logu daha temiz yapar, ancak hiçbir hedefli tarayıcıyı durdurmaz. Sınırlı zamanınız varsa, önce genel anahtar ve PermitRootLogin no yapın, sonra portu değiştirin. Tersi zaman kaybıdır.

Web sunucusuna bir antivirüs kurmak da genellikle az etki eder. Linux sunucusundaki gerçek saldırı yüzeyi, diskteki dosyalar değil, çalışan servisler ve sürümleridir. ss -tulpn ile neyin dinlediğini görün ve tanımadığınız her servisi kapatın. Bu iş beş dakika sürer ve birkaç güvenlik aracından daha fazla etki eder.

Bilmeniz gereken bir sınırlama

Bu işlerin hiçbiri uygulamanın kendi güvenlik açığını engellemez. WordPress'iniz varsa ve yamalanmamış bir eklenti sürümü varsa, sıkılaştırılmış SSH hiçbir yardım etmez çünkü saldırgan kabuktan değil, web yolundan girer. O yol için WordPress güvenliği; wp-config'ten kendileri açık olan eklentilere doğru başlangıç noktasıdır. Sunucu sıkılaştırma ve uygulama güvenliği iki ayrı katmandır ve hiçbiri diğerinin yerini tutmaz.

Sunucuyu kaybettiğinizde, nerede hata yaptığınızı ne gösterir

Üç yaygın belirti:

• SSH portunda Connection refused: güvenlik duvarı veya sshd servisi ayakta değil. Sunucu konsolundan systemctl status sshd çalıştırın.
• Daha önce çalışan bir anahtarla Permission denied (publickey): ~/.ssh izinleri 777 veya 775. Dizin için 700, authorized_keys için 600 olmalıdır. sshd bunu varsayılan olarak reddeder ve açık bir mesaj da vermez.
• Giriş başarılı ama sudo çalışmıyor: kullanıcı sudo grubunda değil veya grup üyeliğinin uygulanması için yeniden giriş yapmanız gerekiyor.

Sunucunuz bir kurumsal ağın arkasındaysa ve çalışanlar dışarıdan bağlanıyorsa, SSH sıkılaştırma yeterli değildir; erişim yolunu da kontrol etmelisiniz. Çalışanların güvenli erişimi için kapsamlı kurumsal VPN rehberi tam da bu katmanı kapsıyor.

DNS kayıtlarınızın ve ağ yolunuzun doğru olup olmadığını kontrol etmek için, her büyük değişiklikten önce DNS ve ağ kontrol araçlarını kullanın. Güvenlik duvarı değişikliğinden sonra site dışarıdan açılmıyorsa, önce sorunun DNS mi yoksa paket filtresi mi olduğunu bilmelisiniz.

Bu katmanı kendiniz tutmamayı tercih ediyorsanız, ServerNet güvenlik hizmetleri tam da bu işleri hizmet olarak kapsıyor; ancak o durumda bile sunucunuzda neyin ayarlandığını bilmelisiniz, çünkü bir gün sorun çıktığında ilk soru tam da budur.

Sık sorulan sorular

SSH portunu değiştirmek gerçekten güvenliği artırır mı?

Bir dereceye kadar, ama sanıldığı kadar değil. Portu değiştirmek log hacmini ve otomatik deneme sayısını azaltır, ancak tüm portları tarayan tarayıcıları engellemez. Gerçek etki genel anahtardan ve root girişini kapatmaktan gelir. Yalnızca bir şey yapabiliyorsanız, PasswordAuthentication no seçeneğini seçin.

Güvenlik duvarını etkinleştirdikten sonra neden sunucuya bağlanamıyorum?

Çünkü ufw enable komutundan önce SSH portu kuralını eklemediniz veya portu değiştirdiniz ve eski kuralı sildiniz. Çözüm SSH'den değil, sunucu konsolundan gelir. Güvenlik duvarını etkinleştirmeden önce her zaman bir oturum açık bırakın ve ikinci oturumda test edin.

Otomatik güncelleme sunucuyu bozabilir mi?

Evet ve bunun ana nedeni otomatik yeniden başlatmadır. Automatic-Reboot true ise, sunucu uygun olmayan bir saatte açılır ve bağımlı servisler düzgün başlamayabilir. Bunu false yapın ve yeniden başlatmayı kendi maintenance pencerenizde gerçekleştirin.

Bugün yapmam gereken minimum şey nedir?

Genel anahtarlı root olmayan bir kullanıcı oluşturun, PermitRootLogin no ve PasswordAuthentication no ayarlayın ve ufw'yi yalnızca gerekli portlarla ayağa kaldırın. Bu dört iş yarım saatten az sürer ve otomatik giriş denemelerinin çoğunu ortadan kaldırır. Kontrol listesinin geri kalanı bunlardan sonra anlam kazanır.