UFW ile Çoklu Ağ Arayüzü Yönetimi: Farklı Interface’lere Özel Kural Tanımlama

Çok arayüzlü bir sunucuyu yönetiyorsanız, UFW’nin varsayılan davranışının sizi biraz hayal kırıklığına uğratabileceğini hemen fark edersiniz. Kurallar tüm arayüzlere uygulanır, tek bir kural eth0‘ı da eth1‘i de ens3‘ü de etkiler. Ama gerçek dünyada işler hiç de bu kadar sade değil: iç ağ trafiğine farklı, DMZ trafiğine farklı, yönetim arayüzüne farklı davranmanız gerekiyor. Bu yazıda UFW’yi arayüz bazında nasıl kontrol altına alacağınızı, hangi senaryolarda ne yapmanız gerektiğini ve arka planda neler döndüğünü detaylıca ele alacağız.

UFW’nin Arayüz Yönetimindeki Temel Mantığı

UFW, aslında iptables üzerinde bir soyutlama katmanıdır. ufw allow 22 dediğinizde bu kural tüm arayüzlere uygulanır. Ancak UFW, in on ve out on sözdizimini kullanarak belirli bir arayüze kural bağlamanıza izin verir.

Önce sisteminizdeki arayüzleri tanıyalım:

ip link show
# veya eski yöntemle:
ifconfig -a

# Daha okunabilir çıktı için:
ip -br link show

Tipik bir çok arayüzlü sunucuda şu tablo karşınıza çıkabilir:

  • eth0 veya ens3: Genel internet arayüzü (WAN)
  • eth1 veya ens4: İç ağ arayüzü (LAN)
  • eth2 veya ens5: DMZ ya da yönetim ağı
  • lo: Loopback arayüzü
  • docker0, virbr0: Sanal arayüzler

Bu arayüzlerin her biri farklı güven seviyelerine sahip. Mesela eth1 üzerinden gelen SSH trafiğine izin verirken eth0 üzerinden gelen aynı trafiği engellemek isteyebilirsiniz. Tam da burada arayüz bazlı kurallar devreye giriyor.

Temel Sözdizimi: in on ve out on

UFW’de arayüze özgü kural yazmanın sözdizimi oldukça sezgisel:

# Gelen trafik için belirli arayüz belirtme
ufw allow in on eth1 to any port 22

# Giden trafik için belirli arayüz belirtme
ufw allow out on eth0 to any port 443

# Hem kaynak hem hedef belirterek
ufw allow in on eth1 from 192.168.1.0/24 to any port 3306

Buradaki parametrelerin anlamlarına bakalım:

  • in on [arayüz]: Belirtilen arayüzden gelen paketlere uygulanır
  • out on [arayüz]: Belirtilen arayüzden çıkan paketlere uygulanır
  • from [ip/subnet]: Kaynak IP ya da subnet filtresi
  • to any port [port]: Hedef port filtresi
  • proto tcp/udp: Protokol filtresi

Şimdi bu bilgiyi gerçek dünya senaryolarına uygulayalım.

Senaryo 1: Web Sunucusu ile Yönetim Ağını Ayırma

Diyelim ki bir web sunucunuz var. eth0 internete açık, eth1 ise yönetim ağınız. SSH erişimini sadece yönetim ağından kabul etmek, HTTP/HTTPS’i ise herkese açmak istiyorsunuz.

# Önce varsayılan politikaları ayarlayalım
ufw default deny incoming
ufw default allow outgoing

# HTTP ve HTTPS tüm arayüzlerden kabul et (internet arayüzü)
ufw allow in on eth0 to any port 80 proto tcp
ufw allow in on eth0 to any port 443 proto tcp

# SSH sadece yönetim arayüzünden kabul et
ufw allow in on eth1 to any port 22 proto tcp

# Yönetim ağından tüm trafiğe izin ver (iç güven)
ufw allow in on eth1 from 10.0.0.0/8

# UFW'yi etkinleştir
ufw enable

Bu yapılandırmayla internet tarafından gelen SSH denemelerinin tamamı düşecek. Yönetim ağından erişim ise sorunsuz çalışacak. Gece yarısı brute force alarmı almaktan kurtulursunuz.

