1. DNS sinkholing nedir?

DNS sinkholing; bir alan adı sorgusuna gerçek otoritatif yanıtı döndürmek yerine, çözümleyici sunucunun önceden tanımlanmış bir sinkhole (lavabo) adresine yönlendiren cevap üretmesi anlamına gelir. Kullanıcının veya cihazın yaptığı A / AAAA sorgusu kaynağa hiç ulaşmaz; çözümleyici, dahili bir RPZ (Response Policy Zone), hosts dosyası veya kara liste yapılandırması üzerinden NXDOMAIN, 0.0.0.0, 127.0.0.1 veya kurum içi captive portal IP'sini geri verir.

Sinkholing terimi orijinal olarak büyük ölçekli botnet komuta-kontrol (C2) altyapılarını ele geçirmek için kullanıldı: araştırmacılar veya kolluk birimleri kötücül bir domain'in tescil kontrolünü alıp kendi sunucularına yönlendirir, böylece enfekte istemcilerin trafiği güvenli bir noktaya akardı. Kurumsal ortamda ise kavram daha basit bir biçimde uygulanır: kurum içi DNS çözümleyicisi, zararlı alan adlarına dair sorguları yerel olarak yutarak son kullanıcıya hiçbir yönlendirilebilir IP döndürmez.

2. Neden gerekli?

Modern saldırı zincirlerinin önemli bir bölümü domain düzeyinde başlar. Phishing kampanyalarında kullanıcı sahte bir alan adına yönlendirilir; zararlı yazılım komuta sunucusuna domain üzerinden ulaşır; veri sızıntısı (data exfiltration) DNS tüneli olarak gerçekleşir. Tüm bu senaryolarda domainin çözümlenmemesi; istemcinin saldırgan altyapısına hiç temas etmemesi demektir.

Çevre güvenlik duvarı (IP/port düzeyinde) bu trafik için tek başına yetersizdir, çünkü saldırganlar paylaşımlı bulut barındırma, CDN ve sık değişen IP havuzları kullanır. Domain'i kaynakta engellemek; arkasındaki IP değişse bile koruma sürekliliğini sağlar. Bunun yanı sıra DNS sinkholing, klasik ortamda logsuz görünen DNS trafiğini görünür kılar: hangi cihaz, hangi saatte, hangi tehdit domain'ine sorgu yaptığını net olarak ortaya koyar.

3. Nasıl çalışır?

Genel akış üç adımdan oluşur. Birinci adımda istemci yerel resolver'a (örneğin 10.0.0.53) bir DNS sorgusu gönderir. İkinci adımda resolver, sorulan alan adını dahili kara liste (RPZ veya benzeri politika kaynağı) ile karşılaştırır. Üçüncü adımda eşleşme bulunursa otoritatif sunucuya sorgu hiç iletilmez; resolver kendi politika yanıtını üretir.

Politika yanıtı dört biçimden biri olur: (a) NXDOMAIN — alan adı yokmuş gibi davran; (b) NODATA — var ama A kaydı yok; (c) sabit bir A kaydı — tüm istemciyi dahili captive portal IP'sine götür; (d) CNAME ile başka bir alana yönlendir. (c) seçeneği, kullanıcıyı bir uyarı sayfasına götürmek için tercih edilir; (a) ise sessiz engelleme için yaygındır.

4. BIND RPZ konfigürasyonu

BIND 9.10+ ile birlikte gelen Response Policy Zone (RPZ), DNS sinkholing için fiili (de facto) standarttır. RPZ tek başına bir DNS zone dosyasıdır; ama içeriği — kayıt isimlerinin — sorgunun konusuna uygulanmak üzere çözümleyici tarafından yorumlanır.

named.conf içine response-policy direktifi eklenir:

// /etc/bind/named.conf.options

options {
    directory "/var/cache/bind";
    recursion yes;
    allow-query { 10.0.0.0/8; 192.168.0.0/16; };

    response-policy {
        zone "rpz.siberanaliz.local" policy given;
    } qname-wait-recurse no
      break-dnssec yes
      max-policy-ttl 60;
};

