ARP Nedir? MAC Adresi, ARP Tablosu ve Spoofing

Bir toplantı salonuna girdiğinizi düşünün. Elinizde bir isim var, ama o ismin hangi yüze ait olduğunu bilmiyorsunuz. Yapabileceğiniz tek şey salona dönüp yüksek sesle sormaktır: “Ahmet Yılmaz burada mı?” Biri elini kaldırır, siz de o yüzü o isimle eşleştirip konuşmaya başlarsınız.

Ağdaki iki cihaz da tam olarak bunu yapar. Elinizdeki IP adresi bir isimdir; kabloya paket koyabilmek için gereken MAC adresi ise yüzdür. İkisini birbirine bağlayan protokolün adı ARP’tır ve aşağıda o sorunun pakette nasıl göründüğünü, cevabın nasıl saklandığını ve kimse kimlik sormadığı için nelerin ters gidebileceğini göreceksiniz.

ARP, ağ protokolleri zincirinin en alt basamağıdır: adres almadan, isim çözmeden, bilet almadan önce bu soru sorulur. Kurumsal bir ağda arıza teşhisi de bu yüzden çoğu zaman buradan başlamak zorundadır.

IP adresinin kendisi, ağ kısmının nerede bittiği ve maskenin ne işe yaradığı ayrı bir konudur; onları IP adresi ve subnet maskesi rehberimizde ele aldık. Aşağıdakileri anlamak için şart değil, ama okumadıysanız oradan başlamak işinizi kolaylaştırır.

Anlatılanların tamamı lab ortamındaki gerçek makinelerden ölçüldü. Paket dökümleri uydurulmadı, ntp01 üzerinde tcpdump ile yakalandı.

Elinizde şu an çözmeniz gereken bir arıza varsa, doğrudan hangi çıktının neyi söylediğine atlayabilirsiniz.

ARP Nedir? IP Adresini MAC Adresine Çeviren Protokol

ARP (Address Resolution Protocol, Adres Çözümleme Protokolü), aynı yerel ağdaki bir IP adresinin hangi MAC adresine ait olduğunu bulan protokoldür. Cihaz ağa “şu IP kimde?” diye sorar, o adresin sahibi “bende, fiziksel adresim şu” diye cevaplar. İş budur, tek cümlede biter.

Salon benzetmesinde eşlemeler şöyle oturuyor:

Bu protokolün ilginç yanı, ne kadar sessiz çalıştığıdır. ARP hiçbir arayüzde görünmez, hiçbir günlüğe düşmez, hiçbir ayar ekranı yoktur. Ağınız yıllarca çalışır ve siz ARP’ın varlığını hiç fark etmezsiniz. Ta ki bir gün iki cihaz birbirini bulamayana kadar.

Neden İki Adres Var? MAC ve IP Adresinin İş Bölümü

İki adres var, çünkü ikisi farklı sorulara cevap veriyor: MAC adresi “bu kabloda kim var”, IP adresi ise “bu paket dünyanın neresine gidecek” sorusunu. Biri yereldir ve donanıma yazılıdır; diğeri mantıksaldır ve size atanır.

Fark en net şurada görünür: bir paket İstanbul’dan Frankfurt’a giderken IP adresi hiç değişmez, MAC adresi her yönlendirici geçişinde baştan yazılır. MAC adresi uçtan uca taşınmaz, yalnızca bir sonraki durağa kadar geçerlidir. Port ve bağlantı beşlisi rehberimizde bu yüzden MAC adresinin beşlinin parçası olmadığını yazmıştık: o bilgi ikinci katmanda yaşar ve orada kalır.

Peki neden ikisi birden? Tek adresle idare edilseydi ne olurdu sorusunu iki yönden de sormak gerekiyor, çünkü iki farklı şey kırılıyor.

Yalnız MAC adresi olsaydı yönlendirme çökerdi. MAC adreslerinde coğrafi bir mantık yoktur: yan yana duran iki bilgisayarın adresi birbirine hiç benzemez, üretici ve üretim sırasına göre dağıtılmıştır. Bu yüzden gruplanamazlar. Bugün bir yönlendirici “şununla başlayan adreslerin hepsi şu yöne” diyerek milyonlarca adresi tek satırda özetleyebiliyor; MAC ile bunu yapamazdı, dünyadaki her ağ kartını tek tek yazması gerekirdi.

Yalnız IP adresi olsaydı hiçbir cihaz işe başlayamazdı. Yeni açılan bir makinenin IP adresi yoktur, onu ağdan ister. Ama istemek de bir paket göndermek demektir ve paket gönderebilmek için elinde zaten bir adres olması gerekir. Yani adres alabilmek için adres lazımdır. Bu kısır döngüyü kıran şey MAC adresidir: fabrikada yazılır, hiçbir yapılandırma gerektirmez ve makine daha hiçbir şey bilmezken bile oradadır. DHCP bunun üzerine kurulur: sunucu, henüz adresi olmayan makineyi MAC adresinden tanır ve dağıttığı adresin kira kaydını ona bağlar.

İkinci maddenin kanıtı birazdan göreceğiniz dökümde duruyor ve gözden kaçması kolay: ARP isteğinin satırında ethertype ARP (0x0806) yazar, IPv4 (0x0800) değil. O çerçevenin içinde IP başlığı hiç yoktur. ARP, IP’nin üstünde değil yanında çalışır; zaten başka türlü olamazdı, çünkü işi IP’nin henüz bilmediği bir şeyi bulmak.

Özetle IP adresi ölçeği, MAC adresi ise başlangıcı ve yereldeki kesinliği sağlıyor. ARP tam olarak bu ikisinin arasındaki boşluğu dolduruyor ve o boşluk yalnız bir kablo genişliğinde: kendi yayın alanınızın dışına çıkamaz.

ARP Nasıl Çalışır? Request ve Reply Çifti

ARP tek bir soru ve tek bir cevaptan oluşur: who-has isteği yayına gider, is-at cevabı yalnız soran cihaza döner. İki sözcük paket dökümünde aynen böyle yazar: who-has “bu adres kimde?”, is-at ise “şu donanım adresinde” demektir. Bunu lab ortamında ölçtük.

Kurgu basit: ntp01 (192.168.1.15) makinesinin önbelleğinden ldap01’in (192.168.1.25) kaydını sildik, sonra tek bir ping attık ve aynı anda ağ trafiğini kaydettik. Beklentimiz, ping’den önce bir ARP alışverişi görmekti.

sudo ip neigh flush dev ens33
ping -c 1 192.168.1.25

Aşağıdaki dökümde üç yere bakın: her satırın başındaki hedef MAC adresine, sorunun ve cevabın yönüne, ve zaman damgalarındaki farka.

20:29:59.271996 00:0c:29:a0:71:9a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806): Request who-has 192.168.1.25 tell 192.168.1.15
20:29:59.272559 00:0c:29:7c:79:af > 00:0c:29:a0:71:9a, ethertype ARP (0x0806): Reply 192.168.1.25 is-at 00:0c:29:7c:79:af
20:29:59.272572 00:0c:29:a0:71:9a > 00:0c:29:7c:79:af, ethertype IPv4 (0x0800): 192.168.1.15 > 192.168.1.25: ICMP echo request
20:29:59.273029 00:0c:29:7c:79:af > 00:0c:29:a0:71:9a, ethertype IPv4 (0x0800): 192.168.1.25 > 192.168.1.15: ICMP echo reply

Bir sözcük daha var ve en çok yanlış okunanı o: tell bir emir değil, adres bildirir. Yani ilk satır tam olarak şunu söylüyor: “192.168.1.25 kimde? Soran 192.168.1.15.” İkinci satır da cevabı veriyor: “192.168.1.25, 00:0c:29:7c:79:af adresinde.”

Okunacak satırlar şunlar:

