Archivi categoria: Open Source

PowerShell Core 6: ancora Open Source in trionfo

Facebooktwittergoogle_plusredditlinkedin

E’ passato più di un anno e mezzo da quando il progetto PowerShell 6 è arrivato su GitHub (https://github.com/powershell/powershell). Per la prima volta PowerShell non è solo OpenSource, ma addirittura Cross-Platform. La nuova shell, con l’obiettivo principale di creare un ambiente leggero mantenendo una buona compatibilità con le versioni precedenti, è ormai stata rilasciata in versione stabile su una moltitudine di sistemi operativi. E’ infatti possibile installare la nuova release su tutti i sistemi operativi Windows client a partire da Windows 7 e su Windows Server a partire da 2008 R2, oltre che su molteplici distribuzioni Linux (CentOS, RedHat. Debian, Fedora, OpenSuse) ed addirittura MacOS dalla versione 10.12.

L’installazione è molto semplice e va effettuata a partire dal Setup scaricato direttamente dalla pagina download del progetto (https://github.com/PowerShell/PowerShell/releases), selezionando la versione relativa al proprio sistema operativo. Il setup della versione per Windows x64 ha una dimensione di circa 50MB.

Dopo aver accettato le condizioni e confermato il path per l’installazione possiamo aprire PowerShell 6 mettendo un segno di spunta su “Launch PowerShell”

Per avviare PowerShell successivamente è possibile richiamare pwsh.exe dal prompt dei comandi se siamo su Windows, o avviare pwsh se siamo su Linux o MacOS.

Come possiamo notare stiamo utilizzando l’edizione Core di PowerShell 6, che come abbiamo anticipato è molto leggera ed ha caratteristiche di compatibilità elevate, ma non è possibile utilizzare gli stessi CmdLet dell’edizione Desktop. E’ importante notare che le due edizioni possono coesistere su uno stesso sistema. Se proviamo ad eseguire sulla stessa macchina il comando powershell vediamo che è possibile utilizzare la PowerShell completa.

Potrebbe capitare di leggere della documentazione su questi due componenti, e li vediamo spesso indicati come FullCLR (Windows PowerShell) e CoreCLR (PowerShell Core)

Aiutiamoci con Windows Subsystem for Linux e scopriamo quanti moduli sono disponibili nelle due edizioni di PowerShell. Proviamo a lanciare su entrambe il comando Get-Module -ListAvailable , che ci restituisce l’elenco dei moduli utilizzabili, redirezionando l’output al comando Linux wc -l, che ci indica il numero di righe di cui questo elenco è composto. Il comando completo è quindi:

Get-Module -ListAvailable bash -c “wc -l”

Proviamo ad eseguirlo su PowerShell Core

E successivamente su PowerShell

La differenza è notevole, 22 moduli contro 100, ma come al solito parliamo di progetti nati da pochissimo tempo e sui quali viene investito un gran numero di risorse, quindi ci aspettiamo delle grosse novità in tempi brevi.

Ricordiamo ovviamente che sui sistemi operativi non Windows è utilizzabile unicamente l’edizione Core, ed a questo proposito indichiamo che su alcune distribuzioni Linux si rilevano problemi nell’ottenimento dell’ultima release utilizzando l’opzione update dei vari package manager. Se vi trovate in questa situazione è sufficiente disinstallare e reinstallare il componente utilizzando:

Sulle distribuzioni Debian/Ubuntu:

sudo apt remove powershell && sudo apt-get install powershell

Sulle distribuzioni RedHat/CentOS:

sudo yum remove powershell && sudo yum install powershell

Sul futuro di PowerShell Core, quindi, sappiamo che la direzione su cui il team di sviluppo si sta muovendo è quella di aumentare il numero dei comandi supportati in modo da avere sistemi, anche eterogenei, sempre più in simbiosi ed in grado di scambiarsi il maggior numero di informazioni possibili, così da permettere un management sempre più centralizzato.

Nel frattempo Windows PowerShell continua ad essere supportato ma probabilmente non ci saranno grossi sviluppi futuri.

Installazione di GLPI 9.2.0 in ambiente Linux

Facebooktwittergoogle_plusredditlinkedin

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


Come effettuare un PenTest – Parte 4: Enumerazione dei target

Facebooktwittergoogle_plusredditlinkedin

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

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

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

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

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

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

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

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

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

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

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

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

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

Per installare NMAP basta eseguire il comando:

# apt-get update

# apt-get install nmap

# nmap

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

Le porte possono essere:

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

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

Tipologie di Scansione: una per ogni occasione

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

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

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

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

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

Dunque mettetevi comodi…

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

# nmap -sU 8.8.8.8 -p 53

[UDP scan sulla porta 53, host 8.8.8.8]

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

Bypass delle protezioni

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

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

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

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

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

Enumerazione SMB

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

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

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

Per utilizzarlo, basta digitare:

# nbtscan 192.168.1.1-254

[Si noti come ho specificato un intervallo di IP]

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

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

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

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

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

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

Cerberus: il microcontroller crittografico Microsoft

Facebooktwittergoogle_plusredditlinkedin
Il microcontroller Cerberus

Il microcontroller Cerberus. Fonte: blog ufficiale Microsoft.

Cerberus è uno dei tanti progetti che Microsoft sta sviluppando in seno all’OPC (Open Compute Project), l’organizzazione nata nel 2o11 per proporre nei data center enterprise degli standard hardware open source ed aggirare il monopolio dei vendor storici – obiettivo non esplicitato nel manifesto programmatico ma indubbiamente raggiunto. Redmond si è unita alla schiera di supporter OPC nel 2014 affiancandosi ad altri illustri nomi come Google ed Apple.

Cerberus è legato ad Olympus, il server cloud custom che Microsoft utilizza già da qualche tempo su Azure con le macchine virtuali FV2 ed il cui design ha raggiunto in questi giorni la versione 2.0. Il microcontroller crittografico, definito dalla stessa compagnia come la prossima fase del progetto Olympus, si occupa di proteggere il firmware di scheda madre, periferiche I/O ed altri elementi sensibili fin dalla fase di pre-boot mediante controllo degli accessi e verifiche d’integrità:

Project Cerberus consists of a cryptographic microcontroller running secure code which intercepts accesses from the host to flash over the SPI bus (where firmware is stored), so it can continuously measure and attest these accesses to ensure firmware integrity and hence protect against unauthorized access and malicious updates. This enables robust pre-boot, boot-time and runtime integrity for all the firmware components in the system.

Quali minacce è in grado di controstare Cerberus

Cerberus root of trust

Cerberus root of trust. Fonte: blog ufficiale Microsoft.

Microsoft, si legge nel post dedicato al microcontroller, spende ogni anno circa 1 miliardo di dollari per garantire la sicurezza “fisica” e digitale delle proprie infrastrutture e parte dell’esperienza maturata su Azure è stata riversata nel progetto. Le potenziali minacce contrastabili da Cerberus sono le seguenti:

  • malintenzionati con privilegi amministrativi o accesso diretto all’hardware;
  • hacker e malware che intendono sfruttare vulnerabilità di applicazioni, sistemi operativi ed hypervisor;
  • attacchi indirizzati alla catena di distribuzione (produzione, assemblamento, in transito);
  • firmware compromessi.

Sposando in pieno i princìpi dell’OPC, Microsoft ha deciso di rendere compatibile Cerberus con qualsiasi processore (viene menzionata la collaborazione con Intel) e scheda madre – in modo da renderne più facile l’implementazione. Tra i settori ai quali si rivolge la compagnia anche quello l‘Internet delle Cose i cui device necessitano sicuramente di standard di sicurezza più elevati. Per quanto riguarda le specifiche del progetto, Microsoft intende rendere disponibili all’OPC in un secondo momento perchè ancora in fase di stesura.

Fonte: 1

 

 

 

 

 

Utilizzo e configurazione di Let’s Encrypt in ambiente Linux/Apache

Facebooktwittergoogle_plusredditlinkedin

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.

Il DNS relativo all’ host/dominio per cui si richiede il certificato dovrà avere un record di tipo “A” e non sarà validato in caso di “CNAME”.

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/

Windows Subsystem for Linux arriva su Windows Server, versione 1709

Facebooktwittergoogle_plusredditlinkedin

Non è la prima volta che ci troviamo a parlare di Linux su Windows, e questa volta iniziamo a fare davvero sul serio perché parliamo di Linux su Windows Server.

Proprio così! A partire dalla build 16215 di Windows Server è possibile installare come app alcune distribuzioni di Linux, che possono girare sulla nostra macchina fisica o virtuale grazie al componente Windows Subsystem for Linux che i lettori abituali del sito della nostra community conoscono già bene. Per tutti gli altri riporto l’articolo in cui annunciavamo il rilascio del componente e la guida per l’installazione https://www.ictpower.it/sistemi-operativi/windows-subsystem-for-linux-finalmente-in-una-release-ufficiale.htm

Sul nostro nuovo Windows Server, conosciuto fino a poco fa come Windows Server RS3 (RedStone 3), ma il cui nome ufficiale è Windows Server, versione 1709, l’interfaccia grafica è stata completamente rimossa e quindi l’installazione di WSL è ben diversa da quella che conosciamo per Windows 10. Aggiungere ed utilizzare questa funzionalità ad ogni modo è estremamente semplice; vediamo in pochi passi come fare:

Il primo step è sicuramente quello di installare una macchina, fisica o virtuale, con una release di Windows Server >16215. Potete scaricare Windows Server, versione 1709 dal portale Volume Licensing Service Center (VLSC) oppure potete utilizzare una macchina virtuale creata su Microsoft Azure, disponibile da pochissimi giorni nel Marketplace. Nel nostro caso, essendo iscritti al programma Microsoft Insider, abbiamo scaricato ed installato l’ultima build disponibile. Windows Server, versione 1709 è disponibile nelle versioni Standard e Datacenter, ma sono nella modalità di installazione Core, come visibile in figura:

Avviamo PowerShell con privilegi amministrativi ed eseguiamo il comando

systeminfo Select-String “^OS Name”

per verificare la build installata

La build installata è la 16299, quindi è possibile attivare la funzionalità di Windows Subsyste for Linux.

Per verificare che la funzionalità sia disponibile possiamo eseguire da PowerShell il comando

Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

Abilitiamo quindi la feature con il comando PowerShell

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

Dopo il riavvio abbiamo la funzionalità WSL attiva.

Possiamo a questo punto scaricare la nostra distribuzione preferita scegliendo tra i link seguenti:

Per questo esempio scaricheremo il pacchetto relativo alla distribuzione Ubuntu, salvandolo con il nome Ubuntu.zip nella nostra home directory con il commando

Invoke-WebRequest -Uri https://aka.ms/wsl-ubuntu-1604 -OutFile ~/Ubuntu.zip -UseBasicParsing

Il pacchetto occupa circa 200MB. Estraiamo l’archivio con

Expand-Archive ~/Ubuntu.zip ~/Ubuntu

Ritroveremo così nella nostra home la cartella Ubuntu contenente l’app da installare

L’installazione è estremamente semplice e viene avviata lanciando l’eseguibile relativo alla distribuzione. Nel nostro caso

Ubuntu.exe

Un wizard ci chiederà di impostare un nome utente ed una password per l’ambiente Linux. Le credenziali saranno completamente indipendenti da quelle di Windows e l’utente sarà membro del gruppo sudoers quindi potrà utilizzare il comando sudo per eseguire l’installazione di eventuali pacchetti aggiuntivi.

Al termine dell’installazione ci troveremo già all’interno della shell linux. Per tornare a PowerShell digitiamo

exit

in qualsiasi momento possiamo utilizzare la nostra distribuzione Ubuntu aprendo la shell Linux con:

bash

Siamo quindi in grado di eseguire comandi e software Linux direttamente sulla nostra macchina Windows Server 1709, e per concludere questa guida eseguiamo

cat /etc/lsb-release

Che ci mostrerà le informazioni sulla distribuzione in uso, confermando che siamo su una Ubuntu 16.04 Long Term Support

Conclusioni

La presenza di Windows Subsystem for Linux anche su Windows Server apre degli scenari di utilizzo molto interessanti, che finora avevamo visto solo nella versione client Windows 10.

Creare un Azure Container Service (ACS) con un Kubernetes cluster

Facebooktwittergoogle_plusredditlinkedin

Abbiamo già visto in diversi articoli apparsi su questo sito che l’utilizzo dei container ci permette di migliorare l’utilizzo delle macchine virtuali sia on-premises che nel Cloud. Tuttavia, per migliorare l’affidabilità e la scalabilità, è necessario far girare decine se non migliaia di container utilizzando diversi Host. Azure Container Service, servendosi di diversi tipi di container orchestrator open source come Docker Swarm, Kubernetes e Marathon di Mesosphere’s DC/OS, permette di semplificare tantissimo la gestione dei container cluster.

In questo articolo analizzeremo l’uso di Kubernetes e della sua implementazione in Azure.

Introduzione

Azure Container Service (ACS) permette di gestire cluster di diversi Docker Hosts, dandoci la possibilità di scalare le nostre applicazioni gestendo decine di migliaia di container grazie anche ad orchestrator come Kubernetes.

Google ha rilasciato Kubernetes nel Febbraio 2015 proprio con lo scopo di orchestrare i container Docker. A Marzo 2016 ha reso il codice open source, donandolo alla Cloud Native Computing Foundation (CNCF) e impegnandosi al suo continuo sviluppo. Fin dall’inizio il software ha riscosso parecchio successo tra gli sviluppatori grazie alle numerose funzionalità che supporta.

Creazione di un cluster Kubernetes utilizzando Azure Container Service

Per creare un cluster Kubernetes in Azure è possibile utilizzare il portale web, un template di Azure Resource Manager oppure Azure CLI 2.0. In alternativa è anche possibile utilizzare un progetto open source presente su Github chiamato acs-engine per definire il cluster e per poterlo creare utilizzando Azure CLI 2.0.

Il modo più veloce per creare un cluster container su Azure è l’utilizzo della Azure Cloud Shell, una shell interattiva accessibile dal browser che permette di gestire le risorse di Azure. Gli utenti Linux possono scegliere di utilizzare Bash, mentre gli utenti Windows possono scegliere di utilizzare PowerShell. È possibile lanciare la Azure Cloud Shell direttamente dal portale di Azure, come mostrato in figura:

Figura 1: Lancio della Azure Cloud Shell dal portale

Quando lanciate la Azure Cloud Shell dal portale di Microsoft Azure la prima volta vi verrà chiesto di creare un gruppo di risorse, un account di archiviazione e una condivisione file (Azure file share). Scegliete di utilizzare Bash (Linux).

Figura 2: Primo lancio della Azure Cloud Shell con la richiesta di creazione dello storage account

Dopo aver creato uno storage account con ridondanza locale (LRS), a cui vengono applicati i normali costi di esercizio, verrà creata una Azure file share, che utilizzeremo sia per gli ambienti Bash che PowerShell.

Figura 3: Avvio della Azure Cloud Shell con Bash

Nella Azure Cloud Shell sono preinstallati i più diffusi strumenti da riga di comando, compreso Azure CLI 2.0, che utilizzeremo per creare l’Azure Container Service. Per prima cosa creiamo un Resource Group con il comando

az group create --name ACS-LabRG --location westeurope

e successivamente creiamo un nuovo servizio di Azure Container Service con orchestrator Kubernetes lanciando il comando

az acs create --orchestrator-type kubernetes --resource-group ACS-LabRG --name ACS-k8scluster --generate-ssh-keys

Figura 4: Creazione del nuovo Azure Container Service

Figura 5: Oggetti creati per l’Azure Container Service

Dopo aver atteso la creazione del nuovo Azure Container Service (che durerà alcuni minuti) possiamo scaricare e configurare le credenziali per accedere all’ACS Kubernetes cluster lanciando il comando

az acs kubernetes get-credentials --resource-group ACS-LabRG --name ACS-k8scluster

Le credenziali verranno salvate nello storage account utilizzato da Azure Cloud Shell.

Figura 6: Download delle credenziali per accedere al cluster ACS

Per verificare la connettività all’ACS Kubernetes Cluster vi basterà eseguire il comando:

kubectl get nodes

e verificare che tutti gli agent nodes siano Ready, come mostrato in figura:

Figura 7: Verifica della creazione e dello stato dei nodi del cluster

Distribuzione di un’applicazione nel cluster ACS Kubernetes

Per testare il nostro cluster distribuiremo un container con nginx, prendendolo dal Docker Hub. Lanciamo il comando

kubectl run nginx-lab --image=nginx --replicas=1 --port=80

e verifichiamo che il pod Kubernetes sia stato creato utilizzando il comando

kubectl get pods

Per identificare lo stato del deployment utilizziamo invece il comando

kubectl get deployment

Figura 8: Verifica dello stato del deployment

Per rendere il pod disponibile dall’esterno dovremo però prima esporlo con il comando

kubectl expose deployment nginx-lab --port=80 --type=LoadBalancer

Dopo qualche minuto, il servizio verrà esposto e potremo connetterci. Per individuare l’indirizzo IP pubblico utilizzato possiamo lanciare il comando

kubectl get services

Se la colonna relativa all’EXTERNAL-IP vi indica Pending, aspettate qualche minuto (nel mio caso ci sono voluti circa 5 minuti) e ripetete il comando.

Figura 9: Indirizzo IP pubblico del cluster

Collegatevi all’indirizzo IP ottenuto ed il vostro container NGINX vi farà apparire la pagina di benvenuto.

Figura 10: Pagina di benvenuto del container

Gestione di un’applicazione nel cluster ACS Kubernetes

Dopo aver creato la prima istanza del nostro deployment, possiamo scalarla facilmente utilizzando il comando

kubectl scale --replicas=2 deployment/nginx-lab

ed esattamente come prima, per verificare la buona riuscita, lanciamo il comando

kubectl get pods

Figura 11: Creazione dello scaling completato

Come potete vedere adesso ci sono due istanze che fanno girare il container nginx.

Con la stessa rapidità con cui è stato scalato è anche possibile cancellare il deployment con il comando

kubectl delete deployment nginx-lab

e verificare con il comando

kubectl get deployment

Figura 12: Cancellazione del Deployment

Conclusioni

I Docker Container di fatto ottimizzano il deployment delle nostre applicazioni e le rendono trasportabili. È necessario però fare in modo che gli Host che ospitano i container siano affidabili e scalabili. Una soluzione di orchestation è quindi necessaria per il corretto funzionamento ma soprattutto per la facilità e rapidità di utilizzo. Kubernetes insieme a Azure Container Service è senza dubbio una soluzione semplice da implementare ed altamente scalabile.

Microsoft ha anche annunciato da un paio di giorni la preview di AKS (Azure Container Service). Per maggiori info visualizzate l’articolo Introducing AKS (managed Kubernetes) and Azure Container Registry improvements

Eseguire i Linux Containers in Windows Server 1709

Facebooktwittergoogle_plusredditlinkedin

Con il rilascio dell’ultima versione del sistema operativo server, chiamata Windows Server 1709 e delle cui novità ne ho parlato nella’articolo https://www.ictpower.it/sistemi-operativi/windows-server-2016-1709-quali-saranno-le-novita.htm, Microsoft e Docker ci offrono la possibilità di far girare i container Linux in un Windows Container Host.

Tra i prerequisiti richiesti per far girare i container Linux ci sono l’installazione di Docker Enterprise Edition e di LinuxKit.

In questa guida vi mostrerò come far girare i Linux Containers all’interno di una macchina virtuale. Per poterlo fare sarà necessario abilitare la Nested virtualization nella VM, in quanto i container Linux possono essere solo Hyper-V Containers. Per avere maggiori informazioni sulla Nested Virtualization vi rimando all’articolo https://www.ictpower.it/guide/abilitare-la-nested-virtualization-con-le-nuove-azure-vm-dv3-ed-ev3.htm

Dopo aver creato la macchina virtuale, che ho chiamato 1709 – Linux Containers, sarà necessario configurarla con la memoria RAM statica ed abilitare la nested virtualization con il comando PowerShell (eseguito con privilegi elevati)

Set-VMProcessor -VMName “1709 – Linux Containers” -ExposeVirtualizationExtensions $true

Configurate la scheda di rete della VM in modo tale che sia abilitato il Mac Address spoofing con il comando PowerShell

Get-VMNetworkAdapter -VMName “1709 – Linux Containers” Set-VMNetworkAdapter -MacAddressSpoofing On

Procedete quindi all’installazione di Windows Server 1709 e terminata l’installazione, utilizzando il tool sconfig, affettuate tutti gli aggiornamenti, come mostrato in figura:

Figura 1: Installazione di Windows Server versione 1709 completata

Figura 2: Installazione degli aggiornamenti

Al termine degli aggiornamenti la versione di Windows sarà la 10.0.16299.19

Installazione di Docker Enterprise Edition

Per installare Docker Enterprise Edition è necessario lanciare un prompt PowerShell con privilegi elevati ed eseguire i comandi:

Install-Module DockerProvider -Force

Install-Package Docker -ProviderName DockerProvider -Force

Figura 3: Installazione di Docker Enterprise for Windows completata

Terminata l’installazione procedete ad un riavvio della macchina virtuale.

Dopo il riavvio potete verificare che il servizio Docker stia girando usando il comando PowerShell Get-Service docker e potete verificare la versione utilizzando il comando Docker version, come mostrato in figura:

Figura 4: Verifica della versione di Docker e dello stato del servizio

Adesso che i prerequisiti sono stati installati possiamo procedere all’installazione di Docker for Linux e del LinuxKit.

Installazione di Docker for Linux e del LinuxKit

Utilizzando un prompt PowerShell eseguito con privilegi elevati installiamo LinuxKit con i seguenti comandi:

$progressPreference ‘silentlyContinue’

mkdir $Env:ProgramFiles\Linux Containers”

Invoke-WebRequest -UseBasicParsing -OutFile linuxkit.zip https://github.com/friism/linuxkit/releases/download/preview-1/linuxkit.zip

Expand-Archive linuxkit.zip -DestinationPath $Env:ProgramFiles\Linux Containers\.”

rm linuxkit.zip

Figura 5: Installazione del LinuxKit

A questo punto scaricate la build di Docker deamon che contiene una versione di Preview che supporta i Linux Container in Windows utilizzando la cmdlet di PowerShell

Invoke-WebRequest -UseBasicParsing -OutFile dockerd.exe https://master.dockerproject.org/windows/x86_64/dockerd.exe

Successivamente avviate un demone Docker che sia in ascolto su una pipe separata utilizzando il comando PowerShell

$Env:LCOW_SUPPORTED=1

$env:LCOW_API_PLATFORM_IF_OMITTED=“linux”

.\dockerd.exe -D –experimental -H “npipe:////./pipe//docker_lcow” –data-root c:\lcow

Figura 6: Avvio del demone Docker per l’esecuzione dei container Linux

Lasciate la finestra che ha avviato il demone in esecuzione (NON CHIUDETELA) e provate ad eseguire un Linux Container aprendo un’altra finestra con il Command Prompt e eseguendo il comando:

docker -H “npipe:////./pipe//docker_lcow” run -ti busybox sh

Figura 7: esecuzione del comando per il lancio del Linux Container

Se l’immagine non è presente nel vostro host Windows verrà scaricata, estratta ed eseguita. È possibile scaricare l’immagine anche utilizzando il comando docker -H “npipe:////./pipe//docker_lcow” pull busybox

Conclusioni

Attualmente l’esecuzione di Linux Container in un Windows Server host richiede un po’ di lavoro per la configurazione e non è supportata in produzione. Sicuramente è un ulteriore passo in avanti per poter permettere agli sviluppatori di poter creare e testare applicazioni Windows/Linux facendo girare container per entrambe le piattaforme side-by-side sullo stesso sistema operativo.