ARP ve DNS zehirlenmesi izleri

Gece vardiyasında Altay Kargo'nun yardım masasına iki şikâyet düşer. Depodaki bir çalışan, sevkiyat panelinin sertifika uyarısı verdiğini söyler. Başka bir çalışan aynı panelin bu kez uyarısız ama farklı görünen bir giriş sayfası açtığını bildirir.

İki şikâyetin kökü aynı olabilir: yerel ağda ARP tablosu ya da çözücüde DNS önbelleği zehirlenmiştir. İki protokol de kimlik doğrulaması olmadan çalışır ve sahte yanıtı gerçeğinden ayırmaz.

Önce iki protokolün güven boşluğunu görürsün. Sonra her birinin izini komut çıktısında, paket kaydında ve Zeek günlüğünde okursun. En sonda bu izlerin hiç oluşmamasını sağlayan anahtar, çözücü ve tarayıcı ayarlarını kurarsın.

ARP, yerel ağda IP adresini fiziksel MAC adresine çeviren protokoldür. Bir cihaz paket göndermeden önce hedefin MAC adresini bilmek zorundadır, bunu ARP isteğiyle sorar. Yanıtı alan her cihaz bu eşleşmeyi kısa süreli bir önbellekte tutar.

Protokolün tasarımında kimlik doğrulama yoktur; herhangi bir cihaz, hiç sorulmadan bile bir ARP yanıtı yayınlayabilir ve alıcı bunu sorgusuz kabul eder. Saldırgan bu boşluğu ARP zehirlenmesinde kullanır: ağ geçidinin IP adresine kendi MAC adresini bağlayan sahte yanıtlar yayınlar. Kurbanın önbelleği güncellenince trafik artık saldırganın cihazı üzerinden akar, kurban hata görmez çünkü paketler sonunda gerçek ağ geçidine ulaşır.

Meşru cihazlar da bazen sorulmadan ARP yayınlar. Buna istenmemiş (gratuitous) ARP denir. Bir cihaz ağa katılırken adres çakışmasını denetlemek ya da yük devretmede yeni MAC'ini duyurmak için bu yayını kullanır. Ayırt edici işaret sıklık ve kalıcılıktır.

Meşru duyuru seyrektir ve beklenen bir olayla birlikte gelir. Zehirlenmede ise ağ geçidinin IP'si için saniyeler arayla tekrar eden yanıtlar görürsün, çünkü saldırgan kurbanın önbelleğini sürekli tazelemek zorundadır. Anahtarlarda Dinamik ARP Denetimi (DAI) açıksa, anahtar DHCP snooping bağlama tablosuyla eşleşmeyen ARP paketini güvenilmeyen porttan içeri almaz. Zehirli eşleşme böylece kurbanın önbelleğine hiç ulaşmaz.

MITRE ATT&CK bu tekniği T1557.002 (ARP Cache Poisoning) koduyla, ortadaki saldırgan başlığı altında sayar. Araya giren saldırgan trafiği dinleyebilir, değiştirebilir ya da başka yere yönlendirebilir. TLS ile korunan bir bağlantının içeriğini okuyamaz.

Sahte sertifika sunarsa kullanıcı tarayıcıda uyarı görür; yardım masasına düşen sertifika şikâyeti bu yüzden değerlidir. Şifresiz protokoller, eski yazıcı ve kamera arayüzleri ise hiç uyarı vermeden okunur. Etki, ağ geçidinin hizmet verdiği bütün segmenti kapsayabilir.

DNS çözümlemesi benzer bir güven zincirine dayanır. İstemci önce kurumun özyinelemeli çözücüsüne sorar. Çözücü cevabı bilmiyorsa sırayla kök sunucuya, üst düzey alan (TLD) sunucusuna ve yetkili ad sunucusuna danışır. Gelen cevabı TTL süresi boyunca önbelleğinde tutar ve aynı soruyu soran herkese oradan verir.

Zehirlenme bu zincirin ortasına sahte bir yanıt sokmakla olur. Sahte yanıt gerçeğinden önce gelir ve eşleşme alanlarını tutturursa, çözücü onu gerçek sanıp önbelleğe yazar. Bundan sonra o çözücüyü kullanan bütün istemciler, TTL dolana kadar yanlış adrese gider.

Çözücü bir yanıtı kabul etmeden önce birkaç alanı karşılaştırır: 16 bitlik sorgu kimliği, yanıtın geldiği adres, kendi kaynak portu ve soru bölümü. 2008'de Dan Kaminsky bu korumanın sanıldığından zayıf olduğunu gösterdi. CERT'in VU#800113 notu, bazı çözücülerin bütün sorgularını sabit bir kaynak porttan gönderdiğini yazdı; geriye yalnız 16 bitlik kimlik kalıyordu.

Çare üreticilerin ortak yamasıyla geldi. RFC 5452, çözücünün sorgu kimliğini 0 ile 65535 arasında öngörülemez seçmesini, kaynak portu da olabildiğince geniş bir aralıktan rastgele almasını ister. Aynı soru için birden çok bekleyen sorgu açılmamasını da önerir.