1. İlk satırdaki hedef ff:ff:ff:ff:ff:ff. Bu, “herkese” demektir. Soru tek bir cihaza değil, aynı yayın alanındaki bütün cihazlara gidiyor. Salona bağırmanın ağdaki karşılığı budur.
2. İkinci satırdaki hedef artık 00:0c:29:a0:71:9a. Cevap yayın değil, doğrudan soranın adresine gidiyor. Yani salonda herkes soruyu duyar, ama cevabı yalnız soran kişi alır.
3. Birinci ve ikinci satır arasında 563 mikrosaniye var. Ping’in kendisi henüz yola çıkmadı bile. ARP, farkına varamayacağınız kadar hızlı biten bir ön hazırlıktır.
4. Üçüncü satırdaki ICMP paketi, cevabı öğrenilen MAC adresine gidiyor. Yani sıralama şu: önce yüzü öğren, sonra konuş.

Beş saniye sonra aynı yakalamada bir satır daha belirdi ve protokolün en çok atlanan yanını gösteriyor:

20:30:04.627661 00:0c:29:7c:79:af > 00:0c:29:a0:71:9a: Request who-has 192.168.1.15 tell 192.168.1.25
20:30:04.627682 00:0c:29:a0:71:9a > 00:0c:29:7c:79:af: Reply 192.168.1.15 is-at 00:0c:29:a0:71:9a

Bu kez soruyu karşı taraf soruyor. Ama sorduğu şey ilk bakışta sanıldığı gibi değil ve farkı bu iki satır ele veriyor.

Bu isteğin hedefi ff:ff:ff:ff:ff:ff değil, doğrudan 00:0c:29:a0:71:9a. Yani ldap01 çerçeveyi ntp01’in MAC adresine göndermiş; bilmediğiniz bir adrese çerçeve gönderemezsiniz, demek ki o adresi zaten biliyordu.

Nereden bildi? İlk satırdan. Bir ARP isteği yalnız soru sormaz, aynı zamanda soranın kendi adres çiftini de taşır. Paketin içinde “ben 192.168.1.15’im ve MAC adresim 00:0c:29:a0:71:9a” bilgisi hazır durur; isteği alan makine bunu kaydeder. ldap01 de kaydetmiş ve hemen kullanmış: yukarıdaki ilk dökümde ping’e 457 mikrosaniyede cevap verdi, arada hiçbir şey sormadan.

Peki beş saniye sonraki bu alışveriş ne? Öğrenme değil, doğrulama. Kulak misafiri olarak edinilmiş bir kaydı işletim sistemi doğrulanmış saymaz; o kayda ilk kez gerçekten dayanması gerektiğinde bir kez sınar. Sınadığı şey eşlemenin doğruluğu değil, karşı tarafın hâlâ orada olması. Linux’ta bu beklemenin adı delay_first_probe_time ve ntp01 üzerinde ölçtüğümüzde 5 saniye çıkmıştı; iki satır arasındaki fark da 5,36 saniye. Uzun olan bekleme, sınamanın kendisi değil: soru ile cevap arasında yalnızca 21 mikrosaniye var.

Buradan iki kural çıkıyor ve ikincisi sahada daha çok işe yarar. Birincisi: ARP çift yönlü değildir, ama bilgi tek yönlü akmaz; soru bir yöne gider, adres çifti iki tarafa birden yerleşir. İkincisi: karşı taraf sizi tanımıyorsa sebep genellikle “sormadı” değildir, sorunuz ona hiç ulaşmamıştır. Tek yönlü çalışan arızalarda bakılacak yer budur.

ARP Önbelleği ve Durumları: Makine Kimi Hatırlıyor?

Bir önceki bölümde çözümlemenin yarım milisaniye sürdüğünü gördük. Ucuz görünüyor. Ama her paket için sorulsaydı ucuz olmazdı: her soru bir yayındır ve yayın, salondaki herkesin işini böler. Bu yüzden makine öğrendiği eşleşmeyi saklar. O saklama alanının adı ARP önbelleğidir.

Bu önbelleği okumak için Linux’ta iki komut vardır: arp -a eskisidir, ip neigh show ise onun yerini alan modern karşılığıdır. İkisi de aynı tabloya bakar ama size aynı şeyi anlatmaz, ve aradaki fark bir arızada hangi komutu yazdığınızı önemli hale getirir. Görmek için ikisini aynı makinede arka arkaya çalıştıralım. Önce eskisi:

arp -a

? (192.168.1.25) at 00:0c:29:7c:79:af [ether] on ens33
? (192.168.1.1) at 60:d8:a4:a7:2e:99 [ether] on ens33
? (192.168.1.10) at <incomplete> on ens33
? (192.168.1.115) at ec:75:0c:9f:45:ea [ether] on ens33

Dört satır, dört komşu. Bu çıktı tek bir şey söylüyor: adresin karşılığı ya biliniyor ya da <incomplete>, yani bilinmiyor. Arada kademe yok, bir kaydın ne kadar taze olduğu görünmüyor.

Şimdi aynı makinede, aynı anda, modern komut:

ip neigh show

192.168.1.25 dev ens33 lladdr 00:0c:29:7c:79:af REACHABLE
192.168.1.1 dev ens33 lladdr 60:d8:a4:a7:2e:99 STALE
192.168.1.10 dev ens33 INCOMPLETE
192.168.1.115 dev ens33 lladdr ec:75:0c:9f:45:ea REACHABLE
fe80::1 dev ens33 lladdr 60:d8:a4:a7:2e:99 router STALE

Aynı tablo, ama iki fark var ve ikisi de teşhiste işinize yarayacak. Birincisi, her satır artık bir durum taşıyor: REACHABLE, STALE, INCOMPLETE. İkincisi, bu çıktıda bir satır fazla var: en alttaki fe80::1, yani bir IPv6 komşusu. Eski komut onu hiç göstermiyor.

arp komutu eski net-tools paketinden gelir, durum bilgisi vermez ve yalnız IPv4 bilir; ip neigh moderni olduğu için teşhiste kullanılması gereken odur. Windows tarafında karşılık arp -a olarak kalır ve o da durum yerine dynamic / static ayrımı verir.

Durumlar makinenin o komşu hakkındaki güven seviyesini anlatıyor:

Tablo durumların ne anlama geldiğini veriyor. Teşhiste asıl işe yarayan şey ise aralarında nasıl gezindiğidir, çünkü bir kaydı gördüğünüz an size bir önceki adımı da söyler:

Buradaki en çok yanlış okunan satır STALE’dir. Kayıt STALE olduğu için bozuk değildir; makine yalnızca “bu bilgiyi bir süredir tazelemedim” diyor. Trafik başladığında kayıt sessizce doğrulanır ve REACHABLE’a döner. Yukarıdaki çıktıda modem (192.168.1.1) tam olarak bu durumda ve ağda hiçbir sorun yok.

Aynı makinede birkaç dakika önce alınmış bir başka anlık görüntü, tablodaki son durumu da gösteriyor:

192.168.1.1 dev ens33 lladdr 60:d8:a4:a7:2e:99 STALE
192.168.1.20 dev ens33 FAILED
192.168.1.10 dev ens33 FAILED
192.168.1.115 dev ens33 lladdr ec:75:0c:9f:45:ea REACHABLE
fe80::1 dev ens33 lladdr 60:d8:a4:a7:2e:99 router STALE

INCOMPLETE ile FAILED arasındaki fark, sahada zaman kazandıran türden bir ayrımdır: INCOMPLETE makinenin hâlâ sorduğu, FAILED ise sormayı bıraktığı anlamına gelir. Yani INCOMPLETE gördüğünüzde soru o anda hâlâ tekrarlanıyordur, FAILED gördüğünüzde ise deneme çoktan bitmiştir ve kayıt yeni bir trafik olana kadar öylece durur. İkisi de aynı şeyi söyler, cihaz cevap vermiyor; ama biri size arızanın canlı olduğunu, diğeri bir süre önce yaşandığını anlatır.

