Archivi categoria: Sicurezza

Implementare reti wireless sicure con 802.1x ed EAP-TLS con Windows Server 2016

Facebooktwittergoogle_plusredditlinkedin

Per permettere l’accesso alle nostre reti wireless molto spesso utilizziamo delle chiavi di cifratura WPA2, che rimangono le stesse per diverso tempo, e che spesso vengono anche consegnate ad utenti ospiti delle nostre reti. Chiunque disponga della chiave può quindi accedere alla WLAN e non sempre nelle nostre infrastrutture ci preoccupiamo di cambiarla periodicamente, considerando anche che dovremmo farlo su tutti gli access point e su tutti i client.

Per garantire un metodo più affidabile di autenticazione e autorizzazione, da anni è possibile implementare una struttura di protezione WLAN basata sul protocollo 802.1x, uno standard IEEE per l’autenticazione dell’accesso alla rete che può anche essere utilizzato per la gestione delle chiavi di protezione WPA2. Il suo utilizzo non è limitato alle reti senza fili, ma può essere implementato in numerosi switch di fascia alta nelle reti LAN cablate. Per approfondimenti sul funzionamento del protocollo 802.1x vi rimando alla pagina https://it.wikipedia.org/wiki/IEEE_802.1x

In questo articolo vedremo come implementare l’uso del protocollo 802.1x per le nostre reti wireless (ma analogo ragionamento può essere fatto per le reti cablate) utilizzando un server di autenticazione RADIUS creato con Windows Server 2016 ed EAP-TLS. EAP-TLS offre un processo di autenticazione molto sicuro, che sostituisce le semplici password con certificati digitali lato client e lato server, tramite l’utilizzo di una Certification Authority (PKI), creando di fatto quella che viene chiamata Mutual Authentication.

EAP-TLS con Mutual Authentication è attualmente l’implementazione più sicura per l’accesso alle reti wireless o alle reti cablate. I client autenticano il server RADIUS ed il server RADIUS chiede ai client di autenticarsi, richiedendo loro un certificato digitale.

Pertanto questo tipo di autenticazione, basato su certificati digitali sia computer che utente, permette l’accesso solo a chi possiede il certificato corretto e, nel caso la connessione avvenga tramite rete wireless, subito dopo l’autenticazione viene rilasciata una chiave WPA2 unica per utente (o per computer) ed unica per ogni sessione di connessione!

Per creare una infrastruttura di accesso che supporti questo protocollo affronteremo diversi passaggi:

  1. Creazione della Certification Authority e relativa configurazione
  2. Configurazione dei gruppi di accesso in Active Directory
  3. Creazione del server RADIUS di autenticazione utilizzando il ruolo Network Policy Server (NPS)
  4. Rilascio dei certificati per i client
  5. Configurazione degli Access Point per il supporto all’802.1x
  6. Configurazione dei client per il supporto all’EAP-TLS nelle reti wireless

Figura 1: Schema dell’infrastruttura necessaria all’implementazione del protocollo 802.1 con EAP-TLS

Creazione della Certification Authority (CA)

Per creare una certification authority si utilizza il ruolo Active Directory Certificate Services. Procedete all’installazione del ruolo in una macchina Windows Server.

Figura 2: Installazione del ruolo Active Directory Certificate Services in Windows Server 2016

Aggiungete il Role Services di Certification Authority e di Certification Authority Web Enrollment, che vi darà la possibilità di rilasciare i certificati per i vostri client anche attraverso un’interfaccia web.

Figura 3: Aggiunta dei Role Services per il ruolo di CA

Terminata l’installazione sarà necessario configurare la nostra Certification Authority. Cliccate quindi sul link Configure Active Directory Certificate Services in the destination computer.

Figura 4: Installazione del ruolo completata. È necessario però configurarlo

Dopo aver cliccato sul link si aprirà un wizard di configurazione. Configurare entrambi i Role Services che avete appena installato, come mostrato in figura:

Figura 5: Scelta dei Role Services da configurare

Il primo passaggio consiste nell’indicare se volete creare una CA di tipo Enterprise o Standalone. Nel nostro ambiente di dominio utilizzeremo una CA di tipo Enterprise.

Figura 6: Scelta del tipo di Certification Authority da installare

Poiché si tratta del primo server che installiamo, scegliamo di creare una Root CA. Per chi è poco pratico di Certification Authority e vuole conoscere nel dettaglio le differenze, consiglio la lettura dell’articolo Types of Certification Authorities

Figura 7: Scelta del tipo di Certification Authority da utilizzare

Per poter rilasciare i certificati, la vostra Root CA deve avere una chiave privata. Scegliete di creare una nuova Private Key e proseguite con il wizard.

Figura 8: Creazione della nuova chiave privata per la Root CA

La scelta del provider per la crittografia può avere un impatto determinante per la sicurezza, le performance e la compatibilità dei certificati rilasciati dalla vostra CA. Lasciate le impostazioni predefinite e proseguite nel wizard. Poiché le Cryptographic Options sono molto importanti, vi rimando alla lettura dell’articolo Cryptographic Options for CAs

Figura 9: Scelta del provider per la crittografia

Scegliete il nome della vostra CA, in modo che sia facilmente riconoscibile.

Figura 10: Scelta del nome della Certification Autority

Scegliete il periodo di validità del certificato della Root CA

Figura 11: Scelta del periodo di validità del certificato della Root CA

Specificate dove volete che venga salvato il database ed il file di log della CA

Figura 12: Percorsi di installazione del database del file di log della CA

Confermate tutte le configurazioni che avete inserito nel wizard e cliccate sul pulsante Configure:

Figura 13: Conferma delle configurazioni degli Active Directory Certificate Services

Dopo pochi istanti avrete creato e configurato la vostra Certification Authority!

Figura 14: Creazione della CA completata

Configurazione del Network Policy Service (NPS)

Per implementare la nostra infrastruttura basata su RADIUS e protocollo 802.1x ci serviremo di un server Windows in cui installeremo il ruolo di Network Policy Service (NPS). Indipendentemente dal metodo di autenticazione che utilizzerete per le vostre reti wireless (EAP-TLS, PEAP-TLS oppure PEAP-MS-CHAP v2), sarà obbligatorio installare sul Server NPS un certificato digitale che ne permetta il riconoscimento come server di autenticazione.

Per questo motivo sarà necessario distribuire tramite la nostra CA il certificato corretto, creato dal template RAS and IAS Server. Un certificate template viene utilizzato dalla CA per definire il formato ed il contenuto del certificato, per specificare quale utente o quale computer potranno richiederlo e per definirne tutte le caratteristiche e gli usi. Per maggiori informazioni potete leggere l’articolo Certificate Templates Overview

Aprite quindi la console della Certification Authority e dal nodo Certificate Template fate clic col tasto destro scegliendo New –> Certificate Template to Issue

Figura 15: Scelta del nuovo certificate template da distribuire

Per permettere al vostro server NPS di ottenere il certificato valido per poter essere utilizzato con RADIUS server, aggiungetelo in Active Directory al gruppo RAS and IAS Servers. Il gruppo infatti ha la possibilità, di default, di ottenere il certificato dal template RAS and IAS Server che abbiamo appena distribuito.

Figura 16:Aggiunta del server NPS01 al al gruppo RAS and IAS Servers in Active Directory

Riavviate il server NPS in modo tale che possa ottenere nel proprio token Kerberos il SID del gruppo RAS and IAS Servers e, dopo esservi autenticati, aprite una nuova console MMC, aggiungete lo snap-in dei Certificati Computer e procedete alla richiesta del certificato per il server NPS01, come mostrato in figura:

Figura 17: Richiesta di un nuovo certificato sul server NPS01

Se avrete effettuato correttamente tutte le operazioni, vedrete tra le opzioni disponibili la possibilità di richiedere il certificato dal template RAS and IAS Server.

Figura 18: Richiesta del certificato dal template RAS and IAS Server

Installazione del ruolo di Network Policy and Access Services sul server RADIUS

Procedete all’installazione del ruolo Network Policy and Access Services sul server NPS01, come mostrato nelle due figure:

Figura 19: Aggiunta del ruolo Network Policy and Access Services

Figura 20: Aggiunta del ruolo NPS completata

Lanciate la console del Network Policy Server e dalla scheda Getting Started scegliete dal menù a tendina che volete implementare lo scenario di RADIUS Server for 802.1x Wireless or Wired Connections. Cliccate sul link Configure 802.1x, come mostrato in figura:

Figura 21: Scelta dello lo scenario di RADIUS Server for 802.1x Wireless or Wired Connections nella scheda Getting Started

Partirà un wizard che vi guiderà nella configurazione. Nella prima schermata scegliete lo scenario. Nel nostro caso vogliamo rendere sicura una rete wireless.

Figura 22: Scelta del tipo di connessione per l’802.1x

Nella seconda schermata aggiungere il vostro RADIUS Client, cioè l’Access Point che invierà le richieste di connessione al vostro server NPS. Indicate anche uno Shared Secret, che dovrete successivamente inserire nel pannello di configurazione dell’Access Point.

Figura 23: Aggiunta del RADIUS Client (Wireless Access Point)

Figura 24: Potete aggiungere tutti i RADIUS Client che volete utilizzare nella vostra rete wireless sicura

Nella terza schermata scegliete il metodo di autenticazione. Nel nostro caso utilizzeremo i certificati digitali da installare sui pc client che vogliono accedere alla rete wireless (protetta con 802.1x ed EAP-TLS). Scegliete Microsoft: Smart Card or other certifcate e dal pulsante Configure assicuratevi di selezionare il certificato corretto per il vostro server NPS (cioè il certificato generato dal template RAS and IAS Server della vostra CA):

Figura 25: Scelta del metodo di autenticazione

Nella quarta schermata scegliete il gruppo di utenti o di computer di Active Directory che sarà autorizzato ad accedere alla rete wireless. Io ho aggiunto il gruppo Domain Computers

Figura 26: Scelta del gruppo di Active Directory che sarà autorizzato ad accedere alla rete wireless

Se utilizzate le VLAN nella vostra infrastruttura, sarà necessario effettuare ulteriori configurazioni. Maggiori informazioni sono contenute nell’articolo Configure Network Policies

Figura 27: Configurazioni relative alle VLAN

A questo punto il vostro wizard sarà terminato e verranno create una Connection Request Policy ed una Network Policy, entrambe chiamate Secure Wireless Connections.

Figura 28: Configurazione del server NPS completata

Configurazione dei computer client

Terminata la configurazione del server RADIUS è necessario configurare i client. Come prima operazione ci occuperemo di distribuire i certificati ai client che saranno autorizzati ad accedere alla rete wireless. Per poterlo fare ci serviremo di un template e delle group policy. Per poter distribuire i certificati utilizzando le GPO dovremo creare un template adatto a tale scopo.

Creazione del template per la distribuzione dei certificati ai computer del dominio

Dalla console Certificate Templates duplicate il template chiamato Computer per poterne generare uno nuovo, come mostrato in figura:

Figura 29: Duplicazione del template Computer

Dalle proprietà del nuovo template, provvedete a configurare un nuovo nome, ad indicare una durata per i certificati emessi e ad aggiungere alla scheda Security il gruppo di Computer di Active Directory che potrà richiederne i certificati che verranno da esso generati. Se volete utilizzare le GPO per la distribuzione dei certificati non dimenticatevi di selezionare l’opzione AutoEnroll, come mostrato nelle figure seguenti:

Figura 30: Definizione del nome del nuovo template certificati

Figura 31: Permesso di esportare la chiave privata

Figura 32: Aggiunta del gruppo di Active Directory autorizzato e selezione dell’AutoEnroll

Figura 33: Scelta delle informazioni da inserire nei certificati emessi

Terminata la creazione del template, collegatevi alla console di gestione della Certification Authority e distribuite il nuovo template certificato che avete creato, come mostrato nelle figure seguenti:

Figura 34: Aggiunta del nuovo certificate template alla CA

Figura 35: I due certificate template creati e distribuiti dalla nostra CA

Distribuzione del certificato computer utilizzando le Group Policy

Per distribuire il certificato Computer nel nostro dominio tramite le Group Policy vi basta creare una nuova GPO, collegarla alla OU dove si troveranno i computer autorizzati ad utilizzare la rete wireless e da Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Policies modificare la voce Certificate Services Client – Auto-Enrollment come mostrato in figura:

Figura 36: Auto-Enrollment dei certificati tramite GPO

Tutti i template certificato che saranno configurati per l’Auto-Enrollment per i gruppi di computer di Active Directory verranno distribuiti tramite questo metodo. Nessuno ovviamente vi vieta di installare manualmente i certificati sui vostri computer.

Effettuate un gpupdate sui vostri computer, magari utilizzando la PowerShell Invoke-GPUpdate e assicuratevi che abbiano ricevuto un certificato digitale

Figura 37: Certificati digitali emessi dalla CA e distribuiti tramite Group Policy

Figura 38: Certificato ricevuto dal client tramite la GPO

Configurazione degli Access Point per il supporto all’802.1x

La configurazione dei Wireless Access Point per il supporto all’802.1x varia da modello a modello. In genere trovate la configurazione sotto la voce Wireless
Security, scegliendo WPA2-Enterprise, WPA-Enterprise oppure Open with 802.1X. Nel mio caso ho scelto di utilizzare una chiave WPA2, che verrà data al computer solo dopo che sarà avvenuta l’autenticazione. Ho ovviamente dichiarato qual è il server RADIUS da utilizzare (NPS01) e lo Shared Secret che avevo precedentemente impostato nel wizard di creazione della Network Policy.

Figura 39: Configurazione del Wireless Access Point per l’utilizzo di WPA2-Enterprise

Configurazione dei client per la connessione alla rete wireless

Per configurare manualmente il client a connettersi alla rete protetta con il protocollo 802.1x è necessario effettuare delle operazioni. Spostatevi nel pannello di controllo del vostro client (Io sto usando Windows 10 versione 1709), andate in Network and Sharing Center e scegliete di configurare una connessione manuale verso una rete wireless, come mostrato in figura:

Figura 40: Connessione manuale ad una rete wireless in Windows 10

Inserite il nome della rete wireless a cui volete collegarvi e scegliete come Security type la voce WPA2-Enterprise

Figura 41: Scelta del nome della rete wireless e del metodo di autenticazione

Nel passaggio successivo cliccate sul pulsante Change Connection setting

Figura 42: Modifica delle opzioni della connessione

Spostatevi nella scheda Security e assicuratevi che nel Security type ci sia WPA2-Enterprise, nell’Encryption type ci sia AES e in Authentication method ci sia Microsoft: Smart Card or other certificate. Cliccate sul pulsante Settings per selezionare se volete utilizzare una Smart Card oppure un certificato presente sul computer e controllate di aver selezionato Use Simple Certificate Selection, nel caso sul vostro computer siano installati diversi certificati.

Figura 43: Modifica delle configurazioni di Security per la rete wireless

Cliccando sul pulsante Advanced settings potrete anche forzare come metodo di autenticazione la Computer Authentication, come mostrato in figura:

Figura 44: Opzioni avanzate della scheda Security

Confermate le impostazioni cliccando su OK e provate a collegarvi alla rete wireless. Se tutto sarà stato configurato correttamente vi riuscirete a collegare in pochissimi istanti.

È possibile verificare le configurazioni della rete wireless in qualsiasi momento accedendo al Network and Sharing Center, cliccando sul nome della rete wireless e scegliendo Wireless Properties dalla scheda Wi-Fi status, come mostrato in figura:

Figura 45: Modifica delle configurazioni della rete Wi-Fi

Configurazione dei client per la connessione alla rete wireless tramite Group Policy

Per semplificare la connessione alla rete wireless protetta con 802.1x è possibile anche utilizzare le Group Policy. In effetti la connessione manuale è alquanto impegnativa, non alla portata di tutti gli utenti ed è necessario collegarsi a tutti i pc client per poterla effettuare. Con le GPO, esattamente come abbiamo fatto con i certificati digitali per i computer, l’operazione diventa invece molto semplice.

Create una Group Policy e collegatela alla OU dove si trovano i computer che volete configurare. Spostatevi nel ramo Computer Configuration\Policies\Windows Settings\Security Settings\Wireless Network (IEEE 802.11) Policies e cliccando con il tasto destro scegliete Create a New Wireless Network Policy for Windows Vista and Later Releases, come mostrato in figura:

Figura 46: Creazione di una nuova Wireless Network Policy

Nella scheda che si aprirà, scegliete un nome per la vostra policy e cliccate su Add per aggiungere le configurazioni di una nuova rete wireless di tipo Infrastruttura, come mostrato in figura:

Figura 47: Aggiunta della nuova rete wireless

Nelle proprietà del nuovo profilo della rete wireless che volete aggiungere, inserite il nome dell’SSID della rete e cliccate sul pulsante Add

Figura 48: Aggiunta dell’SSID della rete wireless

Cliccate sulla scheda Security e configuratela con le informazioni visualizzate nella figura seguente:

Figura 49: Configurazione delle Security per la rete wireless

Completate la configurazione cliccando su OK.

Figura 50: Completamento della configurazione

Da questo momento il profilo verrà distribuito attraverso le group policy. Effettuate un gpupdate sui vostri computer client oppure utilizzate la PowerShell Invoke-GPUpdate dal domain controller e assicuratevi che i client possano accedere alla rete Wi-Fi protetta.

Conclusioni

La sicurezza è una condizione determinante per la protezione delle nostre infrastrutture e della nostra produzione. Filtrare l’accesso alle reti wireless o alle reti cablate servendosi del protocollo di autenticazione 802.1x con EAP-TLS certamente incrementa il lavoro da fare ma allo stesso tempo permette di essere sicuri che alle nostre reti possano accedere solo i computer autorizzati.

Meltdown e Spectre: prodotti VMware

Facebooktwittergoogle_plusredditlinkedin

Meltdown e Spectre ono delle vulnerabilità alquanto serie che affliggono la maggior parte dei processori esistenti sul mercato, rendendo quindi potenzialmente attaccabili sistemi come personal computer, server, dispositivi mobile, ma anche molti servizi di tipo cloud. Al momento, l’unico modo per minimizzare l’effeto di questi problemi è aggiornare sia i sistemi operativi che gli eventuali hypervisor. In realtà stanno arrivando anche i primi microcode (aggiornamenti del firmware delle CPU) da parte di alcuni hardware vendor. Per quanto riguarda VMware, si tratta di applicare delle opportune patch a vSphere, sia nella parte ESXi che nella parte […]

The post Meltdown e Spectre: prodotti VMware appeared first on vInfrastructure Blog.

Gestire l’accesso alle macchine virtuali in Microsoft Azure con la funzionalità JIT (Just-in-Time)

Facebooktwittergoogle_plusredditlinkedin

Mai come in questo periodo il tema della sicurezza informatica sta monopolizzando gli articoli e gli avvisi che ci arrivano dai diversi vendor hardware e software e gli attacchi si stanno non solo evolvendo come complessità, ma soprattutto stanno aumentando. Difendersi dagli attacchi è sempre impegnativo e non bisogna mai sottovalutare nulla, ma io sono dell’idea che prevenire sia meglio che curare e quindi nell’approccio alla sicurezza la cosa più importante è ridurre la superficie di attacco.

Avevo già parlato in un precedente articolo di una funzionalità di sicurezza introdotta in Windows Server 2016 e chiamata Just Enough Administration (JEA), che ha come scopo quello di aumentare la sicurezza nella gestione e nella delega dei privilegi in Windows Server. In questo articolo invece vi parlo di una funzionalità di Microsoft Azure, attualmente in PREVIEW e che si chiama Just in time VM Access, che può essere usata per bloccare il traffico in ingresso verso le porte dei protocolli di amministrazione (RDP per Windows oppure SSH per Linux) delle macchine virtuali di Azure, riducendo l’esposizione agli attacchi.

Figura 1: Attivazione della funzionalità di Just in time VM Access in Azure Security Center

Questo tipo di funzionalità non è pero disponibile gratuitamente e fa parte del piano Standard del Centro Sicurezza di Azure (Security Center), che offre la gestione unificata della sicurezza e la protezione avanzata dalle minacce per tutti i workload in esecuzione in Azure, in locale nella propria rete aziendale e in altri cloud. È possibile aggiornare tutta la sottoscrizione di Azure al piano Standard, che viene ereditato da tutte le risorse all’interno della sottoscrizione oppure è possibile aggiornare a un solo gruppo specifico di risorse (Resource Group). Per poterlo fare è sufficiente modificare la Security Policy del Security Center come mostrato in figura:

Figura 2: Modifica delle Security Policy e del Pricing Tier in Azure Security Center

Nel momento in cui attivate la funzionalità di Just in time VM Access, Il Security Center protegge il traffico in ingresso verso le macchine virtuali creando una regola nel Network Security Group (NSG) utilizzato dalle schede di rete della VM, che blocca le porte di gestione. Quando avrete necessità di accedere in modalità amministrativa alla VM, vi basterà richiedere l’accesso e indicare per quanto tempo necessitate di amministrare la macchina. Il Security Center provvederà a modificare le regole sul Netowrk Security Group consentendo il traffico in entrata verso le porte di gestione per il periodo di tempo specificato. Al termine di questo periodo, il Security Center ripristinerà le regole preesistenti.

Attivazione del Just in time VM Access

La prima volta che vorrete usare la funzionalità di Just in time VM Access vi verrà chiesto di attivare (in prova gratuita per i primi 60 giorni) il piano Standard, come mostrato in figura:

Figura 3: Attivazione del Piano Standard per Azure Security Center

Una volta che avrete attivato il piano Standard potrete tornare nella console del Just in time VM access e visualizzare le informazioni per ogni macchina virtuale, divise in 3 categorie:

  • Configured – Macchine virtuali che sono state configurate per supportare l’accesso Just-In-Time. I dati visualizzati sono relativi all’ultima settimana e includono, per ogni macchina virtuale, il numero di richieste approvate, la data dell’ultimo accesso e l’ultimo utente che ha effettuato l’accesso.
  • Recommended – Macchine virtuali che possono supportare l’accesso Just-In-Time, ma che non sono state ancora configurate.
  • No Recommandation – I motivi per cui una macchina virtuale può risultare non raccomandata sono:
    • Network Security Group mancante – La soluzione Just-In-Time richiede la presenza di un gruppo di sicurezza di rete.
    • Macchina virtuale classica – L’accesso Just-in-Time alle macchine virtuali attualmente supporta solo VM distribuite tramite Azure Resource Manager.
    • Endpoint Protection non installato – Il Centro sicurezza di Azure monitora lo stato della protezione antimalware e verifica che nella VM sia installato Endpoint Protection

Figura 4: Macchine virtuali su cui non può essere abilitata il Just in time VM access

Per abilitare la funzionalità è sufficiente selezionare la VM, cliccare sul pulsante Enable JIT on VM e nel blade che si apre cliccare su Save, come mostrato in figura:

Figura 5: Abilitazione della funzionalità di Just in time VM access

Richiedere l’accesso a una macchina virtuale

Per richiedere l’accesso ad una macchina virtuale è sufficiente selezionare la VM nella scheda Configured e cliccare sul pulsante Request Access. Nel blade che verrà aperto definite quale porta aprire, a quali indirizzi IP permettere la connessione, per quanto tempo permettere la connessione. Al termine della scelta dei criteri cliccate sul pulsante Open Ports, come mostrato in figura:

Figura 6: richiesta di apertura delle porte di amministrazione

In qualsiasi momento potete modificare la configurazione dell’accesso JIT alla VM, visualizzarne le proprietà e i log delle attività, come mostrato in figura:

Figura 7: Modifica della configurazione dell’accesso JIT alla VM

È sempre possibile aggiungere altre porte alla configurazione dell’accesso JIT alla VM e per ognuna di loro stabilirne anche la durata, che in ogni caso non potrà superare le 24 ore.

Figura 8: Aggiunta di una nuova regola alla configurazione dell’accesso JIT alla VM

Visualizzando la scheda Networking della macchina virtuale potrete visualizzare quali regole sono state applicate al Network Security Group della VM. Sono state inserire le regole di SecurityCenter-JIT che hanno una priorità più bassa e quindi hanno precedenza rispetto alle altre regole create.

Figura 9: Regole di SecurityCenter-JIT applicate al Network Security Group della VM

Conclusioni

La semplicità con cui è possibile configurare l’accesso Just in Time alle VM di Azure permette di poter ridurre drasticamente la superfice d’attacco verso le VM esposte, come ad esempio le Jump Box con IP pubblico, ed impedisce di fatto tutti gli attacchi verso il Desktop Remoto o verso Secure Shell che cercano di indovinare le credenziali amministrative. Un modo semplice ed efficace per proteggerci e per mitigare gli attacchi di forza bruta aprendo le porte solo durante la connessione per eseguire attività di gestione o manutenzione sulle VM.

Creare un Guarded Fabric con l’Admin-trusted attestation e le Shielded VMs in Windows Server 2016

Facebooktwittergoogle_plusredditlinkedin

Introduzione

Spesso nei Datacenter il ruolo dei diversi amministratori è ben definito e le mansioni sono ben separate: ci sono gli Storage Administrator, i Network Administrator, i Backup Operator e i Virtualiztion-host Administrator. Ognuno di loro ha privilegi limitati quando lavora sui diversi server fisici. Nelle infrastrutture virtuali, in contrasto con quanto appena affermato, può capitare che spesso questi amministratori abbiano privilegi maggiori rispetto a quelli che gli dovrebbero essere permessi.

Scopo di questo articolo è mostrarvi come rendere più sicura l’infrastruttura virtuale e come creare un Guarded Fabric, cioè l’insieme degli host di virtualizzazione Hyper-V ed il loro Host Guardian Service (HGS), che può gestire e far girare macchine virtuali protette (Shielded VM)

Guarded Fabric

Con il rilascio di Windows Server 2016, Microsoft ha introdotto un nuovo modello di sicurezza per la virtualizzazione che è progettato per proteggere gli Hosts e le loro VM. Poiché una VM è un insieme di file, è necessario proteggerla da tutti quegli attacchi che possono avvenire via rete, sullo storage o mentre vengono salvate durante il backup. Questa è una necessità che prescinde dalla piattaforma di virtualizzazione utilizzata, sia che si tratti di Hyper-V, VMware o altre tecnologie di virtualizzazione. Se una macchina dovesse essere spostata fuori dall’azienda (sia accidentalmente che intenzionalmente), questa VM potrebbe essere eseguita in qualsiasi altro sistema non aziendale e quindi si potrebbe avere accesso ai dati contenuti nella VM.

Per proteggersi dalla possibilità che l’infrastruttura (Fabric) possa essere compromessa e si possa accedere ai file delle VM, Windows Server 2016 ha introdotto le Hyper-V Shielded VM, macchine virtuali (Generation 2) che hanno un virtual TPM (Trusted Platform Module), cifrate utilizzando Bitlocker Drive Encryption e che possono essere eseguite solo su alcuni Host di virtualizzazione approvati all’interno del Fabric.

Un Guarded Fabric è formato da un Host Guardian Service (HGS), che generalmente è un cluster a tre nodi, uno o più guarded hosts e una serie di Shielded VM. Vi consiglio prima di cominciare illaboratorio di dare un’occhiata all’articolo https://blogs.technet.microsoft.com/datacentersecurity/2017/03/14/shielded-vms-a-conceptual-review-of-the-components-and-steps-necessary-to-deploy-a-guarded-fabric/

Attestation Modes nei Guarded Fabric

L’Host Guardian Service (HGS) supporta due tipi differenti di deployment (attestation modes) di un guarded fabric: TPM-Trusted Attestation (Hardware based) e Admin-Trusted Attestation (Active Directory based). Il TPM-Trusted Attestation è la modalità che offre la protezione migliore, ma richiede che gli Host Hyper-V utilizzino UEFI 2.3.1 e TPM 2.0. L’Admin-Trusted Attestation è pensato per supportare gli Host che non hanno un TPM 2.0. I Guarded Hosts che fanno girare le Shielded VM vengono approvati dall’HGS in base alla loro appartenenza a un gruppo di sicurezza di Active Directory.

Figura 1: Infrastruttura Guarded Fabric che utilizza Admin-Trusted Attestation (Active Directory based)

Host Guardian Service (HGS)

Il nuovo ruolo server HGS introdotto in Windows Server 2016 è composto dall’Attestation Service e dai Key Protection Services, che permettono ad Hyper v di far girare le Shielded VM. L’Attestation Service verifica l’identità e la configurazione dell’Host Hyper-V (Guarded Host) e il Key Protection Services (KPS) genera la transport key che è necessaria a sbloccare e a far girare le shielded VM. Le Shielded VM proteggono i dati delle macchine virtuali supportando il Virtual TPM che permette di abilitare Bitlocker Encryption sui dischi delle macchine virtuali.

Figura 2: Funzionamento dell’Host Guardian Service

Per i requisiti hardware e software di un server HGS si faccia riferimento all’articolo https://docs.microsoft.com/en-us/windows-server/virtualization/guarded-fabric-shielded-vm/guarded-fabric-prepare-for-hgs

Installazione del Server HGS

In questo articolo verrà mostrato come configurare un server HGS per supportare Admin-Trusted attestation.

Per installare il Server HGS (che nel mio caso è una macchina chiamata LON-SRV1 che è in workgroup) è sufficiente lanciare con privilegi elevati la cmdlet

Install-WindowsFeature –Name HostGuardianServiceRole –IncludeManagementTools –Restart

Figura 3: Schema di funzionamento del laboratorio

Dopo il riavvio, aprite un command prompt di PowerShell con privilegi elevati e digitate i seguenti comandi:

$adminPassword ConvertTo-SecureString -AsPlainText ‘Pa55w.rd’ –Force

Install-HgsServer -HgsDomainName ‘contoso.com’ -SafeModeAdministratorPassword $adminPassword –Restart

Verrà a questo punto installato l’Host Guardian Service, che prevede l’installazione di una nuova foresta chiamata Contoso.com.

Figura 4: Installazione dell’Host Guardian Service, con relativa creazione del dominio

Figura 5: Installazione del Server HGS completata

NOTA: In ambiente di produzione, L’HGS dovrebbe essere installato in un cluster per assicurarsi che l’accesso alle Shielded VM sia mantenuto anche nel caso in cui uno dei nodi HGS non sia disponibile. Pertanto installate il ruolo Server HGS sul primo nodo, che sarà anche il domain controller del dominio HGS di gestione, e successivamente aggiungete gli altri nodi per dominio HGS esistente. Per aggiungere gli altri nodi al Cluster HGS seguite le istruzioni contenute nell’articolo https://docs.microsoft.com/en-us/windows-server/virtualization/guarded-fabric-shielded-vm/guarded-fabric-configure-additional-hgs-nodes

Guardian

Guardian è il termine che viene utilizzato per descrivere la copia di certificati (uno per il signing, l’altro per l’encryption) che protegge la chiave di cifratura simmetrica che viene utilzizata per cifrare il virtual TPM (vTMP) delle Shielded VM. I Guardians contengono solo le chiavi pubbliche, mentre le chiavi private vengono conservate dall’Host Guardian Service (HGS).

Dopo aver nuovamente riavviato il Server HGS, loggatevi come amministratore di dominio (contoso\administrator). Avete bisogno di due certificati per poter inizializzare il vostro server HGS: uno per la firma ed uno per la crittografia. Come prima operazione dovrete creare un certificato (signing.contoso.com) che utilizzerete per la firma. Da un prompt di PowerShell con privilegi elevati digitate i seguenti comandi:

md c:\HGS

$certificatePassword ConvertTo-SecureString -AsPlainText ‘Pa55w.rd’ –Force

$signingCert New-SelfSignedCertificate -DnsName “signing.contoso.com”

Export-PfxCertificate -Cert $signingCert -Password $certificatePassword -FilePath ‘C:\HGS\signingCert.pfx’

Figura 6: Creazione ed esportazione del certificato per la firma completata

A questo punto create ed esportate il certificato che userete per la crittografia (encryption.contoso.com) utilizzando i seguenti comandi:

$encryptionCert New-SelfSignedCertificate -DnsName “encryption.contoso.com”

Export-PfxCertificate -Cert $encryptionCert -Password $certificatePassword -FilePath ‘C:\HGS\encryptionCert.pfx

Figura 7: Creazione ed esportazione del certificato per la cifratura completata

Per visualizzare i certificati appena creati potete utilizzare il comando certutil -viewstore “Shielded VM Local Certificates” oppure utilizzare una MMC vuota e lo snap-in dei certificati Computer, come mostrato in figura:

Figura 8: Visualizzazione dei certificati creati utilizzando il comando certutil

Figura 9 Visualizzazione dei certificati creati utilizzando lo snap-in dei certificati Computer

Inizializzazione dell’Host Guardian Service (HGS)

Il passaggio successivo consiste nell’inizializzazione del server HGS. Inizializzate il server HGS con la modalità Admin-Trusted attestation usando il comando PowerShell

Initialize-HGSServer -HgsServiceName ‘hgs’ -SigningCertificatePath ‘C:\HGS\signingCert.pfx’ -SigningCertificatePassword $certificatePassword -EncryptionCertificatePath ‘C:\HGS\encryptionCert.pfx’ -EncryptionCertificatePassword $certificatePassword -TrustActiveDirectory

Figura 10: Inizializzazione del server HGS con la modalità Admin-trusted attestation

Terminata l’operazione di inizializzazione siete pronti ad utilizzare il vostro Server HGS! Per maggiori informazioni vi rimando all’articolo https://docs.microsoft.com/en-us/windows-server/virtualization/guarded-fabric-shielded-vm/guarded-fabric-initialize-hgs-ad-mode-default

Per verificare che tutto sia stato configurato correttamente potete lanciare il comando PowerShell Get-HgsTrace -RunDiagnostics

Figura 11: Inizializzazione del server HGS completata correttamente

Creazione del trust tra il dominio HGS ed il dominio in cui sono attestati gli Host Hyper-V

Per poter utilizzare la Admin-Trusted attestation (Active directory based) è necessario creare un trust unidirezionale tra il dominio del Fabric (nel mio caso Adatum.com) ed il dominio HGS (nel mio caso Contoso.com).

Figura 12: Trust unidirezionale tra il dominio del Fabric (Adatum.com) ed il dominio HGS (Contoso.com)

Configurate il DNS sul LON-SVR1 in modo tale da creare un conditional forwarder che possa risolvere il dominio adatum.com e create un trust di foresta unidirezionale dal dominio HGS verso il dominio fabric utilizzando i due comandi:

Add-DnsServerConditionalForwarderZone -Name “adatum.com” -ReplicationScope “Forest” -MasterServers 172.16.0.10

netdom trust contoso.com /domain:adatum.com /userD:adatum.com\Administrator /passwordD:Pa55w.rd /add

Figura 13: Crazione del trust tra il dominio del fabric ed il dominio HGS

Configurazione del Fabric Domain Server

Aggiungete sul domain controller del fabric (adatum.com) un conditional forwarder che possa risolvere il dominio contoso.com utilizzando il comando PowerShell

Add-DnsServerConditionalForwarderZone -Name ‘contoso.com’ -ReplicationScope “Forest” -MasterServers 172.16.0.11

Create nel dominio Adatum.com un nuovo gruppo chiamato HGSHosts e inserite nel gruppo gli Host di virtualizzazione Hyper-V che ospiteranno le Shielded VM (nel mio caso ho aggiunto LON-HOST1).

Figura 14: Creazione del gruppo che conterrà gli Host di virtualizzazione

Verificate con il comando Get-ADGroup HGShosts qual è il SID del gruppo appena creato. Il SID verrà utilizzato per configurare poi sul Server HGS (LON-SVR1) l’Attestation Host Group ed individuerà tutti gli Host autorizzati a far girare le Shielded VM.

Figura 15: Verifica del gruppo appena creato

Spostatevi quindi sul computer LON-SVR1 e digitate il comando Add-HgsAttestationHostGroup -Name HGSHosts –Identifier <SID>, sostituendo il paramento <SID> con il valore del SID del gruppo che avete precedentemente visualizzato.

Figura 16: aggionta dell’Host Attestation Group al Server HGS

Lanciate il comando Get-HgsTrace -RunDiagnostics per verificare che tutto sia stato configurato correttamente e dopo qualche minuto ricevere lo status di Pass in verde, come mostrato in figura:

Figura 17: Verifica della configurazione del Server HGS

A questo punto avrete terminato la creazione del server HGS e la creazione di un Fabric Domain Server con un Attestation Host Group.

Configurazione dei server Hyper-V (Guarded Host)

Per configurare Hyper-V all’utilizzo di un server HGS e trasformarlo in un Guarded Host in modo tale che possa ospitare Shielded VM, è sufficiente aggiungere ad una macchina Windows Server 2016 il ruolo di Host Guardian Service, sia utilizzando PowerShell con il comando Install-WindowsFeature HostGuardian –IncludeManagementTools –Restart sia utilizzando l’interfaccia grafica di aggiunta e rimozione dei ruoli.

Figura 18: Aggiunta del Ruolo di Host Guardian Service

Figura 19: Installazione del ruolo di Host Guardian Service e di tutti i prerequisiti

Terminata l’installazione ed il successivo riavvio, possiamo configurare il nostro Host Hyper-V come client HGS (Guarded Host) utilizzando il comando PowerShell

Set-HgsClientConfiguration -AttestationServerUrl ‘http://LON-SVR1.Contoso.com/Attestation’ -KeyProtectionServerUrl ‘http://LON-SVR1.Contoso.com/KeyProtection’

Figura 20: Aggiunta del client HGS

È possibile visualizzare in qualsiasi momento la configurazione eseguendo la cmdlet Get-HgsClientConfiguration

Creazione di una Shielded VM

Per creare una Shielded VM è necessario creare una macchina virtuale Generation 2. Nel mio caso la macchina si chiamerà ShieldedVM01

Figura 21: Creazione di una nuova VM Generation 2

Terminata la creazione della macchina procedete all’installazione del Sistema operativo

Figura 22: Installazione del Sistema operativo

Terminata l’installazione della VM ricordatevi di abilitare il Desktop Remoto, in quanto dopo che avremo reso la VM “shielded” non sarà più possibile utilizzare la console di Hyper-V per potervi accedere.

Figura 23: Abilitazione del Desktop remoto nella VM da proteggere

A questo punto arrestate la macchina virtuale, che potrà essere protetta solo se è spenta.

Protezione della VM

Dall’Host di virtualizzazione LON-HOST1 collegatevi al Key Protection Web Service ospitato sul Server HGS (LON-SVR1) e salvate la configurazione localmente utilizzando il comando:

MD C:\HGS

Invoke-WebRequest http://LON-SVR1.contoso.com/Keyprotection/service/metadata/2014-07/metadata.xml -OutFile ‘C:\HGS\HGSGuardian.xml’

Rendete a questo punto LON-HOST1 un local HGS Guardian, utilizzando il file xml che avete generato, digitando il comando PowerShell

$Owner =  New-HgsGuardian –Name ‘Owner’ –GenerateCertificates

$Guardian Import-HgsGuardian -Path ‘C:\HGS\HGSGuardian.xml’ -Name ‘TestFabric’ –AllowUntrustedRoot

Figura 24: Creazione dell’Host Guardian

Create un Key Protector, che definisce quale Fabric è autorizzato ad eseguire la macchina virtuale protetta con il comando:

# Creazione di un Key Portector, che stabilisce quale fabric potrà avviare la VM

$KP New-HgsKeyProtector -Owner $Owner -Guardian $Guardian -AllowUntrustedRoot

# Abilitazione dello shielding della VM

Set-VMKeyProtector –VMName ShieldedVM01 –KeyProtector $KP.RawData

Il passaggio finale consiste nell’abilitare la Security Policy sulla VM e di fatto trasformarla in una Shielded VM.

# Configura la policy di sicurezza della VM

Set-VMSecurityPolicy -VMName ShieldedVM01 -Shielded $true

Figura 25: Configurazione della VM e trasformazione in una Shielded VM

Per abilitare il virtual TPM sulla macchina virtuale è invece sufficiente eseguire il comando Enable-VMTPM -VMName ShieldedVM01.

Adesso la macchina virtuale ShieldedVM01 può essere avviata e se aprite il Virtual Machine Connector riceverete una schermata come quella mostrata in figura, che vi avvisa che d’ora in poi potrete connettervi alla VM utilizzando solo il Desktop remoto.

Figura 26: La connessione in console è proibita sulle Shielded VM

Da questo momento la macchina è protetta e potrà essere eseguita solo sugli Host autorizzati. Infatti se provate ad avviare la macchina su un Host non autorizzato riceverete il seguente messaggio di errore:

Figura 27: Esecuzione di una Shielded VM su un Host non autorizzato e relativo messaggio di errore

Se provate a montare il disco di una VM che è stata protetta riceverete invece il seguente messaggio di errore

Figura 28: Il tentativo di montare il VHD di una Shielded VM fallisce con un errore

Shielded VM in Windows 10 Client Hyper-V

Da Windows 10, versione 1709, anche Client Hyper-V può ospitare le Shielded VM utilizzando l’Attestation con un Server HGS remoto, mentre prima di questa versione era possibile farlo solo utilizzando il local mode, cioè facendo in modo che le encryption key del vTPM venissero salvate localmente. Per approfondimenti vi rimando all’articolo https://blogs.technet.microsoft.com/datacentersecurity/2018/01/05/shielded-vm-local-mode-and-hgs-mode/

Conclusioni

Windows Server 2016 è la versione più sicura tra i sistemi operativi server rilasciati da Microsoft e nell’era dell’Hybrid Cloud la sicurezza rappresenta la sfida maggiore proprio per la natura distribuita dei worloads su diverse piattaforme. Host Guardian Service e le Hyper-V Shielded VM rappresentano un’ottima soluzione per proteggere le macchine virtuali dagli attacchi esterni e dagli accessi non autorizzati da parte degli Hyper-V Administrators.

Reinventare l’approccio alla sicurezza

Facebooktwittergoogle_plusredditlinkedin

Assistiamo a uno sviluppo significativo delle smart city, con trasporti pubblici senza conducente, pagamenti contactless, assistenti personali virtuali, raccolta intelligente dei rifiuti e parcheggi smart che vengono sperimentati o utilizzati in tutto il mondo. Presto avremo auto senza conducente, case abilitate all’uso di IoT in grado di rilevare quando c’è bisogno di riparazioni e controllo del traffico tramite l’intelligenza artificiale.

Ma queste innovazioni, che sono accolte favorevolmente dalle imprese e dalle città intelligenti, richiedono anche la fiducia dei consumatori e la totale garanzia di sicurezza. E più imprese intraprendono queste nuove proposte, più sono apparentemente a rischio. Tutto in un momento in cui la protezione di dati e sistemi è più importante che mai.

Queste innovazioni rimangono necessarie per il successo delle imprese e delle città. Quindi, per evolvere, le aziende devono considerare l’innovazione e la sicurezza in tandem. L’IT ha bisogno di soluzioni in grado di proteggere le interazioni tra utenti, applicazioni e dati in luoghi più dinamici, complessi ed estesi che mai.

Ciò significa reinventare l’approccio alla sicurezza: passare da una ricerca dispendiosa in termini di tempo, quasi senza speranza per ogni singola possibile minaccia, capire esattamente cosa si suppone debba fare un carico di lavoro e agire immediatamente quando c’è una deviazione da ciò. Affinché l’innovazione continui, le imprese devono considerare questo approccio come parte intrinseca della gestione dell’infrastruttura.

Clicca qui per guardare il Tech Talk Carpool e seguici per conoscere il prossimo viaggio. Nel frattempo, prova i prodotti VMware con gli Hands-on Lab e assicurati che il tuo data center sia protetto scaricando la guida VMware for Dummies.

 

Misure minima di sicurezza ICT per le Pubbliche Amministrazioni

Facebooktwittergoogle_plusredditlinkedin

Informazioni generali

Il 26 settembre 2016 l’AgID (Agenzia per l’Italia Digitale) ha pubblicato un documento che contiene l’elenco ufficiale delle “Misure minime per la sicurezza ICT delle pubbliche amministrazioni” che devono essere adottate in attuazione della Direttiva 1 agosto 2015 del Presidente del Consiglio dei Ministri che emana disposizioni finalizzate a consolidare lo stato della sicurezza informatica nazionale.

Le Misure minime sono diventate di obbligatoria adozione per tutte le Amministrazioni con la pubblicazione sulla Gazzetta Ufficiale (Serie Generale n.103 del 5-5-2017) della Circolare 18 aprile 2017, n. 2/2017, recante «Misure minime di sicurezza ICT per le pubbliche amministrazioni. (Direttiva del Presidente del Consiglio dei ministri 1° agosto 2015)».

Modalità di attuazione

L’adeguamento delle Pubbliche amministrazioni alle Misure minime dovrà avvenire entro il 31 dicembre 2017, a cura del responsabile della struttura per l’organizzazione, l’innovazione e le tecnologie di cui all’art.17 del C.A.D., e in sua assenza a cure del dirigente allo scopo designato.

Il dirigente responsabile dell’attuazione deve compilare e firmare digitalmente con marcatura temporale il “Modulo di implementazione” allegato alla Circolare. Le modalità con cui ciascuna misura è implementata presso l’amministrazione debbono essere sinteticamente riportate nel modulo di implementazione.

Dopo la sottoscrizione il modulo di implementazione deve essere conservato e, in caso di incidente informatico, trasmesso al CERT-PA insieme con la segnalazione dell’incidente stesso.

Al fine di fornire tutte le principali informazioni identificative e descrittive relative alle singole misure può essere utile fare riferimento anche alle informazioni contenute in procedure, eventualmente, già approvate e adottate dall’Amministrazione che si raccomanda di fornire in allegato in caso di segnalazione di incidente informatico al CERT-PA.

Fra le misure minime è previsto anche che le pubbliche amministrazioni accedano sistematicamente a servizi di early warning che consentano loro di rimanere aggiornate sulle nuove vulnerabilità di sicurezza. A tal proposito il CERT-PA fornisce servizi proattivi ed informativi a tutte le amministrazioni accreditate.

AgID provvederà ad aggiornare le Misure minime tutte le volte che si renderà necessario, in funzione dell’evoluzione della minaccia cibernetica, al fine di mantenere la Pubblica Amministrazione ad un livello adeguato di protezione.

Premesse sulla definizione delle Misure minime di sicurezza ICT per le pubbliche amministrazioni

Le Misure minime di sicurezza ICT per le pubbliche amministrazioni si basano sull’insieme di controlli noto come SANS 20, pubblicato dal Center for Internet Security come CCSC «CIS Critical Security Controls for Effective Cyber Defense» nella versione 6.0 di ottobre 2015. Il SANS20 è un elenco composto da venti controlli, denominati Critical Security Control (CSC), ordinato sulla base dell’impatto sulla sicurezza dei sistemi. Ciascun controllo precede tutti quelli la cui implementazione innalza il livello di sicurezza in misura inferiore alla sua.

Dal momento che è comune convinzione che i primi cinque controlli siano quelli indispensabili per assicurare il minimo livello di protezione nella maggior parte delle situazioni AgID è partita da questi per stabilire le misure minime di sicurezza per la pubblica amministrazione italiana e definire gli AgID Basic Security Control(s) (ABSC).

Per definire gli ABSC AgID è partita dal confronto tra le versioni 6.0 e 5.1 dei CCSC, assunto quale indicatore dell’evoluzione della minaccia cibernetica nel corso degli ultimi anni da cui risulta:

  • Un aumento di importanza delle misure relative agli amministratori di sistema, che balzano dal 12° al 5° posto, entrando nella rosa dei Quick Win.
  • Riduzione d’importanza della sicurezza applicativa scivola dal 6° al 18° posto
  • Riduzione d’importanza degli accessi wireless dal 7° al 15° a causa della diffusione delle contromisure atte a contrastare le vulnerabilità tipiche di tali ambiti.

Si è deciso di fare riferimento, nell’identificazione degli ABSC, alla versione 6 dei CCSC. Tuttavia l’insieme dei controlli definiti è più vicino a quello della versione 5.1 poiché AgID ha ritenuto che molti dei controlli eliminati nel passaggio alla nuova versione, probabilmente perché non più attuali nella realtà statunitense, sono ancora importanti nel contesto della pubblica amministrazione italiana.

Strutturazione delle Misure minime di sicurezza ICT per le pubbliche amministrazioni

Il CCSC è stato concepito essenzialmente nell’ottica di prevenire e contrastare gli attacchi cibernetici, ragione per la quale non viene data particolare rilevanza agli eventi di sicurezza dovuti a casualità quali guasti ed eventi naturali. Per questa ragione, ai controlli delle prime cinque classi AgID ha deciso di aggiungere quelli della CSC8, relativa alle difese contro i malware, della CSC10, relativa alle copie di sicurezza, unico strumento in grado di proteggere sempre e comunque le informazioni dal rischio di perdita, e della CSC13, riferita alla protezione dei dati rilevanti contro i rischi di esfiltrazione.

Ciascun CSC è costituito da una famiglia di misure di dettaglio più fine, che possono essere adottate in modo indipendente, consentendo un’ulteriore modulazione utile ad adattare il sistema di sicurezza alla effettiva realtà locale. AgID ha ritenuto che anche al secondo livello ci fosse una granularità ancora eccessiva, soprattutto sotto il profilo implementativo, che avrebbe costretto soprattutto le piccole amministrazioni ad introdurre misure esagerate per la propria organizzazione. Per tale ragione è stato introdotto un ulteriore terzo livello, nel quale la misura di secondo livello viene decomposta in misure elementari, ancora una volta implementabili in modo indipendente. Pertanto un ABSC è identificato da un identificatore gerarchico a tre livelli x, y, z, dove x e y sono i numeri che identificano il CSC concettualmente corrispondente e z individua ciascuno dei controlli di livello 3 in cui questo è stato raffinato.

Quindi le Misure minime di sicurezza ICT per le pubbliche amministrazioni sono composte da 8 ABSC che sono derivati dai CSC 1,2,3,4,5,8,10 e 13.

Il primo livello delle Misure minime di sicurezza ICT per le pubbliche amministrazioni corrisponde ad una famiglia di controlli destinati al perseguimento del medesimo obiettivo (ABSC o relativo CSC) e ad esso è associata una tabella che li contiene tutti i controlli così strutturata:

  • La prima colonna «ABSC_ID#» è sviluppata gerarchicamente su tre livelli e definisce l’identificatore univoco di ciascuno di essi.
  • La seconda colonna «Descrizione» specifica il controllo attraverso una definizione sintetica.
  • La terza colonna «FNSC» (Framework nazionale di sicurezza cibernetica), viene indicato l’identificatore della Subcategory del Framework Core del Framework nazionale per la Cyber Security, proposto con il 2015 Italian Cyber Security Report del CIS «La Sapienza» presentato lo scorso 4 febbraio 2016, al quale il controllo è riconducibile.
  • La quarta, la quinta e la sesta colonna sono booleane e costituiscono una linea guida che indica quali controlli dovrebbero essere implementati per ottenere un determinato livello di sicurezza.
    • La quarta colonna «Minimo» specifica il livello sotto il quale nessuna amministrazione può scendere e i controlli in essa indicati debbono riguardarsi come obbligatori.
    • La quinta colonna «Standard» può essere assunta come base di riferimento nella maggior parte dei casi.
    • La sesta colonna «Alto» può essere considerata come un obiettivo a cui tendere.

Minaccia cibernetica per le pubbliche amministrazioni

La pubblica amministrazione continua ad essere oggetto di attacchi dimostrativi, provenienti da soggetti spinti da motivazioni politiche ed ideologiche, ma sono diventate importanti e pericolose le attività condotte da gruppi organizzati, non solo di stampo propriamente criminale, i quali dispongono di un’elevata quantità di risorse che si riflette nell’utilizzo di strategie e strumenti sofisticati.

Quindi le misure preventive devono essere affiancate da efficaci strumenti di rilevazione, in grado di abbreviare i tempi, oggi pericolosamente lunghi, che intercorrono dal momento in cui l’attacco primario è avvenuto e quello in cui le conseguenze vengono scoperte.

In questo scenario, in cui è fondamentale la rilevazione delle anomalie operative, viene data grande importanza agli inventari, a cui sono dedicati l’ABSC 1 e l’ABSC 2, nonché alla protezione della configurazione, a cui è dedicato l’ABSC 3.

Per prevenire efficacemente gli attacchi basati sulla scalata ai privilegi, occorre dare importanza all’analisi delle vulnerabilità, a cui è dedicato l’ABSC 4, al fine di eliminare le vulnerabilità e rilevare le alterazioni nel caso di un attacco in corso.

L’ABSC 5 dedicata alla gestione degli utenti, in particolare quelli amministratori su cui il SANS20 ha posto particolare attenzione portando l’importanza della loro gestione dal 12° al 5° posto.

L’ABSC 8 è dedicato all’individuazione di codice malevolo spesso installato durante una o più fasi di attacchi complessi.

Le copie di sicurezza rappresentano di fatto l’unico strumento che garantisce il ripristino dopo un incidente, quindi a tele fondamentale attività è dedicato l’ABSC 10.

Dal momento che l’obiettivo principale degli attacchi più gravi è la sottrazione di informazioni alla protezione dei dati è stato dedicato l’ABSC 13.

Conclusioni

Le Misure minime di sicurezza ICT sono parte integrante del più ampio disegno delle Regole Tecniche per la sicurezza informatica della Pubblica Amministrazione, a riguardo si veda la news di AgID Sicurezza informatica per la PA: focus su standard di riferimento per tutte le amministrazioni e il capitolo dedicato alla “Sicurezza” del Piano Triennale.

In estrema sintesi le Misure minime di sicurezza ICT per le pubbliche amministrazioni sono un insieme ordinato e ragionato di “controlli” predisposto da AgID al fine di fornire alle pubbliche amministrazioni un elenco di azioni puntuali di natura tecnica od organizzativa che costituiscono un riferimento pratico per valutare e innalzare il livello della sicurezza informatica.

AgID ha cercato di modulare i controlli in modo da non costringere le Pubbliche Amministrazioni più piccole ad introdurre misure esagerate per la propria organizzazione, con conseguenti inutile dispendio di risorse. Per questo motivo i singoli controlli CSC sono stati trasposti nei controlli ABSC suddividendoli in famiglie di misure di dettaglio più fine in modo da consentire alle Pubbliche Amministrazioni di implementare un livello di sicurezza informatica adatto alle effettive esigenze della specifica realtà locale suddividendo i controlli in tre gruppi verticali, riferiti a livelli complessivi di sicurezza crescente.

Il livello minimo Misure minime di sicurezza ICT rappresenta i controlli obbligatori che ogni amministrazione pubblica deve implementare entro il 31 dicembre 2017, ma sarebbe opportuno valutare le azioni necessarie sull’infrastruttura tenendo conto anche dei controlli di livello Standard che rappresentano la una base di riferimento e costituiscono un ragionevole compromesso fra efficacia delle misure preventive ed onerosità della loro implementazione. I controlli di livello Alto il livello adeguato per le organizzazioni maggiormente esposte a rischi, per la criticità delle informazioni trattate o dei servizi erogati, inoltre rappresentano l’obbiettivo l’obiettivo ideale cui tutte le altre organizzazioni dovrebbero tendere. In ogni caso le amministrazioni NSC (Nucleo di Sicurezza Cibernetica), dovrebbero collocarsi almeno a livello “standard” in assenza di requisiti più elevati.

Ovviamente le Misure minime di sicurezza ICT per le pubbliche amministrazioni insieme al Framework Nazionale per la Cybersecurity, destinato a piccole e micro imprese italiane, può consentire ad aziende private può fornire ottimi spunti su cui modellare la sicurezza della propria infrastruttura in base al criticità dei dati trattati o ai servizi erogati.

Meltdown e Spectre: vulnerabilità a livello hardware

Facebooktwittergoogle_plusredditlinkedin

Meltdown e Spectre sono delle vulnerabilità alquanto serie che affliggono la maggior parte dei processori esistenti sul mercato, rendendo quindi potenzialmente attaccabili sistemi come personal computer, server, dispositivi mobile, ma anche molti servizi di tipo cloud. Queste vulnerabilità riguardano molte famiglie di CPU, incluse quelle di AMD, ARM e Intel, e poiché lavorano ad un basso livello, qualunque sistema operativo che giri su di esse è potenzialmente colpito. Purtroppo, a differenza di quanto avvenuto in passato per problemi a livello di CPU, in questo caso non è risolvibile con un banale aggiornamento del microcode del […]

The post Meltdown e Spectre: vulnerabilità a livello hardware appeared first on vInfrastructure Blog.

Come effettuare un PenTest – Parte 4: Enumerazione dei target

Facebooktwittergoogle_plusredditlinkedin

Siamo arrivati alla fase definita “Enumerating Target”. Tale fase è il processo per il quale vengono raccolte informazioni sulla macchina target come:

  • Elenco di Porte aperte (Port Scan);
  • Identificazione OS (fingerprint);
  • Servizi Applicativi Attivi.

Prima di affrontare questi tre punti, provando a descrivere alcuni approcci utili, è opportuno definire in maniera chiara la definizione di Port Scanning:

Port Scanning è un’attività che permette di determinare lo stato delle porte TCP o UDP su una macchina vittima. Una porta aperta significa che un host è in ascolto e dunque vi è un servizio accessibile. Al contrario una porta chiusa sta ad indicare che il target non è in ascolto su quella specifica porta.

Un esempio pratico di port scanning e il suo possibile risultato può essere questo:

Un attaccante, interrogando una porta aperta (dunque un servizio attivo su una potenziale vittima), è in grado di recuperare la versione di un Web Server (Esempio molto banale ma chiarificatore).

Se la versione del Web Server risulta vulnerabile, secondo le ultime scoperte, potrebbe essere possibile sfruttare la vulnerabilità.

Prima di affrontare una simulazione di scansione, occorre ricordare due concetti base a livello di trasporto nello STACK TCP/IP:

  • Il protocollo TCP è considerato statefull in quanto ha dei controlli interni inerenti la ritrasmissione dei pacchetti; utilizza il concetto del Three Way-HandShake ed è utilizzato, data la sua affidabilità, per trasmettere dati come HTTP, FTP o SSH.

  • Il protocollo UDP è al contrario Stateless. I pacchetti inviati non sono controllati e qualora un pacchetto vada perso, dovrà essere ritrasmesso dall’applicazione.

    Un modo per poter identificare porte aperte e relativi servizi, è utilizzando il network tool NMAP. La possibilità di conoscere la versione dei servizi esposti può essere un buon punto di partenza per ricercare eventuali vulnerabilità o exploit pubblici.

Nmap risulta essere uno dei tools più famosi e completi presenti nel panorama dell’IT security. Oltre al semplice port scan può essere usato anche per:

  • Host Discovery;
  • Identificazione di Host/Servizi;
  • Os (Operating System) Fingerprint;
  • Network Traceroute;
  • Custom Nmap Script.

Per installare NMAP basta eseguire il comando:

# apt-get update

# apt-get install nmap

# nmap

Nell’interrogare una porta, essa potrebbe rispondere in più modi, a seconda del suo stato. NMAP si preoccupa di interpretare le risposte e fornirci un riscontro User-Friendly.

Le porte possono essere:

  • Open: significa che ha la porta in ascolto ha accettato un pacchetto TCP o un UDP datagram;
  • Closed: significa che anche se la porta risulta accessibile, non vi è nessun servizio esposto;
  • Filtered: sta ad indicare che il tool non è in grado di identificare se la porta è aperta o no, in quanto vi può essere un packet-filter
  • Unfiltered: non riesce ad identificare se la porta è aperta o chiusa;
  • Open | Filtered: è solito ricevere questo stato quando nmap non è in grado di capire se la porta è aperta o filtrata. Accade quando vi è un drop dei pacchetti;
  • Closed | Filtered: in quest’ultimo caso, il tool non è in grado di determinare se la porta è filtrata o chiusa.

L’utilizzo basilare di Nmap è stato già affrontato in un precedente articolo che vi invito a leggere prima di proseguire la lettura di questo articolo: https://www.ictpower.it/sicurezza/testare-la-sicurezza-della-propria-rete-utilizzando-nmap.htm

Tipologie di Scansione: una per ogni occasione

Nmap utilizza numerose tipologie di scansioni: ognuna di esse ha una funzione specifica e con finalità ben precise.

  • TCP Connect scan (-sT): questa scansione va a stabilire un three-way handshake su tutte le porte specificate dall’attaccante. Risulta essere molto intrusiva, lenta e loggabile dalla vittima;
  • SYN Scan (-sS): è la tipologia di scansione utilizzata da Nmap per default, veloce e non intrusiva. Definita anche half-open in quanto vengono inviati pacchetti TCP con FLAG SYN, senza completare il three-way Handshake.

    In base alla risposta della vittima è facile capire se un servizio risulta essere in ascolto.

  1. Se la risposta ad un pacchetto SYN risulta essere SYN/ACK siamo in presenza di una porta aperta e con un servizio attivo;
  2. nel caso di risposta RST/ACK, significa che la porta non è in ascolto.
  3. Se dovessimo ricevere un pacchetto ICMP di tipo “destination unreacheble” potrebbe trovarci di fronte ad una porta filtrata.
  • TCP NULL Scan (-sN), FIN scan (-sF) o XMAS scan (-sX): sono 3 tipologie di scansione che agiscono sempre sui flag del protocollo TCP. NULL scan tende a non settare nessun bits di controllo. FIN Scan setta il FLAG FIN nel TCP, XMAS Scan setta i FLAG URG, FIN e PSH.
    • Se si riceve un pacchetto con FLAG RST, la porta risulta chiusa; se non si riceve risposta significa che la porta può essere aperta o filtrata.
  • TCP Maimon scan (-sM): è una tecnica di scansione basata sul settare i FLAG TCP con FIN/ACK.
    • Se riceviamo un pacchetto RST la porta risulterà chiusa;
    • se il pacchetto sarà droppato la porta è da considerarsi aperta. (Droppato da DROP, dunque scartato)
  • TCP ACK scan (-sA): Utilizzato prevalentemente per vedere se vi è un firewall di tipo stateful e quali porte sono filtrate.
    • Se riceviamo un pacchetto con FLAG RST la porta non è filtrata;
  • TCP Idle scan (-sI) : è una scansione indiretta, utilizzata per nascondere il vero attaccante. Utilizza infatti uno “Zombie”. Potrebbe essere un buon modo per mascherare alcune tracce.

Fino ad ora abbiamo descritto le scansioni più utilizzate con il protocollo TCP. Per il protocollo UDP le performance di scansione tendono ad essere molto inferiori.

Dunque mettetevi comodi…

Un buon consiglio potrebbe essere quello di concentrarsi su le porte standard o condurre una scansione in modo distribuito.

# nmap -sU 8.8.8.8 -p 53

[UDP scan sulla porta 53, host 8.8.8.8]

Ricorda: Nmap, per default, scansiona le top 1000 porte. Per specificare le porte usa il comando -p.

Bypass delle protezioni

Esistono alcune tecniche molto utili per Bypassare controlli basati su IDS o Firewall:

  • Fragment packets (-f): nmap si preoccuperà di dividerà i pacchetti in 8 byte o meno dopo l’header IP;
  • (–mtu): permette di specificare la dimensione della frammentazione di un pacchetto. Il Maximum Transmission Unit (MTU) deve essere un multiplo di otto o Nmap restituirà errore;
  • –source-port <portnumber> permette di specificare la porta sorgente. È utile per ingannare un firewall qualora esso accetti una determinata porta in ingresso;
  • –data-length: permette di specificare la grandezza dei pacchetti inviati;
  • –max-parallelism: con questa istruzione possiamo specificare quanti tentativi/prove possono esser fatte verso un target in un certo tempo;
  • –scan-delay <time>: può essere utile per ingannare IPS/IDS basati su rilevazione degli eventi con soglia.

Una combinazione tra una scansione ben studiata e delle impostazioni di evasione potrebbe garantirvi un ottimo risultato in poco tempo.

Per chi volesse, esiste la possibilità di avere una GUI per utilizzare Nmap. Parliamo di ZenMap. Oltre ad un’interfaccia più semplice ed intuitiva, vi è la possibilità di salvare profili o configurazioni personalizzate.

Inoltre vi è la possibilità di osservare una possibile topologia di rete scansionata.

Enumerazione SMB

Se stiamo andando a testare un ambiente con prevalenza di macchine Windows, questo approccio può essere molto utile. Si tratta di una enumerazione basata sul collezionare informazioni del protocollo Server Message Block.

Tale protocollo è usato per condividere file e stampanti in rete ed è utilizzato da Sistemi Windows.

Per affrontare un enumerazione SMB è possibile scaricare il tool nbtscan.

Per utilizzarlo, basta digitare:

# nbtscan 192.168.1.1-254

[Si noti come ho specificato un intervallo di IP]

Il risultato del comando restituisce il range di ip con le risposte alle query NetBIOS. La differenza sostanziale tra il comando nbtscan e nbtstat è che nello script nbtscan è possibile inserire un range di Ip.

Tale tipologia di enumerazione resta sconsigliata in quanto facilmente loggabile in una macchina vittima.

Esistono altre tecniche di enumerazione più avanzate come quella basata su SNMP (snmpcheck) o VPN (ike-scan) che non affronteremo. Per ulteriori dettagli vi rimando ai rispettivi tools:

Snmpcheck: https://tools.kali.org/information-gathering/snmp-check

Ike-scan: https://github.com/royhills/ike-scan

Siamo giunti al termine di questo articolo con la consapevolezza e l’abilità di poter identificare servizi esposti e possibilmente vulnerabili. Nel prossimo passo cercheremo di mappare tutte le possibili vulnerabilità presenti sulla macchina target per poi sfruttarle a nostro vantaggio.