VPS Güvenlik Duvarı: UFW, firewalld ve iptables

VPS güvenlik duvarı: araç seçimi ve erişim politikası

İnternete açılan bir VPS, siteniz henüz duyurulmamış olsa bile otomatik port taramalarına ve bağlantı denemelerine maruz kalabilir. SSH, HTTP/HTTPS ve SMTP gibi servislerin dışarıdan erişilebilirliği, dinleme adreslerine ve ağ kurallarına bağlıdır; bu portlar her sunucuda kendiliğinden açık değildir. VPS üzerinde yalnızca gerekli servislere izin veren bir güvenlik duvarı kural seti, gereksiz dış erişimi sınırlar.

Bu yazıda, VPS üzerinde en sık kullanılan üç yaklaşımı; ufw, firewalld ve iptables araçlarını yan yana koyup karşılaştırmalı şekilde ele alacağız. Amacımız; “Hangi aracı seçmeliyim?”, “Varsayılan kural seti nasıl olmalı?”, “IPv6 kurallarını nasıl ele almalıyım?” sorularını yanıtlamak ve sunucunuzun dağıtımına, servislerine ve erişim ihtiyaçlarına uyarlayabileceğiniz örnek komutlar sunmak.

Temel güvenlik duvarı kavramları (araçlardan bağımsız)

Önce araçlardan bağımsız birkaç temel kavramı netleştirelim; böylece ufw, firewalld ve iptables komutları size daha anlamlı gelecektir.

• Stateful filtreleme: Bağlantı takibi ESTABLISHED ve RELATED trafiği ayırt eder. Mevcut bir SSH oturumunun sürmesi yeni bağlantıya izin verildiğini kanıtlamaz.
• INPUT / OUTPUT / FORWARD: Sırasıyla sunucuya gelen, sunucudan çıkan ve sunucunun yönlendirdiği trafik. Konteyner, VPN ve yönlendirici trafiği yalnızca INPUT ile yönetilemez.
• Varsayılan politika: Eşleşmeyen trafiğe uygulanır. Host örneklerinde gelen erişim sınırlanır, giden trafik açıktır. firewalld’de default zone hedefi, ICMP istisnasıyla REJECT benzeri davranır; her araçta aynı DROP komutu kullanılmaz.
• IPv4 ve IPv6: Sunucunuzda IPv6 aktifse, erişim politikasını her iki ailede doğrulayın.
• Port ve servis: TCP/UDP trafiğinde portlar (80/tcp, 443/tcp gibi) filtreleme ölçütlerinden biridir; güvenlik duvarı kuralları IP adresi, protokol ve bağlantı durumunu da değerlendirebilir. firewalld servisleri bir veya birkaç port/protokol tanımı içerebilir.

Güvenlik duvarının temel mantığı; “gerekeni özellikle aç, gerisini kapat”tır. Bu bakış açısını koruduğunuz sürece, hangi aracı seçtiğiniz ikinci sırada kalır.

ufw, firewalld ve iptables’a genel bakış

ufw nedir, hangi senaryolarda öne çıkar?

ufw (Uncomplicated Firewall), özellikle Ubuntu ve türevlerinde kullanılan, kurulu olup olmadığı imaja göre değişen, iptables tabanlı bir yönetim katmanıdır. Dağıtımın iptables komutları nf_tables uyumluluk katmanını kullanabilir; ufw’yi doğrudan nft komut diliyle aynı araç saymayın.

• Basit komut seti: ufw allow 22/tcp, ufw deny 25/tcp gibi okunabilir komutlar.
• Uygulama profilleri: Nginx, OpenSSH gibi servisler için hazır tanımlar kullanılabilir.
• Küçük ve orta ölçekli VPS’lerde, özellikle tek yöneticili ortamlarda idealdir.

firewalld nedir, hangi dağıtımlarda karşımıza çıkar?

firewalld, RHEL ailesinde yaygın bir güvenlik duvarı yöneticisidir. Zone ve service kavramlarını kullanır. Bu rehberdeki komutlar 1.3.x arayüzüyle uyumludur; arka uç ve paket sürümünü kurulu sistemde kontrol edin. Güncel belgelerde varsayılan arka uç nftables’tır.

