Anti-Spoofing (Čeština)

MANRS Provádění Průvodce

• Úvod
• Koordinace
• Globální Validace
• Anti-Spoofing
• Filtrování
• Shrnutí a kontrolní seznamy
• Další informace

4.3. Anti-Spoofing-prevence provozu s falešnými zdrojovými IP adresami

relevantní MANRS očekávané akce:

• síťový operátor implementuje systém, který umožňuje validaci zdrojové adresy alespoň pro sítě zákazníků s jedním domovem, jejich vlastní koncové uživatele a infrastrukturu., Síťový operátor implementuje filtrování proti spoofingu, aby zabránil vstupu a opuštění sítě paketů s nesprávnou zdrojovou IP adresou.

IP source address spoofing je praxe původních IP datagramů se zdrojovými adresami jinými než adresami přiřazenými hostiteli původu. Jednoduše řečeno, hostitel předstírá, že je nějaký jiný hostitel. To lze využít různými způsoby, zejména k provedení útoků odmítnutí služby (DoS) zesílení odrazu, které způsobují, že hostitel reflektoru odesílá provoz na spoofed adresu.,

existuje mnoho doporučení, jak zabránit IP spoofingu filtrováním vniknutí, např. kontrola zdrojových adres IP datagramů v blízkosti okraje sítě. Většina dodavatelů zařízení podporuje filtrování vniknutí v nějaké formě. Od roku 2005 nebylo nasazení technik proti spoofingu omezením výkonu zařízení. Bylo to omezení touhy a ochoty nasadit a udržovat konfiguraci proti spoofingu.

paradoxně mohou být významné útoky zesílení DoS pro poskytovatele služeb drahé., Náklady poškozují značku, poškozují provoz zákazníků a mají vedlejší provozní/nákladový dopad na ostatní zákazníky. Těmto útokům zesílení DoS lze předejít. Bez spoofingu by to nebylo možné.

to ukazuje, že filtrování ingress rozhodně není dostatečně nasazeno. Bohužel neexistují žádné výhody pro poskytovatele služeb (SP), který využívá filtrování ingress. Existuje také široce držené přesvědčení, že filtrování ingress pomáhá pouze tehdy, když je univerzálně nasazeno.,

běžné přístupy k tomuto problému zahrnovaly softwarové funkce, jako je ověření zdrojové adresy v sítích kabelového modemu nebo přísná validace uRPF (Unicast Reverse – Path Forwarding) v sítích routeru. Tyto metody mohou usnadnit režii správy v případech, kdy je směrování a topologie relativně dynamická. Dalším přístupem by mohlo být použití informací o filtrování příchozích prefixů k vytvoření paketového filtru, který by umožnil pouze pakety se zdrojovými IP adresami, pro které by síť mohla legitimně propagovat dosažitelnost.,

pro většinu menších a jednodušších síťových architektur je nejjednodušší způsob, jak zabránit spoofingu, použití Unicast RPF (uRPF) v přísném režimu. Pro filtrování zdrojových adres používaných zařízeními v doméně layer-2 lze použít vylepšení ověření zdrojové adresy (SAVI). Na zařízení, kde nejsou k dispozici funkce automatického filtrování, můžete použít seznamy řízení přístupu (ACLs) k ruční implementaci ekvivalentního filtrování. Všechny tyto technologie jsou vysvětleny níže.

4.3.1., Hlavní zásady pro anti-Spoofing architektury

být co nejúčinnější anti-spoofing techniky by měly být použity co nejblíže ke zdroji, jak je to možné. V podnikových sítích jsou zdrojové adresy používané každým zařízením často kontrolovány a vynucovány, takže bezpečnostní audity mohou přesně určit, které zařízení odeslalo který paket.

Pro úspěšné provádění MANRS, takové jemné granularity na úrovni zařízení není nutné, protože MANRS se zaměřuje na zabezpečení směrování a anti-spoofing na úrovni sítě., Proto se běžné architektury proti spoofingu zaměřují na to, aby zákazníci neposílali pakety se špatnými zdrojovými adresami.

Prosazování používání platný zdroj adres na úrovni zákazníka má tu výhodu, že zákazníci nemohou spoof navzájem adresy, které jim brání způsobuje problémy pro sebe, které jsou těžko k ladění.

Pokud z nějakého důvodu není možné vynutit použití zdrojové adresy na zákazníka, pak je alternativou prosadit ji v agregačních bodech, aby zákazníci byli alespoň omezeni, v jakých adresách mohou podvádět., Minimálně by mělo být na úrovni ISP anti-spoofing, aby zákazníci nemohli spoofovat adresy jiných organizací a způsobovat problémy v celém rozsahu internetu.

