Anti-Spoofing (Magyar)

Manrs végrehajtási útmutató

• Bevezetés
• koordináció
• globális érvényesítés
• anti-Spoofing
• szűrés
• összefoglaló és ellenőrző listák
• további információk

4.3. Anti-Spoofing – Megakadályozza a forgalom hamis forrás IP cím

Releváns MANRS várható műveletek:

• Hálózat üzemeltetője hajtja végre a rendszer, amely lehetővé teszi a forrás cím jóváhagyás legalább egyetlen átköltözik csonk ügyfél hálózatok, saját végfelhasználók, illetve infrastruktúra., A hálózatüzemeltető hamisítás elleni szűrést hajt végre, hogy megakadályozza a helytelen forrás IP-címmel rendelkező csomagok belépését a hálózatból.

IP forrás cím hamisítás az a gyakorlat, származó IP-adatok forráscímek eltérő rendelt a fogadó származási. Egyszerűen fogalmazva, a házigazda úgy tesz, mintha más házigazda lenne. Ezt különféle módon lehet kihasználni, leginkább a szolgáltatásmegtagadás (DoS) reflexióerősítő támadások végrehajtására, amelyek miatt a reflektor gazdagép forgalmat küld a hamis címre.,

számos ajánlás van az IP-hamisítás megakadályozására az ingress szűréssel, például az IP-adatok forráscímeinek ellenőrzése a hálózati él közelében. A legtöbb berendezésgyártó valamilyen formában támogatja az ingress szűrést. 2005 óta az anti-spoofing technikák telepítése nem korlátozta a berendezés teljesítményét. Ez volt a vágy és a hajlandóság korlátozása a hamisítás elleni konfiguráció telepítésére és fenntartására.

ironikus módon a jelentős DoS erősítési támadások drágák lehetnek a szolgáltatók számára., A költségek károsítják a márkát, károsítják az ügyfelek működését, és járulékos működési/költség hatással vannak más ügyfelekre. Ezek a DoS erősítési támadások megelőzhetők. Hamisítás nélkül lehetetlen lenne.

Ez azt mutatja, hogy a behatolási szűrés határozottan nem eléggé telepítve van. Sajnos nincs előnye annak a Szolgáltatónak (SP), amely bevezeti az ingress szűrést. Van egy széles körben elterjedt meggyőződés is, hogy az ingress szűrés csak akkor segít, ha egyetemesen telepítve van.,

a probléma közös megközelítései olyan szoftverfunkciókat érintettek, mint a SAV (forrás – cím érvényesítése) a kábel-modem hálózatokon vagy a szigorú uRPF (unicast Fordított útvonal továbbítása) érvényesítése az útválasztó hálózatokon. Ezek a módszerek megkönnyíthetik az adminisztrációt azokban az esetekben, amikor az útvonalválasztás és a topológia viszonylag dinamikus. Egy másik megközelítés lehet a bejövő előtagszűrő információinak használata egy csomagszűrő létrehozásához, amely csak olyan forrás IP-címekkel rendelkező csomagokat engedélyezne, amelyekhez a hálózat jogosan hirdetheti az elérhetőséget.,

a legtöbb kisebb és egyszerűbb hálózati architektúránál a hamisítás megelőzésének legegyszerűbb módja az Unicast RPF (uRPF) használata szigorú módban. A Layer-2 tartományon használt eszközök által használt forráscímek szűréséhez a forráscím-validációs fejlesztések (SAVI) használhatók. Azon berendezéseken, ahol az automatikus szűrési funkciók nem állnak rendelkezésre, a hozzáférés-vezérlési listák (ACL-ek) segítségével manuálisan végrehajthatja az egyenértékű szűrést. Ezeket a technológiákat az alábbiakban ismertetjük.

4.3.1., Vezérelvei anti-Spoofing architektúrák

, hogy a lehető leghatékonyabb anti-spoofing technikákat kell alkalmazni a lehető legközelebb a forrás. A vállalati hálózatokban az egyes eszközök által használt forráscímeket gyakran ellenőrzik és érvényesítik, így a biztonsági ellenőrzések pontosan meg tudják határozni, hogy melyik eszköz melyik csomagot küldte.

