MANRS Implementation Guide
- Introduzione
- Coordinamento
- Convalida globale
- Anti-Spoofing
- Filtraggio
- Riepilogo e liste di controllo
- Informazioni aggiuntive
4.3. Anti-Spoofing-Prevenire il traffico con indirizzi IP di origine contraffatti
MANRS rilevanti azioni previste:
- L’operatore di rete implementa un sistema che consente la convalida dell’indirizzo di origine per almeno le reti dei clienti stub a casa singola, i propri utenti finali e l’infrastruttura., L’operatore di rete implementa il filtro anti-spoofing per evitare che i pacchetti con indirizzo IP sorgente errato entrino e escano dalla rete.
Lo spoofing dell’indirizzo di origine IP è la pratica di originare datagrammi IP con indirizzi di origine diversi da quelli assegnati all’host di origine. In termini semplici, l’host finge di essere un altro host. Questo può essere sfruttato in vari modi, in particolare per eseguire attacchi di amplificazione della riflessione Denial of Service (DoS) che causano un host reflector per inviare traffico all’indirizzo falsificato.,
Ci sono molte raccomandazioni per prevenire lo spoofing IP tramite il filtro di ingresso, ad esempio controllando gli indirizzi di origine dei datagrammi IP vicino al bordo della rete. La maggior parte dei fornitori di apparecchiature supporta il filtraggio dell’ingresso in qualche forma. Dal 2005, l’implementazione di tecniche anti-spoofing non è stata una limitazione delle prestazioni delle apparecchiature. È stata una limitazione del desiderio e della volontà di implementare e mantenere la configurazione anti-spoofing.
Ironia della sorte, significativi attacchi di amplificazione DoS possono essere costosi per i fornitori di servizi., I costi danneggiano il marchio, danneggiano le operazioni dei clienti e hanno un impatto collaterale operativo/sui costi su altri clienti. Questi attacchi di amplificazione DoS sono prevenibili. Sarebbero impossibili senza spoofing.
Questo dimostra che il filtro di ingresso non è sicuramente sufficientemente distribuito. Sfortunatamente, non ci sono vantaggi per un provider di servizi (SP) che distribuisce il filtro di ingresso. C’è anche una convinzione diffusa che il filtraggio dell’ingresso aiuta solo quando è universalmente distribuito.,
Approcci comuni a questo problema hanno coinvolto funzionalità software come SAV (Source – Address Validation) su reti via cavo-modem o strict URPF (unicast Reverse-Path Forwarding) validazione su reti router. Questi metodi possono facilitare il sovraccarico dell’amministrazione nei casi in cui il routing e la topologia sono relativamente dinamici. Un altro approccio potrebbe essere quello di utilizzare le informazioni del filtro prefisso in entrata per creare un filtro pacchetti, che consentirebbe solo pacchetti con indirizzi IP di origine per i quali la rete potrebbe legittimamente pubblicizzare la raggiungibilità.,
Per la maggior parte delle architetture di rete più piccole e semplici, il modo più semplice per prevenire lo spoofing è usare Unicast RPF (uRPF) in modalità Strict. Per filtrare gli indirizzi di origine utilizzati dai dispositivi su un dominio layer-2, è possibile utilizzare il SAVI (Source Address Validation Improvements). Nelle apparecchiature in cui non sono disponibili funzionalità di filtraggio automatico, è possibile utilizzare gli elenchi di controllo degli accessi (ACL) per implementare manualmente il filtro equivalente. Tutte queste tecnologie sono spiegate di seguito.
4.3.1., Principi guida per le architetture anti-Spoofing
Per essere il più efficace possibile le tecniche anti-spoofing devono essere applicate il più vicino possibile alla sorgente. Nelle reti aziendali, gli indirizzi di origine utilizzati da ogni dispositivo sono spesso controllati e applicati in modo che gli audit di sicurezza possano individuare esattamente quale dispositivo ha inviato quale pacchetto.
Per un’implementazione di successo di MANRS, tale granularità fine a livello di dispositivo non è necessaria in quanto MANRS si concentra sulla sicurezza del routing e sull’anti-spoofing a livello di rete., Pertanto, le comuni architetture anti-spoofing si concentrano sul fatto che i clienti non inviano pacchetti con indirizzi di origine errati.
L’applicazione dell’uso di indirizzi di origine validi a livello di cliente ha il vantaggio che i clienti non possono falsificare gli indirizzi degli altri, il che impedisce loro di causare problemi reciproci difficili da eseguire il debug.
Se per qualche motivo non è possibile applicare l’utilizzo dell’indirizzo di origine per cliente, un’alternativa è applicarlo nei punti di aggregazione in modo che i clienti siano almeno limitati in quali indirizzi possono falsificare., Come minimo ci dovrebbe essere anti-spoofing a livello di ISP in modo che i clienti non possono falsificare gli indirizzi di altre organizzazioni e causare problemi su scala Internet.
4.3.2. Unicast RPF
BCP38 uRPF Strict Mode con RFC1998++ style of multihoming (un BCP per multihoming) è un approccio che funziona in configurazioni simmetriche (single homed) e asimmetriche (multihomed BGP), ed è stato implementato operativamente nel 2002. Sì, ci sono molti che pensano che ” uRPF non funzioni a causa dell’asimmetria del routing”, ma questo non è vero., La documentazione del 2001, il whitepaper ISP Essentials (Google per la versione 2.9) e il libro ISP Essentials (ISBN 1587050412) insieme alle distribuzioni in diversi SP principali hanno dimostrato che la modalità uRPF strict è una tecnica praticabile.
Ci sono quattro algoritmi per uRPF: Modalità rigorosa (controlla IP sorgente e adiacenza), Modalità libera (controlla solo IP sorgente), Percorso fattibile (controlla IP sorgente con le alternative del FIB) e modalità VRF (permit/deny check on source in una tabella separata dal FIB)., Ognuna di queste opzioni uRPF è progettata per specifiche funzioni di “anti-spoofing” in diverse parti della rete.
- uRPF Modalità rigorosa-BCP38 sul cliente-SP bordo. Ogni pacchetto in entrata viene testato contro il FIB e se l’interfaccia in entrata non è il miglior percorso inverso, il pacchetto viene eliminato.
- uRPF Loose Mode-sRTBH ovunque nella rete-ma solo controllare se il percorso è in FIB. Se non nel FIB, poi cadere. Se è nel FIB, quindi passare. Buono per sRTBH e mitigare alcuni traffico falsificato sul bordo peering.,
- uRPF Percorso fattibile-sRTBH ovunque nella rete e BCP38 per i clienti multihomed e percorsi asimmetrici. Nella modalità fattibile il FIB mantiene percorsi alternativi a un determinato indirizzo IP. Se l’interfaccia in entrata corrisponde a uno qualsiasi dei percorsi associati all’indirizzo IP, il pacchetto viene inoltrato. Altrimenti il pacchetto viene eliminato.
- uRPF VRF Mode – Applicazione della politica di peering basata su BGP o sRTBH più granulare (NOTA La modalità VRF potrebbe essere utilizzata come BCP38, ma non è stata dimostrata operativamente)
uRPF può essere utile in molti punti della rete., È più spesso utilizzato sui bordi delle reti in cui sono collegati clienti, server e/o client perché la modalità rigorosa funziona bene lì. Gli operatori di rete sono riluttanti a utilizzare uRPF nel nucleo delle loro reti a causa del timore di cadere accidentalmente traffico valido che ha preso un percorso inaspettato attraverso la loro rete. La modalità Percorso fattibile uRPF dovrebbe risolvere tali problemi.
Sia Cisco che Juniper implementano sia la modalità strict che la modalità loose. Mostriamo come utilizzare la modalità rigorosa., Configurare la modalità uRPF Strict sulle interfacce verso i clienti con:
Cisco:
ip verify unicast source reachable-via rx ipv6 verify unicast source reachable-via rxJuniper:
family inet { rpf-check; } family inet6 { rpf-check; }Che farà in modo che il cliente possa utilizzare solo gli indirizzi IP che si indirizzano a loro. In situazioni in cui sei cliente di un altro ISP in cui hai un percorso predefinito che punta a quell’ISP dovresti usare:
Cisco:
ip verify unicast source reachable-via rx allow-default ipv6 verify unicast source reachable-via rx allow-defaultJuniper:
I router Juniper adattano automaticamente il loro filtro uRPF in base a dove tutti i percorsi predefiniti puntano verso. Basta usare gli stessi comandi di cui sopra.,
L’opzione consenti-default è necessaria perché per impostazione predefinita gli indirizzi di origine saranno abbinati solo a rotte specifiche, ignorando la rotta predefinita. Mentre la corrispondenza con la rotta predefinita sembra essere la stessa di consentire qualsiasi cosa, non lo è.Si assicura che il tuo upstream non ti invii traffico per il quale hai altri percorsi più specifici che puntano in una direzione diversa, come le tue reti e le reti dei tuoi clienti. Questo vi proteggerà contro il traffico falsificato da altri.
4.3.3., Elenco di accesso dinamico (Radius & Diameter)
Il modo standard per impostare gli elenchi di accesso per gli utenti autenticati da Radius è tramite l’attributo Radius 11 (Filter-Id). Con questo attributo è possibile dire al router di applicare un elenco di accesso preesistente alla connessione dell’utente. Ciò richiede un metodo out-of-band per eseguire il provisioning di tutti i router con le liste di accesso corrette però.
Alcuni fornitori hanno opzioni di raggio extra che possono essere utilizzate per eseguire il provisioning dinamico dell’elenco di accesso stesso tramite Radius., Cisco ad esempio fornisce funzionalità extra tramite gli attributi cisco-avpair:
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"Ciò consentirebbe solo i pacchetti del cliente che hanno un indirizzo di origine nell’intervallo 192.0.2.0/24.
4.3.4. SAVI
SAVI è il nome del gruppo di lavoro If che lavora sui miglioramenti della convalida degli indirizzi di origine. Per la convalida dell’indirizzo di origine di un cliente, viene comunemente utilizzata la soluzione SAVI per DHCP in RFC 7513., Questa versione di SAVI tiene traccia di tutti gli indirizzi IP assegnati a ciascun dispositivo curiosando negli scambi di messaggi DHCPv4 e DHCPv6 sullo switch di rete a cui il cliente è connesso. Se un cliente utilizza un indirizzo di origine non autorizzato, lo switch rilascia il pacchetto.
I fornitori spesso usano la propria terminologia per descrivere le funzionalità di SAVI. Sui dispositivi Cisco queste funzionalità sono indicate come DHCP Snooping, Source Guard e Prefix Guard.
4.3.5., IP Verify Source
Le reti Ethernet sono domini broadcast e per impostazione predefinita non esiste alcuna convalida di chi è autorizzato a inviare pacchetti con quali indirizzi. Per configurare gli switch Cisco per verificare gli indirizzi di origine utilizzati dai dispositivi collegati, è possibile utilizzare l’impostazione “verifica origine ip”.,
Ci sono tre varianti di questa caratteristica:
● ip verify source
● ip verify source port-security
● ip verify source tracking port-security
La prima variante verifica dell’indirizzo IP di origine, la seconda variante, inoltre, consente di verificare l’indirizzo MAC di origine e la terza variante tracce le associazioni tra indirizzo IP e l’indirizzo MAC. Per impedire ai clienti di utilizzare l’indirizzo MAC di un altro cliente, si consiglia l’ultima variante. Tutti questi basano la loro decisione sui dati DHCP snooped.,
Prima di essere in grado di verificare gli indirizzi di origine, lo switch deve essere configurato per snoop il traffico DHCP per raccogliere dati su cui basare le proprie decisioni con ip dhcp snooping. Per tenere traccia di quale porta ethernet si connette a ciascun client DHCP utilizzare l’opzione DHCP 82 conip dhcp snooping information option. Ciò è necessario perché con verify port-security lo switch non apprenderà gli indirizzi MAC fino a quando il server DHCP non avrà assegnato un indirizzo IP al dispositivo collegato. L’opzione 82 è quindi necessaria per ricordare allo switch dove era collegato il client.,
Sono necessari diversi passaggi per consentire il tracciamento sicuro dei dispositivi e verificare i loro indirizzi di origine. Il primo passo è abilitare” ip device tracking ” a livello globale sullo switch. Questo fa in modo che lo switch può tenere traccia di quale indirizzo IP appartiene a quale indirizzo MAC. Quindi su ogni interfaccia, definire il numero di dispositivi che sono autorizzati a connettersi con ip device tracking maximum num dove num può essere un numero da 1 a 10. Ora abilita switchport port-security su ogni interfaccia per garantire che vengano utilizzati solo gli indirizzi MAC consentiti., E infine abilitare la funzione di verifica che collega tutti questi insieme a ip verify source tracking port-security.
Ora lo switch ha tutte le informazioni necessarie per curiosare il traffico DHCP, collegare gli indirizzi IP agli indirizzi MAC e verificare che tutti i pacchetti inviati tramite lo switch siano conformi allo stato raccolto che si basa sulle risposte dal server DHCP. I pacchetti che non sono conformi a ciò che il server DHCP ha assegnato verranno eliminati.
4.3.6. Cable Source-Verifica
Le reti modem via cavo sono per molti versi simili alle reti ethernet., Se non diversamente configurato, gli utenti possono falsificare gli indirizzi di origine o rubare gli indirizzi di altri utenti sulla rete via cavo. La funzione di verifica della sorgente del cavo Cisco consente all’operatore CMTS di limitare gli indirizzi di origine che un utente può utilizzare.
Esistono due varianti di questa funzione:
● cable source-verify
● cable source-verify dhcp
Entrambe le varianti influenzano gli indirizzi della sottorete della rete via cavo che possono essere utilizzati. La prima variante impedisce solo agli utenti di rubare gli indirizzi degli altri e quindi non è sufficiente per MANRS., Vedremo la seconda variante.
Configurare cable source-verify dhcp indica al CMTS che tutti gli indirizzi di origine devono essere verificati rispetto ai lease DHCP che il CMTS ha visto. Se un pacchetto viene inviato con una fonte diversa, il CMTS lo lascerà cadere. Ciò impedirà agli utenti di utilizzare indirizzi non assegnati tramite DHCP .
Problemi possono verificarsi quando il CMTS viene ricaricato. In tal caso il CMTS non conoscerà tutti i leasing DHCP dai suoi utenti e potrebbe eliminare il traffico legittimo. Per risolvere questo problema il CMTS può essere configurato per utilizzare il protocollo DHCP LeaseQuery., Ciò consente al CMTS di chiedere al server DHCP informazioni sui leasing per il traffico che sta vedendo. Una volta che il server DHCP conferma che esiste un lease legittimo per quell’indirizzo, il CMTS lo aggiungerà alla sua cache e consentirà il traffico.
Per configurare il CMTS di non fidarsi ARP sulla rete via cavo configurarlo conno cable arp. Ciò assicurerà che solo le informazioni apprese da DHCP e LeaseQuery siano attendibili durante la verifica degli indirizzi di origine.
La funzione cable source-verify protegge solo la sottorete della rete via cavo stessa., Per impedire agli utenti di spoofing altri indirizzi, e per consentire il traffico da parte dei clienti che hanno una subnet instradata che sono autorizzati a utilizzare, anche configurare ip verify unicast source reachable-via rx per abilitare la modalità uRPF Strict sulla rete via cavo. Ciò controllerà tutti gli indirizzi di origine che non sono direttamente sulla rete via cavo e consentirà la convalida rispetto, ad esempio, ai percorsi statici per le sottoreti instradate verso i clienti.
4.3.7., Access Control List (ACL)
Gli ACL sono comunemente distribuiti sul confine Provider Edge (PE) – Customer Edge (CE), ma sono anche molto utili in altri luoghi come le reti server, client e infrastrutture del provider per evitare che i dispositivi si comportino male. La strategia ACL ottimizzata sarebbe quella di inserire un filtro di autorizzazione esplicito nell’interfaccia del cliente. I filtri di autorizzazione espliciti consentono intervalli di indirizzi specifici e quindi negano tutto il resto. Ad esempio, se al cliente dell’operatore viene assegnato 192.0.2.0/24, l’ACL BCP 38 consentirebbe tutti gli indirizzi di origine da 192.0.2.,0/24 e quindi negare tutti i pacchetti il cui indirizzo di origine non è 192.0.2.0 / 24.
Sulle interfacce downstream dell’ISP, dovrebbero esserci filtri che verificano gli indirizzi di origine utilizzati dai suoi clienti. Se uRPF non può essere utilizzato, sono necessari ACL manuali. Prendiamo il primo cliente dal diagramma di esempio sopra:
Cisco:
Juniper:
4.3.7.1., Punti di aggregazione
Quando gli ACL al limite PE-CE non sono possibili, ad esempio perché più clienti sono collegati a una singola rete layer-2 e i dispositivi layer-2 non hanno le caratteristiche per filtrare le informazioni layer-3, il filtraggio in un punto di aggregazione è la seconda soluzione migliore.
In questo esempio non è possibile (per qualche motivo non specificato) filtrare su / 24 per ogni cliente. In tal caso filtraggio su 192.0.2.0 / 23 e 198.51.100.,0/23 (e allo stesso modo per IPv6) in un punto di aggregazione vicino alle connessioni del cliente limiterebbe almeno le possibilità di spoofing per quel gruppo di clienti a un piccolo intervallo di indirizzi.
La configurazione viene eseguita nello stesso modo mostrato nella sezione precedente, tranne che ora viene eseguita su un router diverso in una posizione più centrale nella rete.
4.3.8. Carrier Grade NAT-È NAT uno strumento anti-Spoof?
Per impostazione predefinita molte implementazioni NAT non filtrano l’indirizzo di origine dei client., Prendiamo ad esempio una semplice configurazione NAT su un router Cisco come:
ip nat inside source list INSIDE pool OUTSIDE overloadQuesta regola NAT tradurrà i pacchetti con un indirizzo di origine in access list ALL’interno e cambierà l’indirizzo di origine in un indirizzo nel pool ESTERNO. Tuttavia, i pacchetti che hanno un indirizzo di origine contraffatto che non è incluso nell’elenco di accesso INTERNO verranno inoltrati senza alcuna traduzione, con conseguente pacchetti falsificati su Internet., Quando un pacchetto contraffatto corrisponde all’elenco di accesso, verrà tradotto utilizzando il pool specificato, quindi il mondo esterno non vede un indirizzo di origine falsificato, ma sarà impossibile per l’operatore NAT risalire ai pacchetti falsificati al loro creatore.
Questo dimostra che NAT non è uno strumento anti-spoofing. Anche quando si utilizza NAT gli indirizzi di origine utilizzati dai clienti devono essere controllati il più vicino possibile al cliente, proprio come nei casi senza NAT mostrati in precedenza in questo capitolo. Solo allora è possibile impedire ai pacchetti falsificati e/o non rintracciabili di raggiungere Internet.