Access switch’ler çoğu kurumda “güvenli” varsayılır: içerideyiz, kullanıcı zaten bizim kullanıcı… Üretimde ise en pahalı küçük sorunların bir kısmı L2 seviyesinde başlar: yanlış DHCP dağıtımı, ARP spoofing ile trafik kaçırma, statik IP taklidi, yanlış VLAN’a düşen cihazlar. Bu yazıda sahada en çok işe yarayan üç guardrail’i birlikte anlatıyorum:
- DHCP Snooping (DHCP’nin kaynağını doğrula + binding tablosu üret)
- Dynamic ARP Inspection (DAI) (ARP paketlerini binding tablosuna göre doğrula)
- IP Source Guard (porttan çıkan IP/MAC’i bağla, sahtekârlığı kısıtla)
Hedef tehdit modeli (sahadaki gerçekler)
Bu üçlü, aşağıdaki sınıf problemleri ciddi ölçüde azaltır:
- Rogue DHCP: Bir kullanıcı laptop’uyla “DHCP server” açar; çevresindeki cihazlar yanlış gateway/DNS alır.
- ARP spoofing / MITM: Aynı VLAN’da bir cihaz “ben gateway’im” diyerek trafiği üstüne alır.
- IP taklidi: Statik IP ile başka bir host’un IP’si kullanılır (özellikle yazıcı/kamera/IoT tarafında).
Bu kontroller, NAC/802.1X’in yerine geçmez. Ama NAC’in olmadığı veya kademeli devreye alındığı ortamlarda bile çok düşük maliyetle blast radius’i küçültür.
Tasarım ilkeleri: önce güvenli varsayılan, sonra istisna
Uygulamada en kritik 3 karar:
- Trusted port sadece DHCP server’a giden uplink/relay tarafı olmalı (access port’ları trusted yapılmaz).
- Kademeli rollout: bir binada / bir access stack’te başlayın; anomali/istisna envanteri çıkarın.
- İz + runbook: “kim kırıldı?” sorusuna 10 dakikada cevap verecek log/komut setiniz olsun.
1) DHCP Snooping’i devreye al: binding tablosunu üret
DHCP Snooping iki şey yapar:
- DHCP mesajlarını izler; server tekliflerinin (OFFER/ACK) nereden geldiğini kontrol eder.
- DHCP’den öğrenilen IP/MAC/port/VLAN eşleşmesini binding olarak tutar.
Nerede açılır?
- VLAN bazında: sadece gerçekten DHCP kullanılan VLAN’larda.
- Access katmanı: kullanıcı/cihazların takıldığı switch’ler.
- Uplink: DHCP server/relay’e giden port(lar) “trusted”.
Operasyonel pre-check
Devreye almadan önce şu üç bilgi net olmalı:
- DHCP server’lar nerede? (VLAN içi mi, merkezi mi?)
- DHCP relay var mı? (IP helper / relay agent)
- Statik IP kullanılan cihazlar listesi var mı? (yazıcı, kamera, PLC, firewall mgmt vb.)
2) DAI: ARP paketini binding’e göre doğrula
DAI’nin gücü şu: ARP “ben şu IP’yim” diyen bir protokol ve doğası gereği sahtekârlığa açık. DAI, ARP paketlerini DHCP Snooping binding tablosuyla karşılaştırır ve uyuşmayanları düşürür.
Hangi VLAN’larda?
- Kullanıcı VLAN’ları ve IoT VLAN’ları: evet
- Sunucu VLAN’ları: duruma göre (çoğu yerde L2 daha az, risk/karmaşa daha yüksek)
- Yönetim VLAN’ı: genelde daha kontrollü; yine de risk/işletme dengesine göre
DAI’yi “sert” açma
Sahada en güvenli açılış sırası:
- DHCP Snooping → binding tablosu oluşsun
- DAI → önce izleme / düşük etkili eşikler
- Statik IP istisnaları → ARP ACL/static binding
- Sonra sıkılaştırma
3) IP Source Guard: porttan çıkan IP/MAC’i kilitle
IP Source Guard, porttan çıkan trafiğin kaynak IP/MAC’ini binding’e bağlar. Bu, “statik IP taklidi” sınıfını ciddi kısıtlar.
Pratikte en çok şu iki kazanım görülür:
- Aynı VLAN’da IP çakışması / taklidi daha hızlı ortaya çıkar
- ARP zehirleme denemeleri daha az başarılı olur (DAI ile birlikte)
Troubleshooting: ‘bir cihaz internete çıkmıyor’ anında ne bakılır?
Üretimde sorun anında hızlı triage için basit bir akış:
- Cihaz DHCP mi almış, statik mi?
- Binding tablosunda IP/MAC/port görünüyor mu?
- DAI drop sayıları artıyor mu?
- Hangi portta drop var? (genelde access port)
Rollout planı: dalga + geri dönüş
Benim sahada en çok işe yarayan rollout modeli:
- Canary: 1 access stack / 1 kat / 1 küçük bina
- İstisna envanteri: statik IP, eski cihazlar, özel DHCP gereksinimleri
- Dalga: her dalgada 2–3 stack (teknik ekip aynı gün geri alabilecek kapasitede kalsın)
- Alarm: DAI drop oranı, DHCP snooping violation, IP source guard violation
- Geri dönüş: VLAN/port bazlı hızlı disable prosedürü
Kapanış: L2 koruma “küçük” değil, incident azaltır
DHCP Snooping + DAI + IP Source Guard; tek başına kurumun tüm güvenliğini çözmez. Ama doğru devreye alındığında iki şeyi birlikte getirir: tahmin edilebilirlik ve kanıt. İçerideki küçük hataların büyük kesintiye dönüşmesini zorlaştırır; incident anında “ne oldu?” sorusunu daha hızlı cevaplamanızı sağlar.