Correzione di una vulnerabilità OpenSSL al firewall

Question

Correzione di una vulnerabilità OpenSSL al firewall

#1 da (4 voti)

2

Oggi abbiamo fatto un test di Qualys su due dei nostri URL. Gli URL sono di due applicazioni simili (stesse versioni) ospitate su server identici situati in due diversi datacenter. Il test ha restituito "A-" per uno e "F" per l'altro. La ragione per la classificazione "F" è stata data come:

This server is vulnerable to the OpenSSL Padding Oracle vulnerability (CVE-2016-2107) and insecure. Grade set to F.

Tuttavia, la versione di OpenSSL che abbiamo su entrambi i server è vecchia e identica:

[user@alpha01 ~]$ rpm -qa | grep openssl
openssl-1.0.1e-30.el6_6.4.x86_64

Perché il test Qualys non identifica la vulnerabilità sul server che ha dato "A-" sebbene stia eseguendo una versione vulnerabile di OpenSSL come l'altra? È OpenSSL Padding vulnerabilità Oracle qualcosa che può essere risolto a livello di firewall? Sospetto che il firewall sul server che ha ricevuto il 'A-' abbia avuto successo nel filtrare il pacchetto che stava tentando di testare questa vulnerabilità. Ho ragione? È qualcosa che può essere risolto a livello di firewall? (Poiché entrambi i server Web si trovano in diversi data center e dietro diversi firewall)

openssl firewalls

posta Sree 13.03.2017 - 13:17

fonte

1 risposta

Leggi altre domande sui tag openssl firewalls

Vulnerabilità di injection URL Come proteggere l'autenticazione JWT REST dall'accettare le chiamate dal browser?

score 4 · Accepted Answer

Is OpenSSL Padding Oracle vulnerability something that can be fixed at the firewall level? I suspect the firewall at the server that received the 'A-' was successful in filtering out the packet that was trying to test this vulnerability. Am I right? Is this something that can be fixed at the firewall level?

No. I protocolli SSL / TLS hanno protezioni anti-manomissione; se, ad esempio, il firewall dovesse alterare l'handshake, la stretta di mano fallirebbe perché entrambe le parti convalidano che ciò che hanno inviato è ciò che viene visto dall'altro lato.

Altre configurazioni potrebbero proteggerti. Se disponevi di uno scaricatore SSL o di un proxy man-in-the-middle, qualcosa che ha chiuso e riaperto le connessioni in modo da avere le connessioni # 1 e # 2:

[Server] < --- 1 --- > [Proxy] < --- 2 --- > [Scanner]

Quindi lo farebbe, perché la libreria SSL vulnerabile sul server non viene toccata dallo scanner.

However, the version of OpenSSL we have on both the servers are old and identical:
[user@alpha01 ~]$ rpm -qa | grep openssl
openssl-1.0.1e-30.el6_6.4.x86_64

E vecchio. Quella versione è stata sostituita da OpenSSL-1.0.1e-48.el6_8.4.x86_64.rpm . Consiglierei di aggiornarlo in entrambi i posti e vedere se questo lo fa andare via. Riavvia i tuoi servizi dopo l'aggiornamento, naturalmente.

Si noti che non ho davvero affrontato la questione radice di "Perché due server con le stesse librerie danno risultati diversi." Questo perché non ci sono abbastanza informazioni da dire. I daemon del server sono uguali su entrambi gli host? Si potrebbe usare diverse librerie SSL? Lo scanner ha utilizzato lo stesso livello di test contro entrambi? Quante volte hai scansionato ogni host? I risultati sono coerenti?

Con tutto ciò che è sconosciuto, e dato che stai eseguendo una versione deprecata di OpenSSL, la mia raccomandazione è di applicare patch e test di nuovo.