• Zone: Arayüz ve kaynakların hangi politikaya girdiğini belirler. trusted gelen bağlantıları kabul ettiği için yalnızca özel ağ adı taşıyan bir arayüzü otomatik olarak bu zone’a koymayın.
• Service: http, https, ssh gibi tanımların içerdiği portları inceleyin.
• Runtime ve permanent: Çalışan kurallar ile diskteki kurallar ayrıdır. Reload kalıcı durumu yükler; kaydedilmemiş runtime değişiklikleri kaybolur.

iptables nedir, ne zaman doğrudan kullanılır?

iptables, Netfilter üzerinde tablo, zincir ve eşleşmeleri yöneten düşük seviyeli bir araçtır. NAT ve gelişmiş eşleşmeler için esnektir; yönlendirme, VPN veya konteyner politikası ayrıca tasarlanmalıdır. Trafik şekillendirme için iptables tek başına tam bir tc alternatifi değildir.

Bugün birçok dağıtım arka planda nftables’a geçiş yapıyor olsa da, iptables hâlâ çok yaygın kullanılıyor. nftables tarafını derinlemesine ele aldığımız nftables ile VPS güvenlik duvarı rehberimiz bu yazının doğal devamı niteliğinde.

Hangi dağıtımda hangi aracı kullanmalı?

Dağıtım–araç seçimi için genel öneriler şöyle; kurulu araçları ayrıca kontrol edin:

• Ubuntu / Debian: ufw basit senaryolar için bir seçenektir; hazır kurulu olduğunu varsaymayın. Basit senaryolar için ufw, gelişmiş kurulumlar için doğrudan iptables/nftables tercih edilir.
• AlmaLinux / Rocky Linux / RHEL: firewalld yaygın bir seçenektir; kurulu ve etkin olup olmadığı imaja bağlıdır. Panel (cPanel, Plesk vb.) varsa, araç seçimini panelin güvenlik duvarı yönetimiyle uyumlu yapın.
• Minimal/özel imajlar: Hiçbiri kurulu olmayabilir; doğrudan iptables veya nftables üzerine kendi tercih ettiğiniz yöneticiyi kurarsınız.

VPS veya dedicated sunucu için araç seçerken dağıtımı, mevcut kuralları ve varsa panelin kullandığı yöneticiyi esas alın. Özet tavsiye:

• Ubuntu/Debian: Basit host politikası için ufw; daha ayrıntılı ihtiyaçta mevcut yöneticinin yeteneklerini değerlendirin.
• RHEL ailesi: Dağıtımın desteklediği firewalld yaklaşımı çoğu host için uygundur. Panel veya otomasyon zaten kuralları yönetiyorsa onun desteklenen entegrasyonunu kullanın.

İyi bir VPS güvenlik duvarı tasarımı nasıl olmalı?

Ufak komut örneklerine geçmeden önce, kuralları tasarlarken izlemeniz gereken prensipleri netleştirelim. DCHost blogunda anlattığımız VPS sunucu güvenliği rehberimizle de uyumlu, pratik bir kontrol listesi şu şekilde:

• Gereksiz gelen erişimi kapatın. SSH ve uygulamalar için yalnızca gereken kaynak/portları açın; ağın çalışması için gereken ICMP/ICMPv6’yı körlemesine engellemeyin.
• SSH için baştan tek politika seçin: Yönetim IP’leriyle kaynak kısıtlaması veya kamuya açık erişimde bağlantı sınırlaması. İkinci bir dar izin, daha önceki geniş izni kaldırmaz.
• Web: Yalnızca hizmet veriliyorsa 80/tcp ve 443/tcp. Bu sunucu HTTP/3 uç noktasıysa, hizmetin dinlediği UDP portuna da izin verin; bu genellikle 443/udp’dir.
• Veritabanı: Yerel soket, özel ağ veya VPN tercih edin; gerekliyse doğrulanmış istemci adreslerine izin verin.
• Her iki adres ailesi: IPv4 kuralı IPv6 kaynağını yetkilendirmez.
• Gözlem ve yönetim: Log hacmini sınırlayın; aynı zincirlere birbiriyle yarışan yöneticiler atamayın.