4.3.2. Unicast RPF

BCP38 uRPF Strict Mode with rfc1998++ style of multihoming (BCP pro multihoming) je přístup, který funguje v symetrických (single homed) a asymetrických (multihomed BGP) konfiguracích a byl poprvé operativně nasazen v roce 2002. Ano, existuje mnoho lidí, kteří si myslí, že“ uRPF nefunguje kvůli asymetrii směrování“, ale to není pravda., Dokumentace z roku 2001, ISP Essentials whitepaper (Google pro verzi 2.9) a ISP Essentials book (ISBN 1587050412) spolu s nasazením v několika hlavních SPs prokázaly, že uRPF strict mode je životaschopná technika.

k Dispozici jsou čtyři algoritmy pro uRPF – Přísný Režim (kontrola zdrojových IP a přilehlost), Volný Režim (kontrolují pouze zdrojovou IP), Možné Cesty (kontrola zdrojových IP s FIB to alternativy), a VRF Mode (povolit/zakázat podívejte se na zdroj v samostatné tabulce z FIB)., Každá z těchto možností uRPF je určena pro specifické funkce „anti-spoofing“ v různých částech sítě.

• uRPF Strict Mode-BCP38 on the customer – Sp edge. Každý příchozí paket je testován proti FIB a pokud příchozí rozhraní není nejlepší obrácenou cestou, paket je vynechán.
• Urpf Loose Mode-sRTBH kdekoli v síti-ale zkontrolujte pouze, zda je trasa v FIB. Pokud ne v FIB, pak pokles. Pokud je v FIB, pak projděte. Dobré pro sRTBH a zmírnění některých spoofed provozu na hraně peering.,
• uRPF proveditelná cesta-sRTBH kdekoli v síti a BCP38 pro zákazníky s více palci a asymetrické trasy. V proveditelném režimu FIB udržuje alternativní cesty k dané IP adrese. Pokud se příchozí rozhraní shoduje s některou z tras spojených s adresou IP,pak je paket předán. V opačném případě je paket vynechán.
• uRPF VRF Mode-BGP based peering Policy Enforcement nebo zrnitější sRTBH (poznámka režim VRF může být použit jako BCP38, ale není provozně prokázáno)

uRPF může být užitečné na mnoha místech v síti., Nejčastěji se používá na okrajích sítí, kde jsou připojeni zákazníci, servery a/nebo klienti, protože tam funguje přísný režim. Provozovatelé sítí váhají s použitím uRPF v jádru svých sítí kvůli strachu z náhodného poklesu platného provozu, který se jejich sítí vydal nečekanou cestou. uRPF proveditelný způsob cesty by měl tyto problémy vyřešit.

Cisco i Juniper implementují přísný režim i volný režim. Ukážeme, jak používat přísný režim., Konfigurovat uRPF Přísný Režim na rozhraní směrem k zákazníkům s:

Cisco:

 ip verify unicast source reachable-via rx ipv6 verify unicast source reachable-via rx

Jalovec:

 family inet { rpf-check; } family inet6 { rpf-check; }

To bude ujistěte se, že zákazník může používat pouze adresy IP, které vám cestu k nim. V situacích, kdy jste zákazníkem jiného ISP, kde máte výchozí trasu směřující k tomuto ISP, byste měli použít:

Cisco:

 ip verify unicast source reachable-via rx allow-default ipv6 verify unicast source reachable-via rx allow-default

Juniper:

Juniper routery automaticky přizpůsobí filtrování uRPF na základě toho, kam směřují jakékoli výchozí trasy. Stačí použít stejné příkazy jako výše.,

možnost povolit-výchozí je nutná, protože ve výchozím nastavení budou zdrojové adresy porovnány pouze s konkrétními trasami, ignorující výchozí trasu. Při porovnávání proti výchozí trasa se zdá být stejné jako umožnit nic není. To zajišťuje, že vaše upstream nepošle provozu, pro který máte jiné více-konkrétní trasy směřující jiným směrem, jako je vaše vlastní sítě a vašich zákazníků sítě. To vás ochrání před falešným provozem od ostatních.

4.3.3., Dynamický přístupový seznam (poloměr & průměr)

standardní Způsob nastavení přístupových seznamů pro uživatele ověřené poloměrem je pomocí atributu poloměr 11 (filtr-Id). Pomocí tohoto atributu můžete směrovači říct, aby použil již existující seznam přístupu k připojení uživatele. To však vyžaduje metodu out-of-band poskytnout všechny směrovače se správnými seznamy přístupů ačkoli.

