Gli indirizzi IP sono "banali da forgiare"?

Stavo leggendo alcune delle note sul nuovo servizio DNS pubblico di Google :

• Vantaggi prestazionali
• Vantaggi per la sicurezza

Ho notato nella sezione sicurezza questo paragrafo:

Fino a quando una soluzione standard a livello di sistema per le vulnerabilità DNS non sarà universalmente implementata, come il protocollo DNSSEC2, i resolver DNS aperti devono adottare autonomamente alcune misure per mitigare le minacce note. Sono state proposte molte tecniche; vedi IETF RFC 4542: misure per rendere il DNS più resiliente rispetto alle risposte contraffatte per una panoramica della maggior parte di esse. In Google Public DNS, abbiamo implementato e ti consigliamo i seguenti approcci:

• Overprovisioning delle risorse della macchina per proteggere dagli attacchi DoS diretti ai risolutori stessi. Poiché gli indirizzi IP sono banali da falsificare per gli aggressori, è impossibile bloccare le query in base all'indirizzo IP o alla sottorete; l'unico modo efficace per gestire tali attacchi è semplicemente assorbire il carico.

Questa è una realizzazione deprimente; anche su Stack Overflow / Server Fault / Super User, utilizziamo spesso gli indirizzi IP come base per ban e blocchi di ogni tipo.

Pensare che un attaccante "di talento" possa usare banalmente qualsiasi indirizzo IP che desidera e sintetizzare tutti gli indirizzi IP falsi univoci che desidera, è davvero spaventoso!

Quindi le mie domande:

• È davvero così facile per un utente malintenzionato creare un indirizzo IP in libertà?
• In tal caso, quali mitigazioni sono possibili?

Come affermato da molti altri, le intestazioni IP sono banali da falsificare, purché non ci si interessi a ricevere una risposta. Questo è il motivo per cui viene visto principalmente con UDP, poiché TCP richiede una stretta di mano a 3 vie. Una notevole eccezione è l' inondazione SYN , che utilizza TCP e tenta di legare risorse su un host ricevente; di nuovo, poiché le risposte vengono scartate, l'indirizzo di origine non ha importanza.

Un effetto collaterale particolarmente sgradevole della capacità degli attaccanti di falsificare gli indirizzi di origine è un attacco di retrodiffusione . C'è una descrizione eccellente qui , ma brevemente, è l'inverso di un attacco DDoS tradizionale:

1. Ottieni il controllo di una botnet.
2. Configura tutti i tuoi nodi in modo che utilizzino lo stesso indirizzo IP di origine per pacchetti dannosi. Questo indirizzo IP sarà la tua eventuale vittima.
3. Invia pacchetti da tutti i tuoi nodi controllati a vari indirizzi su Internet, indirizzando le porte che in genere non sono aperte o connettendosi a porte valide (TCP / 80) dichiarando di far parte di una transazione già esistente.

In uno dei casi menzionati in (3), molti host risponderanno con un ICMP irraggiungibile o un reset TCP, indirizzato all'indirizzo di origine del pacchetto dannoso . L'attaccante ora ha potenzialmente migliaia di macchine senza compromessi sulla rete che eseguono un attacco DDoS sulla vittima prescelta, il tutto attraverso l'uso di un indirizzo IP di origine contraffatto.

In termini di mitigazione, questo rischio è realmente uno che solo gli ISP (e in particolare gli ISP che forniscono accesso ai clienti, anziché il transito) possono affrontare. Esistono due metodi principali per farlo:

1. Filtraggio dell'ingresso - assicurando che i pacchetti che arrivano alla tua rete provengano da intervalli di indirizzi che vivono sul lato opposto dell'interfaccia in entrata. Molti fornitori di router implementano funzionalità come l'inoltro unicast del percorso inverso , che utilizzano le tabelle di routing e forwarding del router per verificare che l'hop successivo dell'indirizzo di origine di un pacchetto in arrivo sia l'interfaccia in arrivo. Ciò viene eseguito al meglio nel primo hop di livello 3 nella rete (ovvero il gateway predefinito).