Yeni kurulan VPS’ler için önerdiğimiz ilk adımları ayrıntılı olarak “Yeni VPS’te İlk 24 Saat” rehberimizde anlattık; burada ise güvenlik duvarı kısmını derinleştiriyoruz.

ufw ile adım adım VPS güvenlik duvarı yapılandırma

Kurulum ve temel ayarlar

Bu bölüm Ubuntu 24.04 LTS, ufw 0.36.2 komut sözdizimini esas alır. Kurulu sürümü kontrol edin. Adımlar, başka bir yönetici veya panelin kural yazmadığı, ufw’nin henüz etkin olmadığı yeni host içindir. Tüm komutlar root kabuğunda çalıştırılır; aşağıdaki üç araçtan yalnızca seçtiğiniz bölümü uygulayın. Etkin sistemde önce mevcut politikayı, gerçek SSH portunu ve sunucunun gördüğü yönetim kaynak adreslerini kaydedin. Çalışan konsol/kurtarma erişimini ve geri dönüşü önce sınayın. ufw eksikse:

apt update
apt install ufw
ufw version
ufw status verbose

UFW’nin IPv6 kurallarını yönetmesi için /etc/default/ufw dosyasında aşağıdaki büyük harfli ayarı kontrol edin. Bu ayar işletim sistemine IPv6 adresi veya rota sağlamaz; ağ yapılandırması ayrı konudur.

IPV6=yes

Bu ayarı kurallar oluşturulmadan ve ufw etkinleştirilmeden önce doğrulayın. IPv6’yı sonradan açıyorsanız eski kuralların IPv6 karşılıklarını ayrıca inceleyin. Yeni, etkin olmayan host için politikalar:

ufw default deny incoming
ufw default allow outgoing

SSH politikasını seçme ve web portları

Uzak yönetimi kaybetmemek için gerçek SSH portunu karşılayan kuralı etkinleştirmeden önce hazırlayın. Bu başlangıç örneği herkese açık SSH için limit kullanır. Sabit yönetim adresleriniz varsa aşağıdaki kaynak kısıtlaması seçeneğini bunun yerine kullanın. Web portlarını yalnızca web sunucusu çalışıyorsa ekleyin:

ufw limit 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp

SSH zaten 2222/tcp üzerinde dinliyorsa 22/tcp limit kuralı yerine aşağıdakini kullanın. Güvenlik duvarı komutu SSH servisinin portunu değiştirmez:

ufw limit 2222/tcp

Kaynak kısıtlaması ve mevcut geniş izinleri kaldırma

ufw 0.36.2 limit kuralı aynı IP’den 30 saniyede altı veya daha fazla bağlantı başlatma girişimini sınırlar. Bu bir kullanıcı doğrulama mekanizması veya kapsamlı saldırı engelleme garantisi değildir. Kaynak kısıtlaması seçiyorsanız limit kuralıyla birlikte geniş bir erişim yolu bırakmayın. Mevcut kuralları önce numaralı görünümde inceleyin:

ufw status numbered

SSH erişimini yalnızca belirli kaynaklardan açmak için aşağıdaki IPv4 ve IPv6 kurallarını herkese açık limit/allow kuralı yerine seçin. 203.0.113.10 ve 2001:db8::10 belgeleme adresleridir; sunucunun gördüğü gerçek yönetim adreslerinizle, 22’yi gerçek SSH portunuzla değiştirin. IPv6 ile yönetim gerekmiyorsa IPv6 SSH izni eklemeyin. Etkin sistemde izinleri önce ekleyip konsol açıkken geniş kuralları kaldırın; ardından yeni bağlantıyla izin verilen ve verilmeyen kaynakları sınayın.

ufw allow from 203.0.113.10 to any port 22 proto tcp
ufw allow from 2001:db8::10 to any port 22 proto tcp

İlk eşleşen kural kazanır. Geniş allow, limit veya profil izni duruyorsa kaynak kısıtlaması tamamlanmış değildir. Numara ile silme yalnızca seçilen IPv4 veya IPv6 satırını siler ve numaralar kayar; her silmeden sonra listeyi yenileyin. Rastgele sıra numarası kullanmayın.

