Yeni Sunucu Sertleştirme: İlk SSH'tan Güvenlik Duvarına

Sunucuyu teslim aldınız, IP ve root parolası elinizde ve çoğu kişinin yaptığı ilk şey ssh root@IP ile giriş yapıp hemen SSH portunu değiştirmek oluyor. Yarım saat sonra terminal penceresi kapanıyor ve bir daha giriş yapamıyorlar. Eğer şu anda tam bu noktada duruyorsanız, işlerin sırasını değiştirin. Sunucu sertleştirme yukarıdan aşağıya uygulanan bir kontrol listesi değildir; uyulmadığı takdirde kendinizi sunucudan atacağınız bir sırası vardır.

Herhangi bir değişiklikten önce bir geri dönüş yolu oluşturun

Erişimi kesme ihtimali olan her değişikliğin bir geri dönüş yolu olmalıdır. İki yolunuz var: ya sunucu yönetim panelinden KVM/VNC konsolunu açık tutun, ya da önceden mevcut kullanıcıdan bağımsız çalışan sudo yetkili ikinci bir kullanıcı oluşturun.

adduser deploy
usermod -aG sudo deploy
mkdir -p /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

Şimdi ikinci bir terminalde ssh deploy@IP ile giriş yapın ve açık kalsın. Sonraki tüm değişiklikleri o terminalden yapın. Bir yerde kilitlenirseniz, o açık terminal sizi kurtarır. İşler ters giderse ve hiçbir yol kalmazsa, sunucuyu yeniden kurma ve rescue modunda çalışma son seçenektir; ancak o noktaya gelmek bir saat ekstra iş demektir.

Önce güncelleme, sonra her şey

Yeni teslim edilen bir sunucu genellikle yayınlanmasının üzerinden birkaç hafta veya birkaç ay geçmiş bir imaja sahiptir. Herhangi bir paket kurmadan önce depoları güncelleyin:

apt update && apt upgrade -y
apt install -y unattended-upgrades
dpkg-reconfigure --priority=low unattended-upgrades

Debian 12 ve Ubuntu 22.04'te bu komutlar sorunsuz çalışır. Çekirdek güncellendiyse needrestart veya reboot gerekir; ancak yeniden başlatmayı güvenlik duvarını ayarladıktan sonraya erteleyin ki sunucu açılmazsa sorunun nereden kaynaklandığını bilesiniz.

Burada hata yapılıyor: çoğu kişi henüz güvenlik duvarı olmayan bir sunucuda apt upgrade çalıştırıyor ve yeniden başlatmadan sonra servislerinin açılmadığını görüyor, çünkü yeni sürüm bir yapılandırmayı üzerine yazmış. Ana paketleri yükseltmeden önce apt list --upgradable komutuna bakın ve listede MySQL veya Nginx varsa önce yapılandırmanın yedeğini alın.

SSH'ı kendiniz dışarıda kalmayacak şekilde kapatın

Sıra önemlidir. Önce genel anahtarı sunucuya koyun, sonra parolayı devre dışı bırakın. Tersini yaparsanız, iki adım arasında erişiminiz kesilir.

1. Genel anahtarı yeni kullanıcının ~/.ssh/authorized_keys dosyasına yerleştirin.
2. Ayrı bir terminalde anahtarla giriş yapın ve çalıştığından emin olun.
3. /etc/ssh/sshd_config.d/99-hardening.conf dosyasını oluşturun.
4. sshd -t ile yapılandırmanın geçerliliğini test edin.
5. systemctl reload sshd ile uygulayın, restart ile değil.

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 20
AllowUsers deploy

SSH portunu değiştirme konusunda: ben varsayılan 22'yi koruyorum. Portu değiştirmek gerçek güvenlik katmaz, sadece log gürültüsünü azaltır ve karşılığında güvenlik duvarını yanlış yapılandırırsanız veya ISP portu kapatırsa zamanınız boşa gider. Israr ediyorsanız, önce yeni portu güvenlik duvarında açın, sonra sshd'yi reload edin ve eski portu birkaç gün açık tutun.

Güvenlik duvarı: yalnızca gerekli olan

Ubuntu ve Debian'da ufw en basit yoldur. Ancak etkinleştirmeden önce SSH portunu ekleyin:

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

Sunucunuzda Docker varsa önemli bir nokta: Docker kendi iptables kurallarını doğrudan yazar ve ufw'yi atlar. Yani ufw'de kapalı olan bir port dışarıdan erişilebilir olabilir. docker ps ile hangi portların publish edildiğini görün ve compose'da yalnızca gerçekten gerekli portları bind edin, örneğin 3306:3306 yerine 127.0.0.1:3306:3306. Doğru kurulum için VPS'te Docker kurulumu sayfasına bakın.

MySQL servisiniz varsa, 3306 portunu mutlaka dışarıdan kapatın. Güçlü bir parolanız olsa bile, tarayıcılar sürekli denemeye devam eder. MySQL güvenliği ve erişimlerin kısıtlanması anonim kullanıcıyı silme ve bind-address'i kapatma adımlarını kapsar.

