BIND DNS Sunucusunda Response Policy Zone ile DNS Filtreleme

yazar

Ağ yöneticilerinin en çok baş ağrısı yaşadığı konulardan biri kötü amaçlı alan adlarını, reklam sunucularını veya şirket politikasıyla çelişen siteleri engellemektir. Güvenlik duvarı kuralları yazmak, proxy üzerinden trafik yönlendirmek gibi yöntemler işe yarasa da DNS katmanında filtreleme yapmak çok daha zarif ve performanslı bir çözüm sunar. İşte bu noktada BIND’ın Response Policy Zone (RPZ) özelliği devreye giriyor.

Response Policy Zone Nedir?

RPZ, BIND 9.8 ile birlikte hayatımıza giren ve DNS sorgularına verilen yanıtları özel politikalar çerçevesinde değiştirmenizi sağlayan bir mekanizmadır. Basitçe söylemek gerekirse: bir istemci kötü amaçlı bir alan adını sorguladığında, o alan adının gerçek IP adresi yerine siz ne döndürmek istiyorsanız onu döndürebilirsiniz. Ya da sorguyu tamamen susturabilirsiniz.

RPZ’nin güzel yanı, bu kararları DNS sunucusunun kendisinde vermenizdir. Trafik ağdan çıkmadan, gerçek sunucuya ulaşmadan müdahale edersiniz. Bu hem hız hem de güvenlik açısından ciddi avantaj sağlar.

Gerçek dünya senaryosunu düşünün: Şirket ağınızda 500 istemci var. Bunların bir kısmı farkında olmadan zararlı yazılım indiriyor, fidye yazılımı komuta kontrol sunucularıyla iletişim kurmaya çalışıyor. Güvenlik duvarında her IP adresini tek tek engellemek yerine, DNS seviyesinde o alan adlarını bloke etmek hem daha kolay hem de daha etkilidir çünkü kötü aktörler IP adreslerini kolayca değiştirebilir ama alan adları genellikle sabit kalır.

RPZ’nin Çalışma Mantığı

RPZ, özel bir DNS zone dosyası olarak tanımlanır. Bu zone içindeki kayıtlar normal DNS kayıtları gibi görünse de özel anlamlar taşır. BIND bu zone’daki kurallara göre gelen sorgulara karşılık üretir.

Temel eylemler şunlardır:

  • NXDOMAIN: Alan adı mevcut değil yanıtı döndür
  • NODATA: Kayıt tipi mevcut değil yanıtı döndür
  • PASSTHRU: Filtreyi geç, gerçek yanıtı döndür (whitelist için kullanılır)
  • DROP: Sorguyu tamamen yok say, yanıt verme
  • TCP-only: Yalnızca TCP üzerinden yanıt ver (rate limiting için kullanışlı)
  • Redirect: İstemciyi başka bir IP adresine yönlendir

BIND Kurulumu ve Temel Yapılandırma

Önce BIND’ın kurulu ve çalışır durumda olduğundan emin olalım. Ubuntu/Debian sistemlerde:

sudo apt update
sudo apt install bind9 bind9utils bind9-doc -y
sudo systemctl enable bind9
sudo systemctl start bind9

CentOS/RHEL sistemlerde:

sudo dnf install bind bind-utils -y
sudo systemctl enable named
sudo systemctl start named

BIND versiyonunuzu kontrol edin, RPZ için 9.8 ve üzeri gerekiyor:

named -v
# BIND 9.16.1-Ubuntu (Stable Release)

RPZ Zone Dosyası Oluşturma

RPZ zone dosyası standart bir zone dosyasıyla aynı söz dizimini kullanır ama içeriği farklı yorumlanır. Önce temel bir RPZ zone dosyası oluşturalım:

sudo nano /etc/bind/db.rpz.blocked

Dosyanın içeriği şöyle olmalı:

$TTL 300
@ IN SOA localhost. root.localhost. (
    2024010101 ; Serial
    1h         ; Refresh
    15m        ; Retry
    1w         ; Expire
    1h )       ; Negative TTL

@ IN NS localhost.

; Zararlı alan adlarını NXDOMAIN ile engelle
malware-site.com        CNAME .
*.malware-site.com      CNAME .

; Reklam sunucusunu engelle
ads.example-ad.net      CNAME .
*.ads.example-ad.net    CNAME .

; Bir siteyi başka bir IP'ye yönlendir (uyarı sayfası)
blocked-content.com     A 192.168.1.100
*.blocked-content.com   A 192.168.1.100

Burada CNAME . (nokta ile biten) NXDOMAIN anlamına gelir. CNAME *. (yıldız ile biten) ise NODATA anlamına gelir.