Belirli servislere izin verme

Uygulama profilleri kurulu pakete bağlıdır. Profili kullanmadan önce adını ve portlarını inceleyin:

ufw app list
ufw app info "Nginx Full"

Kurulu Nginx Full profilinin gerçekten gereken 80/tcp ve 443/tcp portlarını içerdiğini doğrularsanız, doğrudan web portu kurallarına alternatif olarak:

ufw allow "Nginx Full"

Etkinleştirme ve durum kontrolü

SSH kaynak/port eşleşmesini, IPv6 ayarını, gerekli servisleri ve kurtarma yolunu doğruladıktan sonra yeni hostta ufw’yi etkinleştirin. Mevcut SSH oturumunu açık tutun; başka istemciden yeni bağlantı kurun:

ufw enable

Durumu görmek için:

ufw status verbose
ufw status numbered
ufw show raw

IPv6 örneği

IPV6=yes ile yeni eklenen genel port kuralları iki aileyi kapsayabilir; kaynak adresli kurallar yalnızca kendi ailesindedir. Yeni yönetim kısıtlaması için yukarıdaki iki kaynak kuralını esas alın. Yapılandırma değişikliğini etkin ufw’de yeniden yüklemek için, önce yedek ve kurtarma planı hazırken:

ufw reload

Reload sonrasında IPv4 ve IPv6 üzerinden yeni SSH/web bağlantılarını ve engellenmesi gereken kaynakları ayrı sınayın. Sadece ufw status çıktısı uçtan uca erişimi veya yönlendirilen trafiğin politikasını kanıtlamaz.

firewalld ile adım adım VPS güvenlik duvarı yapılandırma

Kurulum ve servis yönetimi

RHEL 9 ailesinde firewalld yaygındır; bu bölüm 1.3.x komut arayüzünü kullanır. Yüklü ve etkin olduğunu varsaymayın. Paket eksikse kurulum değişikliğini önce inceleyin; kayıtlı SSH/zone kuralları ve konsol erişimi doğrulanmadan servisi başlatmayın:

dnf install firewalld
firewall-cmd --version
systemctl status firewalld

Etkin değilse önce kayıtlı yapılandırmayı firewall-offline-cmd --check-config ile denetleyin ve gerçek SSH yolunu gözden geçirin. Yalnızca bu hazırlık tamamlanınca:

systemctl enable --now firewalld

Temel kavramlar:

• Zone: Arayüz/kaynak politikası; varsayılan zone tüm arayüzlerin public olduğunu göstermez.
• Service: Port/protokol tanımı; ssh çoğunlukla 22/tcp’dir, özel portu otomatik izlemez.
• Runtime: Çalışan durumu değiştirir. --runtime-to-permanent, sınanmış runtime durumunun tamamını diske yazar ve eski permanent durumu üzerine alır.
• Permanent: Tek başına çalışan durumu değiştirmez; reload kalıcı durumu yükler ve kaydedilmeyen runtime kurallarını kaybettirir.

Varsayılan zone’u ve arayüzleri kontrol etme

firewall-cmd --get-default-zone
firewall-cmd --get-active-zones
firewall-cmd --zone=public --list-all
firewall-cmd --permanent --zone=public --list-all

Sonraki komutlar, genel ağa bakan arayüzün gerçekten public zone’da olduğu örnektir; sunucunuzdaki doğru zone’u kullanın. Zone kaynak atamalarını, daha geniş servis/port izinlerini ve varsa policy/direct kurallarını da inceleyin. Temel host için default hedef, ICMP’yi koruyup eşleşmeyen diğer trafiği reddeder. Hedef ayarı yalnızca permanent kapsamındadır:

firewall-cmd --permanent --zone=public --get-target

Sadece DROP yapmak için hedef değiştirmeyin; ICMPv6 ve erişim etkisini ayrıca tasarlamak gerekir. Mevcut hedef farklıysa, kayıtlı yapılandırmada firewall-cmd --permanent --zone=public --set-target=default ancak tüm kalıcı erişim kuralları hazırken ve planlı reload öncesinde kullanılabilir. Aşağıdaki runtime-first akış, hedefin zaten default olduğunu varsayar.

