So che le persone possono modificare le intestazioni IP e cambiare l'indirizzo IP di origine, ma per i dispositivi di rete dovrebbe essere semplice rilevare tali messaggi. Se non lo fanno, perché è così difficile? Aggiunge troppo sovraccarico?
So che le persone possono modificare le intestazioni IP e cambiare l'indirizzo IP di origine, ma per i dispositivi di rete dovrebbe essere semplice rilevare tali messaggi. Se non lo fanno, perché è così difficile? Aggiunge troppo sovraccarico?
Risposte:
So che le persone possono modificare le intestazioni IP e cambiare l'indirizzo IP di origine, ma per i dispositivi di rete dovrebbe essere semplice rilevare tali messaggi.
Gli indirizzi IP falsi nelle intestazioni possono essere rilevati e bloccati in dispositivi di rete commerciali; altre intestazioni IPv4 false possono essere un po 'più difficili da identificare. Molte persone si riferiscono alla funzione per rilevare indirizzi IP di origine falsi come "Unicast Reverse Path Forwarding", che è abbreviato in uRPF ; uRPF è definito in RFC 3704 ed è considerato una best practice corrente su Internet . uRPF deve essere applicato sul primo router dall'apparecchiatura locale del cliente o sul router perimetrale in una rete aziendale.
Se non lo fanno, perché è così difficile? Aggiunge troppo sovraccarico?
Finché il router non è un router basato su CPU, non vi è alcuna penalità di prestazione. Molti dei router / switch utilizzati dagli ISP hanno questa funzionalità integrata in un ASIC nell'hardware; normalmente non c'è un enorme penalità prestazionale per accenderlo. A volte ci sono conflitti di funzionalità, ma di nuovo questo non è un grosso problema nella maggior parte dei casi.
Le politiche e le competenze del personale tecnico / operativo dell'ISP variano e molti ISP (in particolare nei paesi più piccoli) sono così impegnati a far "funzionare" le cose che non hanno cicli per farle "funzionare bene".
La prevenzione della modifica dell'indirizzo IP di origine richiede elenchi di accesso (ACL) o filtro unicast inverso (uRPF).
Né vieni gratis. uRPF richiede in genere una ricerca aggiuntiva o una ricerca singola più complessa, quindi potrebbe persino dimezzare le prestazioni di ricerca in alcune piattaforme. ACL rallenterà la ricerca e utilizzerà la memoria.
uRPF non richiede manutenzione, è sufficiente configurarlo una volta e dimenticarlo. ACL ha bisogno di un sistema che sappia quali indirizzi si trovano dietro l'interfaccia e si assicura che l'ACL rimanga aggiornato.
ACL più ampiamente supportato di uRPF, uRPF è una funzionalità relativamente rara nei dispositivi di livello switch L3. Nei router "reali" di solito sono disponibili entrambe le funzionalità.
Anche se entrambe le funzionalità sono disponibili, la configurazione di uRPF in un posto errato della rete può interrompere la rete, non comprendere le limitazioni ACL specifiche della piattaforma può causare interruzioni.
Di solito, tu stesso non trarrai alcun vantaggio nel prevenire lo spoofing dell'indirizzo di provenienza, è soprattutto Internet a beneficiarne. Corri un rischio diverso da zero provando a farlo, poiché potresti finire per rompere le cose. E i tuoi clienti non trarranno alcun vantaggio, nessuno ti pagherà di più per implementarli. Quindi la ricompensa è bassa nel farlo.
Il fornitore di servizi responsabile lo fa, perché è la cosa giusta da fare, ma non è realistico aspettarsi che verrà distribuito l'antispoofing in una porzione rilevante di dispositivi di accesso. L'obiettivo molto più realistico è, se eseguiamo ACL nelle connessioni di transito IP, in quanto vi sono solo circa 6000 numeri AS tozzi.
Il motivo per cui questo è persino un problema è dovuto agli attacchi di riflessione UDP, che possono essere risolti da protocolli come QUIC e MinimaLT che assicurano che la riflessione non abbia vantaggi, poiché la query in entrata è garantita più grande della risposta in uscita, quindi lo spoofing perde i suoi benefici.
Recentemente è diventato molto popolare usare la riflessione UDP come attacco DDoS. Ci sono molti server DNS spalancati nei dispositivi CPE consumer che i consumatori non sono a conoscenza, quindi quei consumatori soffrono quando la loro connessione domestica è congestionata poiché viene utilizzata per riflettere l'attacco. Ed è anche un modo semplice per ottenere un'amplificazione significativa, piccole query di decine di byte possono produrre una risposta di oltre mille byte. Ci sono stati attacchi DDoS di riflessione che sono diverse centinaia di gigabit al secondo, e più piccoli sono tutti i giorni, solo la domenica sera abbiamo trasportato un attacco da 43 Gbps a uno dei nostri clienti.
Il filtro degli indirizzi di origine non è banale nel mondo reale, perché il routing di Internet è asimmetrico, quindi in linea di principio abbiamo bisogno di indovinare se è probabile che un pacchetto da questa fonte appaia su questa interfaccia in arrivo.
Non esiste una formula semplice per questo, perché per ogni regola che funziona per quasi tutti i casi, esiste anche un caso d'uso che ha senso dal punto di vista commerciale e che poi si spezzerebbe.
Il filtro del percorso inverso funziona perfettamente sui router perimetrali, in cui esiste una chiara definizione di "interno" e "esterno": non si consente agli estranei di utilizzare indirizzi "interni" e viceversa. Diventa più complicato non appena inizio a utilizzare router edge multipli per ridondanza.
Per i router backbone, l'unico modo per implementare il filtraggio del percorso inverso è consentire i pacchetti in entrata quando il peer annuncia un percorso di lavoro (indipendentemente dal fatto che sia la nostra preferenza). Sarebbe una ricerca proibitivamente lunga, facilmente aggirabile e spezza il caso d'uso in cui compro deliberatamente il transito ma non annuncio il mio prefisso in quel link.