Lab: ARP Tablosu Ne Diyor? Üç Makine, Üç Farklı Sessizlik

Şimdi önbelleğin arıza anında ne söylediğine bakalım, çünkü asıl değeri orada.

Sahadaki en büyük yanılgılardan biri de şudur: “ping atıyorum, cevap gelmiyor, demek ki cihaz kapalı.” Bu çıkarım çoğu zaman yanlıştır ve nedenini ölçtük. Aynı ağdaki üç makineye ping attık; üçü de sustu, ama üçü aynı sebeple susmadı.

Birinci makine, 192.168.1.25: sağlıklı referans. Ping cevap veriyor, ARP kaydı REACHABLE. Bir önceki bölümdeki döküm bu makineye ait, tekrar etmiyoruz.

İkinci makine, 192.168.1.10: kapalı bir sunucu. Ping çıktısı şöyle:

PING 192.168.1.10 (192.168.1.10) 56(84) bytes of data.
From 192.168.1.15 icmp_seq=1 Destination Host Unreachable
From 192.168.1.15 icmp_seq=2 Destination Host Unreachable

2 packets transmitted, 0 received, +2 errors, 100% packet loss

Çıktıdaki Destination Host Unreachable satırlarının başında duran adrese dikkat edin: 192.168.1.15, yani ping’i atan makinenin kendisi. Mesaj hedeften gelmiyor. Ping’in ürettiği hata mesajlarının hangisinin kimden geldiği ve bunun teşhisi nasıl daralttığı ICMP ve ping hataları makalesinde ayrı ayrı ölçüldü.

Aynı anda kaydettiğimiz trafikte ise şunlar var:

20:27:11.143707 00:0c:29:a0:71:9a > ff:ff:ff:ff:ff:ff: Request who-has 192.168.1.10 tell 192.168.1.15
20:27:12.167705 00:0c:29:a0:71:9a > ff:ff:ff:ff:ff:ff: Request who-has 192.168.1.10 tell 192.168.1.15

Dikkat edilecek iki nokta var ve ikisi de kolay kaçırılır:

1. Destination Host Unreachable mesajı 192.168.1.15’ten geliyor, yani makinenin kendisinden. Bir yönlendirici size haber vermiyor; sizin kendi çekirdeğiniz “bu paketi kabloya koyamıyorum, çünkü hedefin MAC adresini bulamadım” diyor. Bu satırı bir router mesajı sanmak, aramayı baştan yanlış yere yönlendirir.
2. Yayına atılan soru cevapsız kalıyor ve saniyede bir tekrarlanıyor. Salona bağırıyorsunuz, kimse el kaldırmıyor. Önbellekteki karşılığı INCOMPLETE, bir süre sonra FAILED.

Üçüncü makine, 192.168.1.115: ve burada beklenti çöküyor. Ping sonucu ikinci makineyle neredeyse aynı:

PING 192.168.1.115 (192.168.1.115) 56(84) bytes of data.

3 packets transmitted, 0 received, 100% packet loss

Ama yakalamada tamamen başka bir şey görünüyor:

20:28:43.518120 00:0c:29:a0:71:9a > ec:75:0c:9f:45:ea, ethertype IPv4: 192.168.1.15 > 192.168.1.115: ICMP echo request
20:28:44.519826 00:0c:29:a0:71:9a > ec:75:0c:9f:45:ea, ethertype IPv4: 192.168.1.15 > 192.168.1.115: ICMP echo request

192.168.1.115 dev ens33 lladdr ec:75:0c:9f:45:ea REACHABLE

ICMP paketi doğru MAC adresine, tek hedefe gidiyor. Yani ARP çalıştı. Makine soruyu sordu, karşı taraf el kaldırdı, eşleşme kuruldu ve önbellekte REACHABLE olarak duruyor. Cevapsız kalan şey ARP değil, ping’in kendisi: o makinenin güvenlik duvarı ICMP’yi düşürüyor.

Üç vakayı yan yana koyduğumuzda öğrendiğimiz şey üç makine değil, şu ayrımdır:

Ortadaki sütun bu makalenin tezidir: ping susabilir, ARP susmaz. Ping bir uygulamaya, bir güvenlik politikasına ve bir güvenlik duvarı kuralına tabidir; ARP ise çerçevenin kabloya konabilmesi için zorunludur. Bir makine ağda ayaktaysa ve aynı yayın alanındaysa ARP’a cevap vermek zorundadır, çünkü cevap vermezse hiçbir trafik alamaz. Bu zorunluluğun madalyonun öbür yüzünü de yarattığını aşağıda göreceğiz: teşhiste elinizi güçlendiren şey, saldırgana da kapanmayan bir kanal bırakıyor.

Pratik sonuç, teşhis sırasını tersine çevirir: “ping çalışmıyor” dediğinizde bakılacak ilk yer üst katmanlar değil, ip neigh çıktısıdır. Kayıt REACHABLE ise cihaz oradadır ve sorun filtrededir; kayıt hiç oluşmuyorsa sorun ikinci katmandadır ve yukarıda arama yapmak vakit kaybıdır.

Switch’in MAC Adres Tablosu: Çerçeve Doğru Portu Nasıl Buluyor?

Buraya kadar hep aynı tabloya baktık: makinenin ARP tablosuna. Ama bir çerçevenin yolculuğu orada bitmez. Makineniz MAC adresini öğrendikten sonra çerçeveyi kabloya koyar ve o andan sonra teslimat kararını başkası verir: Switch.

Bir çerçeve 192.168.1.20’ye giderken sırayla şunlar olur:

1. Makineniz sorar: “192.168.1.20 kimin?” Bu ARP’tır. Cevap bir MAC adresidir ve ARP tablonuza yazılır.
2. Makineniz çerçeveyi o MAC adresine gönderir. IP’nin işi burada biter; kabloya çıkan şey artık bir MAC adresidir.
3. Switch devralır: “bu MAC benim hangi portumda?” Kendi tablosuna bakar ve çerçeveyi yalnız o porttan çıkarır.

Yani ağda arka arkaya iki çeviri yapılır ve her biri ayrı bir cihazda, ayrı bir tabloda durur:

Üçüncü adım, switch’i hub’dan ayıran şeydir. Hub’ın böyle bir tablosu yoktur, geleni bütün portlara kopyalar. Switch ise tablosu sayesinde yalnız doğru kabloya gönderir. Salon benzetmesinde bu ikinci tablo kapı görevlisinin defteridir: siz kimi aradığınızı bilirsiniz, o kişinin hangi kapıdan girdiğini defter bilir. Hub’da defter yoktur, görevli her mesajı bütün kapılardan birden bağırır.

Peki switch bu tabloyu nereden bilir? Kimse ona anlatmaz, geçen trafikten öğrenir. Bir porttan gelen çerçevenin kaynak adresini okur ve o adresi o portla eşler. Lab’daki yönetilebilir switch’e sorduğumuzda tablosu şuydu:

console#show mac address-table

Aging time is 300 Sec

Vlan     Mac Address           Type        Port
-------- --------------------- ----------- ---------------------
1        F48E.381B.184D        Management  Vl1
5        5811.22B1.0E54        Dynamic     Gi1/0/1
5        F48E.381B.184D        Management  Vl5

Total MAC Addresses in use: 3

Ortadaki satır iş istasyonunun Ethernet arayüzü: 5811.22B1.0E54 adresi Gi1/0/1 portunda görülmüş ve tipi Dynamic. Bu satırı kimse yazmadı; switch o kablodan geçen bir çerçeveye bakıp kendisi çıkardı. Diğer iki satır switch’in kendi yönetim adresi. Bu üç satır, yukarıda anlattığımız ikinci çevirinin ta kendisi: bir MAC adresi ve onun durduğu fiziksel port.

