Anti-Spoofing

Manrs Implementation Guide

• Inleiding
• coördinatie
• globale validatie
• Anti-Spoofing
• Filtering
• samenvatting en checklists
• aanvullende informatie

4.3. Anti-Spoofing – voorkomen van verkeer met vervalste bron-IP-adressen

relevante MANRS verwachte acties:

• netwerkoperator implementeert een systeem dat bronadresvalidatie mogelijk maakt voor ten minste single-homed stub-klantennetwerken, hun eigen eindgebruikers en infrastructuur., Network operator implementeert anti-spoofing filtering om te voorkomen dat pakketten met een onjuist bron IP-adres het netwerk binnenkomen en verlaten.

IP-bronadres spoofing is de praktijk van oorsprong IP-datagrammen met andere bronadressen dan die welke zijn toegewezen aan de host van oorsprong. In eenvoudige termen, de gastheer doet zich voor als een andere gastheer. Dit kan op verschillende manieren worden benut, met name om Denial of Service (DoS) reflectie-versterking aanvallen uit te voeren die ervoor zorgen dat een reflector host om verkeer naar het vervalste adres te sturen.,

Er zijn veel aanbevelingen om IP-spoofing te voorkomen door filtering binnen te dringen, bijvoorbeeld het controleren van bronadressen van IP-datagrammen dicht bij de netwerkrand. De meeste leveranciers van apparatuur ondersteunen ingress filtering in een bepaalde vorm. Sinds 2005 is de inzet van anti-spoofing technieken geen beperking van de prestaties van de apparatuur. Het is een beperking van de wens en de bereidheid om de anti-spoofing configuratie te implementeren en te onderhouden.

ironisch genoeg kunnen significante DoS-amplificatieaanvallen duur zijn voor serviceproviders., De kosten schaden het merk, schade klant operaties, en hebben collateral operationele / kosten impact op andere klanten. Deze DoS versterkingsaanvallen zijn te voorkomen. Ze zouden onmogelijk zijn zonder spoofing.

Dit toont aan dat binnendringingsfiltering zeker niet voldoende wordt ingezet. Helaas zijn er geen voordelen voor een Service provider (SP) die ingress filtering implementeert. Er is ook een wijdverbreide overtuiging dat het binnendringen van filtering alleen helpt wanneer het universeel wordt ingezet.,

gemeenschappelijke benaderingen van dit probleem hebben betrekking op softwarefuncties zoals SAV (source-Address Validation) op kabelmodemnetwerken of strikte uRPF (unicast Reverse-Path Forwarding) validatie op routernetwerken. Deze methoden kunnen de overhead van administratie in gevallen verlichten waar het routeren en topologie relatief dynamisch is. Een andere aanpak zou kunnen zijn om binnenkomende prefix-filterinformatie te gebruiken om een pakketfilter te maken, waardoor alleen pakketten met bron-IP-adressen worden toegestaan waarvoor het netwerk legitiem reclame kan maken voor bereikbaarheid.,

voor de meeste kleinere en eenvoudigere netwerkarchitecturen is de eenvoudigste manier om spoofing te voorkomen door Unicast RPF (uRPF) in strikte modus te gebruiken. Voor het filteren van bronadressen die worden gebruikt door apparaten op een layer-2-domein kan de Bronadress Validation Improvements (Savi) worden gebruikt. Op apparatuur waar geen automatische filterfuncties beschikbaar zijn, kunt u ACL ‘ s (Access Control Lists) gebruiken om handmatig gelijkwaardige filtering te implementeren. Al deze technologieën worden hieronder uitgelegd.

4.3.1., Leidende beginselen voor Anti-Spoofingarchitecturen

om zo effectief mogelijk te zijn moeten anti-spoofingtechnieken zo dicht mogelijk bij de bron worden toegepast. In bedrijfsnetwerken worden de bronadressen die door elk apparaat worden gebruikt vaak gecontroleerd en afgedwongen, zodat beveiligingsaudits precies kunnen bepalen welk apparaat welk pakket heeft verzonden.