Fail2ban ve izleme: saldırı başladığında

SSH'ı kapattıktan sonra /var/log/auth.log dosyasına bakın. Sunucu internette birkaç saat kaldıysa, yüzlerce başarısız deneme görürsünüz. Fail2ban bunları otomatik olarak engeller:

apt install -y fail2ban
systemctl enable --now fail2ban
fail2ban-client status sshd

fail2ban-client status sshd çıktısı mevcut engellenenlerin sayısını gösterir. Sayı sıfırsa ve sunucu internette birkaç gün kaldıysa, ya jail doğru etkinleştirilmemiştir ya da log başka bir yoldadır.

İzlemeyi ciddiye alın. İzlemesi olmayan bir sunucu, dolduğunda veya yük yükseldiğinde, site erişilemez hale gelene kadar haber vermez. htop, iotop ve netdata gibi araçlar yeterlidir. Yük yükselirse ve nedenini anlamazsanız, Yüksek sunucu yükünün nedenini teşhis etme adım adım ilerler.

SSL, yedekleme ve sertleştirmeden sonra kalanlar

Sunucu sertleştirme SSL sertifikası olmadan tamamlanmaz. Bir web servisiniz varsa, Certbot en hızlı yoldur:

apt install -y certbot python3-certbot-nginx
certbot --nginx -d example.com -d www.example.com

Kurulumdan sonra, yenileme zamanlayıcısının etkin olduğundan emin olmak için systemctl list-timers | grep certbot komutunu çalıştırın. Let's Encrypt sertifikaları doksan gün geçerlidir ve otomatik yenileme çalışmazsa, siteniz bir sabah güvenlik hatasıyla açılmaz. Certbot ile ücretsiz sertifika kurulumu yaygın yenileme hatalarını da kapsar.

Yedeklemeyi unutmayın. Sertleştirme birçok şeyi engeller, ancak yanlışlıkla dosya silmeyi engellemez. rsync veya scp ile gecelik olarak başka bir hedefe yedek gönderen basit bir betik, herhangi bir güvenlik duvarından daha değerlidir. scp ve rsync ile dosya transferi doğru kalıbı gösterir.

Neler sonraya ertelenebilir

Tam sertleştirme bir günlük iştir. Acele ediyorsanız şu sırayı izleyin: güncelleme, sudo kullanıcısı, SSH anahtarı, parolayı devre dışı bırakma, güvenlik duvarı. SELinux veya AppArmor, gelişmiş izleme ve çekirdek düzeyinde sertleştirmeyi gelecek haftaya bırakabilirsiniz. Ancak bu beş maddeyi ilk gün yapın.

Sunucuyu yeni bir sağlayıcıdan aldıysanız ve tüm bu işleri manuel yapmak istemiyorsanız, güvenli başlangıç yapılandırmasına sahip yönetilen bir Linux hosting daha hafif bir başlangıç noktasıdır; ancak tam kontrol istiyorsanız, aynı çıplak sunucu yukarıdaki kontrol listesiyle iş görür.

Sıkça sorulan sorular

SSH portunu değiştirdikten sonra neden artık giriş yapamıyorum?

Muhtemelen güvenlik duvarı yeni portu açmadı ya da sshd servisini restart ettiniz ve yapılandırmada hata vardı. KVM konsoluyla giriş yapın, yapılandırma hatasını görmek için sshd -t çalıştırın ve reload'dan önce ufw allow NEWPORT/tcp komutunun çalıştırıldığından emin olun. İkinci terminali açık tuttuğunuz sürece bu sorun birkaç dakikada çözülür.

Root girişini devre dışı bırakmak yeterli mi?

Hayır. PasswordAuthentication yes olarak kalırsa, diğer kullanıcılar üzerinde brute-force saldırısı devam eder. İkisini birlikte kapatın ve yalnızca anahtarla girişi açık bırakın. Ayrıca yalnızca giriş yapmasını istediğiniz kullanıcılara izin vermek için AllowUsers ayarlayın.

ufw ve iptables'ı birlikte kullanmalı mıyım?

Hayır. ufw, iptables üzerinde bir yönetim katmanıdır ve aynı anda ham iptables kuralları yazarsanız, yeniden başlatma veya reload sonrasında kurallarınız silinebilir. Birini seçin. Docker'ınız varsa, Docker'ın kendi kurallarını ayrı yazdığını ve portları konteyner düzeyinde kısıtlamanız gerektiğini bilin.

Sertleştirmeden sonra birinin giriş denediğini nasıl anlarım?

fail2ban-client status sshd ile engellenenlerin sayısını görün ve journalctl -u ssh --since "24 hours ago" | grep Failed komutunu çalıştırın. Engellenen sayısı yüksekse ancak hiçbiri kendi IP'leriniz değilse, sistem doğru çalışıyor demektir. Kendi IP'niz engellendiyse, fail2ban-client set sshd unbanip IP ile serbest bırakın.