ufw kilitlenmesi sonrası sunucu erişimi nasıl geri alınır

Erişimi geri kazanma

Eğer ufw sizi VPS sunucunuzdan dışarı kilitlediyse, erişimi geri kazanmanın tek yolu sağlayıcı konsolu veya kurtarma modudur; çünkü engelleme kuralı aktif hale geldiğinde SSH tabanlı bir çözüm yolu kalmaz. Çekirdek, paketlerinizi sshd sürecine ulaşmadan önce düşürdüğü için giriş yapacak veya ağ üzerinden onaracak bir yer kalmaz. Sağlayıcınızın kontrol panelinden konsolu açın, komut satırına giriş yapın ve şu komutu çalıştırın:

sudo ufw disable

Firewall stopped and disabled on system startup çıktısını görmelisiniz. Yeni SSH bağlantıları bir veya iki saniye içinde tekrar çalışır hale gelir. Yapılandırdığınız hiçbir şey kaybolmaz: disable kuralları çekirdekten kaldırır ve /etc/ufw/ufw.conf içerisine ENABLED=no yazar; kurallarınız ise bir sonraki ufw enable komutunu beklemek üzere /etc/ufw/user.rules dosyasında diskte kalmaya devam eder.

Sunucuyu yeniden başlatıp düzelmesini beklemeyin. ufw açılışta kendiliğinden başladığı için ENABLED=yes komutu, ağ ayağa kalkmadan önce aynı kural setinin tekrar yüklenmesi anlamına gelir. Yeniden başlatma, ufw kaynaklı bir kilitlenme durumunda hiçbir şeyi değiştirmez.

Konsol, sahip olmadığınız bir parola gerektirebilir

Web konsolu (VNC veya seri bağlantı), makineye fiziksel olarak bağlı bir klavye işlevi görür. Bu bir ağ yolu değildir, dolayısıyla hiçbir güvenlik duvarı kuralı bunu engelleyemez. Yerel bir oturum açma işlemi gerektirir; yalnızca SSH anahtarı kullanılan kurulumların başarısız olduğu nokta burasıdır: Eğer sudo kullanıcınız için hiçbir zaman bir parola belirlemediyseniz ve root girişi kilitliyse, konsol yanıt veremeyeceğiniz bir istem görüntüler. SSH erişiminiz varken hemen şimdi bir parola belirleyin: sudo passwd yourname. Çoğu yönetim paneli root parolasını sıfırlayabilir, ancak bu işlem genellikle yeniden başlatma gerektirir.

Konsol kullanılamaz durumdaysa, sağlayıcının kurtarma sistemini (rescue system) başlatın. Bu sistem, diskiniz bağlı değilken çalışan ayrı bir işletim sistemidir; böylece ufw servisini dışarıdan devre dışı bırakabilirsiniz.

lsblk
sudo mount /dev/vda1 /mnt
sudo sed -i 's/^ENABLED=yes/ENABLED=no/' /mnt/etc/ufw/ufw.conf
sudo umount /mnt

Önce lsblk komutunu çalıştırın, çünkü root bölümü her zaman /dev/vda1 olmayabilir. Normal sisteme yeniden başlatma yaptığınızda, siz el ile etkinleştirene kadar ufw kapalı kalacaktır.

Minimal kurtarma sırası

Bu sırayı takip edin. İlk dört adım güvenlidir. Beşinci adım ise risklidir.

1. Kuralları kaldırmak ve erişiminizi geri kazanmak için sudo ufw disable komutunu kullanın.
2. Eklediğiniz kuralları, onları ekleyen komutlar biçiminde yazdırmak için sudo ufw show added komutunu kullanın. Bu komut, ufw status komutunun aksine ufw devre dışıyken de çalışır.
3. sshd servisinin gerçekten dinlediği portu doğrulamak için sudo sshd -T | grep -i '^port' komutunu kullanın. Siz değiştirmediyseniz, bu komut port 22 çıktısını verecektir.
4. Bir sonraki etkinleştirme işleminde kilitlenmemek için, gerçek portunuzu kullanarak sudo ufw allow 22/tcp komutunu çalıştırın.
5. Önce bir geri alma (rollback) planlayarak sudo ufw enable komutunu çalıştırın. Bununla ilgili ayrıntılar bu sayfanın devamında yer almaktadır.

ufw reset komutu gerçekte ne yapar