İki tablo da artık yerinde. Ama ikisi de bir hafızaya yazılıyor ve hafıza devreye girdiği anda yeni bir soru doğuyor: bu kayıtlar ne kadar süre yaşıyor?

Kim Ne Kadar Hatırlar? ARP ve MAC Tablolarının Ömrü

Sahada en çok tekrarlanan sayı beş dakikadır. Sayı doğrudur, ama çoğu zaman yanlış tabloya yapıştırılır. Ölçtüğümüzde çıkan tablo şu: bir çerçevenin yolunda üç ayrı sayaç var, üçü de farklı cihazda ve üçü de farklı süre.

Üç Ayrı Sayaç, Üç Ayrı Cihaz

Birinci satır Linux’ta base_reachable_time_ms, Windows’ta BaseReachableTime adıyla duruyor; ikisinde de 30000 ölçtük. İkinci satırın kanıtı yukarıdaki çıktının ilk cümlesi: Aging time is 300 Sec. Üçüncüsü aynı cihazda, ama ayrı bir komutla görünüyor:

console#show arp

Age Time (seconds)............................. 1200
Response Time (seconds)........................ 1
Retries........................................ 4
Cache Size..................................... 1000
Dynamic Renew Mode ............................ Enable
Total Entry Count Current / Peak .............. 2 / 2

IP Address       MAC Address        Interface       Type      Age
---------------  -----------------  --------------  --------  -----------
192.168.1.2      F48E.381B.184D     Vl5             Local         n/a
192.168.1.224    5811.22B1.0E54     Vl5             Dynamic    0h  0m  0s

Aynı switch, iki tablo, iki ayrı süre. Alttaki Age sütunu kaydın yaşını gösterir ve bu çıktıda sıfıra yakın duruyor. Sebebi ayar değil trafik: 192.168.1.224 o sırada konuşan bir cihazdı ve akan her çerçeve kaydı tazeliyordu. Dynamic Renew Mode’un tek başına ne yaptığı ise ayrı bir sorudur ve cevabı ancak trafik kesildiğinde görünür. Aşağıdaki ölçüm tam olarak onu kesti.

Bu sayılar birer alt sınırdır, kesin teslim tarihi değil. MAC adres tablosunu ölçtük: bir adres ağdan tamamen yok edildikten sonra kayıt 373. saniyede hâlâ duruyordu, 439. saniyede düşmüştü. Yapılandırmada 300 yazmasına rağmen. Sebebi tasarım gereği: switch tabloyu sürekli değil periyodik olarak tarar ve her kayıtta “bu turda kullanıldı mı” işaretine bakar; iki tur boyunca kullanılmayan kayıt silinir. Bu yüzden gerçek silinme süresi, ayarlanan değerin bir ila iki katı arasındadır. Yani 300 saniyelik bir ayar pratikte 300 ile 600 saniye arasında bir yerde iş görür.

Salonda tek bir hafıza vardı: sizinki. Ağda üç tane var ve üçü aynı anda unutmuyor.

Teşhisteki karşılığı şudur: “ARP kaç dakika hatırlar?” sorusunun tek bir cevabı yoktur, hangi cihaza sorduğunuza bağlıdır. Bir cihaz ağdan koptuğunda iş istasyonunun kaydı yarım dakika içinde şüpheli hale gelirken, switch’in tablosundaki satır beş dakika daha durabilir. Yani ip neigh çıktısı boşalmışken show mac address-table cihazı hâlâ gösteriyorsa bu bir çelişki değil, iki ayrı sayacın farkıdır.

Lab: Aynı IP, Yeni Cihaz. Kim Ne Zaman Fark Ediyor?

Buraya kadar sayaçların ne kadar sürdüğüne baktık. Asıl soru şu: bu süreler ne zaman canınızı yakar?

Şu sahneyi düşünün. Bir cihaz arızalandı, yerine yenisini taktınız ve aynı IP adresini verdiniz. Adres değişmedi, arkasındaki donanım değişti. Ya da bir kamerayı .50’den .101’e aldınız, boşalan .50’yi de başka bir kameraya verdiniz. İkisinde de aynı şey olur: bir adres, beş dakika öncekinden farklı bir cihazı gösteriyor.

Sorun şurada: o adresi hatırlayanlar bunu bilmiyor. Ellerindeki kayıt artık yanlış ve kimse onlara haber vermedi.

Bunu lab ortamında birebir kurduk. 192.168.1.99 adresini sabit tuttuk, arkasındaki cihazı değiştirdik ve eskisini ağdan tamamen kaldırdık; yani o adrese giden paketlerin ulaşacağı bir yer kalmadı. Yeni cihaz “ben geldim” diye bir duyuru da yapmadı, çünkü bu turda ölçmek istediğimiz şey duyuru olmadan ne olduğuydu. O duyurunun kendisini ve gerçekte ne kadar işe yaradığını aşağıda ayrıca ölçüyoruz.

Sonra aynı adresi arayan iki makineyi ayrı ayrı izledik: bir iş istasyonu ve bir switch.

İş istasyonu beş saniyede toparlandı:

17:24:13  OK     D6-76-8D-F7-D1-FB  Probe
17:24:18  KAYIP  D6-76-8D-F7-D1-FB  Unreachable
17:24:23  OK     52-57-6E-C6-D0-81  Reachable

Kayıt önce Probe’a, oradan Unreachable’a düştü. Makine yeniden yayın sorgusu attı, doğru MAC’i öğrendi ve devam etti. Toplam kayıp: bir paket.

Switch aynı olayda yirmi bir dakika sürdü. Değişimden altı dakika sonra hâlâ buradaydı:

console#ping 192.168.1.99
 Pinging 192.168.1.99 with 0 bytes of data:

----192.168.1.99 PING statistics----
4 packets transmitted, 0 packets received, 100% packet loss

console#show arp
IP Address       MAC Address        Interface       Type      Age
---------------  -----------------  --------------  --------  -----------
192.168.1.99     1A4A.ED68.B905     Vl5             Dynamic    0h  6m 15s

1A4A.ED68.B905 artık var olmayan bir adrestir. Switch onu tutmaya devam ediyor ve her paketi oraya gönderiyor. Sonrasında da bırakmadı:

Kayıt tam olarak Age Time süresi dolduğunda düştü, bir saniye önce değil.

Farkı yaratan şey sayacın uzunluğu değil, davranış. Switch dört tur boyunca sıfır cevap aldı ve bir kez bile yayına çıkıp yeniden sormadı. Elindeki kayda güvenip ölü bir adrese paket göndermeye devam etti. Dynamic Renew Mode açık olmasına rağmen bu böyleydi: o ayar kaydı cevapsızlıkta sınamıyor, yalnızca sayaç dolduğunda yeniden çözümlüyor. Nitekim düzelme de tam orada geldi. Son satırdaki doğru MAC adresi, switch’in aradaki yirmi dakikada bir şey öğrenmesinden değil, sayacın dolup soruyu ilk kez yeniden sormasından geliyor.

Sahadaki karşılığı şudur: bir kamerayı ya da erişim noktasını yeni bir adrese aldığınızda kendi bilgisayarınızdan hemen erişebilirsiniz, ama ağdaki başka bir cihaz onu yirmi dakika bulamayabilir. İkisi de doğru çalışıyordur; biri sorusunu tekrar sorar, diğeri sormaz. Teşhis sırasında “bende çalışıyor” cümlesinin neden hiçbir şey kanıtlamadığını akılda tutun.

Bu iki tablo birlikte çalıştığı sürece ağ sessizce işler. Ama ikisi de aynı koşula bağlıdır ve o koşulu şimdiye kadar hiç sorgulamadık.