2. Filtraggio dell'uscita: garantire che i pacchetti che escono dalla rete siano solo origine dagli intervalli di indirizzi che possiedi. Questo è il naturale complemento del filtro di ingresso ed è essenzialmente parte dell'essere un "buon vicino"; assicurando che anche se la tua rete è compromessa dal traffico dannoso, quel traffico non viene inoltrato alle reti con cui ti colleghi.

Entrambe queste tecniche sono più efficaci e facilmente implementabili quando eseguite in reti "edge" o "access", in cui i client si interfacciano con il provider. L'implementazione del filtro di ingresso / uscita sopra il livello di accesso diventa più difficile, a causa della complessità dei percorsi multipli e del routing asimmetrico.

Ho visto queste tecniche (in particolare il filtro di ingresso) utilizzate con grande efficacia all'interno di una rete aziendale. Forse qualcuno con una maggiore esperienza con i fornitori di servizi può fornire maggiori informazioni sulle sfide della distribuzione di filtri di ingresso / uscita su Internet in generale. Immagino che il supporto hardware / firmware sia una grande sfida, oltre a non essere in grado di forzare i fornitori a monte in altri paesi ad attuare politiche simili ...

È davvero così facile per un utente malintenzionato creare un indirizzo IP in libertà?

Certo, se non mi interessa davvero ricevere alcuna risposta, posso facilmente inviare pacchetti usando qualsiasi indirizzo sorgente che mi piace. Dal momento che molti ISP non hanno davvero buone regole di uscita, tutto ciò che forgia in genere verrà consegnato.

Se l'attaccante ha effettivamente bisogno di una comunicazione bidirezionale diventa molto difficile. Se hanno bisogno di una comunicazione bidirezionale, tende ad essere più semplice usare semplicemente un proxy di qualche tipo. Che è molto facile da impostare se sai cosa stai facendo.

Il bando delle persone per indirizzo IP è moderatamente efficace su SF / SO / SU poiché il sito utilizza http / https che richiede una comunicazione bidirezionale.

Little Proof of Concept per la risposta di Zordeche (con ubuntu):

$ sudo apt-get install hping3
$ sudo hping3 -1 --spoof 11.10.10.20 www.google.com
HPING www.google.com (eth0 64.233.169.105): icmp mode set, 28 headers + 0 data bytes

Quindi in un'altra console:

$ sudo tcpdump -i eth0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
13:30:19.439737 IP 11.10.10.20 > yo-in-f105.1e100.net: ICMP echo request, id 31297, seq 0, length 8

Quindi sì, banale, ma poi non ricevi le risposte come menzionato in precedenza a meno che tu non abbia accesso a 11.10.10.20 o abbia uno sniffer da qualche parte tra www.google.com e 11.10.10.20 (E dovrebbe essere proprio di fronte di entrambe le estremità, poiché non è possibile prevedere il percorso dei pacchetti). Inoltre, il gateway spoofer (ISP) potrebbe non lasciare quel pacchetto fuori dalla porta se hanno una sorta di ispezione IP in corso e vedere che la fonte ha un cattivo odore.

Gli indirizzi IP sono facili da creare per il traffico UDP unidirezionale . Per i pacchetti TCP, è possibile creare solo connessioni TCP semiaperte con pacchetti SYN. Questa è anche la base di un tipo di attacco DOS. Ma non puoi creare una connessione HTTP con un indirizzo contraffatto (ad esempio, se stai filtrando le sessioni per utilizzare lo stesso indirizzo IP). Sebbene sì, puoi falsificare un indirizzo IP nei pacchetti, è utile solo per alcuni tipi di attacchi denial of service.

L'articolo GOOG parlava esplicitamente di DNS. DNS utilizza sia i pacchetti UDP che TCP. Quelli UDP possono essere forgiati, ma non il TCP. TCP richiede una stretta di mano a 3 vie . Se viene forgiato l'indirizzo IP per un pacchetto TCP, il computer di forgiatura non riceverà la risposta e la connessione fallirà. L'UDP, come menzionato in altre risposte, è "spara e dimentica" e non richiede alcuna comunicazione di risposta. Gli attacchi DoS arrivano quasi esclusivamente sotto forma di pacchetti UDP per questo motivo.

