DockerHub: trovati i primi container contaminati

Facebooktwittergoogle_plusredditlinkedin

Docker è sulla cresta dell’onda da tanto tempo, troppo tempo perchè passasse inosservato.

E, prima o poi, doveva succedere: sono state rilevate le prime immagini di container contaminate, da software di crypto-mining, direttamente sul Docker Hub, il registry ufficiale e pubblico di Docker.

Il registry è un componente fondamentale in un’infrastruttura a container; è il componente da cui Docker (o sistemi che utilizzano Docker come base, ad esempio Kubernetes) scarica delle immagini di container che poi esegue sull’host; una volta fatta la build dell’immagine più o meno specializzata è possibile caricarla su un registry, che può essere privato o pubblico (come nel caso di Docker Hub) così che uno o più altri host possano utilizzare quell’immagine senza doverla rigenerare ex-novo.

Due società che si occupano di sicurezza, Fortinet e Kromtech, in questi giorni hanno pubblicato due articoli in cui rivelano che ben 17 immagini di container Docker avevano al loro interno dei miner di cryptovalute che, all’insaputa degli utenti, utilizzano le risorse delle macchine su cui questi container venivano lanciati per generare una BotNet sufficientemente ampia da trovare qualche cryptovaluta.

Queste immagini, considerate sicure, sono state scaricate ben 5 milioni di volte prima che venissero identificate e rimosse, e sfruttavano installazioni di Docker e Kubernetes configurate male per scaricare ed eseguire uno script di mining, oltre al servizio fornito ufficialmente. Il tutto, cosa ancora più preoccupante, in maniera del tutto automatica.

Of course, we can safely assume that these had not been deployed manually. In fact, the attack seems to be fully automated. Attackers have most probably developed a script to find misconfigured Docker and Kubernetes installations. Docker works as a client/server architecture, meaning the service can be fully managed remotely via the REST API

Ovviamente possiamo assumere con sicurezza che queste non siano state rilasciate manualmente. Di fatto, l’attacco sembra essere totalmente automatizzato. Gli attaccanti hanno probabilmente sviluppato uno script per trovare installazioni Docker e Kubernetes configurate male. Docker funziona in un’architettura client/server, quindi il servizio può essere completamente gestito da remoto tramite API REST

I due articoli mostrano anche gli aspetti tecnici su cui si basano questi attacchi, e spiegano che gli attaccanti sono riusciti a ricavare circa $90,000 in cryptovalute (544.74 Monero per l’esattezza) prima di essere scoperti e che le immagini venissero definitivamente rimosse dall’hub e dai sistemi.

As with public repositories like GitHub, Docker Hub is there for the service of the community. When dealing with open public repositories and open source code, we recommend that you follow a few best practices including: know the content author, scan images before running and use curated official images in Docker Hub and certified content in Docker Store whenever possible

Come per i repository pubblici come GitHub, Docker Hub è li a servizio della comunità. Quando si ha a che fare con repository pubblici aperti e codice open source, raccomandiamo di seguire alcune regole come: conoscere l’autore del contenuto, scansionare le immagini prima di usarle ed utilizzare immagini ufficiali presenti in Docker Hub e contenuti certificati nel Docker Store dove possibile.

Regole di puro buon senso, quindi, noi aggiungiamo che forse partire da immagini base ufficiali, costruirsi le proprie immagini specializzate ed utilizzare un registry privato (lo stesso Docker fornisce una semplice procedura per farlo) è la soluzione più sicura.

Vembu BDR Suite 3.9.1 Update 1 con supporto per vSphere 6.7

Facebooktwittergoogle_plusredditlinkedin

Vembu BDR Suite 3.9.1 Update 1 con supporto per vSphere 6.7

vembu-bdr-suite-3-9-1-support-vsphere-6-7-01

Vembu ha rilasciato la nuova versione della soluzione di backup Vembu BDR Suite 3.9.1 Update 1 introducendo il pieno supporto per l’ultima release di VMware vSphere 6.7.

Con il software di backup Vembu, è possibile proteggere le proprie virtual machine in esecuzione negli ambienti VMware vSphere e Microsoft Hyper-V e server/workstation fisici WindowsLinux.

vembu-bdr-suite-3-9-1-support-vsphere-6-7-02

 

Supporto vSphere 6.7

L’Update 1 aggiunge la funzionalità di poter eseguire backup e repliche delle virtual machine in esecuzione in ambiente VMware vSphere 6.7 ma non introduce nuove funzioni sostanziali.

