Anti-Spoofing (Dansk)

MANRS Gennemførelse Vejledning

• Indledning
• Koordinering
• Globale Validering
• Anti-Spoofing
• Filtrering
• Resumé og tjeklister
• Yderligere oplysninger

4.3. Anti-Spoofing – Forebyggelse af trafik med forfalsket kilde-IP-adresser

der er Relevante MANRS forventede handlinger:

• netværksoperatør implementerer et system, der gør det muligt for kilden til validering af adresser til mindst single-homed stub kundernes netværk, deres egne slutbrugere og infrastruktur., Netværksoperatør implementerer anti-spoofing-filtrering for at forhindre pakker med forkert kilde-IP-adresse i at komme ind og forlade netværket.

IP source address spoofing er praksis med oprindelse IP datagrammer med andre kildeadresser end dem, der er tildelt værten af origin. Enkelt sagt foregiver værten at være en anden vært. Dette kan udnyttes på forskellige måder, især til at udføre denial of Service (DoS) refleksions-amplifikationsangreb, der får en reflektorvært til at sende trafik til den forfalskede adresse.,

Der er mange anbefalinger til at forhindre IP-forfalskning ved at trænge ind i filtrering, f.eks. De fleste udstyrsleverandører understøtter indblæsningsfiltrering i en eller anden form. Siden 2005 har implementering af anti-spoofing teknikker ikke været en begrænsning af udstyrets ydeevne. Det har været en begrænsning af lyst og vilje til at implementere og vedligeholde anti-spoofing konfiguration.ironisk nok kan betydelige DoS-forstærkningsangreb være dyre for tjenesteudbydere., Omkostningerne skader mærket, beskadiger kundeoperationer og har sikkerhedsmæssig/omkostningspåvirkning på andre kunder. Disse dos-forstærkningsangreb kan forebygges. De ville være umulige uden forfalskning.

Dette viser, at indblæsningsfiltrering bestemt ikke er tilstrækkeligt implementeret. Desværre er der ingen fordele for en tjenesteudbyder (SP), der anvender ingress-filtrering. Der er også en udbredt tro på, at ingress-filtrering kun hjælper, når den er universelt implementeret.,

Fælles tilgange til dette problem har involveret software features såsom GEM (Kilde – Adresse Validering) på kabel-modem netværk eller strenge uRPF (unicast-Omvendte-Sti Videresendelse) validering på routeren netværk. Disse metoder kan lette administrationens overhead i tilfælde, hvor routing og topologi er relativt dynamisk. En anden tilgang kunne være at bruge indgående præfiksfilterinformation til at oprette et pakkefilter, hvilket kun tillader pakker med kilde-IP-adresser, som netværket legitimt kunne annoncere tilgængelighed for.,

For de fleste mindre og enklere netværksarkitekturer er den nemmeste måde at forhindre forfalskning ved at bruge Unicast RPF (uRPF) i streng tilstand. Til filtrering af kildeadresser, der bruges af enheder på et layer-2-domæne, kan Source Address Validation Improvements (SAVI) bruges. På udstyr, hvor automatiske filtreringsfunktioner ikke er tilgængelige, kan du bruge Access Control Lists (ACL ‘ er) til manuelt at implementere tilsvarende filtrering. Alle disse teknologier er forklaret nedenfor.

4.3.1., Vejledende Principper for Anti-Spoofing Arkitekturer

At være så effektiv som muligt, anti-spoofing teknikker bør anvendes så tæt på kilden som muligt. I virksomhedsnetværk kontrolleres og håndhæves de kildeadresser, der bruges af hver enhed, ofte, så sikkerhedsrevisioner kan bestemme nøjagtigt, hvilken enhed der sendes hvilken pakke.

for en vellykket implementering af MANRS er en sådan fin granularitet på enhedsniveau ikke nødvendig, da MANRS fokuserer på routingsikkerhed og anti-spoofing på et netværksniveau., Derfor fokuserer almindelige anti-spoofing-arkitekturer på at sikre, at kunder ikke sender pakker med de forkerte kildeadresser.håndhævelse af brugen af gyldige kildeadresser på kundeniveau har den fordel, at kunderne ikke kan forfalske hinandens adresser, hvilket forhindrer dem i at forårsage problemer for hinanden, der er svære at fejlsøge.

Hvis det af en eller anden grund ikke er muligt at håndhæve brug af kildeadresse pr.kunde, er et alternativ at håndhæve det på aggregeringspunkter, så kunderne i det mindste er begrænsede i hvilke adresser de kan forfalske., Som et minimum bør der være anti-spoofing på internetudbyder niveau, så kunderne ikke kan spoof adresser på andre organisationer og forårsage problemer på en Internet-dækkende skala.

