In che modo Windows / IIS mantiene protetto un certificato o non dovrei mai eseguire Apache Webserver su un server Windows?

Question

In che modo Windows / IIS mantiene protetto un certificato o non dovrei mai eseguire Apache Webserver su un server Windows?

#1 da (14 voti)

7

Se seguo il ragionamento di un collega, sembra che non dovresti mai eseguire Apache Webserver o Tomcat su un server Windows se vuoi mantenere sicuro il certificato https.

Lasciatemi spiegare prima che questa domanda si evolva in una battaglia tra troll Windows e Linux.

Ad esempio, quando si utilizza Apache Tomcat per un sito Web https, la chiave privata viene archiviata in un keystore. Perché Tomcat sia in grado di utilizzare questo tasto abbiamo tre opzioni:

Non utilizzare la password sul keystore;
La password del keystore deve essere inserita all'avvio del servizio Tomcat;
La password del keystore è impostata in testo normale in un file di configurazione.

L'uso dell'opzione 3 sembra il più praticato. Ma chiunque abbia accesso a questo file e al keystore è in grado di estrarre la chiave privata. Ovviamente il filesystem può proteggere il keystore e il file di configurazione. Sembra che Linux offra più opzioni per separare l'accesso a quei file per processi diversi. Questo ragionamento ha portato alla conclusione che ho iniziato con.

Non ho familiarità con il modo in cui Windows o IIS gestiscono ciò, ma aspetto che funzioni in qualche modo simili sotto il cofano. Il mio problema è che non lo so per certo. In che modo IIS è in grado di utilizzare il certificato in Windows se nessuno inserisce la sua password? O è appena memorizzato nel registro invece di un file di configurazione? E sta impostando una sicurezza del certificato elevata uguale all'opzione 2?

Qualcuno potrebbe spiegarmi come funziona?

Btw. Non sono interessato a HSM. Per ora mi interessa sapere se e come Windows / IIS protegge un certificato o una chiave privata che non usa l'opzione 3.

Ho cercato, ma non ho potuto trovare risposte conclusive. Ho sfogliato 30 pagine taggate con "certificati" e ho utilizzato google. Trovo difficile distillare una risposta definitiva da loro. Qui di seguito cito le fonti che ho trovato di qualche aiuto. Spero davvero che tu possa aiutarmi o indicarmi la giusta fonte.

Sicurezza su stackExchange:

Quanto è sicura la mia chiave privata nel certificato digitale di Windows negozio?
Come dovrei memorizzare le chiavi SSL sul server?
Come memorizzare una chiave RSA privata per un'applicazione?
Quali sono alcune buone pratiche di progettazione per il certificato multipiattaforma stoccaggio?

Microsoft

[Blog TechNet] Cos'è una protezione avanzata per i tasti in Windows?
[TechNet, EFS] Come vengono memorizzate le chiavi private

Vari siti:

[ServerFault] Come gestire una protezione della chiave privata SSL dei server Web (password vs. nessuna password)?
[CodingHorror] Mantenere private le chiavi private
[SecurityInnovation] Come eseguire il test per Key Store non sicuro Vulnerabilità
[RootSecurity] Come esportare certificati "non esportabili" dal Archivio certificati Microsoft
[Symantec] In che modo gli aggressori rubano le chiavi private dai certificati digitali

iis webserver tls certificates

posta Gos Bilgon 19.12.2013 - 20:52

fonte

1 risposta

Leggi altre domande sui tag iis webserver tls certificates

overflow del buffer dello stack nella funzione principale? [chiuso] Come funziona questo attacco javascript?

score 14 · Answer 1

Un'osservazione generica è la seguente: se puoi riavviare la macchina, e il server torna operativo automaticamente, senza ulteriori interventi umani, quindi, per definizione, il contenuto del disco macchina contiene tutto ciò che la macchina deve accedere alla chiave privata. Corrispondentemente, qualcuno che ha accesso completo alla macchina (come "root" su Linux, "Administrator" su Windows) sarà in grado di recuperare anche la chiave privata.