voor een succesvolle implementatie van MANRS is een dergelijke fijnkorreligheid op apparaatniveau niet nodig, aangezien MANRS zich richt op routering van beveiliging en anti-spoofing op netwerkniveau., Daarom richten veelgebruikte anti-spoofingarchitecturen zich op ervoor te zorgen dat klanten geen pakketten verzenden met de verkeerde bronadressen.

het afdwingen van het gebruik van geldige bronadressen op klantniveau heeft het voordeel dat klanten elkaars adressen niet kunnen spoofen, wat voorkomt dat ze problemen voor elkaar veroorzaken die moeilijk te debuggen zijn.

als het om een of andere reden niet mogelijk is om bronadresgebruik per klant af te dwingen, dan is een alternatief om het af te dwingen op aggregatiepunten, zodat klanten ten minste beperkt zijn in welke adressen ze kunnen spoofen., Op zijn minst moet er anti-spoofing zijn op het niveau van de ISP, zodat klanten adressen van andere organisaties niet kunnen spoofen en problemen kunnen veroorzaken op Internet-brede schaal.

4.3.2. Unicast RPF

BCP38 Urpf Strict Mode with rfc1998++ style of multihoming (een BCP voor multihoming) is een benadering die werkt in symmetrische (single homed) en asymmetrische (multihomed BGP) configuraties, en werd voor het eerst operationeel geïmplementeerd in 2002. Ja, er zijn velen die denken dat” uRPF werkt niet vanwege routering asymmetrie”, maar dit is niet waar., Documentatie uit 2001, de ISP Essentials whitepaper (Google voor versie 2.9) en de ISP Essentials book (ISBN 1587050412) samen met implementaties in verschillende grote SPs hebben aangetoond dat uRPF strict mode is een haalbare techniek.

Er zijn vier algoritmen voor uRPF-Strict Mode( controleer bron IP en adjacency), Loose Mode (controleer alleen bron IP), haalbaar pad (controleer bron IP met de alternatieven van de FIB), en VRF Mode (permit/deny check op Bron in een aparte tabel van de FIB)., Elk van deze uRPF opties zijn ontworpen voor specifieke “anti-spoofing” functies in verschillende delen van het netwerk.

• uRPF Strict Mode-BCP38 on the customer-SP edge. Elk inkomend pakket wordt getest tegen de FIB en als de inkomende interface niet het beste omgekeerde pad is, wordt het pakket gedropt.
• uRPF Loose Mode-sRTBH overal in het netwerk – maar controleer alleen of de route in de FIB is. Als het niet in de FIB, dan vallen. Als het in de FIB, dan pas. Goed voor sRTBH en het verminderen van wat vervalste verkeer op de peering edge.,
• uRPF haalbaar pad-sRTBH overal in het netwerk en bcp38 voor multihomed klanten en asymmetrische routes. In de haalbare modus onderhoudt de FIB alternatieve routes naar een bepaald IP-adres. Als de binnenkomende interface overeenkomt met een van de routes die aan het IP-adres zijn gekoppeld, wordt het pakket doorgestuurd. Anders wordt het pakket gedropt.
• uRPF VRF Mode-BGP gebaseerde peering Policy Enforcement of meer gedetailleerde sRTBH (opmerking VRF Mode kan worden gebruikt als BCP38, maar is niet operationeel bewezen)

uRPF kan nuttig zijn op veel plaatsen in het netwerk., Het wordt meestal gebruikt op de randen van de netwerken waar klanten, servers en/of clients zijn verbonden omdat de strikte modus daar goed werkt. Netwerkexploitanten aarzelen om uRPF in de kern van hun netwerken te gebruiken vanwege de angst om per ongeluk geldig verkeer te laten vallen dat een onverwacht pad door hun netwerk heeft genomen. uRPF haalbare Pad modus moet dergelijke problemen op te lossen.