Nel contesto di Stack Overflow e siti familiari, il problema sollevato da Takaun Daikon è molto valido. Esistono molti modi per ottenere un nuovo indirizzo IP dal proprio ISP. La modifica di un indirizzo MAC è chiaramente la più semplice e funziona per molti ISP. Inoltre, molte persone che sono sciocche possono usare un proxy pubblico o TOR. Bloccare chiaramente l'IP di origine per quei pacchetti bloccherebbe semplicemente il proxy o il nodo di terminazione TOR.

Quindi è valido il blocco degli indirizzi IP? Inferno sì, lo è. Ma finirai con errori. Bloccerai alcuni IP che in realtà non sono la fonte del problema (ovvero i proxy) e avrai anche persone che evitano i tuoi blocchi cambiando gli IP. La persona che è abbastanza sfortunata da ottenere in seguito l'IP vietato non sarà in grado di accedere alla famiglia di siti SO. Ma il tasso di errore dovrebbe essere piccolo. A meno che tu non stia bloccando enormi set di IP. Ma se stai bloccando uno o due al giorno, dovresti stare bene.

Potresti voler introdurre uno schema leggermente più sofisticato in cui blocchi, ma solo per un periodo, come un anno. Se la tua rete è in grado di limitare la larghezza di banda o limitare la connessione, potresti anche prendere in considerazione uno schema in cui i sacchetti douche che eseguono benchmark Apache sul tuo sito vengono semplicemente messi in una gabbia con larghezza di banda molto limitata.

Lo spoofing IP continuerà perché gli ISP sono pigri.

Il mio ISP sa bene che sono su un indirizzo specifico, o almeno sulla sottorete in cui mi trovo. Eppure posso usare qualsiasi indirizzo di origine. Perché? Semplicemente, costo.

Se fingo alcuni indirizzi qua e là, il mio ISP non costa nulla. Se ogni utente del mio ISP falsificasse un pacchetto tra l'1: 00 e le 2:00, non sarebbe ancora un segnale sul radar. Tuttavia, quando una botnet invia molti pacchetti contraffatti da molti host su molti ISP, la macchina o la rete di destinazione cadono.

La realtà finanziaria è che, a meno che tu non sia quello attaccato, lo spoofing non costa nulla. L'implementazione del filtro vicino al cliente costa denaro e chi spende il denaro realizza ben poco ritorno oltre a sapere che sono buoni cittadini di rete.

UDP e ICMP sono i più facili da falsificare, ma è anche possibile TCP. Richiede un sistema operativo remoto non sicuro, che utilizza numeri di sequenza prevedibili per sfruttare. A volte sono le macchine di bilanciamento del carico che modificano i numeri di sequenza e li rendono prevedibili. Quindi, TCP è possibile, ma più difficile.

L'anti-spoofing DNS si concentra principalmente sul lato della sicurezza per impedire a qualcuno di inviare una risposta falsa a un risolutore ricorsivo. Gli aspetti alluvionali di UDP non sono specifici del DNS se non una singola piccola query (diciamo, per ".") Causerà una risposta piuttosto ampia. Quindi, rende un bel vettore di amplificazione. Esistono molti altri protocolli UDP che funzionano, ma il DNS è in uso ovunque ed è facile trovare macchine da usare per amplificare gli attacchi.

DNSSEC lo rende ancora peggio, con pacchetti UDP che possono raggiungere dimensioni 4k.

Gli indirizzi IP sono banali da forgiare per quanto riguarda gli attacchi DOS basati su DNS (D), in quanto in genere si tratta di pacchetti UDP "Fire-and-forget". Per il traffico HTTP, non è questo il caso, quindi dovresti trovarti sulla stessa rete locale del server web (completamente possibile, ovviamente, a seconda di dove è ospitato il tuo sito), o controllare i router intermedi.

Puoi inviare una lettera a chiunque e se non metti un indirizzo di ritorno sulla busta (o metti quella sbagliata), possono assumere tutti i filtri della posta indesiderata nel mondo e non filtrare il tuo messaggio senza aprirlo (elaborazione ).