zone "rpz.siberanaliz.local" {
    type master;
    file "/etc/bind/zones/rpz.siberanaliz.local";
    allow-query { localhost; };
    allow-transfer { none; };
};

Ardından zone dosyasının kendisi standart bir BIND zone şemasına uygun olur, tek farkla: her kayıt, engellenecek alan adı için bir politika tetikleyicisi olarak yorumlanır.

; /etc/bind/zones/rpz.siberanaliz.local
$TTL 60
@   IN  SOA  localhost. root.localhost. (
        2026052701  ; serial: YYYYMMDDNN
        3600        ; refresh
        600         ; retry
        86400       ; expire
        60 )        ; minimum
    IN  NS   localhost.

; --- SiberAnaliz domain göstergeleri ---
; Politika: NXDOMAIN dön
ornek-phish-domeni.tld         CNAME .
*.ornek-phish-domeni.tld       CNAME .
malware-c2.example             CNAME .
*.malware-c2.example           CNAME .

; Alternatif politika: dahili captive portal'a yönlendir
; ornek-phish-domeni.tld       A     10.20.30.40
; *.ornek-phish-domeni.tld     A     10.20.30.40

RPZ'de CNAME . (nokta) NXDOMAIN ile eş anlamlıdır ve sessiz engelleme için en yaygın seçimdir. Wildcard satırı (*.domain) saldırganın sıklıkla kullandığı login., secure. gibi alt alanları da kapsar; göstergenin yalnızca apex'i yerine bütün ailesi engellenir. Konfigürasyon sonrası şu komutla devreye alınır:

sudo named-checkconf
sudo named-checkzone rpz.siberanaliz.local /etc/bind/zones/rpz.siberanaliz.local
sudo rndc reload
# isabet doğrulaması:
dig @127.0.0.1 ornek-phish-domeni.tld
# beklenen: ;->>HEADER<<- ... status: NXDOMAIN

5. dnsmasq alternatifi

BIND'in karmaşık zone yönetimi her ortam için orantılı değildir. Şube ofisleri, küçük lokasyonlar veya konteyner içi resolver'lar için dnsmasq çok daha hafif bir alternatiftir. address= ve server= direktifleri sayesinde alan adı seviyesinde engelleme tek satırda mümkündür.

# /etc/dnsmasq.d/siberanaliz-block.conf

# Politika 1: sessiz NXDOMAIN (boş cevap)
server=/ornek-phish-domeni.tld/
server=/malware-c2.example/

# Politika 2: 0.0.0.0 dön (RFC 6761 sinkhole)
address=/ornek-phish-domeni.tld/0.0.0.0
address=/malware-c2.example/0.0.0.0

# Politika 3: dahili captive portal IP'ye yönlendir
# address=/ornek-phish-domeni.tld/10.20.30.40

# log-queries  # üretimde isabet ölçümü için açılabilir

address=/example.tld/0.0.0.0 formu örtük wildcard'dır: hem apex hem alt alan adları yakalanır. Konfigürasyon yenileme:

sudo dnsmasq --test
sudo systemctl reload dnsmasq
# isabet testi:
dig @127.0.0.1 ornek-phish-domeni.tld +short
# beklenen: 0.0.0.0

6. Pi-hole konsepti

Pi-hole esasen dnsmasq (ya da modern sürümlerde pihole-FTL) üzerine kurulu, web tabanlı yönetim arayüzü ve hazır besleme listeleri sağlayan bir dağıtımdır. Pi-hole'da bir "adlist" eklemek; arka planda düzenli aralıklarla URL'den alan adı listesi çekip gravity.db (SQLite) içine yüklemek anlamına gelir.

Pi-hole yönetim panelinden Group Management → Adlists bölümüne SiberAnaliz CSV uç noktasının URL'i eklenir. CSV başlık satırı ve fazla sütunlar içerdiği için doğrudan değil, ön işleme ile sade bir domain.txt üretilmesi tavsiye edilir. Bu liste daha sonra kendi sunucunuzdan Pi-hole'a servis edilir.

