Sunucudan Kilitlenme: Sıfırlamadan Erişimi Kurtarma

SSH bağlantısı kesilir, tekrar denersin, yine kesilir. Ne bir hata mesajı görürsün, ne bir yanıt. Sadece ekranda Connection timed out veya Connection refused kalır ve birkaç dakika önce kendin bir iptables komutuyla veya bir satır sshd_config ile bu kapıyı kapattığını bilirsin. Bu duruma teknik çevrelerde "sunucudan kilitlenme" denir ve çoğu insanın yaptığı ilk şey yanlıştır: makineyi sıfırlamak.

Sunucuyu yeniden başlatmak neredeyse hiçbir zaman sorunu çözmez, çünkü yazdığın kural diskte kayıtlıdır ve önyüklemeden sonra tekrar yüklenir. Güvenlik duvarı servisini enable yaptıysan daha da kötü: her önyüklemede aynı kural geri gelir. O halde her şeyden önce, yeniden başlatmayı bırak ve ikinci bir giriş yolu ara.

Kurtarma konsolu: hâlâ açık olan tek kapı

Her altyapı sağlayıcısının genel ağ dışında bir erişim yolu vardır. ServerNet'te bu yol kontrol panelinden seri konsol veya VNC şeklinde erişilebilir. Bu konsol sunucunun ağ yığınından geçmez, dolayısıyla SSH'ı kapatan güvenlik duvarı kuralının ona hiçbir etkisi yoktur. Eğer özel sunucun veya VPS'in varsa, ihtiyaç duymadan önce bu düğmenin paneldeki yerini şimdi bul.

Konsol üzerinden girdiğinde, önce düşündüğünü değil, gerçek durumu gör:

iptables -L INPUT -n -v --line-numbers
nft list ruleset
ss -tlnp | grep :22
systemctl status sshd

ss çıktısı sana SSH servisinin gerçekten çalışıp çalışmadığını söyler. Eğer 22 numaralı port LISTEN listesinde değilse, sorun güvenlik duvarı değildir; servis çökmüştür veya yapılandırması bozuktur. Bu ayrım, zamanının yarısını kurtarır. Eğer port dinliyor ama dışarıdan yanıt alamıyorsan, suçlu filtre katmanıdır.

Suçlu kuralı diğerlerini kaybetmeden silmek

Kuralları numaralı olarak gör ve sadece o tek satırı sil. Tüm zinciri iptables -F ile silmek aptalca bir iştir; çünkü diğer koruyucu kuralları da beraberinde götürür ve sunucuyu çıplak bırakır.

iptables -D INPUT 3
# veya nftables için
nft delete rule inet filter input handle 12

Sildikten sonra, hemen başka bir terminalden SSH'ın geri gelip gelmediğini test et. Bu test başarılı olana kadar konsol terminalini kapatma.

Zamanlı kural: uygulamadan önce güvence oluştur

Asıl sorun kuralın yanlış olması değil; geri dönüş yolu olmadan uygulamış olmandır. Yıllardır üretim sunucularında kullandığım standart çözüm, otomatik geri dönüş zamanlamasıdır. Güvenlik duvarında herhangi bir değişiklik yapmadan önce, sen onaylamazsan önceki kuralları kendiliğinden geri getirecek bir job koy.

# sağlıklı durumu kaydet
iptables-save > /root/fw-good.rules

# onaylamazsan 5 dakika sonra otomatik geri dönüş
echo "iptables-restore < /root/fw-good.rules" | at now + 5 minutes

Şimdi yeni kuralı uygula. Eğer bağlantın kesilirse, beş dakika bekle ve tekrar bağlan. Her şey doğruysa, job'u atrm ile iptal et ve yeni durumu kaydet. Bu desen nftables'ta da nft list ruleset > /root/fw-good.nft ve nft -f ile çalışır. Maliyeti, beş dakika beklemek zorunda olman ve o süre boyunca sunucunun eski kurallarla dönmesidir. Üretim ortamı için bu beş dakika, satın alacağın en ucuz sigortadır.

at hakkında önemli bir not: birçok minimal dağıtımda yüklü değildir. Eğer at yoksa, aynı işi systemd-run ile yap:

systemd-run --on-active=5min /sbin/iptables-restore /root/fw-good.rules

Asla erişim kesintisine yol açmayan sıralama

İşlerin sırası, komutların kendisinden daha önemlidir. İşte pratikte işe yarayan sıralama:

1. İkinci bir SSH oturumu aç ve açık tut. Asla tek bir bağlantı üzerinde güvenlik duvarı değişikliği yapma.
2. Sağlıklı durumu dosyaya kaydet.
3. Otomatik geri dönüş job'unu etkinleştir.
4. Yeni kuralı uygula.
5. İkinci oturumdan test et. Eğer işe yararsa, ilk oturumu kapat ve job'u iptal et.

Eğer SSH portunu değiştiriyorsan, yeni kuralı sshd'yi yeniden başlatmadan önce ekle, sonra değil. Yaygın hata, kişinin portu sshd_config'te değiştirmesi, servisi yeniden başlatması ve sonra güvenlik duvarının sadece eski portu açtığını hatırlamasıdır. Sonuç: servis sağlıklıyken sunucudan kilitlenme. Bu işin ayrıntıları ve fail2ban yapılandırması için SSH güvenliği; port değiştirmekten fail2ban ve açık anahtara kılavuzuna bak.