ufw reset ilk adım değil, son çaredir. Güvenlik duvarını devre dışı bırakır, tüm kural dosyalarını yedekler ve varsayılan ayarları gelen bağlantıları reddedecek, giden bağlantılara izin verecek şekilde döndürür. Her dosya için bir yedekleme satırı yazdırır:

Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'

Sıfırlama işleminden sonra hiçbir izin kuralı kalmaz. Bu nedenle komutu SSH üzerinden değil, konsol üzerinden çalıştırın ve tekrar etkinleştirmeden önce SSH kuralını ekleyin. Bu yedekler düz metin dosyalarıdır. sudo grep -n dport /etc/ufw/user.rules.20260813_101500 eski kuralların ne olduğunu gösterir; yanlışlıkla sildiğiniz bir kural kümesini bu şekilde yeniden oluşturabilirsiniz.

ufw kurallarını nerede tutar

Dosyaları okumak, hafızadan tahmin yürütmekten daha güvenilirdir. Beş farklı yol, sistemin tüm durumunu barındırır:

• /etc/ufw/user.rules ve /etc/ufw/user6.rules: Eklediğiniz kurallar, değerlendirilme sırasına göre burada bulunur.
• /etc/ufw/before.rules ve /etc/ufw/after.rules, ayrıca 6 varyantları: ufw'nin kurallarınızın etrafına sardığı çerçeve; buna yerleşik bağlantılar için kabul kuralları ve loopback kuralları dahildir.
• /etc/default/ufw: Varsayılan politikalar ve IPV6 anahtarı.
• /etc/ufw/ufw.conf: ENABLED ve günlük seviyesi.
• /var/log/ufw.log: Günlük kaydı açık olduğunda engellenenler.

ufw, bir dosyayı yeniden yazmadan önce zaman damgalı bir kopyasını oluşturur, bu nedenle ls /etc/ufw/ dizini user.rules.20260813_101500 gibi isimlerle dolar. Bu sizin geri alma geçmişinizdir ve değişiklikleri geri almaya başlamadan önce okunması faydalıdır.

Disk üzerindekinden ziyade çekirdeğe (kernel) neyin yüklendiğini görmek için sudo ufw show raw veya sudo iptables -S ve sudo ip6tables -S komutlarını kullanın. Ubuntu 22.04 ve 24.04 sürümlerinde bu komutlar nft destekli sürümlerdir, bu nedenle sudo nft list ruleset aynı kuralları daha yeni bir sözdizimiyle yazdırır.

Neden ufw'yi etkinleştirmek SSH oturumumu sonlandırdı?

Varsayılan gelen trafik politikası deny şeklindedir. SSH portunuz için bir kural tanımlamadan ufw'yi etkinleştirmek, tüm yeni bağlantıları keser. ufw sizi şu şekilde uyarır: Command may disrupt existing ssh connections. Proceed with operation (y|n)? y yanıtını vermek ve SSH için izin kuralı tanımlamamak, bu sayfadaki tüm sorunların en yaygın nedenidir.

Kafa karıştırıcı olan kısım gecikmedir. /etc/ufw/before.rules, kendi kurallarınız işlenmeden önce ESTABLISHED,RELATED durumundaki paketleri kabul eder; bu nedenle komutu girdiğiniz oturum normal şekilde çalışmaya devam eder. Kilitlenme durumu yalnızca bir sonraki bağlantıda ortaya çıkar; bu da saatler sonra olabilir ve o ana gelindiğinde güvenlik duvarı değişikliği artık bağlantılı görünmez. Her zaman ikinci bir SSH oturumu açın ve ilkini kapatmadan önce çalıştığını doğrulayın.

Bir ilke değişikliğinden sonra apt ve DNS neden çalışmayı durdurdu?

sudo ufw default deny outgoing giden DNS (domain name system) sorgularını ve giden HTTP trafiğini engeller; bu nedenle isim çözümleme başarısız olur ve paket güncellemeleri durur. apt update, Temporary failure resolving 'archive.ubuntu.com' hatasını raporlar. Gelen SSH bağlantıları çalışmaya devam eder, çünkü bu bağlantılara verilen yanıtlar ESTABLISHED durumundadır ve güvenlik duvarı kurallarından geçer; bu durum, güvenlik duvarı aslında sorunun kaynağı olmasına rağmen masum görünmesine neden olur.

