Archivi categoria: Openness

Gestione backup GLPI v9.1.4 in ambiente Windows

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.

Configurazione autenticazione Windows in GLPI v9.1.4

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.

Ubuntu disponibile sul Windows Store

E’ proprio vero, come promesso da Microsoft qualche mese fa, la prima distribuzione Linux è a disposizione degli utenti Windows 10 direttamente sullo Store. Questo significa che chiunque abbia a disposizione una macchina con Windows 10 potrà scaricare ed installare il relativo pacchetto come accade per qualsiasi altra app, ed utilizzare (limitatamente alla riga di comando) un vero e proprio sistema operativo Linux.

Attualmente l’unica distribuzione disponibile è Ubuntu, ma molto presto sarà possibile installare Fedora e Suse. Essendo una novità assoluta, questa feature ha sicuramente bisogno di un periodo di test prima di diventare disponibile al grande pubblico, ed al momento l’installazione è limitata agli utenti del programma Windows Insider. L’iscrizione al programma è gratuita e semplicissima, e per effettuarla o semplicemente per avere qualche informazione è possibile visitare la pagina:

https://insider.windows.com/

Con tutta probabilità l’installazione delle distribuzioni Linux dello Store sarà disponibile per tutti dopo l’installazione del Fall Creators Update, l’aggiornamento della release di Windows che verrà distribuita a partire dal prossimo autunno.