Yayın Alanı: ARP’ın Duvarı Nerede Biter?

O koşul şudur: aynı yayın alanında olmak. ARP isteği oraya ulaşamıyorsa MAC adresi hiç öğrenilmez; switch’in tablosu ne kadar doğru olursa olsun teslim edilecek bir çerçeve oluşmaz. Şimdi o duvarın nerede durduğuna bakalım, çünkü sahadaki en pahalı teşhis hatalarından biri tam burada doğuyor.

Yayın alanı, bir yayın paketinin ulaşabildiği en geniş alandır. ARP isteği yayın olduğu için ARP’ın menzili de tam olarak budur. Salonun duvarları: içeride bağırdığınızı herkes duyar, dışarıdakiler hiçbir şey duymaz.

Bu duvarı ören şey çoğu kurumsal ağda kablo değil, çerçevelere iliştirilen bir etikettir. Duvarın nasıl çizildiği ve tek bir portun aynı anda iki yayın alanına nasıl hizmet edebildiği VLAN ve 802.1Q yazımızın konusu.

Bunun ne kadar gerçek olduğunu görmek için ntp01 üzerinde 30 saniye boyunca hiçbir şey yapmadan ARP trafiğini dinledik:

sudo tcpdump -i ens33 -n "arp"

20:25:30.133858 ARP, Request who-has 192.168.1.158 tell 192.168.1.115
20:25:38.766755 ARP, Request who-has 192.168.1.15 tell 192.168.1.1
20:25:38.869127 ARP, Request who-has 192.168.1.25 tell 192.168.1.1
20:25:38.971489 ARP, Request who-has 192.168.1.30 tell 192.168.1.1

Bu dört satırın hiçbiri bizim ürettiğimiz trafik değil. Birincisinde bir iş istasyonu bambaşka bir adresi arıyor; sonraki üçünde modem sırayla ağdaki cihazları yokluyor. Hepsini duyuyoruz, çünkü aynı salondayız. Yayın alanı soyut bir kavram değil, dinlediğinizde duyduğunuz gürültüdür.

Peki hedef gerçekten başka bir ağdaysa ne olur? Makine hedefi aramaz, çıkış kapısını arar. Salondan çıkması gerektiğini anlar ve kapıdaki görevliye seslenir. Paket dökümünde bunun karşılığı, who-has satırındaki adresin hedef yerine gateway adresi olmasıdır. Bu davranışın maske yanlış yazıldığında nasıl bir performans kaybına yol açtığını IP adresi rehberimizin ölçüm bölümünde göstermiştik.

Lab: Aynı Ağda Görünen İki Cihaz, İki Ayrı Yayın Alanı

Buraya kadarı iddia. Şimdi ölçelim, çünkü bu bölüm sahada en çok şu itirazı alır: switch’in adresi de 192.168.1.2/24 ise ikisi zaten aynı ağdadır, nasıl ulaşılamıyor? Yerinde bir itiraz, ve cevabı beklendiği yerde değil.

Ölçüm sırasında ağda beş adres vardı ve beşi de 192.168.1.0/24 içindeydi:

Önce iş istasyonuna soralım. Windows’ta komşu tablosunu hangi arayüzden çözüldüğüyle birlikte gösteren komut şudur:

Get-NetNeighbor -IPAddress 192.168.1.2, 192.168.1.1

InterfaceAlias IPAddress   LinkLayerAddress        State
-------------- ---------   ----------------        -----
Wi-Fi          192.168.1.2 00-00-00-00-00-00 Unreachable
Wi-Fi          192.168.1.1 60-D8-A4-A7-2E-99   Reachable
Ethernet       192.168.1.2 F4-8E-38-1B-18-4D   Reachable
Ethernet       192.168.1.1 00-00-00-00-00-00  Incomplete

Dört satırı okumanın en kolay yolu önce LinkLayerAddress sütununa bakmak. İki satırda gerçek bir donanım adresi var, iki satırda 00-00-00-00-00-00.

00-00-00-00-00-00 bir MAC adresi değildir, boş bir kutudur. Makine o adresi sordu, kimse cevap vermedi, dolayısıyla yazacak bir şey bulamadı. Sorduğunu unutmadığı için satır tabloda duruyor, ama cevap hanesi sıfırlarla dolu kalıyor. Yanındaki State sütunu da aynı şeyi söylüyor: Unreachable ve Incomplete, ikisi de “cevap gelmedi”nin iki ayrı hâli.

Şimdi tabloya bir daha bakın. Cevap veren satırlar çapraz duruyor:

Modem yalnız kablosuz taraftan, switch yalnız kablodan cevap veriyor. Yani iki adres birbirine bir hane uzaklıkta, aynı maskeyi taşıyor, ve farklı kablolarda oturuyor.

Bu makineden iki adrese de ping çalışır, çünkü iş istasyonunun her iki alanda da bir ayağı vardır. Ayrımı gösteren şey ping değil, cevabın hangi arayüzden geldiğidir.

Şimdi tek arayüzlü bir makineye, kablosuz tarafa köprülü ntp01’e geçelim. ARP tablosunu sıfırlayıp switch’e bağlanmayı deniyoruz:

sudo ip neigh flush dev ens33
ssh ilker@192.168.1.2

ssh: connect to host 192.168.1.2 port 22: No route to host

Ardından komşu tablosuna bakıyoruz:

ip neigh show dev ens33

192.168.1.1    lladdr 60:d8:a4:a7:2e:99 REACHABLE
192.168.1.115  lladdr ec:75:0c:9f:45:ea REACHABLE
192.168.1.2                             FAILED
192.168.1.224                           INCOMPLETE

Dört adres, dördü de aynı /24 içinde, ikisi bulundu ikisi bulunamadı. Modem ve iş istasyonunun kablosuz arayüzü REACHABLE; switch FAILED, iş istasyonunun Ethernet arayüzü INCOMPLETE. Bulunamayan iki adresin tek ortak yanı, kablonun öbür ucunda olmaları.

İtirazın cevabı da burada. ntp01, 192.168.1.2’yi kendi maskesine göre kendi ağında sayar. Bu yüzden paketi yönlendiriciye teslim etmez, doğrudan ARP eder ve cevap bekler. Cevap gelmez. Switch başka bir adres bloğunda olsaydı, örneğin 192.168.99.2, ntp01 paketi gateway’e verirdi ve aradaki yönlendirme kuruluysa ulaşırdı. Yani aynı ağda olmak burada bir güvence değil, arızanın sebebidir. Maske “bu benim komşum” der, kablo “değil” der, ve ARP kabloya inanır.

Tabloda bir satır daha var ve tek başına bu makalenin tezini taşıyor. Aynı makineden iş istasyonunun kablosuz adresine ping attık:

ping -c 2 192.168.1.115

2 packets transmitted, 0 received, 100% packet loss, time 1031ms

Ping tamamen sessiz, ama aynı adresin komşu kaydı REACHABLE ve MAC adresi doğru yazılmış. Cihaz oradadır, Windows Firewall ICMP’yi drop etmektedir: paket sessizce çöpe atılır, geriye bir hata mesajı bile dönmez. Bir güvenlik duvarının paketi sessizce yutması ile açıkça reddetmesi arasındaki fark ve bunun teşhis süresine yansıması port rehberimizin güvenlik duvarı ölçümünde duruyor. Ping susabilir, ARP susmaz; bu tabloda ikisi yan yana duruyor.

Topoloji ve Switch Seçimi: ARP’ın Gizli Faturası

Yayın alanının sınırını çizen cihaz yönlendiricidir; switch ise varsayılan olarak bu sınırı genişletir, daraltmaz. Sınırı switch üzerinde çizmek istiyorsanız araç VLAN’dır.