Zehirlenme izini iki yerde ararsın. Birincisi çözücünün kendisidir. Çözücü, bekleyen hiçbir sorguyla eşleşmeyen yanıtları sayabilir. Unbound'daki unwanted-reply-threshold ayarı bu sayaç eşiği aşınca günlüğe uyarı yazar ve önbelleği temizler.

Kısa sürede gelen yüzlerce eşleşmesiz yanıt, birinin sahte yanıt denediğini düşündürür. İkincisi istemciye ulaşan cevaptır. Alışılmadık kısa TTL, aynı ad için kısa sürede birbirinden farklı IP adresleri ve hiç sorulmamış bir sorunun cevabı zehirlenmenin izidir. Kurum içi bir adın birden dış bir adrese çözülmesi en hızlı fark edilen sapmadır.

DNSSEC bu riski kriptografik imzayla kapatır. Bölgenin sahibi her kayıt kümesini imzalar ve imzayı RRSIG kaydı olarak yayınlar. Doğrulama yapan çözücü imzayı bölgenin DNSKEY kaydıyla, o anahtarı da üst bölgedeki DS kaydıyla denetler. Zincir kök bölgeye kadar uzanır.

İmzası tutmayan yanıtı çözücü önbelleğe yazmaz ve istemciye SERVFAIL döner. DNSSEC yanıtı şifrelemez, yalnız kaynağını ve bütünlüğünü kanıtlar. Yaygınlığı hâlâ tam değildir; imzasız bir bölge için çözücünün elinde yalnız RFC 5452 önlemleri kalır. İzleme bu yüzden DNSSEC olan ağlarda da sürer.

$ dig +dnssec portal.altaykargo.example A

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41207
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232

;; ANSWER SECTION:
portal.altaykargo.example. 300 IN A     10.20.0.15
portal.altaykargo.example. 300 IN RRSIG A 13 3 300 20261031000000 20261001000000 40551 altaykargo.example. kVb2...

Çıktıyı satır satır oku. +dnssec seçeneği sorguya DO (DNSSEC OK) bitini ekler; OPT satırındaki flags: do bunu gösterir. Başlıktaki qr yanıtı, rd özyineleme isteğini, ra çözücünün özyineleme yaptığını söyler. Asıl işaret ad bayrağıdır: çözücü imza zincirini doğruladığını bildirir.

RRSIG satırında A imzalanan kayıt türüdür, 13 algoritmadır (ECDSA P-256 ve SHA-256), 3 addaki etiket sayısıdır. Ardından özgün TTL, imzanın bitiş ve başlangıç zamanı, anahtar etiketi ve imzalayan bölge gelir. Yanıt bozuksa doğrulayan çözücü SERVFAIL döner. Aynı sorguyu +cd ile tekrarlarsan çözücü doğrulamayı atlar ve veri gelir; bu fark sorunun imzada olduğunu gösterir.

Kendi makinende önbelleği denetlemek için arp ya da ip neigh komutunu kullanırsın. Önbellek her IP için tek satır tutar, bu yüzden aynı IP'nin iki satırını genelde görmezsin. Asıl iz iki biçimde çıkar. Birincisi ağ geçidinin IP'si ile başka bir IP'nin aynı MAC'i göstermesidir; saldırgan ağ geçidini taklit ederken kendi IP'sini de kullanmaya devam eder.

İkincisi ağ geçidinin MAC'inin zamanla değişmesidir. Bunu görmek için doğru MAC'i bir yere not eder ve düzenli olarak karşılaştırırsın. Büyük ağlarda merkezi bir izleme aracı anahtar tablolarını karşılaştırıp sapmayı raporlar.

$ ip neigh show
192.168.1.1 dev eth0 lladdr 00:0c:29:aa:bb:cc REACHABLE
192.168.1.66 dev eth0 lladdr 00:0c:29:aa:bb:cc STALE
192.168.1.20 dev eth0 lladdr 3c:52:82:10:4e:91 REACHABLE

C:\> arp -a
Interface: 192.168.1.30 --- 0x7
  Internet Address      Physical Address      Type
  192.168.1.1           00-0c-29-aa-bb-cc     dynamic
  192.168.1.66          00-0c-29-aa-bb-cc     dynamic

İlk çıktıda 192.168.1.1 ağ geçididir. lladdr değeri o IP için öğrenilen MAC'tir, sondaki REACHABLE ya da STALE ise eşleşmenin tazeliğini gösterir. 192.168.1.66 aynı MAC'i taşır. İki yorum mümkündür: ya iki adres aynı cihaza aittir ya da .66 kendini ağ geçidi gibi tanıtıyordur.

Envanterde ağ geçidinin MAC'i farklı yazıyorsa ikinci yorum güçlenir. Windows çıktısı aynı bilgiyi tireli MAC biçimiyle verir. Type sütunundaki dynamic, eşleşmenin ARP ile öğrenildiğini söyler. Statik tanımlı bir satır static görünür ve sahte yanıtla değişmez.

