Best practice documentate per l'implementazione del proxy inverso

Question

Best practice documentate per l'implementazione del proxy inverso

#1 da (10 voti)

8

Sto cercando una documentazione sulle migliori pratiche per l'implementazione di un proxy inverso.

Dobbiamo consentire a un database interno / server web di accedere in ingresso al mondo esterno e stiamo cercando di determinare il metodo più efficiente e sicuro per farlo.

Abbiamo già un server Red Hat 2 che esegue una configurazione Apache con mod proxy, ma vogliamo dare un'occhiata alle best practice odierne (dato che questo server è antico).

Ho cercato su Google un bel po 'e non sono ancora riuscito a trovare niente di meno che un consiglio estremamente generale relativo alle best practice di sicurezza ordinarie.

Apprezzerei molto qualsiasi cosa tu possa fornire.

Grazie! Erik

proxy http-proxy

posta Irongrave 09.01.2014 - 17:44

fonte

1 risposta

Leggi altre domande sui tag proxy http-proxy

Come utilizzare la crittografia su un sito che utilizza solo un indirizzo IP, nessun nome di dominio? Quanto è strong visualCaptcha?

score 10 · Answer 1

NIST SP 800-44 Linee guida per la protezione dei server Web pubblici è un buon punto di partenza, anche se non è una bacchetta magica (ed ora ha alcuni anni).

Nella mia esperienza alcuni dei requisiti e delle mitigazioni più importanti, in un ordine non particolare, sono:

Assicurarsi che i server proxy, server Web back-end (e DB) non possano stabilire connessioni dirette in uscita (Internet) (inclusi DNS e SMTP, e in particolare HTTP). Ciò significa (forward) proxy / relay per l'accesso in uscita richiesto, se necessario.
Assicurati che il tuo logging sia utile (§ 9.1 in precedenza), e coerente . Potresti avere registri da più dispositivi (router, firewall / IPS / WAF, proxy, server web / app, server DB). Se non riesci a collegare in modo rapido, affidabile e deterministico i record su ogni dispositivo, stai sbagliando . Ciò significa NTP e la registrazione di tutti o alcuni: PID, TID, ID di sessione, porte, intestazioni, cookie, nomi utente, indirizzi IP e forse più (e potrebbe significare che alcuni registri contengono informazioni riservate).
Comprendi i protocolli e prendi decisioni consapevoli e consapevoli: compresa la scelta della versione di cipher / TLS, le dimensioni dell'intestazione HTTP, le lunghezze degli URL, i cookie. I limiti dovrebbero essere implementati sul proxy inverso. Se stai eseguendo la migrazione a un'architettura a livelli, assicurati che il team di sviluppo si trovi nel ciclo in modo che i problemi vengano rilevati il prima possibile.
Eseguire scansioni di vulnerabilità dall'esterno o chiedere a qualcuno di farlo per te. Assicurati di conoscere il tuo impronta e che i rapporti evidenziano i delta, così come il teorico TLS SNAFU du-jour.
Comprendi le modalità di errore. Inviando agli utenti un valore predefinito "HTTP 500 - le ruote si sono staccate" quando hai problemi di carico o stabilità è sciatto
Monitoraggio, metriche e grafici: avere dati storici e normali è inestimabile quando si esaminano le anomalie e per la pianificazione della capacità.
Sintonizzazione: dal tempo del TCP - attendi per ascoltare il backlog ai cookie SYN, ancora una volta devi prendere decisioni consapevoli e consapevoli.
Segui le linee guida per l'hardening del sistema operativo di base, considera l'uso di chroot / jail, IDS basato su host e altre misure, se disponibili.