někteří prodejci mají další možnosti poloměru, které lze použít k dynamickému poskytování samotného seznamu přístupu prostřednictvím poloměru., Cisco například nabízí další funkce prostřednictvím cisco-avpair atributy:

 cisco-avpair = "ip:inacl#5=permit ip 192.0.2.0 0.0.0.255 any" cisco-avpair = "ip:inacl#99=deny ip any any"

Tento by povolit pouze pakety od zákazníka, které mají zdrojovou adresu v 192.0.2.0/24 rozsah.

4.3.4. SAVI

SAVI je název pracovní skupiny IETF, která pracuje na vylepšení ověření zdrojové adresy. Pro ověření zdrojové adresy zákazníka se běžně používá řešení SAVI pro DHCP v RFC 7513., Tato verze SAVI sleduje všechny IP adresy, které byly přiřazeny ke každému zařízení, snoopingem na zprávách DHCPv4 a DHCPv6 na síťovém přepínači, ke kterému je zákazník připojen. Pokud zákazník použije neautorizovanou zdrojovou adresu, přepínač paket stáhne.

prodejci často používají vlastní terminologii k popisu funkcí SAVI. Na zařízeních Cisco jsou tyto funkce označovány jako DHCP Snooping, Source Guard a Prefix Guard.

4.3.5., IP Verify Source

ethernetové sítě jsou vysílací domény a ve výchozím nastavení neexistuje validace toho, kdo smí odesílat pakety, se kterými adresami. Pro konfiguraci přepínačů Cisco pro ověření zdrojových adres používaných připojenými zařízeními lze použít nastavení „ip verify source“.,

k Dispozici jsou tři varianty této funkce:
● ip verify source
● ip verify source port-security
● ip verify source tracking port-security

první varianta ověřuje, zda zdrojové IP adresy, druhá varianta také ověřuje, zda zdrojové adresy MAC a třetí varianta sleduje vazby mezi IP adresu a MAC adresu. Aby zákazníci nemohli používat MAC adresu jiného zákazníka, doporučuje se poslední varianta. Všechny z nich zakládají své rozhodnutí na snooped DHCP dat.,

než budete moci ověřit zdrojové adresy, musí být přepínač nakonfigurován tak, aby snoop DHCP traffic shromažďoval data, aby svá rozhodnutí založil pomocí ip dhcp snooping. Chcete-li sledovat, který ethernetový port se připojuje ke každému klientovi DHCP, použijte možnost DHCP 82 s ip dhcp snooping information option. To je nezbytné, protože s ověřte, zda port-bezpečnostní spínač nebude učit MAC adresy, dokud DHCP server přidělil IP adresu připojeného zařízení. Možnost 82 je proto nutné připomenout přepínači, kde byl klient připojen.,

existuje několik kroků nezbytných k tomu, aby bylo možné zabezpečit sledování zařízení a ověřit jejich zdrojové adresy. Prvním krokem je globálně povolit „sledování ip zařízení“ na přepínači. To zajišťuje, že přepínač může sledovat, která IP adresa patří ke které MAC adrese. Poté na každém rozhraní definujte počet zařízení, která se mohou připojit pomocí ip device tracking maximum num, kde num může být číslo od 1 do 10. Nyní povolte switchport port-security na každém rozhraní, abyste zajistili, že budou použity pouze povolené MAC adresy., A nakonec povolte funkci ověření, která všechny spojuje s ip verify source tracking port-security.

nyní má přepínač všechny informace, které potřebuje k potlačení provozu DHCP, propojení IP adres s MAC adresami a ověření, že všechny pakety odeslané přepínačem odpovídají shromážděnému stavu, který je založen na odpovědích ze serveru DHCP. Pakety, které neodpovídají tomu, co server DHCP přidělil, budou vynechány.

4.3.6. Zdroj kabelu-ověřte

sítě kabelového modemu jsou v mnoha ohledech podobné sítím ethernet., Pokud není nakonfigurováno jinak, mohou uživatelé podvádět zdrojové adresy nebo ukrást adresy ostatních uživatelů v kabelové síti. Funkce Cisco cable source-verify umožňuje operátorovi CMTS omezit, které zdrojové adresy může uživatel používat.

existují dvě varianty této funkce:

● cable source-verify
● cable source-verify dhcp

obě varianty ovlivňují, které adresy z podsítě kabelové sítě mohou být použity. První varianta pouze brání uživatelům v tom, aby si navzájem kradli adresy, a proto není dostatečná pro MANRS., Podíváme se na druhou variantu.

konfigurace cable source-verify dhcp říká CMTS, že všechny zdrojové adresy musí být ověřeny proti pronájmům DHCP, které CMTS viděly. Pokud je paket odeslán s jiným zdrojem, CMTS jej upustí. To zabrání uživatelům používat adresy, které jim nejsou přiřazeny prostřednictvím DHCP .

