MANRS Implementation Guide
- Introduction
- Coordination
- anti-Spoofing
- Filtering
- Summary and checkists
- Additional information
Global Validation
4.3. Anti- – Huijaus – Estää liikennettä väärentää lähteen IP-osoitteet
Asiaa MANRS odotettavissa toimet:
- Verkko-operaattori toteuttaa järjestelmä, joka mahdollistaa source-address validation vähintään yhden-homed stub asiakkaan verkostojen, oman loppukäyttäjille ja infrastruktuuri., Verkko-operaattori toteuttaa huijauksen estävää suodatusta estääkseen virheellisen lähdekoodin IP-osoitteen sisältävien pakettien pääsyn verkkoon ja poistumisen verkosta.
IP – lähdeosoitteen huijaus on käytäntö, jossa alkuperäosoitteita on muitakin kuin alkuperäosoitteelle osoitettuja LÄHDEOSOITTEITA. Yksinkertaisuudessaan juontaja esittää jotain muuta juontajaa. Tätä voidaan hyödyntää eri tavoin, erityisesti suorittaa Denial of Service (DoS) heijastus-vahvistus hyökkäyksiä, jotka aiheuttavat heijastin isäntä lähettää liikennettä väärennetty osoite.,
on olemassa monia suosituksia IP-huijauksen estämiseksi ingressisuodatuksella, esimerkiksi IP-datagrammien lähdeosoitteiden tarkistaminen lähellä verkon reunaa. Useimmat laitetoimittajat tukevat ingress-suodatusta jossain muodossa. Vuodesta 2005 alkaen huijaustekniikoiden käyttöönotto ei ole rajoittanut laitteiden suorituskykyä. Se on ollut rajoitus halu ja halu ottaa käyttöön ja ylläpitää anti-huijaus kokoonpano.
ironista kyllä, merkittävät DoS-vahvistushyökkäykset voivat olla palveluntuottajille kalliita., Kustannukset vahingoittavat brändiä, vahingoittavat asiakkaiden toimintaa ja niillä on vakuudet toiminta – /kustannusvaikutukset muihin asiakkaisiin. Nämä dos-vahvistushyökkäykset ovat estettävissä. Ne olisivat mahdottomia ilman huijausta.
Tämä osoittaa, että ingressien suodatusta ei todellakaan käytetä riittävästi. Valitettavasti, ei ole mitään hyötyä palveluntarjoaja (SP), joka käyttää ingress suodatus. Yleisesti uskotaan myös, että suodattaminen auttaa vain silloin, kun sitä käytetään yleisesti.,
yleisiä lähestymistapoja tähän ongelmaan ovat olleet ohjelmistoominaisuudet, kuten SAV (Source – Address Validation) kaapelimodeemiverkoissa tai tiukka urpf (unicast Reverse-Path Forwarding) validointi reitittimen verkoissa. Nämä menetelmät voivat helpottaa hallinnon yläpuolella tapauksissa, joissa reititys ja topologia on suhteellisen dynaaminen. Toinen mahdollinen lähestymistapa olisi käyttää saapuvan etuliite suodattaa tietoa luoda paketti-suodatin, joka sallisi vain paketteja lähde-IP-osoitteet, joiden verkosto voi oikeutetusti mainostaa tavoitettavuus.,
useimmissa pienemmissä ja yksinkertaisemmissa verkkoarkkitehtuureissa helpoin tapa estää huijausta on käyttää Unicast RPF: ää (uRPF) tiukassa tilassa. Layer-2-verkkotunnuksen laitteiden käyttämien lähdeosoitteiden suodatuksessa voidaan käyttää Lähdeosoitteen Validointiparannuksia (SAVI). Laitteissa, joissa automaattisia suodatusominaisuuksia ei ole saatavilla, voit käyttää Kulunvalvontaluetteloita (ACLs) vastaavan suodatuksen manuaalisesti toteuttamiseksi. Kaikki nämä teknologiat on selitetty alla.
4.3. 1., Ohjaavat Periaatteet Anti-Huijaus Arkkitehtuurit
olla mahdollisimman tehokas anti- – huijaus tekniikoita olisi sovellettava niin lähelle lähdettä kuin mahdollista. Enterprise Networksissa jokaisen laitteen käyttämiä lähdeosoitteita ohjataan ja valvotaan usein niin, että tietoturvaauditoinnit voivat paikantaa tarkalleen, minkä laitteen lähetit.
onnistuneen täytäntöönpanon MANRS, niin hieno rakeisuus laitteen tasolla ei ole tarpeen, koska MANRS keskittyy reititys turvallisuus ja anti- – huijaus verkon tasolla., Siksi yleiset huijausten estoarkkitehtuurit keskittyvät varmistamaan, että asiakkaat eivät lähetä paketteja, joissa on väärä lähdeosoite.
Valvoa käyttöä voimassa oleva lähde-osoitteet asiakkaan tasolla on se hyöty, että asiakkaat eivät voi huijata toistensa osoitteita, mikä estää heitä aiheuttaa ongelmia toisiaan, että on vaikea debug.
Jos jostain syystä se ei ole mahdollista valvoa lähde-osoitteen käyttö per asiakas, niin vaihtoehto on panna täytäntöön sen yhdistäminen pistettä niin, että asiakkaat ovat vähintään rajoitettu joiden osoitteet he voivat huijaus., Vähintään pitäisi olla anti-huijaus ISP-tasolla, jotta asiakkaat eivät voi huijaus osoitteita muiden organisaatioiden ja aiheuttaa ongelmia Internetin laajuisessa mittakaavassa.
4.3. 2. Unicast RPF
bcp38 uRPF Strict Mode with RFC1998++ style of multihoming (a BCP for multihoming) on lähestymistapa, joka toimii symmetrisissä (single homed) ja epäsymmetrisissä (multihomed BGP) kokoonpanoissa, ja se otettiin käyttöön ensimmäisen kerran operatiivisesti vuonna 2002. Kyllä, on monia, jotka ajattelevat, että ”uRPF ei toimi, koska reititys epäsymmetria”, mutta tämä ei ole totta., Dokumentaatio vuodelta 2001, ISP Essentials whitepaper (Google versio 2.9) ja ISP Essentials book (ISBN 1587050412) sekä käyttöönotto useissa suurissa SPs ovat osoittaneet, että uRPF tiukka tila on kannattava tekniikka.
On olemassa neljä algoritmeja uRPF – tiukka Tila (tarkista lähde-IP ja läheisyytensä), Löysä Tilassa (tarkista vain lähde-IP), Toteuttamiskelpoinen Polku (tarkista lähde-IP kanssa FIB on vaihtoehtoja) ja VRF-Tilassa (sallia/kieltää tarkistaa lähde erillisessä taulukossa FIB)., Jokainen näistä uRPF vaihtoehtoja on suunniteltu erityisiä ”anti-huijaus” toimintoja eri puolilla verkkoa.
- uRPF Strict Mode – Bcp38 on the customer-sp edge. Jokainen saapuva paketti testataan FIB: tä vastaan ja jos saapuva käyttöliittymä ei ole paras kääntöpolku, paketti pudotetaan.
- uRPF Loose Mode – sRTBH missä tahansa verkossa – mutta tarkista vain, jos reitti on FIB. Jos ei FIB, sitten pudota. Jos se on FIB, sitten kulkea. Hyvä sRTBH: lle ja lieventää huijattua liikennettä huipun reunalla.,
- uRPF toteuttamiskelpoinen polku-sRTBH missä tahansa verkossa ja BCP38 multihomed-asiakkaille ja epäsymmetrisille reiteille. TOTEUTTAMISKELPOISESSA tilassa FIB ylläpitää vaihtoehtoisia reittejä tiettyyn IP-osoitteeseen. Jos saapuva käyttöliittymä vastaa mitä tahansa IP-osoitteeseen liittyvää reittiä, paketti lähetetään eteenpäin. Muuten paketti putoaa.
- uRPF VRF Mode – BGP-pohjainen Peering Policy Enforcement tai rakeisempi sRTBH (NOTE VRF Modea voidaan käyttää nimellä BCP38, mutta sitä ei ole toiminnallisesti todistettu)
uRPF voi olla hyödyllinen monissa paikoissa verkossa., Se on useimmiten käytetty reunat verkostoja, joissa asiakkaat, palvelimet ja/tai asiakkaat ovat yhteydessä, koska tiukka Tila toimii hyvin siellä. Verkko-operaattorit empivät uRPF: n käyttöä verkkojensa ytimessä, koska pelkäävät vahingossa pudottavansa kelvollisen liikenteen, joka on kulkenut heidän verkostonsa kautta odottamattoman reitin. uRPF toteuttamiskelpoinen polku tila pitäisi ratkaista tällaisia ongelmia.
sekä Cisco että Juniper toteuttavat sekä tiukan tilan että löysän tilan. Näytämme, miten tiukkaa tilaa käytetään., Määritä uRPF: n tiukka tila rajapinnoilla asiakkaita kohtaan:
Cisco:
ip verify unicast source reachable-via rx ipv6 verify unicast source reachable-via rxKataja:
family inet { rpf-check; } family inet6 { rpf-check; }, että asiakas voi käyttää vain IP-osoitteita, jotka reitität heille. Tilanteissa, joissa olet toisen ISP: n asiakas, jossa sinulla on kyseiseen ISP: hen viittaava oletusreitti, sinun pitäisi käyttää:
Cisco:
ip verify unicast source reachable-via rx allow-default ipv6 verify unicast source reachable-via rx allow-defaultKataja:
Kataja reitittimet mukauttavat uRPF-suodatustaan automaattisesti sen mukaan, mihin tahansa oletusreitteihin suuntautuvat. Käytä samoja komentoja kuin edellä.,
allow-default-vaihtoehto on välttämätön, koska oletusarvoisesti lähdeosoitteet sovitetaan yhteen vain tiettyjä reittejä vastaan jättäen huomiotta oletusreitin. Se varmistaa, että ylävirtasi ei lähetä sinulle liikennettä, jota varten sinulla on muita tarkempia reittejä, jotka osoittavat eri suuntaan, kuten omia verkkoja ja asiakkaiden verkkoja. Tämä suojaa sinua huijatulta liikenteeltä muilta.
4.3. 3., Dynaaminen Liityntäluettelo (säde & halkaisija)
yleinen tapa asettaa liityntäluettelot Radius-todennetuille käyttäjille on Radius-attribuutin 11 (Filter-Id) kautta. Tämän ominaisuuden avulla voit kertoa reitittimelle, että se soveltaa olemassa olevaa liityntälistaa käyttäjän yhteyteen. Tämä edellyttää kuitenkin taajuuskaistan ulkopuolista menetelmää kaikkien reitittimien toimittamiseksi oikeilla liityntälistoilla.
joillakin myyjillä on ylimääräisiä Värttinävaihtoehtoja, joita voidaan dynaamisesti käyttää itse liityntälistan toimittamiseen säteellä., Cisco tarjoaa lisätoimintoja esimerkiksi cisco-avpair-attribuuttien kautta:
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"tämä mahdollistaisi vain asiakkaalta tulevat paketit, joilla on lähdeosoite 192.0.2.0/24-alueella.
4.3. 4. SAVI
SAVI on LÄHDEOSOITTEEN Validointiparannuksia käsittelevän IETF: n työryhmän nimi. Asiakkaan lähdeosoitteen validoinnissa käytetään yleisesti RFC 7513: n DHCP-ratkaisun savia., Tämä versio SAVI pitää kirjaa kaikista IP-osoitteista, jotka on määritetty kunkin laitteen nuuskia DHCPv4-ja DHCPv6-viestin vaihtoa verkon kytkin, että asiakas on liitetty. Jos asiakas käyttää luvatonta lähdeosoitetta, kytkin pudottaa paketin.
myyjät käyttävät usein omaa terminologiaansa Savin piirteiden kuvaamiseen. Ciscon laitteissa näitä ominaisuuksia kutsutaan nimellä DHCP Snooping, Source Guard ja Prefix Guard.
4.3. 5., IP-Varmennuslähde
Ethernet-verkot ovat lähetysalueita, ja oletuksena ei ole varmennusta siitä, kuka saa lähettää paketteja, joissa on mitkä osoitteet. Cisco-kytkinten määrittämiseen liittyneiden laitteiden käyttämien lähdeosoitteiden todentamiseksi voidaan käyttää” ip verify source ” – asetusta.,
tästä ominaisuudesta on olemassa kolme varianttia:
● ip verify source
● ip verify source port-security
● ip verify source tracking port-security
ensimmäinen muunnos tarkistaa lähteen IP-osoitteen, toinen muunnos tarkistaa myös lähteen MAC-osoitteen ja kolmas muunnos seuraa sidontoja IP-osoitteen ja MAC-osoitteen välillä. Jotta asiakkaat eivät käyttäisi toisen asiakkaan MAC-osoitetta, suositellaan viimeistä versiota. Kaikki nämä perustavat päätöksensä snooped DHCP data.,
ennen kuin pystytään todentamaan lähdeosoitteet, kytkin on konfiguroitava snoop DHCP trafficiin keräämään tietoja, jotta sen päätökset voidaan perustaa ip dhcp snooping. Pitääkseen kirjaa siitä, minkä ethernet-portin yhdistää kuhunkin DHCP-asiakkaaseen, käytä DHCP-vaihtoehtoa 82 ip dhcp snooping information option. Tämä on tarpeen, koska varmentamalla port-security kytkin ei opi MAC-osoitteita ennen kuin DHCP-palvelin on antanut IP-osoitteen liitettyyn laitteeseen. Vaihtoehto 82 on näin ollen tarpeen muistuttaa kytkimestä, johon asiakas oli kytketty.,
on olemassa useita toimenpiteitä, jotka mahdollistavat laitteiden turvallisen seurannan ja niiden lähdeosoitteiden tarkistamisen. Ensimmäinen askel on ottaa käyttöön ”ip device tracking” maailmanlaajuisesti kytkimellä. Tämä varmistaa, että kytkin voi seurata, mikä IP-osoite kuuluu mihin MAC-osoitteeseen. Määrittele sitten kussakin käyttöliittymässä niiden laitteiden lukumäärä, jotka saavat muodostaa yhteyden ip device tracking maximum num jossa num voi olla numero 1-10. Ota nyt käyttöön jokaisella käyttöliittymällä varmistaaksesi, että käytössä on vain sallitut MAC-osoitteet., Ja lopuksi ottaa käyttöön todentamisominaisuuden, joka yhdistää nämä kaikki yhdessä ip verify source tracking port-securitykanssa.
Nyt kytkin on kaikki tiedot, joita se tarvitsee snoop DHCP-liikennettä, linkki IP-osoitteet, MAC-osoitteet ja tarkistaa, että kaikki paketit lähetetään kautta kytkin oltava on kerätty valtio, joka perustuu vastauksia DHCP-palvelin. Paketit, jotka eivät vastaa sitä, mitä DHCP-palvelin on määrittänyt, pudotetaan.
4.3. 6. Kaapelilähde-Verify
Kaapelimodeemiverkot muistuttavat monin tavoin ethernet-verkkoja., Ellei toisin ole määritetty, käyttäjät voivat väärentää lähdeosoitteita tai varastaa muiden kaapeliverkossa olevien käyttäjien osoitteet. Cisco cable source-verify-toiminnon avulla CMTS-operaattori voi rajoittaa, mitä lähdeosoitteita käyttäjä saa käyttää.
On olemassa kaksi muunnelmia tästä ominaisuudesta:
● cable source-verify
● cable source-verify dhcp
Molemmat vaihtoehdot vaikuttavat, jossa käsitellään kaapeli verkon aliverkon eivät saa käyttää. Ensimmäinen muunnos vain estää käyttäjiä varastamasta toistensa osoitteita, eikä se näin ollen riitä MANSEILLE., Tarkastelemme toista versiota.
konfigurointi cable source-verify dhcp kertoo CMTS: lle, että kaikki lähdeosoitteet on varmennettava CMTS: n näkemiä DHCP-vuokrasopimuksia vastaan. Jos paketti lähetetään eri lähteestä CMTS pudottaa sen. Tämä estää käyttäjiä käyttämästä osoitteita, joita ei ole osoitettu heille DHCP: n kautta .
CMTS: n uudelleenlastauksessa voi esiintyä ongelmia. Tällaisessa tapauksessa CMTS ei tiedä kaikkia DHCP vuokrasopimuksia käyttäjiltään ja saattaa pudottaa laillista liikennettä. Tämän ratkaisemiseksi CMTS voidaan konfiguroida käyttämään DHCP LeaseQuery-protokollaa., Näin CMTS voi kysyä DHCP-palvelimelta vuokrasopimuksista näkemäänsä liikennettä varten. Kun DHCP-palvelin vahvistaa, että siellä on laillinen vuokrasopimus, että osoite TERMINOINTILAITTEEN lisää sen välimuisti ja mahdollistaa liikenteen läpi.
jotta CMTS ei luottaisi kaapeliverkossa olevaan ARP: hen, määritä se no cable arp. Tämä varmistaa, että vain DHCP: stä ja Leasequerystä opittuihin tietoihin luotetaan lähdeosoitteita tarkistettaessa.
cable source-verify ominaisuus ainoastaan suojaa aliverkon kaapeliverkon itse., Estääkseen käyttäjiä huijaamasta muita osoitteita ja salliakseen liikenteen asiakkailta, joilla on reititetty aliverkosto, jota he saavat käyttää, myös configure ip verify unicast source reachable-via rx mahdollistaa uRPF: n tiukan tilan kaapeliverkossa. Se tarkistaa kaikki lähde-osoitteita, jotka eivät ole suoraan kaapelilla verkkoon ja mahdollistaa validointi vastaan esimerkiksi staattiset reitit reititetään aliverkkoja asiakkaita kohtaan.
4.3. 7., Access Control List (Acl)
Acl ovat yleisesti käytössä Provider Edge (PE) – Customer Edge (CE) – rajan, mutta ovat myös erittäin hyödyllisiä muissa paikoissa, kuten kohti provider on oma palvelin, asiakas ja infrastruktuurin verkostot estää laitteita siellä huonosti. Optimoitu ACL-strategia olisi asettaa nimenomainen lupasuodatin asiakasrajapintaan. Nimenomaiset lupasuodattimet sallivat erityiset osoitealueet ja kieltävät sitten kaiken muun. Jos esimerkiksi operaattorin asiakas jaetaan 192.0.2.0 / 24, BCP 38 ACL sallisi kaikki lähdeosoitteet 192.0.2.alkaen.,0/24 ja sitten kieltää kaikki paketit, joiden lähdeosoite ei ole 192.0.2.0 / 24.
loppupään liitännät ISP, ei pitäisi olla suodattimia, jotka tarkistaa lähde osoitteita käytetään sen asiakkaita. Jos uRPF: ää ei voida käyttää, manuaaliset ACL: t ovat tarpeen. Otetaan ensimmäinen asiakas yllä olevasta esimerkkikaaviosta:
Cisco:
Kataja:
4.3.7.1., Aggregointipisteet
kun ACL: t PE-CE-rajalla eivät ole mahdollisia, esimerkiksi siksi, että useat asiakkaat on liitetty yhteen layer-2-verkkoon ja layer-2-laitteilla ei ole ominaisuuksia suodattaa layer-3-tietoja, niin suodatus aggregointipisteessä on toiseksi paras ratkaisu.
tässä esimerkissä se on (jostain määrittelemätön syy) ei ole mahdollista suodatin /24 jokaiselle asiakkaalle. Tällöin suodatus 192.0.2.0/23 ja 198.51.100.,0/23 (ja vastaavasti IPv6) klo yhdistäminen kohta lähellä asiakasta yhteyksiä olisi ainakin rajoittaa huijaus mahdollisuuksia, että ryhmä asiakkaita, pieni valikoima osoitteita.
kokoonpano tehdään samalla tavalla kuin edellisessä jaksossa, paitsi nyt se tehdään eri reitittimellä verkon keskeisemmässä paikassa.
4.3. 8. Carrier Grade NAT-onko NAT Anti-huijaus työkalu?
oletusarvoisesti monet NAT-toteutukset eivät suodata asiakkaiden lähdeosoitetta., Otetaan esimerkiksi yksinkertainen NAT kokoonpanossa on Cisco reitittimen, kuten:
ip nat inside source list INSIDE pool OUTSIDE overloadTämä NAT-sääntö on kääntää paketit, joiden lähde-osoite access list ALLA ja vaihda lähde-osoite osoite-allas ULKONA. Kuitenkin paketit, jotka on väärennetty lähdeosoite ei ole mukana SISÄLLE pääsy luettelo toimitetaan ilman käännöstä, jolloin väärennetty paketit Internetissä., Kun huijattu paketti vastaa liityntälistaa, se käännetään määritetyllä Poolilla, joten ulkomaailma ei näe huijattua lähdeosoitetta, mutta Nat-operaattorin on mahdotonta jäljittää huijatut paketit takaisin alullepanijaansa.
tämä osoittaa, että NAT ei ole huijaustyökalu. Myös käytettäessä Nat lähdeosoitteet asiakkaiden on tarkastettava mahdollisimman lähellä asiakasta, aivan kuten tapauksissa ilman NAT näkyy aiemmin tässä luvussa. Vain silloin voidaan estää väärennettyjen ja / tai jäljittämättömien pakettien pääsy Internetiin.