a MANRS sikeres megvalósításához nincs szükség ilyen finom szemcsézettségre az eszköz szintjén, mivel a MANRS a hálózati szintű útválasztás biztonságára és a hamisítás elleni küzdelemre összpontosít., Ezért gyakori anti-spoofing architektúrák összpontosítani ügyelve arra, hogy az ügyfelek nem küld csomagokat a rossz forrás címeket.

az érvényes forráscímek ügyfélszintű használatának érvényesítése azzal az előnnyel jár, hogy az ügyfelek nem tudják hamisítani egymás címeit, ami megakadályozza, hogy problémákat okozzanak egymásnak, amelyeket nehéz hibakeresni.

Ha valamilyen oknál fogva nem lehetséges a forráscím-használat érvényesítése ügyfélenként, akkor alternatíva az összevonási pontokon történő érvényesítése, hogy az ügyfelek legalább korlátozottak legyenek, mely címekben hamisíthatnak., Legalább az internetszolgáltató szintjén anti-spoofingnak kell lennie, hogy az ügyfelek ne hamisítsák meg más szervezetek címeit, és ne okozzanak gondot az Internet egész területén.

4.3.2. Unicast RPF

BCP38 uRPF Szigorú Mód RFC1998++ stílusú multihoming (egy BCP a multihoming) egy olyan módszer, ami működik, a szimmetrikus (egységes átköltözik), az aszimmetrikus (többcímes BGP) konfigurációk, volt az első üzemszerűen alkalmazott 2002-ben. Igen, sokan azt gondolják, hogy “az uRPF nem működik az útválasztási aszimmetria miatt”, de ez nem igaz., Dokumentáció 2001-től, az ISP Essentials whitepaper (Google for version 2.9) és az ISP Essentials book (ISBN 1587050412) valamint telepítések több nagy SPs kimutatták, hogy uRPF szigorú mód egy életképes technika.

négy algoritmusok uRPF – Szigorú Mód (ellenőrizze forrás IP adjacency), Laza Mód (ellenőrizze, csak a forrás IP-címe), Megvalósítható Út (ellenőrizze a forrás IP-címe a FIB alternatívákat), valamint VRF Mód (engedély/tagadom, ellenőrizze a forrás egy külön táblázat a FIB)., Mindegyik uRPF opció a hálózat különböző részein található speciális “hamisítás elleni” funkciókhoz készült.

• uRPF szigorú mód – bcp38 az ügyfél-SP szélén. Minden bejövő csomagot tesztelnek a FIB ellen, ha a bejövő interfész nem a legjobb Fordított útvonal, akkor a csomag leesik.
• uRPF Loose Mode-sRTBH bárhol a hálózaton-de csak ellenőrizze, hogy az útvonal A FIB. Ha nem a FIB-ben, akkor dobja le. Ha a FIB-ben van, akkor adja át. Jó az sRTBH-nak, és enyhít néhány hamis forgalmat a peering szélén.,
• uRPF – sRTBH bárhol a hálózaton, és bcp38 multihomed ügyfelek és aszimmetrikus útvonalak. Megvalósítható módban A FIB alternatív útvonalakat tart fenn egy adott IP-címre. Ha a bejövő felület megegyezik az IP-címhez társított útvonalak bármelyikével, akkor a csomag továbbításra kerül. Ellenkező esetben a csomag leesik.
• uRPF VRF Mode-BGP alapú Peering Policy Enforcement vagy több szemcsés sRTBH (megjegyzés VRF mód lehet használni, mint BCP38, de nem volt operacionálisan bizonyított)

uRPF hasznos lehet sok helyen a hálózatban., Leggyakrabban azon hálózatok szélein használják, ahol az ügyfelek, a szerverek és/vagy az ügyfelek csatlakoznak, mert a szigorú mód ott jól működik. A hálózatüzemeltetők vonakodnak használni az uRPF-et hálózatuk magjában, mert attól tartanak, hogy véletlenül eldobják az érvényes forgalmat, amely váratlan utat tett a hálózatukon keresztül. az uRPF megvalósítható útvonal módnak meg kell oldania az ilyen problémákat.