Informazioni aggiuntive possono essere consultate nelle Relase Notes.

vembu-bdr-suite-3-9-1-support-vsphere-6-7-03

 

Edizioni Vembu BDR Suite disponibili

La soluzione di backup Vembu è disponibile in tre versioni ed è adatta per ambienti SMB ed Enterprise.

 

Standard Edition

La BDR Suite è constantemente in sviluppo per migliorare funzionalità e prestazioni, e recentemente Vembu ha esteso la propria offerta commerciale anche per le SMB introducendo la Standard Edition, una soluzione di backup vantaggiosa che soddisfa tutti i requisiti richiesti dal proprio business per garantire la massima protezione delle virtual machine e dei dati.

vembu-bdr-suite-3-9-1-support-vsphere-6-7-04

Le funzionalità principali disponibili nella versione Standard possono essere riassunte come segue:

  • Backup VMware agentless
  • Replica delle VM
  • Tecnologia CBT
  • Supporto per i VMware Virtual Volumes e Virtual SAN
  • Hot-Add e SAN transport mode
  • Immagini di backup application-aware
  • Ripristino granulare per Microsoft Exchange, SQL, Active Directory e SharePoint

 

Enterprise Edition

La Vembu BDR Suite Enterprise Edition è orientata per realtà medie ed Enterprise fornendo funzioni base ed estese, come il supporto per il Tape Backup, replica delle VM, persistent boot, retention avanzata GFS, etc.

vembu-bdr-suite-3-9-1-support-vsphere-6-7-05

 

Free Edition

Vembu fornisce inoltre una Free Edition perpetua della BDR Suite con due opzioni disponibili che possono essere utilizzate:

  • funzionalità illimitate per tre virtual machine
  • virtual machine illimitate con funzionalità limitate

La versione free supporta entrambe le piattaforme virtuali VMware ed Hyper-V.

vembu-bdr-suite-3-9-1-support-vsphere-6-7-06

Vembu BDR Suite 3.9.1 Update 1 è disponibile per il download come 30-day trial.

signature

Copyright Nolabnoparty. All Rights Reserved.

Altro giro, altro bug (per Intel)!

Facebooktwittergoogle_plusredditlinkedin

L’epopea di Intel e dei bug hardware dei suoi processori non cenna a diminuire. Dopo l’annuncio di altre varianti di Spectre e Meltdown, con relative patch in arrivo, Cyberus Technology annuncia la scoperta di un nuovo buco, relativo al lazy FPU state switching (cambiamento di stato della FPU pigro).

Di cosa si tratta? Abbiamo già accennato ai meccanismi di Meltdown e Spectre, per cui alcune tecniche di miglioramento delle prestazioni (branch prediction) permettono l’accesso non autorizzato a dati memorizzati nella CPU; anche questa volta siamo di fronte ad un caso simile.

Le nostre CPU eseguono un solo programma alla volta, ma possono sospendere l’esecuzione di un programma ed eseguirne un altro: fatto spesso (e con sufficiente velocità), questo crea l’illusione del multitasking, ovvero l’esecuzione contemporanea di più programmi. La CPU usa tutta una serie di registri per sapere a che punto del programma sia arrivata e su che dati stesse lavorando: il cambio avviene salvando la situazione di questi registri e caricando la situazione del programma lasciato in sospeso da riprendere.
Anche in questo caso lo switch di programma può essere piuttosto oneroso, quindi una tecnica per migliorare le prestazioni è evitare l’effettivo cambiamento fino a quando non sarà necessario, lasciando quindi accessibili dei dati che non appartengono al programma in esecuzione in quel momento.

Questa particolare falla non riguarda tutta la CPU, ma la FPU (Floating-Point Unit), ovvero quel chip che si occupa esclusivamente dei calcoli che riguardano numeri con la virgola (le operazioni fatte con numeri interi sono più semplici e gestite direttamente dalla CPU). Ai tempi di 286 e 386 si parlava di coprocessore, ma l’utilità (e il costo irrisorio aggiuntivo) hanno ormai fatto integrare questo componente in tutti i processori moderni. Il dettaglio sembra piccolo, e che limiti i danni, peccato che moltissimi calcoli siano demandati all’FPU, compreso criptazioni e codifiche/decodifiche: danni limitati proprio alla parte più sensibile.