4.3.2. Unicast RPF

BCP38 uRPF Strenge med RFC1998++ stil multihoming (en BCP for multihoming) er en strategi, der virker i symmetrisk (enkelt homed) og asymmetrisk (multihomed BGP) konfigurationer, og blev først operationelt udsendt i 2002. Ja, der er mange, der tror, at “uRPF ikke fungerer på grund af routing asymmetri”, men det er ikke sandt., Dokumentation fra 2001, ISP Essentials whitepaper (Google for version 2.9) og ISP Essentials bog (ISBN 1587050412) sammen med installationer i flere større SPs har vist, at uRPF strenge er en holdbar teknik.

Der er fire algoritmer til uRPF – streng tilstand (kontroller kilde-IP og adjacency), løs tilstand (kontroller kun kilde-IP), mulig sti (kontroller kilde-IP med FIB ‘ s alternativer) og VRF-tilstand (Tillad / Afvis kontrol af kilde i en separat tabel fra FIB)., Hver af disse uRPF muligheder er designet til specifikke “anti-spoofing” funktioner i forskellige dele af netværket.

• uRPF streng tilstand – bcp38 på kunden-SP kant. Hver indgående pakke testes mod FIB, og hvis den indgående grænseflade ikke er den bedste omvendte vej, tabes pakken.
• uRPF løs tilstand-sRTBH overalt i netværket-men kun kontrollere, om ruten er i FIB. Hvis ikke i FIB, så slip. Hvis det er i FIB, så pass. God til sRTBH og afbøde nogle misvisende trafik på peering kant.,
• uRPF mulig sti-sRTBH overalt i netværket og BCP38 for multihomed kunder og asymmetriske ruter. I den mulige tilstand opretholder FIB alternative ruter til en given IP-adresse. Hvis den indgående grænseflade matcher med nogen af de ruter, der er knyttet til IP-adressen, videresendes pakken. Ellers er pakken faldet.
• uRPF VRF-Mode – BGP baseret Peering Politik Håndhævelse eller mere detaljeret sRTBH (BEMÆRK VRF-Tilstand kan bruges som BCP38, men er ikke blevet operationelt bevist)

uRPF kan være nyttigt i mange steder i netværket., Det bruges oftest på kanterne på de netværk, hvor kunder, servere og/eller klienter er forbundet, fordi streng tilstand fungerer godt der. Netværksoperatører tøver med at bruge uRPF i kernen i deres netværk på grund af frygt for ved et uheld at tabe gyldig trafik, der har taget en uventet vej gennem deres netværk. uRPF mulig sti-tilstand skal løse sådanne problemer.

både Cisco og Juniper implementerer både streng tilstand og løs tilstand. Vi viser, hvordan man bruger streng tilstand., Konfigurere uRPF Strenge på grænseflader mod kunder med:

Cisco:

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

Enebær:

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

Der vil sørge for at kunden kan kun bruge IP-adresser, som du vej til dem. I situationer, hvor du er kunde hos en anden internetudbyder, hvor du har en standardrute, der peger på den internetudbyder, skal du bruge:

Cisco:

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

Juniper:

Juniper routere tilpasser automatisk deres uRPF-filtrering baseret på, hvor eventuelle standardruter peger mod. Brug bare de samme kommandoer som ovenfor.,

indstillingen Tillad-standard er nødvendig, fordi kildeadresser som standard kun matches mod specifikke ruter, idet standardruten ignoreres. Mens matchende mod standard rute synes at være det samme som at tillade noget som helst, det er det ikke. Det sikrer, at din upstream ikke sende dig trafik, som du har andre mere specifikke ruter, der peger i en anden retning, som dit eget netværk og dine kunders netværk. Dette vil beskytte dig mod falsk trafik fra andre.

4.3.3., Dynamisk adgangsliste (Radius & Diameter)

standardmetoden til at indstille adgangslister for Radius-autentificerede brugere er gennem Radius attribut 11 (Filter-Id). Med denne attribut kan du bede routeren om at anvende en allerede eksisterende adgangsliste til brugerens forbindelse. Dette kræver dog en out-of-band-metode til at give alle routere de korrekte adgangslister.

nogle leverandører har ekstra Radius muligheder, der kan bruges til dynamisk bestemmelse adgangslisten selv gennem Radius., Cisco giver for eksempel ekstra funktionalitet via cisco-avpair-attributter:

 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"

Dette tillader kun pakker fra kunden, der har en kildeadresse i 192.0.2.0/24-området.