mind a Cisco, mind a Juniper mind a szigorú módot, mind a laza módot alkalmazza. Megmutatjuk, hogyan kell használni a szigorú módot., Konfigurálja az uRPF szigorú módot az ügyfelekkel szembeni interfészeken:

Cisco:

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

Juniper:

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

Ez biztosítja, hogy az ügyfél csak azokat az IP-címeket használja, amelyeket hozzájuk irányít. Olyan helyzetekben, amikor az ügyfél egy másik ISP, ahol van egy alapértelmezett útvonalat mutat, hogy az INTERNETSZOLGÁLTATÓ kell használni:

Cisco:

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

Boróka:

Boróka router automatikusan alkalmazkodik a uRPF szűrés alapján, ahol bármelyik alapértelmezett útvonal felé mutat. Csak használja ugyanazokat a parancsokat, mint fent.,

az engedélyezés-alapértelmezett opcióra azért van szükség, mert alapértelmezés szerint a forráscímek csak meghatározott útvonalakhoz lesznek illesztve, figyelmen kívül hagyva az alapértelmezett útvonalat. Miközben az alapértelmezett útvonalhoz igazodik, úgy tűnik, hogy ugyanaz, mint bármit engedélyezni, nem az. gondoskodik arról, hogy az upstream ne küldjön olyan forgalmat, amelyre más, specifikusabb útvonalak mutatnak más irányba, például a saját hálózatai és az ügyfelek hálózatai. Ez megvédi Önt a hamis forgalomtól másoktól.

4.3.3., Dynamic Access List (Radius & átmérő)

a RADIUS-hitelesített felhasználók hozzáférési listáinak beállításának szokásos módja a Radius attribútum 11 (Filter-Id). Ezzel az attribútummal megmondhatja az útválasztónak, hogy alkalmazzon egy már meglévő hozzáférési listát a felhasználó kapcsolatához. Ehhez azonban egy sávon kívüli módszerre van szükség ahhoz, hogy az összes útválasztót a megfelelő hozzáférési listákkal biztosítsa.

egyes gyártók extra sugár opciókkal rendelkeznek, amelyek felhasználhatók a hozzáférési lista dinamikus biztosítására a sugáron keresztül., A Cisco például extra funkcionalitást biztosít a cisco-avpair attribútumokon keresztül:

 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"

Ez csak olyan csomagokat engedélyezne az ügyféltől, amelyeknek forráscíme van a 192.0.2.0/24 tartományban.

4.3.4. A SAVI

SAVI az IETF munkacsoport neve, amely a forráscím-érvényesítési fejlesztéseken dolgozik. Az ügyfél forráscímének érvényesítéséhez általában az RFC 7513-ban található SAVI for DHCP megoldást használják., A SAVI ezen verziója nyomon követi az összes IP-címet, amelyet az egyes készülékekhez hozzárendeltek a DHCPv4 és a DHCPv6 üzenetváltások bepillantásával a hálózati kapcsolón, amelyhez az ügyfél csatlakozik. Ha az ügyfél nem engedélyezett forráscímet használ, a kapcsoló eldobja a csomagot.

a gyártók gyakran használják saját terminológiájukat a SAVI funkciók leírására. A Cisco eszközökön ezeket a funkciókat DHCP Snooping, Source Guard és Prefix Guard néven emlegetik.

4.3.5., IP Verify Source

az Ethernet hálózatok sugárzott tartományok, alapértelmezés szerint nincs érvényesítés arról, hogy ki küldhet csomagokat, mely címekkel. A Cisco kapcsolók konfigurálásához a csatlakoztatott eszközök által használt forráscímek ellenőrzésére az” ip verify source ” beállítás használható.,

ennek a funkciónak három változata létezik:
● ip verify source
● ip verify source port-security
● ip verify source tracking port-security

az első változat ellenőrzi a forrás IP-címét, a második változat a forrás MAC-címét és a harmadik változatot is ellenőrzi nyomon követi az IP-cím és a MAC-cím közötti kötéseket. Annak megakadályozása érdekében, hogy az ügyfelek egy másik ügyfél MAC-címét használják, az utolsó változat ajánlott. Ezek mind a DHCP adataira alapozzák döntésüket.,