Burada hata yapıyorlar

Defalarca gördüğüm gerçek hata: birinin ufw allow 22/tcp komutunu önceden çalıştırmadan ufw enable komutunu vermesi. Belirti tam olarak şudur: SSH anında kesilir, ama ping hâlâ yanıt verir ve web sitesi de ayakta kalır. Çünkü ufw varsayılan olarak gelen trafiği kapatır ama ICMP'ye ve önceden açılmış portlara dokunmaz. Bu da kişinin ağın sağlıklı olduğunu ve sorunun başka bir yerde olduğunu düşünmesine neden olur. Eğer bu belirtileri görürsen, önce kurtarma konsolundan ufw status verbose komutunu kontrol et.

İkinci hata: SSH yanıtlarının aynı yerden döndüğünü anlamadan OUTPUT zincirine kural uygulamak. Bağlantı kurulur, kimlik doğrulama reddedilir, sonra kesilir. Bunu iptables -L OUTPUT -n -v ile ve drop paketlerini sayarak teşhis et.

Kurtarma konsolu da erişilebilir olmadığında

Eğer fiziksel bir sunucudaysan ve fiziksel erişimin yoksa, ya da konsolu çalışmayan bir VPS'in varsa, tek seçenek sağlayıcının paneli üzerinden rescue modunda önyükleme yapmaktır. Bu durumda sistem minimal bir ortamdan başlar ve kural dosyasını elle düzeltmek için ana diski mount edersin. Bu yol yavaştır ve bu yüzden "otomatik geri dönüş job'u" aşamasını her ciddi değişiklikten önce önemsiyorum.

Erişimin kritik olduğu servisler için, koruma katmanını kendini kilitlemeyeceğin bir yere koy. ServerNet'in DDoS koruması bu işi ağın kenarında yapar ve filtre kuralları işletim sistemi yığınından ayrı kalır; yani yerel güvenlik duvarını bozsan bile, zararlı trafik orada durdurulur ve sen daha temiz bir sistemle karşılaşırsın.

Kurtarmadan sonra bunları kontrol et

Bağlantının geri gelmesi işin sonu değildir. Üç şeyi mutlaka kontrol et:

• Kaydedilen kurallar mevcut bellek durumuyla aynı olsun. iptables-save çıktısını iptables -L ile karşılaştır.
• Güvenlik duvarı servisi önyüklemede etkin olsun ki yeniden başlatmadan sonra sürprizle karşılaşmayasın: systemctl is-enabled nftables.
• Değişiklik kaydını tut. Güvenlik duvarındaki her değişikliğin bir kaydı olmalı ki tekrar kilitlendiğinde hangi kuralın suçlu olduğunu bilesin. Bu kayıtları tutma yöntemini Denetim günlüğü nedir ve nasıl bozulmadan korunur? yazısında anlattım.

Yazdığın kuralın doğru olup olmadığından şüphe ediyorsan, ana sunucuda uygulamadan önce aynı kuralları aynı dağıtım sürümüne sahip bir test makinesinde çalıştır. Debian 11 ile 12 arasındaki nftables sürüm farkı bazı komutların sözdiziminde az değildir ve bu da testte çalışan bir kuralın üretimde hata vermesine neden olur.

Sıralamayla ilgili son bir not: portları kapatmadan önce her zaman ağ inceleme araçlarını elinin altında bulundur ki dışarıdan neyin açık olduğunu doğrulayabilesin. DNS ve ağ inceleme araçları tam da bu anlar içindir.

Sık sorulan sorular

Sunucuyu yeniden başlattıktan sonra neden hâlâ SSH yapamıyorum?

Çünkü güvenlik duvarı kuralları diskte kayıtlıdır ve servis önyüklemede bunları tekrar yükler. Yeniden başlatma sadece bellek durumunu temizler, kural dosyasını değil. /etc/nftables.conf dosyası veya iptables-save çıktısı düzeltilene kadar, her önyükleme aynı kilidi geri getirir.

Sorunun güvenlik duvarından mı yoksa SSH servisinin kendisinden mi olduğunu nasıl anlarım?

Kurtarma konsolundan ss -tlnp | grep :22 komutunu çalıştır. Eğer port LISTEN durumundaysa, servis sağlıklıdır ve suçlu filtre katmanıdır. Değilse, sorun sshd'de veya yapılandırmasındadır ve güvenlik duvarına dokunmak işe yaramaz.

Tüm kuralları iptables -F ile silmek hızlı bir çözüm mü?

Hayır. Bu komut tüm giriş, çıkış ve yönlendirme kurallarını siler ve sunucuyu her türlü trafiğe açık bırakır. Doğrusu, --line-numbers ile suçlu kuralı bulup sadece o tek satırı -D ile silmektir.

Zamanlı geri dönüş kuralını at bulunmayan bir sunucuda nasıl çalıştırırım?

systemd-run --on-active=5min kullan. Bu komut, beş dakika sonra geri dönüş komutunu çalıştıracak geçici bir birim oluşturur ve at'nin yüklü olmasına gerek duymaz. Her şey doğruysa, birimi systemctl stop ile iptal et.