Linux Firewall: ufw, firewalld ve nftables Hangisi, Ne Zaman?

Kısa cevap: Linux’ta firewall katmanı çekirdekteki netfilter altyapısıdır; ufw, firewalld ve iptables komutu bunun üstündeki farklı arayüzlerdir. Yeni kurulumlarda alt katman nftables’tır. Basit bir sunucuda ufw yeterlidir, bölge mantığı ve çok arayüzlü kurgularda firewalld, karmaşık NAT ve büyük IP listelerinde doğrudan nftables tercih edilir.

Linux firewall katmanları: kim kimin üstünde çalışıyor?

Kafa karışıklığının kaynağı, aynı işi yapan çok sayıda komutun bulunmasıdır. Gerçekte tek bir motor vardır ve geri kalanı ona yazan arayüzlerdir.

Katman	Ne	Not
Çekirdek	netfilter	Paketleri gerçekten filtreleyen altyapı
Kural motoru	nftables (modern) / iptables (eski)	Modern dağıtımlarda iptables komutu iptables-nft olarak nftables’a yazar
Kolay arayüz	ufw, firewalld	İnsan tarafından yönetilebilir soyutlama
Uygulama	Docker, libvirt, Kubernetes	Kendi kurallarını doğrudan motora ekler

Buradaki en önemli satır sonuncusudur ve yazının ilerleyen bölümünde ayrıca ele alacağım: Docker gibi araçlar sizin arayüzünüzü (ufw) atlayarak doğrudan motora yazar. “ufw’de kapattım ama port hâlâ açık” sorununun tamamı bu satırdan doğar.

Hangi altyapının çalıştığını şöyle görürsünüz:

# iptables komutu hangi arka uca yazıyor
sudo iptables --version
# "iptables v1.8.x (nf_tables)" görüyorsanız alt katman nftables'tır

# Mevcut nftables kural setinin tamamı
sudo nft list ruleset

ufw, firewalld ve nftables: hangisini seçmeli?

Üçü de aynı işi yapar; fark, soyutlama seviyesi ve ekosistemdedir.

Ölçüt	ufw	firewalld	doğrudan nftables
Varsayılan geldiği yer	Ubuntu, Debian	RHEL, Rocky, AlmaLinux, Fedora	Her yerde (alt katman)
Öğrenme eşiği	En düşük	Orta (zone kavramı)	En yüksek
Bölge (zone) desteği	Yok	Var, güçlü	Elle kurulur
Çalışırken kural değişimi	Yeniden yükleme	Runtime + permanent ayrımı	Atomik yükleme
Karmaşık NAT / set	Sınırlı	Orta	Tam kontrol
Kural setini dosyada versiyonlama	Zor	Orta	Kolay ve okunabilir

Pratik seçim kuralım şudur:

• Tek WAN arayüzü, birkaç açık port, Debian/Ubuntu: ufw. Fazlasına gerek yok.
• RHEL ailesi veya birden fazla güvenlik bölgesi (iç ağ, DMZ, VPN): firewalld.
• Yönlendirme, çok sayıda NAT kuralı, binlerce IP’lik engelleme listesi, kural setini git’te tutma isteği: doğrudan nftables.

Bir kural değişmez: aynı sunucuda ikisini birlikte çalıştırmayın. ufw ve firewalld aynı motora yazdıkları için birbirlerinin kurallarını beklenmedik biçimde etkiler ve hangi kuralın neden orada olduğunu takip edilemez hâle getirir.

Varsayılan kapalı firewall politikası nasıl kurulur?

Doğru politika her zaman aynıdır: gelen trafik varsayılan olarak reddedilir, giden serbesttir, yalnız ihtiyaç duyulan portlar açılır.

ufw ile

Sıralama kritik: önce SSH’a izin verin, sonra politikayı değiştirin, en son etkinleştirin.

sudo ufw allow 22/tcp                # ÖNCE bu
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Yönetim portunu tek bir kaynağa kısıtlamak çok daha güçlüdür:

sudo ufw delete allow 22/tcp
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp

firewalld ile

firewalld’de kurallar bir bölgeye eklenir ve çalışan yapılandırma ile kalıcı yapılandırma ayrıdır. --permanent olmadan yapılan değişiklik yeniden başlatmada kaybolur; bu ayrımı atlamak en sık yapılan hatadır.

# Aktif bölgeyi gör
sudo firewall-cmd --get-active-zones

# Servisleri kalıcı olarak aç
sudo firewall-cmd --permanent --zone=public --add-service=ssh
sudo firewall-cmd --permanent --zone=public --add-service=https