mielőtt ellenőrizné a forráscímeket, a kapcsolót úgy kell konfigurálni, hogy snoop DHCP forgalmat gyűjtsön, hogy döntéseit a ip dhcp snoopingsegítségével alapozza meg. Annak nyomon követéséhez, hogy melyik ethernet port csatlakozik az egyes DHCP-kliensekhez, használja a DHCP 82 opciót ip dhcp snooping information option. Erre azért van szükség, mert a port-biztonság ellenőrzésével a kapcsoló nem fogja megtanulni a MAC-címeket, amíg a DHCP-kiszolgáló nem rendelt IP-címet a csatlakoztatott eszközhöz. Ezért a 82.lehetőség szükséges ahhoz, hogy emlékeztesse a kapcsolót, ahol az ügyfél csatlakoztatva volt.,

számos lépés szükséges az eszközök biztonságos nyomon követéséhez és a forráscímek ellenőrzéséhez. Az első lépés az “ip eszközkövetés” globális engedélyezése a kapcsolón. Ez biztosítja, hogy a kapcsoló nyomon tudja követni, hogy melyik IP-cím tartozik a MAC-címhez. Ezután minden felületen határozza meg azoknak az eszközöknek a számát, amelyek csatlakozhatnak a ip device tracking maximum num – hoz, ahol a num lehet egy szám 1-től 10-ig. Most engedélyezze a switchport port-security minden felületen annak biztosítása érdekében, hogy csak az engedélyezett MAC-címeket használják., Végül engedélyezze az ellenőrzési funkciót, amely ezeket összekapcsolja a ip verify source tracking port-security.

Most, hogy a kapcsoló be van minden információt meg kell snoop DHCP forgalom, link az IP címek, MAC címek, illetve ellenőrizze, hogy az összes csomagot küldött a kapcsoló megfelel az összegyűjtött állam, amely alapján a válaszok a DHCP-kiszolgálótól. Azok a csomagok, amelyek nem felelnek meg a DHCP-kiszolgáló hozzárendelésének, le lesznek dobva.

4.3.6. Kábelforrás-ellenőrizze

a kábelmodem hálózatok sok szempontból hasonlóak az ethernet hálózatokhoz., Hacsak másképp nincs konfigurálva, a felhasználók hamisíthatják a forráscímeket, vagy ellophatják a kábelhálózat többi felhasználójának címét. A Cisco cable source-verify funkció lehetővé teszi a CMTS operátor számára, hogy korlátozza a felhasználó által használt forráscímeket.

ennek a funkciónak két változata létezik:

● cable source-verify
● cable source-verify dhcp

mindkét változat befolyásolja, hogy a kábelhálózat alhálózatának mely címei használhatók. Az első változat csak megakadályozza, hogy a felhasználók ellopják egymás címét, ezért nem elegendő a MANRS számára., Megnézzük a második változatot.

cable source-verify dhcp azt mondja a CMTS-nek, hogy minden forráscímet ellenőrizni kell a CMTS által látott DHCP lízingekkel szemben. Ha egy csomagot más forrásból küldenek, a CMTS eldobja. Ez megakadályozza a felhasználókat abban, hogy a DHCP-n keresztül hozzájuk nem rendelt címeket használják .

problémák léphetnek fel a CMTS újratöltésekor. Ebben az esetben a CMTS nem ismeri a DHCP összes lízingjét a felhasználóitól, és csökkentheti a törvényes forgalmat. Ennek megoldásához a CMTS konfigurálható a DHCP LeaseQuery protokoll használatára., Ez lehetővé teszi a CMTS számára, hogy kérje a DHCP szervert az általa látott forgalom lízingjeiről. Amint a DHCP-kiszolgáló megerősíti, hogy erre a címre jogos bérleti díj vonatkozik, a CMTS hozzáadja a gyorsítótárhoz, és lehetővé teszi az átmenő forgalmat.

a CMTS konfigurálásához, hogy ne bízzon az ARP-ben a kábelhálózaton, konfigurálja azt no cable arp. Ez biztosítja, hogy csak a DHCP-től és a LeaseQuery-től tanult információk legyenek megbízhatóak a forráscímek ellenőrzésekor.

