Implementazioni open source o comuni per la sicurezza delle applicazioni Web del proxy inverso

2

Mi rendo conto che già una domanda simile a questa , ma questo è un po 'di follow-up.

Capisco che un server proxy inverso di per sé non sia molto utile come misura di sicurezza per le app Web perché semplicemente "nasconde" il server dietro di esso, proteggendolo dalle impronte digitali, DDoS possibilmente, yada yada. Tuttavia, ritengo che l'implementazione di say snort + squid potrebbe portare a qualche livello di sicurezza a livello di applicazione perché è possibile analizzare il traffico per schemi di attacco comuni. Ma non ho visto molte informazioni in rete su quali prodotti, progetti open source o anche solo ricette per questo tipo di sistema sono disponibili.

La motivazione di questa domanda è che io sostengo un'applicazione legacy OLD basata su una versione pesantemente modificata, non sicura e non aggiornabile di Apache2. NON POSSO Mettere semplicemente mod_security2 nel conf, non funzionerà (non riesco a ottenere i sorgenti di questa vecchia distribuzione incasinata di apache per compilare mod_security2). Quindi, pensavo che la prossima cosa migliore sarebbe stata implementare un tipo di proxy inverso, dal momento che non solo questo poteva risolvere il mio problema immediato per questa app legacy, ma anche se impostato correttamente potrei vederlo essere usato per future app come bene - sicurezza delle app Web centrale.

La mia modalità di pensare è errata? Se non è del tutto fuori base, ci devono essere alcune soluzioni, prodotti, progetti, ricette, ecc. Esistenti. Squid + sniff tutto ciò di cui ho bisogno?

EDIT: E come funziona tutto questo quando ho bisogno di farlo anche con traffico crittografato?

    
posta tacos_tacos_tacos 24.09.2012 - 22:54
fonte

1 risposta

3

L'uso di mod_security come proxy inverso è comune , specialmente nel mondo IIS in cui solo recentemente è disponibile un WAF gratuito. Apache che gira come proxy inverso gestirà gli handshake SSL, quindi non sarà un problema.

Tuttavia sembra che tu abbia un MOLTO PROBLEMA PIÙ GRANDE nelle tue mani. Se non riesci ad aggiornare Apache, sei completamente e totalmente fottuto. Ti garantisco che esistono exploit disponibili pubblicamente per il tuo sistema. Ci sono nuovi sistemi di sicurezza disponibili per Linux come AppArmor e SELinux, non avere questi è un errore fatale.

Non sono sicuro del motivo per cui pensi che sia ok per avere un sistema estremamente vecchio e che mettere un cerotto su di esso è un comportamento accettabile. Se un esperto di sicurezza vede questo, farà dei mattoni. Un WAF non è in alcun modo in forma o costituisce un sostituto per la risoluzione delle vulnerabilità note nel tuo sistema (punto). Un WAF è solo un altro livello e devi pianificare un fallimento. (E un WAF sarà il primo a cadere perché di solito è il più debole.)

    
risposta data 25.09.2012 - 03:30
fonte

Leggi altre domande sui tag