# Yönetimi tek kaynağa kısıtla (rich rule)
sudo firewall-cmd --permanent --zone=public \
  --add-rich-rule='rule family="ipv4" source address="203.0.113.10" service name="ssh" accept'

# Kalıcı ayarları çalışan yapılandırmaya yükle
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

Doğrudan nftables ile

nftables’ın en büyük avantajı, kural setinin tek bir okunabilir dosya olmasıdır. Bu dosya sürüm kontrolüne konabilir, gözden geçirilebilir ve atomik olarak uygulanır.

/etc/nftables.conf:

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
    # Yönetim erişimine izinli kaynaklar (tek yerden yönetilir)
    set yonetim_ip {
        type ipv4_addr
        elements = { 203.0.113.10, 198.51.100.20 }
    }

    chain input {
        type filter hook input priority filter; policy drop;

        # Kurulu bağlantılar ve döngü arayüzü
        ct state established,related accept
        ct state invalid drop
        iif lo accept

        # ICMP (teşhis için gerekli, tamamen kapatmayın)
        ip protocol icmp accept
        ip6 nexthdr ipv6-icmp accept

        # Yönetim: yalnız listedeki kaynaklardan SSH
        ip saddr @yonetim_ip tcp dport 22 accept

        # Genel servisler
        tcp dport { 80, 443 } accept

        # Reddedilenleri sınırlı biçimde logla
        limit rate 5/minute log prefix "nft-drop: "
    }

    chain forward {
        type filter hook forward priority filter; policy drop;
    }

    chain output {
        type filter hook output priority filter; policy accept;
    }
}

Uygulama ve kalıcılık:

# Sözdizimini kontrol et (uygulamadan önce)
sudo nft -c -f /etc/nftables.conf

# Uygula
sudo nft -f /etc/nftables.conf

# Açılışta yüklensin
sudo systemctl enable --now nftables

set yapısı bu örneğin en değerli parçasıdır. Yönetim IP’lerinizi tek bir kümede toplarsınız; yeni bir IP eklemek kural yazmayı değil, kümeye eleman eklemeyi gerektirir. Binlerce IP’lik engelleme listelerinde bu yapı, tek tek kural yazmaya göre karşılaştırılamayacak kadar verimlidir; MikroTik tarafındaki address-list mantığının doğrudan karşılığıdır ve MikroTik firewall yazısında anlattığım brute force savunmasının Linux’taki eşdeğeri budur.

Firewall değiştirirken kendinizi kilitlememek için ne yapmalı?

Uzak bir sunucuda firewall değiştirmek, dalın ucunu keserken üstünde oturmaya benzer. İki koruma yöntemi:

1. Konsol erişimini önceden test edin. Sağlayıcının web konsolu veya kendi donanımınızda IPMI/KVM çalışıyor mu, giriş bilgileri elinizde mi? Test edilmemiş bir konsol yoktur.

2. Otomatik geri alma zamanlayıcısı kurun. Riskli bir kural setini uygulamadan önce, on dakika sonra eski kural setine dönecek bir görev tanımlayın:

# Mevcut kural setini yedekle
sudo nft list ruleset > /root/nft-yedek.conf

# 10 dakika sonra otomatik geri dön (bağlantı koparsa sigorta)
echo "nft -f /root/nft-yedek.conf" | sudo at now + 10 minutes

Yeni kural setiyle bağlantınız devam ediyorsa zamanlayıcıyı iptal edersiniz (atq ile iş numarasını bulup atrm ile silin). Bağlantınız koparsa sunucu on dakika içinde eski hâline döner. Bu basit alışkanlık, uzaktan yönetilen sunucularda çok sayıda gereksiz veri merkezi ziyaretini önler.

Docker firewall kurallarını neden deliyor?

Bu, Linux sunucu güvenliğindeki en yaygın ve en sinsi tuzaktır. Senaryo şöyle: ufw’yi doğru kurdunuz, yalnız 80 ve 443 açık. Sonra bir konteyneri şöyle çalıştırdınız:

docker run -d -p 8080:80 nginx

Şimdi ufw status çıktısında 8080 görünmüyor, ama sunucunun IP’sine 8080 portundan dışarıdan erişilebiliyor. Sebep şudur: Docker, yayımlanan portlar için doğrudan çekirdeğin NAT tablosuna kendi kurallarını ekler ve bu kurallar ufw’nin filtre zincirinden önce değerlendirilir. ufw sizin için görünmez hâle gelir.

Doğru çözüm sıraya göre:

1. Portu yalnız yerel arayüze yayımlayın. Konteyner dışarıya doğrudan açılmayacaksa adres belirtin:

# Yanlış: tüm arayüzlerde dışarı açılır
docker run -d -p 8080:80 nginx

# Doğru: yalnız yerelden erişilebilir
docker run -d -p 127.0.0.1:8080:80 nginx

Bu tek değişiklik, sorunun büyük çoğunluğunu kaynağında çözer. Dışarıya sunulması gereken servisler yerel porta bağlanır ve bir ters vekil sunucu üzerinden yayımlanır; ters vekil seçenekleri için nginx, Traefik ve Caddy karşılaştırmasına bakın.

2. Hiç yayımlamayın. Konteynerler birbirleriyle Docker ağı üzerinden konuşuyorsa port yayımlamaya gerek yoktur; yalnız dışarı bakan servis yayımlanır. Ayrıntısı Docker ağ yapılandırması yazısında.

3. Docker’ın iptables yönetimini kapatmak teknik olarak mümkündür ama önerilmez: kapattığınızda konteyner ağının NAT ve yönlendirme kurallarını elle yazmak zorunda kalırsınız ve tek bir eksik kural tüm konteyner ağını bozar. Bunu yalnız ne yaptığını tam bilen ve kural setini versiyonlayan ortamlarda yapın.

Kontrol alışkanlığı: konteyner çalıştırdıktan sonra dışarıdan gerçekten ne göründüğünü doğrulayın.

# Sunucuda dinleyen portlar ve hangi adrese bağlı oldukları
sudo ss -tulpn | grep LISTEN

# 0.0.0.0:PORT görüyorsanız o port TÜM arayüzlerde açıktır

127.0.0.1:8080 ile 0.0.0.0:8080 arasındaki fark, bu yazının tek cümleyle en pratik çıktısıdır.

Firewall kuralları nasıl doğrulanır ve izlenir?

Firewall yazmak yarısıdır; ne yaptığını görmek diğer yarısı.

# Hangi kural kaç paket saydı (etkisiz kuralları bulmanın yolu)
sudo nft list ruleset -a

# ufw'nin ürettiği sayaçlar
sudo ufw status numbered

# Reddedilen trafiği canlı izle (nft log prefix ile eşleşir)
sudo journalctl -kf | grep "nft-drop"

Log kuralına mutlaka hız sınırı koyun (örnekteki limit rate 5/minute). Sınırsız log yazan bir firewall kuralı, yoğun bir taramada diski doldurur ve sunucuyu kendisi durdurur. Üretim sunucularında gördüğüm kesintilerin şaşırtıcı bir kısmı saldırıdan değil, saldırıyı loglamaktan kaynaklanır.

Disk doluluğu ve kural sayaçlarını düzenli izlemek için sunucu izleme rehberine bakın.

Kontrol listesi

• Gelen trafik varsayılan olarak reddediliyor (policy drop veya default deny incoming)
• Yalnız bir firewall arayüzü kullanılıyor (ufw veya firewalld, ikisi birden değil)
• SSH kuralı politika değişikliğinden önce eklendi
• Yönetim portu kaynak IP kısıtlı veya VPN arkasında
• ICMP tamamen kapatılmadı (teşhis için gerekli)
• Docker portları 127.0.0.1: ile yayımlanıyor, dışa açık olanlar bilinçli
• ss -tulpn çıktısındaki her 0.0.0.0 bağlanması açıklanabiliyor
• Log kuralında hız sınırı var
• Kural seti dosyada ve sürüm kontrolünde (nftables kullanılıyorsa)
• Konsol/IPMI erişimi test edildi, geri alma sigortası biliniyor

Firewall, sunucu güvenliğinin yalnız ağ ayağıdır. Erişim tarafını SSH sertleştirme rehberi, ilk kurulum sırasını VPS ilk 30 dakika listesi, tüm katmanların bütününü Linux sunucu yönetimi yol haritası tamamlar. Ağ kenarındaki filtrelemeyi router üzerinde yapıyorsanız MikroTik firewall ve VLAN izolasyonu yazıları aynı savunmanın ağ ayağını anlatır.

Kurumsal ölçekte firewall politikası tasarımı ve denetimi için siber güvenlik ve network yönetimi hizmet sayfalarına bakabilirsiniz.

Kaynaklar

• nftables wiki (netfilter projesi resmi belgeleri)
• nft manual page (komut ve ifade referansı)
• Docker: Packet filtering and firewalls (Docker ve firewall etkileşimi)