# /usr/local/bin/siberanaliz-pihole.sh
#!/usr/bin/env bash
set -euo pipefail

SRC="https://siberanaliz.com/export.csv?type=domain"
DST="/var/www/lists/siberanaliz-domain.txt"
TMP="$(mktemp)"

curl -fsSL --retry 3 -o "$TMP" "$SRC"
# CSV'den yalnızca domain sütununu süz, başlığı at, lowercase'e indir
awk -F',' 'NR>1 {gsub(/"/, "", $2); print tolower($2)}' "$TMP" \
  | grep -E '^[a-z0-9.-]+\.[a-z]{2,}$' \
  | sort -u > "$DST"

# Pi-hole gravity güncellemesi
/usr/local/bin/pihole -g

Cron tetiklemesi saatlik veya 4 saatlik yapılır (DNS önbellek TTL'leri ile uyumlu). Aşırı sık güncellemeden kaçınılması, hem sunucu hem yukarı akış için iyi vatandaşlık prensibidir.

7. SiberAnaliz listesini entegre etmek

SiberAnaliz /export.csv?type=domain uç noktası kararlı bir kontrat üzerinden domain göstergelerini sunar. Aşağıdaki örnek; CSV'den RPZ zone dosyasını üreten tam bir cron pipeline'dır:

# /usr/local/bin/siberanaliz-rpz.sh
#!/usr/bin/env bash
set -euo pipefail

SRC="https://siberanaliz.com/export.csv?type=domain"
ZONE="/etc/bind/zones/rpz.siberanaliz.local"
TMP="$(mktemp)"
SERIAL="$(date -u +%Y%m%d%H)"

curl -fsSL --retry 3 -A "siberanaliz-rpz-puller/1.0" -o "$TMP" "$SRC"

{
  printf '$TTL 60\n'
  printf '@ IN SOA localhost. root.localhost. (%s 3600 600 86400 60)\n' "$SERIAL"
  printf '  IN NS localhost.\n\n'
  awk -F',' 'NR>1 {
      gsub(/"/, "", $2);
      d=tolower($2);
      if (d ~ /^[a-z0-9.-]+\.[a-z]{2,}$/) {
          printf "%s CNAME .\n*.%s CNAME .\n", d, d
      }
  }' "$TMP"
} > "$ZONE.new"

# yalnızca doğrulama geçerse aktif et
named-checkzone rpz.siberanaliz.local "$ZONE.new" && mv "$ZONE.new" "$ZONE"
rndc reload rpz.siberanaliz.local

Cron tarafında bu betik saatlik tetiklenir:

# /etc/cron.d/siberanaliz-rpz
17 * * * * root /usr/local/bin/siberanaliz-rpz.sh >> /var/log/sib-rpz.log 2>&1

Konuyla ilgili insan tarafından gözlem için /tehdit/domain liste sayfası uygundur; her gösterge için bağlam (kategori, kritiklik, son senkron zamanı) ayrı ayrı görülebilir.

8. Cloudflare DNS Firewall API

Bulut tabanlı çözümleyici kullanan kurumlar — Cloudflare Gateway, NextDNS, Quad9 Pro — aynı engellemeyi sağlayıcının API'si üzerinden yaparlar. Cloudflare Gateway için politika tabanlı engelleme örneği:

# Cloudflare Zero Trust Gateway "DNS list" oluşturma
curl -fsSL -X POST \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  "https://api.cloudflare.com/client/v4/accounts/$CF_ACCOUNT_ID/gateway/lists" \
  -d '{
        "name": "siberanaliz-domains",
        "description": "SiberAnaliz domain göstergeleri",
        "type": "DOMAIN",
        "items": [
          {"value": "ornek-phish-domeni.tld"},
          {"value": "malware-c2.example"}
        ]
      }'