Al momento l’attacco sembra specifico delle CPU Intel, ma non è ancora dato sapere esattamente quali modelli né quanto sia difficile attuarlo. Tutto perduto, quindi?
No, perché da qualche anno i processori dispongono di una nuova istruzione (XSAVEOPT) per memorizzare lo stato dei registri che non si comporta pigramente, e i kernel moderni usano questa funzionalità di default: vale per RHEL/CentOS 7, Ubuntu 16.04, in genere dal kernel 4.9. Perfino Windows 10 è già coperto.
Per chi invece usasse un kernel più antico, dal kernel 3.7 è disponibile l’opzione al boot “eagerfpu=on”, che disattiva l’ottimizzazione problematica.

Per questo giro, forse, possiamo stare tranquilli.

Creazione di un laboratorio con Azure Lab Services (preview)

Facebooktwittergoogle_plusredditlinkedin

Abbiamo visto nel precedente articolo Creare DevTest Labs in Microsoft Azure come il servizio DebTest Labs consenta agli sviluppatori o ai tester di creare un ambiente in Azure che permetta di tenere sotto controllo i costi e allo stesso tempo permetta di effettuare tutti i test applicativi utilizzando sia macchine Windows che macchine Linux. L’evoluzione di questo servizio, che attualmente è in Preview, si chiama Azure Lab Services ed è un servizio che permette di creare un ambiente per lo sviluppo oppure un laboratorio da utilizzare per uso scolastico.

Il proprietario di un Lab crea un laboratorio, esegue il provisioning delle macchine virtuali Windows o Linux, installa il software e gli strumenti necessari e li rende disponibili per gli utenti del lab. Gli utenti del lab si connettono alle macchine virtuali del lab e le possono utilizzare per poter effettuare attività giornaliere oppure per svolgere i compiti scolastici. In ogni caso sarà possibile tenere sempre sotto controllo i costi del laboratorio e questo permette di ottimzizare l’utilizzo delle risorse a disposizione.

Diversi sono i vantaggi offerti dagli Azure Lab Services ed in particolare vi evidenzio:

  • Configurazione veloce e flessibile di un lab. Tramite Azure Lab Services, i proprietari di lab possono configurare velocemente un lab per le loro esigenze ed il servizio offre scalabilità e resilienza dell’infrastruttura.
  • Esperienza semplificata per gli utenti dei lab. Gli utenti del lab possono eseguire la registrazione a un lab con un codice di registrazione e accedervi in qualsiasi momento per usare le risorse del lab.
  • Analisi e ottimizzazione dei costi. Il proprietario del lab può impostare pianificazioni del lab per arrestare e avviare automaticamente le macchine virtuali. Può anche specificare le fasce orarie in cui le macchine virtuali del lab saranno accessibili agli utenti, impostare i criteri di utilizzo per ciascun utente o lab per ottimizzare i costi, nonché analizzare le tendenze di utilizzo e attività in un lab.
  • Sicurezza incorporata. Gli utenti del lab possono accedere in modo sicuro alle risorse tramite la rete virtuale configurata con ExpressRoute o con VPN da sito a sito. (attualmente non disponibile nella Preview)

In questo articolo creerò un laboratorio da utilizzare in una classe, per permettere agli studenti di lavorare con le macchine virtuali ed eseguire i compiti scolastici.

Creazione del laboratorio

Per poter creare il laboratiorio vi basta loggarvi al portale di Azure e creare una nuova risorsa di tipo Lab Services, come mostrato in figura:

Figura 1: Creazione di un nuovo Lab Service

Dopo aver atteso la creazione di un nuovo Lab Account, dalla scheda Overview, cliccate sul collegamento per poter aggiungere un nuovo Lab Creator. Il Lab Creator è un ruolo che permetterà al docente di poter creare una classe per i propri studenti oppure permetterà di creare un ambiente di test o di demo.

Figura 2: Aggiunta del Lab Creator

Figura 3: Configurazioni del ruolo di Lab Creator e dei permessi per la creazione del lab

Una volta che avrete deciso a chi concedere i privilegi di Lab Creator potrete far collegare il lab creator al sito web di Azure Lab Services. Dopo essersi autenticato gli verrà chiesto di confermare le autorizzazioni di accesso richiesta dall’ap Azure Lab Services, come mostrato in figura:

Figura 4: Conferma dell’accesso e autorizzazioni per Azure Lab Services

Il Lab Creator a questo punto è pronto per creare un nuovo laboratorio, cliccando sul pulsante New Lab. Oltre a fornire il nome del laboratorio, gli verrà chiesto la dimensione delle VM da utilizzare, la versione del sistema operativo (Windows o Linux) e le credenziali di accesso alla VM, come mostrato in figura. È possibile modificare la dimensione delle VM da utilizzare nel lab seguendo le istruzioni dell’articolo Use PowerShell to set allowed VM sizes in Azure Lab Services ed aggiungere altre immagini delle VM oltre a quelle proposte di default, seguendo le istruzioni dell’articolo Use PowerShell to add a marketplace image to a lab in Azure DevTest Labs