Su Windows, le chiavi private basate su software sono memorizzate in DPAPI . Per rendere la storia breve, la chiave privata è collegata a un account (l'account della macchina per l'archivio "Macchina locale") e la protezione si basa in ultima analisi sulla crittografia utilizzando la password dell'account come chiave. Per un IIS che si avvia automaticamente, la password corrispondente deve essere scritta da qualche parte nelle interiora del sistema. Possono esserci livelli di crittografia e di riferimento indiretto, ma possono essere svelati da chiunque abbia diritti sufficienti. Vedi questa risposta per i suggerimenti su come fare praticamente.

Inoltre, se qualcuno ottiene i privilegi amministrativi sulla macchina live, allora può semplicemente collegarsi al processo del server Web in esecuzione e saccheggiare direttamente il contenuto della RAM, con ReadProcessMemory () .

Quindi qualsiasi protezione sarà, in definitiva, relativa a quanto bene il sistema operativo impedirà agli utenti non autorizzati di ottenere i privilegi di amministratore. Da questo punto di vista, non c'è molta differenza tra Apache / Tomcat e IIS: è possibile memorizzare la chiave privata per Apache in un file e impostare alcuni ACL per rendere questo file leggibile solo dall'utente specifico che eseguirà Apache. Le persone con diritti amministrativi saranno in grado di ignorarlo, ma, come spiegato sopra, possono fare qualsiasi sulla macchina.

Ora ci possono essere sottigliezze quantitative. Giù al nucleo della macchina, c'è il kernel; il codice del kernel, per definizione, è Dio. Può leggere e scrivere tutta la RAM, accedere a tutto l'hardware. Il kernel è anche il gatekeeper che decide chi può fare cosa. Nella vista del kernel, ogni codice applicativo viene eseguito con una serie di privilegi, che descrivono esattamente ciò che il codice può fare. Alcuni privilegi sono equivalenti a Dio, il che significa che un processo che ha quel privilegio può organizzarsi, più o meno direttamente, per ottenere la stessa potenza del kernel. In un sistema Linux tradizionale, qualsiasi processo di root è equivalente a Dio, dato che root può creare e caricare moduli del kernel, cioè codice personalizzato direttamente nel kernel stesso. Per transitività, qualsiasi processo che possa assumere il controllo di un processo con privilegi equivalenti a Dio è egualmente equivalente a Dio.

I processi equivalenti a Dio sono obiettivi succulenti per gli attaccanti. Più questo processo esiste, più è probabile che uno di loro abbia una vulnerabilità sfruttabile che permetterà all'aggressore di raggiungere la divinità. Pertanto, ridurre le dimensioni e la portata del processo equivalente a Dio può aiutare ad aumentare la sicurezza pratica. Ci sarà ancora, nel profondo della macchina, un codice equivalente a Dio (se solo il kernel stesso), ma la messa a punto può aiutare a mantenere quel codice piccolo.

Linux e Windows, per impostazione predefinita, sono approssimativamente equivalenti (un sacco di processi eseguiti come root / account di sistema), ma offrono diversi strumenti per ridurli. Su Linux potresti giocare con chroot e, più genericamente, SELinux . Su Windows puoi fare molta messa a punto e restrizioni con i Criteri di gruppo. In entrambi i casi è abbastanza facile chiuderti, quindi fai attenzione.

Riepilogo: non c'è niente di sbagliato in Apache / Tomcat su Windows. Le protezioni applicate su chiavi private utilizzate da IIS non sono qualitativamente diverse o più forti dei diritti di accesso ai file. Un buon sysadmin raggiungerà un livello di sicurezza simile in entrambi i casi, sulla stessa macchina.

In ogni caso, si consiglia di non consentire a qualsiasi utente non privilegiato di eseguire codice arbitrario su server con dati sensibili. L'esperienza mostra che quando agli attaccanti è concesso di eseguire codice non privilegiato a livello locale, il numero di buchi sfruttabili aumenta drasticamente.