named.conf Yapılandırması

RPZ zone’unuzu BIND’a tanıtmak için named.conf.options veya ilgili yapılandırma dosyasına ekleme yapmanız gerekiyor:

sudo nano /etc/bind/named.conf.options
options {
    directory "/var/cache/bind";
    
    // RPZ yapılandırması
    response-policy {
        zone "rpz.blocked" policy NXDOMAIN;
        zone "rpz.whitelist" policy PASSTHRU;
    };
    
    // Önerilen güvenlik ayarları
    recursion yes;
    allow-recursion { 192.168.0.0/16; 10.0.0.0/8; localhost; };
    
    dnssec-validation auto;
    
    listen-on { any; };
    listen-on-v6 { any; };
};

Ardından zone tanımlarını named.conf.local dosyasına ekleyin:

sudo nano /etc/bind/named.conf.local
// RPZ engelleme listesi
zone "rpz.blocked" {
    type master;
    file "/etc/bind/db.rpz.blocked";
    allow-query { none; };
    allow-transfer { none; };
};

// RPZ whitelist
zone "rpz.whitelist" {
    type master;
    file "/etc/bind/db.rpz.whitelist";
    allow-query { none; };
    allow-transfer { none; };
};

Whitelist dosyasını da oluşturalım:

sudo nano /etc/bind/db.rpz.whitelist
$TTL 300
@ IN SOA localhost. root.localhost. (
    2024010101 ; Serial
    1h         ; Refresh
    15m        ; Retry
    1w         ; Expire
    1h )       ; Negative TTL

@ IN NS localhost.

; Bu alan adları her zaman gerçek yanıtı alır
; Whitelist'teki kayıtlar PASSTHRU policy ile çalışır
; Herhangi bir RPZ kuralından muaf tutmak istediğiniz domainleri buraya ekleyin
trusted-partner.com     CNAME *.
*.trusted-partner.com   CNAME *.

Yapılandırmayı kontrol edip BIND’ı yeniden başlatalım:

sudo named-checkconf
sudo named-checkzone rpz.blocked /etc/bind/db.rpz.blocked
sudo systemctl restart bind9

Çoklu RPZ Zone’ları ve Öncelik Sırası

Birden fazla RPZ zone’u tanımladığınızda, öncelik sırası response-policy bloğundaki yazım sırasına göre belirlenir. Önce yazılan zone daha yüksek önceliğe sahiptir. Bu özellikten yararlanarak sofistike bir filtreleme hiyerarşisi oluşturabilirsiniz:

response-policy {
    // 1. Whitelist her zaman önce gelir, engelleme listelerini override eder
    zone "rpz.whitelist" policy PASSTHRU;
    
    // 2. Fidye yazılımı komuta kontrol sunucuları
    zone "rpz.ransomware-c2" policy DROP;
    
    // 3. Genel zararlı yazılım listesi
    zone "rpz.malware" policy NXDOMAIN;
    
    // 4. Şirket politikası engelleme listesi
    zone "rpz.corporate-policy" policy NXDOMAIN;
    
    // 5. Reklam engelleme
    zone "rpz.ads" policy NXDOMAIN;
} qname-wait-recurse no;

qname-wait-recurse no seçeneği performans açısından önemlidir. Bu seçenek olmadan BIND, politika kararı vermeden önce tam recursive çözümleme yapar, bu da gereksiz yük oluşturur.

Dinamik RPZ Güncellemeleri ve Otomasyon

Gerçek dünya kullanımında engelleme listelerini manuel olarak güncellemek pratik değildir. Tehdit istihbarat listeleri, reklam engelleme listeleri gibi kaynakları otomatik olarak RPZ zone’unuza aktaran bir script yazalım:

#!/bin/bash
# /usr/local/bin/update-rpz.sh
# RPZ listelerini harici kaynaklardan güncelleyen script

RPZ_DIR="/etc/bind"
RPZ_FILE="$RPZ_DIR/db.rpz.malware"
TEMP_FILE="/tmp/rpz_temp.txt"
LOG_FILE="/var/log/rpz-update.log"
SERIAL=$(date +%Y%m%d%H)

# Tehdit listesi kaynakları (örnek URLler)
THREAT_FEEDS=(
    "https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts"
)

echo "$(date): RPZ güncelleme başladı" >> "$LOG_FILE"

# Zone dosyası başlığını yaz
cat > "$TEMP_FILE" << EOF
$TTL 300
@ IN SOA localhost. root.localhost. (
    $SERIAL ; Serial
    1h       ; Refresh
    15m      ; Retry
    1w       ; Expire
    1h )     ; Negative TTL

@ IN NS localhost.

EOF

