Firewall Kuralını Yanlış Yazdım, Sunucuya Giremiyorum

Enter tuşuna bastınız ve terminal dondu. ufw enable komutunun altında imleç yanıp sönüyor ama hiçbir çıktı gelmiyor; Ctrl+C bile bir şey yapmıyor. Birkaç saniye sonra oturum Connection to 203.0.113.10 closed by remote host diyerek kapanıyor. Yeniden bağlanmayı deniyorsunuz: ssh [email protected] komutu otuz saniye boyunca hiçbir şey yazmadan bekliyor ve Operation timed out ile düşüyor. Sunucu ayakta, siteler açılıyor olabilir; ama siz artık içeri giremiyorsunuz.

Bu, sunucu yönetiminde herkesin en az bir kez yaşadığı ve yaşadığı anda kalp atışını hızlandıran durumdur. İyi haber şu: sunucu çalışıyor, veri kaybı yok ve neredeyse her durumda kurtarılabilir. Kötü haber ise SSH'ın artık bir seçenek olmaması. Yani sorunu, sorunun kendisini yarattığı kanaldan çözemezsiniz. Çözüm başka bir kapıdan geçmek zorunda: sağlayıcınızın panelindeki KVM/VNC konsolu ya da o da yoksa rescue (kurtarma) modu.

Bu yazıda önce gerçekten firewall'ın mı kilitlediğini birkaç saniyede nasıl anlayacağınızı, ardından konsoldan UFW, iptables/nftables ve CSF kurallarını nasıl geri alacağınızı, konsol erişimi bile olmayan senaryolarda rescue moddan diski bağlayıp nasıl müdahale edeceğinizi anlatacağız. En sonda da asıl önemli kısım var: bir daha aynı yere düşmemek için kuralı zaman aşımlı uygulamanın dört pratik yolu.

Gerçekten Firewall mı Kilitledi, Yoksa Başka Bir Şey mi?#

Panikle konsola koşmadan önce on saniyelik bir teşhis yapın. Bağlantının nasıl başarısız olduğu, sebebi büyük ölçüde ele verir.

En kritik ayrım ilk iki satırdır. Zaman aşımı neredeyse her zaman DROP demektir; çünkü REJECT kuralı ya da kapalı bir port anında cevap döndürür. Sessizlik, paketin hiç cevaplanmadan atıldığının işaretidir ve bu da tipik bir DROP politikasıdır.

Kendi bilgisayarınızdan hızlı doğrulama:

# Port gerçekten cevap veriyor mu?
nc -vz 203.0.113.10 22

# ICMP açıksa sunucu ayakta mı diye bak
ping -c 3 203.0.113.10

# Farklı bir servis (örneğin web) hâlâ çalışıyor mu?
curl -I --max-time 5 http://203.0.113.10/

ping cevap veriyor ve web sitesi açılıyorsa sunucu diri, sadece 22. porta giden yol kapalıdır. Bu, klasik firewall kilitlenmesidir. Eğer hiçbir şeye cevap gelmiyorsa sorun ağ katmanında ya da makinenin kendisinde olabilir; o senaryo için sunucuma bağlanamıyorum yazısındaki daha geniş kontrol listesi daha uygundur. Kimlik doğrulama hatası alıyorsanız firewall ile işiniz yok; SSH permission denied publickey hatası tarafına bakın.

Küçük bir ihtimali de aklınızda tutun: sunucunuzda otomatik bir kurtarma mekanizması çalışıyor olabilir. CSF TESTING modundaysa veya daha önce bir at işi bıraktıysanız, birkaç dakika bekleyip tekrar denemek bazen tek yapmanız gereken şeydir.

Panelden KVM/VNC Konsoluyla Sunucuya Girmek#

KVM veya VNC konsolu, sunucunun sanal ekranına ve klavyesine doğrudan bağlanmanızı sağlar. Ağ üzerinden değil, hipervizör üzerinden çalıştığı için firewall kuralları bu erişimi etkilemez. Fiziksel olarak makinenin başına oturmuş gibi düşünün.

Çoğu sağlayıcıda müşteri panelinde hizmetinizi açıp "Konsol" veya "VNC" butonuna basmanız yeterlidir; tarayıcıda siyah bir ekran ve login isteği açılır. Girdikten sonraki adımlar aşağıdaki bölümlerde.

Konsolda takılınan üç klasik nokta var, önceden bilmekte fayda var:

1. Klavye düzeni farklıdır. Konsol genellikle US düzeni kullanır. Şifrenizde : - / ? gibi karakterler varsa Türkçe Q klavyede bastığınız tuş başka bir karakter üretebilir. En pratik çözüm, şifreyi önce kullanıcı adı alanına yazıp gözle doğrulamak, sonra silip asıl alana geçmektir.
2. Kopyala-yapıştır çoğu zaman çalışmaz. Uzun komutları elle yazmak zorunda kalabilirsiniz. Bu yüzden aşağıdaki komutları mümkün olduğunca kısa tuttuk.
3. Root şifresini bilmiyor olabilirsiniz. Sunucuya anahtarla giriyorsanız root şifresi hiç belirlenmemiş olabilir. Bu durumda paneldeki "root şifresini sıfırla" seçeneğini kullanın; yoksa doğrudan rescue moda geçmeniz gerekir.

Konsola girdiğinizde ilk iş, hangi firewall'ın devrede olduğunu tespit etmektir:

# Hangi araç çalışıyor?
systemctl is-active ufw firewalld
command -v csf ufw nft iptables

# Aktif kural sayısına hızlı bakış
iptables -L INPUT -n --line-numbers | head -20

UFW Kilitlediyse Kuralı Nasıl Geri Alırım?#

UFW (Uncomplicated Firewall) Ubuntu ve Debian'da en yaygın seçenektir ve en sık şu şekilde kilitler: önce ufw default deny incoming yazılır, SSH için izin kuralı eklenmeden ufw enable çalıştırılır.

Konsoldan sırayla:

# 1) Mevcut kuralları numaralı olarak gör
ufw status numbered

# 2) Yanlış kuralı numarasıyla sil
ufw delete 3

# 3) SSH'ı açıkça izinli hale getir
ufw allow 22/tcp

# 4) Acil durumsa firewall'ı tamamen devre dışı bırak
ufw disable

Numaraları silerken yukarıdan aşağıya değil, aşağıdan yukarıya gidin: bir kuralı sildiğinizde altındaki kuralların numaraları kayar ve ikinci komutta yanlış satırı silersiniz.

Kural listesi tamamen içinden çıkılmaz hale geldiyse sıfırdan başlamak en hızlısıdır:

ufw --force reset
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw --force enable
ufw status verbose

ufw reset mevcut kuralları silmeden önce /etc/ufw/ altına yedek dosyalar bırakır; yanlışlıkla kaybettiğiniz bir kuralı oradan geri okuyabilirsiniz. UFW'nin kural mantığı, uygulama profilleri ve limit gibi ileri seçenekler için UFW güvenlik duvarı rehberine göz atabilirsiniz.

Sık atlanan bir ayrıntı: SSH'ı standart dışı bir porta taşıdıysanız ufw allow 22/tcp sizi kurtarmaz. Gerçekte dinlenen portu doğrulayın:

ss -tlnp | grep sshd
grep -ri '^port' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/ 2>/dev/null

Port değişikliğinin firewall tarafını unutmak, kilitlenmelerin en yaygın ikinci sebebidir; konuyu SSH portu değiştirme yazısında ayrıntılı ele almıştık.

iptables ve nftables Kurallarını Konsoldan Temizlemek#

Doğrudan iptables kullanıyorsanız kilitlenme genellikle iki hatadan doğar: -P INPUT DROP politikasının izin kurallarından önce verilmesi ya da yeni kuralın -A ile listenin sonuna eklenip, üstteki bir DROP satırının altında kalması.

Önce durumu görün, sonra en kaba ama en güvenli hamleyi yapın:

# Kuralları satır numaralarıyla listele
iptables -L -n -v --line-numbers

# Belirli bir kuralı sil (INPUT zincirinin 4. satırı)
iptables -D INPUT 4

# Acil kurtarma: politikaları aç ve tüm kuralları temizle
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F

IPv6 ayrı bir tablodur ve ayrıca temizlenmelidir. Sunucunuza IPv6 üzerinden bağlanıyorsanız sadece iptables temizlemek işe yaramaz:

ip6tables -P INPUT ACCEPT
ip6tables -F

Kalıcı kurallar, dağıtıma göre farklı dosyalarda tutulur. Konsoldan düzelttiğiniz kurallar yeniden başlatmada geri gelmesin diye bu dosyaları da güncellemeniz gerekir:

Modern sistemlerde arka planda nftables olabilir. iptables komutu çalışsa bile kuralları nft ile görmek daha net sonuç verir:

