ARP spoofing, köprülü ağlarda trafiği ele geçirmenin sessiz ama etkili bir yoludur. Ortamımda, Linux köprüleri konteyner ağları ve VM izolasyonu için kullanıldığı için, ARP denetimi ve statik bağlamaları zorunlu kılmak için ebtables'a güveniyorum. Bu, güvenlik duvarlarını değiştirmekle ilgili değil; spoofed ARP yanıtlarının anahtar yığınına ulaşmadan önce bağlantı katmanında düşürülmesini sağlayan bir güvenlik ağı eklemekle ilgili.
Neden ARP koruması için ebtables?
arptables gibi standart araçlar nftables'a karşı kullanımdan kaldırıldıysa da, ebtables hala köprü cihazlarında güvenilir şekilde çalışır. Bir VM veya konteyner Linux köprüsüne bağlandığında, köprü seviyesinde MAC-IP bağlamasını zorunlu kılmadıkça ARP yanıtlarını sahtekarlık yapabilir. Beklenen donanım adresiyle eşleşmeyen gönderen MAC'ine sahip herhangi bir ARP yanıtını düşürmek için ebtables kullanırım.
br0 gibi köprü arayüzlerinde dağıttığım temel kural şu şekildedir:
ebtable -A FORWARD -p ARP --arp-op Reply \
! -s 00:11:22:33:44:55 --arp-ip-src 192.168.10.10 -j DROPBu, 192.168.10.10'dan gelen bir ARP yanıtı MAC adresi 00:11:22:33:44:55 değilse, onu düşür demektir. Köprüdeki her statik IP/MAC çifti için bu kuralı tekrarlamanız gerekir.
Betik ile statik ARP bağlamalarını otomatikleştirme
Her konak için ebtables kurallarını elle eklemek hata yapmaya açıktır. Bunun yerine, güvenilir bir envanterden (genellikle CSV veya DNS dışa aktarımı) bunları üretiyorum. Cron veya systemd zamanlayıcısı üzerinden çalıştırdığım basitleştirilmiş Bash parçacığı şöyle:
#!/bin/bash
BRIDGE="br0"
INVENTORY="/etc/network/hosts.csv" # format: IP,MAC,Hostname
# Üretimde dikkatli olun: ARP ile ilgili mevcut ebtables kurallarını temizle
ebtable -t filter -F FORWARD
while IFS=',' read -r ip mac hostname; do
[[ "$ip" =~ ^# ]] && continue
ebtables -A FORWARD -p ARP --arp-op Reply \
! -s "$mac" --arp-ip-src "$ip" -j DROP
done < "$INVENTORY"Envanterimi Git'te tutuyorum, böylece değişiklikler denetlenebilir. CSV'yi güncelledikten sonra betiği çalıştırıp ebtables -L FORWARD -v ile doğruluyorum.
Konaklarda statik ARP girişleriyle birleştirme
ebtables filtrelemesiyle birlikte, kritik konaklarda statik ARP girişlerini yedek olarak hâlâ ayarlıyorum. Bu, köprüden kaç somehow geçebilecek spoofed yanıtların (örneğin yanlış yapılandırılmış VLANlar nedeniyle) konak tarafından kabul edilmesini önler. Linux'ta:
sudo arp -s 192.168.10.10 00:11:22:33:44:55 -i eth0Kalıcı hale getirmek için, dağıtıma bağlı olarak bunu /etc/network/interfaces veya Netplan yapılandırmasına ekliyorum.
İzleme ve hata ayıklama
Bu kuralları dağıttıktan sonra trafik kesilirse şunları kontrol edin:
- Köprünün gerçekten iletim yapıp yapmadığı (
brctl showmacs br0) - ebtables'in yüklenip yüklenmediği (
lsmod | grep ebtables) - Vurma sayaçlarını görmek için
ebtables -L FORWARD -vkullanın - Geçici olarak düşürmek yerine loglayın:
-j LOG --log-prefix "ARP-SPOOF: "
DHCP-atadaki IP'lerin yanlış pozitif sonuçlara yol açtığı durumlar gördüm; bu yüzden bu yönlendirici, sunucu veya yönetilen VM gibi statik olarak atanmış cihazlar için en iyi sonuç verir. Dinamik uç noktalar için, 802.1X veya port güvenliği gibi alternatifleri değerlendirin.
Son düşünceler
Köprü katmanındaki ARP spoofing korulaması cazip olmayabilir, ama casusluk ve temel MITM girişlerini durduran düşük overhead'lu bir kontrolüdür. ebtables filtrelemesiyle statik bağlamaları ve sürüm kontrolü altında olan envanteri birleştirerek, IDS'mizdeki yanlış alarmları azalttım ve yatay hareketi zorlaştırdım.
[BGP rota sızıntısı koruması](https://furkanikkan.com/urun/bgp-route-leak-korumasi-rpki-ile-trafik-hijacking-i-engellemek-65) hakkındaki önceki yazımda da belirttiğim gibi, savunma derinliği katman 2'den başlar. Üretimde Linux köprüleri yönetiyorsanız, ebtables kurallarını otomatikleştirin — bir ARP zehirleme olayı yaşayıp "keşke yapmış olsaydım" demenin beklentiniz olmasın.
Kapak görseli: Unknown · CC0 (Openverse / kamu malı) · https://www.rawpixel.com/image/6038427/photo-image-public-domain-technology-line