Senaryo 2: Veritabanı Sunucusu Güvenliği

Üç arayüzlü bir veritabanı sunucusu düşünün: biri uygulama sunucularına açık, biri yönetim ağına, biri de yedekleme ağına. Her arayüz için farklı kurallar gerekiyor.

# Uygulama ağından MySQL erişimi (eth0 = app network)
ufw allow in on eth0 from 172.16.0.0/16 to any port 3306 proto tcp

# Yönetim ağından SSH (eth1 = management)
ufw allow in on eth1 from 10.10.0.0/24 to any port 22 proto tcp

# Yedekleme ağından rsync ve SSH (eth2 = backup network)
ufw allow in on eth2 from 192.168.100.0/24 to any port 22 proto tcp
ufw allow in on eth2 from 192.168.100.0/24 to any port 873 proto tcp

# Monitoring için ICMP'ye izin ver (sadece management interface)
ufw allow in on eth1 proto icmp

# Tüm diğer trafiği engelle
ufw default deny incoming
ufw default deny forward

Burada dikkat edilmesi gereken nokta: ufw default deny forward satırı. Eğer sunucunuz paket yönlendirme yapmıyorsa bu şart. Yönlendirme yapıyorsa ayrı forward kuralları yazmanız gerekecek.

UFW’nin Before Rules Dosyasına Müdahale

Bazı gelişmiş kurallar için UFW’nin kendi arayüzünü aşıp doğrudan iptables kurallarına inmek gerekiyor. Bu durumda /etc/ufw/before.rules dosyası devreye giriyor.

Örneğin NAT veya özel arayüz yönlendirme senaryolarında:

# /etc/ufw/before.rules dosyasını düzenle
sudo nano /etc/ufw/before.rules

# Dosyanın en başına, *filter satırından önce şunu ekle:
*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE
COMMIT

Bu eklemenin ardından ufw reload komutuyla değişikliklerinizi uygulayın. Bu yaklaşım özellikle VPN gateway veya router görevi gören sunucularda işe yarıyor.

Senaryo 3: Docker ve Sanal Arayüzler

Docker kullanan bir sunucuda işler biraz karmaşıklaşıyor. Docker kendi iptables kurallarını yazıyor ve UFW ile çakışmalar yaşanabiliyor. Bunu düzgün yönetmek için:

# Docker bridge arayüzünden gelen trafiği yönet
# docker0 arayüzü genellikle 172.17.0.0/16 subnet kullanır

# Container'lardan host'a erişimi sınırla
ufw allow in on docker0 from 172.17.0.0/16 to any port 5432 proto tcp

# Container'ların dış dünyayla iletişimini kontrol et
# Bu kural container'ların DNS'e ulaşmasına izin verir
ufw allow in on docker0 from 172.17.0.0/16 to any port 53

# Özel Docker network'ler için (docker network ls ile bulabilirsiniz)
ufw allow in on br-a1b2c3d4e5f6 from 172.20.0.0/16 to any port 8080 proto tcp

Docker ile UFW kullanırken /etc/docker/daemon.json dosyasına şunu eklemenizi de tavsiye ederim:

{
  "iptables": false
}

Bu ayar Docker’ın iptables kurallarını otomatik yazmasını engelliyor ve UFW üzerinden tam kontrol sağlıyor. Ancak dikkatli olun, bu değişiklikten sonra container network bağlantısını manuel olarak yönetmeniz gerekecek.

Mevcut Kuralları Görüntüleme ve Doğrulama

Arayüz bazlı kurallarınızın doğru uygulandığını kontrol etmek için:

# Tüm kuralları numaralı listele
ufw status numbered

# Verbose modda daha fazla detay
ufw status verbose

# Aktif iptables kurallarını doğrudan gör
iptables -L -n -v --line-numbers

# Belirli bir arayüze gelen/giden trafiği izle
tcpdump -i eth1 -n port 22

ufw status verbose çıktısında her kuralın hangi arayüze bağlı olduğunu açıkça görebilirsiniz. Şuna benzer bir çıktı alırsınız:

  • 22/tcp on eth1 ALLOW IN Anywhere – eth1 üzerinden SSH izni
  • 80/tcp on eth0 ALLOW IN Anywhere – eth0 üzerinden HTTP izni
  • 3306/tcp on eth0 ALLOW IN 172.16.0.0/16 – Belirli subnet’ten MySQL izni