Yani ARP’ın menzilini protokol belirlemez, siz belirlersiniz. Kabloları nasıl çektiğiniz ve hangi cihazı aldığınız, henüz tek bir paket geçmeden önce bu sınırı çizer. Aşağıdaki iki bölüm bu iki kararın faturasını gösteriyor: biri topolojinin, diğeri cihaz seçiminin.

Yanlış Ağ Topolojisi: ARP Maliyeti ve Cihazlara Binen Yük

Yayın alanının nerede bittiği kâğıt üstünde teknik bir ayrıntı gibi durur. Sahada bir lokasyonun tamamını yavaşlatır.

Meslek hayatımda gördüğüm en sıkıntılı topolojilerden biri böyleydi: switch’ler birbirine arka arkaya eklenmiş, her yeni ihtiyaçta bir öncekinin boş portuna atlanmıştı. Sonuçta bütün lokasyonun internet performansı düşmüştü. Böyle topolojiler tek bir kötü kararla oluşmaz; arka arkaya alınmış, her biri tek başına masum görünen küçük kararlarla büyür.

Bir switch zincirinde üç şey aynı anda olur ve üçü de birikimlidir.

Birincisi bant genişliğidir. En uçtaki switch’e bağlı bütün cihazların trafiği, aradaki her switch’in tek bir uplink portundan geçmek zorundadır, yani zincir uzadıkça o tek kablo daha çok makinenin yükünü taşır.

İkincisi bu makalenin konusudur: zincirin tamamı tek bir yayın alanıdır. Bir uçtaki makinenin sorduğu who-has sorusu, aradaki her switch’ten geçer ve lokasyondaki her cihazın ağ kartına ulaşır. Cihaz sayısı arttıkça hem soruyu soran taraf büyür, hem o soruyu dinlemek zorunda kalan taraf. Salonun duvarlarını her kaldırdığınızda bağırışınızı daha çok kişi duyar; bir noktadan sonra herkes aynı anda bağırdığı için kimse kimseyi duymaz.

Üçüncüsü switch’lerin içinde birikir ve en geç fark edilen budur. Yukarıda kurduğumuz MAC adres tablosunu hatırlayın: zincirdeki her switch, yayın alanındaki adreslerin hepsini öğrenmek zorunda kalır, çünkü hepsinin trafiği bir noktada kendi üzerinden geçer. Tablonun kapasitesi sınırlıdır. Dolduğunda switch yeni adres öğrenemez ve hedefini bilmediği çerçeveleri bütün portlarından taşırır, yani o çerçeveler için switch olmaktan çıkıp hub gibi davranır.

Aynı yükün bir de uç tarafı vardır: her yayın çerçevesi, yayın alanındaki her ağ kartını kesintiye uğratır ve işletim sistemine kadar çıkar. Bir IP telefon ya da kamera bunu bir sunucu kadar rahat kaldırmaz.

”Aptal Switch” Neden ARP Teşhisini Kör Eder?

Yukarıdaki anlatım bir şeyi varsayıyor: switch’in tablosuna bakabildiğinizi. Sahada bu varsayım çoğu zaman tutmaz.

Yönetilemeyen switch’e sahada kısaca “aptal switch” denir ve bu ad yanıltıcıdır. O cihaz aptal değildir: MAC adres tablosu vardır, adresleri öğrenir, çerçeveyi doğru porttan çıkarır. Hub’dan farkı gerçektir ve durmaktadır. Eksik olan yönlendirme yeteneği değil, size cevap verme yeteneğidir. Kapıda bir görevli vardır ve defterini tutar; yalnız o defteri kimseye göstermez.

Bunun ARP teşhisine etkisi doğrudandır: bu makale boyunca kurduğumuz zincirin son halkası kopar. ARP tablosu size hangi MAC adresinin cevap verdiğini söyler. O adresi hangi fiziksel kabloya bağlayan bilgi ise switch’in tablosundadır. Oraya bakamıyorsanız elinizde yalnız bir MAC adresi kalır ve o adresin binanın neresinde durduğunu bulmanın tek yolu kabloları tek tek çekmektir.

İkincisi daha ağırdır. Yönetilemeyen bir switch’in arkasında sahte ARP cevabı üreten bir cihaz varsa, o cihaz hiçbir yerde görünmez: ne bir günlükte, ne bir tabloda, ne bir alarmda. Aşağıda anlatacağımız Dynamic ARP Inspection gibi önlemler de tam olarak burada devre dışı kalır, çünkü uygulanacakları yer o cihazın kendisidir.

Peki haritada olmayan o katı bulmanın bir yolu var mı? Var, ve o cihaza sormaya gerek yok: üstündeki yönetilebilir switch’e sorulur.

Bir switch portu normalde tek bir cihaz görür, yani MAC adres tablosunda o port için tek satır olur. Bir portta birden çok MAC adresi görüyorsanız, o portun arkasında çerçeveleri çoğaltan bir şey vardır. Lab’da bunu ölçtük:

Vlan     Mac Address           Type        Port
-------- --------------------- ----------- ---------------------
5        000C.29A0.719A        Dynamic     Gi1/0/2
5        5811.22B1.0E54        Dynamic     Gi1/0/2
5        EEA7.58A3.9726        Dynamic     Gi1/0/2

Tek portta üç adres. Bizim turumuzda sebebi sanal makine çalıştıran bir iş istasyonuydu, ama imza aynıdır ve ihtimaller kısa bir listedir: masa altına takılmış yönetilemeyen bir switch, sanallaştırma sunucusu, PC portu olan bir IP telefon, ya da bir erişim noktası. Hangisi olduğunu MAC adreslerinin üretici önekinden ve portun fiziksel yerinden daraltırsınız.

Yani cihaz haritada görünmese de iz bırakır. Sahada “burada yönetilemeyen bir switch var mı” sorusunun en hızlı cevabı budur: port başına MAC sayın, birden fazlaysa aşağıda bir şey vardır. Bu sayım ARP tablosunda yapılamaz, çünkü orada port bilgisi hiç yoktur; yalnız switch’in tablosunda görünür.

Kimsenin haberi olmadan takılan ucuz bir masa altı switch’i bu yüzden ağ haritasında olmayan bir kata benzer; kurumsal ağ kurulumu sayfamızda bunu “kaçak kat” benzetmesiyle anlatmıştık. Teşhis açısından anlamı tek cümledir: haritada olmayan bir yeri arıza anında arayamazsınız.

Buradan çıkan kural ekipman kalitesinden önce gelir: kalabalık bir ortamda yerel ağın sağlığını belirleyen şey topolojidir, geri kalan her şey onun üstüne kurulur. Pahalı bir güvenlik duvarı, yanlış kurgulanmış bir topolojinin faturasını ödemez. Cihaz seçimi ve segmentasyon kararları switch ve router kurulumu rehberimizde ele alınıyor.

Gratuitous ARP: Kimse Sormadan Konuşmak

Tasarım kararlarını bir kenara bırakıp protokolün kendisine dönelim. Buraya kadar gördüğümüz her ARP cevabı bir sorunun karşılığıydı. Ama protokolde, kimse sormadan konuşmaya izin veren bir biçim de var: gratuitous ARP. Cihaz kendi adresini kendisi ilan eder, yani salonda kimse çağırmadan ayağa kalkıp “ben buradayım, yüzüm bu” der.

Bu ilan üç işi birden görür:

1. Adres çakışması tespiti. Makine ayağa kalkarken kendi adresini sorar. Cevap gelirse o adres başkasında demektir ve çakışma daha ilk saniyede yakalanır.
2. Önbellek tazeleme. Ağdaki diğer cihazlar bu ilanı duyup kendi tablolarını günceller. Kimsenin ayrıca sorması gerekmez.
3. Devir teslim. Yedekli sistemlerde bir sanal adres bir makineden diğerine geçtiğinde, yeni sahip bu ilanı yayınlar. Amaç, ağa adresin artık başka bir MAC adresinde olduğunu duyurmaktır.