problémy mohou nastat při opětovném načtení CMTS. V takovém případě CMTS nebude znát všechny pronájmy DHCP od svých uživatelů a může upustit od legitimního provozu. K vyřešení tohoto problému lze CMTS nakonfigurovat tak, aby používal protokol DHCP LeaseQuery., To umožňuje CMTS požádat server DHCP o pronájem provozu, který vidí. Jakmile server DHCP potvrdí, že existuje legitimní pronájem této adresy, CMTS ji přidá do mezipaměti a umožní provoz.

Chcete-li nakonfigurovat CMTS tak, aby nevěřily ARP v kabelové síti, nakonfigurujte jej pomocí no cable arp. To zajistí, že při ověřování zdrojových adres jsou důvěryhodné pouze informace získané z DHCP a LeaseQuery.

funkcecable source-verify chrání pouze podsíti samotné kabelové sítě., Chcete-li zabránit uživatelům v spoofingu jiných adres a umožnit provoz od zákazníků, kteří mají směrovanou podsíti, kterou mohou používat, nakonfigurujte také ip verify unicast source reachable-via rx pro povolení přísného režimu uRPF v kabelové síti. To zkontroluje všechny zdrojové adresy, které nejsou přímo v kabelové síti, a umožní ověření například statických tras pro směrované podsítě směrem k zákazníkům.

4.3.7., Access Control List (ACLs)

ACLs jsou běžně nasazeny na hranici poskytovatele Edge (PE) – Customer Edge (CE), ale jsou také velmi užitečné na jiných místech, jako je směrem k vlastním serverovým, klientským a infrastrukturním sítím poskytovatele, aby se zabránilo tomu, že se tam zařízení budou chovat špatně. Optimalizovanou strategií ACL by bylo umístit explicitní filtr povolení na rozhraní zákazníka. Filtry s výslovným povolením povolují konkrétní rozsahy adres a pak popírají vše ostatní. Například pokud je zákazníkovi operátora přiděleno 192.0.2.0/24, BCP 38 ACL povolí všechny zdrojové adresy od 192.0.2.,0/24 a pak popřít všechny pakety, jejichž zdrojová adresa není 192.0.2.0 / 24.

na navazujících rozhraních ISP by měly být filtry, které ověřují zdrojové adresy používané jeho zákazníky. Pokud uRPF nelze použít, jsou nutné ruční ACL. Vezměme si prvního zákazníka z výše uvedeného příkladu:

Cisco:

Juniper:

4.3.7.1., Agregace Bodů

Když Acl na PE-CE hranice nejsou možné, například proto, že více zákazníků jsou spojeny do jedné vrstvy-2 sítě a vrstva-2 zařízení nemusí funkce pro filtrování na layer-3 informace, pak filtrování na agregační bod je druhé nejlepší řešení.

v tomto příkladu není (z nějakého nespecifikovaného důvodu) možné filtrovat na /24 pro každého zákazníka. V tomto případě filtrování na 192.0.2.0/23 a 198.51.100.,0/23 (a podobně pro IPv6) v agregačním bodě blízko zákaznických připojení by alespoň omezilo možnosti spoofingu pro tuto skupinu zákazníků na malý rozsah adres.konfigurace

se provádí stejným způsobem, jak je znázorněno v předchozí části, s výjimkou toho, že se nyní provádí na jiném routeru na centrálním místě v síti.

4.3.8. Carrier Grade Nat – je NAT Anti-Spoof nástroj?

ve výchozím nastavení mnoho implementací NAT nefiltruje zdrojovou adresu klientů., Vezměte například jednoduchou konfiguraci NAT na směrovači Cisco jako:

 ip nat inside source list INSIDE pool OUTSIDE overload

toto pravidlo Nat překládá pakety se zdrojovou adresou v seznamu přístupů uvnitř a změní zdrojovou adresu na adresu v bazénu venku. Pakety, které mají spoofed zdrojovou adresu, která není zahrnuta v seznamu vnitřní přístup budou předány bez jakéhokoli překladu, což má za následek spoofed pakety na internetu., Když se podvržený paket shoduje s seznamem přístupů, bude přeložen pomocí zadaného fondu, takže vnější svět nevidí falešnou zdrojovou adresu, ale pro operátora NAT nebude možné vysledovat falešné pakety zpět k jejich původci.

to ukazuje, že NAT není anti-spoofing nástroj. I při použití Nat musí být zdrojové adresy používané zákazníky zkontrolovány co nejblíže zákazníkovi, stejně jako v případech bez NAT uvedených dříve v této kapitole. Teprve pak může být zabráněno spoofed a/nebo nevysledovatelným paketům dostat se na Internet.

4.3.9., Další čtení