SSH kaynaklarını ve web servislerini tanımlama

Örnekte SSH yalnızca iki yönetim adresine açılır. Belgeleme adreslerini gerçek adreslerle, 22’yi dinlenen portla değiştirin. IPv6 yönetimi gerekmiyorsa ikinci aile iznini eklemeyin. Genel web servisleri ayrıca açılır:

firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="203.0.113.10/32" port port="22" protocol="tcp" accept'
firewall-cmd --zone=public --add-rich-rule='rule family="ipv6" source address="2001:db8::10/128" port port="22" protocol="tcp" accept'
firewall-cmd --zone=public --add-service=http
firewall-cmd --zone=public --add-service=https

Yeni kuralları ekledikten sonra konsol açıkken eski geniş SSH izinlerini kaldırın. Standart public zone’da ssh servisi bulunabilir. Yalnızca gerçekten mevcut olan ilgili servis/port izinleri için:

firewall-cmd --zone=public --remove-service=ssh
firewall-cmd --zone=public --remove-port=22/tcp

Diğer zone, rich rule veya policy içindeki geniş izinler de incelenmelidir. Her iki ailede yeni yetkili SSH bağlantısını ve yetkisiz kaynağın reddedilmesini doğrulamadan kalıcılaştırmayın. Özel port kullanıyorsanız, örneğin mevcut geniş 2222/tcp izni için firewall-cmd --zone=public --remove-port=2222/tcp gerekir; yalnızca 22/tcp iznini kaldırmak özel portu daraltmaz.

Özel SSH portu ve uygulama portları

SSH 2222/tcp üzerinde dinliyorsa yukarıdaki iki rich rule içindeki port="22" yerine port="2222" kullanın; 22 için yeni izin eklemeyin. Aşağıdaki 8080/tcp ise yalnızca herkese açık olması gereken bir uygulama için ayrı örnektir; özel API’ye genel izin vermeyin:

firewall-cmd --zone=public --add-port=8080/tcp

Veritabanına istemci bazlı erişim

Veritabanı yalnızca gerekli özel ağ/VPN istemcilerine açılmalıdır. Aşağıdaki tek IPv4 izni, belgeleme adresi gerçek yetkili istemciyle değiştirildikten sonra kullanılabilir. Başka geniş MySQL izni varsa tek başına erişimi daraltmaz:

firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="203.0.113.10" port protocol="tcp" port="3306" accept'

IPv6 denetimi ve kalıcılaştırma

Servis izinleri genelde her iki aileye uygulanır; family="ipv4" veya family="ipv6" içeren rich rule yalnızca o aileye aittir. SSH ve gerekli web/özel servisleri dışarıdan sınayın. Sonra tüm runtime durumunun kalıcı dosyaları değiştirmesini istediğinizi doğrulayarak:

firewall-cmd --runtime-to-permanent &&
firewall-cmd --check-config &&
firewall-cmd --reload &&
firewall-cmd --zone=public --list-all

Reload sonrası izin ve ret testlerini tekrarlayın; planlı yeniden başlatmada zone/arayüz atamalarını tekrar doğrulayın. NetworkManager yönetimindeki bağlantılarda zone, bağlantı profilinden gelir; kalıcı profili de eşleştirin. Özel arayüz için internal zone kullanılabilir, ancak iç ağdaki her istemcinin her servise yetkili olduğunu varsaymayın; trusted zone genel kabul anlamına gelir.

iptables ile doğrudan kural yazma

Zincirler ve temel akış

iptables’ta en çok kullanılan filter tablosu ve üç ana zincir vardır:

• INPUT: Sunucuya gelen trafik.
• OUTPUT: Sunucudan çıkan trafik.
• FORWARD: Sunucu üzerinden yönlendirilen trafik.

Aşağıdaki düşük seviyeli örnek, sabit adresli, yönlendirme yapmayan, konteyner/panel/VPN veya Fail2ban otomasyonu ve zincirleri bulunmayan yeni bir web hostu içindir. DHCP kullanıyorsanız adres yenileme trafiği ayrıca tasarlanmalıdır; bu şablonu doğrudan uygulamayın. Her iki ailede kaynak kısıtlı SSH ve genel HTTP/HTTPS vardır. NAT ve yönlendirme ihtiyacını kapsam dışı varsayarak geçmeyin; bu host şablonu o ortamlara uygun değildir.