Eğer giden trafiği engelleyen bir ilke (deny outgoing policy) uygulamak istiyorsanız, makinenin ihtiyaç duyduğu trafiğe izin verin:

sudo ufw allow out 53
sudo ufw allow out 80/tcp
sudo ufw allow out 443/tcp
sudo ufw allow out 123/udp

Son kural eklenmediği takdirde sistem saati kayar ve yanlış saat, TLS (transport layer security) sertifika doğrulamasını bozar; bu nedenle curl port hatalarından ziyade tarih hataları nedeniyle başarısız olmaya başlar. Bu belirti değişiklikten günler sonra ortaya çıkar; bu yüzden giden trafiği engelleme ilkesi, bir kez kurup bıraktığınız makineler için değil, sürekli izlediğiniz makineler için uygundur.

Ufw kuralım neden hiçbir zaman eşleşmiyor?

ufw, kullanıcı kurallarını sırayla değerlendirir ve ilk eşleşmede durur. Geniş kapsamlı bir allow kuralından sonra eklenen bir deny kuralı hiçbir zaman tetiklenmez; çünkü paket hakkındaki karar zaten ilk izin kuralıyla verilmiştir. Kuralların sırasını numaralı olarak görüntüleyin ve ardından kuralı ihtiyaç duyduğunuz konuma ekleyin.

sudo ufw status numbered
sudo ufw insert 1 deny from 203.0.113.10 to any port 22
sudo ufw delete 4

sudo ufw --dry-run allow 8080/tcp komutu, yazılacak kuralları herhangi bir değişiklik yapmadan ekrana basar. Bu, bir kuralı canlıya almadan önce okumanın güvenli yoludur.

Bir diğer tuzak ise uygulama profillerinde yatar. sudo ufw allow OpenSSH, /etc/ufw/applications.d/openssh-server içindeki profili kullanır ve bu profil 22 numaralı port anlamına gelir. Eğer sshd 2222 portunu dinliyorsa, bu kural kimsenin kullanmadığı bir portu açar ve kurallar doğru görünmesine rağmen sistemin dışında kalmanıza neden olur. Portu değiştirdiğinizde kuralda port numarasını kullanın. Söz diziminin geri kalanı bir VPS için ufw güvenlik duvarı temelleri bölümünde ele alınmıştır.

IPv4 kuralları neden gördüklerimi açıklamıyor?

Trafiğin yarısı IPv4 olmadığı için bu durum yaşanır. Ubuntu, IPV6=yes paketini /etc/default/ufw içinde sunar ve ufw, /etc/ufw/user6.rules dosyasında paralel bir v6 kural kümesi tutar. ufw allow from 203.0.113.10 to any port 22 gibi bir IPv4 adresiyle yazılan kural, v6 tarafında hiçbir kural oluşturmaz. Eğer VPS sunucunuzun bir AAAA kaydı varsa, istemciniz IPv6 protokolünü tercih eder ve ufw status doğru görünen bir kural gösterirken bağlantınız zaman aşımına uğrar. Aradaki farkı ssh -4 user@host ile ssh -6 user@host karşılaştırması yaparak test edin. İlki çalışıyor ancak ikincisi çalışmıyorsa, sorun v6 kural kümesindeki eksikliktir.

Tersi durum güvenlik açısından daha kötüdür. IPV6=no ayarı yapıldığında, ufw ip6tables dosyasını yönetmez; bu nedenle v6 politikası çekirdeğin varsayılan değeri olan ACCEPT durumunda kalır. Kapalı olduğunu düşündüğünüz bir port, IPv6 adresi üzerinden yanıt verir ve hiçbir ufw komutu bunu raporlamaz. Durumu sudo ip6tables -S ve ss -tlnp ile kontrol edin ve konunun tamamını anlamak için ufw IPv6 portlarını nasıl yönetir belgesini okuyun.

Docker, ufw tarafından engellenen bir portu neden açık tutar?

Docker, nat tablosuna DNAT (hedef ağ adresi çevirisi) kuralları yazarak ve kendi zincirini FORWARD içine ekleyerek bir portu yayınlar. ufw kuralları INPUT yolunda bulunur. Bir container'a gelen trafik, ana makineye teslim edilmek yerine doğrudan yönlendirildiği için, engelleme kuralınızın bulunduğu zincire hiçbir zaman ulaşmaz. ufw aktif olsa ve her şeyi engellese bile docker run -p 5432:5432 internetten erişilebilir durumdadır.