nft list ruleset

# Acil durumda tüm nftables kural setini boşalt
nft flush ruleset

nft flush ruleset sunucuyu tamamen korumasız bırakır; sadece erişimi geri kazanmak için, hemen ardından doğru kuralları yazmak şartıyla kullanın. Zincir mantığı, tablo yapısı ve doğru sıralama için iptables temelleri ve iptables ile güvenlik duvarı yazıları iyi bir başlangıç noktasıdır.

CSF Kilitlediyse Ne Yapmalı?#

CSF (ConfigServer Security and Firewall) cPanel/WHM sunucularında çok yaygındır ve kendine has kurtarma komutları vardır. En sık senaryo, TCP_IN listesinde SSH portunun bulunmaması ya da lfd'nin sizi kaba kuvvet denemesi sandığı için engellemesidir.

# Firewall'ı geçici olarak tamamen devre dışı bırak
csf -x

# IP'nizi engelli listesinden çıkar
csf -dr 198.51.100.25

# IP'nizi kalıcı izin listesine ekle
csf -a 198.51.100.25 ofis

# Düzelttikten sonra tekrar etkinleştir
csf -e

csf -x bir kilitlenmeyi anında çözer ama sunucuyu açıkta bırakır; sorunu düzeltir düzeltmez csf -e ile geri açın. Kalıcı yapılandırmayı /etc/csf/csf.conf içindeki TCP_IN satırından düzeltmeyi unutmayın:

TCP_IN = "20,21,22,25,53,80,110,143,443,465,587,993,995"

Değişiklikten sonra csf -r ile kuralları yeniden yükleyin. Engellenmenizin sebebi tekrarlayan başarısız girişlerse, arka plandaki mantığı anlamak için kaba kuvvet saldırısı yazısı yardımcı olur.

Konsol da Yoksa: Rescue Moddan Kurtarma#

Konsol açılmıyorsa, root şifresi bilinmiyorsa veya sistem hiç boot etmiyorsa rescue (kurtarma) modu son çaredir. Sağlayıcı sunucuyu geçici bir kurtarma imajıyla başlatır; diskiniz o imajın içinde sıradan bir blok cihaz olarak durur. Firewall kuralları yüklenmediği için dosyalara serbestçe müdahale edebilirsiniz.

Tipik akış:

# 1) Diskleri ve bölümleri gör
lsblk -f

# 2) Kök bölümü bağla (örnek: /dev/vda1)
mount /dev/vda1 /mnt

# 3) Chroot için gerekli sanal dosya sistemlerini bağla
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys

# 4) Sisteme geç
chroot /mnt /bin/bash

Chroot içindeyken firewall'ı açılışta başlamayacak şekilde kapatmak en güvenli yaklaşımdır; çünkü chroot içinde çalıştırdığınız iptables komutları asıl çekirdek tablolarını doğru şekilde yansıtmayabilir:

# UFW'yi açılışta devre dışı bırak
systemctl disable ufw

# Kalıcı iptables kurallarını devre dışı bırak
mv /etc/iptables/rules.v4 /etc/iptables/rules.v4.bozuk

# CSF'yi test moduna al
sed -i 's/^TESTING = "0"/TESTING = "1"/' /etc/csf/csf.conf

Ardından exit ile chroot'tan çıkın, bağladıklarınızı umount -R /mnt ile ayırın ve sunucuyu panelden normal moda alıp yeniden başlatın. Sistem açıldığında SSH tekrar erişilebilir olacaktır.

Rescue moda geçmeden önce mümkünse snapshot alın. Yanlış bir mv veya sed komutu, kurtarmaya çalıştığınız sistemi çok daha kötü bir duruma sokabilir.

Bir Daha Kilitlenmemek İçin: Zaman Aşımlı Geri Alma#

Asıl mesele burası. Riskli bir firewall değişikliğini uygularken, değişiklik başarısız olursa sistemin kendi kendini eski haline döndürmesini sağlayabilirsiniz. Kural yazmadan önce bir zamanlayıcı kurarsınız; erişiminiz devam ederse zamanlayıcıyı iptal edersiniz, kesilirse birkaç dakika içinde sunucu kendini kurtarır.

Yöntem 1: systemd zamanlayıcısı#

Ek paket gerektirmez, systemd kullanan her dağıtımda hazırdır ve bu yüzden varsayılan tercihiniz olmalıdır:

# 5 dakika sonra UFW'yi kapatacak tek seferlik bir iş kur
systemd-run --on-active=5min --unit=firewall-kurtarma ufw --force disable

# Bağlantınız hayatta kaldıysa işi iptal edin
systemctl stop firewall-kurtarma.timer

Aynı yaklaşımın iptables karşılığı:

systemd-run --on-active=5min --unit=fw-geri-al \
  /bin/sh -c 'iptables -P INPUT ACCEPT; iptables -F'

Zamanlayıcı mantığını daha ayrıntılı kullanmak isterseniz systemd timer ile zamanlanmış görevler yazısı konuyu genişletiyor.

Yöntem 2: at ile zamanlanmış geri alma#

at paketi kuruluysa (apt install at veya dnf install at) tek satırla halledebilirsiniz:

echo "ufw --force disable" | at now + 5 minutes

# Bekleyen işleri listele ve gerekirse iptal et
atq
atrm 1

Yöntem 3: iptables-apply ile onaylı uygulama#

Debian ve Ubuntu'da iptables paketiyle gelen iptables-apply, hazırladığınız kural setini uygular ve size "bu değişikliği koruyayım mı?" diye sorar. Belirtilen süre içinde cevap gelmezse, yani bağlantınız kesildiyse, kuralları otomatik olarak geri alır:

# Yeni kuralları bir dosyaya yaz, 30 saniyelik onay süresiyle uygula
iptables-apply -t 30 /etc/iptables/yeni-kurallar.v4

Yöntem 4: CSF TESTING modu#

CSF kullanıyorsanız yerleşik güvenlik ağı zaten var. /etc/csf/csf.conf içinde:

TESTING = "1"
TESTING_INTERVAL = "5"

TESTING = "1" iken CSF, belirtilen dakika aralığıyla iptables kurallarını temizleyen bir zamanlanmış görev bırakır. Yani hatalı bir kural sizi en fazla beş dakika dışarıda tutar. Yapılandırmayı doğrulayana kadar bu modda kalın, ancak canlıda kapatmayı unutmayın: TESTING açıkken CSF gerçek koruma sağlamaz ve lfd başlatılmaz.

Yöntem karşılaştırması#

İkinci oturumu açık tutma alışkanlığı#

Otomatik geri almadan bağımsız olarak, riskli bir değişiklikten önce ikinci bir SSH oturumu açın ve ona dokunmayın. Firewall değişiklikleri genellikle kurulu bağlantıları anında düşürmez; ESTABLISHED durumundaki oturumlar bağlantı takibi sayesinde ayakta kalabilir. Yeni oturum açılamıyorsa hâlâ elinizde çalışan bir kabuk vardır ve kuralı oradan geri alabilirsiniz.

Sunucuya paralel bir kapı bırakmak isterseniz, SSH'ı ikinci bir portta da dinletmek pratik bir sigortadır:

# /etc/ssh/sshd_config içine
Port 22
Port 2222

Bu portu firewall'da açık bırakır, birincil kuralı denerken yedek olarak kullanırsınız. Hangi portların dışarıya açık kalması gerektiğine dair genel çerçeve için sunucuda hangi portlar açık olmalı yazısına bakabilirsiniz.

Kendinizi Kilitleyen 5 Klasik Hata#

1. İzin kuralından önce varsayılan politikayı DROP yapmak. ufw default deny incoming veya iptables -P INPUT DROP komutunu SSH iznini eklemeden çalıştırmak, kilitlenmelerin bir numaralı sebebidir. Sıralamayı her zaman "önce izin, sonra politika" olarak kurun.
2. Standart dışı SSH portunu unutmak. 2222'de dinleyen bir sshd için 22 kuralı yazmak hiçbir işe yaramaz. Kuralı yazmadan önce ss -tlnp | grep sshd ile gerçek portu doğrulayın.
3. IPv6'yı atlamak. Yalnızca iptables yapılandırıp ip6tables tarafını boş bırakmak, "kural yazdım ama hâlâ girilebiliyor" ya da tam tersine "kural yazdım, artık giremiyorum" gibi kafa karıştırıcı sonuçlar üretir. İki tabloyu birlikte düşünün.
4. -A ile eklerken sıralamayı gözden kaçırmak. -A kuralı zincirin sonuna ekler. Üstte geniş bir DROP satırı varsa yeni izin kuralınıza hiç sıra gelmez. Bu durumda -I INPUT 1 ile başa eklemek gerekir.
5. Erişimi dinamik bir IP'ye kısıtlamak. ufw allow from 198.51.100.25 to any port 22 yazıp ertesi gün ev internetinizin IP'si değiştiğinde kapıda kalırsınız. Ev veya ofis IP'niz sabit değilse ya bloğu geniş tutun ya da anahtar tabanlı kimlik doğrulamaya güvenip portu açık bırakın, kaba kuvvet korumasını Fail2ban gibi bir araca devredin.