Paket kaydında aynı izi Wireshark gösterir. Bir IP adresi iki farklı MAC'ten duyurulunca Wireshark uzman bilgisine yinelenen adres uyarısı ekler. Bu uyarıyı arp.duplicate-address-detected filtresiyle süzersin; arp.duplicate-address-frame alanı aynı adresin daha önce görüldüğü çerçeveyi gösterir.

Sorulmadan yayınlanan yanıtları arp.isgratuitous == 1 ile ayırırsın. Yalnız ağ geçidinin yanıtlarına bakmak için arp.src.proto_ipv4 == 192.168.1.1 yazar ve eth.src sütununu eklersin. Bu sütunda zaman içinde iki farklı MAC görürsen zehirlenme kayıttadır.

Tek makineden bakmak yetmez, ağ genelinde sürekli bir göz gerekir. arpwatch gibi araçlar segmentteki ARP trafiğini dinler ve IP-MAC eşleşmelerini bir veritabanında tutar. Bir IP yeni bir MAC'e geçince changed ethernet address, en son görülen MAC'ten bir öncekine dönünce flip flop bildirimi üretir.

Zehirlenme sırasında flip flop çoğu zaman art arda gelir, çünkü gerçek ağ geçidi ile saldırgan aynı IP için sırayla yanıt verir. Anahtardaki DHCP snooping bağlama tablosu ikinci bir kaynaktır. ARP'de görülen eşleşme bu tabloyla çelişiyorsa sahte yanıtın geldiği portu oradan bulursun.

$ zeek-cut -d ts query answers TTLs rcode_name < dns.log | grep portal
2026-09-30T23:58:12+0000  portal.altaykargo.example  10.20.0.15    3600.000000  NOERROR
2026-10-01T00:41:07+0000  portal.altaykargo.example  203.0.113.66  30.000000    NOERROR
2026-10-01T00:41:09+0000  portal.altaykargo.example  203.0.113.66  30.000000    NOERROR
2026-10-01T01:12:40+0000  portal.altaykargo.example  10.20.0.15    3600.000000  NOERROR

zeek-cut, Zeek günlüğünden yalnız istediğin sütunları alır; -d seçeneği zaman damgasını okunur tarihe çevirir. query sorulan adı, answers dönen adresleri, TTLs cevabın ömrünü, rcode_name sonuç kodunu verir. İlk satır normal durumdur: iç portal 10.20.0.15 adresine, bir saatlik TTL ile çözülür. 00:41'de aynı ad dış bir adrese, 30 saniyelik TTL ile çözülmeye başlar.

İç uygulamanın birden dış adrese taşınması ve TTL'nin yüz yirmi kat kısalması iki ayrı sapmadır. Son satırda eski cevap geri gelir. Aradaki süre, etkilenen kullanıcıları ararken bakacağın zaman penceresidir.

Ortadaki saldırgan TLS'i kıramıyorsa bağlantıyı şifresiz sürüme indirmeyi dener. Buna SSL stripping denir. Kullanıcı adresi https olmadan yazdığında ilk istek şifresiz gider, saldırgan da kullanıcıyla şifresiz konuşmayı sürdürür. İz uygulama katmanında görünür.

Vekil sunucu ya da Zeek http.log kaydında, normalde yalnız HTTPS ile açılan bir giriş sayfasına 80 numaralı porttan POST isteği gidiyorsa durum şüphelidir. HSTS bu saldırıyı engeller: tarayıcı Strict-Transport-Security başlığını bir kez gördükten sonra o siteye şifresiz bağlanmaz. İlk ziyareti de korumak için alan adı tarayıcıların HSTS ön yükleme listesine eklenir.

Bir analist iki izi genelde birlikte okur. ARP zehirlenmesi trafiği saldırganın cihazından geçirir, DNS zehirlenmesi ise kurbanı sahte bir sunucuya yönlendirir. İkisi art arda görülüyorsa saldırgan hem yönlendirme hem içerik değiştirme peşindedir.

Tek başına ARP sapması bazen yanlış yapılandırmadan ya da yedek ağ geçidinin devreye girmesinden çıkar. DNS sapması da planlı bir taşıma olabilir. Her masum açıklamayı değişiklik kaydıyla doğrularsın. İki sapma aynı saatte ve kayıtlı bir değişiklik olmadan görünüyorsa şüphe olaya dönüşür.

Aynı iz sürme mantığını farklı bir olayda da kullanırsın. Bir kullanıcı bankasının sitesinin tuhaf göründüğünü bildirdiğinde önce DNS yanıtını, sonra ARP tablosunu kontrol edersin. Kalıcı çözüm ise izlerin hiç oluşmamasıdır. Erişim anahtarlarında DHCP snooping ve DAI açılır.

İstemciler yalnız kurumun doğrulayan çözücüsüne gider, dışarıya doğrudan 53 numaralı port çıkışı kapatılır. Kurumun kendi bölgeleri DNSSEC ile imzalanır, web uygulamaları HSTS başlığı gönderir. Küçük segmentlerde ağ geçidi için statik ARP kaydı da işe yarar.