sudo iptables -t nat -S DOCKER

En basit çözüm, portu loopback üzerinde yayınlamaktır: -p 127.0.0.1:5432:5432, ana makine tarafını 127.0.0.1 adresine bağlar; bu durumda ufw ayarları ne olursa olsun dışarıdan hiçbir erişim sağlanamaz. Docker portlarını ufw çevresinde yayınlama başlıklı bölüm, servisin dış dünyaya açık olması gereken durumları ele almaktadır.

Kuralı uygulamadan önce geri alma işlemini planlayın

Güvenlik duvarı yönetilebilirliğini sağlayan alışkanlık budur. Riskli herhangi bir değişiklikten önce, geri alma işlemini planlayın. Değişiklik erişiminizi kısıtlarsa, makine beş dakika içinde kendini düzeltir ve konsolu açmak zorunda kalmazsınız.

sudo systemd-run --on-active=5m --unit=ufw-rollback /usr/sbin/ufw disable

systemd Running timer as unit: ufw-rollback.timer çıktısını verir. Şimdi değişikliğinizi yapın. Değişiklikten sonra yeni bir SSH oturumu açabiliyorsanız, geri alma işlemini iptal edin:

sudo systemctl stop ufw-rollback.timer

Eğer yeni bir oturum açamıyorsanız, bekleyin. ufw kendiliğinden kapanır ve bir sonraki denemenizde bağlantı sağlanır. Klasik shutdown -r +5 hilesi ufw ile işe yaramaz, çünkü ufw önyükleme sırasında aynı kural kümesini tekrar yükler.

İkinci bir erişim yolu bulundurun

• İhtiyaç duymadan önce sağlayıcı konsoluna bir kez giriş yapın ve parolanın çalıştığını doğrulayın. Daha önce test etmediğiniz bir konsol, yedek sayılmaz.
• Kendi anahtarına sahip ikinci bir sudo kullanıcısı bulundurun; böylece hatalı bir authorized_keys dosyası erişiminizin tamamen kesilmesine neden olmaz.
• Sağlayıcınızın panelinde, ufw'den bağımsız bir ağ güvenlik duvarı çalıştırıp çalıştırmadığını kontrol edin. Bu güvenlik duvarı aynı portları engeller ve ufw status bunu hiçbir zaman raporlamaz.
• Eğer IP adresiniz dinamikse, ufw allow from <your home address> adresini tek SSH kuralınız yapmayın. Sağlayıcınız bu adresi gece değiştirebilir ve erişiminizi kaybedebilirsiniz.

Tüm bunları yapmanın en uygun zamanı, yeni bir VPS üzerindeki ilk on dakika içinde gerçekleştirilen diğer kurulum işlemleriyle birlikte, sunucu henüz yeniyken yapılan zamandır.

Reddedilen veya zaman aşımına uğrayan bağlantılar hangi katmanın başarısız olduğunu gösterir

Connection refused, bir paketin sunucuya ulaştığını ve bir şeyin TCP sıfırlama (reset) yanıtı gönderdiğini ifade eder. Ağ yolu sorunsuzdur; bu nedenle sshd durdurulmuş veya farklı bir portta dinleme yapıyor olabilir. Güvenlik duvarı nadiren bu durumun nedenidir, çünkü ufw varsayılan olarak paketleri reddetmek yerine düşürür (drop).

Connection timed out, hiçbir yanıtın dönmediği anlamına gelir. Bu durum bir düşürme (drop) işleminin işaretidir: ufw, sağlayıcı ağ güvenlik duvarı veya yanlış bir adres söz konusu olabilir. Bu iki hatayı doğru okumak, bir saatlik tahmin yürütme süresinden tasarruf sağlar ve connection refused ile timed out arasındaki fark konusu, geriye kalan durumları detaylıca ele alır.

Turn logging on before the next change

sudo ufw logging on
sudo tail -f /var/log/ufw.log

A blocked packet appears like this:

[UFW BLOCK] IN=eth0 OUT= SRC=203.0.113.10 DST=192.0.2.5 LEN=60 PROTO=TCP SPT=51234 DPT=22 WINDOW=64240 SYN