Tuttavia, se il mittente desidera una risposta, l'indirizzo di ritorno dovrebbe essere corretto, oppure dovrebbe esserci un meccanismo a livello di applicazione per ottenere l'indirizzo corretto. Quindi posso farti pensare che stai aprendo una lettera di Nana, ma anche se ti ingannassi con il contenuto della lettera, non invierai Nana un assegno intestato a CASH a un indirizzo in Nigeria (a meno che Nana non sia nigeriana ). Quindi la sfida / risposta è un'efficace difesa fintanto che non sei anche Man in the Middled.

Posso impostare qualsiasi indirizzo IP sorgente che voglio in un datagramma.
Se il mio ISP lascerebbe uscire un pacchetto del genere in libertà è un'altra domanda.

Mentre questa è certamente una realtà che deve essere affrontata, il problema di fondo è in realtà non tecnico: le persone con intenti maliziosi cercano di fare cose maligne. La vera soluzione quindi deve essere anche non tecnica.

Penso che quello che Stackoverflow abbia fatto sia ESATTAMENTE la soluzione giusta per gestire la seconda linea di difesa: le tecniche per limitare i potenziali utenti di spam attraverso i diversi modi di limitare le loro capacità di interagire con la piattaforma prima di raggiungere un certo livello di "credibilità".

Queste tecniche non solo aiutano a migliorare la qualità complessiva del sito, ma incoraggiano anche gli utenti a essere più coinvolti e fornire risposte più credibili / affidabili.

Dal punto di vista tecnico, la cosa migliore da fare sarebbe fare come suggerisce Google: basta essere efficienti nell'assorbire / gestire il carico aggiuntivo.

Ottimo lavoro e continua a migliorare!

UDP è la parte principale del motivo per cui questo è facile: infatti Skype e Slingbox sfruttano la capacità di forgiare facilmente indirizzi IP in UDP per " punzonare " attraverso NAT e consentire un facile peer-to-peer.

Il protocollo TCP è più difficile poiché richiede un ciclo SYN / ACK completo, ma è comunque possibile inondare il server con pacchetti SYN sospesi che vanno a indirizzi IP a molti hop di distanza e essenzialmente legano un numero enorme di router nel processo.

Come accennato in precedenza, l'utilizzo dei proxy è banale e sono disponibili un numero molto elevato di proxy anonimi aperti.

Anche senza usare un proxy, posso impostare l'indirizzo MAC sul mio firewall su qualsiasi nuovo valore arbitrario, ripristinare il mio modem via cavo e il mio ISP mi assegnerà un nuovissimo indirizzo IP brillante.

E questo è solo per cominciare. Esistono molti altri modi per aggirare i divieti IP.

In tal caso, quali mitigazioni sono possibili?

Non puoi fare molto sul lato ricevente.

L'ISP del falsario dovrebbe filtrare il traffico in uscita in modo che i suoi clienti non possano falsificare gli IP da reti diverse.

Sono presenti solo poche righe nella configurazione del router, quindi non ci sono buone scuse per non farlo.

Esiste un modo per tracciare l'attaccante, ma richiede la copertura dei provider upstream: http://www.cymru.com/Documents/dos-and-vip.html

Come altri hanno sottolineato, UDP è abbastanza banale da forgiare, TCP non tanto.

La difesa preferita, ma sfortunatamente non distribuita universalmente, sono i filtri di uscita.

Per gli ISP che eseguono servizi DSL ecc., Ogni linea virtuale deve essere configurata con ip verify unicast reverse-path(o qualunque sia l'equivalente non Cisco) che blocchi qualsiasi pacchetto il cui indirizzo IP di origine non rientri negli intervalli noti per essere instradati lungo quella linea.

Ricordo di aver programmato i socket alla fine degli anni '90 con quello che probabilmente era Visual Basic e potevamo impostare l'IP di origine sulla nostra connessione. Ricordo vagamente che quando l'abbiamo provato, netstat -an mostrava l'effettivo IP di origine, ma i registri di Apache mostravano l'IP falsificato; e penso che Apache stia consegnando l'IP spoofing ai moduli perl e così via.