Server fisici con Hyper-V: vanno in dominio o no?

Avevo lanciato un sondaggio (link) a fine articolo. La domanda era questa:

“Prendiamo due server fisici con Hyper-v a bordo come virtualizzatore. Per motivi di Sicurezza i due server:“

Vanno in dominio 21%

Non vanno in dominio 79%

Pensavo inizialmente di rivelare la risposta corretta con un semplice commento ma il risultato del sondaggio mi ha completamente spiazzato e alla fine ho deciso di scrivere un articolo.

La risposta andata per la maggiore è “non vanno in dominio”.

Beh: è la risposta sbagliata. Non lo dico io, non lo dice chatgpt, che a seconda di come gli chiedi le cose ti da una versione e subito dopo il contrario della stessa, lo dice Microsoft e lo dice in base ad argomentazioni precise e molto valide.

Prima di iniziare chiedo a chi legge di fare lo sforzo di non voler a tutti i costi sostenere la propria teoria, ma di comprendere le ragioni per le quali un server fisico Hyper-v, fuori dominio, non è quasi mai la scelta corretta. Inoltre, questo evidenzia un fatto ancora più importante: se una cosa è sempre stata fatta così e la maggior parte delle persone dice così, non è detto che questa sia la cosa corretta.

Ora, partiamo dalla probabile spiegazione con la quale il 79% di persone ha risposto che i server hyper-v andrebbero fuori dominio: per generiche ragioni di sicurezza in modo che, in caso di attacco sia più complesso per un attaccante compromettere i server fisici senza trovare in AD le credenziali. Beh, sappiate che i server fuori dominio sono invece meno sicuri per molte ragioni.

Innanzitutto, se partiamo dal primo livello di sicurezza, i server fisici devono essere segmentati in una vlan separata di management indipendente, ma questo lo si fa in qualsiasi caso, dominio o no.

Da qui in giù invece, ci sono diverse considerazioni da fare relative al dominio. Molti, anzi quasi tutti, non considerano mai l’organizzazione di Active directory a TIER Model, ovvero la suddivisione logica delle utenze e degli accessi amministrativi, a risorse di dominio: credenziali dedicate per l’accesso ai server fisici sono d’obbligo, così come l’applicazione di policy che impediscono l’accesso ad ogni altra utenza di dominio (domain admin compresi) agli stessi server.

Le credenziali di amministratore locale: se in dominio, potrete pensare di far gestire le credenziali amministrative locali a Microsoft Lasp in modo che la password venga creata e gestita esclusivamente da Active directory (rinnovata automaticamente ogni tot giorni con criteri di sicurezza specifici e che non è disponibile sui server stessi). Se siete fuori dominio questa password è presente sulle macchine e nel 99% dei casi non verrà MAI PIU’ resettata.

Addirittura, mettendoli in dominio, potreste pensare di non gestire i server fisici con le sole credenziali locali gestite da LAPS rendendo così ancora più ristretto l’accesso ai server.

A questo punto sento le voci di chi sta dicendo: “eh Francesco ma allora è la stessa cosa che lasciarli fuori dominio..”

Eh, no ragazzi non lo è, perché lasciando i server fuori dominio avreste ulteriori Insicurezze che elenco qui sotto:

- Se non mettete i server in dominio non avrete la possibilità di gestirli via Group policy Object

- Vi perdereste la gestione semplificata dei certificati, dei ruoli e degli aggiornamenti

- In caso di cluster failover è richiesto per sicurezza che i server siano membri di dominio tanto che il Failover Cluster Manager usa active directory per gestire i nodi e le risorse. Se configurate un cluster e utilizzerete Active directory, verrà sfruttato Kerberos che è di gran lunga il protocollo (e insieme di servizi) più sicuro tra quelli disponibili per lo scopo

- In caso di VM Replica, dovreste gestire il tutto con certificati (solitamente autogenerati) e non con Kerberos

- non è possibile usare deleghe basate su account di dominio o autorizzazioni granulari

- è più difficile revocare o aggiornare i privilegi da remoto senza che avvengano interazioni dirette con i server

- tutto si basa su account locali, che non sono scalabili né tracciabili in ambienti medio-grandi

- Se perdi l’accesso all’account locale amministrativo, non puoi più accedere al server (senza interventi esterni)

Volete però sapere il vantaggio (o svantaggio) per eccellenza?

Se gestite server windows fuori dominio e vi connettete alle macchine, ad esempio via rdp, incorrerete in maggiori rischi per la sicurezza, legati soprattutto ai processi di autenticazione.

In questo scenario:

- Viene utilizzato NTLM come protocollo di autenticazione, meno sicuro rispetto a Kerberos

- NTLM è vulnerabile a attacchi MITM, Replay e Pass-the-Hash

- Viene usato CredSSP in modalità meno sicura, senza mutua autenticazione affidabile

- I certificati TLS utilizzati per la cifratura sono, nella quasi totalità dei casi, autofirmati e non validabili, compromettendo l’integrità della connessione.

Quindi, per concludere questo papiro possiamo affermare che, tra le altre cose:

· verranno utilizzati meccanismi di autenticazione più deboli

· si verificherà l’impossibilità di applicare policy centralizzate

· ci sarà una maggiore esposizione a vulnerabilità e attacchi

· incorrerete nella gestione locale di credenziali statiche e difficilmente tracciabili

Replicare il livello di sicurezza e gestione ottenibile con server integrati in Active Directory è non solo più complicato, ma anche molto meno efficace

Quindi, perché fare il triplo del lavoro per avere una situazione meno sicura e più esposta a rischi?

Alla prossima.

Francesco Guiducci – BitArmor S.r.l Se hai paura del caos non sei pronto per la realtà

https://www.linkedin.com/posts/francesco-guiducci-47178071_la-risposta-%C3%A8-una-solamente-senza-se-e-senza-activity-7342616156379213825-MAfn?utm_source=social_share_send&utm_medium=member_desktop_web&rcm=ACoAAA897pUBJy12Pe09H99kUT1vvUuzmXGQyNo