Quando la maggior parte delle persone sente parlare di «WinRM su HTTP», pensa subito che si tratti di un disastro in termini di sicurezza pronto a verificarsi. Dopotutto, per anni ci è stato ripetuto che l’HTTP è pericoloso e l’HTTPS è sicuro.
Ma in realtà, l'uso del protocollo Windows Remote Management (WinRM) presenta alcune sfumature. In molti ambienti, HTTP non è significativamente meno sicuro di HTTPS.
Il malinteso sulla crittografia:
WinRM su HTTP è intrinsecamente insicuro?
L'errore più diffuso è che WinRM invii i dati tramite HTTP in chiaro. Non è così.
Per impostazione predefinita, WinRM utilizza l'autenticazione Kerberos o NT LAN Manager (NTLM) e le chiavi segrete vengono impiegate per crittografare il contenuto del messaggio a livello di applicazione, indipendentemente dal protocollo di trasporto.
In WinRM, HTTP è semplicemente il canale di trasporto; la crittografia e l'autenticazione vengono gestite a livello di applicazione, al di sopra di esso. Un malintenzionato che intercetti il traffico di rete non vedrà né il comando né l'output. Né sarà in grado di effettuare l'autenticazione tramite l'endpoint HTTP di WinRM.
WinRM è stato progettato tenendo conto di questa separazione, il che lo rende fondamentalmente diverso, ad esempio, da un sito web che funziona su HTTP, dove il contenuto è effettivamente in chiaro.
Cosa offre in realtà il protocollo HTTPS?
Il protocollo HTTPS avvolge l'intera connessione nel protocollo Transport Layer Security (TLS), che offre due garanzie aggiuntive:
- crittografia a livello di trasporto
- autenticazione del server basata su certificato
La crittografia a livello di trasporto è in gran parte superflua, vista la crittografia dei messaggi integrata in WinRM.
La convalida del certificato è davvero utile. Offre una maggiore garanzia che si stia comunicando con il dispositivo che si crede, il che aiuta a proteggersi da determinati scenari di attacchi man-in-the-middle (MiTM) su reti non affidabili.
Tuttavia, in una rete interna ben gestita e dotata di adeguati controlli DNS e Active Directory (AD), tali minacce sono già state notevolmente mitigate con altri mezzi.
Quando l'uso di WinRM su HTTP è perfettamente giustificato
In un ambiente collegato al dominio, WinRM su HTTP offre tre elementi fondamentali per una gestione remota sicura:
- Integrità del messaggio
- Crittografia dei messaggi e un
- Un certo grado di autenticazione reciproca se si utilizza Kerberos
Un avvertimento importante: l'autenticazione di base dovrebbe essere sempre disabilitata, come avviene per impostazione predefinita.
L'autenticazione di base invia le credenziali senza alcuna protezione effettiva e rappresenterebbe l'unica vera vulnerabilità di WinRM su HTTP se lasciata abilitata. Assicurati quindi che rimanga disabilitata.
Molti ambienti aziendali consolidati utilizzano WinRM su HTTP internamente senza che ciò comporti un aumento significativo dei rischi. Inoltre, l'onere operativo legato alla gestione dei certificati per HTTPS può effettivamente introdurre dei rischi se gestito in modo inadeguato; certificati scaduti, autorità di certificazione configurate in modo errato e flussi di automazione non funzionanti sono problemi concreti che HTTP evita del tutto.
Quando è consigliabile utilizzare HTTPS? Leggi prima questo articolo
L'HTTPS è la scelta giusta quando si opera su reti non sicure.
Tuttavia, l'implementazione di WinRM su HTTPS senza una corretta configurazione del Channel Binding Token (CBT) potrebbe in realtà comportare un livello di sicurezza inferiore rispetto a quello offerto dal protocollo HTTP.
Il CBT associa la procedura di autenticazione a un canale TLS specifico, impedendo a un malintenzionato di inoltrare le credenziali intercettate per autenticarsi su WinRM per conto dell'utente interessato.
L'uso di HTTPS senza CBT può creare un falso senso di sicurezza. La connessione è crittografata, ma l'autenticazione può comunque essere reindirizzata, il che crea una vulnerabilità critica. Senza CBT, le autenticazioni Kerberos e NTLM su TLS rimangono vulnerabili agli attacchi di reindirizzamento.
Al contrario, WinRM su HTTP non subisce le stesse conseguenze, poiché il traffico è protetto da WinRM tramite le credenziali di autenticazione dell'utente.
Fortunatamente, Windows abilita di default i CBT in modalità «Relaxed», che garantisce protezione nella maggior parte dei casi.
C:>winrm get winrm/config/service/auth
Auth
Basic = false
Kerberos = true
Negotiate = true
Certificate = false
CredSSP = false
CbtHardeningLevel = Relaxed
Tuttavia, la configurazione consigliata consiste nell'impostare esplicitamente i CBT su " Strict".
C:>winrm set winrm/config/service/auth @{CbtHardeningLevel="Strict"}
Ciò garantisce che vengano accettati solo i tentativi di autenticazione correttamente associati al canale TLS, riducendo così in modo efficace la superficie di attacco tramite relay.
Conclusione: fare in modo che l'uso di WinRM su HTTP sia una scelta consapevole
Le decisioni in materia di sicurezza dovrebbero basarsi su modelli di minaccia reali, non su preferenze protocollari automatiche.
In un ambiente di dominio con Kerberos, l'uso di WinRM su HTTP non rappresenta una configurazione azzardata. HTTPS è preferibile su reti non affidabili, ma solo se configurato correttamente. Un'implementazione HTTPS senza che i CBT siano impostati almeno sul livello predefinito "Relaxed" — o, idealmente, su "Strict" — è probabilmente più pericolosa dell'HTTP, poiché induce un falso senso di sicurezza lasciando aperto un vettore critico di inoltro dell'autenticazione.
Cerca di capire come funziona il tuo protocollo di autenticazione. Cerca di capire il livello di affidabilità della tua rete.