Kural Silme ve Güncelleme

Yanlış tanımladığınız bir kuralı düzeltmeniz gerektiğinde:

# Numaralı listeyi gör
ufw status numbered

# Belirli numaralı kuralı sil
ufw delete 3

# Doğrudan kural yazarak silme
ufw delete allow in on eth1 to any port 22 proto tcp

# Tüm kuralları sıfırla (dikkatli kullanın!)
ufw reset

ufw reset sonrasında UFW devre dışı kalır ve tüm kurallar silinir. Uzak sunucuda bu komutu çalıştırmadan önce konsol erişiminizin olduğundan emin olun. Yoksa kendinizi kilitleyebilirsiniz.

Uygulama Profilleri ile Arayüz Kombinasyonu

UFW, önceden tanımlı uygulama profilleri sunuyor. Bu profilleri arayüz kurallarıyla kombine edebilirsiniz:

# Mevcut profilleri listele
ufw app list

# OpenSSH profilini sadece belirli arayüze uygula
ufw allow in on eth1 app OpenSSH

# Nginx Full profilini sadece WAN arayüzüne uygula
ufw allow in on eth0 app 'Nginx Full'

# Kendi profilinizi oluşturun
sudo nano /etc/ufw/applications.d/myapp

Özel profil dosyası şöyle görünür:

[MyWebApp]
title=My Custom Web Application
description=Custom ports for internal web app
ports=8080,8443/tcp

Bu profil oluşturulduktan sonra ufw app update MyWebApp ile güncelleyip kurallarınıza dahil edebilirsiniz.

Logging ile Trafik Analizi

Hangi arayüzden ne geldiğini takip etmek için logging’i arayüz bazında incelemek çok değerli:

# UFW logging'i etkinleştir
ufw logging on

# Yoğun logging modu
ufw logging high

# Log dosyasını izle
tail -f /var/log/ufw.log

# Belirli arayüzden gelen engellenen paketleri filtrele
grep "IN=eth0" /var/log/ufw.log | grep "BLOCK"

# Kaynak IP'lere göre istatistik
grep "IN=eth0" /var/log/ufw.log | grep "BLOCK" | awk '{print $13}' | sort | uniq -c | sort -rn | head 20

Log formatında IN=eth0 gibi giriş arayüzü ve OUT=eth1 gibi çıkış arayüzü bilgisi açıkça görünüyor. Bu sayede hangi arayüzden hangi trafiğin geçtiğini kolayca analiz edebilirsiniz.

Senaryo 4: Hibrit Bulut Ortamında Güvenlik

Hem fiziksel hem bulut bağlantısı olan bir sunucu düşünün. Site-to-site VPN arayüzünüz tun0, internet arayüzünüz eth0, iç ağ ise eth1:

# VPN tüneli üzerinden gelen güvenilir trafiğe geniş izin
ufw allow in on tun0 from 10.8.0.0/24

# VPN'den yönetim portlarına erişim
ufw allow in on tun0 to any port 22 proto tcp
ufw allow in on tun0 to any port 8080 proto tcp
ufw allow in on tun0 to any port 9090 proto tcp

# İnternetten sadece gerekli portlara izin
ufw allow in on eth0 to any port 80 proto tcp
ufw allow in on eth0 to any port 443 proto tcp

# İç ağdan her şeye izin
ufw allow in on eth1 from 192.168.0.0/16

# VPN olmadan management portlarına erişimi engelle
ufw deny in on eth0 to any port 8080
ufw deny in on eth0 to any port 9090

Bu yapılandırmada yönetim arayüzleri sadece VPN tüneli üzerinden erişilebilir oluyor. İnternetten doğrudan yapılan saldırı denemeleri ilk kural seti tarafından düşürülüyor.

Otomatizasyon: UFW Kural Yönetim Script’i

Çok sayıda sunucu yönetiyorsanız kuralları elle tek tek girmek hem yorucu hem hata prone. Basit bir bash script’i ile standart yapılandırmayı otomatize edebilirsiniz:

#!/bin/bash
# multi_interface_ufw.sh - Çoklu arayüz UFW yapılandırması

# Arayüz değişkenleri
WAN_IFACE="eth0"
LAN_IFACE="eth1"
MGMT_IFACE="eth2"
MGMT_SUBNET="10.0.0.0/24"
APP_SUBNET="172.16.0.0/16"

# UFW'yi sıfırla
echo "UFW sıfırlanıyor..."
ufw --force reset

# Varsayılan politikalar
ufw default deny incoming
ufw default deny outgoing
ufw default deny forward

# Loopback trafiğine her zaman izin ver
ufw allow in on lo
ufw allow out on lo

# WAN arayüzü kuralları
ufw allow in on $WAN_IFACE to any port 80 proto tcp
ufw allow in on $WAN_IFACE to any port 443 proto tcp
ufw allow out on $WAN_IFACE proto tcp
ufw allow out on $WAN_IFACE proto udp

# LAN arayüzü kuralları
ufw allow in on $LAN_IFACE from $APP_SUBNET
ufw allow out on $LAN_IFACE to $APP_SUBNET

# Yönetim arayüzü kuralları
ufw allow in on $MGMT_IFACE from $MGMT_SUBNET to any port 22 proto tcp
ufw allow in on $MGMT_IFACE from $MGMT_SUBNET to any port 9100 proto tcp  # Node exporter

# UFW'yi etkinleştir
ufw --force enable

echo "UFW yapılandırması tamamlandı."
ufw status verbose

Bu script’i /etc/ufw/ altına koyun ve yeni sunucu kurulumlarında tek komutla standart güvenlik kurallarını uygulayın.

Yaygın Hatalar ve Çözümleri

Arayüz bazlı UFW yönetiminde sık karşılaşılan sorunlara değinelim:

Arayüz adı yanlış yazılmış olabilir. ip link show çıktısında gördüğünüz tam adı kullanın. eth0 ile ens3 arasında karıştırmak kuralların hiç uygulanmamasına yol açar. UFW sessizce hata vermez, kural kayıt altına alınır ama çalışmaz.

Kural sırası önemlidir. UFW kuralları sırayla işler. Genel bir deny kuralından önce spesifik allow kurallarınızın gelmesi gerekir. ufw status numbered ile sırayı kontrol edin, gerekirse ufw insert [numara] allow... komutuyla istenilen pozisyona kural ekleyin.

default deny outgoing dikkat ister. Giden trafiği de varsayılan olarak engelliyorsanız DNS dahil her şeyi açık belirtmeniz gerekir. Birçok sysadmin giden trafiği kısıtladıktan sonra sunucunun internete erişemediğini görüp panikler. ufw allow out on eth0 to any port 53 gibi kuralları eklemeyi unutmayın.

Loopback unutulmamalı. 127.0.0.1 üzerinden haberleşen uygulamalar için loopback arayüzüne her zaman izin verin. Birçok uygulama health check veya IPC için loopback kullanır.

Sonuç

UFW ile çoklu arayüz yönetimi, ilk bakışta karmaşık görünse de in on ve out on sözdizimini kavradıktan sonra oldukça güçlü ve esnek bir güvenlik politikası oluşturabiliyorsunuz. İnternete açık arayüzü sıkı tutmak, iç ağ ve yönetim arayüzlerine makul esneklik tanımak, DMZ trafiğini ayrıca kontrol altına almak… Bunların hepsi UFW’nin sunduğu araçlarla mümkün.

Asıl değer, bu kuralları bir kez doğru tanımladıktan sonra hem okunabilir hem de bakımı kolay bir güvenlik duvarı yapısına sahip olmanızda yatıyor. before.rules dosyasına inmeden, ham iptables komutlarıyla boğulmadan, UFW’nin sağladığı soyutlama katmanıyla üretim ortamına hazır kurallar yazabiliyorsunuz.

Kurulumlarınızı mutlaka test ortamında doğrulayın, kural değişikliklerini versiyon kontrol sistemine alın ve özellikle uzak sunucularda her değişiklik sonrası bağlantının hala çalıştığını teyit edin. Kendinizi kilitlemeden başarılı UFW yönetimi dilerim.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir