Anti-Spoofing (Română)

MANRS Ghid de Implementare

• Introducere
• Coordonarea
• Global de Validare
• Anti-Spoofing
• Filtrare
• Rezumat și liste de verificare
• informații Suplimentare

4.3. Anti-Spoofing – Prevenirea traficului cu falsificata sursa adrese IP

Relevante MANRS de așteptat acțiuni:

• operatorul de Rețea pune în aplicare un sistem care permite adresă sursă de validare pentru cel puțin single-relocate stub client rețele, propria lor utilizatorilor finali și a infrastructurii., Operatorul de rețea implementează filtrarea anti-spoofing pentru a împiedica pachetele cu adresa IP sursă incorectă să intre și să părăsească rețeaua.

spoofing adresa sursă IP este practica de origine datagrame IP cu adrese sursă, altele decât cele atribuite gazdă de origine. În termeni simpli, gazda se preface că este o altă gazdă. Acest lucru poate fi exploatat în diverse moduri, mai ales pentru a executa atacuri de amplificare a reflecției Denial of Service (DoS) care determină o gazdă reflector să trimită trafic către adresa falsă.,

există multe recomandări pentru a preveni falsificarea IP prin filtrarea prin infiltrare, de exemplu, verificarea adreselor sursă ale datagramelor IP aproape de marginea rețelei. Majoritatea furnizorilor de echipamente acceptă filtrarea ingress într-o anumită formă. Din 2005, implementarea tehnicilor anti-spoofing nu a fost o limitare a performanței echipamentului. A fost o limitare a dorinței și dorinței de a implementa și menține configurația anti-spoofing.în mod ironic, atacurile semnificative de amplificare DoS pot fi costisitoare pentru furnizorii de servicii., Costurile afectează marca, dăunează operațiunilor clienților și au un impact operațional/cost colateral asupra altor clienți. Aceste atacuri de amplificare DoS pot fi prevenite. Ar fi imposibil fără falsificare.acest lucru demonstrează că filtrarea ingress nu este cu siguranță suficient de implementată. Din păcate, nu există beneficii pentru un furnizor de servicii (SP) care implementează filtrarea ingress. Există, de asemenea, o convingere larg răspândită că filtrarea ingress ajută doar atunci când este implementată universal.,abordările comune ale acestei probleme au implicat caracteristici software, cum ar fi Sav (validarea adresei sursă) în rețelele de modem – cablu sau validarea strictă a uRPF (unicast Reverse-Path Forwarding) în rețelele de router. Aceste metode pot ușura cheltuielile generale de administrare în cazurile în care rutarea și topologia sunt relativ dinamice. O altă abordare ar putea fi utilizarea informațiilor despre filtrul prefix de intrare pentru a crea un filtru de pachete, care ar permite doar pachete cu adrese IP sursă pentru care rețeaua ar putea face publicitate legitimă accesibilitate.,pentru majoritatea arhitecturilor de rețea mai mici și mai simple, cel mai simplu mod de a preveni spoofing-ul este folosind Unicast RPF (uRPF) în modul Strict. Pentru filtrarea adreselor sursă utilizate de dispozitive pe un domeniu layer-2 pot fi utilizate îmbunătățiri de validare a adreselor sursă (SAVI). Pe echipamentele în care funcțiile de filtrare automată nu sunt disponibile, puteți utiliza listele de control al accesului (ACL) pentru a implementa manual filtrarea echivalentă. Toate aceste tehnologii sunt explicate mai jos.

4. 3.1., Principiile directoare pentru arhitecturile Anti-Spoofing

pentru a fi cât mai eficiente posibil tehnicile anti-spoofing ar trebui aplicate cât mai aproape de sursă. În rețelele de întreprinderi, adresele sursă utilizate de fiecare dispozitiv sunt adesea controlate și aplicate, astfel încât auditurile de securitate să poată indica exact ce dispozitiv a trimis ce pachet.pentru o implementare cu succes a MANRS, o astfel de granularitate fină la nivelul dispozitivului nu este necesară, deoarece MANRS se concentrează pe securitatea rutării și anti-spoofing la nivel de rețea., Prin urmare, arhitecturile comune anti-spoofing se concentrează pe asigurarea faptului că clienții nu trimit pachete cu adrese sursă greșite.

aplicarea utilizării adreselor sursă valide la nivel de client are avantajul că clienții nu își pot falsifica reciproc adresele, ceea ce îi împiedică să creeze probleme unul pentru celălalt, care sunt greu de depanat.dacă dintr-un anumit motiv nu este posibilă aplicarea utilizării adresei sursă pentru fiecare client, atunci o alternativă este aplicarea acesteia la punctele de agregare, astfel încât clienții să fie cel puțin limitați la adresele pe care le pot falsifica., Cel puțin ar trebui să existe anti-spoofing la nivelul ISP, astfel încât clienții să nu poată falsifica adresele altor organizații și să provoace probleme la scară largă pe Internet.

4. 3.2. Unicast RPF

BCP38 uRPF Modul Strict cu RFC1998++ stil de multihoming (PTF pentru multihoming) este o abordare care funcționează în simetric (single relocate) și asimetrice (multilocalizate BGP), configurații, și a fost primul din punct de vedere operațional implementat în anul 2002. Da, sunt mulți care cred că „uRPF nu funcționează din cauza asimetriei de rutare”, dar acest lucru nu este adevărat., Documentația din 2001, ISP Essentials documentație (Google pentru versiunea 2.9) și ISP Essentials carte (ISBN 1587050412), împreună cu implementări în mai multe SPs au demonstrat că uRPF modul strict este o tehnică viabilă.există patru algoritmi pentru modul Urpf-Strict (verificați IP-ul sursei și adiacența), modul Loose (verificați numai IP-ul sursei), calea fezabilă (verificați IP-ul sursei cu alternativele FIB) și modul VRF (permiteți/refuzați verificarea sursei într-un tabel separat de FIB)., Fiecare dintre aceste opțiuni uRPF este concepută pentru funcții specifice „anti-spoofing” în diferite părți ale rețelei.modul Strict uRPF-BCP38 pe marginea clientului-SP. Fiecare pachet de intrare este testat împotriva FIB și dacă interfața de intrare nu este cea mai bună cale inversă, pachetul este abandonat.

uRPF Loose Mode-sRTBH oriunde în rețea-dar verificați numai dacă ruta este în FIB. Dacă nu în FIB, apoi picătură. Dacă este în FIB, atunci treceți. Bun pentru sRTBH și atenuarea unor trafic falsificat pe marginea peering.,

uRPF cale fezabilă-sRTBH oriunde în rețea și BCP38 pentru clienții multihomed și rute asimetrice. În modul fezabil FIB menține rute alternative la o anumită adresă IP. Dacă interfața de intrare se potrivește cu oricare dintre rutele asociate adresei IP, atunci pachetul este redirecționat. În caz contrar, pachetul este abandonat.

uRPF VRF Mode – aplicarea politicii de Peering bazată pe BGP sau sRTBH mai granular (notă modul VRF ar putea fi utilizat ca BCP38, dar nu a fost dovedit operațional)

uRPF poate fi util în multe locuri din rețea., Este cel mai adesea folosit pe marginile rețelelor în care clienții, serverele și/sau clienții sunt conectați, deoarece modul Strict funcționează bine acolo. Operatorii de rețea ezită să folosească uRPF în nucleul rețelelor lor din cauza fricii de a renunța accidental la traficul valid care a luat o cale neașteptată prin rețeaua lor. modul de cale fezabilă uRPF ar trebui să rezolve astfel de probleme.atât Cisco, cât și Juniper implementează atât modul strict, cât și modul liber. Arătăm cum să folosim modul strict., Configurați uRPF Modul Strict pe interfețe față de clienți cu:

Cisco:

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

Ienupăr:

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

Care va asigurați-vă că clientul poate folosi doar adresele IP care faci traseul de la ei. În situațiile în care sunteți clientul un alt ISP-ul în cazul în care aveți un traseu prestabilit, arătând că ISP-ul ar trebui să utilizați:

Cisco:

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

Ienupăr:

routere Juniper adapta automat lor uRPF de filtrare pe baza de unde orice default rute sunt orientate spre. Utilizați aceleași comenzi ca mai sus.,

opțiunea allow-default este necesară deoarece în mod implicit adresele sursă vor fi potrivite numai pe anumite rute, ignorând ruta implicită. În timp ce se potrivesc împotriva ruta implicită pare a fi la fel ca permite nimic, nu este. Se face sigur că în amonte nu trimite trafic pentru care ai altele mai specifice rute îndreptat într-o direcție diferită, cum ar fi propriile rețele și clienților dumneavoastră rețele. Acest lucru vă va proteja împotriva traficului falsificat de la alții.

4. 3.3., Dynamic Access List (Radius & Diameter)

modul standard de a seta listele de acces pentru utilizatorii autentificați în Radius este prin atributul Radius 11 (Filter-Id). Cu acest atribut puteți spune routerului să aplice o listă de acces preexistentă la conexiunea utilizatorului. Acest lucru necesită o metodă în afara benzii pentru a furniza toate routerele cu listele de acces corecte.unii furnizori au opțiuni suplimentare de rază care pot fi utilizate pentru a furniza dinamic lista de acces în sine prin Radius., Cisco, de exemplu, oferă funcționalități suplimentare prin cisco-avpair atribute:

 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"

Acest lucru ar permite doar pachetelor de la client, care au o adresă sursă în 192.0.2.0/24 de gama.

4. 3.4. SAVI

SAVI este numele grupului de lucru IETF care lucrează la îmbunătățiri de validare a adresei sursă. Pentru validarea adresei sursă a unui client, soluția SAVI pentru DHCP din RFC 7513 este utilizată în mod obișnuit., Această versiune de SAVI ține evidența tuturor adreselor IP care au fost atribuite fiecărui dispozitiv prin snooping pe schimburile de mesaje DHCPv4 și DHCPv6 pe comutatorul de rețea la care Clientul este conectat. Dacă un client folosește o adresă sursă neautorizată, comutatorul va renunța la pachet.

vânzătorii folosesc adesea propria terminologie pentru a descrie caracteristicile SAVI. Pe dispozitivele Cisco, aceste caracteristici sunt denumite DHCP Snooping, Source Guard și Prefix Guard.

4. 3.5., Rețelele Ethernet sunt domenii de difuzare și, în mod implicit, nu există nicio validare a cine are voie să trimită pachete cu ce adrese. Pentru a configura comutatoarele Cisco pentru a verifica adresele sursă utilizate de dispozitivele conectate, se poate utiliza setarea „IP verify source”.,

Există trei variante ale acestui element de:
● ip verify source
● ip verify source port-security
● ip verify source tracking port-security

prima varianta verifică adresa IP a sursei, cea de-a doua variantă, de asemenea, verifică dacă adresa MAC sursă și cea de-a treia variantă piese legăturile între adresa IP și adresa MAC. Pentru a împiedica clienții să utilizeze adresa MAC a altui client, se recomandă ultima variantă. Toate acestea își bazează decizia pe datele DHCP snooped.,

înainte de a putea verifica adresele sursă, comutatorul trebuie să fie configurat să spioneze traficul DHCP pentru a colecta date pe care să își bazeze deciziile cu ip dhcp snooping. Pentru a urmări ce port ethernet se conectează la fiecare client DHCP, utilizați opțiunea DHCP 82 cu ip dhcp snooping information option. Acest lucru este necesar deoarece, cu verify port-security, comutatorul nu va învăța adresele MAC până când serverul DHCP nu a atribuit o adresă IP dispozitivului conectat. Prin urmare, opțiunea 82 este necesară pentru a reaminti comutatorului unde a fost conectat clientul.,există mai mulți pași necesari pentru a permite urmărirea sigură a dispozitivelor și pentru a verifica adresele sursă ale acestora. Primul pas este să activați” urmărirea dispozitivelor ip ” la nivel global pe comutator. Acest lucru vă asigură că comutatorul poate urmări ce adresă IP aparține adresei MAC. Apoi, pe fiecare interfață, definiți numărul de dispozitive cărora li se permite să se conecteze cu ip device tracking maximum num unde num poate fi un număr de la 1 la 10. Acum activați switchport port-security pe fiecare interfață pentru a vă asigura că sunt utilizate numai adresele MAC permise., Și în final activați caracteristica de verificare care leagă toate acestea împreună cu ip verify source tracking port-security.

acum comutatorul are toate informațiile de care are nevoie pentru a spiona traficul DHCP, a conecta adresele IP la adresele MAC și a verifica dacă toate pachetele trimise prin comutator sunt conforme cu starea colectată care se bazează pe răspunsurile de la serverul DHCP. Pachetele care nu sunt conforme cu ceea ce a atribuit serverul DHCP vor fi abandonate.

4. 3.6. Cablu sursă-verificați

rețelele de modem de cablu sunt în multe feluri similare cu rețelele ethernet., Dacă nu este configurat altfel, utilizatorii pot falsifica adresele sursă sau pot fura adresele altor utilizatori din rețeaua de cablu. Caracteristica Cisco cable source-verify permite operatorului CMTS să limiteze ce sursă se adresează unui utilizator.există două variante ale acestei caracteristici:

●cable source-verify
●cable source-verify dhcp

ambele variante afectează adresele din subrețeaua rețelei de cablu care pot fi utilizate. Prima variantă împiedică utilizatorii să-și fure adresele reciproc și, prin urmare, nu este suficientă pentru MANRS., Vom analiza a doua variantă.

Configurarea cable source-verify dhcp spune CMTS că toate adresele sursă trebuie verificate în raport cu contractele de leasing DHCP pe care CMTS le-a văzut. În cazul în care un pachet este trimis cu o sursă diferită CMTS va scadea. Acest lucru va împiedica utilizatorii să utilizeze adrese care nu le sunt atribuite prin DHCP .

probleme pot apărea atunci când CMTS este reîncărcat. Într-un astfel de caz, CMTS nu va cunoaște toate contractele de închiriere DHCP de la utilizatorii săi și ar putea scădea traficul legitim. Pentru a rezolva acest lucru CMTS poate fi configurat pentru a utiliza protocolul DHCP LeaseQuery., Acest lucru permite CMTS să ceară serverului DHCP despre contractele de închiriere pentru traficul pe care îl vede. Odată ce serverul DHCP confirmă că există un contract de închiriere legitim pentru această adresă, CMTS îl va adăuga în memoria cache și va permite traficul.

pentru a configura CMTS să nu aibă încredere în ARP pe rețeaua de cablu configurați-l cu no cable arp. Acest lucru vă va asigura că numai informațiile învățate de la DHCP și LeaseQuery sunt de încredere atunci când verificați adresele sursă.

caracteristica cable source-verify protejează numai subrețeaua rețelei de cablu în sine., Pentru a împiedica utilizatorii să falsifice alte adrese și pentru a permite traficul de la clienții care au o subrețea rutată pe care li se permite să o utilizeze, configurați și ip verify unicast source reachable-via rx pentru a activa modul strict uRPF în rețeaua de cablu. Aceasta va verifica toate adresele sursă care nu sunt direct în rețeaua de cablu și va permite validarea, de exemplu, a rutelor statice pentru subrețele direcționate către clienți.

4. 3.7., Lista de Control al accesului (Acl-uri)

Acl-uri sunt frecvent utilizate pe Provider Edge (PE) – Customer Edge (CE) limita, dar sunt, de asemenea, foarte utile în alte locuri, cum ar fi spre furnizorului de propriul server, client și rețelele de infrastructură pentru a preveni dispozitive de incorect. Strategia ACL optimizată ar fi plasarea unui filtru de permis explicit pe interfața clientului. Filtrele de autorizare explicite permit intervale de adrese specifice și apoi neagă orice altceva. De exemplu, dacă clientului operatorului i se alocă 192.0.2.0/24, BCP 38 ACL ar permite toate adresele sursă de la 192.0.2.,0/24 și apoi neagă toate pachetele a căror adresă sursă nu este 192.0.2.0/24.

pe interfețele din aval ale ISP, ar trebui să existe filtre care să verifice adresele sursă utilizate de clienții săi. Dacă uRPF nu poate fi utilizat, atunci sunt necesare ACL-uri manuale. Să luăm primul client din diagrama de exemplu de mai sus:

Cisco:

Juniper:

4.3.7.1., Puncte de agregare

Când Acl-uri la PE-CE limita nu sunt posibile, de exemplu pentru că mai mulți clienți sunt conectate la un singur strat-2 și rețea layer-2 dispozitive nu au caracteristici pentru a filtra pe layer-3 informații, apoi filtrarea la o agregare punct este a doua cea mai bună soluție.

în acest exemplu este (pentru un motiv nespecificat) nu este posibil să se filtreze pe / 24 pentru fiecare client. În acest caz, filtrarea pe 192.0.2.0 / 23 și 198.51.100.,0/23 (și în mod similar pentru IPv6) la un punct de agregare apropiat de conexiunile clienților ar limita cel puțin posibilitățile de falsificare pentru acel grup de clienți la o gamă mică de adrese.

Configurarea se face în același mod ca în secțiunea anterioară, cu excepția faptului că acum se face pe un router diferit într-o locație mai centrală în rețea.

4. 3.8. Carrier Grade NAT – este NAT un instrument Anti-Spoof?

în mod implicit, multe implementări NAT nu filtrează adresa sursă a clienților., Luați, de exemplu, o configurație simplă NAT pe un router Cisco cum ar fi:

 ip nat inside source list INSIDE pool OUTSIDE overload

această regulă NAT va traduce pachete cu o adresă sursă în lista de acces în interiorul și schimba adresa sursă la o adresă în piscină în afara. Cu toate acestea, pachetele care au o adresă sursă falsificată care nu este inclusă în lista de acces interior vor fi redirecționate fără nicio traducere, rezultând pachete falsificate pe Internet., Când un pachet falsificat se potrivește cu lista de acces, acesta va fi tradus folosind piscina specificată, astfel încât lumea exterioară să nu vadă o adresă sursă falsificată, dar va fi imposibil ca operatorul NAT să urmărească pachetele falsificate înapoi la inițiatorul lor.acest lucru arată că NAT nu este un instrument anti-spoofing. Chiar și atunci când se utilizează nat, adresele sursă utilizate de clienți trebuie verificate cât mai aproape de client, la fel ca în cazurile fără NAT prezentate anterior în acest capitol. Numai atunci pachetele falsificate și / sau nedetectabile pot fi împiedicate să ajungă pe Internet.

4. 3.9., Lectură suplimentară