4.3.4. SAVI

SAVI er navnet på IETF-arbejdsgruppen, der arbejder med forbedringer af kildeadresse Validering. Til validering af en kundes kildeadresse er SAVI for DHCP-løsningen i RFC 7513 almindeligt anvendt., Denne version af SAVI holder styr på alle de IP-adresser, der er tildelt hver enhed ved at snooping på dhcpv4 og DHCPv6 meddelelsesudvekslinger på netværkskontakten, som kunden er tilsluttet. Hvis en kunde bruger en uautoriseret kilde adresse kontakten vil droppe pakken.

leverandører bruger ofte deres egen terminologi til at beskrive SAVI-funktioner. På Cisco-enheder kaldes disse funktioner DHCP Snooping, Source Guard og Prefi.Guard.

4.3.5., IP Verify Source

Ethernet-netværk udsendes domæner, og som standard er der ingen validering af, hvem der har lov til at sende pakker med hvilke adresser. For at konfigurere Cisco-s .itches til at verificere de kildeadresser, der bruges af de tilsluttede enheder, kan indstillingen “ip verify source” bruges.,

Der er tre varianter af denne funktion:
● ip verify source
● ip verify source port-security
● ip verify source tracking port-security

Den første variant kontrollerer, kilde-IP-adresse, den anden variant er også kontrollerer den kilde, MAC-adresse og den tredje variant spor bindinger mellem IP-adresse og MAC-adresse. For at forhindre kunder i at bruge en anden kundes MAC-adresse anbefales den sidste variant. Alle disse baserer deres beslutning på snooped DHCP-data.,

før du kan verificere kildeadresser, skal kontakten konfigureres til at snuse DHCP-trafik for at indsamle data for at basere sine beslutninger på med ip dhcp snooping. For at holde styr på, hvilken ethernet-port der forbinder til hver DHCP-klient, skal du bruge DHCP option 82 med ip dhcp snooping information option. Dette er nødvendigt, fordi kontakten med verify port-security ikke lærer MAC-adresser, før DHCP-serveren har tildelt en IP-adresse til den tilsluttede enhed. Mulighed 82 er derfor nødvendigt for at minde om kontakten, hvor klienten var tilsluttet.,

Der er flere trin, der er nødvendige for at muliggøre sikker sporing af enheder og verificere deres kildeadresser. Det første trin er at aktivere “ip device tracking” globalt på kontakten. Dette sikrer, at kontakten kan spore, hvilken IP-adresse der hører til hvilken MAC-adresse. Definer derefter antallet af enheder, der har tilladelse til at oprette forbindelse til ip device tracking maximum num, hvor num kan være et tal fra 1 til 10. Aktiver nu switchport port-security på hver grænseflade for at sikre, at kun tilladte MAC-adresser bruges., Og til sidst aktivere verifikationsfunktionen, der forbinder alle disse sammen med ip verify source tracking port-security.

Nu er det skifte har alle de oplysninger, den har brug for at snoop DHCP-trafik, link IP-adresser, MAC-adresser, og kontroller, at alle pakker, der sendes gennem kontakten overensstemmelse med de indsamlede stat, der er baseret på svar fra DHCP-serveren. Pakker, der ikke er i overensstemmelse med, hvad DHCP-serveren har tildelt, vil blive droppet.

4.3.6. Kabel kilde-Bekræft

kabel modem Netværk er på mange måder ligner ethernet-netværk., Medmindre andet er konfigureret, kan brugerne forfalske kildeadresser eller stjæle adresserne på andre brugere på kabelnetværket. Cisco cable source-verify-funktionen gør det muligt for CMTS-operatøren at begrænse, hvilken kilde der adresserer en bruger, der har tilladelse til at bruge.

Der er to varianter af denne funktion:

● cable source-verify
● cable source-verify dhcp

Begge varianter påvirke, hvilke adresser fra kablet netværk subnet er tilladt at blive brugt. Den første variant forhindrer kun brugere i at stjæle hinandens adresser og er derfor ikke tilstrækkelig til MANRS., Vi vil se på den anden variant.

konfigurationcable source-verify dhcp fortæller CMT ‘erne, at alle kildeadresser skal verificeres mod DHCP-lejemål, som CMT’ erne har set. Hvis en pakke sendes med en anden kilde, vil CMT ‘ erne droppe den. Dette forhindrer brugere i at bruge adresser, der ikke er tildelt dem via DHCP .