Figura 5: Creazione di un nuovo laboratorio

Figura 6: Immagini delle macchine virtuali disponibili di default

Dopo qualche istante sarà possibile, dalla Dashboard del Lab, accedere alle configurazioni. Attendete che venga completata la creazione della VM e, dopo averla avviata, configurate il template della macchina virtuale con tutte le caratteristiche che volete fornire agli utenti del lab. Collegatevi alla macchina in desktop remoto ed effettuate le personalizzazioni che desiderate (installazione di software, configurazioni).

Figura 7: Creazione del laboratorio completata

Terminate le configurazioni del template potete modificarne i dettagli, per fornire ai vostri studenti/utenti maggiori informazioni sulla VM.

Figura 8: Modifica dei dettagli del template

A questo punto potete pubblicare il template facendo clic sul pulsante Publish. Una volta che il template è stato pubblicato non sarà più possibile modificarlo.

Figura 9: Pubblicazione del template della VM

Configurazione dei criteri di utilizzo del laboratorio

È possibile definire dei criteri di utilizzo del laboratorio, come ad esempio il numero massimo di utenti che potranno utilizzarlo. Per poter definire la policy vi basterà cliccare su Usage Policy e definire il numero massimo di utenti consentito, come mostrato in figura:

Figura 10: Definizione della Usage Policy del Lab

Dopo aver stabilito il numero massimo di macchine virtuali da creare nel vostro Lab (nella Preview potete creare un massimo di 5 VM), potrete registrare i vostri utenti e dargli la possibilità di accedere al laboratorio.

Figura 11: Creazione delle VM nel Lab

Prossimamente sarà possibile anche limitare l’utilizzo del laboratorio a determinati periodi della giornata. Al momento la funzionalità non è ancora disponibile.

Figura 12: Abilitazione della programmazione della disponibilità del Lab

Utilizzo del Lab

Per permettere l’utilizzo del lab ai propri studenti ed ai propri collaboratori sarà necessario prima aggiungere gli utenti utilizzando il pulsante User registration e successivamente inviare il link che verrà generato a chi dovrà utilizzare il lab.

Figura 13: Generazione del link per poter permettere agli studenti di poter accedere al laboratorio

Dal portale amministrativo sarà possibile verificare le assegnazioni e lo stato della macchina virtuale, come mostrato in figura:

Figura 14: verifica delle assegnazioni delle VM disponibili nel Lab

Collegamento al Lab

A questo punto chi riceverà il link dovrà collegarsi al sito web di Azure Lab Services e dopo aver inserito le credenziali dell’organizzazione (quindi di Azure AD) ed aver accettato le autorizzazioni da dare agli Azure Lab Services, potrà cominciare ad utilizzare la macchina virtuale del laboratorio che gli è stata assegnata. Nella schermata principale vedrà le VM a cui gli è stato consentito l’accesso e, dopo averle avviate, potrà collegarsi in desktop remoto utilizzando le credenziali fornite dal Lab Creator.

Figura 15: Dopo l’accesso al portale degli Azure Lab Services l’utente vedrà le VM che gli sono state assegnate

Figura 16: Accesso alla VM del Lab dopo l’accensione

Dal portale di amministrazione il Lab Creator può tenere sotto controllo la situazione, può avviare/stoppare la macchina virtuale, può connettersi in desktop remoto per dare assistenza all’utilizzatore della VM

Figura 17: Gestione delle VM del Lab dal portale amministrativo

Conclusioni

Azure Lab Services può essere usato per implementare molti scenari. Uno dei più importanti prevede la possibilità di ospitare computer di sviluppo per gli sviluppatori oppure è un’interessante soluzione per implementare laboratori scolastici nel Cloud. Un docente può creare un laboratorio, installare macchina virtuali Windows o Linux, installare il software necessario per le esercitazioni e rendere disponibili le VM ai propri studenti. Vedremo nella versione finale cosa sarà disponibile, intanto proviamo la preview 🙂

Buon lavoro!

Nic

Pubblicare applicazioni aziendali con Azure Active Directory Application Proxy

Facebooktwittergoogle_plusredditlinkedin

