Proxy HTTP vs bump-in-wire

Con il proxy HTTP, i sistemi utente possono avere indirizzi privati locali (ad es. indirizzi nelle reti 10.0.0.0/8 o 192.168.0.0/16) poiché, a livello TCP / IP, questi sistemi comunicano solo con il proxy, non Internet in generale. Con la casella "bump-in-the-wire", i sistemi utente devono essere in grado di contattare siti esterni arbitrari più o meno direttamente, il che implica IP pubblico (costoso!) O NAT (che può avere problemi di ridimensionamento a migliaia di locali gli utenti).

La casella di bump-in-the-wire ha anche bisogno di intercettare il traffico in entrata e in uscita e, in quanto tale, può essere complicato per il retrofit in un'architettura esistente. Il proxy HTTP, d'altra parte, è un host ordinario, per quanto riguarda i router.

Ai fini del monitoraggio degli utenti su una rete aziendale, la differenza tra sniffing on-the-wire / intercettazione e proxy è piccola. In effetti, una casella on-the-wire è una scelta superiore per molti aspetti, se tutto il traffico è forzato su di esso, in quanto vedrà il traffico su tutte le porte.

Tuttavia, i proxy non sono installati solo negli ambienti aziendali per spiare e bloccare i propri utenti. Il livello di astrazione che forniscono di richiedere il traffico HTTP / HTTPS (di cui è probabilmente la maggioranza) è sicuramente una buona pratica per aumentare la sicurezza della rete aziendale.

Anche se da solo, un proxy non è il punto di forza della sicurezza sulla tua rete, non è certamente una soluzione da ignorare perché "non fa molto". Supponendo che una rete dominata da Windows, l'impostazione di criteri di gruppo sulla rete per richiedere ai client di connettersi al proxy aziendale con le credenziali di Active Directory è una mitigazione straordinariamente semplice. Ciò impedisce a Mr.BadGuy di entrare a far parte della tua rete e (a) annusare credenziali collegati a Internet che possono essere utilizzati per l'elevazione e (b) estrapolare i dati aziendali dalla tua rete senza nemmeno un account.

Un proxy in una rete ben progettata può rivelarsi una soluzione elegante e in realtà, in un ambiente aziendale, non dovrebbe essere concesso molto (se non nessuno) oltre HTTP / HTTPS in uscita. Mentre una soluzione on-the-wire ti dà un sacco di energia, comporta anche un sacco di rischi. Quanto capitale otterrebbe un attaccante per irrompere nella tua casella on-the-wire?

Penso che sia una questione di scala del traffico e infrastruttura di rete attualmente in atto. Se si desidera solo il proxy del traffico HTTP, non ha senso inserirlo come un bump nel wire (un proxy trasparente) in modo tale che tutto debba essere separato dall'interruttore. Ciò significa che è necessario (addizionale) marcia L4 per spingere il traffico HTTP al proxy trasparente, mentre un proxy esplicito non richiede la commutazione aggiuntiva.

Durante la lettura di The Tangled Web , ho riscontrato un problema con un proxy trasparente che memorizza nella cache il contenuto per risparmiare larghezza di banda:

"L'approccio adottato dai proxy trasparenti è insolitamente pericoloso: qualsiasi tale proxy può guardare l'IP di destinazione e l'intestazione Host inviata nella connessione intercettata, ma non ha modo di immediatamente dicendo se l'IP di destinazione è realmente associato al nome del server specificato. A meno che non sia necessaria una ricerca e una correlazione aggiuntive eseguito, clienti e server co-cospiratori possono avere una giornata campale con questo comportamento Senza questi controlli aggiuntivi, l'aggressore semplicemente ha bisogno di connettersi al proprio server di casa e inviare un messaggio fuorviante Host: www.google.com per avere la risposta memorizzata nella cache per tutti altri utenti come se provenissero genuinamente da www.google.com . "

I proxy HTTP sono limitati a HTTP e in genere cercano solo il traffico sulla porta 80. Un utente intelligente potrebbe facilmente ignorare il proxy HTTP per accedere a Internet comunicando su un'altra porta.

Raccomando l'approccio bump-in-the-wire fintanto che la soluzione che si sta distribuendo monitora tutte le porte 65K +. In altre parole, nessun utente sarebbe in grado di bypassare perché tutte le porte sono monitorate. Naturalmente, le tue politiche dovrebbero trarre vantaggio da questa capacità. Questo è molto facile da installare perché non vengono utilizzati indirizzi IP. Pertanto non è necessaria alcuna riconfigurazione di rete. Ovviamente, questo approccio presuppone che altri dispositivi forniscano funzionalità firewall / NAT.

Inoltre, dovresti pensare a come il dispositivo bump-in-the-wire fallisce. Se fallisce, l'accesso a Internet è bloccato per tutti. È possibile utilizzare un interruttore di bypass se questo non è accettabile. Ovviamente, puoi implementare un paio di appliance con alta disponibilità / failover automatico.

Un proxy può offrire una progettazione di rete di difesa più approfondita e più flessibile. Ad esempio, tutto il traffico HTTP / HTTPS / streaming-contenuto che non passa attraverso il proxy può essere identificato e ucciso da un firewall moderno indipendentemente dalla porta su cui viene eseguito (o consentito solo se si tratta di un host noto che esegue un'applicazione nota per il proxy ignaro) . Inoltre, utilizzando un set di proxy e uno script .pac, è possibile separare diversi tipi di traffico Web: gli utenti desktop possono essere inviati a un proxy di caching su una connessione Internet, il server critico o il traffico della workstation possono uscire da un altro e un traffico di applicazioni Web verso una rete fidata (dove il proxy è configurato per proteggere la rete fidata da utenti non autorizzati) su un terzo.

Questo può essere ottenuto con il filtraggio in modalità trasparente con alcuni intelligenti routing, firewall e configurazione dello switch di livello 3, ma in alcune situazioni sarà molto più semplice e affidabile gestirlo con un set di proxy.

Ho paura che non ci sia una soluzione facile. Una delle cause principali è che un utente può trovare facilmente nel sito Web un nuovo nuovi proxy ogni giorno e possono usare gli indirizzi IP per bypassare il tuo proxy HTTP o il tuo bump-in-the-wire.

L'approccio migliore è quello che filtra per contenuto, non per destinazione. Potrebbe essere bypassato comunque, ma per meno casi ed è difficile.