Der kan opstå problemer, når CMT ‘ erne genindlæses. I et sådant tilfælde vil CMT ‘ erne ikke kende alle DHCP-lejekontrakter fra sine brugere og kan muligvis droppe legitim trafik. For at løse dette kan CMT ‘ erne konfigureres til at bruge DHCP Lease .uery-protokollen., Dette gør det muligt for CMT ‘ erne at spørge DHCP-serveren om lejemål for trafik, den ser. Når DHCP-serveren bekræfter, at der er en legitim lejekontrakt for denne adresse, vil CMTS tilføje den til dens cache og tillade trafikken igennem.

for At konfigurere CMTS til ikke at stole på ARP på kablet netværk, skal du konfigurere det med no cable arp. Dette vil sikre, at kun oplysninger, der er lært fra DHCP og lease .uery, er tillid til, når man verificerer kildeadresser.

cable source-verify funktionen beskytter kun undernet til selve kabelnetværket., For at forhindre brugere i at efterligne andre adresser, og for at tillade trafik fra kunder, der har en dirigeres undernet, som de må bruge, også konfigurere ip verify unicast source reachable-via rx for at aktivere uRPF Strenge på kabel-nettet. Det vil kontrollere alle kildeadresser, der ikke er direkte på kabelnetværket, og tillade Validering mod for eksempel statiske ruter for dirigerede undernet mod kunder.

4.3.7., Access Control List (Acl ‘er)

Acl’ er er almindeligt anvendt på den Udbyder Kant (PE) – Kunde Kant (CE) grænse, men er også meget nyttige i andre steder som i retning af udbyderens egen server, klient og infrastruktur-netværk for at forhindre, at andre enheder der fra, der ikke makker ret. Optimeret ACL-strategi ville være at placere et eksplicit tilladelsesfilter på kundegrænsefladen. Eksplicitte tilladelsesfiltre tillader specifikke adresseområder og nægter derefter alt andet. Hvis operatørens kunde f.eks. tildeles 192.0.2.0/24, tillader BCP 38 ACL alle kildeadresser fra 192.0.2.,0/24 og nægter derefter alle pakker, hvis kildeadresse ikke er 192.0.2.0/24.

på internetudbyderens do .nstream-grænseflader skal der være filtre, der verificerer de kildeadresser, som kunderne bruger. Hvis uRPF ikke kan bruges, er manuelle ACL ‘ er nødvendige. Lad os tage den første kunde fra eksemplet diagram ovenfor:

Cisco:

Juniper:

4.3.7.1., Sammenlægning Points

Når Acl ‘ er på PE-CE-grænse ikke er muligt, eksempelvis fordi flere kunder, der er forbundet til et enkelt lag-2-netværk og lag-2 enheder ikke har de funktioner, der skal filtreres på layer-3-oplysninger, så filtrering ved en sammenlægning punkt er den næstbedste løsning.

i dette eksempel er det (af en eller anden uspecificeret grund) ikke muligt at filtrere på / 24 for hver kunde. I så fald filtrering på 192.0.2.0/23 og 198.51.100.,0/23 (og tilsvarende for IPv6) på et aggregeringssted tæt på kundeforbindelserne ville i det mindste begrænse spoofingmulighederne for denne gruppe af kunder til et lille udvalg af adresser.

konfiguration udføres på samme måde som vist i det foregående afsnit, undtagen nu udføres det på en anden router på en mere central placering i netværket.

4.3.8. Carrier Grade NAT-er NAT en Anti-Spoof værktøj?

som standard filtrerer mange NAT-implementeringer ikke kundernes kildeadresse., Tag for eksempel en simpel NAT-konfiguration på en Cisco-router som:

 ip nat inside source list INSIDE pool OUTSIDE overload

denne NAT-regel oversætter pakker med en kildeadresse i adgangslisten inde og ændrer kildeadressen til en adresse i poolen udenfor. Pakker, der har en forfalsket kildeadresse, der ikke er inkluderet i inside access list, vil dog blive videresendt uden oversættelse, hvilket resulterer i forfalskede pakker på internettet., Når en forfalsket pakke matcher adgangslisten, oversættes den ved hjælp af den specificerede pool, så omverdenen ikke ser en forfalsket kildeadresse, men det vil være umuligt for NAT-operatøren at spore de forfalskede pakker tilbage til deres ophavsmand.

Dette viser, at NAT ikke er et anti-spoofing værktøj. Selv når du bruger NAT, skal de kildeadresser, som kunderne bruger, kontrolleres så tæt på kunden som muligt, ligesom i de tilfælde uden NAT vist tidligere i dette kapitel. Først da kan forfalsket og/eller ikke-sporbare pakker forhindres i at nå Internettet.

4.3.9., Yderligere læsning