zowel Cisco als Juniper implementeren zowel strict mode als loose mode. We laten zien hoe je strikte modus te gebruiken., Configureer Urpf Strict Mode op interfaces naar klanten met:

Cisco:

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

Juniper:

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

die ervoor zorgt dat de klant alleen IP-adressen kan gebruiken die u naar hen routeert. In situaties waarin u de klant bent van een andere ISP, waar u een standaardroute naar die ISP heeft, moet u het volgende gebruiken:

Cisco:

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

Juniper:

Juniper routers passen hun uRPF-filtering automatisch aan op basis van waar standaardroutes naar wijzen. Gebruik gewoon dezelfde commando ‘ s als hierboven.,

de optie allow-default is noodzakelijk omdat standaard de bronadressen alleen worden vergeleken met specifieke routes, waarbij de standaardroute wordt genegeerd. Het zorgt ervoor dat je upstream geen verkeer verzendt waarvoor je andere meer specifieke routes hebt die in een andere richting wijzen, zoals je eigen netwerken en de netwerken van je klanten. Dit zal u beschermen tegen vervalste verkeer van anderen.

4.3.3., Dynamische toegangslijst (Radius & Diameter)

De standaard manier om toegangslijsten in te stellen voor met Radius geverifieerde gebruikers is via Radius attribuut 11 (Filter-Id). Met dit kenmerk kunt u de router vertellen een reeds bestaande toegangslijst toe te passen op de verbinding van de gebruiker. Dit vereist wel een out-of-band methode om alle routers te voorzien van de juiste toegangslijsten.

sommige leveranciers hebben extra Radius-opties die kunnen worden gebruikt om de toegangslijst zelf dynamisch te verschaffen via Radius., Cisco biedt bijvoorbeeld extra functionaliteit via Cisco-avpair attributen:

 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"

Dit zou alleen pakketten van de klant toestaan die een bronadres hebben in het bereik 192.0.2.0/24.

4.3.4. SAVI

SAVI is de naam van de IETF-werkgroep die werkt aan verbeteringen voor de validatie van bronadressen. Voor de validatie van het bronadres van een klant wordt vaak de SAVI voor DHCP-oplossing in RFC 7513 gebruikt., Deze versie van SAVI houdt alle IP-adressen bij die aan elk apparaat zijn toegewezen door rond te snuffelen op de dhcpv4-en DHCPv6-berichtenuitwisselingen op de netwerkswitch waarmee de klant is verbonden. Als een klant een onbevoegd bronadres gebruikt, zal de switch het pakket laten vallen.

leveranciers gebruiken vaak hun eigen terminologie om SAVI-functies te beschrijven. Op Cisco-apparaten worden deze functies aangeduid als DHCP Snooping, Source Guard en Prefix Guard.

4.3.5., IP Verify Source

Ethernet-netwerken zijn uitzenddomeinen, en standaard is er geen validatie van wie pakketten mag verzenden met welke adressen. Als u Cisco-switches wilt configureren om de bronadressen te verifiëren die door de aangesloten apparaten worden gebruikt, kunt u de instelling” ip verify source ” gebruiken.,

Er zijn drie varianten van deze functie:
● ip verify source
● ip verify source port-security
● ip verify source tracking port-security

de eerste variant verifieert het bron-IP-adres, de tweede variant verifieert ook het bron-MAC-adres en de derde variant volgt de bindingen tussen IP-adres en MAC adres. Om te voorkomen dat klanten het MAC-adres van een andere klant gebruiken, wordt de laatste variant aanbevolen. Al deze baseren hun beslissing op snooped DHCP data.,

