Bu bölüm metnini Türkçeye çevir. Anlam aynı kalsın. İngilizce cümle bırakma.
Kenar ağımızda VLAN trunking için birkaç kamuya açık Linux köprüsü çalıştırıyorum. Son zamanlarda garip DHCP davranışı gözlemledik — istemciler zaman aşımına uğruyor, sunucu günlükleri DISCOVER patlamalarıyla dolduruluyor. Arızalı kablolar ve yanlış yapılandırılmış kapsamlar dışarıda bırakıldıktan sonra, desen klasik bir DHCP açlık saldırısını gösteriyordu: biri, adres havuzunu tüketmek için köprüye sahte MAC adresleriyle trafik dolduruyordu.
Ortamımda köprü kendi başına bir DHCP sunucusu çalıştırmıyor; sadece trafiği geçiriyor. Bu yüzden iptables paketleri görüyor olamaz — çünkü paketler yönlendirilmiyor, köprüleniyor. İşte burada ebtables devreye girer. Katman 2'de çerçeveleri filtrelemek ve hız sınırlamak için kullanılır; tam da ARP ve IPv4 DHCP trafiği için ihtiyacımız olan şey.
br0 üzerinde basit bir hız sınırlaması kurarak, bu floodu legitimate yenilemeleri bozmadan nasıl sınırlayabileceğimi gösteriyorum.
DHCP Koruması için ebtables Neden Kullanılır?
DHCP açlık saldırısı, rastgele chaddr alanlarıyla DISCOVER paketlerini yoğun bir şekilde göndererek çalışır. Her benzersiz MAC adresi, sunucuyu yeni bir kira teklifi vermeye zorlar ve bu da havuzu hızla tüketir. Bu paketler katman 2 yayınları olduğu için, köprü arayüzlerindeki iptables tarafından engellenemez; rahatça geçer. ebtables ise köprü kararı yapılmadan önce çalıştığı için, bu paketleri erken aşamada düşürüp sınırlayabiliriz.
İlk olarak köprüye gelen trafiği kontrol ettim:
watch -n 1 'ebtables -L -v'Çıktı, tek bir porttan saniyede binlerce ARP ve IPv4 çerçevesi geldiğini gösterdi — klasik bir flood imzası.
ARP ve IPv4 Çerçeveleri İçin Hız Sınırlandırma
Tüm çerçeveleri düşürmek yerine (yeniden bağlanma sırasında istemcileri bozabileceği için), bir hız sınırı seçtim: 50 çerçeve patlamasına izin ver, ardından saniyede 10 çerçeveyi sürdür. Bu, DHCP sunucusunun aşırı yüklenmesini önlerken normal işlemi korur.
Ebtables limit eşleşmesi kullanarak iki kural oluşturdum — biri ARP için, diğeri IPv4 için:
ebtables -A FORWARD -p arp --limit 10/sec --limit-burst 50 -j ACCEPT
ebtables -A FORWARD -p arp -j DROP
ebtables -A FORWARD -p IPv4 --limit 10/sec --limit-burst 50 -j ACCEPT
ebtables -A FORWARD -p IPv4 -j DROP--limit ve --limit-burst seçenekleri, iptables ile aynı sözdizimini kullanır. Patlama sonrası, fazlalık çerçeveler sessizce düşürülür.
Kuralları Kalıcı Hale Getirme
Debian/Ubuntu'da, kurallarımı şu şekilde kaydediyorum:
sudo ebtables-save > /etc/ebtables.rulesArdından, br0 için /etc/network/interfaces dosyasına bir geri yükleme satırı ekliyorum:
iface br0 inet manual
bridge_ports eth1 eth2
pre-up ebtables-restore < /etc/ebtables.rulesRHEL/CentOS'ta eşdeğeri, /etc/sysconfig/ebtables dosyasına kaydetmek ve ebtables hizmetini etkinleştirmektir.
Etkiyi İzleme
Kuralları uyguladıktan sonra, sayaçları izledim:
ebtables -L FORWARD -vACCEPT kuralları ~10fps'de sabit trafik gösterirken, DROP kuralları artmaya başladı — bu da flood'un kırpıldığını onayladı. Sunucudaki DHCP DISCOVER logları saniyede binlerce seviyesinden yönetilebilir bir seviyeye düştü ve istemciler tekrar kira almaya başladı.
Sınırlamalar ve Ayarlama İpuçları
Bu bir mükemmel çözüm değildir. Belirli bir saldırgan, düşük hızlı ama yavaş isteklerle havuzu yine de tüketebilir. Bunun için DHCP sunucu tarafı korumaları gerekir, örneğin MAC-adres filtrelemesi veya MAC başına hız sınırlaması (ISC dhcpd, Kea veya Windows Server’da mevcuttur).
Ayrıca, ebtables limit eşleştirmesi bağlantısız durumdadır — yani her MAC için durum takibi yapmaz. Eğer istemci başına sınırlama ihtiyacınız varsa, bunu ebtables + ipset ile birleştirmeyi veya nftables’e geçmeyi düşünebilirsiniz.
Journald hız sınırlamasıyla ilgili önceki gönderimimde de bahsettiğim gibi, burada da aynı patlama/sürdürme ilkesini uygulayabilirsiniz: normal ani artışları emmek, floodu durdurmak.
Bridged ağda DHCP sorunları yaşıyorsanız, önce ebtables sayaçlarını kontrol edin. Hafif, köprü yolunda çalışır ve DHCP sunucusunu dokunmadan işe yarar.
Kapak görseli: Unknown · CC0 (Openverse / kamu malı) · https://www.rawpixel.com/image/6038427/photo-image-public-domain-technology-line