La necessità di rendere utilizzabili al di fuori del perimetro aziendale le applicazioni interne è un’esigenza ormai quotidiana, ma la disponibilità esterna di queste risorse costringe necessariamente chi amministra l’infrastruttura ad “aprire le porte” verso Internet, con tutte le implicazioni dal punto di vista della sicurezza che questo comporta.

Sono state e sono tutt’ora utilizzate una serie di tecniche di mitigazione, ad esempio l’impiego di proxy a reverse con l’utilizzo di sistemi di re-writing degli URL, che consentono una separazione netta delle connessioni in ingresso e forniscono una certa sicurezza sulle risorse esposte.

Questa architettura permette la collocazione in DMZ di sole macchine con il compito di gestire le richieste in ingresso e ridirigerle poi, con alcune regole di controllo all’interno. In questo modo le infrastrutture sensibili non hanno contatto diretto con l’esterno.

Contestualmente a questi accorgimenti l’adozione di sistemi IDS/IPS “garantiscono” un accettabile livello di sicurezza.

In ogni caso questo approccio ha richiesto e richiede che il firewall perimetrale consenta la connessione ed “apra” almeno una porta verso l’interno, richiede anche che i vari apparati posti a controllo del perimetro siano costantemente aggiornati e verificati

Azure Active Directory Application Proxy

In Microsoft Azure è disponibile un servizio che si lega in modo stretto con Azure Active Directory e che in maniera concettualmente del tutto nuova permette in modo semplice la fruizione delle applicazioni ad utenti esterni all’azienda.

Questo servizio è Azure Active Directory Application Proxy, disponibile con la versione BASIC o PEMIUM di Azure Active Directory.

Per poter utilizzare la funzione di Application Proxy, dal portale di Azure è sufficiente, selezionata la Directory di riferimento, attivare la funzionalità in prova valida per 30 giorni e successivamente terminata la fase di test, effettuarne l’acquisto.

Figura 1: Abilitazione servizi AAD Premium

Figura 2: Attivazione di Azure AD Premium P2 Trial

Attivata la funzionalità di Azure AD Premium è necessario installare il componente Application Proxy Connector. La scelta più corretta è quella di dedicare un sistema server a questa funzione, scelta che permette una migliore scalabilità delle risorse e di gestione.

Figura 3 Download componente Connector

Per configurare correttamente regole di uscita dell’Application Proxy è utile la lettura del documento Attività iniziali del proxy di applicazione e installazione del connettore

Mentre per un controllo diretto ed una verifica puntuale della configurazione è disponibile il tool Azure Active Directory Application Proxy Connector Ports Test Tool

È anche possibile permettere che il Connector interno utilizzi per collegarsi ad Azure un Web Proxy , questo qualora non fosse possibile agire direttamente sul Firewall per definire regole puntuali di uscita.

In questo caso è bene considerare che un possibile malfunzionamento del Web Proxy stesso si ripercuoterebbe necessariamente sulla raggiungibilità delle applicazioni.

L’aspetto interessante, relativo alla sicurezza del sistema, è che NON è richiesto che in ingresso venga definita alcuna regola sul Firewall.

L’applicazione che è utilizzata esternamente sarà disponibile tramite il portale Azure e sarà la componente Application Proxy che si occuperà di renderla accessibile e di “dialogare” con il Connector interno, che è la sola componente ad avere contatti con l’applicazione in rete locale.

Per analogia con il sistema tradizionale a Reverse Proxy il Connector è un Reverse Proxy, con la sola ma importante differenza che questo, come detto sopra, non ha contatti con l’esterno ma riceve e reindirizza le richieste dalla componente cloud.

Figura 4: Principio di funzionamento di Azure Active Directory Application Proxy

A questo punto è evidente che l’infrastruttura di sicurezza Aziendale può essere “alleggerita” in quanto come già detto non è richiesto che siano attivate porte in ascolto, questo compito è demandato ad Azure.

Pubblicazione di una applicazione interna tramite Azure AD Application Proxy

Dal portale di Azure selezionare la directory in cui si è abilitata la funzione e successivamente selezionare Configura un’app

Figura 5: Aggiunta dell’applicazione on-premises da esporre

Nella maschera successiva scegliere “Add your own on-premises application”

Verrà così proposta una ulteriore videata con le specifiche proprie dell’applicazione che si intende pubblicare

  • Nome serve ad identificare l’applicazione all’interno del portale di accesso e di configurazione
  • URL interno è l’effettivo URL che il connettore installato on premise contatterà (di norma l’Url dell’applicazione interna)
  • URL Esterno è il riferimento
    pubblico per la raggiungibilità dell’applicazione interna, nel caso si usi un dominio Custom, questo è selezionabile dalla casella
  • Metodo di Autenticazione Preliminare è effettivamente la modalità con cui gli utenti accederanno all’autenticazione dell’applicazione.

Con la modalità Azure AD l’utente verrà effettivamente autenticato con i servizi di Azure e quindi beneficiando anche di quelle che sono le prerogative di questi utenti: gestione Self-Service della password, possibilità di definire criteri di sblocco personalizzati, accesso da dispositivi con determinate caratteristiche etc.

Con la modalità Passtrough invece, all’utente viene proposto direttamente (se previsto) il login dell’applicazione interna.

Nel caso in cui sia impostata la modalità Azure AD e l’applicazione (tipicamente legacy) non sia in grado di utilizzare di questa modalità, verrà richiesta una seconda autenticazione.

A questo punto è possibile accedere all’applicazione, è da notare che di default tutto il traffico è in HTTPS e viene utilizzato un certificato generato per il nome host definito.

Tuttavia, siccome si possono anche gestire URL esposti in Azure con FQDN del proprio dominio pubblico è possibile effettuare l’upload di un certificato aziendale.

Controllo delle funzionalità del Connector Gateway

Questo oggetto non ha particolari opzioni di configurazione, all’atto dell’installazione, viene richiesto un account amministratore globale della directory e con questo il gateway si registra ed autentica sulla directory stessa.

È possibile all’interno del registro eventi rilevare eventuali errori o anomalie archiviate in AadApplicationProxy (fig.6)

Sono anche disponibili, al fine di valutare le performance di questo servizio alcuni Performance Counters (fig.7)

Figura 6: Contatori disponibili per la verifica delle performance del servizio

Figura 7: Aggiunta dei contatori

Considerazioni relative agli aspetti di sicurezza

Controllo tramite NMAP delle informazioni deducibili tramite un port SCAN

Al di là delle considerazioni espresse in precedenza, un piccolo e sicuramente approssimativo test relativo agli aspetti legati alla sicurezza è stato condotto utilizzando NMAP.

Tramite questo tool si è cercato di identificare il sistema operativo sul quale l’applicazione è installata.

Sono stati effettuati due TEST distinti, il primo verso una applicazione esposta in modo tradizionale FWàRev-ProxyàApplicazione

Figura 8: Scansione verso l’esposizione con Reverse Proxy tradizionale

Nmap seppure con una certa approssimazione ha rilevato un host Linux fig. sopra

Ed il secondo sempre verso la stessa applicazione ma esposta tramite AZURE con la struttura descritta sopra

Figura 9 Scansione verso l’esposizione con Azure Application Proxy

Nmap non è riuscito ad identificare il sistema verso il quale ha fatto la scansione.

Conclusioni

Partendo dall’assunto che non esiste LA soluzione perfetta, sicura e garantita e vista anche la velocità di implementazione e il discreto grado di sicurezza by-default dell’infrastruttura, la soluzione di Azure Application Proxy può essere un valido aiuto alle realtà che necessitano di rendere fruibili le proprie applicazioni all’esterno del perimetro aziendale.

Riferimenti:

Azure Application Proxy Connector

Azure Application Proxy Connector – connessione tramite proxy interno

Risoluzione dei problemi relativi alla pubblicazione di applicazioni tramite Azure

Sicurezza

Presto sarà possibile avere un laptop Linux con processore ARM, parola di Torvalds!

Facebooktwittergoogle_plusredditlinkedin

In seguito all’aggiunta del supporto per il processore Qualcomm Snapdragon 845, un processore ARM di tipo SoC (System on a Chip), Linus Torvalds, creatore di Linux, si è detto fiducioso di poter vedere presto girare Linux su laptop che montano questa tecnologia, senza quindi dover passare da sistemi Chrome, sebbene ormai anche su questi sia possibile far girare applicazioni Linux.

Come spiega Phoronix sebbene il supporto per Qualcomm Snapdragon 845 SoC sia presente nel Kernel 4.18 in forma limitata, è facile credere che con l’avanzare delle prossime release questo diventi maturo e, come indica Torvalds, pronto per un utilizzo “quotidiano” in sistemi Linux.

Il principio alla base dei ragionamenti del creatore di Linux risiede nella possibilità di poter disabilitare secure boot nel processore, in modo da poter avviare un sistema operativo non previsto, in questo caso Linux.