İki aile için dosya hazırlama ve geri dönüş

Ubuntu 24.04’te iptables 1.8.10 sözdizimini esas alın. iptables --version çıktısındaki legacy/nf_tables arka ucunu kaydedin; iki komut ailesinde tutarlı arka uç kullanın ve uygulama sırasında değiştirmeyin. iptables-apply ve ip6tables-apply araçlarının kurulu olduğunu kontrol edin. Çalışan konsol erişimiyle, yeni boş bir çalışma dizini ve her iki ailenin tam yedeğini oluşturun. Mevcut dizinin veya yedeğin üzerine yazmayın; dizin oluşturma ya da iki yedekten biri başarısızsa sonraki adıma geçmeyin:

umask 077
iptables --version
ip6tables --version
mkdir /root/firewall-review &&
iptables-save > /root/firewall-review/before.v4 &&
ip6tables-save > /root/firewall-review/before.v6

Aşağıdaki metni /root/firewall-review/rules.v4 dosyası olarak kaydedin; bu bir shell scripti değildir. Yönetim IPv4 adresini ve SSH portunu önce değiştirin. Restore dosyası filter tablosunun tamamını değiştirir; mevcut yönetici zincirleri olan sisteme uygulanmaz. Komutları sırayla flush/DROP yapmak yerine dosyayı önce bütünüyle hazırlayın:

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p icmp -j ACCEPT
-A INPUT -p tcp -s 203.0.113.10/32 --dport 22 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT
COMMIT

IPv6 dosyasını da /root/firewall-review/rules.v6 adıyla hazırlayın. IPv6 yönetim adresi ve portu aynı erişim niyetini taşımalıdır; IPv6 SSH gerekmiyorsa yalnızca ilgili SSH satırını çıkarın. Örnekte tüm ICMPv6 kabul edilir: komşu keşfi ve Packet Too Big gibi gerekli mesajları kesmeyen basit host tercihidir, en dar ICMPv6 politikası değildir. Daha sıkı tür/kaynak/hop-limit filtresi RFC 4890 ve ağ rolüne göre ayrıca tasarlanır:

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p ipv6-icmp -j ACCEPT
-A INPUT -p tcp -s 2001:db8::10/128 --dport 22 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT
COMMIT

İki dosyanın da sözdizimini denetleyin; hata varsa uygulamayı durdurun. --test kuralları kurar/doğrular ama commit etmez; gerçek erişimi kanıtlamaz:

iptables-restore --test < /root/firewall-review/rules.v4
ip6tables-restore --test < /root/firewall-review/rules.v6

Önce aynı dağıtım ve arka uçta yalıtılmış deneme yapın. Konsol ve ikinci istemci hazırken IPv4’ü süreli onayla uygulayın:

iptables-apply -t 120 /root/firewall-review/rules.v4

120 saniye örnektir; doğrulama süresini önceden planlayın. Yeni IPv4 SSH/web bağlantılarını ve engellenmesi gereken erişimi sınamadan y ile onaylamayın. Yanıt verilmezse araç önceki IPv4 kurallarına döner. IPv4 doğrulandıktan sonra IPv6 için ayrı oturumda:

ip6tables-apply -t 120 /root/firewall-review/rules.v6

IPv6 erişim, ICMPv6/komşu keşfi ve engellenmesi gereken kaynakları ayrıca sınayın. İki aile tek atomik işlem değildir. İkinci aşama başarısız olursa ilk onaylanan aile kendiliğinden geri dönmez; konsoldan iki özgün yedeği de geri yükleyin. Araç/oturum/host çökmesine karşı zaman aşımı tek başına kurtarma garantisi değildir:

iptables-restore < /root/firewall-review/before.v4
ip6tables-restore < /root/firewall-review/before.v6

Kuralları kalıcı yapmak

Her iki aile uygulandıktan ve yeni bağlantı/ret testleri geçtikten sonra kalıcılaştırın. Ubuntu/Debian’da iptables-persistent paketi netfilter-persistent eklentilerini sağlar. Kurulum mevcut kuralları kaydetmeyi sorabilir; önce doğru çalışan durumu doğrulayın:

apt install iptables-persistent
netfilter-persistent save

/etc/iptables/rules.v4 ve rules.v6 içeriklerini kontrol edin. Yeniden başlatma sonrası ikisinin de yüklendiğini, yeni SSH ve uygulama erişimini konsol hazırken doğrulayın. Kaydetme, dosyaları otomatik olarak doğru veya kurtarılabilir yapmaz.

RHEL ailesinde kalıcılık için dağıtımın ve seçili arka ucun desteklediği yöntemi kullanın. Bir dosyayı kaydetmek kendiliğinden boot sırasında çalıştırmaz; genel bir rc.local önerisini tüm dağıtımlara uygulamayın.

Karşılaştırma: ufw, firewalld ve iptables artıları–eksileri

Kullanım kolaylığı

• ufw: Öğrenmesi en kolay, özellikle tek sunuculu Ubuntu VPS’lerde çok pratik. Basit gereksinimler için ideal.
• firewalld: Zone ve service kavramı sayesinde orta ölçekli yapılarda düzenli kalmayı kolaylaştırır. Öğrenme eğrisi ufw’den biraz daha diktir.
• iptables: En esnek ama en karmaşık seçenek. Yanlış bir kural tek komutla kendinizi sunucudan kilitlemenize neden olabilir.

Dağıtım entegrasyonu ve ekosistem

• Ubuntu/Debian: Paket ve ufw/iptables arka ucunu kontrol edin.
• AlmaLinux/Rocky/RHEL: Desteklenen firewalld paketini ve varsa panel entegrasyonunu esas alın.
• Konteyner: Host INPUT kuralları, yönlendirilen veya yayımlanmış port trafiği için yeterli kabul edilemez.

Dinamiklik ve otomasyon

• ufw: İncelenebilir basit kurallar ve otomasyon için uygundur.
• firewalld: Runtime değişiklikleri destekler; reload sırasında kalıcı durumun ne içerdiği önemlidir. Kesintisizlik garantisi yoktur.
• iptables: Dosya tabanlı kuralları sürümleyin; seçilen arka uçta deneme, geri dönüş ve kalıcılık testlerini otomasyona ekleyin.

Ne zaman hangisini seçmeli?

• Basit host: Dağıtımla uyumlu ufw veya firewalld çoğu zaman yeterlidir.
• Birden çok ağ: Zone, kaynak ve yönlendirme kapsamını tasarlayın; büyüme tek başına araç değişimi gerektirmez.
• Özel NAT/eşleşme: Yönetim sorumluluğu net iptables veya nftables tasarımı kullanılabilir. Trafik şekillendirme gereksinimini ayrıca değerlendirin.

Yaygın hatalar ve kaçınmanız gereken senaryolar

“Test için güvenlik duvarını kapattım, öyle kaldı” sendromu

Sorun giderirken güvenlik duvarını tamamen kapatmak, ilgisiz servisleri de erişime açabilir. Gereken kaynak/port için süreli ve kayıtlı istisna tasarlayın; örneğin firewalld runtime izinlerinde desteklenen --timeout seçeneğini kullanmadan önce gerçek komut desteğini doğrulayın. Süreli izin kaldırılınca erişimin tekrar kapandığını sınayın.

Veritabanı portlarını dünyaya açmak

MySQL’in 3306 portunu veya PostgreSQL’in 5432’sini doğrudan internete açmak, saldırı yüzeyinizi dramatik şekilde büyütür. Mutlaka:

• Bu portları sadece iç ağ veya VPN arayüzüne açık tutun,
• Ya da IP bazlı çok sıkı kısıtlama uygulayın.

IPv6’yı tamamen unutmak

IPv4 kısıtlamaları IPv6 trafiğini kendiliğinden korumaz. IPv6 adresleri, rotalar ve DNS kayıtlarıyla birlikte her iki ailenin erişimini sınayın. Ağ ayarları için IPv6 yapılandırma rehberimize bakabilirsiniz.

Güvenlik duvarını tek katmanlı düşünmek