Considerando quello che siamo in grado di fare con Windows Subsystem for Linux (https://www.ictpower.it/sistemi-operativi/windows-subsystem-for-linux-finalmente-in-una-release-ufficiale.htm), ci chiediamo che differenza faccia utilizzare questo tipo di distribuzione rispetto a quella inclusa in Windows 10 a partire dall’Anniversary Update. Fondamentalmente non ci sono differenze, quello che cambia è la modalità di installazione, estremamente semplice, ed il fatto che la modalità di installazione che utilizzavamo fino ad ora sarà considerata “deprecata”, e probabilmente verrà dismessa. Dallo store, inoltre, sarà possibile scegliere la distribuzione da installare, operazione ad oggi possibile ma un po’ complessa.

L’app scaricata dallo store installa una distribuzione indipendente, che gira in una “sandbox” ed è quindi possibile installare più distribuzioni contemporaneamente per utilizzarle in maniera autonoma.

Se siete già in possesso di una macchina con Windows 10 Insider con una build maggiore o uguale a #16215, quindi, non vi resta che provarla; potete scaricare l’app Ubuntu direttamente da questo link:

https://www.microsoft.com/it-it/store/p/ubuntu/9nblggh4msv6

Noi non possiamo fare altro che seguire tutte le novità e le sorprese a cui Windows 10 ci sta abituando!

Installazione GLPI v9.1.4 in ambiente Windows

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:

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:

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:

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.

Come effettuare un PenTest – Parte 2: Information Gathering

Abbiamo visto nel precedente articolo cos’è il Penetration Testing o PenTest.

In questo capitolo cercheremo di affrontare la seconda fase di un PenTest, basata su esempi reali e spiegazione di alcuni tools utilizzabili. L’information Gathering può essere distinto in due metodologie: attivo o passivo.

L’obiettivo principale di questa fase è quello di raccogliere più informazioni possibili che possano essere utili nell’attività di PenTest: alcuni dati possono essere ricavati dal DNS, hostname, IP, tecnologie hardware usate, username, documenti sensibili, informazioni di password reset, informazioni di contatto, SOCIAL NETWORK vari ed altro ancora.

Tale attività risulta essere nevralgica e molto importante. Più informazioni riuscirò a carpire, più accurata sarà la mia ricerca.

Nella ricerca delle informazioni ATTIVA cercheremo di ottenere le informazioni, ad esempio, nel traffico di rete dove si trova il nostro target; nella modalità PASSIVA utilizzeremo servizi di terze parti come Google/Linkedin/Shodan ecc.

Nella Information Gathering che stiamo descrivendo non esiste una tecnica o approcci standard: vince chi ha più creatività ed inventiva.

I motori di ricerca possono essere i vostri migliori amici…

È importante aggiungere che, per una raccolta di informazioni meno intrusiva e anonima ma con più difficoltà nel reperire dati, l’approccio PASSIVO è preferibile. L’approccio ATTIVO, restituirà all’attaccante molte info ma il rischio di essere scoperto e bloccato potrebbe essere alto.

La tipologia di approccio può essere scelto dal cliente al momento della redazione del Test PLAN.

Passiamo ai fatti…

Immaginiamo di voler raccogliere più info possibili da un Sito Web sfruttando l’approccio Ibrido (ATTIVO + PASSIVO).

Dove potremmo reperire un numero adeguato di Info?

Siti Web pubblici (affacciati su Internet) possono essere considerati la vetrina di una vittima. Sono molto utili per mostrare ai clienti i loro servizi e prodotti, ma possono essere sfruttati per carpire informazioni di varia natura e successivamente sfruttate a proprio vantaggio.

NOTA: Se un sito web è hostato su un provider esterno, raccogliere informazioni può essere difficoltosa, se il sito è hostato in server proprietari la faccenda potrebbe diventare più interessante…

Risorse Pubbliche alla portata di tutti

Esistono nel web numerose applicazioni che permettono di ottenere alcune info importanti per il proseguimento del PenTest.

Facciamo alcuni esempi:

https://archive.org/ : Permette di avere uno storico dei siti web. Dalla versione più recente alla più vecchia;

http://whois.domaintools.com/: Permette, tramite protocollo whois, di avere molte informazioni utili;

https://centralops.net/co/: simile al secondo link, con il vantaggio di poter fare un port scan semplice via web. (attività anonima a danno del target)

L’utilizzo di risorse pubbliche disponibili su Web, è sempre da preferire in quanto permette di mantenere un certo anonimato. A discapito di ciò, vi è una difficoltà di adeguare i tool via web alle nostre esigenze.

Tools in Linux

WHOIS

In alcune distro Linux è possibile adoperare il protocollo di rete Whois direttamente da terminare di comando.

#whois ictpower.it

Whois permette di effettuare delle query al fine di ottenere informazioni riguardo la registrazione del dominio. È possibile avere informazioni riguardo DNS server e contatti di colui che ha registrato il dominio. Con un pizzico di malizia e una spolverata di “linkedin” è possibile divertirsi un pò.

Ripasso di alcuni record DNS:

SOA: Informazioni autorevoli sulla zona DNS, incluso server DNS principale.

NS: Delega una zona DNS ad essere gestita da un server DNS autorevole per quel dominio.

A: Indirizzo IPv4 dell’host.

MX: Collega un nome di dominio ad una lista di server di posta autorevoli per quel dominio.

AAAA: Indirizzo Ipv6 dell’host.

CNAME: Collega un nome DNS ad un altro.

DIG

Altri tools che possono essere molto utili per poter raccogliere alcune informazioni sono:

Dig permette di fare query DNS; il solo comando DIG restituirà solo record di tipo A. Per poter ottenere tutti i record basterà digitare:

#dig ictpower.it any

Il fattore vincente in DIG può essere quello che permette di eseguire query salvate in un file di testo.

DNSENUM

Una valida alternativa a DIG, può essere dnsenum che permette di restituire i record DNS sfruttando alcune implementazioni aggiuntive:

  • Permette di ottenere nomi e sottodomini aggiuntivi utilizzando Google;
  • Scoprire sottodomini utilizzando tecniche di brute forcing da file di testo;
  • Utilizzare thread per elaborare diverse query…
  • Etc…

#dnsenum ictpower.it

Utilizzando il semplice comando dnsenum, otterremo informazioni riguardo IP dell’host, nome server e IP del server di posta.

Altri tools che permettono un’analisi più automatizzata sono Fierce o DMitry che approcciano l’information gathering in maniera più aggressiva e approfondita.

DA USARE CON MODERAZIONE…

Network Routing Information

Altre informazioni che possiamo ricavare, sono quelle inerenti al “network routing information”; conoscere tali dati permette ad un PenTester di comprendere la rete nella quale si trova il proprio target ed evitare di essere scoperto. In questa fase è possibile anche osservare se vi è un firewall a protezione del target.

TCPtraceroute

Il primo per importanza è sicuramente TCPtraceroute.

Come si evince dal nome, sfrutta il comando traceroute che, combinato ad una serie di migliorie, permette di ottenere risultati sicuramente più efficaci.

Il traceroute packet, nonché “UDP o ICMP
echo
request” con TTL variabile, molto spesso sono filtrati da un firewall; TCPtraceroute sfrutta il TCP SYN (stealth Scan) nonchè pacchetti legittimi e difficilmente bloccabili.

Se TCPtraceroute riceve in risposta del TCP SYN, un SYN/ACK significa che la porta è aperta, se il flag viene settato con RST significa che la porta è chiusa.

Tctrace

Strumento alternativo a TCPtraceroute è tctrace, che sfrutta la stessa tecnica.

TheHarvester

Ladies and gentlemen, inchinatevi davanti al tool per eccellenza per information Gathering.

Uno dei tool più malvagi ed utili che siano stati mai creati è TheHarvester (Tradotto “Il raccoglitore”).

Tale strumento è utilizzato per raccogliere domini, indirizzi email e documenti con metadata inerenti il target. Esso si basa su un suo algoritmo di ricerca in grado di interrogare i maggiori motori di ricerca conosciuti, facendo sì che l’attaccante non visiti direttamente il target. Dunque il target sarà ignaro delle nostre attività.

Riprendendo dalla descrizione nella pagina Github <<https://github.com/laramies/theHarvester>>, elenco alcuni motori di ricerca che interroga:

  • Google
  • Yahoo
  • Baidu
  • Shodan
  • Twitter
  • Etc…

Come ultimo, ma non per importanza, abbiamo Metagoofil.

Cercate documenti inerenti un possibile target? Questo tool fa per voi.

Esso si basa sul fantastico Google, andando a ricercare tutti i documenti con metadati del dominio target.

Possiamo ricercare documenti word, excel, presentazioni powerpoint, PDF

I suoi passi sono fondamentalmente 4:

  1. Cerca tutti i documenti presenti nel web tramite Google, con le estensioni specificate;
  2. Scarica i documenti trovati in locale;
  3. Estrae i metadati dai documenti scaricati;
  4. Salva i dati in un file HTML.

I metadati possono essere username, Versioni software, nomi macchina. Facile No?

Nel prossimo articolo affronteremo il cosiddetto processo di Target Discover nella rete.

Penetration Test: non solo per Hacker…

Quello nel quale stiamo per addentrarci oggi e nei prossimi capitoli, è un’attività che può essere compiuta per scopi leciti o illeciti. Il Penetration Testing o PenTest può essere definito come il processo che permette di analizzare in profondità la sicurezza di uno o più sistemi. L’attività deve essere una parte importante dei processi aziendali in modo da assicurare la piena consapevolezza dei punti deboli dell’infrastruttura IT e non.

Per ogni PenTest può essere applicata una diversa metodologia; si intende un insieme di regole da poter seguire per condurre un PenTest in maniera corretta.

Tale pratica può essere condotta indipendentemente o come attività schedulata nel proprio ufficio di IT Security. Uno scheduling comporta l’implementazione di adeguate misure di sicurezza, redigere un documento di analisi dei rischi, revisione del Codice, creazione di modelli di minacce ed altro…

Esistono due approcci metodologici al PenTest:

  • Black Box
  • White Box

Parliamo di “Scatola Oscura” o Black Box quando colui o coloro che compiono l’attività di Penetration non hanno cognizione delle tecnologie implementate nell’organizzazione target. Devono essere adottate tutte le tecniche di hacking conosciute ed è importante saper classificare le vulnerabilità in base al loro livello di rischio. (es. Un sistema vulnerabile ad un Local Code Execution può essere considerato meno grave rispetto ad un Remote code execution)

Tale metodologia può essere più costosa in termini di tempo e risorse rispetto ad un approccio di tipo White Box ed è soggetto alle reali abilità dell’attaccante.

La metodologia White Box, al contrario, è una tipologia di PenTest dove l’attaccante è a conoscenza di tutto l’ambiente che andrà a testare. È il miglior modo per valutare e concentrarsi su tutte quelle tecnologie che possono risultare critiche. In questo caso si va a valutare i rischi esterni che l’azienda/organizzazione incorre, non valutando le vulnerabilità interne (es. Social Enginering / Dipendente Scontento).

Gli step sono simili alle fasi di Black Box, ma in qualche modo l’approccio White Box può essere integrato nei cicli di vita di implementazioni Hardware/Software per eliminare le possibili problematiche a monte di un possibile attacco.

Sentiamo spesso parlare di Vulnerability Assessment e Penetration testing. Ma qual è la differenza sostanziale?

La differenza basilare è che nel Vuln. Assessment si vanno ad evidenziare tutte le possibili vulnerabilità, andandole a valutare il possibile impatto, nel PenTest si procede ad identificare tutte le vulnerabilità ed sfruttare possibili exploit pubblici o custom (0-day) con l’aggiunta di privilege escalation e mantenimento dell’accesso ai sistemi target.

In questo viaggio impervio non siamo soli…

Esistono varie linee guida che possono essere d’aiuto per chi voglia incominciare ad implementare controlli periodici:

Altre metodologie e tecniche di PenTest possono essere “Blind”, “Double Blind”, “Gray Box”, “Double gray box”, “Tandem”, “Reversal”.

Compreso la base dell’argomento, vediamo come deve essere pianificata l’attività nel modo migliore.

Esistono tantissimi tools che possono essere adoperati per tale proposito ma è importante usarli con criterio e sapienza in modo da poter massimizzare il risultato con uno sforzo minore.

Le fasi del PenTest, che possono essere semplici o complessi in base all’ambiente target, sono:

  • Definizione del Target
  • Raccolta delle Informazioni
  • Identificare e Scoprire il Target
  • Enumerazione Target
  • Mapping delle Vulnerabilità
  • Ingegneria Sociale
  • Sfruttamento delle falle
  • Escalation dei privilegi
  • Mantenimento dell’accesso
  • Documentazione and Reporting

In base all’approccio white/black box, sarà sempre possibile modificare l’ordine delle fasi che potrà essere adattato in base alla tipologia di target da valutare.

Nei prossimi articoli affronteremo tutti i capitoli con vari esempi e casi reali. Partiamo dalla definizione del Target e Test Plan

Definizione del Target / Test Plan

Il primo capitolo che deve essere affrontato obbligatoriamente, parte da una unica semplice domanda: Cosa vogliamo testare? Perché?

Non aver ben chiaro la risposta alla domanda, porterà con sé uno spreco eccessivo di risorse.

In primis, è necessario creare un documento che elenchi le linee guida e le informazioni che dovranno essere estratte o trovate nei sistemi target. (es. informazioni dell’infrastruttura). Si procederà poi ad un Test Plan prevedendo l’allocazione delle risorse necessarie, analisi dei costi, NDA, regole di ingaggio ecc…

N.B: Il Plan potrà comprendere anche eventuali limitazioni o restrizioni nel condurre il PenTest.

Dovranno essere definiti anche i vantaggi fondamentali che il cliente ricevere in favore del raggiungimento degli obiettivi aziendali tramite PenTest. È una sezione che sarà utile a valutare il risultato ottenuto in termini qualitativi.

Si parte, da alcuni punti:

  • Raccolta di informazioni base come nome dell’azienda, indirizzo, sito web, contatti, numeri di telefono etc…
  • Si definisce il vero obiettivo del PenTest;
  • Si stabilisce la tipologia di PenTest (black/ white / Ingegneria sociale inclusa/esclusa…)
  • Quanti target devono essere testati;
  • Quali sistemi operativi utilizza la vostra infrastruttura (info dipendente dall’approccio scelto)
  • Device di rete da testare? (IDS/IPS/ load balancer…)
  • Disaster recovery plan definito?
  • Standard che l’azienda deve rispettare?
  • Contatti del capo progetto;
  • Tempo di esecuzione dei test;
  • Budjet;
  • Ulteriori info/richieste.

È importante comprendere anche come dovrà essere redatto il report finale:

  • Report per l’esecutivo;
  • Report tecnico;
  • Report per sviluppatori.

In che modo dovrà essere consegnato:

  • Email;
  • Email cifrata;
  • Stampato;
  • Consegna a mano…

Una volta raccolti tutti i requisiti di base del Test Plan, in ultima analisi occorre assegnare le adeguate risorse e calendarizzare tutte le attività; tramite alcuni strumenti è possibile gestire i progetti in corso e poterne mantenere facilmente traccia.

Nel prossimo articolo, si introdurrà il concetto ed esempi pratici di Information Gathering.

Configurazione di macchine Linux su Azure tramite DSC

In un articolo precedente (https://www.ictpower.it/guide/installare-e-configurare-powershell-desired-state-configuration-for-linux.htm) abbiamo visto come configurare un ambiente per il deploy automatico di packages tramite Desired State Configuration for Linux su client e server nella nostra rete locale.

Vediamo cosa succede nel caso in cui l’esigenza è quella di configurare delle macchine linux che si trovano invece sul cloud di Microsoft, da tutti conosciuto con il nome di Azure. Per questo esempio utilizzeremo una macchina Debian, creandola utilizzando uno dei template disponibili; per creare le risorse su Azure è necessario possedere una sottoscrizione attiva.

Iniziamo proprio creando le risorse necessarie su Azure, effettuiamo quindi il login su https://portal.azure.com e selezioniamo dal menu:

Nuovo -> Calcolo -> Ubuntu Server 16.04 LTS

Quindi facciamo click su Crea per avviare la configurazione di una macchina virtuale Ubuntu.

Un semplice wizard richiederà di compilare tutte le informazioni necessarie, quali tecnologia dei dischi da utilizzare, nome macchina, modalità di autenticazione e gruppo di risorse a cui associare la VM. Sceglieremo poi le risorse hardware, la configurazione della rete ed eventuali servizi aggiuntivi. In pochi minuti una notifica sulla pagina web del portale ci informerà del completamento dell’operazione, e la nostra macchina sarà raggiungibile tramite collegamento ssh direttamente sull’ip pubblico assegnato.

Il wizard chiede di assegnare un nome al gruppo di risorse che conterrà la macchina Ubuntu e tutti i servizi correlati (storage, rete, ecc…); questo nome verrà utilizzato in seguito per creare altre risorse. Per il mio esempio il nome del gruppo di risorse è LinuxDSC.

Allo stato attuale le versioni di OMIserver e dell’agent DSC non permettono il deploy corretto delle configurazioni nel caso queste prevedano l’installazione di pacchetti software. Essendo il nostro scopo proprio quello di installare dei servizi sulla macchina linux remota, è neccessario procedere all’aggiornamento dei due pacchetti. L’operazione è molto semplice e possiamo effettuarla direttamente connettendoci via SSH alla macchina remota. Io ho utilizzato Windows Bash, ma possiamo utilizzare putty o un qualsiasi altri client ssh.

Connettiamoci via SSH quindi all’IP pubblico che troviamo sul portale Azure, relativo alla nostra VM, ed eseguiamo sulla macchina linux i seguenti comandi per scaricare nella cartella /tmp le versioni (ad oggi) più recenti di OMI server e PowerShell DSC:

sudo wget https://github.com/Microsoft/omi/releases/download/v1.1.0-0/omi-1.1.0.ssl_100.x64.deb -P /tmp

sudo wget https://github.com/Microsoft/PowerShell-DSC-for-Linux/releases/download/v1.1.1-294/dsc-1.1.1-294.ssl_100.x64.deb -P /tmp

e li installiamo con:

sudo dpkg -i /tmp/omi-1.1.0.ssl_100.x64.deb /tmp/dsc-1.1.1-294.ssl_100.x64.deb

Possiamo verificare di avere le versioni corrette con i comandi:

sudo dpkg -l | grep dscsudo dpkg -l | grep omi

 

E’ possibile anche avviare una sessione SSH utilizzando PowerShell, ma è necessario installare un modulo aggiuntivo chiamato Posh-SSH, per aggiungere il supporto a questo protocollo. Il modulo è eventualmente disponibile sul sito PowerShell Gallery a questo indirizzo:

https://www.powershellgallery.com/packages/Posh-SSH/1.7.7

Per l’installazione, in ogni caso, è sufficiente aprire PowerShell come amministratore ed eseguire:

Install-Module -Name Posh-SSH

Volendo utilizzare i cmd-let di PowerShell per gestire la nostra sottoscrizione Azure abbiamo bisogno di installare anche i moduli Azure PowerShell, scaricando ed installando il pacchetto disponibile a questo link:

http://aka.ms/webpi-azps

A questo punto possiamo effettuare il login su Azure utilizzando ilcomando

Add-AzureRmAccount

Dopo aver inserito le credenziali, PowerShell ci risponde con i dettagli della sottoscrizione:

Nel caso esistano più sottoscrizioni con lo stesso account possiamo selezionare quella da utilizzare con i seguenti comandi:

#Connessione ad Azure

Add-AzureRmAccount

#Selezione subscription

$subscription (Get-AzureRmSubscription  Out-GridView -Title ‘Select an Azure Subscription …’  -PassThru)

Set-AzureRmContext -SubscriptionId $subscription.subscriptionId -TenantId $subscription.TenantID

E’ necessario quindi creare un ulteriore “Account di archiviazione” o “Storage Account” per ospitare le configurazioni DSC. Utilizziamo anche qui Azure PowerShell specificando il nome del nostro Resource Group, il nome del nuovo storageaccount da creare e la location. I valori disponibili per la variabile $Location ad oggi sono i seguenti: eastus, eastus2, eastus2stage, westus, westeurope, eastasia, southeastasia, japaneast, japanwest, northcentralus, southcentralus, centralus, northeurope, brazilsouth, australiaeast, australiasoutheast, southindia, centralindia, westindia, canadaeast, canadacentral, westus2, westcentralus, uksouth, ukwest, koreacentral, koreasouth

$ResourceGroupName “LinuxDSC”

$storageaccountName “dscdisk”

$Location “westeurope”

New-AzureRmStorageAccount -ResourceGroupName $ResourceGroupName -Name $storageaccountName -Type Standard_LRS -Location $Location

Al termine dell’elaborazione ci verrà restituito un messaggio di conferma

Possiamo verificare che il nuovo storage account è disponibile sul portale Azure:

Creiamo ora un container all’interno dello storage account; per non appesantire la guida creiamo il container con “Permission -Off” rendendo accessibile il container solo al proprietario. Essendo le variabili già definite eseguiamo:

Set-AzureRmCurrentStorageAccount -ResourceGroupName $ResourceGroupName -Name $storageaccountName

New-AzureStorageContainer -Name linuxdsc -Permission Off

Il container è subito disponibile, e ce lo conferma la risposta nella PowerShell

Ora prepariamo la nostra macchina per eseguire il push della configurazione, nel mio caso sto utilizzando una macchina con Windows 10 Pro. Abbiamo bisogno di installare il modulo DSC for Linux, quindi eseguiamo da una PowerShell con diritti amministrativi il comando:

Install-Module –name nx

In alternativa è possibile effettuare il download del pacchetto MSI da:

https://www.microsoft.com/en-us/download/details.aspx?id=46919

ed installarlo utilizzando le opzioni predefinite. L’installazione provvederà ad aggiungere il modulo nx, necessario per l’utilizzo di DSC for Linux nella cartella

%USERPROFILE%\Documents\WindowsPowerShell\Modules

Tutto è pronto per la preparazione di uno script di configurazione, che per l’occasione consisterà nell’installazione automatizzata del servizio httpd sulla nostra macchina Azure con sistema operativo Ubuntu. Lo script è molto semplice, e va eseguito direttamente da PowerShell. Consiste in una prima parte di dichiarazione della configurazione ed una seconda in cui viene eseguito il comando per generare il file .mof che DSC utilizzerà per eseguire il push sulla macchina remota.

Personalmente ho avuto un po’ di problemi nell’incollare lo script nella finestra PowerShell poiché venivano stranamente aggiunti caratteri in modo casuale corrompendo il testo incollato. Non sapendo se il problema dipende da qualcosa di particolare nella mia situazione, mostro comunque il workaround utilizzato.

Ho incollato lo script direttamente nell’ISE e salvato in formato .ps1, quindi ho richiamato l’esecuzione dello script direttamente da PowerShell. Per aprire l’ISE è sufficiente cercare PowerShell ISE nella barra della ricerca di Windows, o lanciare il comando ISE da PowerShell.

Lo script utilizzato è il seguente:

Configuration
ubuntuconf {


Import-DscResource -Module nx


Node “localhost” {

    nxPackage
Apache {

        PackageManager ‘Apt’

        Ensure ‘Present’

        Name ‘apache2’

    }

}

}

ubuntuconf -OutputPath: “C:\temp”

Salviamo lo script ad esempio con il nome conf.ps1 e lo eseguiamo da PowerShell:

.\conf.ps1

Verrà creato un file chiamato <nomehost>.mof nella directory indicata nello script; questo file è il modello che DSC confronterà con lo stato attuale della macchina da configurare, effettuando in maniera automatizzata le eventuali operazioni di adeguamento. Nel nostro caso, ad esempio, si assicurerà che il pacchetto apache2 sia installato.

Trasferiamo questo file all’interno del container che abbiamo creato su Azure con il comando PowerShell:

Set-AzureStorageBlobContent -Container linuxdsc -File C:\temp\localhost.mof

Anche in questo caso possiamo verificare dal portale Azure che il nostro contenitore include il file .mof che abbiamo appena inviato

Ora è necessario configurare i privilegi di accesso su questo file per fare in modo che la nostra macchina Ubuntu sia in grado di leggerlo. A costo di complicare un po’ la procedura evitiamo di ottenere un link pubblico impostando l’accesso con autenticazione tramite Shared Access Signatures (SAS), creando un opportuno token. Possiamo impostare un limite di tempo per la validità di questo token, e per questo esempio imposteremo 1 mese.

$templateuri New-AzureStorageBlobSASToken -Container linuxdsc -Blob ‘localhost.mof’ -Permission -ExpiryTime (Get-Date).AddMonths(1) -FullUri

Il comando

echo $templateuri

ci restituirà il valore da utilizzare nello script DSC descritto successivamente. Infine otteniamo l’elenco delle chiavi disponibili con il commando:

Invoke-AzureRmResourceAction -ResourceGroupName $ResourceGroupName -ResourceType Microsoft.Storage/storageAccounts -ResourceName $StorageAccountname -Action listKeys -ApiVersion 2015-05-01-preview -Force -OutVariable keys

Essendo sufficiente al nostro scopo la key1, per ottenere la chiave da utilizzare nel prossimo script possiamo eseguire eseguire da PowerShell:

$keys[0].key1

Siamo pronti quindi ad effettuare il deploy della nostra configurazione eseguendo uno script PowerShell DSC; per personalizzare lo script abbiamo bisogno di tenere presente le variabili relative allo storage account ed alle chiavi che permettono la lettura del file mof. Le variabili sono:

StorageAccountName (il nome dell’account archivio creato nel primo step), StorageAccountKey (La key1 restituita dal comando precedente), FileUri (Il valore restituito dopo l’upload del file mof), vmname (il nome della risorsa della macchina virtuale su Azure)

Eseguiamo il cmd-let per conoscere l’ultima versione di DSCforLinux disponibile

$extensionName ‘DSCForLinux’

$publisher ‘Microsoft.OSTCExtensions’

Get-AzureRmVMExtensionImage -PublisherName Microsoft.OSTCExtensions -Location $location -Type DSCForLinux

E settiamo la variabile version utilizzando questa versione

$version ‘2.2’

Poi settiamo le variabili relative all’autenticazione:

$privateConfig 

‘{

“StorageAccountName”: “linuxdsc”,

“StorageAccountKey”: “//storageaccountkey//”

}’

$publicConfig ‘{

“Mode”: “Push”,

“FileUri”: “//fileuri//”

}’

E finalmente lanciamo il deploy del modello che avevamo creato sulla vm Linux su Azure, avendo cura di settare la variabile $vmName indicando il nome della VM su Azure, nel mio caso:

$vmName=“LNXClient01”

Set-AzureRmVMExtension -ResourceGroupName $ResourceGroupName -VMName $vmName -Location $location -Name $extensionName -Publisher $publisher -ExtensionType $extensionName -TypeHandlerVersion $version -SettingString $publicConfig -ProtectedSettingString $privateConfig

Un messaggio di OK ci conferma l’avvenuto deploy della configurazione. In questo caso abbiamo installato il pacchetto apache2 (Webserver apache) sulla nostra macchina di test.

Nel caso si verificassero degli errori è possibile analizzare i log direttamente sulla macchina Linux; possiamo trovare informazioni dettagliate sulle operazioni relative a DSC nel file /var/log/azure/DSCForLinux/<versione>/extension.log

Per verificare il funzionamento del servizio creiamo dal portale Azure una regola di firewall all’interno delle risorse di tipo “Gruppo sicurezza di rete” per consentire le connessioni sulla porta 80 (servizio http), e proviamo ad aprire un browser navigando direttamente sull’ip pubblico della nostra macchina.

Il webserver è attivo e raggiungibile dall’esterno

Possiamo ora divertirci a provare infinite configurazioni, ricordando che DSC è in grado di effettuare tantissime operazioni sulla macchina client, fra le quali gestione di file e cartelle, installazione e rimozione di pacchetti, gestione gruppi e utenti ed esecuzione di script.

Personalmente credo che questa funzionalità abbia un potenziale davvero enorme, e sembra quasi incredibile come su una infrastruttura proprietaria Microsoft sia possibile utilizzare servizi di automazione completamente Open Source.

Migrare una macchina fisica Linux verso Microsoft Azure

Al giorno d’oggi, nella gestione di infrastrutture, può capitare di dover effettuare migrazioni di macchine fisiche verso il cloud. Questa operazione richiede un’attenta analisi dello scenario e una procedura dettagliata che può variare in base al sistema operativo che si vuol migrare.

In questa guida analizzeremo tutti gli step necessari per migrare una macchina fisica Ubuntu 16.04 verso i servizi cloud di Azure.

La prima fase racchiude tutte le operazioni relative alla preparazione della macchina nel rispetto dei requisiti di Azure.

1. Nella macchina fisica è necessario aggiornare gli archivi con quelli di Azure in /etc/apt/sources.list

Per effettuare l’operazione basterà eseguire da terminale:

# sudo sed -i 's/[a-z][a-z].archive.ubuntu.com/azure.archive.ubuntu.com/g' /etc/apt/sources.list

# sudo apt-get update

2. È necessario aggiornare il sistema operativo al kernel più recente eseguendo i comandi seguenti:

# sudo apt-get update

# sudo apt-get install linux-generic-hwe-16.04 linux-cloud-tools-generic-hwe-16.04

# sudo apt-get dist-upgrade

# sudo reboot

3. Modificare la configurazione di avvio del kernel per Grub in modo da includere ulteriori parametri del kernel per Azure.

Per fare questo, editare il /etc/default/grub e modificare la stringa GRUB_CMDLINE_LINUX_DEFAULT nel seguente modo:

GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0,115200n8 earlyprintk=ttyS0,115200 rootdelay=300"

4. Dopo la modifica lanciare sudo update-grub per aggiornare la configurazione.

5. Per poter interfacciare la macchina con i servizi di Azure è necessario installare l’Agente Linux di Azure. L’installazione di questa componente avviene attraverso i seguenti comandi:

# sudo apt-get update

# sudo apt-get install walinuxagent

6. Successivamente è necessario effettuare il deprovisioning della macchina e prepararla per il provisioning in Azure:

# sudo waagent -force -deprovision

# export HISTSIZE=0

# logout

La seconda fase racchiude tutte le operazioni necessarie per convertire la macchina fisica in un’immagine. In questa fase ci avvarremo dell’utilizzo di due strumenti:

  • DD è una componente di Linux comunemente usata per creare le immagini di un disco e produrne un file immagine
  • VHDTool è uno strumento per Windows utilizzato per manipolare i file VHD (Download: http://bit.ly/1FWQzVx)
1. Per creare l’immagine del disco della macchina bisogna lanciare il seguente comando:

dd if=/dev/sda of=/mnt/my_ubuntu_disk.img

dove sda fa riferimento all’intero disco della macchina e my_ubuntu_disk.img è il nome di dell’immagine che andremo a creare all’interno di un mount point che potrà essere un disco esterno oppure una share di rete.

N.B. L’operazione potrebbe durare molto tempo in caso di disco di grosse dimensioni. Il prompt non darà alcun feedback fino al termine dell’operazione. È possibile monitorare lo stato della creazione dell’immagine dalle variazioni della dimensione del file.

DD crea l’immagine includendo anche lo spazio vuoto. Eventualmente è possibile usare ulteriori tool per ridurre la dimensione dell’immagine. È pertanto necessario utilizzare uno spazio di appoggio sufficientemente grande.

2. Dal prompt dei comandi di Windows lanciare VHDTool /convert c:\my_ubuntu_disk.img

3. Rinominare il file my_ubuntu_disk.img con estensione .vhd

Nella terza fase si procederà all’upload del VHD su Azure e alla creazione della macchina virtuale.

1. Tramite l’interfaccia della riga di comando di Azure 2.0 accedere alla sottoscrizione attraverso il comando az login

2. Creare un gruppo di risorse. I gruppi di risorse riuniscono in modo logico tutte le risorse di Azure a supporto delle macchine virtuali. Per creare il gruppo eseguire: az group create –name myResourceGroup –location westus

3. Creare un account di archiviazione per il VHD nel gruppo di risorse appena creato con il comando:

az storage account create --resource-group myResourceGroup --location westus \

     --name mystorageaccount --kind Storage --sku Standard_LRS

4. Generare le chiavi di accesso per l’account di archiviazione:

az storage account keys list --resource-group myResourceGroup --account-name mystorageaccount

Al termine dell’esecuzione del comando, prendere nota del valore di key1 poiché verrà utilizzato per accedere all’account di archiviazione.

5. Creare un contenitore di archiviazione per organizzare i dischi in modo logico:

az storage container create --account-name mystorageaccount \

--account-key valoredikey1 --name mydisks

6. Il seguente passaggio permetterà l’effettivo caricamento del VHD su Azure:

az storage blob upload --account-name mystorageaccount \

--account-key key1 --container-name mydisks --type page \

--file /path/to/disk/my_ubuntu_disk.vhd --name myUbuntu.vhd

7. Per creare una macchina virtuale dal disco rigido virtuale, occorre convertire innanzitutto il disco rigido virtuale in un disco gestito con il comando:

az disk create --resource-group myResourceGroup --name myManagedDisk \

--source https://mystorageaccount.blob.core.windows.net/mydisks/myUbuntu.vhd

8. Una volta creato il disco gestito, lanciando il seguente comando, si otterrà il suo URI di cui prenderemo nota:

az disk list --resource-group myResourceGroup \

    --query '[].{Name:name,URI:creationData.sourceUri}' --output table

9. Infine, per creare la macchina virtuale:

az vm create --resource-group myResourceGroup --location westus \

--name myVirtualMachine --os-type linux \

--admin-username miouser --admin-password miapassword \

--attach-os-disk uri_del_disco

Una volta terminata la procedura, avremo riprodotto la macchina fisica sul cloud di Azure. Da questo momento del completamento del deploy, potremo gestire la macchina dal portale di Azure.


Bisognerà effettuare delle verifiche sull’apertura degli endpoint corrispondenti ad eventuali porte configurate sulla macchina fisica. Inoltre, grazie ai servizi cloud, sarà possibile completare la configurazione aggiungendo nuove funzionalità alla macchina come ad esempio un set di disponibilità.

Switch delle shell Linux con Windows 10 WSL

Sono passati 9 mesi dal rilascio di Windows 10 Anniversary Update, l’aggiornamento del sistema operativo che ha introdotto la funzionalità Windows Subsystem for Linux (WSL), grazie alla quale è possibile eseguire su Windows i binari di tipo ELF64, compilati cioè per funzionare su un sistema operativo Linux.

All’interno della community ICTPower ci siamo spesso occupati di questa nuova funzionalità, poiché ribadisce con forza la volontà di Microsoft di avvicinare il mondo dell’Open Source, e costituisce quindi una delle novità più importanti della politica aziendale degli ultimi tempi.

Rimandiamo quindi agli articoli precedenti in cui abbiamo illustrato gli step per l’installazione di questa funzionalità:

https://www.ictpower.it/sistemi-operativi/windows-subsystem-for-linux-finalmente-in-una-release-ufficiale.htm

e mostrato come sostituire l’immagine di Ubuntu di default con una contenente Suse:

https://www.ictpower.it/guide/opensuse-in-windows-subsystem-for-linux-in-windows-10.htm

In questo articolo, invece, presentiamo un progetto molto interessante che è possibile trovare su github, chiamato WSL Distribution Switcher. Come è possibile intuire dal nome si tratta di un tool in grado di tenere installate sul nostro client Windows 10 molteplici distribuzioni di Linux, ed impostare quella in uso con WSL con un semplice comando.

Finalmente, quindi, ognuno è libero di utilizzare la propria distribuzione preferita, e l’occasione è imperdibile per chi si sta avvicinando al mondo Linux per la prima volta per provare le differenze tra le varie distribuzioni senza creare un numero enorme di macchine virtuali, e scegliere quella più adatta alle proprie esigenze. L’occasione è imperdibile anche per me, poiché utilizzando in maniera molto più agevole CentOS rispetto alle altre, finalmente ho la possibilità di farlo anche con WSL.

Come premessa riporto la pagina del progetto è la seguente, in modo da poterla seguire per tutti gli aggiornamenti futuri:

https://github.com/RoliSoft/WSL-Distribution-Switcher

Il tool è costituito da una serie di immagini, una per ogni distribuzione di Linux, ed uno script per effettuare lo switch da una distribuzione all’altra. Lo script è scritto in Python, un linguaggio di programmazione molto semplice e dinamico, e quindi abbiamo bisogno di installare le relative librerie per utilizzarlo.

Scarichiamo l’ultima versione di Python3 dal sito python.org, ad oggi troviamo la versione 3.6.1 disponibile a questo link:

https://www.python.org/ftp/python/3.6.1/python-3.6.1-amd64.exe

ed installiamo il pacchetto lasciando le impostazioni di default:

Scarichiamo quindi il pacchetto contenente il tool dall’indirizzo:

https://github.com/RoliSoft/WSL-Distribution-Switcher/archive/master.zip

Ed estraiamo l’archivio, ad esempio nella cartella Download

Nel mio caso particolare tutti i file sono nella cartella:

C:\Users\ICTPower\Downloads\WSL-Distribution-Switcher-master

Apriamo una PowerShell e posizionamoci in questa cartella. Per eseguire semplicemente questa operazione è possibile scrivere “powershell” nella barra degli indirizzi della cartella stessa, ed avviamo il download della distribuzione desiderata utilizzando lo script get-source. Iniziamo, ad esempio, scaricando un’immagine di CentOS con il comando:

py.exe .\get-source.py centos

Allo stesso modo è possibile effettuare il download di debian, fedora, suse ed alpine; in futuro saranno sicuramente disponibili immagini di altre distribuzioni. Per eseguire lo step successivo è necessario che WSL sia installato ma non attivo, quindi non dovranno essere aperte istanze di Windows bash al momento dell’esecuzione del comando altrimenti lo script restituirà un errore.

Scaricata l’immagine la installiamo con:

py.exe .\install.py centos

Al termine delle operazioni l’immagine appena installata diventa quella di default all’apertura di Windows bash, verifichiamolo subito aprendo una shell eseguendo dal prompt dei comandi:

bash

e leggiamo il contenuto del file /etc/os-release, che nelle distribuzioni CentOS ci da un po’ di informazioni sulla versione in uso

cat /etc/os-release

Come possiamo vedere ci troviamo su una CentOS7, loggati nel sistema con l’utente creato in fase di installazione di WSL. Nel mio caso il nome dell’utente è gnanoia. Ho trovato un problema nell’eseguire il comando “su” e guadagnare i privilegi di root. Al momento della richiesta della password, infatti, questa non veniva riconosciuta. Non avendo modo di indagare se il problema fosse dovuto alla versione dell’immagine, alla mia build di Windows10 o ad altri fattori, ho trovato un rapido workaround settando l’utente root come predefinito all’apertura di Windows bash; in questo modo la shell viene avviata senza la richiesta di alcuna password ed è possibile eseguire il comando “passwd” per settarne una nuova. E’ poi possibile reimpostare l’utente non privilegiato come predefinito per tornare alla condizione iniziale.

E’ possibile modificare l’utente predefinito di WSL utilizzando il comando lxrun /setdefaultuser <user>, quindi nel nostro caso eseguiamo da un prompt di DOS:

lxrun /setdefaultuser root

quindi apriamo bash e modifichiamo la password con il comando

passwd

chiudiamo la shell di root con

exit

chiudimo la shell iniziale per tornare al DOS con

exit

e risettiamo l’utente iniziale come predefinito. Nel mio caso:

lxrun /setdefaultuser gnanoia

Tutta la sequenza è visibile nello screenshot seguente:

Proviamo ora ad avviare bash ed utilizzare su per utilizzare la shell con privilegi amministrativi:

Ora la nostra immagine Centos7 è completa e funzionante, e possiamo utilizzare il gestore dei pacchetti yum per installare i nostri software preferiti.

Da un’analisi più approfondita però sono emerse delle limitazioni dovute alla tenera età di WSL, per cui non risulta possibile installare alcuni pacchetti, probabilmente per la mancanza del supporto ad alcune syscall; non ci rimane che essere pazienti e sperare che questa funzionalità cresca il più velocemente possibile chissà che nella prossima build di Windows10 non sia già tutto perfettamente funzionante.

In particolare i test di installazione sono falliti per iptools ed httpd, nello screenshot seguente vediamo il dettaglio dell’errore:

yum install httpd

Alla fine dell’elaborazione del comando il risultato sarà quello mostrato in figura:

Senza allarmarci troppo, quindi, fiduciosi di una rapida risoluzione, non perdiamo troppo di vista lo scopo dell’articolo, e torniamo all’installazione di distribuzioni alternative di Linux per WSL, provando ad effettuare in maniera rapida lo switch da una all’altra.

Torniamo quindi sulla nostra PowerShell per scaricare ed installare un’immagine di debian.

Come per l’installazione precedente, lo script imposta l’ultima immagine installata come predefinita, quindi avviando Windows bash ci aspettiamo di trovare una shell Debian. Infatti…

Per switchare da una distribuzione all’altra non è ovviamente necessario reinstallarla, quindi volendo tornare ad utilizzare CentOS, od una qualsiasi altra distribuzione già installata possiamo ricorrere allo script per lo switch:

py.exe .\switch.py centos

Verifichiamo che l’operazione ha avuto successo riaprendo bash e leggendo il file /etc/os-release

Ringraziamo sentitamente gli autori dello script, e rimaniamo in attesa della disponibilità delle nostre immagini preferite; anche in questo caso non possiamo fare a meno di notare che l’avvicinamento di Microsoft al mondo dell’Open Source sta scatenando una miriade di contributi di chi, ognuno a modo proprio, cerca di favorire la completa integrazione dei sistemi.

Scenari di accesso a server Linux attivi in Microsoft Azure

Gestione degli ambienti grafici in Console

Normalmente nell’utilizzo di server on-premise si ha accesso alla console di sistema ed è quindi possibile il pieno controllo utilizzando anche la console grafica. In Azure non disponendo di una console vera propria l’accesso al desktop del sistema operativo è meno agevole.

In questo scenario l’utilizzo di sistemi Linux piuttosto che Windows presenta ulteriori differenze.

In Windows è possibile l’accesso in console grafica tramite RDP, e con l’opzione /console ottenere la condivisione della sessione 0.

In Linux è meno agevole eseguire applicazioni grafiche su host attivi in Cloud, ma con pochi semplici accorgimenti è possibile ridirigere la console del server su una postazione on premise da cui effettuare la gestione.

Il tutto si basa su X Windows , l’ambiente grafico disponibile su (quasi) tutti i sistemi Linux, e sul re-indirizzamento dell’interfaccia a partire da una sessione terminale SSH all’interno della quale transiterà tutto il traffico.

Condizione essenziale affinché sia possibile eseguire remotamente applicazioni è che la postazione dove queste vengono visualizzate abbia un server X installato. Se si accede da una postazione Linux questa funzionalità è attiva di default (a meno che non si scelgano installazioni minimal).

In Windows dovremo installare un server X Windows, ossia una sorta di emulatore in grado di visualizzare localmente le applicazioni eseguite sul sistema in Cloud.

Configurazioni sul server Linux in Azure

Per abilitare la funzione di Forwarding dell’interfaccia X11 all’interno di SSH, in modo che l’applicazione eseguita remotamente venga visualizzata sulla postazione di gestione, è necessario modificare il file sshd_config presente in /etc/ssh/ a
All’interno del file sono presenti la varie impostazioni relative all’ambiente grafico, in questo caso ci soffermiamo sulla riga #ForwardX11 no

Individuata questa impostazione dovremo rimuovere il # ad inizio riga e modificare il valore NO ( di default) portandolo a YES.

A questo punto sarà sufficiente attivare una sessione SSH con l’opzione -X verso il server. all’interno di una sessione terminale eseguita dall’ambiente grafico della postazione di gestione.

ssh -X utente@ip-server

Figura1

Eseguito il comando si aprirà una sessione terminale verso il server Linux e sarà possibile visualizzare localmente un’applicazione grafica eseguita sul server in cloud.

Figura2: Browser Firefox eseguito su server Linux in Cloud ma visualizzato su postazione locale

Apparentemente questa modalità operativa non è di grande aiuto in quanto normalmente tramite l’interfaccia a caratteri è possibile effettuare la completa gestione di un sistema Linux, ma ad esempio, in installazioni dove è necessario avviare un browser locale al server per eseguire attività di configurazione, questo modo di operare risulta l’unico possibile, se non consideriamo la possibilità di installare VNC nella versione per Linux o altri software analoghi, ma implicano ulteriori attenzioni in termini di sicurezza.

Considerazioni relative all’ambiente Windows

Quanto visto fin qui è applicabile se la postazione da cui si esegue il management è anch’essa Linux, nel caso in cui la connessione avvenga da una postazione Windows dovremo installare su quest’ultima un server X-Windows in grado di dialogare con il sistema operativo in Cloud, esistono vari software anche a pagamento, in questo scenario abbiamo utilizzato XMing disponibile sul sito ufficiale, dopo aver fatto una modesta “donazione”, ma scaricabile anche da Sourceforge gratuitamente nella versione precedente. (unica nota è che ad oggi la versione “libera” non è ancora dichiarata compatibile con Windows 10)

Per poter eseguire, come nell’esempio visto prima, un’applicazione grafica, dobbiamo anche da Windows accedere con una sessione SSH sul server Linux, a questo scopo è possibile utilizzare PUTTY configurando la sezione relativa alla redirezione X11

Dopo aver definito il nome/indirizzo Host, nella configurazione SSH è sufficiente attivare il flag relativo alla funzione di X11 Forwarding, e dopo aver aperto la sessione terminale eseguire l’applicazione voluta

Figura 5 Browser Firefox eseguito su server Linux in Cloud ma visualizzato su postazione locale Windows

Lo scenario considerato è basato su una distribuzione Centos, come ho avuto modo di dire in articoli precedenti, trattandosi di sistemi Linux, ed essendo questo sistema operativo molto differente nelle varie distribuzioni, anche presenti in Azure, è possibile che ci siano alcune differenze di implementazione, è sempre consigliabile utilizzare MAN al fine di ottenere le informazioni puntuali sulla distribuzione in uso.

In breve queste sono le possibilità offerte per ottenere un accesso ad applicazioni grafiche che per ragioni differenti devono essere eseguite su un server Linux attivo in Azure. Come si è visto, il perno di tutta la funzione di redirezione del “desktop”, al di là del server X-Windows è SSH che in questo caso opera come un vero e proprio Tunnel, questa funzione è utilizzabile anche per effettuare l’accesso servizi che per motivi più diversi non sono esposti pubblicamente ma soltanto accessibili localmente, magari attraverso l’interfaccia di Loopback.

Utilizzo di SSH tunnel per accesso a PhpMyadmin su Azure VM LAMP

Le scelte disponibili dalla gallery di Azure comprendono numerose possibilità in ambito Open Source tra queste, per gli utilizzatori degli ambienti LAMP, (Linux Apache MySQL PhpMyadmin) sono disponibili ad oggi, una serie di immagini già preconfigurate. Alcune a pagamento, altre gratuitamente.

Utilizzando dalla gallery “l’immagine” Lamp fornita da Bitnami con pochi click possiamo installare un ambiente completo con le tre componenti configurate e funzionanti.

Una peculiarità di questa installazione è quella di avere l’accesso al servizio di PhpMyadmin accessibile esclusivamente dal localhost. Questa scelta è dettata esclusivamente da ragioni di sicurezza, in quanto è preferibile mantenere protetta la gestione di MySQL non esponendo il servizio sull’ip pubblico del server.

E’ possibile una gestione completa da riga di comando, ma le varie operazioni di configurazione non sono semplici, in uno scenario di questo tipo, l’accesso alla gestione è ragionevole che avvenga per mezzo del browser.

Consideriamo anche che in un ambiente Cloud-Based risulta difficile attivare una console grafica da cui eseguire un browser direttamente sul server linux e per contro, risulta sconveniente modificare la configurazione in modo da consentire un accesso “pubblico” al servizio.

Il sistema operativo Ubuntu, Bitnami usa questa distro per il deploy del server LAMP, è accessibile in SSH tramite un normale emulatore terminale.

Con SSH, come abbiamo visto in precedenza, è possibile definire un Tunnel in modo da incanalare il traffico verso porte normalmente bloccate utilizzando una sorta di redirezione. In questo modo è possibile accedere al servizio PhpMyadmin in ascolto sulla porta 80 LOCALHOST del server Lamp anche da postazioni esterne. Si evita così di dover utilizzare, come in questo caso, un browser sul server stesso.

Funzionamento del Tunnel SSH

Lo schema e le relazioni in gioco nei vari componenti è il seguente:

Figura 6

In pratica l’emulatore SSH opportunamente configurato “apre” una porta tcp (in questo caso 7654) in ascolto sull’host locale (il pc di gestione) e ridirige il traffico verso l’endpoint su cui ha effettuato la connessione, in questo modo tutto il traffico transita verso l’host attraversando il Tunnel cifrato reso disponibile da SSH.

Nello scenario descritto in questo documento il tunnel viene utilizzato per l’accesso al servizio Web Apache dell’amministrazione di MySQL, ma questa implementazione in generale è valida per tutti i servizi che per ragioni differenti si vogliono mascherare o non sono accessibili dall’ip pubblico dei server in Azure non necessariamente di questa sola immagine.

Se consideriamo la postazione remota con sistema operativo Windows possiamo utilizzare Putty come emulatore terminale SSH, la configurazione è semplice ed attivabile con pochi passaggi

Per prima cosa è necessario definire una connessione verso l’host dove è presente LAMP

Figura 7 Configurazione Putty

Successivamente selezionare nel ramo “connection” la voce SSH e poi ancora Tunnels (1)

Figura8 definizione delle opzioni per il Tunnel SSH

Nei campi a destra “Source Port” (2) e “Destination” (3) dovremo inserire rispettivamente la porta che verrà aperta sul pc locale, l’indirizzo del server in Cloud e la porta che ospita il servizio a cui vogliamo accedere, in questo caso trattandosi di PhpMyadmin in ascolto su porta 80 in Localhost imposteremo questo valore.

Nel caso si volesse, tramite questa connessione SSH in Tunnel, accedere ad un altro host sulla rete in Azure, sarà sufficiente digitarne l’ip o il nome fqdn. In questo caso il server su cui è attiva la connessione opererà come una sorta di gateway verso l’host desiderato.

La possibilità offerta dall’impostazione al punto (4) permette, al client locale su cui Putty è attivo, di operare come gateway, analogamente a quanto detto per il punto 3, ma dal lato della rete on-Premise in questo modo le varie postazioni potranno “puntare” all’indirizzo Ip/Porta della postazione ed accederanno al medesimo servizio su Azure.

Figura 9 apertura del socket sulla porta configurata

Utilizzando un browser dal lato client è sufficiente riferirsi all’indirizzo localhost in porta 7654 per accedere.

Figura 10

Questa configurazione è possibile tramite Putty su sistemi Windows ma se on premise disponessimo di un host con sistema operativo Linux sarà sufficiente eseguire SSH da riga di comando con i parametri corretti.

Figura 11 SSH Tunnel in Linux

La sintassi del comando in Linux è la seguente:

ssh -N -L:<porta-locale>:127.0.0.1:<porta-remota> utente@host-remoto

NOTA BENE se il comando, richiesta la password di autenticazione, non ritorna errori ma resta con il cursore lampeggiante senza ritornare al prompt comandi il funzionamento è regolare.

Per verificare la correttezza della configurazione è sufficiente anche in questo caso aprire la pagina di PhpMyadmin

Figura 12 accesso a PhpMyadmin

Per questa configurazione è stato utilizzato Putty come applicazione Client in Windows, ma normalmente i vari emulatori SSH prevedono la funzionalità di Tunneling. L’emulatore PUTTY è liberamente utilizzabile, leggero e non richiede installazione, in commercio esistono vere e proprie applicazioni che oltre ad essere emulatori hanno in sé anche la componente di X-Windows server.

Tra tutti quelli disponibili Mobaxterm ha la possibilità di un uso libero fino a otto sessioni verso diversi Host

Riferimenti:

Mobaxterm guida alla configurazione di un tunnel ssh

Putty download