Un proxy inverso di fronte al server Web migliorerà la sicurezza?

Un professionista della sicurezza di terze parti consiglia di eseguire un proxy inverso di fronte al server Web (tutti ospitati nella DMZ) come misura di sicurezza delle migliori pratiche.

So che questa è un'architettura tipica raccomandata in quanto fornisce un altro livello di sicurezza davanti a un'applicazione web per prevenire gli hacker.

Tuttavia, poiché un proxy inverso sta spostando allegramente HTTP avanti e indietro tra l'utente e il server Web interno, non fornirà alcuna misura di prevenzione dell'hacking sul server Web stesso. In altre parole, se l'app Web presenta una falla nella sicurezza, il proxy non fornirà una quantità significativa di sicurezza.

E dato che il rischio di un attacco a un'applicazione web è molto più alto di quello di un attacco al proxy, c'è davvero molto guadagnato aggiungendo una casella aggiuntiva nel mezzo? Non utilizzeremmo nessuna delle funzionalità di memorizzazione nella cache di un proxy inverso, ma solo uno strumento stupido per spostare i pacchetti avanti e indietro.

C'è qualcos'altro che mi manca qui? L'ispezione dei pacchetti HTTP con proxy inverso è diventata così buona da poter rilevare attacchi significativi senza importanti colli di bottiglia delle prestazioni, o è solo un altro esempio di Security Theater?

Il proxy inverso è MS ISA prima.

Apache ha mod_security, che rileverà attacchi di sicurezza comuni. C'è anche mod_cband, che può limitare la larghezza di banda utilizzata. Non sarei sorpreso se l'ISA avesse qualcosa di simile. Senza qualcosa che stia effettivamente effettuando controlli sul traffico HTTP mentre passa attraverso il proxy, è tutto un po 'inutile dal punto di vista della sicurezza.

Ciò che ti darà un proxy inverso è il bilanciamento del carico, il failover, la memorizzazione nella cache, SSL e lo scaricamento dei file, lasciando che i tuoi server web facciano quello che sanno fare: servire HTML.

ISA Server è in grado di cercare e prevenire vari exploit HTTP e impedire loro di accedere al server Web. Sebbene la maggior parte dei server HTTP moderni non sia più sfruttabile da questo, ha anche il vantaggio di non inviare questo traffico al server web.

Inoltre, ISA può semplificare l'esecuzione di operazioni quali l'aggiunta dell'accelerazione SSL e la pre-autorizzazione degli utenti a vari URL. Può persino fungere da bilanciamento del carico per te, in modo da poter aggiungere facilmente più server Web senza utilizzare un bilanciamento del carico hardware separato.

Assicurati di prendere i pro che questa persona sta dando all'ISA e di ponderarlo rispetto a quanto sovraccarico aggiuntivo costerà per gestire ed eseguire l'ISA rispetto ai vantaggi.

Un proxy inverso di fronte al server Web migliorerà la sicurezza?

Un proxy inverso ti fornisce un paio di cose che potrebbero rendere il tuo server più sicuro.

• Un luogo per monitorare e registrare ciò che sta accadendo separato dal server Web
• Un posto per filtrare o firewall separato dal tuo server web se sai che alcune aree del tuo sistema sono vulnerabili. A seconda del proxy, potresti essere in grado di filtrare a livello di applicazione.
• Un altro posto per implementare ACL e regole se non puoi essere abbastanza espressivo per qualche motivo sul tuo server web.
• Uno stack di rete separato che non sarà vulnerabile allo stesso modo del tuo server web. Ciò è particolarmente vero se il proxy proviene da un altro fornitore.
  • L'uso del setup di Apache come proxy davanti al server Apache probabilmente non è utile quanto qualcosa come Squid davanti ad Apache.

Un proxy inverso senza filtro non ti protegge automaticamente da tutto, ma se il sistema che devi proteggere ha un valore elevato, l'aggiunta di un proxy inverso può valere i costi di supporto e prestazioni.

Potrebbe proteggere il tuo server delle applicazioni da attacchi basati su richieste HTTP errate ... Soprattutto se è possibile sul proxy inverso (e non sul server delle applicazioni) configurare esattamente l'aspetto di una buona richiesta e non consentire il superamento di richieste errate. Se devi dire come appaiono le cattive richieste, sarà quasi sicuramente inutile. In altre parole, potrebbe proteggere dagli attacchi di overflow del buffer, ma non dall'iniezione SQL.

Principalmente, sembra un teatro della sicurezza. Hai assunto un consulente per la sicurezza e devono dirti qualcosa da fare per migliorare la tua sicurezza. È abbastanza improbabile che un attaccante possa mai entrare nel proxy inverso e se semplicemente lo bypassano, possono sempre biasimarti; quindi è una raccomandazione sicura.

Fondamentalmente, i proxy inversi nasconderanno la tua infrastruttura dal mondo. Quindi è principalmente un caso di sicurezza per oscurità, a meno che il tuo server web sia davvero ingestibile e non garantito.

Può anche proteggere i tuoi server web da una sorta di DOS (denial of service distribuito), specialmente se il tuo sito web è "pesante", fungendo quindi da strato di cache.

Ha anche dei trucchi: nasconderà alla tua applicazione il vero IP del cliente. Ti farà consumare più potenza del server e aggiungere uno strato di cose che possono rompersi. Ricorda che il proxy inverso dovrà gestire più connessioni (in genere due volte di più: connessioni ai clienti e connessioni al tuo server Web).

Alla fine della giornata, un proxy inverso non ti risparmierà comunque di avere un sito Web sicuro.

Penso che Zoredache abbia dato un'ottima risposta ai vantaggi che può offrire un proxy inverso. Ho usato Pound che è un proxy inverso, bilanciamento del carico e frontend HTTPS.

http://www.apsis.ch/pound/

Un vantaggio di cui non credo che nessun altro abbia parlato è il fatto che non è necessario aprire porte / IP esterne attraverso il firewall esterno. Un buon sistema di proxy inverso avvierà la comunicazione dall'interno della rete al server nella DMZ proteggendo le reti dagli attacchi diretti. Questo, tuttavia e come altri hanno già detto, non ti proteggerà da un'applicazione scritta male.