# Hosts dosyası formatından domain listesi çek ve RPZ formatına dönüştür
for FEED in "${THREAT_FEEDS[@]}"; do
    curl -s --max-time 30 "$FEED" | 
    grep "^0.0.0.0" | 
    grep -v "0.0.0.0 0.0.0.0" | 
    awk '{print $2}' | 
    grep -E "^[a-zA-Z0-9]([a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(.[a-zA-Z0-9]([a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$" | 
    while read domain; do
        echo "$domain CNAME ."
        echo "*.$domain CNAME ."
    done >> "$TEMP_FILE"
done

# Tekrar eden kayıtları temizle
sort -u "$TEMP_FILE" -o "$TEMP_FILE"

# Dosyayı yerine koy ve syntax kontrol yap
mv "$TEMP_FILE" "$RPZ_FILE"
chown bind:bind "$RPZ_FILE"

if named-checkzone rpz.malware "$RPZ_FILE" > /dev/null 2>&1; then
    rndc reload rpz.malware
    echo "$(date): RPZ başarıyla güncellendi" >> "$LOG_FILE"
else
    echo "$(date): HATA - Zone syntax hatası!" >> "$LOG_FILE"
    exit 1
fi

Script’i çalıştırılabilir yapın ve cron’a ekleyin:

chmod +x /usr/local/bin/update-rpz.sh

# Crontab'a ekle - her gece 02:00'da çalışsın
echo "0 2 * * * root /usr/local/bin/update-rpz.sh" > /etc/cron.d/rpz-update

RPZ ile Yönlendirme Sayfası Kurma

Sadece NXDOMAIN döndürmek yerine, kullanıcıları engelleme sebebini açıklayan bir sayfaya yönlendirmek çok daha kullanıcı dostu bir yaklaşımdır. Bunun için bir web sunucusu kurmanız ve RPZ’de o sunucunun IP adresine yönlendirme yapmanız gerekir:

# nginx ile basit bir uyarı sayfası
sudo apt install nginx -y

sudo nano /etc/nginx/sites-available/rpz-block-page
server {
    listen 80 default_server;
    listen [::]:80 default_server;
    
    # Tüm hostlara yanıt ver
    server_name _;
    
    root /var/www/rpz-block;
    index index.html;
    
    location / {
        try_files $uri $uri/ =404;
    }
}

RPZ zone dosyanızda yönlendirme:

; Şirket politikası ihlali - uyarı sayfasına yönlendir
gambling-site.com       A 192.168.1.50
*.gambling-site.com     A 192.168.1.50

social-media-blocked.com    A 192.168.1.50
*.social-media-blocked.com  A 192.168.1.50

RPZ Günlükleri ve İzleme

RPZ etkinliğini izlemek için BIND’ın loglama özelliğini detaylı şekilde yapılandırmanız önerilir:

sudo nano /etc/bind/named.conf.options

Options bloğunun dışına logging direktifi ekleyin:

logging {
    channel rpz_log {
        file "/var/log/named/rpz.log" versions 7 size 50m;
        print-time yes;
        print-severity yes;
        print-category yes;
        severity info;
    };
    
    channel general_log {
        file "/var/log/named/general.log" versions 3 size 20m;
        print-time yes;
        severity dynamic;
    };
    
    category rpz { rpz_log; };
    category general { general_log; };
    category queries { rpz_log; };
};

Log dizinini oluşturun ve izinleri ayarlayın:

sudo mkdir -p /var/log/named
sudo chown bind:bind /var/log/named
sudo systemctl restart bind9

Log dosyasını takip etmek için:

# Engellenen sorguları canlı izle
sudo tail -f /var/log/named/rpz.log | grep "rpz"

# Son 1 saatte en çok engellenen domainleri listele
sudo grep "rpz" /var/log/named/rpz.log | 
    grep "$(date '+%d-%b-%Y %H')" | 
    awk '{print $10}' | 
    sort | uniq -c | sort -rn | head 20

Performans Optimizasyonu

Büyük engelleme listeleriyle çalışırken BIND’ın bellek kullanımı artabilir. named.conf.options içindeki bazı ayarlar performansa katkı sağlar:

options {
    // RPZ için önerilen cache boyutu
    max-cache-size 256m;
    
    // Zone transferi için bellek optimizasyonu  
    transfer-format many-answers;
    
    // RPZ sorgu performansı
    response-policy {
        zone "rpz.whitelist" policy PASSTHRU;
        zone "rpz.malware" policy NXDOMAIN;
    } 
    qname-wait-recurse no
    nsip-enable no
    nsdname-enable no;
    
    // Gereksiz recursive sorguları kısıtla
    max-cache-ttl 3600;
    max-ncache-ttl 300;
};

