L’implementazione di una Certification Authority (CA) nella propria infrastruttura prevede una preventiva analisi della struttura della Public Key Infrastructure (PKI) più adatta alla propria organizzazione e la predisposizione dei prerequisiti necessari. La trattazione delle componenti di una PKI e della configurazione di un server web per la pubblicazione della CRL e dei certificati delle CA è disponibile nel precedente articolo Deploy PKI in Windows Server 2016 – Parte 1.

Di seguito analizzeremo l’installazione e la configurazione di una Root CA Offline, nell’ipotesi di voler realizzare una CA Two-Tier (a due livelli) facendo riferimento al seguente schema che verrà utilizzato come scenario di esempio.

La Root CA viene mantenuta normalmente spenta, di conseguenza è preferibile che non sia integrata in Active Directory e quindi dovrà essere Standalone e non Enterprise, mentre la Subordinate CA a cui verrà demandano il compito di rilasciare i certificati sarà di tipo Enterprise per beneficiare dell’utilizzo dei modelli di certificato e dell’integrazione con Active Directory.

Sebbene spesso la giustificazione del fatto che la Root CA Offline è preferibile che sia non joinata ad un domino Active Directory, e quindi Standalone e non Enterprise, sia imputata al fatto che la scadenza della password dell’account computer che per default avviene ogni 30 giorni, causando l’impossibilità di utilizzare il secure channel. In realtà come indicato nel post Machine Account Password Process dal momento che il processo di rinnovo della password dell’account computer è avviato dal client non vi alcun rischio che il secure channel non possa essere utilizzato anche se la Root CA viene mantenuta spenta per lunghi periodi.

“Question: If a workstation does not change its password, will it not be allowed to log onto the network?

Answer: Machine account passwords as such do not expire in Active Directory. They are exempted from the domain’s password policy. It is important to remember that machine account password changes are driven by the CLIENT (computer), and not the AD. As long as no one has disabled or deleted the computer account, nor tried to add a computer with the same name to the domain, (or some other destructive action), the computer will continue to work no matter how long it has been since its machine account password was initiated and changed.

So if a computer is turned off for three months nothing expires. When the computer starts up, it will notice that its password is older than 30 days and will initiate action to change it. The Netlogon service on the client computer is responsible for doing this. This is only applicable if the machine is turned off for such a long time.

Before we set the new password locally, we ensure we have a valid secure channel to the DC. If the client was never able to connect to the DC (where never is anything prior the time of the attempt – time to refresh the secure channel), then we will not change the password locally.”

In realtà il vero motivo per cui è preferibile la Root CA sia Standalone è che per avere un’elevata sicurezza non dovrebbe essere connessa alla rete neppure quando viene avviata saltuariamente per installare gli aggiornamenti automatici, ma attestata su una rete separata che consenta la comunicazione con l’infrastruttura solo per permettere l’aggiornamento della CRL e del certificato della CA sul server web che si occupa di pubblicarli.

Per ulteriori informazioni si vedano:

• Certification Authority Guidance
• Securing Public Key Infrastructure (PKI)
• Server Certificate Deployment
• AD CS Step by Step Guide: Two Tier PKI Hierarchy Deployment

Installazione e configurazione della Root CA Offline

Per configurare il servizio di CA occorre aggiungere il ruolo Active Directory Certificate Services selezionando l’installazione del servizio Certification Autority.

Terminata l’installazione è possibile configurare il servizio della CA in base alle seguenti impostazioni utilizzando le credenziali di amministratore locale.

Per sicurezza il nome della CA non fa alcun riferimento all’hostname del server e il database dei certificati viene mantenuto in un disco separato da quello di sistema.

Configurazione Estensioni della Root CA Offline per impostare i CRL (Certificate Revocation List) Distribution Points (CDP)

Lo scopo delle estensioni CRL CDP è quello di indicare ai client dove trovare le CRL aggiornate firmate dalla CA, tali informazioni verranno poi inserite nei certificati generati dalla CA.

Per impostazione predefinita vi sono quattro CRL CDP già configurati e su alcuni di essi occorre eseguire alcune impostazioni affinché l’unico riferimento alla CRL che verrà inserito nei certificati rilasciati sia quello dell’URL del server Web che pubblica la CRL. Nello scenario di esempio l’URL di pubblicazione della CRL è http://crl.ictpower.local/CertEnroll.

Il CRL CDP locale è usato dalla CA e non necessita di essere modificato.

Il CRL CDP ldap deve essere modificato in modo da non pubblicare la CRL, volendo è anche possibile rimuovere tale CRL CDP dal momento che di fatto non verrà utilizzato.

Il CRL CDP http è già impostato in modo da non pubblicare la CRL, volendo è anche possibile rimuovere tale CRL CDP dal momento che di fatto non verrà utilizzato.

Il CRL CDP file deve essere modificato in modo da non pubblicare la CRL, volendo è anche possibile rimuovere tale CRL CDP dal momento che di fatto non verrà utilizzato.

Creare un CRL CDP per l’URL http con le opzioni di inclusione nella CRL per l’URL http://crl.ictpower.local/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl.

Applicare le modifiche riavviando i servizi della CA.

Configurazione Estensioni della Root CA Offline per impostare gli Access Information Access (AIA) Distribution Points (CDP)

Lo scopo delle estensioni AIA CDP è quello di indicare ai client dove trovare il certificato della CA per eseguire la verifica dell’attendibilità nel caso in cui il certificato non contenga al suo interno la catena dei certificati, tali informazioni verranno poi inserite nei certificati generati dalla CA.

L’ AIA CDP locale per impostazione predefinita non viene incluso nei certificati e quindi non necessita di essere modificato.

L’AIA CDP ldap per impostazione predefinita non viene incluso nei certificati e quindi non necessita di essere modificato, volendo è anche possibile rimuovere tale AIA CDP dal momento che di fatto non verrà utilizzato.

L’AIA CDP http per impostazione predefinita non viene incluso nei certificati e quindi non necessita di essere modificato, volendo è anche possibile rimuovere tale AIA CDP dal momento che di fatto non verrà utilizzato.

L’AIA CDP file deve essere modificato in modo da non essere incluso nei certificati, volendo è anche possibile rimuovere tale AIA CDP dal momento che di fatto non verrà utilizzato.

Creare un AIA CDP per l’URL http con le opzioni di inclusione nella CRL per l’URL http://crl.
ictpower.local/CertEnroll/<ServerDNSName>_<CaName><CertificateName>.crt.

Applicare le modifiche confermando il riavvio dei servizi delle CA.

Configurazione della CRL della Root CA Offline

Impostare la pubblicazione della CRL ad un periodo superiore a quello a cui si prevede di avviare periodicamente la Root CA Offline che normalmente sarà mantenuta spenta. Tramite le proprietà dei Certificati revocati si imposta un intervallo di pubblicazione di 4 settimane ipotizzando che settimanalmente la CA sarà avviata per installare eventuali aggiornamenti del sistema.

Verificare in C:\Windows\System32\CertSrv\CertEnroll che la CRL sia stata pubblicata, è possibile avviare la pubblicazione della CRL tramite la voce del menu contestuale All Tasks\Pubblish dei Certificati revocati, oppure mediante il comando:

certutil -CRL

Configurazione della validità dei certificati emessi dalla Root CA Offline

Per default la validità dei certificati emessi da una CA Standalone è di un anno, ma tale impostazione è modificabile tramite certutil che a sua volata modificherà le impostazioni nel registro.

Dal momento che la durata del certificato della CA è stato impostato a 20 anni con previsione di rinnovo ogni 10 anni la validità dei certificati emessi verrà impostata a 10 anni tramite il comando:

certutil -setreg ca\ValidityPeriodUnits “10”

La chiave di registro in cui vene mantenuta tale impostazione è:

HKLM\System\CurrentControlSet\Configuration\CAName\ValidityPeriodUnitis

Al termine della configurazione riavviare il servizio della CA, ad esempio tramite il comando:

net stop certsvc & net start certsvc

Copia della CRL e del certificato della Root CA Offline su server Web per la pubblicazione della CRL

Per consentire l’accesso al server web da parte della Root CA Offline l’approccio più corretto è quello di creare sul server web un account con privilegi di lettura e scrittura su una share che punti alla cartella che conterrà le CRL e i certificati delle CA come illustrato nel precedente articolo Deploy PKI in Windows Server 2016 – Parte 1. Nello scenario di esempio sul server web Web01 si ipotizza che siano state eseguite le seguenti configurazioni:

1. Creazione di un record DNS crl di tipo A per il server web consenta l’accesso a quest’ultimo tramite il nome crl.ictpower.local
2. Creazione di un account CAUpdate che verrà utilizzato dal server Root CA e Subordinate CA per accedere alla cartella condivisa in cui copiare CRL e certificato CA.
3. Creazione della share CertEnroll per concedere l’accesso in lettura e scrittura alla cartella S:\CertEnroll tramite l’account CAUpdate.

Sul server Root CA occorre quindi memorizzare sull’account che verrà utilizzato per aggiornare CRL e certificato CA sul server web le credenziali dell’account CAUpdate specificando come indirizzo del server crl.ictpower.local.

Aggiornare la CRL e copiare sul server web la CRL e il certificato CA della Root CA Offline tramite i comandi che possono anche essere eseguiti tramite un’operazione schedulata all’avvio della Root CA:

certutil -CRL
copy /Y “C:\Windows\System32\CertSrv\CertEnroll\*.crl” \\crl.ictpower.local\CertEnroll
copy /Y “C:\Windows\System32\CertSrv\CertEnroll\*.crt” \\crl.ictpower.local\CertEnroll

L’implementazione di una Certification Authority (CA) Two-Tier (a due livelli) si conclude con l’installazione della Subordinate CA anche detta issuing CA. La trattazione delle componenti di una PKI e della configurazione di un server web per la pubblicazione della CRL e dei certificati delle CA è disponibile nel precedente articolo Deploy PKI in Windows Server 2016 – Parte 1, mentre nell’articolo Deploy PKI in Windows Server 2016 – Parte 2 è stata descritta l’installazione e la configurazione della Root CA Offline.

Di seguito analizzeremo quindi l’installazione e la configurazione della Subordinate CA Offline, nell’ipotesi di voler realizzare una CA Two-Tier (a due livelli) facendo riferimento al seguente schema che verrà utilizzato come scenario di esempio.

La Subordinate CA sarà di tipo Enterprise in modo da poter essere utilizzata in modo integrato con Active Diectory e poter utilizzare i modelli di certificato, quindi il server che assolverà il ruolo di Subordinate CA dovrà essere membro del dominio Active Directory.

Per ulteriori informazioni si vedano:

• Certification Authority Guidance
• Securing Public Key Infrastructure (PKI)
• Server Certificate Deployment
• AD CS Step by Step Guide: Two Tier PKI Hierarchy Deployment

Installazione e configurazione della Subordinate CA

Per configurare il servizio di CA occorre aggiungere il ruolo Active Directory Certificate Services selezionando l’installazione del servizio Certification Autority.

Terminata l’installazione è possibile configurare il servizio della CA in base alle seguenti impostazioni utilizzando le credenziali di un account membro del gruppo Enterprise Admin di Active Directory. Durante la procedura di configurazione verrà creata una richiesta di certificato per generare il certificato della Subordinate CA che dovrà poi essere gestito dalla Root CA.

Configurazione dell’accesso al server Web per la pubblicazione della CRL

Per consentire l’accesso al server web da parte della Subordinate CA l’approccio più corretto è quello di creare sul server web un account con privilegi di lettura e scrittura su una share che punti alla cartella che conterrà le CRL e i certificati delle CA come illustrato nel precedente articolo Deploy PKI in Windows Server 2016 – Parte 1. Nello scenario di esempio sul server web Web01 si ipotizza che siano state eseguite le seguenti configurazioni:

1. Creazione di un record DNS crl di tipo A per il server web consenta l’accesso a quest’ultimo tramite il nome crl.ictpower.local
2. Creazione di un account CAUpdate che verrà utilizzato dal server Root CA e Subordinate CA per accedere alla cartella condivisa in cui copiare CRL e certificato CA.
3. Creazione della share CertEnroll per concedere l’accesso in lettura e scrittura alla cartella S:\CertEnroll tramite l’account CAUpdate.

Sul server Subordinate CA occorre quindi memorizzare sull’account che verrà utilizzato per aggiornare CRL e certificato CA sul server web le credenziali dell’account CAUpdate specificando come indirizzo del server crl.ictpower.local.

Richiesta del certificato per Subordinate CA

Dalla Root CA sottomette la richiesta della Subordinate CA che nel processo di configurazione è stata memorizzata sul disco di sistema C: e volendo è raggiungibile dalla Root CA tramite il percorso URL \\casub.ictpower.local\c$.

Emettere il certificato per la Subordinate CA.

Esportare il certificato per la Subordinate CA in formato PKCS #7 (.PB7) selezionando l’opzione di includere tutti i certificati (ovvero il certificato della Root CA) nel percorso URL \\casub.ictpower.local\c$.

Installazione del certificato della Subordinate CA

Prima di installare il certificato della CA aggiungere l’url http://crl.ictpower.local all’elenco dei Trusted Sites sul server Subordinate CA.

Installare il certificato della CA precedente generato dalla Root CA ed esportato in C:\ CASub.ictpower.local_ictpower-CASUB-CA.p7b.

Avviare il servizio della Subordinate CA.

Configurazione Estensioni della Subordinate CA per impostare i CRL (Certificate Revocation List) Distribution Points (CDP)

Lo scopo delle estensioni CRL CDP è quello di indicare ai client dove trovare le CRL aggiornate firmate dalla CA, tali informazioni verranno poi inserite nei certificati generati dalla CA.

Per impostazione predefinita vi sono quattro CRL CDP già configurati e su alcuni di essi occorre eseguire alcune impostazioni affinché l’unico riferimento alla CRL che verrà inserito nei certificati rilasciati sia quello dell’URL del server Web che pubblica la CRL. Nello scenario di esempio l’URL di pubblicazione della CRL è http://crl.ictpower.local/CertEnroll.

Come riportato in Optimizing the Revocation Experience conviene però gestire la CRL solo tramite http disabilitando quindi le opzioni di pubblicazioni nel CDP relativo a LDAP:

“Although AD DS enables publication of CRLs to all domain controllers in the forest, we recommend implementing HTTP instead of LDAP for revocation information publication. Only HTTP enables the use of the ETag and Cache-Control: Max-age headers providing better support for proxies and more timely revocation information. In addition, HTTP provides better heterogeneous support as HTTP is supported by most Linux, UNIX, and network device clients.”

Il CRL CDP locale è usato dalla CA e non necessita di essere modificato.

Il CRL CDP ldap deve essere modificato in modo da non pubblicare la CRL, volendo è anche possibile rimuovere tale CRL CDP dal momento che di fatto non verrà utilizzato.

Il CRL CDP http è già impostato in modo da non pubblicare la CRL, volendo è anche possibile rimuovere tale CRL CDP dal momento che di fatto non verrà utilizzato.

Il CRL CDP file è già impostato in modo da non pubblicare la CRL, volendo è anche possibile rimuovere tale CRL CDP dal momento che di fatto non verrà utilizzato.

Creare un CRL CDP per l’URL http con le opzioni di inclusione nella CRL per l’URL http://crl.ictpower.local/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl.

Applicare le modifiche riavviando i servizi della CA.

Configurazione Estensioni della Subordinate CA per impostare gli Access Information Access (AIA) Distribution Points (CDP)

Lo scopo delle estensioni AIA CDP è quello di indicare ai client dove trovare il certificato della CA per eseguire la verifica dell’attendibilità nel caso in cui il certificato non contenga al suo interno la catena dei certificati, tali informazioni verranno poi inserite nei certificati generati dalla CA.

L’ AIA CDP locale per impostazione predefinita non viene incluso nei certificati e quindi non necessita di essere modificato.

L’AIA CDP ldap deve essere modificato in modo da non essere utilizzato per pubblicare i certificati, volendo è anche possibile rimuovere tale AIA CDP dal momento che di fatto non verrà utilizzato.

L’AIA CDP http per impostazione predefinita non viene incluso nei certificati e quindi non necessita di essere modificato, volendo è anche possibile rimuovere tale AIA CDP dal momento che di fatto non verrà utilizzato.

L’AIA CDP file per impostazione predefinita non viene incluso nei certificati e quindi non necessita di essere modificato, volendo è anche possibile rimuovere tale AIA CDP dal momento che di fatto non verrà utilizzato.

Creare un AIA CDP per l’URL http con le opzioni di inclusione nella CRL per l’URL http://crl.ictpower.local/CertEnroll/<ServerDNSName>_<CaName><CertificateName>.crt.

Applicare le modifiche confermando il riavvio dei servizi delle CA.

Pubblicazione della CRL e del certificato della Subordinate CA

E’ possibile pubblicare la CRL della Subordinate CA tramite interfaccia grafica

Oppure tramite il comando:

certutil –CRL

Copiare sul server web d pubblicazione la CRL e il certificato tramite i comandi:

copy /Y “C:\Windows\System32\CertSrv\CertEnroll\*.crl” \\crl.ictpower.local\CertEnroll
copy /Y “C:\Windows\System32\CertSrv\CertEnroll\*.crt” \\crl.ictpower.local\CertEnroll

Configurazione della validità dei certificati emessi

Per default la validità dei certificati emessi da una CA Enterprise è di due anni, ma tale impostazione è modificabile tramite certutil che a sua volta modificherà le impostazioni nel registro.

Dal momento che la durata del certificato della CA è stato impostato a 10 anni con previsione di rinnovo ogni 5 anni la validità dei certificati emessi verrà impostata a 5 anni tramite il comando:

certutil -setreg ca\ValidityPeriodUnits “5”

La chiave di registro in cui vene mantenuta tale impostazione è:

HKLM\System\CurrentControlSet\Configuration\CAName\ValidityPeriodUnitis

Al termine della configurazione riavviare il servizio della CA, ad esempio tramite il comando:

net stop certsvc & net start certsvc

Verifica della configurazione della CA

Terminata l’installazione e la configurazione della Subordinate CA occorre verificare che la PKI funzioni correttamente, uno strumento utile per eseguire tale verifica è il tool pkiview.msc:

Introduzione

Il 18 novembre 2014 è stata annunciata ufficialmente al pubblico Let’s Encrypt, una certification authority che automatizza gratuitamente la creazione, la validazione, il rilascio ed il rinnovo di certificati X.509 per il protocollo TLS. Let’s Encryp esce dalla beta il 12 aprile 2016 e a oggi, stando alle statistiche pubblicate al link Let’s Encrypt Growth, sono stati generati 33,7 milioni di certificati. Lo scopo di Let’s Encrypty è quello di abilitare la gestione del ciclo di vita dei certificati SSL/TSL per l’utilizzo da parte di siti web in modo rendere sicure le connessioni HTTPS.

Let’s Encrypt si basa sul protocollo ACME ( Automated Certificate Management Environment) del tipo challenge-response in cui il server (Let’s Encrypt) presenta al client (il web server) un insieme di challenge che il proprietario del dominio deve risolvere per provare di essere il responsabile del dominio. Il protocollo ACME prevede anche altri tipi di challenge, in particolare Let’s Encrypt prevede il supporto a challenge di tipo DNS che richiedono di inserire un record di tipo TXT contenente un token presso il server DNS del dominio per cui si richiede il certificato. Le richieste effettuate tramite il protocollo ACME avvengono attraverso JSON firmati (detti anche JSON web signature o JWS) scambiati su connessioni HTTPS. Per ulteriori informazioni sul funzionamento di Let’s Encrypt si veda How It Works.

Per quanto riguarda la compatibilità con Let’s Encrypt è necessario il certificato IdenTrust’s DST Root X3 sia incluso nello store dei certificati attendibili e che siano supportati i certificati SHA2, in ogni caso è possibile eseguire un test di validità del proprio sito web sul sito SSL Labs’ Server Test. Come riportato in Certificate Compatibility i certificati Let’s Encrypt sono supportati in: Mozilla Firefox v2.0 e successivi, Google Chrome, Internet Explorer su Windows XP SP3 e superiore, Microsoft Edge, Android OS v2.3.6 e successivi, Safari per macOS v4.0 e successivi, Safari per iOS v3.1 e successivi, Debian Linux v6 e successivi, Ubuntu Linux v12.04 e successivi, NSS Library v3.11.9 e successivi, Amazon FireOS (Silk Browser), Cyanogen con versione superiore a 10, Jolla Sailfish OS con versione superiore a 1.1.2.16, Kindle con versione superiore a 3.4.1, Java 7 con versione 7u111 e successivi, Java 8 con versione 8u101 e successivi.

Come riportato nelle FAQ i certificati Let’s Encrypt sono di tipo Domain Validation (DV) e possono quindi essere usati su ogni server che utilizzi un nome a dominio come web servers, mail servers, FTP servers, etc, viceversa per necessità quali Email encryption e code signing che richiedono certificati di tipo differente dai Domain Validation i certificati rilasciati da Let’s Encrypt non possono essere utilizzati. Let’s Encrypt non ha in progetto il supporto al rilascio di certificati di tipo Organization Validation (OV) o Extended Validation (EV). Tramite Let’s Encrypt è comunque possibile ottenere certificati per nomi a dominio multipli (certificati SAN o UCC) tramite il meccanismo Subject Alternative Name (SAN), mentre al momenti non vi sono piani di supporto per certificati wildcard anche se non è detto che tali certificati non possano essere emessi in futuro.

Per quanto riguarda la sicurezza è il ciclo di vita dei certificati rilasciati da Let’s Encrypt va precisato che hanno durata di 90 giorni e che possono essere rinnovati dopo 60 giorni (si veda Why ninety-day lifetimes for certificates? per maggiori dettagli), mentre per quanto riguarda la chiave privata questa è sempre generata e mantenuta sui propri server e non dalla Let’s Encrypt certificate authority, in altre parole la chiave priva non sarà mai memorizzata sui server Let’s Encrypt. La lista degli indirizzi IP tramite cui Let’s Encrypt valida il server web non è resa disponibile in quanto tali IP possono cambiare nel tempo oltre al fatto che in futuro potrebbe essere implementata una validazione multipla da parte di più IP.

La gestione della richiesta di un certificato Let’s Encrypt deve essere fatto tramite un client ACME, l’utilizzo di chiavi private esistenti o Certificate Signing Request (CSR) è consentito, ma no n supportato da tutti gli ACME Client.

Implementazione di Let’Encrypt in ambiente Windows

Il client suggerito dal team di Let’s Encrypt per iniziare a lavorare con i loro certificati automatici è Certbot che però al momento è disponibile solo per sistemi operativi UNIX-like, ma come riportato nella pagina ACME Client Implementations sono stati sviluppati vari client e librerie per la gestione dei certificati tramite il protocollo ACME.

In ambiente Windows sono al momento disponibili i seguenti:

• ACMESharp una libreria scritta in .NET e un client PowerShell (al momento l’ultima release è la 0.8.2 del 4 gennaio 2017)
• letsencrypt-win-simple un client a riga di comando scritto in .NET e basato sulla libreria ACMESharp (al momento l’ultima release è la 1.9.3 del 19 marzo 2017)
• Certify GUI un client GUI WinForms scritto in .NET che implementa un wrapper per gli script PowerShell della libreria ACMESharp (al momento l’ultima release è la 0.9.96 del 20 febbraio 2017)
• oocx/acme.net una libreria scritta in .NET e un client a riga di comando (al momento l’ultima release è la 0.0.65 del 4 dicembre 2015)
• kelunik/acme-client un client scritto in PHP (al momento l’ultima release è la 0.2.13 del 5 gennaio 2017)

Nel seguente articolo verrà utilizzato il client letsencrypt-win-simple per richiedere e gestire il rinnovo di un certificato Let’s Encrypt per un sito web ospitato in IIS in ambiente Windows Server 2016, prima di poter procedere alla configurazione è necessario che siano rispettai i seguenti prerequisiti:

• I server web deve poter accedere in HTTPS al dominio letsencrypt.org
• Il server web deve poter essere raggiunto tramite HTTP (TCP 80) e tramite HTTPS (TCP 443)
• Il nome di dominio DNS a cui il server web deve rispondere deve essere registrato sui DNS pubblici

Installazione e configurazione di IIS

Installare IIS con le impostazioni di default.

Per ragioni di sicurezza è consigliabile spostare il Default Web Site su un volume dedicato copiando la directory di default %SystemDrive%\inetpub\wwwroot tramite il seguente comando (nell’esempio la directory del default web site sarà sposta in W:\inetpub\wwwroot):

XCOPY %SystemDrive%\inetpub\wwwroot W:\inetpub\wwwroot /E /O /I

Modificare il path del Default Web Site tramite IIS manager impostando la proprietà Physical Path del Web Site:

Definire il binding del Default Web Site sul nome di dominio per cui occorrerà generare il certificato sulla porta 80.

Riavviare IIS tramite il comando:

IISRESET /RESTART

Testare l’accesso al Default Web Site con una pagina di prova ed eliminare i file di default.

Richiesta di un certificato Let’s Encrypt tramite client ACME

Dopo aver scaricato l’ultima versione di letsencrypt-win-simple (al momento la 1.9.3), disponibile al seguente link https://github.com/Lone-Coder/letsencrypt-win-simple eseguire letsencrypt.exe con privilegi di amministratore locale il quale tramite una procedura guidata eseguirà la richiesta del certificato per il dominio desiderato alla Certification Autority di Let’s Encrypt.

Passo 1: Digitare l’indirizzo mail a cui verranno inviati eventuali errori durante il rinnovo del certificato.

Si noti che verrà richiesto un certificato con periodo di rinnovo di 60 giorni e che per default il path in cui verranno memorizzati i file di configurazione e il certificato sarà %AppData%\letsencrypt-win-simple\httpsacme-v01.api.letsencrypt.org.

Passo 2: Accettare il LET’S ENCRYPT SUBSCRIBER AGREEMENT (Y), i documenti relativi alle policy e agli aspetti legali di Let’s Encrypt sono disponibili al seguente Policy and Legal Repository.

Passo 3: Selezionare l’opzione di generare i certificati per tutti gli hosts (A)

In questa fase della configurazione vengono eseguite le seguenti 4 operazioni:

Passo3 – Operazione 1: Validazione del dominio

Nella directory che contiene il Web Site (W:\inetpub\wwwroot nell’esempio) viene scritta la challenge answer restituita dai servizi di Let’s Encrypt, che di fatto è un file che risiede nella subdirectory .well-know/acme-challenge inoltre viene creato il file web.config nella subdirectory .well-know/acme-challenge per aggiungere le estensionless mime type. Perché l’operazione riesca l’utente con cui si esegue letsencrypt-win-simple dovrà avere i privilegi di accedere in lettura e scrittura alla directory che contiene il Web Site. Affinchè la challenge answer possa poi essere controllata dai servizi di Let’s Encrypt occorre che sia accessibile via HTTP, quindi è necessario che sia possibile accedere pubblicamente all’URL http://nomesito/.well-know/acme-challenge in modo da poter verificare la corrispondenza della challenge answer con quanto registrato nei DNS pubblici.

La challenge answer viene sottoposta alla validazione da parte dei servizi di Let’s Encrypt.

Terminata la validazione vengono eliminati il file della challenge answer, il file web.config e le subdirectory .well-know/acme-challenge e .well-know.

Per maggiori informazioni sulle operazioni di veda How It Works.

Passo3 – Operazione 2: Richiesta del certificato

Per impostazione predefinita i file relativi al certificato richiesto e quelli relativi alla CA di Let’s Encrypt vengono salvati in %AppData% \letsencrypt-win-simple\httpsacme-v01.api.letsencrypt.org

Per maggiori informazioni sulle operazioni di veda How It Works.

Passo3 – Operazione 3: Installazione del certificato nello store dei certificati per renderlo disponibile ad IIS

Passo3 – Operazione 4: Configurazione del binding del Web Site IIS per l’utilizzo di HTTPS tramite il certificato rilasciato da Let’s Encrypt

Passo 4: Configurazione di un’operazione pianificata per il rinnovo del certificato.

Per gestire il rinnovo del certificato viene creata un’operazione pianificata e viene richiesto di specificare l’account con cui eseguire l’operazione schedulata, tale account dovrà avere i privilegi necessari per accedere in lettura e scrittura sulla directory del sito web in modo da poter creare la challenge answer di rinnovo in modo analogo a quanto visto nel Passo3.

I certificati di Le’s Encrypt hanno una durata massima di 90 giorni, ma possono essere rinnovati dopo 60 giorni. L’operazione pianificata viene schedulata per l’esecuzione giornaliera in modo da poter essere ripetuta per un mese in caso di problemi di rinnovo.

Il comando eseguito dall’operazione pianificata è il seguente (nel seguente esempio il tool letsencrypt-win-simple è memorizzato in W:\Util\letsencrypt-win-simple.V1.9.3):

W:\Util\letsencrypt-win-simple.V1.9.3\letsencrypt.exe --renew --baseuri "https://acme-v01.api.letsencrypt.org/"

Conclusione

Let’s Encrypt fornisce oltre alla possibilità di ottenere in modo gratuito certificati SSL/TSL per rendere sicure le connessioni HTTPS anche un approccio semplice per gestire il rinnovo automatico di tali certificati evitando problematiche connesse a certificati scaduti. Sebbene Let’s Encrypt sia particolarmente attenta alla sicurezza in quanto i sui servizi sono resi disponibili dall’Internet Security Research Group (ISRG) va ovviamente tenuto in considerazione che la sicurezza sarà un aspetto su cui occorrerà ancora lavorare.

Infatti una CA che ha le carte in regola per un’adozione su larga scala grazie soprattutto alla gratuità dei propri servizi attrae ovviamente l’attenzione di chi cerca canali con cui diffondere malware. A fine marzo infatti è stato reso noto come in certe situazione Let’s Encrypt sia stata sfruttata per veicolare phishing da parte di siti che tentavano di spacciarsi come PayPal sfruttando il fatto che la verifica del dominio si basa su un controllo della corrispondenza del nome a dominio registrato e non sul contenuto del sito, per un approfondimento si veda il seguente post Let’s Encrypt issues certs to ‘PayPal’ phishing sites: how to protect yourself.

Ovviamente se si desidera proteggere il proprio sito web in IIS tramite un reverse proxy o si vuole utilizzare Let’s Encrypt con un Azure Web Site sarà necessario configurare Let’s Encrypt sul reverse proxy a riguardo si vedano i seguenti:

• Experiment: how to assign a domain name and activate HTTPS on a Free or Shared Azure web site un articolo di Fabrizio Accatino (della community Torino Technologies Group gemellata con ICTPower.it) in cui viene analizzato come implementare Let’s Encrpt su un Azure Free Web Site tramite un reverse proxy basato su NGINX in esecuzione su una Azure A0-Basic Virtual machine.
• Reverse Proxy With IIS and Lets Encrypt un articolo di Murray Grant che analizza come utilizzare IIS per realizzare un reverse proxy HTTPS basato sui certificati Let’s Encrypt.
• Configurazione di un Reverse Proxy con IIS un articolo di Vito Lucatorto (della community ICTPower.it) che analizza come configurare IIS per realizzare un reverse proxy.
• Setup IIS with URL Rewrite as a reverse proxy for real world apps un articolo di Paul Cociuba (Microsoft .Net Escalation Engineer) che analizza l’utilizzo di URL Rewrite in IIS per realizzare un reverse proxy.
• How-to Guide LetsEncrypt a 2012 R2 Web Application Proxy una guida che analizza l’implementazione di Let’s Encrypt nel ruolo Web Application Proxy di Windows Server 2012 R2.

Il servizio DNS è diventato uno dei cardini delle varie infrastrutture Aziendali, Active Directory si “appoggia” sul Name Server per tutta la componente Kerberos e non solo.

Le varie applicazioni aziendali hanno riferimenti FQDN anche all’interno dell’infrastruttura e del perimetro di rete Aziendale, e la navigazione Internet, da sempre richiede tale servizio.

Il DNS, appunto perché è utilizzato per la navigazione, può in qualche modo, chiaramente non da solo, fornire indicazioni su quelli che possono essere tentativi di risoluzione di siti malevoli.

Infatti alcune soluzioni commerciali di protezione si basano proprio su una gerarchia di questo servizio, mettendo a disposizione motori che forniscono esclusivamente risoluzioni per host in qualche modo “fidati”.

È interessante la lettura di questo articolo che introduce all’analisi forense dei log relativi al servizio DNS.

Dal punto di vista dell’operatività del servizio, conoscere le query che il DNS deve risolvere, permette anche di effettuare una pulizia di record dichiarati in modo statico e che nel tempo sono diventati assolutamente inutilizzati ed in generale creano soltanto confusione.

Cercheremo in questo articolo di analizzare quelle che sono le modalità di analisi del funzionamento del DNS aziendale andando a rilevare quali e quante sono le richieste che un DNS deve soddisfare nel corso del tempo.

Un’indicazione molto generica di funzionamento, tramite il PowerShell è possibile ottenerla con il Commandlet Get-DnsServerStatistics

Figura 1

Tuttavia, come si può vedere nella figura 1 vengono fornite solo informazioni molto scarne, principalmente sul numero di query effettuate per tipologia di Record ed il loro stato.

In Windows 2016 è disponibile nativamente la funzione “Enhanced DNS logging and diagnostics “un tool integrato che permette una diagnostica profonda sul funzionamento, non solo dal punto di vista della disponibilità del servizio, ma di come questo è utilizzato, le query a cui deve rispondere etc.

Dalla versione 2016, questa funzione è integrata nativamente, ma era già stata introdotta con Windows 2012 R2 per mezzo dell’installazione della KB: 2956577

Attivazione del log analitico del DNS

Di default il sistema non ha attiva questa funzione di tracing, ma deve essere abilitata mediante il registro eventi

Figura 2 attivazione della modalità di Debug

Posizionandosi nel “ramo” del log eventi “Application and Services Logs\Microsoft\Windows\DNS-Server nelle opzioni a disposizione tramite il tasto DX, esiste la possibilità di attivare il “Service and Debug Log” tramite il quale il DNS inizierà a registrare tutta la sua attività.

È importante considerare il fatto che, in installazioni molto grandi le dimensioni del file di log possono rapidamente raggiungere la soglia limite di 4Gb per registro, è bene quindi effettuare un periodo di osservazione al fine di verificare che non si raggiungano situazioni di funzionamento critiche.

Dal momento che ora tutte le attività del DNS sono tracciate nel Registro Eventi è possibile effettuarne un monitoraggio andando ad identificare il tipo di query che viene effettuata, ed anche quali hostname vengono richiesti al DNS.

Come detto in precedenza in questo modo possiamo verificare se e quali record in quanto non utilizzati possono essere con una certa sicurezza rimossi.

Figura 3 dettaglio voce del log di debug

Nella figura 3 è riportato il dettaglio di un elemento del registro eventi relativo ad una ricerca diretta per la risoluzione di www.google.com, siccome il messaggio di log vero e proprio viene archiviato sotto forma di testo è necessario estrapolarne le informazioni, dal punto di vista della diagnostica sono utili i “campi”:

• Source
• Qname
• Qtype

Il primo individua il richiedente la risoluzione, ossia il client del servizio DNS,

il secondo è l’oggetto vero e proprio della richiesta di risoluzione DNS

mentre il “campo” Qtype individua il tipo di query, secondo l’RFC che norma il servizio DNS come riportato in questa tabella

Ricerca degli eventi all’interno del registro

Come detto sopra le informazioni utili alla diagnostica sono salvate sotto forma di stringhe testuali ed in questo caso è molto utile l’utilizzo delle “Espressioni Regolari” per individuare le varie parti del messaggio.

PowerShell dal canto suo dispone di cmd-let per l’accesso al registro e permette l’uso delle Regular Expression nei suoi parametri di ricerca.

Il cmd-let usato in questo esempio per accedere al registro eventi è Get-WinEvent per mezzo del quale vengono rilevati gli eventi del registro di debug

Get-WinEvent -LogName “Microsoft-Windows-DNSServer/Analytical” -oldest

Tramite le opzioni di filtro applicate all’output, possiamo ottenere le informazioni sul tipo di query che vengono sottoposte al server

Get-WinEvent -LogName “Microsoft-Windows-DNSServer/Analytical” -Oldest | Where-Object { $_.Message -match “QTYPE=[0-9]+”} | ForEach-Object {$DnsRecords += $Matches.Values}

Figura 4 rilevazione del tipo di ricerca fatta sul DNS

Lo script riportato sopra rileva il numero di query eseguite sul DNS raggruppate per tipologia

Get-WinEvent -LogName “Microsoft-Windows-DNSServer/Analytical” -Oldest | Where-Object { $_.Message -match “QNAME=.*?; QTYPE=1”} | ForEach-Object {$DnsRecords += $Matches.Values}

Figura 5 rilevazione e raggruppamento dei nomi host richiesti al DNS

Mentre in questo caso sono rilevate le risoluzioni richieste al DNS

Le Espressioni regolari utilizzate al fine della ricerca puntuale delle occorrenze all’interno dei vari messaggi sono riportate qui sotto, e come si vede fanno parte della stringa di ricerca

• QTYPE=[0-9]+
  
• QNAME=.*?; QTYPE=1
  

Al fine di essere ragionevolmente sicuro che I parametri di ricerca siano corretti, personalmente utilizzo il sito https://regex101.com/ per verificare che l’espressione applicata sulla stringa dia i risultati voluti, il sito Regex01 riporta anche le varie indicazioni sulle strutture delle stringhe di ricerca e consente in modo interattivo di verificare la costruzione delle query valutandone la correttezza sintattica.

Nel caso in cui sia necessario monitorare diversi DNS il cmd-let permette di accedere a server remoti tramite l’opzione -computername

Logging di versioni precedenti la 2012R2

Le versioni di WindowsServer precedenti la 2012R2 non permettono la modalità di attivazione del log DNS come visto finora, per questa tipologia di sistemi è possibile attivare un log su file, funzione che è comunque rimasta anche nelle recenti versioni.

L’attivazione del log avviene tramite lo Snap-in di gestione DNS, alla voce “Debug Logging” spuntando il checkbox, di attivazione del Log.

Figura 6 attivazione log per versioni “legacy”

Sono disponibili ulteriori opzioni, come ad esempio il log delle connessioni in uscita piuttosto che quelle in ingresso, la tipologia di pacchetti, il protocollo di trasporto etc. di default non è necessario attivare il dettaglio in quanto le informazioni di base forniscono già sufficienti indicazioni per determinare eventuali problemi di funzionamento.

Figura 7 DNS log file

Il file di log riporta la descrizione delle varie componenti il log stesso, tuttavia per l’analisi del contenuto del logfile è possibile utilizzare appositi tool free come ad esempio Zedlan

Figura 8 Output Zedlan

Considerazioni

Il servizio DNS è sempre di più uno snodo nevralgico del sistema, il suo monitoraggio, così come la sua manutenzione diventano quindi imprescindibili, le indicazioni riportate sopra non sono sicuramente esaustive ma sono frutto dell’esperienza quotidiana di chi le ha scritte, ed hanno lo scopo di fornire al lettore un punto di vista differente sull’approccio alla gestione di questo servizio.

Riferimenti

https://technet.microsoft.com/en-us/library/dn800669(v=ws.11).aspx

https://blogs.technet.microsoft.com/tip_of_the_day/2016/05/16/tip-of-the-day-using-dns-analytical-logging/

https://support.microsoft.com/it-it/help/2956577/update-adds-query-logging-and-change-auditing-to-windows-dns-servers

Introduzione

Con il decreto della Presidenza del Consiglio dei Ministri del 24 ottobre 2014, pubblicato sulla Gazzetta Ufficiale n. 285 del 9 dicembre 2014 è stata aperta la strada all’attuazione sistema SPID che, come è possibile leggere sulle FAQ pubblicate sul sito governativo dedicato a SPID, rappresenta “il sistema di autenticazione che permette a cittadini ed imprese di accedere ai servizi online della pubblica amministrazione e dei privati aderenti con un’identità digitale unica“.

SPID è stato è stato progettato in conformità a eIDAS (electronic IDentification Authentication and Signature) descritto nel Regolamento UE n° 910/2014 che ha l’obiettivo di rafforzare la fiducia nelle transazioni nell’Unione Europea, fornendo una base normativa comune per interazioni elettroniche sicure fra cittadini, imprese e pubbliche amministrazioni. Le tecniche e protocolli su cui si basa SPID sono già stati sperimentati a livello europeo e adottate dai progetti sperimentali Stork e Stork II (Secure idenTity acrOss boRders linKed), a riguardo si veda SPID verso eIDAS.

Sempre come riportato nelle FAQ “l’identità SPID è costituita da credenziali (nome utente e password) che vengono rilasciate all’utente e che permettono l’accesso a tutti i servizi online”.

Per quanto riguarda le differenze tra SPID e la Carta nazionale sempre nelle FAQ viene riportato quanto segue:

“I due strumenti hanno usi e scopi in parte diversi e in questa prima fase di implementazione del sistema SPID coesisteranno.

A differenza della Carta Nazionale dei Servizi – che non è completamente dematerializzata – per l’uso dell’identità SPID non è necessario alcun lettore di carte e può essere utilizzata in diverse modalità (da computer fisso o da mobile).”

“Nella prima fase di avvio del sistema pubblico di identità digitale la necessità è quella di far coesistere il sistema di autenticazione tramite SPID con quelli già esistenti.

La progressiva implementazione del sistema da parte della pubblica amministrazione (che durerà 24 mesi) farà si che tutti i servizi online siano accessibili tramite SPID.”

SPID è diventato operativo Il 28 luglio 2015, con la Determinazione n. 44/2015 in cui sono stati emanati da AgID i quattro regolamenti (Accreditamento gestori, utilizzo identità pregresse, modalità attuative, regole tecniche) previsti dall’articolo 4, commi 2, 3 e 4, del DPCM 24 ottobre.

Il 7 ottobre 2016 è stata pubblicata la Determinazione 239/2016 che consente anche ai privati di accedere al sistema SPID in qualità di fornitori di servizi.

Le Pubbliche Amministrazioni dovranno aderire al circuito SPID per consentire l’identificazione elettronica dei cittadini per l’erogazione dei propri servizi on line entro il 31 dicembre 2017.

Per ulteriori informazioni si vedano Sistema Pubblico per la gestione dell’Identità Digitale – SPID, le FAQ su spid.gov.it, le FAQ su agid.gov.it e la pagina su Wikipedia dedicata a SPID.

Argomenti

• Architettura di SPID
• Requisiti per l’implementazione di SPID da parte di una Pubblica Amministrazione
• Procedura per l’implementazione di SPID da parte di una Pubblica Amministrazione
  • Procedura Tecnica
  • Procedura Amministrativa
• Conclusioni

Architettura di SPID

Scendendo nel dettaglio dell’architettura di SPID sono previsti tre ruoli:

• Identity provider o gestore di identità digitale (IP) che fornisce le credenziali di accesso al sistema (identità digitali) e gestisce i processi di autenticazione degli utenti. Al momento gli IP accreditati sono Aruba, Infocert, Poste, Sielte e Tim, ma qualunque soggetto in possesso dei requisiti previsti dalle norme può fare richiesta di accreditamento all’Agenzia per l’Italia Digitale (per l’elenco aggiornato degli IP si veda Identity Provider Accreditati).
• Service provider o fornitore di servizi (SP) che mette a disposizione servizi digitali accessibili tramite il login con credenziali SPID. Gli SP sono rappresentati dalle pubblica amministrazioni e dai privati aderenti.
• Attribute provider o gestore di attributi qualificati (AP) che fornisce attributi che qualificano gli utenti (stati, ruoli, titoli, cariche), finalizzati alla fruizione dei servizi, per determinati servizi o processi, infatti, potrà essere necessario dimostrare il possesso di una specifica condizione o di un particolare requisito personale o professionale. Al m omento gli AP accreditati sono il Ministero dello Sviluppo Economico (in relazione ai dati contenuti nell’indice nazionale degli indirizzi Pec delle imprese e dei professionisti), i Consigli, gli Ordini e i Collegi delle professioni regolamentate (per attestare l’iscrizione agli albi professionali), le Camere di Commercio, Industria, Artigianato e Agricoltura (per l’attestazione di cariche e incarichi societari) e l’AgID (in relazione ai dati contenuti nell’indice degli indirizzi della pubblica amministrazione e dei gestori di pubblici servizi).

L’AgID è invece chiamato a svolgere il ruolo di vigilanza sui soggetti accreditati e il ruolo di garante della federazione, gestendo il registro che rappresenta l’insieme dei soggetti che hanno sottoscritto il rapporto di fiducia.

Di seguito lo schema di funzionamento di SPID e il flusso delle interazioni tra i vari ruoli al fine di concedere all’utente l’accesso ai propri dati.

Requisiti per l’implementazione di SPID da parte di una Pubblica Amministrazione

Le Pubbliche Amministrazioni, in qualità di Service Provider, per rendere i propri servizi online accessibili tramite SPID in modo da favorire e semplificare l’utilizzo dei servizi digitali da parte di tutti i cittadini devono attenersi a quanto indicato nella Come diventare fornitore di servizi SPID del sito governativo dedicato a SPID.

Le modalità di funzionamento di SPID sono quelle previste da SAML v2 per il profilo “Web Browser SSO” – SAML V2.0 Technical Overview – Oasis par4.3.

Come riportato nella documentazione presente sul sito developers.italia.it (la comunità italiana degli sviluppatori di servizi pubblici) al link SPID – Regole Tecniche – Introduzione l’implementazione SPID deve rispettare le seguenti:

Devono essere previste le due versioni “SP-Initiated”:

• Redirect/POST binding
  
• POST/POST binding
  

Il meccanismo di autenticazione è innescato dalla richiesta inoltrata dall’utente tramite browser ad un Fornitore di Servizi (Service Provider o SP) che si rivolge al Gestore delle Identità (Identity provider o IdP) selezionato dall’utente in modalità “pull”.

La richiesta di autenticazione SAML, basata sul costrutto <AuthnRequest>, può essere inoltrata da un Service Provider all’Identity Provider usando il binding:

• HTTP Redirect
  
• HTTP POST
  

La relativa risposta SAML, basata sul costrutto <Response>, può essere, invece, inviata dall’Identity Provider al Service Provider solo tramite il binding HTTP POST.

Di seguito lo l funzionamento di un’autenticazione SPID bastata su SAML v2.0:

Come riportato sul sito developers.italia.it al link SPID – Regole Tecniche – Regole tecniche Service Provider il Service Provider deve implementare l’autenticazione in base alle seguenti indicazioni:

Il fornitore di servizi (Service Provider o SP) eroga i servizi agli utenti, richiede l’autenticazione agli Identity Provider e gestisce la procedura di autorizzazione al servizio per la realizzazione dei profili SSO previsti, SP-Initiated Redirect/POST binding e POST/POST binding, deve mettere a disposizione le seguenti interfacce:

• IAuthnResponse: ricezione delle risposte di autenticazione SAML
  
• IMetadataRetrieve: permette il reperimento dei SAML metadata del Service Provider da parte dell’Identity Provider.
  

Per quanto riguarda processamento della <Response> ovvero l’implementazione dell’interfaccia IAuthnResponse devono essere osservate le seguenti indicazioni:

Alla ricezione <Response> qualunque sia il binding utilizzato il Service Provider prima di utilizzare l’asserzione deve operare almeno le seguenti verifiche:

• controllo delle firme presenti nella <Assertion> e nella <response>;
  
• nell’elemento <SubjectConfirmationData> verificare che:
  
  • l’attributo Recipient coincida con la assertion consuming service URL a cui la <Response> è pervenuta
    
  • l’attributo NotOnOrAfter non sia scaduto;
    
  • l’attributo InResponseTo riferisca correttamente all’ID della <AuthnRequest> di richiesta
    

Il fornitore di servizi deve garantire che le asserzioni non vengano ripresentate, mantenendo il set di identificatori di richiesta (ID) usati come per le <AuthnRequest> per tutta la durata di tempo per cui l’asserzione risulta essere valida in base dell’attributo NotOnOrAfter dell’elemento <SubjectConfirmationData> presente nell’asserzione stessa.

Per quanto riguarda invece l’implementazione dell’interfaccia IMetadataRetrieve devono essere osservate le seguenti indicazioni:

Le caratteristiche del Service Provider devono essere definite attraverso metadata conformi allo standard SAML v2.0 (SAML-Metadata) e rispettare le condizioni di seguito indicate:

Nell’elemento <EntityDescriptor> devono essere presenti i seguenti attributi:

• entityID: indicante l’identificativo univoco (un URI) dell’entità
  
• ID univoco, per esempio basato su un Universally Unique Identifier (UUID) o su una combinazione origine + timestamp (quest’ultimo generato con una precisione di almeno un millesimo di secondo per garantire l’univocità)
  

L’elemento <KeyDescriptor>
contenenete il certificato della corrispondente chiave pubblica dell’entità, utile per la verifica della firma dei messaggi prodotti da tale entità nelle sue interazioni con le altre (SAML-Metadata, par. 2.4.1.1);

• deve essere l’elemento <Signature> riportante la firma sui metadata. La firma deve essere prodotta secondo il profilo specificato per SAML (SAML-Metadata, cap. 3) utilizzando chiavi RSA almeno a 1024 bit e algoritmo di digest SHA-256 o superiore;
  

Per la massima tutela della privacy dell’utente il Service Provider deve rendere minima la visibilità dei servizi effettivamente invocati. In questa logica occorre rendere ove possibile indifferenziate le richieste relative a servizi che condividono lo stesso set minimo di attributi necessari per l’autorizzazione.

Infine quanto riguarda invece la disponibilità dei Metadata devono essere osservate le seguenti indicazioni:

I metadata Identity Provider saranno disponibili per tutte le entità SPID federate attraverso l’interfaccia IMetadataRetrive alla URL https://<dominioGestoreIdentita>/metadata, ove non diversamente specificato nel Registro SPID, e saranno firmate in modalita detached dall’Agenzia per l’Italia Digitale. L’accesso deve essere effettuato utilizzando il protocollo TLS nella versione più recente disponibile.

Per quanto riguarda la sicurezza sul canale di trasmissione nei documenti REGOLAMENTO RECANTE LE REGOLE TECNICHE (articolo 4, comma 2, DPCM 24 ottobre 2014) e Avviso nr. 1 del 25 febbraio 2016 GESTIONE DELLA SICUREZZA DEL CANALE DI TRASMISSIONE viene riportato quanto segue:

Il profilo SAML SSO raccomanda l’uso di SSLv.3.0 o TLS 1.0 nei colloqui tra Asserting party (Identity Provider e Attribute Authority ), le Relying Party (Service Provider) e lo user agent. In ambito SPID si rende obbligatorio l’impiego di TLS nella versione più recente disponibile.

In relazione all’impiego di TLS (paragrafo 1.2.2.3 delle regole tecniche), al fine di fornire un riferimento più puntuale si precisa che, allo stato delle conoscenze, la versione raccomandata è la 1.2 e che, in casi particolari e temporanei, può essere adottata la versione 1.1, fermo restando che la versione 1.2 deve essere adottata lato server.

Conseguentemente, le versioni più obsolete dei browser, che non supportano le versioni del protocollo indicate, non devono essere utilizzate e, i livelli minimi accettati per l’accesso ai servizi SPID, devono essere documentati nei confronti degli utenti.

Oltre a implementare le interfacce per necessarie allo scambio d’informazioni tra SP e IP al fine di eseguire l’autenticazione sarà necessario, sia per una questione di user experience che di immagine del sistema, la standardizzazione delle interfacce, della comunicazione e dell’utilizzo del logo spid in base alle regole prodotte da AgID (a riguardo si veda il seguente LINEE GUIDA SULLE INTERFACCE E SULLE INFORMAZIONI IDP/SP).

Per quanto riguarda l’implementazione delle interfacce di comunicazione e l’adeguamento delle interfacce grafiche è possibile fare riferimento ai repository pubblicati su GitHub da developers.italia.it (la comunità italiana degli sviluppatori di servizi pubblici) disponibili all’interno del Repository GitHub Italia.

Per maggiori informazioni si vedano:

• REGOLAMENTO RECANTE LE REGOLE TECNICHE (articolo 4, comma 2, DPCM 24 ottobre 2014)
• Avvisi SPID

Procedura per l’implementazione di SPID da parte di una Pubblica Amministrazione

In sintesi una Pubblica Amministrazione (PA) per adeguare i sistemi informativi alle regole tecniche e alle regole di design dedicate a SPID deve completare due procedure, una tecnica e una amministrativa.

Procedura Tecnica

Il completamento della procedura tecnica richiede i seguenti passi.

Passo 1: implementare le interfacce di comunicazione basate su SAML v2 e adeguare le interfacce grafiche alla user experience richiesta da SPID.

A meno che la PA non abbia sviluppato in modo autonomo l’applicativo web su cui è necessario implementare SPID per renderlo accessibile in modo da favorire e semplificare l’utilizzo da parte di tutti i cittadini, tali operazioni vengono normalmente eseguite dal produttore dell’applicativo.

Passo 2: Elaborare un metadata come descritto nell’Avviso n. 6 del 29/07/2016 NOTE SUL DISPIEGAMENTO DI SPID PRESSO I GESTORI DEI SERVIZI tenendo presente che gli attributi richiesti per l’erogazione di ogni servizio online dovranno essere attinenti e non eccedenti.

A meno che PA non abbia sviluppato in modo autonomo l’applicativo web, anche in questo caso la PA dovrà coordinarsi col produttore dell’applicativo per l’elaborazione del metadata che di fatto è un documento XML contenente le informazioni necessarie per l’interfacciamento dei sistemi di un service provider con quelli delle entità con cui deve interagire (Identity provider e Attribute Provider).

Ogni service provider, secondo le regole tecniche SPID, deve mettere a disposizione un solo metadata (indipendentemente dal numero di servizi erogati dal Service Provider).

Passo 3: Dopo aver elaborato il primo metadata la PA dovrà renderlo disponibile su una url https della PA stessa e darne comunicazione segnalandolo al sistema di supporto per le pubbliche amministrazioni, selezionando la categoria “Comunicazione metadata”. Il metadata verrà verificato e, se necessario, sarà richiesto di apportare modifiche utili a garantire il rispetto delle regole tecniche, in questo caso sarà necessario ripetere la procedura di invio del metadata.

Il metadata dovrà essere firmato tramite chiavi RSA di almeno 1024 bit e algoritmo di digest SHA-256 o superiore (a riguardo si veda [SAML-Metadata] cap3).

Per la firma del metadata è possibile utilizzare un certificato a disposizione della PA con i requisiti richiesti oppure generarne uno autofirmato.

Nel Repository GitHub Italia – SPID Metadata Signer sono disponibili Tools e Scripts per la firma del metadata SAML SPID in ambienti Linux e MacOS.

Per firmare metadata SAML SPID in ambiente Windows è possibile utilizzare il porting del repository SPID Metadata Signer che ho reso disponibile GitHub al seguente SPID Metadata Signer in ambiente Windows.

Come detto precedentemente il metadata dovrà essere reso disponibile su una url https della PA come ad esempio https://<dominioGestoreIdentita>/metadata. Per assolvere a tale requisito la PA se non ha già a disposizione un sito istituzionale in https con certificato conforme ai requisiti all’interno del quale pubblicare il metadata, può acquistare un certificato o utilizzare Let’s Encrypt per ottenere un certificato tramite cui implementare la pubblicazione in https.

Per una guida su come configurare IIS, il web server nativo in Windows, per l’utilizzo ei certificati Let’s Encrypt si veda Implementazione di Let’s Encrypt in ambiente Windows Server 2016.

Se possibile per maggiore semplicità la scelta ottimale sarebbe quella di avere un host dedicato al web server che ospiterà il metadato rispondendo ad un sottodominio dedicato (per esempio spid.dominioserviceprovider) per consentire una maggior scalabilità e indipendenza della parte infrastrutturale dedicata all’autenticazione rispetto a quella dedicata alla parte applicativa.

Un server dedicato consente infatti una più semplice gestione della sicurezza permettendo di applicare configurazioni al livello del web server più restrittive e una modularità maggiore dell’infrastruttura che permette anche scenari ibridi in cui il web server che pubblica i metadati sia in cloud e il server applicativo on premisis.

Il web server che ospita il metadata dovrà infatti essere adeguatamente protetto per evitare compromissioni o mancate disponibilità del metadata stesso.

Nel caso il metadata venga esposto tramite IIS è possibile applicare una serie di best practices finalizzate all’hardenig del web server a riguardo si veda al esempio il mio post Hardening di IIS tramite le HTTP Response Headers.

Passo 4: Dopo che il metadata sarà accettato dagli Identity Provider, i servizi online potranno essere “interfacciati” a SPID per successivi test e messa in produzione.

Procedura Amministrativa

Una volta che i primi servizi interfacciati a SPID saranno pronti per essere pubblicati, il legale rappresentate della PA dovrà compilare e firmare la convenzione e dovrà essere compilato anche il file con l’indicazione dei servizi accessibili tramite SPID. Entrambi i documenti dovranno poi essere inviati all’indirizzo: protocollo@pec.agid.gov.it.

Per concludere il processo di adesione a SPID sono necessarie due figure di riferimento:

• Referente tecnico per tutte le attività di implementazione del sistema di autenticazione SPID
• Rappresentante legale per la firma della convenzione

Sicurezza

L’identità SPID è costituita da credenziali con caratteristiche differenti in base al livello di sicurezza richiesto per l’accesso. Scendendo nel dettaglio esistono tre livelli di sicurezza ognuno dei quali corrisponde a un diverso livello di identità SPID, i livelli di sicurezza di SPID corrispondono anche ad altrettanti livelli specificati nella norma internazionale ISO-IEC 29115:

• Livello 1: permette di accedere ai servizi online attraverso un nome utente e una password scelti dall’utente. A tale livello è associato un rischio moderato e compatibile con l’impiego di un sistema autenticazione a singolo fattore (password associata alla digitazione di una UserID). Il Livello 1 corrisponde al Level of Assurance LoA2 dello standard ISO/IEC DIS 29115.
• Livello 2: necessario per servizi che richiedono un grado di sicurezza maggiore permette l’accesso attraverso un nome utente e una password scelti dall’utente, più la generazione di un codice temporaneo di accesso (one time password). A tale livello è associato un rischio ragguardevole e compatibile con l’impiego di un sistema di autenticazione informatica a due fattori, non necessariamente basato su certificati digitali (password e OTP associati alla digitazione di una UserID). Il Livello 2 corrisponde al Level of Assurance LoA3 dello standard ISO/IEC DIS 29115.
• Livello 3: oltre al nome utente e la password, richiede un supporto fisico (es. smart card) per l’identificazione. A tale livello è associato un rischio altissimo e compatibile con l’impiego di un sistema di autenticazione informatica a due fattori basato su certificati digitali e criteri di custodia delle chiavi private su dispositivi che soddisfano i requisiti dell’Allegato 3 della Direttiva 1999/93/CE. Il Livello 3 corrisponde al Level of Assurance LoA4 dello standard ISO/IEC DIS 29115.

Pubbliche amministrazioni e privati definiscono autonomamente il livello di sicurezza necessario per poter accedere ai propri servizi digitali, ma ad oggi sono disponibili solo identità SPID di primo e secondo livello (come riportato nella FAQ).

Per maggiori dettagli si veda l’Avviso nr 4 del 09/06/2016 Livelli di servizio minimo per funzionalità omogenee.

Conclusioni

Come riportato nella pagina Diffusione del sistema pubblico di identità digitale (SPID) del sito governativo ItaliaSemplice.gov.it i risultati attesi sulla diffusione di SPID erano di 3 milioni di utenti con un’identità digitale a settembre 2015 e di 10 milioni di utenti a dicembre 2017.

I dati aggiornati dello Stato di attuazione dell’agenda digitale di cui SPID fa parte sono disponibili alla pagina Avanzamento Crescita Digitale e al 05/05/2017 i dati erano i seguenti:

• amministrazioni attive: 3.720
• identity provider accreditati: 5
• servizi disponibili tramite SPID: 4.273
• identità SPID erogate: 1.384.375

Sebbene i dati reali di diffusione siano per il momento al di sotto dei valori attesi non si può negare che tale sistema di autenticazione non stia prendendo piede anche grazie ad azioni di Governo, come per esempio il bonus 18App e Carta del Docente, inoltre l’obbligo per le Pubbliche Amministrazioni di aderire al circuito SPID entro il 31 dicembre 2017 darà sicuramente un’ulteriore spinta.

Un altro elemento che aumenterà la diffusione di SPIP sarà l’attivazione del Livello 3 di sicurezza la cui assenza per il momento scoraggia le grandi realtà private come gli istituti di credito ad aderire al sistema.

Per avere informazioni sulle Pubbliche Amministrazioni che erogano i servizi abilitati SPID si veda la pagina Dove puoi usare SPID.

Quando le infrastrutture informatiche assumo dimensioni consistenti o la cui complessità richiede più persone per la gestione comincia a farsi sentire l’esigenza di adottare un software per la gestione del parco informatico e del servizio di helpdesk. Un altro scenario in cui tali tipi di software sono particolarmente utili è quello in cui un fornitore di servizi informatici si trovi a dove gestire più piccole aziende con la necessità di offrire un servizio di helpdesk e anche la gestione del parco macchine e apparecchiature dei propri clienti.

Vari sono i software che propongono soluzioni in tal senso, ma molti di essi affrontano il problema tramite scansione della rete per rilevare in modo automatizzato gli asset informatici presenti, sebbene questo tipo di approccio sia in determinati scenari molto pratico in altri può non essere applicabile o comodo. Infatti in scenari in cui non tutti gli asset possono essere gestiti tramite rilevazione automatica in rete in quanto non raggiungibili o privi di interfaccia di rete o ancora perché è necessario poterli gestire prima che vengano inseriti in rete (si pensi ad esempio ad asset mantenuti in magazzino come ricambi).

Inoltre molto spesso la necessità della gestione del parco informatico parte da specifiche necessità di carattere più amministrativo che tecnico, come la gestione dei rinnovi delle garanzie, la gestione del mazzino, la gestione della posizione fisica degli asset o il computo dell’impatto dell’helpdesk declinato in base alle richieste o per tipologia di asset su cui sono avvenuti gli interventi.

Un prodotto che risponde a queste esigenze è GLPI (Gestion Libre de Parc Informatique), un progetto Open Source gratuito distribuito sotto licenza GPL che consente l’IT Asset Management, l’issue tracking system, fornisce una soluzione di service desk solution e consente la gestione di tasks amministrativi e finanziari, di seguito alcune interessanti caratteristiche:

• Gestione di Multi-entities (multi-park, multi-structure)
• Gestione Multiutenza
• Sistema di autenticazione multipla (locale, LDAP, AD, Pop/Imap, CAS, x509…) e multi servers
• Multilingual (al momento sono disponibili 45 localizzazioni)
• Gestione di Permissions e profili

Per l’elenco completo delle caratteristiche si veda FEATURES LIST OF GLPI.

GLPI è un applicazione web-based nata nel 2003 come progetto Community based a cui chiunque può contribuire tramite lo lo sviluppo di moduli su GitHub – GLPI o mediante lo sviluppo di GLPi plugins, il progetto ha subito negli anni varie evoluzioni sino ad arrivare all’attuale versione 9.1.4, di seguito la time line dell’evoluzione del progetto tratto dalla pagina Wikipedia dedicata al progetto.

Prerequisiti d’installazione di GPLI

Come riportato nel seguente Prerequisites for installing GLPI l’applicazione web ha i seguenti prerequisiti software:

• Un Web Server con supporto PHP (Apache 2 o superiore oppure Microsoft IIS)
• PHP 5.3 o superiore (si veda il seguente Web Server Prerequisites per le estensioni PHP richieste
• Database MySQL 4.23, ma è raccomando utilizzare per ragioni di performance la versione 5.5.x, in alternativa è possibile utilizzare il DBMS MariaDB (a riguardo si veda Database server Prerequisites)

Dal momento che come viene riportato in Database server Prerequisites, GLPI utilizza l’engine MyISAM non è possibile al momento utilizzare SQL Server come DBMS in quanto quest’ultimo utilizza un engine derivato da quello di Sybase SQL Server frutto di una partnership tra Microsoft e Sybase del 1987 (per maggiori dettagli sulla storia dell’evoluzione dell’engine di SQL Server si veda SQL MythBusters – “SQL Server is really a Sybase product not a Microsoft one.”).

Scenario d’installazione

Nel seguente articolo GPLI sarà installato su IIS 8.5 in Windows Server 2012 R2 utilizzando Microsoft Web Platform Installer 5.0 per installare la versione PHP 7.1.1 a 64 Bit, mentre per quanto riguarda il DBMS sarà installato MariaDB 10.2.6 a 64 Bit.

La scelta di non utilizzare MySQL ma MariaDB che è uno dei fork del primo, nato il 29 ottobre 2009, e scritto dagli sviluppatori originali di MySQL dipende dal fatto di utilizzare un DBMS totalmente OpenSource dal momento che andrà a supporto di un applicativo Open Source qual è GLPI. MySQL infatti dalla versione 5.5 include estensioni non Open Source disponibili solo nella versione Enterprise, tale evoluzione di MySQL è frutto dell’acquisizione di Sun Microsystems da parte di Oracle avvenuta il 27 gennaio 2010 (per quanto riguarda l’evoluzione di MySQL e la nascita MariaDBa riguardo si vedano le relative pagine su Wikipedia). In conseguenza al fatto che MySQL non è più un DBMS solo Open Source (esistono infatti due versioni quella Open Source denominata MySQL Community Server e quella proprietaria denominata Enterprise Server) ha portato vari progetti Open Source a sostituire MySQL con MariaDB, come ad esempio Wikipedia (a riguardo si veda Wikipedia Adopts MariaDB) e alcune distribuzioni Linux quali ad esempio Fedora e RedHat (a riguardo si veda Oracle who? Fedora & openSUSE will replace MySQL with MariaDB).

Per quanto riguarda i prerequisiti hardware dovranno essere rispettati almeno quelli consigliati per il sistema operativo (a riguardo si veda System Requirements and Installation Information for Windows Server 2012 R2):

• Processore almeno 1.4 GHz a 64-bit
• 1024 MB di Ram e nel caso una macchina virtuale in Hyper-V è preferibile utilizzare la memoria statica
• 32 GB per il volume dedicato al sistema operativo, è preferibile installare GLPI e il relativo database su un volume dedicato

Dal momento che i vari pacchetti d’installazione di PHP e MariaDB sono disponibili solo in lingua Inglese è consigliabile installare anche il sistema operativo in lingua Inglese configurando le impostazioni del formato data e ora per la nazionalità italiana. Al termine dell’installazione aggiornare il sistema installando gli aggiornamenti necessari.

Per la documentazione relativa a GLPI si faccia riferimento al Wiki del progetto, mentre per ulteriori informazioni sui prerequisiti si veda https://github.com/glpi-project/glpi mentre per informazioni sui changelog delle varie versioni si veda https://github.com/glpi-project/glpi/releases

Installazione del ruolo Web Server (IIS)

Installare il ruolo Web Server (IIS) con le impostazioni di default, al termine dell’installazione aggiornare il sistema installando gli eventuali aggiornamenti necessari.

Come indicato nei seguenti non è possibile (fatta esclusione per alcune cartelle) spostare IIS su un volume dedicato in quanto IIS è un componente di sistema:

• Do we need to install/move IIS related folders to a non-System drive?
• KB2752331 Guidance for relocation of IIS 7.0 and IIS 7.5 content directories
• IIS7: Moving the INETPUB directory to a different drive

Installazione PHP

Il modo più pratico per installare PHP è quello di utilizzare il Microsoft Web Platform Installer, attualmente è disponibile la versione 5.0 che va installata prima di poter avviare l’installazione del PHP. Per avviare l’installazione del Microsoft Web Platform Installer occorre prima disabilitare la funzionalità IE Enhanced security Configuration per il gruppo Administrators (terminata l’installazione sarà possibile riabilitare tale funzionalità).

Una volta installato il Microsoft Web Platform Installer sarà possibile installare PHP selezionando PHP 7.1.1 a 64 Bit tra i prodotti del gruppo Frameworks

L’installazione comporterà l’installazione di ulteriori package e features:

Per verificare la funzionalità di PHP è possibile creare un file phpinfo.php in %SystemDrive%\inetpub\wwwroot col seguente contenuto:

<?php phpinfo(); ?>

Aprire poi la pagina http://localhost/phpinfo.php che mostrerà le informazioni di configurazione tra cui il percorso del file ini di configurazione per default in (%ProgramFiles%\PHP\v7.1\php.ini)

Abilitazione dell’estensione PHP FileInfo e verifica delle configurazioni nel php.ini

Modificare il file %ProgramFiles%\PHP\v7.1\php.ini aggiungendo nella sezione [ExtensionList] le seguenti impostazioni:

extension=php_fileinfo.dll

zend_extension=php_opcache.dll

Come indicato nel seguente Web Server Prerequisites verificare che le seguenti variabili nel file %ProgramFiles%\PHP\v7.1\php.ini rispettino le seguenti indicazioni (le impostazioni predefinite dovrebbero essere coerenti a tali indicazioni):

memory_limit = 64M ; // Minimum Value
file_uploads = on ;
max_execution_time = 600 ; // Optional but not mandatory
register_globals = off ; // Optional but not mandatory
magic_quotes_sybase = off ;
session.auto_start = off ;
session.use_trans_sid = 0 ; // Optional but not mandatory

La versione 9.14 di GLPI richiede l’estensione apcu-bc che richiede a sua volta l’estensione APCu che può essere scaricata al seguente https://pecl.php.net/package/APCu, al momento l’ultima versione è la 5.1.8 ed occorre scaricare la release per PHP 7.1 Non Thread Safe (NTS) x64 dal momento che il PHP in IIS è configurato con l’opzione Thread Safety a disabled come suggerito in http://windows.php.net/:

“If you are using PHP as FastCGI with IIS you should use the Non-Thread Safe (NTS) versions of PHP.”

Dopo aver scaricato l’estensione apcu, scompattarla e copiare la libreria php_apcu.dll in %ProgramFiles%\PHP\v7.1\ext e quindi modificare il file %ProgramFiles%\PHP\v7.1\php.ini aggiungendo nella sezione [ExtensionList] la seguente impostazione:

extension=php_apcu.dll

Dopo aver attivato l’estensione APCu è possibile scaricare l’estensione apcu-bc al seguente https://pecl.php.net/package/apcu_bc, al momento l’ultima versione è la 1.0.3 ed occorre scaricare la release per PHP 7.1 Non Thread Safe (NTS) x64 perché come visto precedentemente IIS è configurato con l’opzione Thread Safety a disabled.

Dopo aver scaricato l’estensione apcu-bc scompattarla e copiare la libreria php_apc.dll in %ProgramFiles%\PHP\v7.1\ext e quindi modificare il file %ProgramFiles%\PHP\v7.1\php.ini aggiungendo nella sezione [ExtensionList] la seguente impostazione:

extension=php_apc.dll

Nel caso dopo l’installazione di GLPI si notino malfunzionamenti nella visualizzazione delle pagine è possibile disabilitare le estensioni APCu e apcu-bc commentando l’attivazione delle estensioni nel file php.ini dal momento che è un requisito opzionale

Per ulteriori informazioni sulle estensoni PHP in Windows si veda Installation of extensions on Windows.

Terminata l’editazione del file %ProgramFiles%\PHP\v7.1\php.ini riavviare IIS tramite lnternet Information Services (IIS) Manager (InetMgr.exe) o mediante il seguente comando:

iisreset /restart

Installazione del DBMS MariaDB

Scaricare dal sito http://mariadb.org (la pagina di download è disponibile al seguente https://downloads.mariadb.org/) il package per piattaforma Windows a 64 Bit dell’ultima versione di MariaDB, al momento l’ultima versione stabile è la 10.2.6 (mariadb-10.2.6-winx64.msi), come riportato la versione 10.2 ha oltre alla features di MySQL 5.6 & 5.7 anche nuove funzionalità. Sebbene esista anche un package ZIP (mariadb-10.2.6-winx64.zip) questo è indicato solo per semplici scenari di test, ma è meno preformante dell’installazione come servizio e meno sicuro, a riguardo si veda Installing MariaDB Windows ZIP Packages.

Avviare l’installazione di MariaDB 10.2.26 64 Bit eseguendo il package msi con le seguenti impostazioni (per la documentazione sulla procedura d’installazione si veda Installing MariaDB MSI Packages on Windows).

Accettare l’installazione delle funzionalità di default.

Selezionare Database instance per impostare il path dei file di dati tramite il pulsante Browse, nello scenario di esempio saranno memorizzati in S:\MariaDB 10.2\data.

Impostare la password dell’utente root che dovrà essere utilizzato solo motivi amministrativi

Impostare le proprietà dell’istanza configurandola come servizio come raccomandato e se non è necessario connettersi remotamente al DBMS disabilitare l’opzione di networking (come nel caso dello scenario di esempio in quanto GLPI sarà installato sullo stesso server), in questo caso per la connessione al database sarà utilizzato named pipes. GLPI per ora non utilizza InnoDB a riguardo si vedano Closing ticket time issue #1150 e Change storage engine to innodb #644.

Per informazioni sulle impostazioni si vedano le seguenti note riportate in Installing MariaDB MSI Packages on Windows:

Per modificare successivamente le impostazioni è possibili intervenire successivamente editando il file my.ini memorizzato nella directory d’installazione (nello scenario di esempio S:\MariaDB 10.2\data), per informazioni sulla configurazione tramite file d’impostazioni si vedano:

• Configuring MariaDB with my.cnf
• Configuring MariaDB for Remote Client Access

Per connettersi all’istanza di MariaDB è possibile utilizzare HeidiSQL, installato per default insieme a MariaDB, configurando una connessione localmente tramite named pipe, come nello scenario d’esempio.

Installazione dell’applicazione GLPI

Scaricare l’ultima versione di GLPI dal sito http://glpi-project.org (la pagina di download è disponibile al seguente http://glpi-project.org/spip.php?article41), al momento l’ultima versione è la 9.1.4 (glpi-9.1.4.tgz). Estrarre il package tgz, ad esempio tramite 7Zip, e copiare la cartella glpi in locale, nello scenario di esempio verrà copiata in S:\glpi-9.1.4\glpi. Quindi creare in IIS all’interno del Default Web Site una Virtual Directory che punta alla cartella gpli in modo da mantenere l’applicazione su un volume diverso da quello del sistema operativo.

Aprire il sito http://localhost/glpi per eseguire la prima parte dell’installazione di GLPI che creerà il database.

Selezionare la localizzazione italiana.

Accettare la licenza (GNU General Public License Versione 2).

Selezionare Installa.

Controllare che tutte le verifiche siano eseguite con successo.

Inserire le credenziali per accedere all’istanza locale (.)del DBMS MariaDB tramite named pipe con l’account root per creare il database.

Creare un nuovo database, nello scenario di esempio sarà denominato glpi.

Attendere la creazione del database.

Attendere il termine dell’istallazione.

Terminata l’installazione sarà possibile accedere a GLPI tramite la pagina http://localhost/glpi autenticandosi con l’account di amministrazione di default (username=glpi e password=glpi) per iniziare a configurare l’applicazione.

Per ragioni di sicurezza cancellare il seguente file: install/install.php (nello scenario di esempio S:\glpi\install\install.php) e modificare le password degli utenti predefiniti glpi, post-only, tech e normal.

Creazione di un utente per l’accesso al database di GLPI da parte dell’applicazione

Creare tramite HeidiSQL un utente che verrà poi utilizzato dall’applicazione GLPI per accesso locale con soli i privilegi sul database di GLPI, nello scenario di esempio il database è denominato glpi mentre l’utente sarà denominato UsrGLPI.

Impostare le credenziali dell’utente per l’accesso al database GLPI tramite la seguente procedura:

• Arrestare IIS tramite Internet Information Services (IIS) Manager o mediante il comando: iisreset /stop
• Impostare le credenziali dell’utente nel file config\config_db.php (nello scenario di esempio S:\glpi-9.1.4\glpi\config\config_db.php)
• Avviare IIS tramite Internet Information Services (IIS) Manager o mediante il comando: iisreset /start

Gestione dei Plugin

Come anticipato all’inizio dell’articolo le funzionalità di GLPI possono essere estese tramite plugins sviluppati da volontari che contribuiscono al progetto, per il catalogo dei plugins disponibili si veda la Plugin directory, mentre se si intende cimentarsi nello sviluppo di un plugin è possibile trovare informazioni utili ai seguenti:

• Plugin development documentation
• GLPI example
• Plugins GLPI-PROJECT
• GLPi Plugin Directory API

Per quanto riguarda l’installazione di un plugin l’operazione è descritta al seguente Plugin installation Procedure in GLPI e consiste nelle seguenti operazioni:

1. Eseguire un backup del database (tramite il menù Amministrazione\Manutenzione)
2. Scaricare il plugin dalla directory GLPI plugins verificando che sia compatibili con la versione di GLPI installata
3. Estrarre il file .tar.gz in una sottocartella col nome del plugin nella directory glpi/plugins dell’applicazione, per estrarre i file .tar.gz è possibile utilizzare ad esempio 7Zip (il nome della cartella del plugin deve rispettare quello presente all’interno del file .tar.gz altrimenti il plugin potrebbe non funzionare correttamente)
4. Eseguire il Log off ed un successivo Log in
   
5. Installare il plugin tramite il menu Configurazione\Plugins selezinando Installa in corrispondenza del plugin
6. Attivare il plugin selezinando Attiva in corrispondenza del plugin

Alcuni plugin necessitano di modifiche al database, che verranno eseguite al primo avvio dello stesso, oppure possono essere necessarie configurazion, in questo caso vi saranno avvisi nella pagina dell’installazione/attivazione del plugin.

L’aggiornamento di un plugin è sostanzialmente simile all’installazione, ma con le precauzioni necessarie per consentire un eventuale ripristino alla versione precedente, di seguito le operazioni da eseguire:

1. Eseguire un backup del database (tramite il menù Amministrazione\Manutenzione) o delle tabelle create dal plugin che dovrebbero essere specificate nel file readme nella directori del plugin syessto (glpi/plugins/<pluginName>)
2. Rinominare la directory del plugin per esempio da glpi/plugins/<pluginName> a glpi/plugins/<pluginName-Versione>
3. Procedere nuovamente all’installazione del plugin come visto precedentemente

Se si intende invece rimuovere un plugin è possibile procedere come segue:

1. Eseguire un backup del database (tramite il menù Amministrazione\Manutenzione)
2. Accedere all’elenco dei plugin installati tramite il menu Configurazione\PluginsS
3. Selezionare Disinstalla in corrispondenza del plugin da rimuovere

Si noti che ovviamente l’utilizzo dei plugin comporterà il controllo che questi siano supportati anche nelle future release di GLPI quanto verranno rilasciate e si deciderà di installarle.

Conclusioni

Grazie al Microsoft Web Platform Installer 5.0 che permette di installare velocemente applicazioni PHP in Windows l’installazione di GLPI si risolve velocemente. Con Windows Server 2016 e la sua integrazione nativa con i container Docker tale installazione potrà ulteriormente essere semplificata. Su GitHub sono infatti presenti vari progetti con la finalità di realizzare container Docker per GLPI, si veda ad esempio driket/docker-glpi – Deploy GLPI (any version) with Docker.

GLPI (Gestion Libre de Parc Informatique) è un progetto Open Source gratuito distribuito sotto licenza GPL che consente l’IT Asset Management, l’issue tracking system, fornisce una soluzione di service desk solution e consente la gestione di tasks amministrativi e finanziari. Tali attività normalmente vengono assegnate a persone differenti e nel caso in cui in cui GLPI venga utilizzato in un’infrastruttura basata su Active Directory diventa comodo integrare l’autenticazione Windows con l’autenticazione GLPI sfruttando LDAP (Lightweight Directory Access Protocol).

Di seguito verranno descritti i passi per configurare l’autenticazione basata su LDAP in GLPI 9.1.4 installato in IIS con PHP 7.1.1 in ambiente Windows Server 2012 R2.

Configurazione di IIS e PHP per il supporto dell’autenticazione Windows

Perché IIS possa gestire l’autenticazione Windows utilizzando gli utenti Active Directory il server che ospita IIS dovrà essere membro del dominio come indicato nella KB258063 Internet Explorer May Prompt You for a Password:

Windows Integrated authentication, also known as Windows NT Challenge/Response, must be enabled in the Web site properties in IIS. Anonymous authentication is attempted first, followed by Windows Integrated authentication, Digest authentication (if applicable), and finally Basic (clear text) authentication.

Both the client and the Web server must be either in the same Microsoft Windows NT-based or Microsoft Windows 2000-based domain or in trusted Windows NT-based or Windows 2000-based domains in which the user’s account can be granted permissions to resources on the IIS-based computer.

Inoltre sul server che ospita IIS dovrà essere installata la componete Windows Authentication di IIS:

Per abilitare in PHP l’autenticazione integrata di Windows abilitare l’estensione LDAP modificando il file %ProgramFiles%\PHP\v7.1\php.ini aggiungendo nella sezione [ExtensionList] la seguente impostazione:

extension=php_ldap.dll

Terminata l’editazione del file %ProgramFiles%\PHP\v7.1\php.ini riavviare IIS tramite lnternet Information Services (IIS) Manager (InetMgr.exe) o mediante il seguente comando:

iisreset /restart

Per ulteriori informazioni si veda IIS Configuration Reference – Windows Authentication.

Configurazione di GLPI per l’utilizzo di LDAP

Per default GLPI ha già delle configurazioni per la gestione degli utenti provenienti da una fonte esterna come LDAP, in particolare le opzioni Aggiunge automaticamente utenti da fonte esterna di autenticazione e Aggiungi un utente senza diritti da LDAP consentono di aggiungere automaticamente gli utenti al primo accesso con profilo di sicurezza Self-Service, se si preferisce gestire l’accesso manualmente impostare a No tali opzioni.

La prima operazione da eseguire è configurare GLPI per l’utilizzo di LDAP sul proprio dominio per la ricerca di utenti e gruppi nella Organizational Unit che conterrà gli utenti che dovranno accedere a GLPI, configurando come segue:

Nel campo Server è possibile specificare il dominio che verrà così risolto con gli indirizzi IP dei vari Domain Controller, mentre nel campo Filtro Connessione specificare la query LDAP che consente di ricercare gli utenti non disabilitati:

(&(objectClass=user)(objectCategory=person)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))

Nel campo BaseDN specificare il path LDAP della Organizational Unit che conterrà gli utenti che dovranno accedere a GLPI, mentre nei campi RootDN e Password specificare le credenziali di un utente a minimi privilegi che verrà utilizzato per eseguire le query LDAP su Active Direcory. Infine nel campo Nome utente specificare l’attributo utente che idendifica il logon name ovvero samaccountname (per default GLPI propone uid).

Inoltre configurare la ricerca dei gruppi come segue

Nel campo Tipo ricerca specificare che la ricerca verrà eseguita nei gruppi, mentre nel campo Filtro di ricerca nei gruppi specificare la seguente query LDAP:

(&(objectCategory=group))

Terminata la configurazione delle impostazioni relative alla Directory LDAP eseguire un test di connessione verso Active Directory con l’opzione Test. Per ulteriori informazioni si veda GLPI, LDAP and Active Directory.

Configurare gli utenti Active Directory in GLPI

Per accedere a GLPI tramite gli utenti Active Directory specificando le autorizzazioni necessari occorre prima aggiungerli tramite il Menù Amministrazione – Utenti selezionando l’opzione Collegamento a directory LDAP e quindi l’opzione Importa nuovi utenti:

In alternativa è possibile far sì che GLPI aggiunga automaticamente gli utenti al primo accesso con profilo di sicurezza Self-Service, come visto precedente.

Abilitazione autenticazione Windows in IIS

Di seguito si ipotizzerà che GLPI è stato installato in una Virtual Directory denominata glpi su cui occorrerà disabilitare l’autenticazione anonima e abitare l’autenticazione Windows tramite lnternet Information Services (IIS) Manager (InetMgr.exe)

Per testare che l’autenticazione Windows funziona correttamente e che l’utente viene trasmesso dal browser al server è possibile creare nella Virtual Directory un file php denominato ad esempio TestAuth.php con seguente contenuto:

<?php

echo “REMOTE_USER = ” . $_SERVER [“REMOTE_USER”] . “<BR />”;

echo “HTTP_AUTH_USER = ” . $_SERVER [“HTTP_AUTH_USER”] . “<BR />”;

echo “PHP_AUTH_USER = ” . $_SERVER [“PHP_AUTH_USER”] . “<BR />”;

echo “USERNAME = ” . $_SERVER [“USERNAME”] . “<BR />”;

echo “REDIRECT_REMOTE_USER” . $_SERVER [“REDIRECT_REMOTE_USER”];

?>

Configurazione GLPI per l’autenticazione automatica

Per far sì che l’utente con cui ci si è autenticati sul client venga passato al server su cui è installato GLPI è necessario configurare come segue l’invio dell’autenticazione nella richiesta http mediante il menù Configurazione – Altri metodi di autenticazione:

In Campo per la registrazione dell’accesso nella richiesta HTTP impostare REMOTE_USER. Dopo aver eseguito tali impostazioni gli utenti a cui è stato consenti l’accesso a GLPI in modo manuale o automatico avranno accesso senza più dover inserire le credenziali, in ogni caso sarà ancora possibile accedere alla pagina di login mediante il seguente url:

http://hostname.domain.ext/glpi/index.php?noAUTO=1

Per maggiori informazioni si veda Automatic authentication

Conclusioni

La gestione dell’autenticazione integrata di Windows in GLPI prevede la configurazione della stessa nei vari componenti quindi in IIS, PHP e GLPI, ma consente un’interessante integrazione con l’infrastruttura Active Directory. Nel caso in cui si riscontrino malfunzionamenti nell’accesso a GLPI mediante l’autenticazione integrata di Windows si provi a chiudere tutte le sessioni dei browser e quindi a tentare nuovamente l’accesso, inoltre per identificare eventuali problemi si provi ad esaminare il file \files\_log\php-errors.log.

GLPI (Gestion Libre de Parc Informatique) è un progetto Open Source gratuito distribuito sotto licenza GPL che consente l’IT Asset Management, l’issue tracking system, fornisce una soluzione di service desk solution e consente la gestione di tasks amministrativi e finanziari. Dal momento che il servizio di l’IT Asset Management e/o di issue tracking system, quando implementate all’interno di un’infrastruttura informatica, assumono un’importanza rilevate ai fini della gestione occorre pianificare un’adeguata politica di backup.

Di seguito verrà analizzato come gestire il backup di GLPI 9.1.4 installato in IIS con PHP 7.1.1 su MariaDB 10.2.7 in ambiente Windows Server 2012 R2, inoltre si ipotizzerà che i file di GLPI siano memorizzati in S:\GLPI e che il database sia stato creato col nome glpi.

Funzionalità di backup in GLPI

GLPI offre nativamente la possibilità di eseguire il backup del database tramite il menu Amministrazione – Manutenzione

Tale backup permette di creare un dump sql o XML del contenuto del database, ma come riportato nella pagina WIKI Data/Backup del progetto GLPI al momento non è possibile automatizzare tale operazione, che può quinti tornare utile per backup estemporanei da eseguire prima di operazioni per cui è consigliabile avere una copia di sicurezza del database.

I backup eseguiti tramite l’interfaccia web di GLPI vengono conservati nella subdirectory files\_dumps della cartella d’installazione, è possibile copiarli e incollarli per esempio per gestire il restore su un server differente ad esempio per creare ambienti di test.

Backup del database di GLPI tramite script

Dal momento che come visto precedentemente il backup nativo di GLPI non offre la possibilità di essere eseguito in base ad una schedulazione, per una gestione automatizzata del processo di backup occorrerà creare degli appositi script da eseguire in base ad un’opportuna pianificazione. Di seguito si analizzerà come creare uno script per il backup del database di GLPI ipotizzando che, come detto precedentemente, quest’ultimo sia esposto dal DBMS MariaDB 10.2.7.

In MariaDB 10.2.7 è stato introdotto il tool di backup mariabackup in versione Beta basato su Percona XtraBackup 2.3.8, a riguardo si vedano About MariaDB Backup e MariaDB Backup released with MariaDB Server 10.1.23. Tramite mariabackup è possibile gestire tramite script le operazioni di backup del DBMS MariaDB, di seguito uno script Powershell per il backup gestito dell’intero DBMS MariaDB con possibilità di gestione del numero minimo di backup da mantenere, lo script prevede l’utilizzo dei parametri per poter essere gestito nell’ambito di un’automazione del backup del server GLPI che prevede più step.

Param(
[string]$MariaBackupFile,
[string]$BackupRoot,
[string]$MariaDBHost,
[string]$User,
[string]$Password,
[uint32]$BackupsRetained
)

Set-strictmode -version latest

# Impostazioni di Test
#$MariaBackupFile= $env:ProgramFiles + “\MariaDB 10.2\bin\mariabackup.exe”
#$BackupRoot=”Z:\Backup-MariaDB”
#$MariaDBHost=”.”
#$User=”root”
#$Password=”P@assW0rd!”
#$BackupsRetained = 10

# Inizializzazione Backup
$BackupPath=$BackupRoot + “\” + (Get-Date -format yyyy-MM-dd)
If (Test-Path $BackupPath) {Remove-Item $BackupPath -Force -Recurse}
New-Item -ItemType Directory -Force -Path $BackupPath

# Avvio backup MariaDB
$TargetArg = “–target-dir=” + $BackupPath
$MariaDBHostArg = “–host=” + $MariaDBHost
$UserArg = “–user=” + $User
$PasswordArg = “–password=” + $password

Start-Process -NoNewWindow -Wait -FilePath $MariaBackupFile -ArgumentList “–backup”, $TargetArg, $MariaDBHostArg, $UserArg, $PasswordArg

# Eliminazione backup obsoleti
$BackupDirectories = (Get-ChildItem -Directory $BackupRoot | Sort FullName)
$BackupsCount = ($BackupDirectories | Measure-Object).Count

If ($BackupsCount -gt $BackupsRetained){
For ($i = 1; $i -le $BackupsCount – $BackupsRetained; $i++) {
Remove-Item $BackupDirectories[$i-1].FullName -Force –Recurse
}
}

Lo script è disponibile nel repository GitHub ermannog/PowerShell/Backup-GLPI col nome Backup-MariaDB.ps1.

In alternativa è anche possibile ovviamente eseguire solo il backup del database di GLPI, di seguito uno script Powershell per il backup gestito del singolo database di GLPI con possibilità di gestione del numero minimo di backup da mantenere, lo script prevede l’utilizzo dei parametri per poter essere gestito nell’ambito di un’automazione del backup del server GLPI che prevede più step.

Param(
[string]$MariaBackupFile,
[string]$BackupRoot,
[string]$MariaDBHost,
[string]$GLPIDatabaseName,
[string]$User,
[string]$Password,
[uint32]$BackupsRetained
)

Set-strictmode -version latest

# Impostazioni di Test
#$MariaBackupFile= $env:ProgramFiles + “\MariaDB 10.2\bin\mariabackup.exe”
#$BackupRoot=”Z:\Backup-MariaDB”
#$GLPIDatabaseName=”glpi”
#$User=”root”
#$Password=”P@assW0rd!”
#$BackupsRetained = 10

# Inizializzazione Backup
$BackupPath=$BackupRoot + “\” + (Get-Date -format yyyy-MM-dd)
If (Test-Path $BackupPath) {Remove-Item $BackupPath -Force -Recurse}
New-Item -ItemType Directory -Force -Path $BackupPath

# Avvio backup Database GLPI
$TargetArg = “–target-dir=” + $BackupPath
$MariaDBHostArg = “–host=” + $MariaDBHost
$GLPIDatabaseNameArg = “–databases=” + $GLPIDatabaseName
$UserArg = “–user=” + $User
$PasswordArg = “–password=” + $password

Start-Process -NoNewWindow -Wait -FilePath $MariaBackupFile -ArgumentList “–backup”, $TargetArg, $MariaDBHostArg, $GLPIDatabaseNameArg, $UserArg, $PasswordArg

# Eliminazione backup obsoleti
$BackupDirectories = (Get-ChildItem -Directory $BackupRoot | Sort FullName)
$BackupsCount = ($BackupDirectories | Measure-Object).Count

If ($BackupsCount -gt $BackupsRetained){
For ($i = 1; $i -le $BackupsCount – $BackupsRetained; $i++) {
Remove-Item $BackupDirectories[$i-1].FullName -Force –Recurse
}
}

Lo script è disponibile nel repository GitHub ermannog/PowerShell/Backup-GLPI col nome Backup-DB-GLPI.ps1.

Backup dell’applicazione web GLPI tramite script

Dopo aver eseguito il backup del database di GLPI occorre anche eseguire il backup dell’applicazione web, di seguito uno script Powershell per il backup gestito dell’applicazione GLPI con possibilità di gestione del numero minimo di backup da mantenere, lo script prevede l’utilizzo dei parametri per poter essere gestito nell’ambito di un’automazione del backup del server GLPI che prevede più step.

Param(
[string]$BackupRoot,
[string]$WebApplicationPath,
[string]$WebSiteName,
[uint32]$BackupsRetained
)

Set-strictmode -version latest

# Impostazioni di Test
#$BackupRoot=”Z:\Backup-WebApplication-GLPI”
#$GLPIWebApplicationPath=”C:\inetpub\wwwroot\glpi”

#$WebSiteName=”Default Web Site”
#$BackupsRetained = 10

# Inizializzazione Backup
$BackupPath=$BackupRoot + “\” + (Get-Date -format yyyy-MM-dd)
If (Test-Path $BackupPath) {Remove-Item $BackupPath -Force -Recurse}
New-Item -ItemType Directory -Force -Path $BackupPath

# Arresto Web Site
Stop-WebSite $WebSiteName

# Avvio Backup Web Application GLPI
Copy-Item -Path $WebApplicationPath -Destination $BackupPath –Recurse

# Avvio Web Site
Start-WebSite $WebSiteName

# Eliminazione backup obsoleti
$BackupDirectories = (Get-ChildItem -Directory $BackupRoot | Sort FullName)
$BackupsCount = ($BackupDirectories | Measure-Object).Count

If ($BackupsCount -gt $BackupsRetained){
For ($i = 1; $i -le $BackupsCount – $BackupsRetained; $i++) {
Remove-Item $BackupDirectories[$i-1].FullName -Force –Recurse
}
}

Lo script è disponibile nel repository GitHub ermannog/PowerShell/Backup-GLPI col nome Backup-WebApplication-GLPI.ps1.

Backup del sistema del server GLPI

Oltre al backup del database e dell’applicazione web di GLPI è consigliabile eseguire un backup dell’intero sistema per gestire anche eventuali disaster recovery. Per gestire tali scenari di ripristino è ovviamente consigliabile che il server GLPI sia una macchina virtuale in modo da poter gestire il backup del sistema con vari approcci.

Un primo modo di eseguire il backup dell’intero sistema è quello di utilizzare Windows Backup dedicandogli ad esempio un disco virtuale. Nel la macchina virtuale del server GLPI sia in esecuzione in Hyper-V conviene connettere il disco virtuale su un controller virtuale SCSI in quanto permette di gestire tramite script la connessione e la disconnessione del VHD a caldo per copiare lo stesso su un server di backup.

In alternativa è possibile eseguire il backup dall’Hypervisor e nel caso che quest’ultimo sia Hyper-V tramite Windows Backup o altri software di backup come ad esempio System Center 2016 Data Protection Manager, Veeam Backup & Replication.

Conclusioni

La gestione del backup di GLPI in ambiente Windows non risulta eccessivamente complessa e può essere automatizzata tramite scripts PowerShell, per un recupero dei dati più semplice conviene eseguire il backup con vari livelli di granularità per consentire il ripristino di dati in tabelle, database, applicazione o intero sistema.

Può essere necessario attivare un servizio di scambio file in modo che utenti, anche esterni, abbiano la possibilità, di effettuare trasferimenti di archivi magari anche per mezzo di procedure schedulate.

Tramite il demone SSH è possibile configurare un servizio di scambio file analogamente al vecchio ed ormai in disuso FTP.

L’utilizzo di SSH in questo caso garantisce maggior riservatezza e sicurezza nella connessione in quanto la comunicazione avviene su in canale cifrato tramite la porta 22 tipica di questo servizio.

Questa peculiarità rende anche le configurazioni relative all’ambiente di protezione più semplici, ovviando alle fastidiose configurazioni necessarie per consentire il traffico in porta 20 e 21 tipiche dell’FTP, oppure all’attivazione della modalità passiva lato client.

Come visto in questo Post tramite SSH è possibile configurare un sistema che realizzi un tunnel in modo da Bypassare eventuali sistemi di sicurezza ed accedere in modo trasparente ad un sistema che è “dietro” ad un Firewall e non accessibile altrimenti.

Nel caso dell’implementazione del servizio SFTP tramite il demone SSH è bene tenere presente questa peculiarità ed adottare alcuni accorgimenti di sicurezza che impediscono, sulla base dell’appartenenza ad un gruppo, l’utilizzo della funzione di Tunnel.

Sempre in un’ottica di robustezza di accesso al servizio, è bene considerare la possibilità che le cartelle definite accessibili per lo scambio di file, siano confinate in un ambiente CHROOT e che gli utenti, con i permessi di accesso allo scambio file, possano esclusivamente accedere a questa funzione, ma non possano in alcun modo avere accesso tramite SSH alla shell del sistema operativo anche se con permessi limitati.

Le configurazioni qui sotto proposte, tengono conto di queste premesse e definiscono un ambiente il più “sicuro” possibile.

Le configurazioni sono effettuate nel file conf del servizio SSHD e più precisamente nel file sshd_config

(in questo esempio è presa come riferimento la Distro Linux Centos 7.x) posizionato in /etc/ssh e per mezzo dei comandi groupadd e useradd verranno creati il gruppo e gli utenti che dovranno accedere alle cartelle in “share”.

Il gruppo creato per concedere il permesso di accesso è FtpScambioFile e verrà creata in / ( root) una cartella /ScambioFiles dove verrà definita in configurazione la root dell’ambiente Chroot per SFTP al di sotto della quale saranno create una o più cartelle per l’archiviazione vera e propria

Per prima cosa è necessario creare il gruppo con il comando groupadd e successivamente la cartella dell’archivio SFTP (che può essere in un punto qualunque del Filesystem per comodità in questo esempio la creeremo in /) e le sottocartelle accessibili in lettura/scrittura

Sudo groupadd FtpScambioFile

sudo mkdir /ScambioFiles/

sudo chown root:root /ScambioFiles/

sudo chmod 755 /ScambioFiles/

la cartella ScambioFiles deve avere come proprietario l’utente root, ed i permessi come nell’esempio sopra, nel caso questo passo non venisse completato, l’accesso risulterebbe impossibile e all’interno di /var/log/secure verrebbe evidenziato un errore

A questo punto è possibile procedere con la creazione di una ulteriore sottocartella utilizzata per il trasferimento dei file e dei relativi permessi

sudo mkdir /ScambioFiles/Scambio

sudo chown root:FtpScambioFile /ScambioFiles/Scambio/

sudo chmod 775 /ScambioFiles/Scambio/

Terminata la prima parte della configurazione, ossia quella relativa alla creazione della struttura delle cartelle e dei relativi permessi, si può proseguire con la configurazione del file sshd_config come nell’immagine qui sotto.

Al termine del file nella sezione # override default of no subsystems commentare la riga presente come indicato al punto 1

Successivamente inserire le seguenti righe di configurazione

Subsystem sftp internal-sftp

Match Group FtpScambioFile

ForceCommand internal-sftp

ChrootDirectory /ScambioFiles/

PermitTunnel no

AllowAgentForwarding no

AllowTcpForwarding no

X11Forwarding no

La dichiarazione al punto 2 imposta il servizio per operare anche come un SFTP server.

Al punto 3 sono indicati il nome del gruppo, il percorso della root del CHROOT e la modalità operativa del servizio SFTP (per dettagli ulteriori consultare la pagina help disponibile sul sistema man sshd_config di cui il testo sotto è un estratto)

# man sshd_config |grep internal

Specifying a command of “internal-sftp” will force the use of an in-process sftp server that requires no support files when used with ChrootDirectory. Alternately the name “internal-sftp” implements an in-process “sftp” server. This may simplify configurations using ChrootDirectory to force a different filesystem root on clients.

A questo punto è sufficiente riavviare il servizio ssh con il comando

systemctl restart sshd.service

e procedere alla creazione dei singoli utenti che accederanno al servizio

sudo adduser -g FtpScambioFile <nome_utente>

sudo passwd <nome_utente>

tramite un client SFTP come ad esempio Filezilla è possibile accedere all’ambiente appena creato, anche nella pagina di Download di Putty è disponibile un eseguibile che da linea di comando può essere di aiuto per script vari.

Considerazioni:

E’ ancora prassi comune l’utilizzo di protocolli poco sicuri per il trasferimento di file come ad esempio FTP.

La soluzione proposta, che parte da un’esigenza ben specifica, ha permesso di salvaguardare da un lato la necessità di avere a disposizione determinate informazioni, e dall’altro di salvaguardare la sicurezza delle stesse permettendone la trasmissione all’interno di un canale cifrato.

Nel sondaggio condotto da Gartner del 17 marzo 2017 sull’adozione di Windows 10 in vendita al seguente User Survey Analysis: Windows 10 Migration Looks Healthy si stima che l’85% delle aziende hanno iniziato la migrazione a Windows 10 e la porteranno a termine entro la fine del 2017, il sondaggio è stato condotto alla fine del 2016 su 1000 aziende di sei paesi.

In un secondo sondaggio eseguito da Dimensional Research sull’adozione di Windows 10 commissionato da Ivanti pubblicato il 27 aprile 2017 al seguente Windows 10 Adoption is Quickly Accelerating but Plagued with Concerns, Reports New Ivanti State of Windows 10 Adoption Survey si stima che il 91% delle organizzazioni IT hanno iniziato l’adozione di Windows 10, il sondaggio è stato condotto su 1.800 professionisti IT di tutto il mondo.

Ed Bott, Microsoft MVP e giornalista autore di libri su tecnologie Microsoft da più di 25 anni, ha analizzato il sondaggio di Gartner e lo ha confrontato con il sondaggio di Dimensional Research e ha condiviso alcune interessanti informazioni che ermergono dai sondaggi nell’articolo Windows 10 Upgrades Accelerate, Yet Many IT Pros Have Concerns pubblicato da Redmond Magazine:

• Secondo Gartner il tempo di deploy di Windows 10 in una azienda che è di circa 21 mesi e secondo Dimensional Research il 77% delle organizzazioni intende completare la migrazione in due anni
• Secondo Dimensional Research gli ostacoli all’adozione di Windows 10 sono dovuti per il 50% al software legacy e per il 26% a fornitori di applicazioni di terze parti
• Secondo Gartner un quarto delle aziende non intraprende l’adozione di Windows 10 a causa del budget limitato in quanto non considera tale attività business-critical
• Secondo Dimensional Research il 60% riferisce che i tempi di logon in Windows 10 sono più veloci e il 16% che sono molto più veloci

Da entrambi i sondaggi, come riferisce Ed Bott, emerge una sorprendente popolarità di Windows 10 Long-Term Servicing Branch (LTSB). Secondo Dimensional Research una azienda su cinque e il il 27% delle aziende con più di 5.000 prevede di distribuire LTSB. Di seguito le considerazioni di Ed Bott a riguardo di questo aspetto sulle statistiche di adozione di Windows 10:

“Those numbers must be causing sleepless nights and even a few ulcers among product planners in Redmond. Microsoft is positioning the LTSB as a special-purpose distribution, one that should be reserved for hardware running mission-critical applications where stability is paramount.

But these findings suggest that enterprise admins are planning to use the LTSB to justify holding off because of what they perceive as the chaos of the new twice-yearly schedule for Windows 10 feature updates.

As Windows 10 nears its second anniversary, Microsoft has made some concessions to those skittish admins. With careful planning, an organization can stay on a single release in the Current Branch for Business for up to 18 months.

For IT admins who are used to planning upgrades every five years, that still feels much too fast.”

La scelta tra services models CCB (Current Branch for Business) o LTSB (Long Term Servicing Branch) che da luglio sono diventati rispettivamente Semi-Annual Channel e Long-Term Servicing Channel (a riguardo si veda il post Novità nei Microsoft servicing models è da valutare attentamente.

Innanzitutto va precisato che LTSB/LTSC è adottabile solo da quelle aziende che hanno la possibilità di utilizzare l’edizione Windows 10 Enterprise in quanto LTSB è una versione dell’edizione Enterprise, quindi occorre avere una Software Assurance attiva sul sistema operativo. Di conseguenza i ragionamenti che seguiranno possono essere applicati ad aziende che sono titolari di contratti multilicenza o aderiscono al programma Cloud Solution Provider (a riguardo si veda il seguente link https://www.microsoft.com/it-it/windowsforbusiness/buy).

Scendendo nel dettaglio Windows 10 LTSB è una versione di Windows 10 priva di alcune caratteristiche, ma per il resto è di fatto una versione Enterprise comprensiva di tutte le caratteristiche di sicurezza avanzate quali Device Guard, Windows Information Protection, Windows Defender ATP con un supporto supporto è di 10 anni dalla data di rilascio di una build contro i 18 mesi del service model Semi-Annual Channel. Quindi LTSB garantisce per 10 anni il rilascio di aggiornamenti di sicurezza e aggiornamenti qualitativi

Le caratteristiche non disponibili e le limitazioni nella versione LTSB sono:

• Tutte le app cosiddette “first party” come ad esempio posta, calendario, news, meteo, camera
• Lo Store anche se è possibile aggiungere app in quanto il framework per eseguirle è presente
• Non può essere aggiornata alla build successiva tramite Windows Update, ma solo da strumenti quali WSUS, SCCM o di terze parti
• Non è presente Cortana
• Non è presente il browser Edge (è presente Internet Explorer 11)
• E’ sconsigliato l’utilizzo di Office 365 click 2 run e suggerito l’utilizzo di Office 2016
• E’ sconsigliato l’utilizzo su hardware Surface
• La cadenza di rilascio delle nuove build non è così regolare in quanto è stato dichiarato che verrà pubblicata una nuova build Long Term ogni circa 3-4 anni, ma va precisato che la prima build era stata pubblicata nel 2015 e la seconda nel 2016

A riguardo si veda Windows 10 Long Term Servicing Branch (LTSB) di Marco Moioli (Technology Solutions Professional Windows 10 at Microsoft).

Microsoft ha dato delle linee guida su quelli che sono gli scenari in cui è suggerita l’adozione dell’LTSB/LTSC, come riportato in Overview of Windows as a service, indicando che l’LTSP dovrebbe essere utilizzata solo per special-purpose devices o specialized systems, va precisato che questa è un linea guida, non viene dichiarato che scenari differenti non siano supportati, ma solo che sarebbero più indicati per il Semi-Annual servicing channel:

“Specialized systems—such as PCs that control medical equipment, point-of-sale systems, and ATMs—often require a longer servicing option because of their purpose. These devices typically perform a single important task and don’t need feature updates as frequently as other devices in the organization. It’s more important that these devices be kept as stable and secure as possible than up to date with user interface changes. The LTSC servicing model prevents Windows 10 Enterprise LTSB devices from receiving the usual feature updates and provides only quality updates to ensure that device security stays up to date. With this in mind, quality updates are still immediately available to Windows 10 Enterprise LTSB clients, but customers can choose to defer them by using one of the servicing tools mentioned in the section Servicing tools.”

“Long-term Servicing channel is not intended for deployment on most or all the PCs in an organization; it should be used only for special-purpose devices. As a general guideline, a PC with Microsoft Office installed is a general-purpose device, typically used by an information worker, and therefore it is better suited for the Semi-Annual servicing channel.”

Inoltre viene specificato che è possibile passare dalla versione LTSB di Windows 10 Enterprise alla versione Semi-Annual Channel di Windows 10 Enterprise senza perdita di dati in quanto è supportato l’upgrade tra le due versioni:

“If an organization has devices currently running Windows 10 Enterprise LTSB that it would like to change to the Semi-Annual Channel, it can make the change without losing user data. Because LTSB is its own SKU, however, an upgrade is required from Windows 10 Enterprise LTSB to Windows 10 Enterprise, which supports the Semi-Annual Channel.”

Dato per scontato che sia possibile utilizzare l’edizione Enterprise di Windows 10, che le funzionalità non presenti in LTSB non siano di interesse e non siano necessarie funzionalità diverse da quelle presenti nella build installata per due o tre anni è possibile valutare se eseguire il deploy della versione LTSB/LTSC o della versione Semi-Annual Channel.

Il post Throwback Thursday: To CBB or to LTSB? pubblicato su ivanti contiene una serie di considerazioni e valutazioni sull’azione di LTSB/LTSC o di CBB/SAC che possono essere utilizzare per orientarsi e la prima considerazione che viene fatta è che la scelta tra CCB/SAC e LTSB/LTSC è qual è il tempo entro occorre necessariamente eseguire un upgrade di build:

“Microsoft is very zealous in its insistence that LTSB should only be used for machines that are “not general purpose”. According to them, a machine that has Microsoft Office on it counts as “general purpose” (an interesting way of classification!), and should therefore always be allocated to the CBB branch. Examples of LTSB use cases only cover critical endpoints such as air-traffic control systems and life-support machines. So to make the choice between CB/CBB or LTSB, what you really need to know is exactly how long you have before the next upgrade must be applied.”

La seconda considerazione che viene fatta è che l’upgrade ad una build successiva va pianificato e gestito nel modo corretto e soprattutto occorre conosce il tempo necessario per eseguire tale attività. L’upgrade ad un build successiva è infatto l’adozione di una versione successiva del sistema operativo e quindi occorre eseguire nell’arco dei 18 mesi i test, la gestione degli eventuali issue e incompatibilità, la gestione dell’impatto di eventuali cambi all’interfaccia utente , la gestione di eventuali feature rimosse, la verifica della poolicies applicate per la gestione centralizzata e quindi il deploy:

“So if we consider 8-14 months as the servicing window for a CBB machine, and err on the side of caution down to 8 months, then in that eight month period you must:

• Test all applications
• Identify any application issues
• Work with vendors to resolve application issues and verify success
• Assess the user interface for any potential changes that require training or communications
• Identify any features which have been removed that users may rely on
• Verify that all previously-applied policies and configurations still work as intended

And that’s probably not an exhaustive list…I’m sure every enterprise out there has some specific testing that needs doing in addition to this list. The presence of the Windows Insider branch means that some of these actions can be done prior to the actual CB release, but still, it’s a lot of work.

So really, when you are deciding on CB/CBB or LTSB, the main question is – do you think you can fit all of the required testing and remediation into the maintenance window? If the answer is yes, use CB/CBB. If not, then go with LTSB.”

Una terza considerazione riguarda l’adozione di LTSB che secondo un sondaggio condotto da ivanti tra gli enterprise EUC (End-user computing) admins indicherebbe che 1 su quattro hanno pianificato di adottare LTSB contro il 54% che ha deciso di adottare CB/CBB, mentre i rimanenti hanno optato per un’adozione mista di LTSB e CB/CBB, di seguito le percentuali:

• 54% di adozione CB/CBB
• 24% di adozione mista CB/CBB e LTSB
• 22% di adozione LTSB

“Interestingly, nearly 1 in 4 respondents reported plans to adopt LTSB, compared to 54% for CB/CBB. The remainder were opting for a mixed environment encompassing both major branches.

The lion’s share of respondents appear committed to embracing the CB/CBB model, but it is also clear that many more people than Microsoft expected are looking at adopting LTSB – either wholly, or in part.”

Una quarta considerazione è che delle limitazioni di LTSB quella che per esperienza dell’autore quella che è più sentita è la mancanza di Edge, mentre la manca dell Store, Cortana e delle Universal Apps non viene al momento percepita come una ragione per scegliere CB/CBB.

“In my experience, the main feature that is lost when adopting LTSB is Microsoft Edge. It’s about the only application or feature that businesses seem to be concerned about losing access to. The Windows Store, Cortana, and all the other Universal Apps don’t seem yet to have enough uptake or interest to justify any meaningful interest in adopting CBB on a feature basis alone.

However, because there isn’t a real killer app available on the UWP platform yet…doesn’t mean there won’t be one. Microsoft – and other vendors too – are slowly porting applications to the new platform, and every iterative update of Windows 10 brings more. The Desktop Bridge offers a way for vendors to convert applications directly from legacy desktop formats without a huge development effort, and this may drive future movement towards the UWP model.”

Per quanto riguarda le Pubbliche Amministrazioni italiane l’adozione di LTSB/LTSC in determinati ambienti e scenari potrebbe aiutare nell’adempimento delle Misure minime di sicurezza ICT per le pubbliche amministrazioni pubblicate nella CIRCOLARE 17 marzo 2017, n. 1/2017 sulla Gazzetta Ufficiale che recepisce la Direttiva del Presidente del Consiglio dei ministri 1° agosto 2015 – 17A02399. 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., ovvero, in sua assenza, del dirigente allo scopo designato.

Per semplificare l’adeguamento alla misura minima ABSC 2.1.1 se non necessario è conveniente non consentire l’utilizzo di app:

• ABSC 2.1.1: Stilare un elenco di software autorizzati e relative versioni necessari per ciascun tipo di sistema, compresi server, workstation e laptop di vari tipi e per diversi usi. Non consentire l’installazione di software non compreso nell’elenco.

L’adeguamento alle misure minime ABSC 3.2.1 e ABSC 4.1.1 può essere più semplice in quanto LTSB/LTSC garantisce una stabilità della configurazione delle workstation per maggior tempo:

• ABSC 3.2.1: Definire ed impiegare una configurazione standard per workstation, server e altri tipi di sistemi usati dall’organizzazione.
• ABSC 4.1.1: Ad ogni modifica significativa della configurazione eseguire la ricerca delle vulnerabilità su tutti i sistemi in rete con strumenti automatici che forniscano a ciascun amministratore di sistema report con indicazioni delle vulnerabilità più critiche.

L’adeguamento alla misura minima ABSC 4.5.1 implica che i sistemi siano sempre aggiornati e quindi nel caso di adozione del CBB/SAC il rispetto del deploy della buid successiva entro i 18 mesi deve essere tassativamente rispettato:

• ABSC 4.5.1: Installare automaticamente le patch e gli aggiornamenti del software sia per il sistema operativo sia per le applicazioni.

Conclusioni

Come emerge dalle statistiche il tempo medio di una migrazione a Windows 10 è di circa due anni questo significa che adottando il service model Current Branch for Business / Semi-Annual Channel sarà necessario eseguire su alcune macchine un upgrade di Build in quanto il supporto del sistema operativo termina dopo 18 mesi dal rilascio della build.

Lo scoglio più comune l’adozione di una nuova Build di Windows 10 ogni 18 mesi sono le ridotte risorse IT che non riescono a completare test e deploy in tale periodo oppure l’impossibilità di avere software certificato per la nuova build entro tale periodo.

Nel caso di dubbio tra l’adozione di CBB/SAC o LTSB/LTSC l’adozione di Windows 10 Enterprise LTSB permette di gestire l’infrastruttura con maggior tranquillità per un determinato periodo tenendo conto che in caso di necessità è possibile eseguire semplicemente l’upgrade alla versione Windows 10 Enterprise CBB/SAC senza alcuna perdita di dati.

Il 17 agosto 2017 è stato pubblicato il Microsoft Security Intelligence Report (SIR) Volume 22 come annunciato nel post Microsoft Security Intelligence Report Volume 22 is now available sul Microsoft Secure Blog.

Il SIR è disponibile al seguente link http://www.microsoft.com/sir e include i dati relativi alle minacce informatiche del primo trimestre del 2017, ma anche dati statistici relativi a vulnerabilità, exploits, malware e siti malevoli raccolti su più di 100 countries/regions.

Nel Volume 22 del SIR sono state apportate due importati cambiamenti al report:

• I dati sono stati suddivisi nelle due categorie cloud ed endpoint
• I dati si riferiscono ad un trimestre (Gennaio 2017 – Marzo 2017) invece che ad un semestre come nei report precedenti in quanto l’obbiettivo sarà quello di fornire aggiornamenti del SIR più frequenti in futuro

Come vedremo analizzando il SIR questi due cambiamenti evidenziano che la tendenza delle minacce è in rapida evoluzione e che l’attenzione degli attaccanti si è spostata anche sul Cloud.

Il SIR viene generato a fronte dei feedback inerenti alla sicurezza che Microsoft ottiene dai sui servizi on-premises e cloud:

“The intelligence that informs this report comes from security-related signals from the consumer and commercial on-premises systems and cloud services that Microsoft operates on a global scale. For example, every month we scan 400 billion emails for phishing and malware, process 450 billion authentications, and execute 18+ billion webpage scans.”

Il primo aspetto che emerge dal SIR volume 22 è un aumento rispetto al 2016 del 300% degli attacchi su account utilizzati per accedere ai servizi cloud e un aumento del 44% delle autenticazioni ai seervizi cloud provenienti da IP malevoli.

Ciò purtroppo è dovuto ad una gestione delle password poco accorta, attacchi di phishing mirati, vulnerabilità in prodotti e servizi di terze parti e ad una mancata gestione degli indirizzi IP autorizzati ad accedere ai servizi cloud:

“The Identity Security and Protection team has seen a 300 percent increase in user accounts attacked over the past year. A large majority of these compromises are the result of weak, guessable passwords and poor password management, followed by targeted phishing attacks and breaches of third-party services.”

“The number of Microsoft account sign-ins attempted from malicious IP addresses has increased by 44 percent from 1Q16 to 1Q17. Security policy based on risk-based conditional access, including comparing the requesting device’s IP address to a set of known “trusted IP addresses” or “trusted devices,” may help reduce risk of credential abuse and misuse.”

Come al solito valgono le indicazioni di usare password uniche per ogni sito e servizio, evitare password deboli e utilizzare metodi alternativi di autenticazione o autenticazioni multifattore. Di seguito le policy relative alle password per l’utilizzo dei servizi in Azure:

• Le Windows VM richiedono una password complessa di almeno 12 caratteri (a riguardo si veda Frequently asked question about Windows Virtual Machines)
• Le Linux VM richiedono una password complessa di almeno 6 caratteri (a riguardo si veda Frequently asked question about Linux Virtual Machines)
• Azure Active Directory richiede password complesse di almeno 8 caratteri (a riguardo si veda Password policies and restrictions in Azure Active Directory)

Il secondo aspetto che emerge dal SIR volume 22 è che i servizi cloud come Microsoft Azure sono diventi interessanti per gli attaccanti non soltanto per ottenere un punto di partenza da cui iniziare compromettere l’infrastruttura, ma anche per utilizzare le macchine virtuali compromesse per lanciare attacchi, in particolare quelli a forza a bruta, campagne di spam e phishing e port scanning. Di seguito distribuzione delle attività malevole eseguite da macchine virtuali compromesse in base a quanto rilevato dall’Azure Security Center.

Per quanto riguarda la situazione italiana nell’ambito di questa nuova tendenza in base alle statistiche dell’Azure Security Center gli attacchi che partono dall’Italia verso i servizi cloud si attestano tra l’1% e il 10%, mentre al momento è poco interessata da attacchi che parto da macchine in cloud compromesse (tra 0 e 0,001%). Le zone da cui partono la maggior parte di attacchi verso il cloud sono invece Nord America e Cina e sono anche le stesse regioni che subiscono il maggior numero di attacchi parto da macchine in cloud compromesse.

“More than two-thirds of incoming attacks on Azure services in 1Q17 came from IP addresses in China and the United States, at 35.1 percent and 32.5 percent, respectively. Korea was third at 3.1 percent, followed by 116 other countries and regions.”

“Compromised virtual machines often communicate with command-and-control (C&C) servers at known malicious IP addresses to receive instructions. More than 89 percent of the malicious IP addresses contacted by compromised Azure virtual machines in 1Q17 were located in China, followed by the United States at 4.2 percent.”

Il terzo aspetto che emerge dal SIR volume 22 è che molti siti web vengono compromessi per diventare dei Drive-by download sites
con l’obbiettivo di infettare i visitatori del sito sfruttando vulnerabilità del browser anche senza scaricare file:

“A drive-by download site is a website that hosts one or more exploits that target vulnerabilities in web browsers and browser add-ons. Users with vulnerable computers can be infected with malware simply by visiting such a website, even without attempting to download anything.

Drive-by download pages are usually hosted on legitimate websites to which an attacker has posted exploit code. Attackers gain access to legitimate sites through intrusion or by posting malicious code to a poorly secured web form, like a comment field on a blog. Compromised sites can be hosted anywhere in the world and concern nearly any subject imaginable, making it difficult for even an experienced user to identify a compromised site from a list of search results.”

I motori di ricerca tra cui Bing possono attuare una prima linea di difesa segnalando all’utente eventuali siti su cui vi sono evidenze di compromissione, dalle statistiche sui siti compromessi di Bing si nota come a Marzo 2017 le Drive-by download pages fossero più diffuse in Asia, Russia e America, ma il fenomeno seppur con minor rilevanza è anche presente in Europa e in particolare in Francia, Italia e Spagna

Il quarto aspetto che emerge dal SIR volume 22 è che c’è stata una riduzione delle infezioni da malware a livello worldwide in base all’analisi dell’Encounter rate definito come “percentage of computers running Microsoft real-time security products that report a malware encounter (Encounter rate does not include threats that are blocked by a web browser before being detected by antimalware software)”. Gli stati con maggior Encouter rate sono state Bangladesh, Pakistan, Indonesia ed Egitto, mentre quelle con Encouter rate minore sono Giappone, Finlandia, Svezia e Norvegia. Un altro aspetto significativo è che in cima alla classifica degli unwanted software ci siano i Browser Modifiers seguiti dai Software Bundlers e dagli Adware (per informazione circa i criteri di identificazione del software come malware o unwanted si veda How Microsoft antimalware products identify malware and unwanted software).

Si noti che una delle funzionalità presenti in Windows Defender è pa protezione da PUA (Potentially Unwanted Application) abilitabile anche tramite chiave di registro, a riguardo si veda Shields up on potentially unwanted applications in your enterprise.

Il quinto aspetto che emerge dal SIR volume 22 è che la maggior diffusione di ransomware nel marzo 2017 è stata riscontrata in Repubblica Ceca, Corea e Italia:

Il sesto aspetto è che emerge dal SIR volume 22 è l’integrazione dell’antivirus in Windows 8 e Windows 10 ha contribuito a ridurre il numero di computer senza Antivirus, ma si registrano comunque importati percentuali di sistemi con Antivirus non aggiornato o disabilitato:

Il sesto aspetto che emerge dal SIR volume 22 in base all’analisi dei siti malevoli, sulla base dei dati forniti da Windows Defender SmartScreen, è che i Phishing sites più diffusi sono quelli relativi a servizi online e istituti finanziari e che le are in cui tale fenomeno è più diffuso sono Ucraina, Sud Africa, Indonesia, Danimarca:

Di seguito l’estratto delle statistiche i valori delle statistiche alcune statistiche che evidenza come in Italia le infezioni dal malware assumano percentuali importanti:

“Encounter rate are shown for locations with at least 100,000 computers running Microsoft real-time security products during a month. Only computers whose users have opted in to provide data to Microsoft are considered when calculating encounter rates.”

Conclusioni

Il SIR volume 22 pone in evidenza che il cloud è diventato interessante per gli attaccanti sia per compromettere infrastrutture sia per utilizzare risorse all’insaputa dei proprietari da cui lanciare campagne di attacchi, per tale ragioni occorre una migliore gestione della sicurezza degli account che possono accedere a servizi cloud rendedo più stingenti le policy di password, aumentando la sicurezza del processo di autenticazione e eseguendo un hardening dei servizi in cloud e in particolare delle VM.

Inoltre rimane fondamentale gestire la sicurezza si siti web aziendali per evitare compromissioni volte alla diffondere malware agli ignari navigatori, questo aspetto conferma anche è sempre prestare la massima attenzione all’aggiornamento e alla sicurezza del brower dal momento che è sempre il primo vettore con cui si propaga l’infezione.

Nonostante l’utilizzo di porte USB per veicolare malware sia una tecnica di attacco non recente, sono ancora molti i casi in cui infrastrutture informatiche subiscono attacchi sfruttando le porte USB per inoculare malware nel sistema.

Sembra infatti che due dei dieci gruppi hacker più pericolosi specializzati in cyber spionaggio utilizzino anche chiavette USB infette per compromettere i sistemi. Mi riferisco ai seguenti gruppi:

• SANDSORM (alias Quedagh, BE2 APT) un gruppo di hacker russi specializzato nel cyber spionaggio e sabotaggio che come tattiche e procedure (TTP) utilizza Watering holes, cd-rom e chiavette USB infette, vulnerabilità, zero- days, custom back door, worms e programmi per il furto di informazioni. Finora ha colpito governi, organizzazioni internazionali e il settore energetico in Europa e negli Stati Uniti ed è collegato agli attacchi ai media e alle infrastrutture energetiche in Ucraina.
• HOUSEFLY (alias Equation) e anche questo gruppo americano utilizza come tattiche e procedure (TTP) Watering holes, cd-rom e chiavette USB infette, vulnerabilità, zero- days, custom back door, worms e programmi per il furto di informazioni. Finora ha colpito obiettivi d’interesse a livello nazionale.

Per dettagli sui vari gruppi hacker, origine, obbiettivi, tecniche e recenti attività si veda l’Internet Security Threat Report (ISTR) Volume 22 pubblicato ad aprile 2017 da Symantec.

Ovviamente gli attacchi condotti tramite device USB si basano sul fatto di riuscire ad inserire o a far inserire dagli utenti un device USB nel sistema, ma stando alla ricerca condotta della University of Illinois e dall’University of Michigan resa pubblica a maggio 2016 la 37th IEEE Security and Privacy Symposium risulta che il 48% delle persone che trova chiavette USB nei parcheggi prova ad inserirle nei propri computer e ad aprire il file contenuti . A riguardo si veda l’articolo Concerns about usb security are real: 48% of people do plug-in usb drives found in parking lots.

Inoltre come non dimenticare che il worm Stuxnet utilizzato nel 2010 per attaccare centrali nucleari è stato veicolato tramite chiavetta USB, per informazioni in merito si veda l’articolo The Real Story of Stuxnet pubblicato il 26 febbraio 2013 dall’ IEEE Spectrum.

Per la mia esperienza vi sono al momento quattro tipi di attacco basati sull’utilizzo dell’Universal Serial Bus (USB) come vettore di attacco.

Scenario 1: Malicious code

In questo scenario si sfrutta la chiavetta USB per diffondere malware che viene attivato quanto l’utente tenta di aprire o eseguire i file presenti sull’unità removibile, il malware può essere già presente sulla chiavetta o venire scaricato direttamente da Internet.

Per proteggersi da questo tipo di attacchi è possibile configurare l’antivirus per eseguire la scansione dei dispositivi removibili, disabilitare le funzionalità di Autoplay o disabilitare l’utilizzo di USB device. A riguardo si vedano:

• Configure scanning options in Windows Defender AV
• KB2328787 Disabling Autoplay through Group Policy or the registry will cause HotStart buttons to not function on Microsoft Windows 7 and Microsoft Windows Vista
• KB823732 How can I prevent users from connecting to a USB storage device?
• Deny All Access to Removable Devices or Media

Scenario 2: Attacchi tramite Social Engineering

In questo scenario si sfrutta una chiavetta USB per portare l’utente su un sito di phishing con l’intento di rubarle credenziali. In alternativa molto spesso vengono fornite con tecniche di Social Engineering all’utente delle chiavette ritenute “fidate” che contengo malware. A riguardo si veda ad esempio l’articolo SEToolkit – Hacking Windows Machines Using USB/CD Infectious Media Generator che spiega come utilizzare il progetto social-engineer-toolkit tramite la distribuzione Kali Linux per generare CD o chiavette USB malevole per sistemi Windows.

Anche in questo caso per proteggersi da questo tipo di attacchi è possibile configurare l’antivirus per eseguire la scansione dei dispositivi removibili, disabilitare le funzionalità di Autoplay o disabilitare l’utilizzo di USB device.

Scenario 3: HID (Human Interface Device) spoofing

Questo scenario prevede un attacco più sofisticato in cui un device USB è camuffato come una chiavetta USB, ma è in realtà una tastiera in grado di inviare la pressione di tasti per fornire all’attaccante un accesso remoto al computer della vittima.

Un’altra variante utilizzata per condurre questo tipo di attacchi quando si ha accesso fisico ad un computer attivo è quello di inserire una chiavetta USB che invia movimenti del mouse casuali (mouse jiggler) per impedire l’avvio dello screensaver e quindi il bocco della sessione. A titolo d’informazione i dispositivi come mouse jiggler possono anche venire utilizzati in indagini forensi per garantire la continuità dell’accesso a sistemi sotto indagine che poi vengono sequestrati mediante l’utilizzo di kit che consentono il trasporto dei sistemi garantendo la continuità dell’alimentazione elettrica (un esempio di tali kit è il HotPlug Field Kit Transport a live computer without shutting it down). Ovviamente le stesse tecniche utilizzate nelle indagini forensi potrebbero essere utilizzate per rubare computer o server.

Per proteggersi da questo tipo di attacchi e disabilitare l’utilizzo di USB device o controllare il tipo di device USB installabili a riguardo si veda:

• Step-By-Step Guide to Controlling Device Installation Using Group Policy

In ambienti Linux, *BSD e OS X è stato sviluppato UsbKill un tool basato su script Python il cui scopo è realizzare un anti-forensic kill-switch che arresta il sistema nel caso rilevi una modifica sulle porte USB, per esempio un inserimento o una rimozione di un dispositivo. USBKill è disponibile nel seguente repository su GitHub https://github.com/hephaest0s/usbkill e può comunque essere utilizzato anche per proteggere sistemi dall’inserimento di dispositivi USB ignoti in particolare in sistemi non presidiati come, ad esempio, i server.

In ambiente Windows al seguente USB Shutdown : Yank USB Pendrive to Shutdown Windows è disponibile un tool simile che esegue lo shutdown   del sistema in caso vengano rilevati modifiche sulle porte USB, il tool è compilato a 32 bit ed è stato testato su Windows 7, 8, 8.1 e 10. Un altro interessante progetto open source in ambiente Windows il cui obbiettivo è bloccare rogue USB device è Beamgun che può bloccare attacchi basati sull’utilizzo di dispositivi USB che generano . Keystroke Injection (per esempio Rubber Duckies) o dispositivi USB con interfaccia ethernet che forniscono accessi remoti, eseguono attacchi di tipo man-in-the-middle e monitoraggio del sistema (per esempio LAN Turtle).

Per ulteriori informazioni su questo tipo di attacchi si vedano:

• USB peripherals can turn against their users (Security Research Labs) e BadUSB Exposure (BadAndroid proof-of-concept for emulating a USB network card under Android by Security Research Labs)
• Mouse Trap: Exploiting Firmware Updates in USB Peripherals (San Diego for WOOT ’14v 8th USENIX Workshop on Offensive Technologies – Agoust 19, 2014)
• USBdriveby (exploits the trust of USB devices by emulating an HID keyboard and mouse, installing a firewall-evading backdoor, and rerouting DNS)
• Rubber Duckies (Malicious keyboard devices that deliver arbitrary payloads on target)
• LAN Turtles (Network adapters that can hijack connections and steal credentials)

Scenario 4: Denial-of-service

Questo scenario prevede l’utilizzo di una chiavetta USB modificata per danneggiare computer della vittima tramite un sovraccarico elettrico sulla porta USB stessa, questo tipo di attacco nasce da un annuncio fatto da un ricercatore sulla sicurezza russo conosciuto come “Dark Purple” nel 2015 nel post USB killer (di cui è disponibile una traduzione in inglese al seguente USB Killer). Da allora l’hardware di tale device si è evoluto per essere sempre più letale ed oggi possibile acquistare device USB Killer V3.0 conformi al marchio CE dal sito https://usbkill.com con le seguenti caratteristiche:

• Input voltage: 4.5 – 5.5 VDC
• Output voltage: -215 VDC
• Pulse Frequency: 8 – 12 times / second
• Pulse current: ≥180A

Ovviamente non possono esserci protezioni software per tipo di attacco, la protezione migliore è valutare se il vendor hardware ha previsto a livello hardware una protezione da sovraccarichi elettrici sulle porte USB del proprio dispositivo (computer, laptop, smartphone, etc..). Sempre sul sito https://usbkill.com oltre all’USB Killer è anche possibile acquistare un Testing Shield che utilizzato in combinazione con l’USB Killer permette di testare se esiste o meno una protezione da sovraccarichi elettrici sulle porte USB.

In base a quanto affermato sul sito https://usbkill.com il 95% dei device hardware testati risulta vulnerabile ad attacchi di tipo USB power surge, mentre Apple sembra essere l’unica vendor che sta lavorando sulla protezione degli attacchi di tipo USB power surge (si veda USB Kill: Behind the scenes), ma sempre su https://usbkill.com è disponibile un USB Killer Adaptor Pack che permette di bypassare il chip di autenticazione su Phone 5, 6, 7 e 8 e il protocollo di autenticazione dell’USB-C.

Nel caso in cui sia possibile non utilizzare le porte USB è possibile bloccare l’inserimento di una UBS Killer impedendo l’uso della porta USB tramite dei USB Port Blocker removibili solo tramite un’apposita chiave (Lindy, Kensington e altri vendor distribuiscono questo tipo di protezione fisica), la disabilitazione da BIOS delle porte USB potrebbe anche rimuovere l’alimentazione alla porta, ma questo spetto va verificato perché dipende da come è stato implementato il BIOS. Ovviamente la miglior protezione sarebbe l’implementazione da parte dei vendor hardware di optoisolatori sulle porte USB.

Dispositivi hardware per la protezione delle porte USB

Gli attacchi su porte USB hanno spinto Robert Fisk a creare USG un hardware USB firewall portatile per porte USG che isola un device USB dal computer per impedire la compromissione di quest’ultimo. USG è disponibile nel seguente repository su GitHub https://github.com/robertfisk/USG e si basa sull’utilizzo di due microprocessori STM32F4 che comunicano con bus seriale ad alta velocità.

L’idea che sta alla base di USG è quella di supportare sull’interfaccia USB solo un numero limitato di comandi ritenuti sicuri per evitare dati malformati o non previsti che sono alla base degli USB Driver Exploits. Inoltre USG blocca gli attacchi basati su funzionalità nascoste supportando solo la connessione di un device e impedendo la modifica runtime della device class. Per quanto riguarda invece gli attacchi basati su comandi USB legittimi viene riportato che si sta ancora lavorando per sviluppare protezioni su questo fronte:

Type 3 Attacks: Evil Functionality in Plain Sight

Type 3 attacks also use completely legitimate USB commands, where the device you are using performs malicious actions. Defending against this type of attack requires rules specific to the attached device. For example, the mass storage class could encrypt blocks before they reach the USB device, rendering man-in-the-middle attempts futile. Or the human interface device (HID) class might block keystrokes arriving faster than a reasonable human typing speed. This firmware functionality is still under development.

Per maggiori dettagli si veda Technical Details for the Curious.

Per quanto riguarda la protezione da attacchi di tipo USB power surge tramite USB Killer viene riportato che l’USG non è stato progettato con questo scopo anche se la protezione potrebbe essere indiretta in quanto l’USG potrebbe bloccare buona parte della scarica elettrica danneggiandosi al posto del computer.

Q. Can the USG protect me from the USB Killer?

A. The USG was not designed to resist physical overvoltage attacks because they are obvious and easily contained. The information in your computer is more valuable than your computer itself, and the USG defends you against attacks that compromise your information.

But having said that, the USG will provide some protection. The voltage surge will pass through and damage two microprocessors and two ESD surge suppressors before it reaches your computer. The USG’s circuits will be destroyed, but the voltage surge will probably be reduced to a safe level at your computer’s port. If anyone does perform this test, you are welcome to tell me the result!

Al momento è disponibile per la vendita la versione 1.0 di USG che ha le seguenti caratteristiche:

The USG’s firmware supports the following devices, at USB 1 speeds (12Mbps):

• Mass Storage – Flash drives and hard drives, 512byte sectors and 2TB max
• Mice – 4 buttons with scroll wheel
• Keyboards – 101 keys

Un altro dispositivo hardware per la protezione delle porte USB è USBCheckIn sviluppato da Federico Griscioli, Maurizio Pizzonia, Marco Sacchetti dell’Università degli Studi “Roma Tre” e reso pubblico alla 14th Annual Conference on Privacy, Security and Trust (PST) del 2016. USBCheckIn è al momento sviluppato come Preemptive research project. USBCheckIn blocca temporaneamente dispositivi non autorizzati e richiede un’interazione all’utente per inserire una sequenza di caratteri in modo che sono chi è a conoscenza di questa passphrase possa autorizzare l’utilizzo del dispositivo USB:

Essentially, USBCheckIn temporarily blocks the traffic coming from the device and at the same time asks the user to physically interact with it. For example, for a keyboard, it shows on its internal display a random sequence of characters that the user has to type with the keyboard. After the user has entered the correct sequence, USBCheckIn logically connects the USB device with the system, and the device can be used normally. If the user enters the wrong sequence, the device is not allowed to communicate with the host system.

If the device is malicious, the commands sent to the host will not pass the authorization process and will not reach the system, preventing any attack from being successful. To prevent brute force attacks, the user has a fixed number of attempts before the device is blocked. After that, he needs to press the button on USBCheckIn to try again the authorization process.

Per info su USBCheckIn si veda il sito http://www.dia.uniroma3.it/~pizzonia/usbcheckin.

Conclusioni

Sebbene le tecniche di attacco su USB siano note ormai da tempo sono comunque sfruttate e potenzialmente pericolose in particolare vengono sfruttare vulnerabilità zero-day o se è possibile per gli attaccanti accedere fisicamente ai computer, ovviamente la soluzione più semplice è quella di impedire fisicamente l’utilizzo delle porte USB se queste non sono necessarie. Se invece il sistema deve utilizzare dispositivi USB se possibile occorre fare in modo che utilizzi esclusivamente dispositivi USB ritenuti affidabili, quindi oltre a prevedere delle difese informatiche contro i rogue USB device è necessario anche evitare gli utenti debbano trovarsi ad utilizzarli e quindi lavorare in tal senso sulle procedure aziendali.

Purtroppo nei casi in cui può essere necessario utilizzare dispositivi USB potenzialmente non affidabili occorre pianificare procedure per il ripristino rapido di postazioni di lavoro nel caso vengano danneggiate o compromesse e confinare gli accessi all’infrastruttura di queste postazioni esposte agli attacchi veicolati tramite dispositivi USB in modo da non mettere a rischio l’intera infrastruttura.

Un caso pratico di questo di uno scenario in cui dispositivi USB potenzialmente pericolosi possano venire inseriti in computer connessi ad una rete dati è la gestione della Carta d’Identità Elettronica (CIE) che dovrà essere attivata in tutti i Comuni d’Italia entro il 2018 e che prevede nelle Modalità di acquisizione foto anche la possibilità da parte del cittadino di portare una fotografia su supporto digitale USB. Questa possibilità espone inevitabilmente i computer utilizzati per la gestione della CIE ad attacchi tramite rogue USB device o peggio ancora alle USB Killer mettendo a rischio, se non vengono prese le dovute contromisure, la rete dati degli uffici del Comune o il danneggiamento dei computer utilizzati per la gestione della CIE nel caso vengano inserite delle USB Killer. In scenari come questo sarebbe utile dotare i computer esposti ad attacchi tramite rogue USB device di device di protezione hardware delle porte USB come USG o USBCheckIn.

Come abbiamo avuto modo di vedere nel Video Tech Heroes di Nicola Ferrini e Paola Presutto, Microsoft ha abbandonato il supporto delle versioni “legacy” di IE mantenendolo esclusivamente per la versione 11.

Nella estrema varietà di siti che ci si trova ad utilizzare, soprattutto in ambito aziendale, non è raro incontrare applicazioni web che richiedono la compatibilità con versioni precedenti di Internet Explorer.

Già dalla versione 10 del browser era attivabile la gestione della “Visualizzazione Compatibilità“

Figura 1

Questa impostazione tuttavia non consentiva (e non consente nemmeno in IE 11) un’impostazione puntuale su un singolo host, infatti definendo www.ictpower.it come host da visualizzare in modalità compatibile, l’elenco viene popolato con l’intero dominio ictpower.it.

Se ci si trova ad operare in ambienti intranet esiste una sola impostazione disponibile ed anche qui non è possibile gestire il singolo host in visualizzazione compatibilità

Alcune soluzioni che abbiamo avuto modo di analizzare hanno visto implementare un dominio differente nel quale riferire i singoli host per cui è richiesta la modalità compatibile. Questa soluzione è difficilmente gestibile e richiede comunque un certo impatto sulla struttura DNS interna.

La configurazione di Internet Explorer 11 prevede una modalità operativa denominata Enterprise Mode, per mezzo della quale è possibile ovviare alla limitazione vista in precedenza, potendo così definire un preciso host in visualizzazione compatibile.

In modo ancor più granulare è possibile definire se un determinato sito deve essere utilizzato in modalità IE7 oppure IE8.

L’attivazione della Modalità Enterprise può avvenire tramite Group Policy o chiavi di registro, e la definizione dei siti e della relativa modalità di navigazione è impostata all’interno di un file XML.

La compilazione di questo file è possibile tramite un apposito tool di gestione, di cui vedremo le peculiarità più avanti.

Attivazione di Enterprise Mode tramite Group Policy

Per mezzo di una GPO è possibile centralmente gestire la modalità operativa del Browser, la Policy oltre che attivare questa impostazione istruisce il “client” su dove reperire il file XML di impostazione. Il percorso in questo caso deve essere un URL navigabile ed accessibile dal client e deve essere dichiarato nella forma

http://<FQDN>/<Nome_File>.xml

In generale, IE11, quando lavora in “Enterprise Mode”, dopo 65 secondi circa dall’avvio, ricerca il file secondo le impostazioni previste nella GPO, una volta individuato e scaricato in locale, questo non viene più controllato fino al prossimo riavvio del browser.

Il file XML, riporta all’interno un numero di versione, all’avvio, IE verifica che il file salvato localmente sia allineato con la versione presente nel repository centrale, nel caso in cui il file locale sia meno recente procede allo scaricamento della versione aggiornata.

La Group Policy può essere definita nelle impostazioni Utente o Computer in:

Modelli Amministrativi\Componenti di Windows\Internet Explorer\Usa Elenco Siti Web di Internet Explorer modalità Enterprise

Chiaramente la definizione della policy nel ramo Computer farà ereditare l’impostazione a tutti gli utenti

Figura 2

Nella configurazione riportata sopra è indicato L’URL completo del file XML definito per le impostazioni del Browser

Attivazione di Enterprise Mode tramite Registro di Sistema

Come accennato in precedenza Internet Explorer può essere attivato per la modalità Enterprise anche tramite chiavi di registro, questa impostazione consente una maggior flessibilità di gestione permettendo di definire tre modalità di reperimento del file XML, che sono:

• Percorso HTTP(S): “SiteList”=”http://intranet.ictpower.it/SiteList.xml”
  
• Rete locale: “SiteList”=”\\UNC_PATH\share\ SiteList.xml”
  
• File locale: “SiteList”=file:///c:\\Users\\<user>\\documenti\\ SiteList.xml
  

Analogamente alla configurazione tramite Group Policy è possibile impostare il browser “per Machine” o “per User”, sarà sufficiente modificare la chiave nel ramo HKLM (HKEY_LOCAL_MACHINE) piuttosto che HKCU (HKEY_CURRENT_USER) per il resto il percorso sarà invariato.

A questo punto navigando un sito per cui è previsto l’uso in modalità Enterprise il browser presenterà anche una visualizzazione particolare, che sta ad indicare l’attivazione di questa modalità.

Figura 3

Le configurazioni viste ora definiscono in modo centralizzato quali siti devono essere navigati in modalità Enterprise, e gli utenti non hanno modo di agire ulteriormente. È possibile attivare una chiave di registro che di fatto “sblocca” l’accesso a questa modalità e quindi gli utilizzatori possono attivarla in autonomia sui vari siti utilizzati.

Modelli Amministrativi\Componenti di Windows\Internet Explorer\Consenti agli utenti di attivare e utilizzare a modalità Enterprise dal menu strumenti

Figura 4

Quando si attiva questa impostazione, è possibile specificare un URL che punta ad un server WEB che ha la funzione di archiviare i messaggi che vengono inviati quando un utente attiva o disattiva la modalità Enterprise dal menu strumenti.

Figura 5

Per dettagli ulteriori sulla configurazione del Server Web e per la consultazione del file di log è possibile consultare questo link.

Creazione del file XML per la gestione della Modalità Enterprise di Internet Explorer 11

Le configurazioni che abbiamo analizzato, si avvalgono, come già detto di un file formato XML che riporta le impostazioni relative ai vari siti, la creazione e gestione di questo file è facilitata da un apposito tool “Enterprise Mode Site List Manager“.

Ad oggi sono disponibili due versioni dello strumento a seconda della versione del sistema operativo e dello schema di XML a questo associato.

Al fine di scegliere correttamente la versione adatta si consiglia di seguire questo link, per brevità si riporta qui sotto la tabella riassuntiva delle versioni e relative compatibilità.

Figura 6

Dalla pagina di download dello strumento e relativamente alla versione V.2 viene riportato il seguente avviso

This tool lets IT Professionals create and update the Enterprise Mode Site List in the version 2.0 (v.2) XML schema. The Enterprise Mode schema has been updated to v.2 to be easier to read and to provide a better foundation for future capabilities. The v.2 schema is supported on Windows 7, Windows 8.1, and Windows 10. The v.1 XML schema will also continue to be supported on Windows 7, Windows 8.1, and Windows 10.

Il tool permette, tramite il tasto ADD, di inserire, uno per ogni riga, I vari URL che dovranno essere navigati in modalità compatibile, in alto è riportata la versione della configurazione utilizzato dal sistema per la comparazione tra il file locale e quello disponibile centralmente.

Caratteristica particolarmente utile è la possibilità di definire soltanto determinati Path di un sito, inserendo il percorso all’interno del campo URL, in questo modo è possibile gestire in modo estremamente preciso le singole aree che richiedono emulazioni differenti rispetto all’intero sito web.

Figura 7 ( definizione di siti visualizzati in modalità compatibile IE7)

Figura 8 (visualizzazione della sola area /articoli/ in modalità compatibile IE7)

Riferimenti:

https://docs.microsoft.com/it-it/internet-explorer/ie11-deploy-guide/turn-on-enterprise-mode-and-use-a-site-list

https://docs.microsoft.com/en-us/internet-explorer/ie11-deploy-guide/check-for-new-enterprise-mode-site-list-xml-file

https://technet.microsoft.com/library/dn640701.aspx

https://technet.microsoft.com/it-it/library/dn781326.aspx

In questo articolo abbiamo proposto l’utilizzo della Certification Authority Let’s Encrypt ed
una configurazione basata sull’implementazione del rilascio automatico di certificati per Internet Information Services.

Analogamente al Web server Microsoft possiamo utilizzare questa CA anche per ambienti Open, quindi Linux, OpenBsd, Nginx ed altri e quindi anche per il rilascio automatico di certificati nel Web server Apache

Nell’analisi della soluzione proposta è bene tenere in considerazione che l’estrema varietà di distribuzioni Linux, comporta anche differenze di implementazione della soluzione proposta, in questo caso i passi descritti sono riferiti ad una distribuzione Centos 6.9 e quindi applicabili all’ambiente RedHat, così come Oracle Linux Enterprise.

Il client ACME (Automated Certificate Management Environment), così come per l’ambiente Windows è disponibile anche in Linux un Client ed è scaricabile tramite Git

Per procedere alla sua installazione è necessario procedere come segue:

• Installare HTTPD
  
• Installare MOD_SSL
  
• Installare i riferimenti al repository EPEL (Extra Packages for Enterprise Linux) da cui installeremo Git
  
• replicare in locale il repository GIT per Let’s Encrypt in /usr/local

terminata la parte di semplice installazione è necessario procedere con i pochi passi necessari ad attivare e configurare il client in modo da permettere il primo rilascio ed il successivo rinnovo dei vari certificati.

È da tenere presente che:

As a domain may resolve to multiple IPv4 and IPv6 addresses, the server will connect to at least one of the hosts found in the DNS A and AAAA records, at its discretion. Because many web servers allocate a default HTTPS virtual host to a particular low-privilege tenant user in a subtle and non-intuitive manner, the challenge must be completed over HTTP, not HTTPS.

Al Punto 1 viene installato il Web Server Apache tramite il comando yum install HTTPD e verranno anche installate le eventuali dipendenze.

Mod_ssl previsto al punto2 è il modulo di gestione del protocollo SSL/TLS in Apache installabile con yum install mod_ssl

Punto 3, il repository EPEL contiene molte estensioni per i sistemi basati su sistemi Linux RedHat Centos e similari anche qui con il comando yum install epel-release otterremo la possibilità, sempre tramite yum di installare numerosi altri pacchetti in questo caso epel ci consente di installare GIT.

AL punto 4 Tramite il comando git clone https://github.com/letsencrypt/letsencrypt posizionandosi in /usr/local potremo replicare in locale la componente ACME con cui richiedere successivamente a Let’s Encrypt i certificati.

Figura 1 Replica da GIT di Let’s Encrypt

Configurazioni preliminari

Prima di procedere con la vera e propria richiesta alla CA dovremo però fare in modo che il WEB server risponda effettivamente anche per l’host per cui attiveremo HTTPS, questa impostazione, è all’interno del file di configurazione di Apache in httpd.conf, editandolo, dovremo definire un Virtual Host per il nostro sito attivo in http.

Figura 2 Impostazione VirtualHost Httpd

Richiesta del certificato HOST

Definita questa impostazione potremo procedere alla richiesta vera e propria del certificato utilizzando l’ambiente CertBot scaricato prima da GIT, posizionandoci quindi in /usr/local/letsencrypt dovremo eseguire il comando:

./letsencrypt-auto --apache -d linux1.robimassa.it

Dove specificheremo il tipo di Web Server utilizzato, ed l’FQDN dell’host che andremo a configurare

Per un elenco completo delle opzioni del client Let’s Encrypt potremo usare l’opzione –help

A questo punto verrà effettuata la richiesta verso la CA, sarà verificato se la configurazione DNS ed host sono corrette, ed in piena autonomia il client provvederà anche a modificare per noi la configurazione del file httpd.conf.

Durante la procedura di installazione sarà possibile scegliere se definire un redirect dalla porta 80 alla 443 o mantenere il precedente protocollo http ed insieme https.

Figura 3 Output comando di richiesta Certificato

Terminata la procedura di configurazione il file httpd.conf sarà modificato secondo le impostazioni volute

Figura 4 Modifica httpd.conf

La nuova impostazione di HTTPS con il certificato richiesto è definita in un file di configurazione che verrà incluso nella configurazione principale

Figura 5

Si noti che il certificato, la relativa chiave privata, la csr e più in generale tutto l’ambiente necessario alla gestione è creato all’interno di /etc/letsencrypt.

Rinnovo automatico del Certificato

Terminata la prima configurazione/richiesta il certificato rilasciato è valido per 3 mesi

Figura 6

il rinnovo può avvenire in modo automatico tramite un’attività impostata (anche quotidianamente) in cron, il comando da impostare è usr/local/letsencrypt-auto renew

ogni operazione che è compiuta dal client è “loggata” in /var/log/letsencrypt/letsencrypt.log

Conclusioni

Let’s Encrypt è una CA Free che può essere utilizzata liberamente da chiunque, il limite finora è nella possibilità di richiedere certificati di tipo Wildcard, ossia per un intero dominio ad esempio *. robimassa.it

Qualche mese fa è stato annunciato anche il rilascio per questo tipo di certificati a partire da gennaio 2018

Figura 7

Riferimenti:

https://letsencrypt.org/

https://certbot.eff.org/

L’Active Directory (AD) se non gestita e monitorata correttamente può diventare un vettore di attacco per l’infrastruttura aziendale. Di seguito elencheremo una serie di tipologie di attacco che possono sfruttare AD come vettore cercano di capire come possono essere prevenute e mitigate.

Attacchi su Active Directory volti a creare una BotNet

Questo tipo di scenari attacco sono stati analizzati da Ty Miller (Managing Director at Threat Intelligence Pty Ltd) e Paul Kalinin (Senior Security Consultant at Threat Intelligence Pty Ltd) nella sessione The Active Directory Botnet tenuta al blackhat USA 2017.

Tali attacchi si basano sul fatto che gli oggetti utente in Active Directory hanno come risaputo un gran numero di attributi che possono essere letti da tutti gli account utenti e computer del dominio, per contare il numero di attributi esposti da un account utente è possibile utilizzare il seguente comando PowerShell:

(Get-ADUser -Identity Username -Properties *).PropertyCount

Gli attributi di un oggetto utente in Active Directory possono essere di vario tipo come Stringa, Numerico, Boolean, Binario, etc. e ogni attributo può contenere dati di diversa dimensione da pochi bytes fino MBytes, di seguito una query PowerShell per vedere nome, tipo e dimensione massima degli attributi degli oggetti utente in Active Directory (a riguardo si veda il post Exploring Active Directory Data Types with PowerShell):

$schema =[DirectoryServices.ActiveDirectory.ActiveDirectorySchema]::GetCurrentSchema()

$schema.FindClass(‘user’).OptionalProperties | Select Name, RangeUpper | Sort RangeUpper -Descending

Gli attributi possono quindi essere utilizzati per l’injection dei dati da parte di una botnet al fine di utilizzarli successivamente da altri computer. Una Active Directory Botnet presenta infatti il seguente schema di funzionamento:

1. Gli host compromessi fanno injection di dati negli attributi del loro account AD ed eseguono query nel dominio per identificare i sistemi compromessi
2. Questo approccio permette al bot master e agli slave di identificare le macchine infette su cui lanciare i comandi le cui risposte saranno memorizzate negli attributi dell’account AD corrispondente all’endpoint e lette poi dall’host che aveva lanciato il comando
3. Le Botnet possono anche implementare una funzione di copertura che consente comunicazioni confidenziali tra gli host e la possibilità di utilizzare proprietà personalizzate di Active Directory per eludere tentativi di rilevamento
4. Questo tipo di attacco fornisce un potente canale di comunicazione che elude i Network Access Controls (NAC) e consente di implementare un Command & Control basato su Active Directory
5. Grazie all’utilizzo degli attributi degli oggetti AD né la Domain separation né la network segmentation possono interrompere la comunicazione
6. Dopo aver stabilità la comunicazione con la Botnet gli attributi binari vengono utilizzati per scaricare file posizioni remote tramite binary-to-text Base64 encoding
7. A questo punto le bots possono comunicare esternamente tramite shell remote che vengono utilizzate anche per eseguire l’exfiltration dei dati all’esterno dell’infrastruttura

La prevenzione di questo tipo di attacchi non può che basarsi sul monitoraggio regolare delle modifiche sugli attributi degli oggetti utenti di AD che non dovrebbero subire Variazioni in modo regolare, ovvero occorre rispettare la quinta legge delle 10 Immutable Laws of Security Administration:

Law #5: Eternal vigilance is the price of security

Nativamente come indicato in Monitoring Active Directory for Signs of Compromise è possibile eseguire l’audit delle Directory Service Changes, ma si noti che vi sono alcune limitazioni (per maggior dettagli si veda Audit Directory Service Changes):

“This subcategory reports changes to objects in AD DS. The types of changes that are reported are create, modify, move, and undelete operations that are performed on an object. Directory service change auditing, where appropriate, indicates the old and new values of the changed properties of the objects that were changed. Only objects with SACLs cause audit events to be generated, and only when they are accessed in a manner that matches their SACL entries. Some objects and properties do not cause audit events to be generated due to settings on the object class in the schema. This subcategory applies only to domain controllers.”

Per maggiori dettagli suul’Auditing di AD si veda anche AD DS Auditing Step-by-Step Guide.

In alternativa è possibile utilizzare prodotti di terze parti, come ad esempio ADAudit Plus di ManageEngine, mentre al momento Advanced Threat Analytics (ATA) non rileva attività malevole basate sulla modifica degli attributi degli oggetti AD, per i dettagli sulle attività sospette rilevate da ATA si veda: Advanced Threat Analytics suspicious activity guide.

AD Discretionary Access Control Lists (DACL) Backdoors

Questo tipo di scenari attacco sono stati analizzati da Andy Robbins (Adversary Resilience Lead at SpecterOps) e Will Schroeder (Offensive Engineer at SpecterOps) nella sessione An ACE Up the Sleeve: Designing Active Directory DACL Backdoors tenuta al blackhat USA 2017 e nel post Active Directory Access Control List – Attacks and Defense del Microsoft Advanced Threat Analytics Team.

Tali attacchi si basano sull’utilizzo del Discretionary Access Control List (DACL) per eseguire privilege escalation in un ambiente di dominio utilizzando come vettore di attacco la creazione di un path di escalation basato sulle permissions degli oggetti AD (DACLs), ma prima di affrontare alcuni potenziali scenari di attacco occorre prima analizzare i concetti su cui questi attacchi si basano.

L’Access Control è implementato assegnando Security Descriptors agli oggetti AD, un Security Descriptor è un set di informazioni collegate ad ogni oggetto e che contiene quattro componenti di sicurezza:

• Il Security identifiers (SIDs) dell’Object Creator (l’utente che ha creato l’oggetto) e del primary group dell’oggetto
• La Discretionary Access Control List (DACL) costituita da access control entries (ACE) che rappresentano i SID di utenti e gruppi a cui sono consentiti o negati i diritti di accesso all’oggetto
• La System Access Control List (SACL) costituita dagli utenti e gruppi a cui è consentito l’auding sull’oggetto
• Un set di control bits che qualificano il significato di un descrittore di protezione o dei singoli membri.

Va precisato che gli accounts built-in privilegiati (Domain Admins, Enterprise Admins, etc) sono protetti dal Security Descriptor propagation (o SDProp) che forza le ACL per impedire modifiche non autorizzate ogni 60 minuti (per default) resettando le permissions a quelle del container AdminSDHolder contenuto nel System container della Domain Partition. Il processo esegue i task in modo recursivo su tutti i membri dei gruppi e disabilita l’eredità su tutti i protected accounts.

Uno scenario di attacco basato sulla Discretionary Access Control List (DACL) è quello che
si basa sulle deleghe di permissions su oggetti AD concessi ad account non-built-in privilegiati. AD consente ad un amministratore di delegare permission a normali account di dominio (utenti, gruppi, computer) senza la necessità di aggiungere tali account a gruppi amministrativi e tra le deleghe comunemente concesse vi sono “Reset Password” (spesso concessa agli utenti helpdesk) e la “Add New Member to a group” (spesso concessa ai proprietari dei business group).

Quindi nel caso in cui venga compromesso un account a bassi privilegi, ma con la delega “Add New Member to a group” che gli permette di aggiungere un utente ad un gruppo che ha a sua volta il privilegio di “Reset Password” su un gruppo che contiene utenti ad elevati privilegi è possibile creare un path di attacco volto alla compromissione di account privilegiati.

Di seguito un schema di esempio di questo path di attacco:

Come illustrato precedentemente un ipotetico attaccante non sarà in grado di eseguire una privileges escalation sui privileged built-in accounts le cui ACL sono protette da SDProp, quindi la modifica alle ACL di default del container AdminSDHolder è sconsigliata perché estende la superficie di attacco del dominio, va comunque precisato che non esistono motivi per cui sia necessario modificare le ACL di default del container AdminSDHolder come riportato nel post Active Directory Access Control List – Attacks and Defense:

“Why would you change AdminSDHolder manually? No idea.

You should be careful with changing the AdminSDHolder, the Exchange team faced several issues with that (in a release candidate) which were all fixed for RTM as the granted permissions on the AdminSDHolder enabled an elevation of privilege scenario that is unacceptable in any environment. If you have a good reason (as we couldn’t find one) please leave us comments at ATAResearch@Microsoft.com.”

Anche in questo caso la prevenzione di questo tipo di attacchi deve innanzitutto basarsi sul monitoraggio dell’infrastruttura inteso come ricerca di potenziali path di attacco e per eseguire tali ricerche è possibile utilizzare un tool open source come BloodHound che utilizzando la teoria dei grafi ricerca relazioni nascoste o non desiderate in un ambiente Active Directory. Un altro tool open source per eseguire l’analisi dei path e delle relazioni in AD, a cui gli stessi autori di BloodHound si sono ispirati, è Active Directory Control Paths. Un terzo tool GUI basato su PowerShell per la creazione di report delle access control lists (DACLs) e delle system access control lists (SACLs) in un ambiente Active Directory è https://github.com/canix1/ADACLScanner, il cui utilizzo è descritto nel post Forensics: Active Directory ACL investigation.

Per l’identificazione di questo tipo di attacchi può anche essere impiegato ATA come indicato nel post Active Directory Access Control List – Attacks and Defense:

“ATA can detect multiple reconnaissance methods, including the ones used by BloodHound, to detect advanced attacks happening in your network.”

Conclusioni

Gli attacchi che hanno come obbiettivo Active Directory sono ovviamente molto pericolosi perché se messi in atto mettono nelle mani dell’attaccante il controllo completo dell’infrastruttura. Per prevenire tali attacchi è necessario gestire attentamente la propria infrastruttura, analizzarla attentamente al fine di scovare preventivamente possibili path di attacco o di escalation e monitorare attentamente comportamenti anomali al fine di bloccare rapidamente eventuali tentativi di compromissione di Active Directory. In altre parole occorre rispettare le 10 Immutable Laws of Security Administration e in particolare oltre alla già citata quinta legge anche la settima:

Law #7: The most secure network is a well-administered one

Dal momento che Active Directory rappresenta il fulcro su cui si basa la sicurezza dell’intera infrastruttura oltre al monitoraggio e analisi è bene adottare anche delle serie politiche per la gestione di account privilegiati a riguardo di veda Securing Privileged Access in cui viene descritto come implementare la protezione degli accessi privilegiati tramite l’utilizzo di account amministrativi separati per attività amministrative, l’adozione di Privileged Access Workstations (PAWs) (a riguarda si veda http://aka.ms/CyberPAW), l’adozione di Local Administrator Password Solution (LAPS) (a riguarda si veda http://aka.ms/LAPS) sia per le workstations che per i server al fine di evitare attacchi Pass-the-Hash and Pass-the-Ticket (per ulteriori informazioni inerenti all’implementazione di queste politiche di sicurezza di veda http://aka.ms/securitystandards).

Sempre nell’ottica di adottare anche delle serie politiche per la gestione di account privilegiati anche le indicazioni fornite nel post Protecting Domain Administrative Credentials circa la best practice di differenziare le credenziali di un amministratore di sistema in base al Tier per cui vengono utilizzate limitando i privilegi di tali credenziali alle sole attività che è necessario svolgere nel Tier:

• Tier 0: attività amministrative su Active Directory
• Tier 1: attività amministrative su server applicativi
• Tier 2: attività non privilegiate di utilizzo dei servizi dell’infrastruttura informatica

Come già discusso anche l’adozione di strumenti di analisi dell’infrastruttura evoluti e basati su machine learning come Advanced Threat Analytics (ATA) possono essere utili nel monitoraggio di tentativi di compromissione, ma come indica la decima delle 10 Immutable Laws of Security Administration non bisogna basare le proprie difese affidandosi ciecamente ad un prodotto di sicurezza:

Law #10: Technology is not a panacea

ATA è sicuramente un ottimo strumento per la rilevazione di vari tipi di attacchi tra cui quelli relativi ad Active Directory (a riguardo si veda Advanced Threat Analytics suspicious activity guide) inoltre la tipicità di questo tipo di prodotto fa sì che sia lecito aspettarsi una sempre maggiore efficacia nel rilevamento dei tentativi di compromissione, ma come detto precedentemente occorre prevedere una difesa della propria infrastruttura basata su più livelli di protezione e monitoraggio. Infatti ATA, al momento, oltre a non avere specifiche funzionalità per il rilevamento di Active Directory BotNet basate sulla modifica degli attributi degli oggetti AD può essere eluso con particolari tecniche descritte nella sessione Evading Microsoft ATA for Active Directory Domination tenuta al blackhat USA 2017 da Nikhil Mittal.

Il 22 novembre a Villorba (TV) si è svolta la conferenza tecnica gratuita Cloud Conference Italia 4.0, organizzata da walk2talk srl, dedicata alle maggiori novità in ambito IT e indirizzata a professionisti del settore quali CIO, IT Manager, Sistemisti ed Architetti IT. La conferenza giunta alla quarta edizione ha visto un grade successo di pubblico che ha dimostrato di aver apprezzato i temi trattati durante la conferenza.

ICTPower è stata invitata a partecipare con una sessione tenuta Ermanno Goletto e Roberto Massa dal titolo Security Best Practices e novità in Windows Server 2016 dedicata all’analisi dell’attuali minacce informatiche, all’applicazione delle best practices per la protezione e il monitoraggio e alle novità contenute in Windows Server 2016. La sessione è stata seguita da un pubblico numeroso che ha dimostrato vivo interesse per i temi e le problematiche trattate e ha voluto premiare i nostri relatori con feedback estremamente positivi.

• Active Directory – Tecniche di attacco e di difesa
• Tecniche di attacco e difesa contro l’utilizzo di dispositivi USB
• Microsoft Security Intelligence Report Volume 22
• Ransomware protection in Windows 10 Anniversary Update
• Cisco 2017 Midyear Cybersecurity Report
• Sicurezza e stampanti multifunzione

Desideriamo ringraziare walk2talk srl per aver dato alla community ICTPower la possibilità di collaborare alla realizzazione di una conferenza che ha riscosso un così grande successo e di aprire una piacevole collaborazione. Per gentile concessione di walk2talk srl rendiamo disponibile la registrazione della sessione sul nostro canale YouTube e vi ricordiamo che tutte registrazioni saranno presto disponibili anche sul sito della conferenza.

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.

Sul sito ICTPower.it abbiamo pubblicato una serie di articoli relativi al Software di gestione ed inventory GLPI, che alla prova dei fatti si è rivelato molto potente principalmente grazie alla sua modularità che ne estende le funzioni tramite molteplici Plug-In.

Riprendendo articoli, già pubblicati, in cui si analizza il percorso passo-passo per la configurazione in ambiente Windows, e dato che GLPI è rilasciato anche per ambienti Linux, proponiamo qui la sua installazione e configurazione di base su questo sistema operativo.

Dato che questa guida prescinde dall’analisi più ad alto livello delle potenzialità del software e delle sue origini, consigliamo, prima di addentrarsi nell’installazione vera e propria, di dedicare un po’ di tempo alla lettura di questo articolo.

Installazione di GLPI in ambiente Windows

relativo all’installazione su Windows Server 2016 ma con una approfondita overview sul progetto e sulla sua documentazione

Premessa

Come è noto la galassia delle distribuzioni Linux è molto estesa, e pur se presenti in rete installazioni di GLPI già preconfezionate per Debian ed altre distribuzioni, in questo articolo è considerata l’installazione in ambiente CentOS, che per sua origine è molto vicina alle distribuzioni Redhat, Fedora ed Oracle Linux Enterprise.

La versione di CentOS che è stata utilizzata è la 7.4 nella sua opzione “minimal” che consente l’installazione di un sistema operativo molto leggero e quindi anche con limitata superficie di attacco.

GLPI è sviluppato in php e utilizza MariaDB (MySQL) per l’archiviazione delle proprie informazioni, mentre come web server è utilizzato l’onnipresente Apache.

Preparazione del sistema operativo

Terminata l’installazione di CentOS 7 nella configurazione Minimal, è utile prima di procedere, effettuare un aggiornamento del sistema tramite YUM, eseguendo il comando

yum update

Alla data di pubblicazione del presente articolo la versione ultima del sistema operativo è la 7.4.1708

il consiglio, per chi dovesse utilizzare questa guida tra qualche è di verificare le eventuali incompatibilità con le Build più recenti del Sistema Operativo.

Terminato l’aggiornamento base del sistema operativo è utile installare PHP (che verrà aggiornato successivamente) e l’utility WGET utile per il recupero di alcuni file di installazione da GitHub (il repository da cui è disponibile GLPI)

yum -y install wget

yum -y install php

Aggiornamento di PHP

A questo punto è necessario aggiornare PHP utilizzando i repository EPEL (Extra Packages for Enterprise Linux) e REMI

wget -q http://rpms.remirepo.net/enterprise/remi-release-7.rpm

wget -q https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

rpm -Uvh epel-release-latest-7.noarch.rpm

rpm -Uvh remi-release-7.rpm

scaricati ed installati i riferimenti ai repository si dovrà abilitare il ramo del repository REMI relativo alla versione 7.1 di PHP

yum-config-manager --enable remi-php71

e successivamente eseguire l’update di PHP

yum update php

a questo punto è possibile verificare la versione di PHP installata

php -v

Terminata questa prima fase di configurazione ed aggiornamento è necessario installare una serie di pacchetti PHP e database necessari al funzionamento di GLPI

yum -y install http

yum -y install php-mysql

yum -y install php-pdo

yum -y install php-gd

yum -y install php-imap

yum -y install php-mbstring

yum -y install php-ldap

yum -y install php-xml

yum -y install php-opcache

yum -y install php-pecl-apcu

yum -y install php-xmlrpc

yum -y install mariadb-server

yum -y install net-tools vim

Configurazione del Firewall di sistema operativo

Configurazione delle componenti di sicurezza Firewall per consentire l’accesso a GLPI

firewall-cmd --permanent --add-service=http

firewall-cmd --reload

in questo esempio è utilizzato il protocollo http, nel caso in cui si intenda attivare il protocollo Https sarà necessario adattare il comando di configurazione per le regole del firewall e configurare Apache per l’uso di certificati.

nel caso si utilizzi un dominio pubblico tramite Letsencrypt è possibile ottenere certificati validi gratuitamente. In alternativa per ambiti lan con domini privati è possibile gestire il rilascio di gertificati tramite l’installazione di CA private.

Impostazione di avvio dei servizi

Impostazione delle opzioni di avvio per Apache e MariaDB al fine di avviare a boot-time i servizi base per GLPI

systemctl enable httpd

systemctl start httpd

systemctl enable mariadb

systemctl start mariadb

Configurazione dell’ambiente MariaDB e creazione del Database per GLPI

Completata questa fase, che definisce i pacchetti base e di supporto per GLPI, è necessario proseguire con la configurazione di ambiente e successivamente creando il DB e la credenziale di accesso che GLPI utilizzerà per il suo funzionamento.

mysql_secure_installatio

questo comando esegue una configurazione dell’ambiente di sicurezza del Database a partire dall’impostazione della password dell’utente root (di database).

Per la nostra installazione, definita la password, è sufficiente confermare tutte le scelte di default fino al temine.

Il passo successivo permette la creazione del Database per GLPI

mysql -u root -p

create database glpi;

CREATE USER 'GlpiUser'@'localhost' IDENTIFIED BY '
1!UserGlpi';

GRANT ALL PRIVILEGES ON glpi. * TO 'GlpiUser'@'localhost' IDENTIFIED BY '
1!UserGlpi';

FLUSH PRIVILEGES;

Installazione di GLPI

I passaggi per l’installazione vera e propria di GLPI sono pochi e molto semplici, è sufficiente scaricare il pacchetto GLPI da repository GitHub e, una volta scompattato, copiarlo nella cartella di Apache.

wget https://github.com/glpi-project/glpi/releases/download/9.2.1/glpi-9.2.1.tgz

tar -xvf glpi-9.2.1.tgz

cp -R glpi /var/www/html

è fortemente consigliato prima di procedere al download di GLPI verificare in GitHub la versione disponibile. Di norma è consigliato il download dell’ultima versione stabile

terminata la copia del pacchetto GLPI è necessario definire le impostazioni di accesso ai file copiati in modo da impostare correttamente la sicurezza dell’installazione.

chmod -R 755 /var/www/html/glpi

chown -R apache:apache /var/www/html/glpi

Prima di procedere con l’avvio della configurazione bisogna modificare il file httpd.conf, relativo alla configurazione di Apache, ed impostare la direttiva AllowOverride per la cartella Docroot a Limit

vi /etc/httpd/conf/httpd.conf

un’ultima configurazione è necessaria per la corretta impostazione in Selinux (che di default è attivo) al fine di permettere a GLPI di operare correttamente

chcon -R -t httpd_sys_rw_content_t /var/www/html/glpi/

setsebool -P httpd_can_network_connect 1
setsebool -P httpd_can_network_connect_db 1

setsebool -P httpd_can_sendmail 1

al termine dei vari passaggi descritti è utile eseguire un riavvio del servizio Apache prima di procedere alla seconda fase della configurazione tramite il browser Web

systemctl restart httpd.service

Completamento della configurazione

a questo punto accedendo tramite un browser all’indirizzo http://<Fqdn>/glpi
è possibile in pochi ulteriori passi portare a termine la configurazione.

Selezionare la lingua di utilizzo dell’applicativo

Accettare i termini della licenza d’uso

Selezionare “install” in quanto si tratta di una nuova installazione

viene eseguito un controllo sulla validazione dei componenti installati

L’installazione procede con la richiesta delle credenziali di accesso al DB creato in precedenza

Selezionare il db GLPI

La configurazione dell’ambiente DB termina con messaggio di conferma

Viene riproposto un riepilogo delle credenziali di accesso default

È possibile accedere direttamente al software

Da cui sarà necessario procedere ad alcune successive impostazioni

Considerazioni

L’installazione è terminata ed il prodotto è utilizzabile la documentazione ufficiale e descrittiva delle varie funzionalità ed impostazioni è reperibile qui:

http://glpi-project.org/

sul sito IctPower sono disponibili i seguenti articoli relativi alla configurazione e gestione di GLPI in ambiente Windows Server

configurazione di GLPI

backup di GLPI

Fusion Inventory è un progetto Open Source francese nato nel 2010 durante il FOSDEM meeting con l’obbiettivo di fornire una migliore integrazione tra differenti progetti di asset management come OCS Inventory, GLPI e GOSA. Come riportato nell’Overview al momento Fusion Inventory è in grado gestire l’inventario dei seguenti device:

• Computers
• Network devices
• Printers
• Virtual machines (VMware vCenter/ESX/ESXi, Virtualbox, Libvirt, Xen, OpenVZ/Virtuozzo, Parallels, LXC, FreeBSD Jails, HPVM, Vserver, Hyper-V)
• Android phone

Inoltre può inviare comandi Wake on Lan e gestire l’installazione, update e la rimozione di software su OS Windows, OS X, Linux e*BSD.

Di seguito lo schema di funzionamento di Fusion Inventory che sfrutta SNMP, WMI il registro di Windows per gestire l’inventario hardware e software dei dispositivi:

Mentre nel seguente schema viene illustrata l’integrazione di Fusion Inventory con GLPI basata sull’Agent distribuito sui computer e sul Plugin installato su GLPI:

In questo articolo verranno analizzati gli aspetti relativi all’installazione del plugin e relativa configurazione per l’import dei dispositivi e l’installazione e la configurazione dell’Agent in ambiente Windows.

Installazione del plugin per FusionInventory in GLPI

La prima operazione da eseguire per utilizzare l’agent di FusionInventory in GLPI è quella di installare il plugin che può essere scaricato da GitHub al seguente link https://github.com/fusioninventory/fusioninventory-for-glpi/releases. Al momento l’ultima release compatibile con GLPI 9.2 è la 9.2+1.0.

Se occorre aggiornare il plugin occorre prima disattivarlo in GLPI tramite il menù Configurazione/Plugin quindi rimuovere la cartella plugins/fusioninventory in GLPI per rimuovere i file deprecati e infine si procede come per una normale installazione. Il plugin non va disinstallato in quanto questo causerebbe la perdita dei dati FusionInventory.

Per installare il plugin occorre scompattare il package, ad esempio con 7zip, quindi copiare la cartella fusioninventory nella cartella plugins di GLPI, per maggior sicurezza eseguire una copia di backup del database di GLPI.

Terminata la copia dei file del plugin occorre installarlo e attivarlo tramite menù Configurazione/Plugin.

Configurazione inziale del plugin per FusionInventory in GLPI

Affinchè l’agent di FusionInventory possa funzionare occorre configurare il plugin specificando il Link d’accesso al servizio tramite il menu Amministrazione/Entità/Root entity/Fusioninventory, l’impostazione di default è https://localhost/glpi.

Dopo l’installazione del plugin, se non è già stato fatto, occorre configurare la gestione delle operazioni pianificate in caso contrario l’interfaccia di GLPI visualizzerà l’errore “GLPI cron not running“, per rimuover il warnig occorre creare una operazione pianificata eseguita ad intervalli compresi tra 1 e 5 minuti che avvii il seguente comando (a riguardo si veda Cron for GLPI and for FusionInventory):

“PathPHP\php.exe” -f PathGLPI\glpi\front\cron.php

Le opzioni di configurazione del plugin sono disponibili tramite il menu Amministrazione/FusionInventory/Generale/Impostazioni generali e sono suddivise nei seguenti gruppi:

• Configurazione generale in cui è possibile impostare la porta TCP dell’Agent e l’utilizzo di SSL per la comunicazione con l’Agent che permette di mettere in sicurezza le informazioni scambiate, a riguardo si veda la sezione Security della documentazione di FusionInventory.
• Inventario dei computer in cui è possibile definire quali informazioni del computeri verranno raccolte dall’Agent
• Inventorio di rete in cui è possibile definire quali informazioni dei dispositivi di rete verranno raccolte dall’Agent tramite SNMP
• Gestione pacchetto in cui è possibile configurare come gestire come vengono inviati i dati al server da parte del’Agent
• Moduli degli agenti in cui è possibile configurare le azioni che possono essere eseguite dall’Agent
• Blocchi in cui è possibile bloccare l’aggiornamento di alcuni campi di Computer, Stampanti e Periferica di rete da parte dell’Agent per evitare che vengano sovrascritte informazioni che si preferisce gestire manualmente

Tramite il menù Amministrazione/FusionInventory/Regole/
Equipment import and link rules è possibile gestire come importare dispositivi Computer, Printer e Network Equipment, Peripheral, Monitor, Phone, in modo da indentificare apparati in modo univoco secondo regole basate su seriale, UUID, nome, MAC o a combinazioni di questi identificativi.

Lo UUID(Universally unique identifier) è un identificatore di 128-bit che rispetta l’RFC4122 esposto dalla classe wmi Win32_ComputerSystemProduct che a sua volta ricava il valore dalla struttura System Information relativa alle informazioni SMBIOS, a riguardo si veda System Management BIOS su Wikipedia. E’ possibile ricavare lo UUID di un computer trami il seguente comando PowerShell:

Get-WmiObject Win32_ComputerSystemProduct | Select-Object -ExpandProperty UUID

E’ possibile modificare, aggiungere, abilitare/disabilitare e variale l’ordine di applicazione delle rule, a riguardo si veda How to work ‘Equipment import and link rules’.

Di seguito un esempio di configurazione delle rule per un asset di tipo computer:

• la rule Computer constraint (name) nega l’importazione nel caso non esista un nome
• le rule Computer update (by uuid), Computer update (by name), Computer import (by uuid), Computer import (by name) aggiornano e se necessario creano l’asset computer identificandolo prima tramite l’UUID e poi tramite il nome
• La rule Computer import denied blocca l’importazione se le rule precedenti non sono soddisfatte

L’elenco delle rule termina con le rule Global che definiscono come gestire importazione e aggiornamento degli asset non classicabili come Computer, Printer e Network Equipment, Peripheral, Monitor, Phone. Inoltre tramite il pulsante Verifica gestire delle regole è possibile eseguire un test di funzionamento delle regole.

Inoltre l’importazione e la creazione dei dispositivi è ulteriormente configurabile tramite i seguenti gruppi di rule disponibili tramite il menù Amministrazione/FusionInventory/Regole:

• Ignored import devices
• Computer entity rules
• Computer location rules
• Computer information rules
• Blacklist

Installazione dell’Agent come servizio in ambiente Windows

La prima opzione d’installazione è quella di installare sui computer utilizzando gli installer a 32 bit o 64 bit a seconda del versione del sistema operativo, al momento è disponibile la versione 2.4 dell’agente scaricabile da GitHub al seguente link https://github.com/fusioninventory/fusioninventory-agent/releases.

Di seguito i passi di installazione, le opzioni e le configurazioni richieste dal setup d’installazione, per informazioni sull’installare, l’installazione massiva l’installazione silente e le opzioni a riga di comando dell’installer si vedano:

• Microsoft Windows Installation
• Windows installer 2.3.x visual mode
• Windows large installation
• Windows installer 2.3.x command-line

Per i dettagli sui passi d’installazione si veda Windows installer 2.3.x visual mode, l’installer prevede le seguenti possibilità ed opzioni di configurazione.

Scelta della lingua d’installazione, al momento sono disponibili le lingue Inglese, Francese e Spagnolo:

Scelta dei componenti da installare, al moneto sono disponibili i seguenti componenti:

• Collect (registry query, WMI query e search file)
• Deploy (software deploy)
• ESX (ESX remote inventory)
• Inventory
• NetDiscovery (network discovery)
• NetInventory (network inventory tramite SNMP)
• WakeOnLan (wake on lan)

Impostazione del path locale dei risultati e dell’URL dei server GLPI o OCS a cui inviare i risultati

Impostazione della modalità di esecuzione, al momento è possibile configurare l’agente per essere eseguito come servizio, operazione pianificata o manuale:

Se viene selezionato la modalità di esecuzione Servizio è possibile configurare il server web locale che verrà installato per consentire il monitoraggio remoto del servizio:

Se viene selezionato la modalità di esecuzione operazione pianificata è possibile configurare la frequenza e l’intervallo orario di esecuzione:

Configurazione delle opzioni di esecuzione e delle opzioni avanzate di configurazione e di log

Al momento non è disponibile il file msi per la distribuzione tramite Group Policy, ma è possibile eseguire l’installazione tramite uno script di avvio computer di questo tipo sfruttando le opzioni a riga di comando dell’installer:

%SystemDrive%
cd %ProgramFiles%
if exist FusionInventory-Agent goto end
\\share\fusioninventory-agent_windows-x64_2.4.exe /acceptlicense /S /server=’http://serverGLPI/glpi/plugins/fusioninventory/’ /runnow
:end

Installazione in modalità portable dell’Agent in ambiente Windows

Se non si intende installare l’agent è anche possibile utilizzare la modalità di installazione portable utilizzando il package a 32 bit o 64 bit a seconda del versione del sistema operativo, al momento è disponibile la versione 2.4 dell’agente scaricabile da GitHub al seguente link https://github.com/fusioninventory/fusioninventory-agent/releases. Tramite la modalità portable è possibile scompattare l’agent senza necessità di avere privilegi amministrativi.

Per eseguire l’Agent sono già disponibili i seguenti script:

• fusioninventory-agent.bat per eseguire l’agent che a sua volta può eseguire vari task tra cui l’inventario, deployment di software o il network discovery si in modo autonomo o in combinazione con un server di gestione compatibile come GLPI, OCS o OTRS (per dettagli si veda fusioninventory-agent)
• fusioninventory-esx.bat per eseguire l’inventario di ESX/ESXi e vCenter VMware remoti tramite l’interfaccia SOAP (per dettagli si veda fusioninventory-esx)
• fusioninventory-injector.bat per eseguire test, benchmark o eseguire il push dell’inventario da macchine off-line (per dettagli si veda fusioninventory-injector)
• fusioninventory-inventory.bat per eseguire un task di inventario in modo autonomo senza necessità di un server GLPI (per dettagli si veda fusioninventory-inventory)
• fusioninventory-netdiscovery.bat per eseguire un discovery su di un network range tramite SNMP versione 1 (per dettagli si veda fusioninventory-netdiscovery)
• fusioninventory-netinventory.bat per eseguire l’inventario su un device di rete tramite SNMP versione 2c (per dettagli si veda fusioninventory-netinventory)
• fusioninventory-wakeonlan.bat per eseguire un task wakeonlan in modo autonomo senza necessità di un server GLPI (per dettagli si veda fusioninventory-wakeonlan)
• fusioninventory-wmi.bat per creare l’inventario di una macchina remota Win32 tramite l’interfaccia WMI

L’agent in modalità portable può comunque essere distribuito tramite le Group Policy Preferences per copiare sul client i file dell’Agent ed avviarlo in modo automatico ad esempio tramite un’operazione schedulata.

Configurazione dell’Agent

L’agent si può configurare tramite file di configurazione in /etc/agent.cfg o tramite registry tramite la chiave HKEY_LOCAL_MACHINE\SOFTWARE\FusionInventory-Agent o nel caso di agent a 32 bit su un sistema a 64 bit tramite la chiave KEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\FusionInventory-Agent, a riguardo si vedano:

• Agent configuration
• Agent man pages
• agent.cfg

Per quanto riguarda la configurazione tramite registro è possibile utilizzare le stesse voci di configurazione del file agent.cfg creando nelle chiave di registro i relativi valori di tipo string (REG_SZ), di seguito un esempio di configurazione che imposta il server GLPI (chiave server), esclude dal rilevamento le i dispositivi categorizzati come stampanti, monitor, video, storage, usb:

Conclusioni

L’utilizzo di Fusion Inventory in combinazione con GLPI consente di gestire l’inventario o parte di esso in modo automatizzato, ovviamente negli scenari in cui parte dell’inventario viene gestito manualmente occorre configurare opportunamente quali dati devono essere raccolti. Si pensi ad esempio al caso in cui i computer vengono acquistati e inventariati e solo dopo connessi in rete, inoltre in molti casi le informazioni che Fusion Inventory raccoglie potrebbero essere non così consistenti, si pensi ad esempio alla marca e modello che Fusion Inventory determina in base a quanto rileva sul sistema tramite wmi e chiavi di registro e quindi non sempre il produttore mantiene sempre le stesse diciture con l’avvicendarsi delle versioni software.

Un altro aspetto da tenere presente è che ne caso si elimina un asset computer occorre eliminarlo anche dal cestino di GLPI in caso contrario se Fusion Inventory rileva in rete un computer che risponde ai requisiti di indentificazione tramite nome, numero di serie, etc. connette le informazioni al primo asset che rispetta la query di identificazione indipendentemente che sia o meno nel cestino di GLPI causando quindi una conseguente impossibilità nel reperire le informazioni raccolte i n quanto gli asset nel cestino non vengono visualizzati.

Glpi è, come abbiamo visto un prodotto completo ed estendibile tramite vari plug-in, ad esempio FusionInventory consente di realizzare partendo da GLPI un valido sistema di Sw ed Hw inventory aziendale. Abbiamo anche scritto una guida su come Integrare FusionInventory con GLPI v9.2.1 in ambiente Windows.

Recentemente la normativa AgID “Misure Minime di Sicurezza ICT” per la Pubblica Amministrazione ha imposto tra le varie implementazioni, anche l’adozione di un inventory automatico del Software intallato. GLPI e l’estensione FusionInventory permettono in modo assolutamente economico e perfettamente automatico di implementare questa funzione, e non avendo in questo caso, la necessità di utilizzare altre funzionalità proprie di GLPI, vediamo come è possibile gestirne l’interfaccia utente in modo da permettere la sola consultazione richiesta.

GLPI presenta la possibilità di “modellare” l’interfaccia dei vari utenti che accedono in modo da presentare ad ognuno esclusivamente le funzioni necessarie. E’ quindi possibile impostare esclusivamente in consultazione le funzioni di inventario messe a disposizione con FusionInventory.

Il punto di partenza è chiaramente l’utente di GLPI che può essere locale oppure riferito ad una sorgente di autenticazione esterna ad esempio Active Directory, in GLPI ad ogni utente deve essere assegnato un profilo in modo da poter completare il processo di login, ed è all’interno delle impostazioni del profilo che possiamo definire con precisione le funzioni, o per meglio dire in questo caso, le visualizzazioni consentite.

Nell’esempio che proponiamo viene creato un profilo “Consultazione HW/SW” con il solo accesso all’inventario di Hardware, Software ed alla visualizzazione delle impostazioni del plugin di FusionInventory

Creazione del profilo

Dal menù di amministrazione nella sezione profili troviamo l’elenco di tutti i quelli esistenti, alcuni di questi sono presenti di default già dall’installazione. Nelle caratteristiche di base del profilo possiamo specificare se gli utenti avranno un’interfaccia semplificata oppure standard, per la quale è possibile ulteriormente definire i campi visualizzati.

Figura 1 pagina profili

Dalla Pagina Principale/Amministrazione/Profili tramite il tasto “+” si può creare il nuovo profilo.

Figura 2creazione profilo

E’ possibile fare sì che il profilo sia dichiarato come “Predefinito”, in questo caso verrà applicato di default ad ogni nuovo utente aggiunto a GLPI, e se è abilitata la possibilità di Self-Provisioning, ogni utente ( se presente in Active Directory ) potrà accedere a GLPI senza ulteriori profilazioni. Verrà quindi autenticato, creato e profilato all’atto del primo accesso.

Di Default GLPI durante l’installazione crea il profilo Self-Service come predefinito e sempre per impostazione predefinita tutti gli utenti oggetto di autenticazione esterna, possono collegarsi. Normalmente, anche per ragioni di sicurezza, è utile non definire alcun profilo come predefinito e disattivare l’impostazione di auto configurazione degli utenti esterni.

Proseguendo nella creazione del profilo si definisce il nome, se deve essere applicato di default ai nuovi utenti, e quale interfaccia di base applicare.

Nell’esempio sono riportate le informazioni corrette al fine di consentire le impostazioni di consultazione per FusionInventory, proseguendo con “Aggiungi” si apre una pagina ulteriore che riporta tutte le varie componenti consultabili ed eventualmente modificabili dagli utenti, l’ultima colonna a destra è utile per l’impostazione rapida di tutti i permessi su ogni asset.

Figura 3 selezione dei permessi

A questo punto è sufficiente selezionare il componente da visualizzare e le azioni permesse per il profilo, per il Plugin FusionInventory potremmo anche non attivare nessuna visualizzazione in quanto è GLPI dalla pagina Asset che riporta gli inventari fatti dagli agent installati, tuttavia è possibile permettere agli utenti la sola visualizzazione delle impostazioni del Plugin attivando i permessi di lettura come riportato sotto.

Terminata l’impostazione del profilo è sufficiente associarlo agli utenti interessati, accedendo al menu Amministrazione dopo aver selezionato il/gli utenti voluti, tramite il menu Azioni è possibile applicare il nuovo profilo.

Figura 4attribuzione dei permessi ad un utente

Nell’esempio descritto in questa guida la possibilità di consultazione per l’utente sarà quindi ridotta alle sole visualizzazioni di Computer (inteso come Hardware) e Software.

Figura 5 accesso ad una pagina ridotta

Considerazioni: la nuova normativa AgID citata in precedenza “impone” a tutta la P.A. una serie di obblighi al fine dell’adeguamento ad uno standard minimo di sicurezza. Alcune di queste implementazioni non hanno ( o quasi ) alternative di tipo Open-Source, la soluzione di inventory ha, come abbiamo visto la possibilità di essere implementata a costo zero, permettendo quindi di impiegare in modo più incisivo le sovente esigue risorse economiche disponibili.

Riferimenti:

Installazione GLPI v9.1.4 in ambiente Windows

Installazione di GLPI 9.2.0 in ambiente Linux

Gestione backup GLPI v9.1.4 in ambiente Windows

Configurazione autenticazione Windows in GLPI v9.1.4

Integrazione FusionInventory con GLPI v9.2.1 in ambiente Windows

http://fusioninventory.org/