voordat u bronadressen kunt verifiëren, moet de switch zodanig zijn geconfigureerd dat DHCP-verkeer wordt doorzocht om gegevens te verzamelen om zijn beslissingen op te baseren met ip dhcp snooping. Gebruik DHCP optie 82 met ip dhcp snooping information optionom bij te houden welke ethernetpoort verbinding maakt met elke DHCP-client. Dit is noodzakelijk omdat de switch met verify port-security geen MAC-adressen zal leren totdat de DHCP-server een IP-adres heeft toegewezen aan het verbonden apparaat. Optie 82 is daarom nodig om de switch te herinneren waar de client was aangesloten.,

Er zijn verschillende stappen nodig om het veilig volgen van apparaten mogelijk te maken en hun bronadressen te verifiëren. De eerste stap is om “ip device tracking” wereldwijd in te schakelen op de switch. Dit zorgt ervoor dat de switch kan bijhouden welk IP-adres behoort tot welk MAC-adres. Definieer vervolgens op elke interface het aantal apparaten dat verbinding mag maken met ip device tracking maximum num waar num een getal van 1 tot 10 kan zijn. Schakel nu switchport port-security in op elke interface om ervoor te zorgen dat alleen toegestane MAC-adressen worden gebruikt., En schakel ten slotte de verificatiefunctie in die deze allemaal koppelt aan ip verify source tracking port-security.

de switch heeft nu alle informatie die hij nodig heeft om DHCP-verkeer te doorzoeken, de IP-adressen aan MAC-adressen te koppelen en te controleren of alle pakketten die via de switch worden verzonden, voldoen aan de verzamelde status die is gebaseerd op reacties van de DHCP-server. Pakketten die niet voldoen aan wat de DHCP-server heeft toegewezen, worden verwijderd.

4.3.6. Kabelbron-verifieer

Kabelmodemnetwerken zijn in veel opzichten vergelijkbaar met ethernet-netwerken., Tenzij anders geconfigureerd, kunnen gebruikers bronadressen spoofen of de adressen van andere gebruikers op het kabelnetwerk stelen. Met de functie Cisco cable source-verify kan de CMTS-operator beperken welke bronadressen een gebruiker mag gebruiken.

er zijn twee varianten van deze functie:

● cable source-verify
● cable source-verify dhcp

beide varianten beïnvloeden welke adressen van het subnet van het kabelnetwerk mogen worden gebruikt. De eerste variant voorkomt alleen dat gebruikers elkaars adressen stelen en is daarom niet voldoende voor MANRS., Wij willen tweede variant beschouwen.

het configureren van cable source-verify dhcp vertelt de CMTS dat alle bronadressen moeten worden geverifieerd aan de hand van DHCP-leases die de CMTS heeft gezien. Als een pakket met een andere bron wordt verzonden, zal de CMTS het laten vallen. Dit voorkomt dat gebruikers adressen gebruiken die niet via DHCP aan hen zijn toegewezen .

problemen kunnen optreden wanneer de CMTS opnieuw wordt geladen. In zo ‘ n geval zullen de CMTS niet alle DHCP-leases van zijn gebruikers kennen en kunnen legitiem verkeer dalen. Om dit op te lossen kunnen de CMTS geconfigureerd worden om het DHCP LeaseQuery protocol te gebruiken., Hierdoor kan de CMTS de DHCP-server vragen naar leases voor verkeer dat hij ziet. Zodra de DHCP-server bevestigt dat er een legitieme lease voor dat adres is, voegt de CMTS het toe aan zijn cache en laat het verkeer door.

om de CMTS zo in te stellen dat ARP op het kabelnetwerk niet vertrouwd, configureer het met no cable arp. Dit zorgt ervoor dat alleen informatie die is geleerd van DHCP en LeaseQuery wordt vertrouwd bij het verifiëren van bronadressen.