Vedremo se l’introduzione di questa funzionalità favorirà l’ascesa dei laptop con processori ARM, al momento limitata, forse dal fatto che Microsoft Windows non li supporta ancora. Quanto alle performance è tutto da capire: lo Snapdragon 845 è decisamente di un’altra categoria rispetto agli ARM classici, ma sarà sufficiente questo per garantire performance adeguate?

Per il momento Linux lo supporta, tutto il resto si vedrà!

Configurare il disaster recovery delle Azure VM in una regione secondaria di Azure

Facebooktwittergoogle_plusredditlinkedin

Azure Site Recovery è un servizio che permettere di poter replicare in Microsoft Azure le nostre macchine fisiche on-premises e le nostre macchine virtuali Hyper-V oppure VMware, per poterle avviare nel momento in cui si verifica un disastro. Ho già avuto modo di affrontare in diversi articoli come proteggere macchine virtuali VMware e come proteggere e migrare server fisici con Azure Site Recovery. Per chi volesse sapere cosa offre e come funziona Azure Site Recovery consiglio la lettura del documento Informazioni su Site Recovery.

In questo articolo vi voglio parlare di come effettuare il Disaster Recovery (DR) di una macchina virtuale ospitata in Microsoft Azure.

Il servizio, disponibile solo da pochi giorni, permette di replicare una macchina virtuale da una Region di Azure verso un’altra Region, in modo tale che se il sito primario non sia disponibile (per un disastro, per problemi di connettività, ecc..) la macchina virtuale possa essere accesa nel sito secondario e sia già pronta per poter eseguire le applicazioni.

Creazione del Recovery Service Vault

Prima di procedere all’abilitazione della replica della nostra Azure VM è necessario creare un Backup and Site Recovery Vault. Collegatevi al portale di Azure e dopo esservi autenticati create un nuovo Recovery Services Vault, come mostrato in figura. Quando create il Recovery Services Vault considerate sempre due fattori:

  • Il Recovery Services Vault non si deve trovare nella Region di Azure dove si trovano le Azure VM da proteggere
  • Il Resource Group in cui inserite il Recovery Services Vault non deve essere nella Region delle VM da proteggere

Le due condizioni sono necessarie perché, in caso di disastro nella Region dove sono ospitate le VM, non sarebbero disponibili né Resource Group né Recovery Services Vault!


Figura 1: Creazione del Recovery Services Vault in una Region diversa da quella dove sono ospitate le Azure VM da proteggere

Protezione delle Azure VM

Terminata la creazione del Recovery Services Vault siamo pronti per proteggere le nostre Azure VM. Dal portale di Azure vi basterà selezionare la VM da proteggere e cliccare sul collegamento Disaster Recovery. Nel blade che si aprirà configurate la Region di destinazione della replica della vostra VM ed il Resource Group, la VNET, lo Storage Account e tutti gli altri parametri richiesti, come mostrato in figura:

Figura 2: Configurazione della Replica della VM e Replication settings

Attenzione: Per poter abilitare la replica della VM è necessario che nella macchina virtuale sia installato l’Azure VM agent. Nel caso non lo fosse o nel caso non rispondesse alle richieste del portale riceverete un messaggio come quello mostrato in figura:

Figura 3: Messaggio di errore nel caso l’Azure VM agent non sia installato o non funzioni

L’abilitazione della replica dura diversi minuti. Potete controllare lo stato della replica dalle notifiche, come mostrato in figura:

Figura 4: Notifiche sulla creazione degli oggetti necessari alla replica della VM

Selezionando la VM e cliccando su Disaster Recovery sarà possibile visualizzare il Site Recovery Job iniziale di abilitazione della replica, come mostrato in figura:

Figura 5: Informazioni sullo stato di replica della Azure VM

Figura 6: Job di abilitazione della replica

Dal blade del Disaster Recovery sarà sempre possibile tenere sotto controllo lo stato di replica della VM e sarà possibile modificare i parametri. Cliccate sul tasto Settings e modificate i parametri della VM replicata. Potete ad esempio decidere in quale Resource Group accenderla e a quale VNET collegarla, oltre ovviamente alla dimensione che deve avere.

Figura 7: Configurazioni della VM replicata

Test del Failover

È sempre buona norma testare periodicamente il failover e verificare che tutto funzioni nella VM che avete replicato. Per effettuare il test vi basta cliccare su Test Failover e seguire le istruzioni. Vi verrà chiesto il Recovery Point che volete testare e la Azure VNET a cui collegare la VM.

Figura 8: Failover Test della VM

Dopo qualche minuto, nel Resource Group dove avete deciso di avviare la macchina per testare il Failover, apparirà la VM e vi ci potrete collegare per poter verificare che tutto funzioni perfettamente.