Sıkça Sorulan Sorular#

Firewall kuralı yüzünden kilitlendiğimde veri kaybı yaşar mıyım?#

Hayır. Firewall yalnızca ağ paketlerini filtreler; disk üzerindeki verilere, veritabanlarına veya çalışan servislere dokunmaz. Sunucu kilitli kaldığınız süre boyunca çalışmaya devam eder, siteler yayında kalır, e-postalar işlenmeye devam eder. Kaybettiğiniz tek şey yönetim erişimidir. Bu yüzden acele edip riskli kurtarma adımlarına atlamak yerine sakin biçimde konsol yolunu denemek en doğrusudur.

KVM konsolu ile SSH arasındaki fark nedir?#

SSH, sunucunun işletim sistemi üzerinde çalışan bir servise ağ üzerinden bağlanır; dolayısıyla ağın, firewall'ın ve sshd'nin sağlıklı olması gerekir. KVM veya VNC konsolu ise hipervizör seviyesinde sanal ekrana ve klavyeye bağlanır. Sunucunun ağı tamamen kapalı olsa, hatta işletim sistemi düzgün açılmasa bile konsol çalışır. Bu yüzden firewall kilitlenmelerinde ilk başvurulacak araçtır.

Rescue moda geçmek sunucuyu sıfırlar mı?#

Hayır. Rescue mod, sunucuyu diskinize dokunmadan geçici bir kurtarma imajıyla başlatır; kendi diskiniz bağlanmayı bekleyen bir cihaz olarak durur. Verileriniz olduğu gibi kalır. Riskli olan kısım, rescue mod içindeyken yaptığınız dosya değişiklikleridir. Bu yüzden diski bağlamadan önce snapshot almak ve yalnızca gerekli dosyalara dokunmak önerilir.

Zaman aşımlı geri alma kurmayı unuttum, şu an kilitliyim. Ne yapmalıyım?#

Sırayla ilerleyin: önce panelden KVM veya VNC konsolunu deneyin, çünkü en az müdahaleli ve en hızlı yöntem odur. Konsola giriş yapamıyorsanız root şifresini panelden sıfırlayıp tekrar deneyin. O da mümkün değilse rescue moda geçip diski bağlayarak firewall servisini devre dışı bırakın. Bu üç adımdan biri neredeyse her senaryoyu çözer.

Firewall'ı tamamen kapatmak güvenli mi?#

Sadece kurtarma anı için ve kısa süreliğine kabul edilebilir. Firewall kapalıyken sunucudaki tüm dinleyen servisler internete doğrudan açık kalır; otomatik tarayıcılar dakikalar içinde portlarınızı bulur. Erişimi geri kazandıktan sonra doğru kural setini yazıp firewall'ı hemen tekrar etkinleştirin. Ara dönemde en azından SSH'ı bilinen IP'lerle sınırlamak riski büyük ölçüde azaltır.

UFW ve iptables aynı anda kullanılabilir mi?#

Teknik olarak UFW zaten iptables ve nftables üzerine kurulu bir ön yüzdür, dolayısıyla ikisi aynı çekirdek tablolarını kullanır. Ancak elle karıştırmak kural sıralamasını öngörülemez hale getirir: UFW yeniden yüklendiğinde elle yazdığınız kurallar silinebilir. Tek bir araç seçip ona bağlı kalın. Ek kural gerekiyorsa UFW'nin /etc/ufw/before.rules dosyasını kullanmak çok daha sağlıklıdır.

Bulut sağlayıcısının kendi güvenlik grubu da beni kilitleyebilir mi?#

Evet, ve bu durum teşhisi zorlaştırır çünkü sunucunun içindeki kurallar tertemiz görünür. Sağlayıcı seviyesindeki güvenlik grubu paketleri makineye hiç ulaştırmadan düşürür, dolayısıyla belirti yine zaman aşımıdır. Sunucu içindeki firewall'ı tamamen kapattığınız halde hâlâ bağlanamıyorsanız, ilk bakacağınız yer paneldeki ağ veya güvenlik grubu kurallarıdır.