de functie cable source-verify beschermt alleen het subnet van het kabelnetwerk zelf., Om te voorkomen dat gebruikers andere adressen spoofen, en om verkeer toe te staan van klanten die een gerouteerd subnet hebben dat ze mogen gebruiken, configureert u ook ip verify unicast source reachable-via rx om uRPF Strict Mode op het kabelnetwerk in te schakelen. Dat controleert alle bronadressen die niet direct op het kabelnetwerk staan en maakt validatie mogelijk tegen bijvoorbeeld statische routes voor routed subnetten naar klanten.

4.3.7., ACL ’s (Access Control List, ACL’ s)

ACL ‘ s worden vaak ingezet op de rand van de Provider Edge (PE) – Customer Edge (CE), maar zijn ook erg handig op andere plaatsen, zoals naar de server -, client-en infrastructuurnetwerken van de provider om te voorkomen dat apparaten zich daar misdragen. Geoptimaliseerde ACL-strategie zou zijn om een expliciet vergunningsfilter op de klantinterface te plaatsen. Expliciete permit filters staan specifieke adresbereiken toe en weigeren dan al het andere. Als de klant van de Operator bijvoorbeeld 192.0.2.0/24 toegewezen krijgt, staat de BCP 38 ACL alle bronadressen van 192.0.2 toe.,0/24 en vervolgens alle pakketten weigeren waarvan het bronadres niet 192.0.2.0/24 is.

op de downstream interfaces van de ISP moeten filters zijn die de bronadressen controleren die door zijn klanten worden gebruikt. Als uRPF niet kan worden gebruikt, zijn handmatige ACL ‘ s noodzakelijk. Laten we de eerste klant uit het voorbeelddiagram hierboven nemen:

Cisco:

Juniper:

4.3.7.1., Aggregatiepunten

wanneer ACL ‘ s op de PE-CE-grens niet mogelijk zijn, bijvoorbeeld omdat meerdere klanten zijn aangesloten op een layer-2-netwerk en de Layer-2-apparaten niet over de mogelijkheden beschikken om op layer-3-informatie te filteren, is filteren op een aggregatiepunt de op één na beste oplossing.

in dit voorbeeld is het (om een onbekende reden) niet mogelijk om voor elke klant op de / 24 te filteren. In dat geval filteren op 192.0.2.0/23 en 198.51.100.,0/23 (en ook voor IPv6) op een verzamelpunt dicht bij de klantverbindingen zou de spoofingmogelijkheden voor die groep klanten ten minste beperken tot een klein aantal adressen.

configuratie wordt gedaan op dezelfde manier als in de vorige sectie, behalve dat het nu wordt gedaan op een andere router op een meer centrale locatie in het netwerk.

4.3.8. Carrier Grade NAT – is NAT een Anti-Spoof Tool?

standaard filteren veel nat-implementaties het bronadres van de clients niet., Neem bijvoorbeeld een eenvoudige NAT-configuratie op een Cisco-router zoals:

 ip nat inside source list INSIDE pool OUTSIDE overload

Deze NAT-regel zal pakketten met een bronadres in de toegangslijst binnen vertalen en het bronadres veranderen naar een adres in de pool buiten. Pakketten die echter een vervalst bronadres hebben dat niet in de inside access lijst is opgenomen, worden zonder enige vertaling doorgestuurd, wat resulteert in vervalste pakketten op het Internet., Wanneer een vervalst pakket overeenkomt met de toegangslijst zal het vertaald worden met behulp van de opgegeven pool, zodat de buitenwereld geen vervalst bronadres ziet, maar het zal onmogelijk zijn voor de nat operator om de vervalste pakketten terug te traceren naar hun originator.

Dit toont aan dat NAT geen anti-spoofing tool is. Ook bij gebruik van NAT moeten de door klanten gebruikte bronadressen zo dicht mogelijk bij de klant worden gecontroleerd, net als in de gevallen zonder NAT die eerder in dit hoofdstuk zijn weergegeven. Alleen dan kunnen vervalste en / of onvindbare pakketten worden voorkomen om het Internet te bereiken.

4.3.9., Extra uitlezing