Figura 9: Macchina virtuale di test per il Failover

Dopo le opportune verifiche potete cliccare su Cleanup test failover e cancellare la macchina virtuale di test, come mostrato in figura:

Figura 10: Cleanup test failover

Failover della Azure VM

Per poter eseguire il Failover della Azure VM è sufficiente cliccare sul pulsante Failover e dal blade scegliere quale Recovery Point applicare e se spegnere la macchina prima di iniziare il failover. Lo spegnimento della macchina ha senso ovviamente in un Failover programmato e non in caso di vero disastro 🙂

Figura 11: Failover della Azure VM nella seconda Region di Azure

Terminato il Fialover potete decidere anche di cambiare recovery point utilizzando il pulsante Change recovery point oppure confermare la scelta fatta utilizzando il pulsante Commit. Dopo aver effettuato il Commit però non sarà più possibile modificare il Recovery Point.

Figura 12: Commit della macchina virtuale e completamento del Failover

Terminato il disastro è possibile riproteggere la Azure VM utilizzando il pulsante Re-protect. La macchina verrà replicata nuovamente verso la Region di partenza, ma se volete potete cliccare sul pulsante Customize e modificare i parametri, scegliendo il Resource Group, la VNET, lo Storage Account e l’Availability Set della macchina di destinazione.

Figura 13: Re-protect della Azure VM

Conclusioni

Il Disaster Recovery è decisamente importante vista la nostra dipendenza dai sistemi IT. Nonostante tutti gli sforzi profusi, può capitare sempre che accada qualcosa di imprevisto che interrompa la possibilità di usufruire dei servizi. Nonostante il Cloud sia stato concepito per essere affidabile, è buona norma essere sempre preparati al peggio. La replica delle VM di Azure è sicuramente una funzionalità interessante per essere certi di poter gestire un disastro importante e per assicurare alle aziende che hanno anche degli obblighi contrattuali o delle esigenze molto stringenti in ambito di Disaster Recovery di poter usufruire delle VM ospitate in Azure ed essere compliant con le loro specifiche.

Per approfondimenti potete visitare la pagina Set up disaster recovery for Azure VMs to a secondary Azure region

Office 365 errore ADFS “AADSTS50008: Unable to verify token signature.”

Facebooktwittergoogle_plusredditlinkedin

Office 365 errore ADFS "AADSTS50008: Unable to verify token signature."

office365-error-adfs-aadsts50008-01

Cercando di accedere alla casella di posta Office 365 tramite browser, il sistema riporta l’errore ADFS “AADSTS50008: Unable to verify token signature.”

Dopo avere digitato le credenziali nel portale Office 365, il seguente errore viene visualizzato:

AADSTS50008: Unable to verify token signature. The signing key identifier does not match any valid registered keys.

office365-error-adfs-aadsts50008-02

Una volta confermato e verificato che entrambi i servizi ADFS e WAP sono operativi senza problemi, lo stato dei Certificati nella console AD FS è riportato come mostrato nella figura. Il certificato Token-decrypting è aggiornato ad una data recente.

office365-error-adfs-aadsts50008-03

Per risolvere il problema, ho trovato un ottimo articolo presso il blog Robin CM’s IT Blog con i corretti comandi PowerShell da eseguire. Aprire la console di PowerShell e digitare il seguente comando per effettuare la connessione ad Azure Active Directory:

PS C:\ Connect-MsolService -Credential (Get-Credential)

Inserire le credenziali dell’admin Office 365 e cliccare OK.

office365-error-adfs-aadsts50008-04

Ora digitare il seguente comando per specificare il server nel quale è in esecuzione AD FS:

PS C:\ Set-MsolADFSContext -Computer w12r2-adfs01.nolabnoparty.local

office365-error-adfs-aadsts50008-05

Poichè è cambiato il certificato in AD FS, è necessario eseguire il seguente comando per aggiornare il nuovo certificato del token decryption in Azure Active Directory:

PS C:\ Update-MsolFederatedDomain -DomainName nolabnoparty.com

office365-error-adfs-aadsts50008-06

Dopo avere eseguito i comandi PowerShell, la casella mailbox di Office 365 è nuovamente accessibile.

office365-error-adfs-aadsts50008-07

Potrebbero essere necessari alcuni minuti di attesa dopo aver inserito i comandi prima di poter accedere alla mailbox.

signature

Copyright Nolabnoparty. All Rights Reserved.

Blog italiani (e in italiano) nel mondo IT/ICT