nsip-enable no ve nsdname-enable no seçenekleri, RPZ’nin sadece sorgu adına bakmasını sağlar, nameserver IP ve isimlerine bakmamasını söyler. Bu büyük listelerde ciddi performans artışı sağlar.

Sorun Giderme

Sık karşılaşılan sorunlar ve çözümleri:

Zone yüklenmiyor:

# Syntax hatasını bul
named-checkzone rpz.malware /etc/bind/db.rpz.malware

# BIND'ın yüklediği zone'ları listele
rndc status | grep zones

# Zone durumunu kontrol et
rndc zonestatus rpz.malware

RPZ kuralları çalışmıyor:

# dig ile test et ve RPZ'nin devreye girip girmediğini kontrol et
dig @localhost malware-site.com

# Yanıtta "Rewritten by RPZ" görmek için
dig @localhost malware-site.com +dnssec

# BIND'ın RPZ'yi algılayıp algılamadığını logdan kontrol et
sudo grep -i "rpz" /var/log/syslog | tail -20

Whitelist çalışmıyor:

Whitelist zone’unun response-policy bloğunda engelleme listelerinden ÖNCE yazıldığından emin olun. Sıralama çok kritiktir.

# Whitelist domain için test
dig @localhost trusted-partner.com
# Gerçek IP adresini dönüyorsa whitelist çalışıyor demektir

Güvenlik Değerlendirmeleri

RPZ güçlü bir araçtır ama bazı önemli noktaları göz önünde bulundurmanız gerekir:

  • DNS over HTTPS (DoH) bypass: İstemciler DoH kullanıyorsa RPZ’yi atlayabilirler. Güvenlik duvarında 8.8.8.8:443, 1.1.1.1:443 gibi harici DoH sunucularına erişimi kısıtlayın
  • DNS over TLS (DoT) bypass: Benzer şekilde 853 numaralı portu dışarıya kapatın
  • DNSSEC ve RPZ: RPZ, DNSSEC imzalı yanıtları değiştirdiğinde istemcide doğrulama hatası oluşabilir. break-dnssec yes seçeneğini RPZ bloğuna ekleyebilirsiniz ama bu DNSSEC güvenliğini kırar, bilinçli bir tercih yapın
  • Zone dosyası güvenliği: RPZ zone dosyalarına yalnızca bind kullanıcısının yazma erişimi olmalı
# Doğru izinleri ayarla
sudo chown root:bind /etc/bind/db.rpz.*
sudo chmod 640 /etc/bind/db.rpz.*

Dış Kaynaklı RPZ Beslemeleri

Kendi listenizi oluşturmanın yanı sıra ticari ve açık kaynak tehdit istihbaratı beslemelerini BIND RPZ’ye doğrudan bağlayabilirsiniz. Bu durumda zone’u slave olarak tanımlarsınız:

zone "rpz.threat-feed" {
    type slave;
    masters { 198.51.100.10; };  // Tehdit istihbarat sağlayıcısının IP'si
    file "/var/cache/bind/rpz.threat-feed";
    allow-query { none; };
};

Açık kaynak alternatifler arasında SURBL, Spamhaus RPZ ve çeşitli topluluk listeleri bulunuyor. Bu listeleri zone transfer protokolüyle alabilir ya da yukarıda gösterdiğim script benzeri araçlarla periyodik güncelleyebilirsiniz.

Sonuç

Response Policy Zone, DNS altyapısını savunma hattına dönüştürmenin en etkili yollarından birini sunar. Kurumsal ağlarda kötü amaçlı yazılımların komuta kontrol sunucularıyla iletişimini kesmek, kullanıcıları zararlı içeriklerden korumak ve şirket politikalarını ağ katmanında uygulamak için RPZ mükemmel bir araçtır.

Pratik açıdan değerlendirdiğimizde: Büyük ölçekli engelleme listelerini güvenlik duvarı kuralları olarak yönetmek kabustur. DNS katmanında yapmak hem daha ölçeklenebilir hem de daha merkezi yönetilebilir bir yapı sunar. Üstelik BIND’ın kendisinde yerleşik olarak geldiğinden ek bir yazılım maliyeti yoktur.

Yapılandırmanızı geliştirirken whitelist mekanizmasını doğru kurduğunuzdan emin olun, yoksa meşru trafiği de engelleyebilirsiniz. Loglama mutlaka açık olsun ki hangi sorguların engellendiğini görebilin. Düzenli otomasyon scriptleri ile tehdit listelerinizi güncel tutun. Bu üç prensibe sadık kaldığınızda RPZ sisteminiz hem güvenli hem de operasyonel açıdan yönetilebilir kalacaktır.

Yorum yapın