a cable source-verify funkció csak a kábelhálózat alhálózatát védi., Annak megakadályozása érdekében, hogy a felhasználók más címeket hamisítsanak, valamint hogy lehetővé tegyék az átirányított alhálózattal rendelkező ügyfelek forgalmát, amelyet használhatnak, konfigurálja a ip verify unicast source reachable-via rx az uRPF szigorú mód engedélyezéséhez a kábelhálózaton. Ez ellenőrzi az összes olyan forráscímet, amely nincs közvetlenül a kábelhálózaton, és lehetővé teszi például az ügyfelek felé irányított alhálózatok statikus útvonalainak érvényesítését.

4.3.7., Hozzáférés-Vezérlési Lista (Acl)

Acl-ek gyakran tevékenykedett a Szolgáltató Edge (PE) – Customer Edge (CE) határ, de szintén nagyon hasznos, más helyeken, mint a szolgáltató felé a saját szerver, kliens infrastruktúra-hálózatok hogy megakadályozza a készülékek ott is működött. Az optimalizált ACL stratégia az lenne, ha kifejezett engedélyszűrőt helyezne az ügyfélfelületre. Az Explicit engedélyszűrők bizonyos címtartományokat engedélyeznek, majd minden mást megtagadnak. Például, ha az Üzemeltető ügyfele 192.0.2.0/24-et kap, a BCP 38 ACL lehetővé tenné az összes forráscímet a 192.0.2-től.,0/24 majd tagadja az összes csomagot, amelynek forráscíme nem 192.0.2.0 / 24.

az internetszolgáltató downstream interfészein szűrőknek kell lenniük, amelyek ellenőrzik az ügyfelek által használt forráscímeket. Ha az uRPF nem használható, akkor kézi ACL-ekre van szükség. Vegyük az első ügyfelet a fenti példamutatásból:

Cisco:

Juniper:

4.3.7.1., Aggregációs Pontok

Ha Acl-ek a PE-CE határ nem lehetséges, például azért, mert több fogyasztó csatlakozik egy rétegben-2 hálózati réteg-2 az eszközök nem a funkciók, hogy kiszűrje a layer-3 információkat, majd szűrés egy aggregációs pont a második legjobb megoldás.

ebben a példában (néhány meg nem határozott okból) nem lehet szűrni a /24-et minden ügyfél számára. Ebben az esetben a szűrés 192.0.2.0/23 és 198.51.100.,0/23 (és hasonlóan az IPv6-hoz) az ügyfélkapcsolatokhoz közeli aggregációs ponton legalább az adott ügyfélcsoport számára a hamisítási lehetőségeket kis címtartományra korlátozná.

A konfiguráció ugyanúgy történik, mint az előző szakaszban látható, kivéve, ha most egy másik útválasztón történik, egy központi helyen a hálózatban.

4.3.8. Carrier Grade NAT – a NAT hamisítás elleni eszköz?

alapértelmezés szerint sok NAT implementáció nem szűri az ügyfelek forráscímét., Vegyünk például egy egyszerű Nat konfigurációt egy Cisco routeren, mint például:

 ip nat inside source list INSIDE pool OUTSIDE overload

Ez a NAT szabály lefordítja a csomagokat egy forráscímmel a hozzáférési listában belül, és megváltoztatja a forráscímet egy címre a medencében kívül. Azok a csomagok azonban, amelyek hamis forráscímmel rendelkeznek, amelyek nem szerepelnek a belső hozzáférési listán, fordítás nélkül továbbításra kerülnek, ami hamis csomagokat eredményez az Interneten., Amikor egy hamis csomag egyezik a hozzáférési lista úgy lesz lefordítva, a megadott medence, tehát a külső világ nem egy hamis forrás ip címet, de lehetetlen lesz a NAT-üzemeltető nyomon követni a hamis csomagok vissza, hogy a kezdeményező.

Ez azt mutatja, hogy a NAT nem hamisító eszköz. Még a NAT használatakor is az ügyfelek által használt forráscímeket a lehető legközelebb kell ellenőrizni az ügyfélhez, csakúgy, mint az ebben a fejezetben korábban bemutatott NAT nélküli esetekben. Csak akkor lehet megakadályozni, hogy a hamis és/vagy lenyomozhatatlan csomagok elérjék az internetet.

4.3.9., További olvasmány