İlan Gönderilir, Ama Dinlenmek Zorunda Değildir

Üçüncü madde kâğıt üstünde temiz duruyor. Ölçtüğümüzde öyle çıkmadı.

Lab ortamında bir adresi yeni bir MAC adresine devrettik ve devralan taraf ilanını yaptı. İlan gerçekten yola çıktı, yakalamada duruyor:

ARP, Request who-has 192.168.1.99 tell 192.168.1.99

Kaynak ve hedef aynı adres: bu, gratuitous ARP’ın imzasıdır. Ama aynı ağdaki iş istasyonu bu ilanı dikkate almadı. Önbelleğinde eski MAC adresi 19 saniye daha durdu ve ancak makine kendi doğrulama turunu tamamlayıp yeniden yayın sorgusu attığında güncellendi.

Bu bir arıza değil, kasıtlı bir savunmadır. Geçerli bir kaydı, istenmeden gelen bir duyuruya bakarak değiştirmek, aşağıda anlatacağımız ARP spoofing saldırısını bedavaya vermek olurdu. İşletim sistemleri bu yüzden ilanı bir ipucu olarak alır, emir olarak değil.

Burada iki ayrı karar var ve sahada sürekli birbirine karıştırılıyor. Tabloda hiç kaydı olmayan bir adres için ilan gelirse ne olacağı bir sorudur; Linux’ta bunu arp_accept belirler ve varsayılanı yeni kayıt açmamaktır. Zaten var olan bir kaydın ilanla ezilip ezilmeyeceği ise başka bir sorudur, ve yukarıda ölçtüğümüz şey budur: kayıt vardı, ilan geldi, kayıt değişmedi. İş istasyonu eski MAC adresini bırakmak için ilanı değil, kendi doğrulama turunun sonucunu bekledi. Pratik sonucu şu: arp_accept ayarını değiştirmek o 19 saniyeyi kısaltmaz, çünkü o süreyi belirleyen ayar değil makinenin kendi sınama sayacıdır.

Pratik sonuç ikiye ayrılır ve ikisi de sahada işinize yarar:

• Gönderen taraf için: ilanı yapmak zorunludur. Yapmazsanız hiç kimse haberdar olmaz ve devir süresi tamamen karşı tarafın sayacına kalır.
• Alan taraf için: ilana güvenmeyin. Bir devir sonrası “duyuru gitti, herkes öğrendi” varsayımı yanlıştır; kim öğrendi kim öğrenmedi, ancak o cihazların tablolarına bakarak bilinir.

Yedekli güvenlik duvarı ve yük dengeleyici geçişlerinin bazen saniyeler yerine dakikalar sürmesinin sebebi çoğu zaman budur: ilan engellenmemiştir, dinlenmemiştir.

Adres çakışmasının neden doğduğu, yani iki dağıtıcının aynı havuzu paylaşması ya da elle verilen adreslerin kayıt altına alınmaması, ayrı bir konudur ve DHCP rehberimizde gerçek bir vakayla ele alınıyor. Buradaki mesele çakışmanın sebebi değil, makinenin onu ağda nasıl fark ettiğidir.

ARP Spoofing: Kimlik Sormayan Protokolün Bedeli

Gratuitous ARP’ta bir şey dikkatinizi çekmiş olmalı: bir cihaz, kimse sormadan, kendi adresini ilan edebiliyor ve diğerleri buna inanıyor. Peki inandıkları şeyin doğru olduğunu nereden biliyorlar? Bilmiyorlar. ARP’ın kimlik doğrulaması yoktur.

Hacker’ların En Sevdiği Protokol Neden ARP’tır?

Saldırganlar ARP’ı sevmez, ARP’ın kapatılamaz olmasını sever. Bir yerel ağa ayak basmış birinin elindeki en kullanışlı araç olmasının dört sebebi var ve dördü de bu makalede zaten ölçtüğümüz davranışlar:

1. Kapatılamaz. Çoğu güvenlik açığı bir servisi kapatarak, bir portu kısarak ya da bir sürümü yükselterek giderilir. ARP’ta böyle bir seçenek yoktur: kapatırsanız ağ çalışmaz. Saldırgan, hedefin asla vazgeçemeyeceği bir mekanizmanın üstünde çalışır.
2. Her zaman cevap alır. Lab bölümünde ölçtüğümüz şeyin diğer yüzü budur: ping susabilir, ARP susmaz. Güvenlik duvarı ICMP’yi düşüren 192.168.1.115 bile ARP’a cevap veriyordu. Yani bir cihaz kendini ne kadar kapatırsa kapatsın, aynı yayın alanındayken ARP kanalı açık kalır.
3. Soru sorulmasını beklemek zorunda değil. Gratuitous ARP bölümünde gördük: protokol, istenmemiş bir ilanı da kabul eder. Saldırganın uygun anı kollamasına gerek yoktur, istediği zaman konuşur ve sonradan gelen ilan öncekini sessizce ezer.
4. Hiçbir yere iz düşmez. Girişte söylediğimiz “ARP hiçbir günlüğe düşmez” cümlesi savunan için bir merak konusuydu; saldıran için bir avantajdır. Yakalanma riski, olağan yönetim araçlarıyla neredeyse sıfırdır.

Bunların toplamı şu: saldırgan yeni bir açık aramıyor, protokolün tasarım gereği yaptığı şeyi kendi lehine kullanıyor. Bu yüzden ARP’a yönelik saldırılar otuz yıldır aynı kalıyor ve bir yama ile kapanmıyor.

Bir de madalyonun öbür yüzü var ve savunma stratejisi tam olarak oradan çıkıyor: bütün bunlar yalnız saldırgan zaten aynı yayın alanının içindeyse geçerlidir. ARP internetten çalışmaz, duvarın dışına geçemez. Yani bu saldırının ön koşulu, birinin o ağa şu ya da bu şekilde girmiş olmasıdır: misafir Wi-Fi’dan, ele geçirilmiş bir bilgisayardan, ya da boş bir toplantı odası prizinden. Segmentasyonun neden savunmanın birinci adımı olduğu buradan anlaşılıyor: saldırıyı engelleyemezsiniz ama erişebileceği salonu küçültebilirsiniz.

Analojinin koptuğu yer tam olarak burasıdır ve bunu açıkça söylemek gerekiyor: gerçek bir toplantı salonunda başkasının adına el kaldıramazsınız, çünkü insanlar birbirinin yüzünü tanır. ARP’ta yüz tanıma yoktur. Protokol, gelen ilk cevabı kabul eder, kimin gönderdiğini sorgulamaz ve daha sonra gelen bir ilan öncekini sessizce ezer.

ARP spoofing, saldırganın başkasının IP adresi için sahte cevap üreterek trafiği kendi üzerine çekmesidir. Mekanizma üç adımdır ve hiçbiri protokolün ihlali değildir; hepsi protokolün izin verdiği şeylerdir:

1. Saldırgan, kurbana “gateway’in MAC adresi benim” der.
2. Aynı anda gateway’e “kurbanın MAC adresi benim” der.
3. İki taraf da tablolarını günceller ve trafik saldırganın üzerinden akmaya başlar. İki uç da normal çalıştığını görür, çünkü paketler yerine ulaşmaya devam eder.

Bu, ortadaki adam konumunu ele geçirmenin en ucuz yoludur ve şifresiz akan her şeyi görünür kılar. Bir arayüzde, bir günlükte ya da bir alarmda karşılığı yoktur; sessizce olur.

ARP Spoofing’e Karşı Ne Yapılır? Üç Araç, Üçü de Kısmi

Savunma tarafında üç araç var ve üçü farklı seviyede iş görüyor:

Uygulamada ilk sıra Dynamic ARP Inspection’dır, çünkü savunmayı uca değil ağa koyar. Ama doğrudan zorlama moduna alınmaz: yanlış yapılandırıldığında meşru trafiği de düşürür. İzlenen yol, önce güvenilir portları işaretlemek, özelliği izleme modunda çalıştırmak, günlükleri birkaç gün okumak ve yanlış pozitif kalmadığında zorlamaya geçmektir.

Bu adımların hepsinin ön koşulu, cihazların yönetilebilir olmasıdır. On üç lokasyonda switch erişimini paylaşılan şifrelerden kişisel hesaplara taşıdığımız projede işin kendisi ARP değildi, ama sıra aynıydı: önce cihaz parkının yönetilebilir hale gelmesi, sonra üzerine kural yazılması.

Şunu da açıkça söylemek gerekir: bu önlemler ARP’ı güvenli hale getirmez, yalnız yerel ağdaki istismarı zorlaştırır. Protokolün kendisinde kimlik doğrulaması yoktur ve olmayacaktır. Asıl savunma, trafiğin ele geçirilse bile okunamaz olmasıdır; yani şifreli protokoller kullanmaktır. Bu, siber güvenlik hizmetlerimizin ağ katmanındaki temel yaklaşımıdır.

ARP ile Teşhis: Hangi Çıktı Neyi Söyler?

Buraya kadar anlatılanların sahadaki karşılığı tek bir alışkanlıkta toplanıyor: bir bağlantı sorununda ip neigh çıktısına, ping’den önce bakmak.

Sık karşılaşılan belirtiler ve ilk bakılacak yerler:

Son satırı özellikle koyduk. STALE gördüğü için tabloyu temizleyen ve sorunu “çözdüğünü” sanan çok kişi var. Temizleme zararsızdır, ama sorunu çözmez: kayıt zaten ilk pakette yenilenirdi.

Bu tablonun tamamı ARP kaydına bakar. Bir belirti daha var ve o bu tabloda hiç görünmez: bir switch portunda birden çok MAC adresi. ip neigh port bilgisi tutmadığı için oradan anlaşılmaz, yalnız switch’in kendi tablosunda görünür ve o portun arkasında çerçeveleri çoğaltan bir cihaz olduğunu söyler. Ne anlama geldiğini ve hangi ihtimallere daraltıldığını yönetilemeyen switch bölümünde ele aldık.

Tabloyu temizlemek gerektiğinde komut her iki tarafta da tek satır.

Windows’ta:

arp -d *
arp -d 192.168.1.25

İlki tablonun tamamını, ikincisi tek bir kaydı siler. İkisi de yönetici hakkı ister; yükseltilmemiş bir kabukta Erişim engellendi alırsınız ve komut sessizce hiçbir şey yapmaz. PowerShell tarafındaki karşılığı Remove-NetNeighbor cmdlet’idir, o da aynı yetkiyi arar.

Linux’ta:

sudo ip neigh flush dev ens33
sudo ip neigh del 192.168.1.25 dev ens33

İlki arayüzün tamamını, ikincisi tek bir kaydı siler.

Ölçtüğümüz turda silinen bir kaydın yeniden kurulması yarım milisaniye sürdü, yani bu işlem pratikte risksizdir. Riskli olan tek durum, elle girilmiş yanlış bir statik kaydın varlığıdır: onu temizlemek düzeltmez, çünkü statik kayıt geri gelir.

Statik kaydın imzası da tam olarak budur: sildikten sonra hâlâ orada olması. Görmek için ayrı bir komut gerekmez, zaten kullandığınız çıktıda yazar. Windows’ta arp -a çıktısındaki tip sütunu dynamic yerine static der, Get-NetNeighbor çıktısında ise durum Permanent görünür. Linux’ta ip neigh satırı REACHABLE ya da STALE yerine PERMANENT ile biter ve flush komutu onu düşürmez.

Kaydı elle yazan komutlar da tek satırdır: Windows’ta arp -s, Linux’ta ip neigh ... nud permanent. Ama bunu kalıcı çözüm olarak kullanmayın. Savunma tablosundaki sınır burada geçerli: elle yazılmış her eşleşme, cihaz değiştiğinde geri dönülüp güncellenmesi gereken bir borçtur ve ölçekte bakımı imkansızdır. Statik kaydın makul kullanımı, bir vakayı teşhis ederken eşleşmeyi geçici olarak sabitlemektir; kalıcı bırakıldığında altı ay sonra kimsenin sebebini hatırlamadığı bir arıza üretir.

ARP burada zincirin en alt halkası olduğu için teşhise de oradan başlanır: bu tablo cevap vermiyorsa, üstündeki hiçbir katmanı kontrol etmenin anlamı yoktur. Adres alamama, isim çözememe, bilet alamama gibi belirtilerde hangi protokolden başlanacağını protokol teşhis sırası tablomuzda bağımlılık sırasına göre dizdik.

Sonuç: Sessiz Protokolün Söyledikleri

ARP, ağınızdaki en sessiz protokoldür. Ayar ekranı yoktur, günlük tutmaz, çalıştığında kimse varlığını fark etmez. Ama bozulduğunda ya da yalan söylendiğinde, üstündeki her katmanı birden götürür.

Bu makalede üç şeyi ölçtük ve üçü de sahada işinize yarayacak:

• Ping susabilir, ARP susmaz. Cevapsız bir ping cihazın kapalı olduğunu kanıtlamaz; ip neigh çıktısı bunu tek satırda ayırır.
• Aynı adres bloğu, aynı yayın alanı demek değildir. İki cihaz aynı /24 içinde görünüp birbirini hiç duymayabilir.
• ARP kimlik sormaz. Gelen ilk cevaba inanır, ve bu bir hata değil tasarımdır. Savunma protokolde değil, ağ cihazında ve şifrelemededir.

Bu üçü birlikte, “ağ bazen yavaşlıyor” ya da “şu sunucuya bazen erişilemiyor” gibi tarif edilmesi zor arızaların büyük kısmını açıklar. Protokol ailesinin geri kalanı ve hangi arızada hangi katmandan başlanacağı ağ protokolleri rehberimizde, adresleme tarafı ise adresleme ve maske rehberimizde duruyor.

Peki bu kadar temel bir şey neden bu kadar az konuşuluyor? Cevap kişisel değil, yapısal. ARP’a bakmamak için dört iyi sebep var ve dördü de protokolün kendi tasarımından geliyor:

• Yapılandırmazsınız. DNS kurarsınız, DHCP ayarlarsınız, güvenlik duvarına kural yazarsınız. ARP’a hiçbir şey yapmazsınız; dolayısıyla varlığını hatırlamanız için bir sebep de doğmaz.
• Hiçbir ekranda görünmez. Panelde sekmesi, arayüzde sayfası, günlükte satırı yoktur. Çalışırken bıraktığı tek iz, bakmayı bilene görünen bir tablodur.
• Kendi belirtisini üretmez. Bozulduğunda “ARP arızası” diye bir hata almazsınız. DHCP’yi ya da DNS’i suçlarsınız, çünkü şikayet eden onlar olur.
• Teşhis alışkanlığı üstten başlar. Herkesin ilk komutu ping, ikincisi traceroute. ip neigh listenin çok aşağısındadır ve çoğu zaman sıra ona hiç gelmez.

Yani ARP bilinmiyor değil, bakılmıyor. Bakmayı gerektiren arıza gelene kadar da buna gerek olmuyor zaten. Ama o arıza geldiğinde ağdaki en sessiz protokol birden en çok konuşan yere dönüşür: ip neigh çıktısındaki tek bir kelime, günlerce yanlış katmanda aranacak bir sorunu tek bakışta yerine oturtur.

Yazan

İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştüren bir ağ ve sistem mühendisidir. Şirketlere özel teknoloji rehberleri burada.