DPT=22 with your own address in SRC= is proof that ufw is the thing blocking you, not the network and not sshd. On a minimal image with no rsyslog there is no /var/log/ufw.log, and the same lines come from sudo journalctl -k | grep UFW. ufw rate limits its own logging rules, so a missing line is not proof that a packet was allowed.

Eklenmemiş kurallar bulursanız

Kendi kendine değişen bir kural kümesi, bir güvenlik duvarı sorunu değildir. root yetkisine sahip bir kullanıcı tarafından yazılmıştır. Hangi sudo komutlarının hangi hesap altında çalıştırıldığını görmek için sudo grep ufw /var/log/auth.log komutunu, bu zaman damgası civarındaki girişleri incelemek için ise last komutunu çalıştırın. Hesaplar tanıdığınız kimseyle eşleşmiyorsa, güvenlik duvarında hata ayıklamayı bırakın ve bunun yerine ele geçirilmiş bir VPS için kontrol listesini uygulayın. Başkasının kontrolündeki bir sunucuda güvenlik duvarını yeniden etkinleştirmek, sorunu yalnızca gizler.

Yapılandırmayı geri yükleme

Sorunun nedenini belirledikten sonra, kilitlenme riskini tekrarlamayacak şekilde ufw servisini tekrar etkinleştirin. Mevcut SSH portunuza izin verin, geri alma işlemini planlayın, servisi etkinleştirin, ardından farklı bir terminalden yeni bir SSH oturumu açarak bağlantıyı doğrulayın. Yalnızca yeni oturumun başarılı olduğundan emin olduktan sonra üzerinde çalıştığınız mevcut oturumu kapatın. Günlük kaydını bir gün boyunca açık bırakın; çünkü günlük kayıtları, user.rules dosyasını okumaktan çok daha hızlı bir şekilde hangi bağlantıya izin vermeyi unuttuğunuzu size gösterecektir.

FAQ

ufw disable kurallarımı siler mi?

Hayır. disable, kurallar kümesini çekirdekten kaldırır ve ENABLED=no içeriğini /etc/ufw/ufw.conf dosyasına yazar. Kurallarınız /etc/ufw/user.rules ve /etc/ufw/user6.rules içinde kalmaya devam eder; güvenlik duvarı devre dışıyken sudo ufw show added komutu bunları listeler. ufw reset, kuralları temizleyen komuttur; bu komut her dosyayı yedekler ve Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500' gibi bir satır çıktısı verir.

VPS'i yeniden başlatmak ufw kısıtlamasını kaldırır mı?

Hayır. ufw, /etc/ufw/ufw.conf içindeki ENABLED=yes üzerinden önyükleme sırasında başlar; bu nedenle ağ bağlantısı kurulmadan önce aynı kurallar yüklenir ve tekrar kısıtlanırsınız. Yeniden başlatma işlemi yalnızca ufw'yi kapattıktan sonra veya diski mount ederek kurtarma modunda ilgili dosyayı düzenledikten sonra işe yarar. Sağlayıcı konsolunu kullanın ve orada sudo ufw disable komutunu çalıştırın.

ufw portu engellediği halde Docker container'ıma neden erişilebiliyor?

Docker, yayınlanan her port için kendi DNAT ve FORWARD kurallarını yazar. Bu trafik, ana makineye (host) teslim edilmek yerine doğrudan container'a yönlendirilir; bu nedenle ufw deny kuralınızın bulunduğu INPUT zincirinden hiçbir zaman geçmez. Port yalnızca ana makine içinse -p 127.0.0.1:5432:5432 ile loopback üzerinden yayınlayın ve Docker'ın ne kurduğunu sudo iptables -t nat -S DOCKER ile inceleyin.

Konsol şifrem yok ve kurtarma moduna erişemiyorum. Seçeneklerim nelerdir?

Kalan seçenekler sağlayıcınıza bağlıdır: genellikle sunucuyu yeniden başlatan kontrol paneli üzerinden şifre sıfırlama veya diski başka bir instance'a bağlayarak /etc/ufw/ufw.conf dosyasını oradan düzenleme. Sunucuyu yeniden oluşturmadan önce destek ekibiyle görüşün; çünkü yeniden oluşturma işlemi üzerindeki verileri siler. Sisteme tekrar erişim sağladığınızda sudo passwd yourname komutunu çalıştırın ve konsol girişini bir kez test edin; böylece bir sonraki kısıtlamada sadece iki dakikanızı harcamış olursunuz.