Üretimde, items dizisi SiberAnaliz CSV'sinden script ile üretilir ve liste mevcutsa PATCH /lists/{id} ile artırımlı güncellenir. Liste oluşturulduktan sonra Gateway tarafında bu listeyi kullanan bir DNS Policy ile birlikte engelleme aktif olur.

9. Log analizi ve isabet izleme

Sinkholing yalnızca bir engelleme katmanı değildir; aynı zamanda son derece değerli bir tespit sinyalidir. Bir cihazın sinkhole edilmiş bir domain'e sorgu atması, o cihazda büyük olasılıkla bir enfeksiyon veya kullanıcı etkileşimi (phishing tıklaması) olduğunu gösterir.

BIND tarafında query log aktifleştirilir:

// /etc/bind/named.conf.options
logging {
    channel rpz_hits {
        file "/var/log/named/rpz.log" versions 10 size 50m;
        severity info;
        print-time yes;
    };
    category rpz { rpz_hits; };
};

rpz.log içine düşen her satır, isabet eden istemci IP'sini ve sorulan alan adını taşır. Bu log SIEM'e (Splunk, Elastic, Sentinel) aktarıldığında "DNS sinkhole hit" korelasyonu kurularak SOC alert üretilebilir. Pi-hole tarafında ise /admin/queries.php arayüzünden veya /etc/pihole/pihole-FTL.db SQLite üzerinden raporlama yapılır.

10. Sık karşılaşılan hatalar

! DNSSEC çakışması: İstemci DNSSEC doğrulaması yapıyorsa politika yanıtı SERVFAIL görünür. BIND'de break-dnssec yes ile RPZ politikası DNSSEC üstünde tutulur.
! Cache zehirlenmesi yanılgısı: Sinkholing protokol saldırısı değildir; istemciler kurum içi çözümleyiciyi atlayıp 1.1.1.1, 8.8.8.8 veya DoH (DNS over HTTPS) kullanırsa engelleme bypass edilir. Bu nedenle 53/UDP ve 443/TCP seviyesinde DoH kısıtlaması güvenlik duvarında uygulanmalıdır.
! Apex / wildcard karışıklığı: Yalnızca apex (example.tld) eklerseniz login.example.tld açık kalır. Operasyonel kural: SiberAnaliz girdileri her zaman wildcard ile birlikte yazılır.
! Beyaz liste eksikliği: Kurumsal SaaS, ortak, ya da devlet tarafındaki kritik alan adları çakışma riskine karşı RPZ içinde passthru politikası ile beyaza alınmalıdır: kritik.kurum.tr CNAME rpz-passthru..
! Stale veri: Cron tetiklemesi başarısız olduğunda çözümleyici kararlı çalışmayı sürdürür ama liste güncellenmez. Pipeline mutlaka log ve monitoring üzerinde gözlemlenmelidir.

Kontrol Listesi

1 Sinkhole hedefi belirlendi (NXDOMAIN / 0.0.0.0 / captive portal).
2 SiberAnaliz CSV uç noktasına HTTPS erişimi doğrulandı.
3 Saatlik cron pipeline kuruldu ve hata durumunda alert üretiyor.
4 RPZ / dnsmasq / Pi-hole konfigürasyonu yeniden yükleme komutu otomatik tetikleniyor.
5 Beyaz liste politikası tanımlandı; kritik kurumsal domainler korunuyor.
6 Query log SIEM'e aktarıldı ve sinkhole isabet kuralı yazıldı.
7 Çıkış yönünde 53/UDP ve 443/DoH kaçışı için firewall kuralı doğrulandı.

SiberAnaliz Verisi ile Hızlı Başlangıç

SiberAnaliz /export.csv uç noktasından Türkiye'de doğrulanmış tehdit göstergelerini doğrudan indirebilir, listeyi gözden geçirmek için domain gösterge sayfasını kullanabilirsiniz.

Domain listesi (CSV) Domain göstergelerini gezin Tüm göstergeler (JSON)