Domanda:
Esistono validi motivi per falsificare un indirizzo?
Steve
2010-12-09 21:27:07 UTC
view on stackexchange narkive permalink

Questo è un corollario alla domanda Perché gli ISP non filtrano in base all'indirizzo di origine per prevenire lo spoofing?.

Esistono validi motivi per falsificare un indirizzo?

Vorrei dare un'occhiata alla domanda che cosa-porta-ip-spoofing-rischi-per la sicurezza. Sento che queste domande sono molto simili, se non duplicate?
Penso che questa domanda sia diversa dalla tua domanda. A prima vista vedo solo rischi; Vorrei sapere come un ambiente IT aziendale può trarre vantaggio dallo spoofing degli indirizzi IP. Link: http://security.stackexchange.com/questions/1009/what-security-risks-does-ip-spoofing-bring
I due potrebbero facilmente incontrarsi nel mezzo, ma le origini sono abbastanza diverse che le risposte potrebbero essere interessanti.
Tre risposte:
Chris Dale
2010-12-09 21:30:42 UTC
view on stackexchange narkive permalink

Ho trovato un articolo qui che descrive alcuni esempi legittimi di spoofing IP:

  • In ambienti IP mobili, dove un host in roaming deve utilizzare un IP "domestico" indirizzo in una rete esterna (rif. C. Perkins, "IP Mobility Support for IPv4)
  • reti private virtuali che impostano l'IP host su un indirizzo locale alla rete dell'organizzazione
Ho aggiornato la risposta e ho aggiunto il vecchio come commento :)
Non vedo ancora sufficienti giustificazioni nel mondo reale per lo spoofing, e ancora non penso che la necessità superi i rischi coinvolti. Spero che più persone pubblichino maggiori dettagli su come un'applicazione utilizza lo spoofing e sul motivo per cui quelle che si affidano alle app non possono essere aggiornate per utilizzare qualcosa di più alto nello stack OSI.
quale VPN lo fa?
Se non sbaglio, ascoltare e rispondere a indirizzi Anycast potrebbe essere considerato uno spoofing in quanto sembra che un indirizzo altrimenti unico sia presente su due lati di un router
Bradley Kreider
2010-12-11 02:36:28 UTC
view on stackexchange narkive permalink

Le reti IP mobili non sono davvero una giustificazione per lo spoofing. RFC 2344 Reverse Tunneling fornisce una risposta per consentire a Mobile IP di funzionare con filtri in ingresso / protezione antispoofing.

Non sono sicuro delle raccomandazioni correnti ma vecchie (2000) RFC come Raccomandazioni ISP RFC 3013 consigliano di filtrare in ingresso e in uscita per fermare lo spoofing.

Non penso che ci sia una ragione reale e legittima per lo spoofing su Internet pubblico. Occasionalmente, le intranet private potrebbero avere una ragione, proprio come hanno una ragione per fare un arp-proxy (un router si maschera da host e inoltra i pacchetti) a volte.

"_Le reti IP mobili non sono realmente una giustificazione per lo spoofing. RFC 2344 Reverse Tunneling fornisce una risposta per consentire a Mobile IP di funzionare con il filtro di ingresso / protezione antispoofing ._" Una risposta per l'antispoofing difficilmente rende lo spoofing non giustificato.
Eh? L'IP mobile è stato presentato come giustificazione per lo spoofing, ma la giustificazione non esiste perché ci sono modi per fare IP mobile senza spoofing.
"_L'IP del cellulare è stato presentato come giustificazione per lo spoofing_" sì, ed è una giustificazione valida. "_ci sono modi per eseguire l'IP mobile senza spoofing_", quindi?
Di cosa sei confuso?
Cosa costituisce una "giustificazione" per qualcosa?
Mi risponderò: ** una giustificazione è una ragione legittima per fare qualcosa. ** Una ragione legittima è quella che serve a uno scopo legittimo. ** La mobilità è un obiettivo legittimo **, quindi lo "spoofing" (non proprio spoofing in realtà, poiché questo è davvero il nostro indirizzo IP) per la mobilità ** è una ragione legittima **. IOW rende legittimo lo "IP spoofing". ** Il fatto che la mobilità possa essere svolta con altri mezzi non è in alcun modo rilevante poiché cerchiamo di determinare se lo "spoofing" è legittimo. **
@curiousguy - ancora una volta: per favore astieniti dall'essere deliberatamente polemico o offensivo. Se continui, verranno applicate varie penalità, inclusi i timeout.
@RoryAlsop Stavo solo spiegando il mio ragionamento. Ti assicuro che non sono "deliberatamente offensivo", ma cerco "deliberatamente" di portare argomenti. Ultimamente * altri * mi hanno inviato commenti offensivi e io ho ** provato ** a rispondere con calma, ma è difficile trovare il tono giusto.
Va bene - in generale ciò che le mod cercano di fare si limita a sbarazzarsi di commenti o frammenti di commenti che sembrano deliberatamente trolling o polemici, o sono offensivi, quindi vedrai che ho modificato e cancellato selettivamente commenti in questo e in altri commenti discussioni. Fondamentalmente, i commenti in Stack Exchange non sono un luogo in cui conversare, sono solo per chiarimenti. Tutte le conversazioni dovrebbero essere tenute in chat
lew
2011-01-14 06:39:14 UTC
view on stackexchange narkive permalink

Un possibile scenario di utilizzo è un ambiente di filtraggio Internet aziendale che non è configurato in linea (ovvero tra Internet e gli utenti) ma monitora il traffico fuori da uno SPAN / TAP di rete.

In questo scenario, quando un l'utente visita un sito che l'ambiente di filtro Web ha elencato in un elenco di blocco, l'applicazione di filtro Web può falsificare l'IP di origine del server Web e inviare un pacchetto di ripristino TCP al client, al server Web o a entrambi per interrompere la connessione.

I prodotti di filtraggio web Websense possono funzionare in questo modo, ad esempio.

Oh. È piuttosto brutto. Vedo persone che si aggiornano costantemente e sono frustrate dal motivo per cui Internet non funziona.
In genere blocchereste solo determinati siti, altrimenti blocchereste completamente l'accesso al web per quegli utenti su un firewall / router. La maggior parte dei prodotti di filtraggio web pubblicherà anche una pagina di blocco, quindi l'utente riceve un feedback. Inoltre, se invia solo l'RST all'utente, dovresti essere in grado di rilasciare quei pacchetti utilizzando un firewall basato su host che può aggirare il blocco.


ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 2.0 con cui è distribuito.
Loading...