OS seviyesindeki güvenlik duvarı, savunmanızın yalnızca bir katmanı olmalı. Uygulama katmanında WAF ve rate limit kullanmak, HTTP düzeyinde ise HTTP güvenlik başlıkları ile tarayıcı tarafını sertleştirmek aynı derecede önemli. Çok katmanlı yaklaşımla küçük yanlış yapılandırmaların etkisini azaltırsınız.

Konteyner, panel ve günlük yönetimi

Docker ile yayımlanan portlar UFW’nin INPUT/OUTPUT yolundan önce yönlendirilebilir. Host filtresinin konteyner portunu koruduğunu varsaymayın. Docker’ın kendi zincirlerini temizlemeyin veya iptables yönetimini körlemesine kapatmayın. iptables arka ucunda DOCKER-USER yaklaşımı, Docker’ın yerel nftables arka ucundaki ayrı tablo/hook yaklaşımıyla aynı değildir; kurulu sürümün belgelerini kullanın. Güncel Docker belgeleri yerel nftables arka ucunu deneysel olarak işaretler.

• Reverse proxy: Arka uç konteyner portlarını genel arayüzde yayımlamayın; sadece proxy kullanmak doğrudan arka uç erişimini engellemez.
• Panel ve posta: Panelin gerçek yönetim portlarını, çalışan posta protokollerini ve gerekiyorsa pasif FTP aralığını envantere alın. SFTP SSH portunu kullanır.
• Özel servis: İç ağ veya VPN tercihini gerçek istemci yetkileriyle eşleştirin; trusted zone’u genel bir veritabanı güvenlik önlemi saymayın.
• Log: UFW log seviyesi, sistemin syslog/journal yönlendirmesi ve disk saklama sınırlarını kontrol edin. iptables LOG hedefi yalnızca kayıt üretir; tek başına DROP yapmaz.

Doğrudan iptables örneğinde, izin kurallarından sonra ve varsayılan DROP politikasından önce kullanılabilecek isteğe bağlı, hız sınırlı kayıt satırı aşağıdadır. Yorum olarak verilmiştir; restore dosyasına shell komutu olarak yapıştırmayın:

# iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables-denied: " --log-level 7

firewalld --set-log-denied çalışan ve kalıcı ayarı değiştirip reload yapar; sıradan salt log sorgusu değildir. Kaydedilmemiş runtime izinlerini önce değerlendirin. Logları merkezileştirirken saklama ve alarmları da planlayın. Daha geniş çerçeve için VPS güvenliği için doğrulanabilir yaklaşımlar ve nftables rehberimiz kullanılabilir.

Doğrulama ve bakım

İzin verilen ve verilmeyen kaynaklardan yeni SSH, web ve gerekiyorsa panel/veritabanı bağlantılarını IPv4 ve IPv6 ile ayrı sınayın. Dinleyen servisleri ss -tulpn ile, dış erişimi istemcide curl veya nc ile kontrol edin. Açık kalan eski SSH oturumu kurtarma yöntemi değildir; bağımsız konsolun çalıştığını ve hizmet planınızda bulunduğunu önceden doğrulayın. Kuralları ve gerekçelerini sürümleyin, değişiklikten sonra reload ve planlı boot sonuçlarını kaydedin.

VPS güvenlik duvarı yapılandırmasında araç adından önce doğru kaynak, port, adres ailesi ve geri dönüş planı gelir. Dağıtımınızla uyumlu tek yönetim akışını seçin; host, yönlendirme ve uygulama katmanlarının sorumluluğunu ayırın. Güvenlik duvarının yanına güncelleme, SSH anahtarları, log izleme ve uygulama kontrolleri ekleyin. Sonraki adım için WAF ve uygulama güvenliği rehberini okuyabilirsiniz. Dış destek alırken sunucu yönetimi ve kurtarma hizmetlerinin kapsamını sözleşmeden doğrulayın.

Resmî kaynaklar

• Ubuntu 24.04: ufw
• Ubuntu 24.04: ufw-framework
• firewalld: firewall-cmd
• Ubuntu 24.04: iptables-restore
• Ubuntu 24.04: iptables-apply
• RFC 4890: ICMPv6
• Docker: packet filtering
• Debian: netfilter-persistent