Anti-Spoofing (Norsk)

MANRS Implementation Guide

• Innledning
• Koordinering
• Global Validering
• Anti-Spoofing
• Filtrering
• Oppsummering og sjekklister
• Mer informasjon

4.3. Anti-Spoofing – Hindrer trafikken med falske kilde-IP-adresser

Relevant MANRS forventet handlinger:

• nettverksoperatøren implementerer et system som gjør det mulig kilde address validation for minst enkelt-home stub kunden nettverk, sine egne sluttbrukere og infrastruktur., Nettverksoperatøren implementerer anti-spoofing filtrering for å hindre pakker med feil kilde-IP-adresse fra inn og ut av nettverket.

kilde-IP-adresse-imitasjon er den praksisen opprinnelige IP-datagrammer med kilde-postadresser andre enn de som er utpekt til verten av opprinnelse. I enkle termer, vert later til å være noen andre vert. Dette kan utnyttes på ulike måter, først og fremst for å utføre tjenestenektangrep (Denial of Service (DoS) refleksjon-amplifikasjon angrep som forårsaker en reflektor vert å sende trafikk til falske adresse.,

Det er mange anbefalinger for å hindre at IP-spoofing av ingress-filtrering, f.eks. kontroll kilde-adresser til IP-datagrammer nær nettverk kanten. De fleste utstyr leverandører støtte ingress filtrering i noen form. Siden 2005, distribusjon av anti-spoofing teknikker har ikke vært en begrensning av utstyrets ytelse. Det har vært en begrensning av ønske og vilje til å deployere og opprettholde anti-spoofing konfigurasjon.

Ironisk nok, betydelig DoS forsterkning angrep kan bli dyrt for Tjenesteleverandører., Kostnadene skade merkevaren, skade på kundens virksomhet, og har sikkerhet, operative/kostnad innvirkning på andre kunder. Disse DoS forsterkning angrep kan forebygges. De ville være umulig uten imitasjon.

Dette viser at ingress filtrering er definitivt ikke tilstrekkelig implementert. Dessverre er det ingen fordeler til en Service provider (SP) som distribuerer ingress filtrering. Det er også en utbredt oppfatning at ingress filtrering bare hjelper til når det er universelt utplassert.,

Vanlige tilnærminger til dette problemet har involvert programvare funksjoner som SAV (Kilde – Postadresse Validering) på kabel-modem nettverk eller strenge uRPF (unicast Omvendt-Sti Videresending) validering på ruteren nettverk. Disse metodene kan lette belastningen av administrasjonen i tilfeller hvor ruting og topologi er relativt dynamisk. En annen tilnærming kan være å bruke inngående prefiks filtrere informasjon for å opprette en pakkedatatilkobling-filter, noe som bare ville tillate pakker med kilde-IP-adresser for nettverket rettmessig kan annonsere reachability.,

For de fleste mindre og enklere nettarkitekturer den enkleste måten å forhindre forfalsking, er ved hjelp av Unicast-RPF (uRPF) i Streng Modus. For filtrering kilde-adresser som brukes av enheter på et lag-2 domenet Kilde Address Validation Forbedringer (SAVI) kan brukes. På utstyr hvor automatisk filtrering funksjoner er ikke tilgjengelige, kan du bruke Access Control Lists (Acl) for manuelt å gjennomføre tilsvarende filtrering. Alle disse teknologiene er forklart nedenfor.

4.3.1., Veiledende Prinsipper for Anti-Spoofing Arkitekturer

for Å være så effektiv som mulig, anti-spoofing teknikker bør legges så nær kilden som mulig. I enterprise-nettverk, kilde-adresser som brukes av hver enhet er ofte kontrolleres og håndheves slik at sikkerhetsrevisjoner kan fastslå nøyaktig hvilken enhet du sendte som pakke.

For en vellykket gjennomføring av MANRS, så fine detaljer på enhetsnivå er ikke nødvendig så MANRS fokuserer på ruting av sikkerhet og anti-forfalskning på et nettverk nivå., Derfor vanlig anti-spoofing arkitekturer fokus på å sørge for at kundene ikke sende pakker med feil kilde-postadresser.

Håndheve bruk av gyldig kilde for adresser på en kunde nivå har den fordelen at kunder ikke kan imitere hverandres adresser, noe som hindrer dem fra å skape problemer for hverandre som er vanskelige å feilsøke.

Hvis du av en eller annen grunn er det ikke mulig å håndheve kilde adressen bruk per kunde, så et alternativ er å håndheve den på aggregering poeng, slik at du som kunde blir minst begrenset i hvilke adresser de kan etterligne., Som et minimum bør det være anti-spoofing på ISP-nivå, slik at kundene kan ikke etterligne adresser til andre organisasjoner og forårsake problemer på en Internett-bred skala.

4.3.2. Unicast-RPF

BCP38 uRPF Strenge Modus med RFC1998++ stil av multihoming (en BCP for multihoming) er en tilnærming som fungerer i symmetrisk (enkelt home) og asymmetrisk (flernettverksdatamaskin BGP) – konfigurasjoner, og ble først operativt utplassert i 2002. Ja, det er mange som tror at «uRPF ikke fungerer på grunn av ruting asymmetri», men dette er ikke sant., Dokumentasjon fra 2001, ISP Essentials whitepaper (Google for versjon 2.9) og ISP Essentials reserve (ISBN 1587050412) sammen med deployeringer i flere store SPs har vist at uRPF strenge modus er en forsvarlig teknikk.

Det er fire algoritmer for uRPF – Streng-Modus (kontroller kilde-IP-og adjacency), Løs-Modus (kontroller eneste kilde-IP), Mulig Banen (sjekk kilde-IP-med FIB ‘ s alternativer), og VRF-Modus (tillate/nekte sjekk på kilde i en egen tabell fra FIB)., Hver av disse uRPF valg er designet for spesifikke «anti-spoofing» – funksjoner i ulike deler av nettverket.

• uRPF Strenge Modus – BCP38 på kunde-SP kanten. Hver pakke er testet mot FIB og hvis det innkommende grensesnittet er ikke den beste motsatt vei, blir pakken er droppet.
• uRPF Løs Modus – sRTBH hvor som helst i nettverket, men bare sjekk hvis ruten er i FIB. Hvis ikke i FIB, og deretter slippe. Hvis det er i FIB, deretter passere. Bra for sRTBH og behandling av noen falske trafikk på kikket kanten.,
• uRPF Mulig Vei – sRTBH hvor som helst i nettverket, og BCP38 for flernettverksdatamaskin kunder og asymmetrisk ruter. I gjennomførbart modus FIB opprettholder alternative ruter til en gitt IP-adresse. Hvis det innkommende grensesnitt samsvarer med noen av rutene forbundet med IP-adresse, så pakken er videresendt. Ellers pakken er droppet.
• uRPF VRF-Modus – BGP basert Kikket Håndhevelse eller mer detaljert sRTBH (MERK VRF-Modus kan brukes som BCP38, men har ikke vært operativt bevist)

uRPF kan være nyttig i mange steder i nettverket., Det er oftest brukt på kantene av nettverk der kundene er, servere og/eller klienter er koblet fordi Strenge Modus fungerer godt der. Nettverksoperatører er nølende til å bruke uRPF i kjernen av sine nettverk på grunn av frykt for uhell slippe gyldig trafikk som har tatt en uventet vei gjennom sine nettverk. uRPF Mulig Vei-modus bør løse slike problemer.

Både Cisco og Juniper implementere både strenge modus og løs-modus. Vi viser hvordan du bruker strengt modus., Konfigurere uRPF Strenge Modus på grensesnitt mot kunder med:

Cisco:

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

Einer:

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

Som vil sørge for at kunden kan bare bruke IP-adresser som du rute til dem. I situasjoner der du er kunde til en annen ISP, hvor du har en standard rute peker på at internett-LEVERANDØREN du bruker:

Cisco:

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

Einer:

Einer rutere automatisk tilpasse sin uRPF filtrering basert på hvor alle standard ruter peker mot. Det er bare å bruke de samme kommandoene som ovenfor.,

tillat-standard alternativ er nødvendig på grunn av standard kilde-adresser vil bli matchet bare mot bestemte ruter, ignorerer standard rute. Mens matching mot standard rute synes å være den samme som gjør noe, det er det ikke. Det gjør at du oppstrøms sender deg ikke trafikk der du har andre mer spesifikke ruter som peker i en annen retning, for eksempel ditt eget nettverk og dine kunders nettverk. Dette vil beskytte deg mot falske trafikk fra andre.

4.3.3., Dynamisk Tilgang Liste (Radius & Diameter)

Den vanlige måten å angi tilgang lister for Radius-godkjente brukere er gjennom Radius attributt 11 (Filter-Id). Med denne egenskapen kan du fortelle ruteren for å bruke en eksisterende access-liste til brukerens tilkobling. Dette krever en out-of-band metode til bestemmelse alle rutere med riktig tilgang lister om.

Noen leverandører har ekstra Radius alternativer som kan brukes til dynamisk bestemmelse tilgang liste seg gjennom Radius., Cisco for eksempel gir ekstra funksjonalitet gjennom cisco-avpair egenskaper:

 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 ville bare tillate pakker fra kunden som har en kilde adresse i 192.0.2.0/24 utvalg.

4.3.4. SAVI

SAVI er navnet på IETF arbeidsgruppe som arbeider på Source Address Validation Forbedringer. For validering av kundens kilde adresse, SAVI for DHCP-løsning i RFC 7513 er ofte brukt., Denne versjonen av SAVI holder styr på alle IP-adresser som har blitt tildelt hver enkelt enhet ved snusing på DHCPv4 og DHCPv6 meldingsutvekslinger på nettverket bryter som kunden er koblet til. Hvis en kunde bruker en uautorisert kilde adresse bryteren vil slippe pakken.

Leverandører bruker ofte sin egen terminologi for å beskrive SAVI funksjoner. På Cisco-enheter disse funksjonene er referert til som DHCP-Snusing, Kilde Vakt og Prefiks Vakt.

4.3.5., IP-Kontroller Kilde

Ethernet-nettverk er kringkasting domener, og som standard er det ingen validering av hvem som får lov til å sende pakker med hvilke adresser. For å konfigurere Cisco-svitsjer for å bekrefte kilden-adresser som brukes av enheter som er koblet til «kontrollere ip-kilde» – innstillingen kan brukes.,

Det er tre varianter av denne funksjonen:
● ip verify source
● ip verify source port-security
● ip verify source tracking port-security

Den første varianten bekrefter kilde-IP-adressen, den andre varianten også bekrefter kilde-MAC-adressen, og den tredje variant spor bindingene mellom IP-adresse og MAC-adresse. For å hindre at kunder som bruker en annen kunde finner MAC-adressen til den siste varianten er anbefalt. Alle disse basere sin avgjørelse på søket DHCP-data.,

Før du være i stand til å kontrollere kilden adresser bryteren må være konfigurert til å snoop DHCP-trafikk for å samle inn data å basere sine beslutninger på med ip dhcp snooping. For å holde oversikt over hvilke ethernet-port kobles til hver DHCP-klienten bruker DHCP-alternativet 82 med ip dhcp snooping information option. Dette er nødvendig fordi med kontroller port-sikkerhet bryteren vil ikke lære MAC-adresser til DHCP-serveren som er tilordnet en IP-adresse til den tilkoblede enheten. Alternativet 82 er derfor nødvendig å minne bytte der hvor klienten var koblet til.,

Det er flere tiltak som er nødvendig for å aktivere sikker sporing av enheter og bekrefte deres kilde-postadresser. Det første trinnet er å aktivere «ip-enhet sporing» globalt på bryteren. Dette gjør at bytte kan spore hvilken IP-adresse som tilhører hvilken MAC-adresse. Klikk på hver enkelt grensesnitt, angi antall enheter som er tillatt å koble med ip device tracking maximum num der num kan være et tall fra 1 til 10. Nå aktiver switchport port-security på hvert grensesnitt for å sikre at bare tillatt MAC-adresser som er brukt., Og til slutt aktivere bekreftelse funksjon som kobler alle disse sammen med ip verify source tracking port-security.

Nå bryteren har all den informasjonen det er behov for å snoop DHCP-trafikk, koble IP-adresser og MAC-adresser, og kontroller at alle pakker som sendes via bryteren i samsvar samlet stat som er basert på svar fra DHCP-serveren. Pakker som ikke svarer til hva DHCP-serveren har tildelt vil bli droppet.

4.3.6. Kabel-Kilde-Kontroller

Kabel-modem nettverk er på mange måter ligner til ethernet-nettverk., Med mindre konfigurert på annen måte, brukere kan etterligne kilde adresser eller stjele adressene til andre brukere på kabel-nettverk. Cisco kabel-kilde-kontroller funksjonen lar CMTS operatør til å begrense hvilken kilde-postadresser en bruker har lov til å bruke.

Det er to varianter av denne funksjonen:

● cable source-verify
● cable source-verify dhcp

Begge varianter påvirke hvilke adresser fra kabel-nettverket er subnettet er lov til å bli brukt. Den første varianten bare hindrer brukere fra å stjele hverandres adresser, og er derfor ikke tilstrekkelig for MANRS., Vi vil se på den andre varianten.

Konfigurere cable source-verify dhcp forteller CMTS at alle kilde-adresser må være verifisert mot DHCP-leier at CMTS har sett. Hvis en pakke er sendt med en annen kilde CMTS vil slippe det. Dette vil hindre brukere fra å bruke adresser som ikke er tilordnet til dem via DHCP .

det kan oppstå Problemer når CMTS er lastet inn på nytt. I et slikt tilfelle CMTS ikke kjenner alle DHCP-leier fra sine brukere og kan slippe legitim trafikk. For å løse dette CMTS kan være konfigurert til å bruke DHCP-LeaseQuery protokollen., Dette gjør at CMTS å spørre DHCP-serveren om leieavtaler for trafikk det er å se. Når DHCP-server bekrefter at det er en legitim leieavtale for at adressen CMTS vil legge den til sin cache og tillate trafikk gjennom.

for Å konfigurere CMTS til å ikke stole på ARP på kabel nettverk konfigurere den med no cable arp. Dette vil sørge for at informasjon kun lært fra DHCP og LeaseQuery er til å stole på når det kontrolleres kilde-postadresser.

cable source-verify har bare beskytter subnet av kabel-nettverket i seg selv., For å hindre brukere fra å etterligne andre adresser, og for å tillate trafikk fra kunder som har et rutet delnett som de får lov til å bruke, også konfigurere ip verify unicast source reachable-via rx for å aktivere uRPF Strengt Modus på kabel-nettverk. Som vil sjekke alle kilde-adresser som ikke er direkte på kabel-nettverk og tillate validering mot for eksempel statiske ruter for rutet delnett mot kunder.

4.3.7., Access Control List (Acl)

Acl-er ofte distribuert på Provider Edge (PE) – Customer Edge (CE) grensen, men er også svært nyttig i andre steder som mot leverandørens egen server, klient og infrastruktur-nettverk for å forhindre at enheter der fra ikke fungerer som den skal. Optimalisert ACL strategi ville være å plassere et eksplisitt tillatelse filter på kundens grensesnitt. Eksplisitt tillatelse filtre tillate bestemt adresse områder og deretter nekte alle andre. For eksempel, hvis Operatøren er kunden er tildelt 192.0.2.0/24, det BCP 38 ACL ville tillate alle kilde-adresser fra 192.0.2.,0/24 og deretter nekte alle pakker som kilde adresse blir ikke 192.0.2.0/24.

På nedstrøms grensesnitt av LEVERANDØREN, skal det være filtre som bekrefte kilden-adresser som brukes av sine kunder. Hvis uRPF kan ikke brukes deretter manuell Acl er nødvendig. La oss ta den første kunden fra eksempel diagrammet ovenfor:

Cisco:

Einer:

4.3.7.1., Aggregering Poeng

Når Acl på PE-CE-grensen er ikke mulig, for eksempel fordi flere kunder er koblet til et enkelt lag-2 nettverket og lag-2 enheter ikke har funksjoner for å filtrere på layer-3 informasjon, så filtrering på en aggregering punkt er den nest beste løsningen.

I dette eksempelet er det (for noen uspesifisert grunn) ikke mulig å filtrere på /24 for hver enkelt kunde. I så fall filtrering på 192.0.2.0/23 og 198.51.100.,0/23 (og tilsvarende for IPv6) på en aggregering punkt nær kunden tilkoblinger ville i det minste begrense spoofing muligheter for at en gruppe av kunder til et lite utvalg av adresser.

Konfigurering er gjort på samme måte som vist i forrige avsnitt, bortsett fra nå det er gjort på en annen ruter i en mer sentral beliggenhet i nettverket.

4.3.8. Carrier-Grade NAT – Er NAT en Anti-Falske Verktøyet?

som standard mange NAT implementeringer ikke filter kilde-adressen til kunder., Ta for eksempel en enkel NAT-konfigurasjon på en Cisco router som:

 ip nat inside source list INSIDE pool OUTSIDE overload

Dette NAT regel vil oversette pakker med en kilde adresse i tilgang liste i og endre kilde-adressen til en adresse i bassenget UTENFOR. Imidlertid, pakker som har et falskt kilde-adresse som ikke er inkludert i den INNE tilgang til listen vil bli videresendt uten noen oversettelse, noe som resulterer i falske pakker på Internett., Når et falskt packet samsvarer med de få tilgang til listen vil det være oversatt ved hjelp av den angitte bassenget, slik at verden utenfor ikke se et falskt kilde-adresse, men det vil være umulig for NAT-operatoren til å spore den falske pakker tilbake til sin opphavsmann.

Dette viser at NAT er ikke en anti-spoofing verktøy. Selv når du bruker NAT kilde-adresser som brukes av kunder som må kontrolleres så nær kunden som mulig, akkurat som i tilfeller uten NAT vist tidligere i dette kapitlet. Bare da kan forfalskede og/eller untraceable pakker bli forhindret til å komme på Internett.

4.3.9., Mer å lese