Archivi categoria: Windows

Classifica delle soluzioni di sicurezza endpoint secondo Gartner nel triennio 2016-2018

Facebooktwittergoogle_plusredditlinkedin

Introduzione

La corretta gestione di una moderna infrastruttura IT dipende principalmente dalle scelte dei prodotti software e una delle scelte più importanti è sicuramente la scelta della soluzione di sicurezza degli endpoint (workstations, smartphones e tablets) ovvero software antivirus, antimalware di ultima generazione.

In questo articolo vi proponiamo un approccio basato sulla comparazione dei report di Gartner dell’ultimo triennio per analizzare l’evoluzione del posizionamento dei Vendor di soluzioni Endpoint Protection Platforms (EPP) nel quadrante magico (QM) di Garner.

Lo scopo è quello di fornire una rapida panoramica di come, secondo Gartner, i Vendor si sono posizionati e di quale sia il loro l’attuale Trend senza fermarsi alla sola analisi dell’ultimo report annuale.

Le soluzioni di EPP hanno subito negli ultimi anni un’evoluzione tale da richiedere una rivisitazione da parte di Gartner della definizione di EPP e dei parametri di valutazione (a riguardo si veda il report Redefining Endpoint Protection for 2017 and 2018 – Published: 29 September 2017 – ID: G00337106) e quindi la valutazione di come un Vendor si è posizionato nel corso degli ultimi anni e del suo Trend può essere un’informazione in sede di scelta di una soluzione di Endpoint Security.

Struttura dell’analisi

Gartner è una importante azienda nel mondo IT che si occupa di Analisi e ricerche di mercato/prodotto e advisoring e il cui obiettivo è quello di supportare le decisioni strategiche con consulenze e report che hanno lo scopo di fornire un punto di vista “super partes” sullo stato generale di un mercato, di una azienda o dei suoi prodotti.

Uno dei report prodotti da Gartner più famosi è il quadrante magico (QM) che è di semplice comprensione perché permette rapidamente di avere una panoramica, secondo Gartner, sul posizionamento che hanno gli attori del mercato. L’analisi del QM va però sempre approfondita con la lettura del documento a cui è affiancato in cui viene motivato in dettaglio le ragioni del posizionamento e che quindi vanno poi contestualizzate negli specifici scenari in cui si sta eseguendo la valutazione perché alcune motivazioni potrebbero essere poco influenti per le scelte necessarie. L’elenco dei Magic Quadrant è disponibile al seguente Gartner Magic Quadrant.

L’analisi dei Vendor di prodotti classificati da Gartner come Endpoint Protection Platforms basata sui seguenti report:

Gartner definisce la categoria Endpoint Protection Platforms come segue:

“The endpoint protection platform provides security capabilities to protect workstations, smartphones and tablets. Security and risk management leaders of endpoint protection should investigate malware detection effectiveness, performance impact on the host machines and administrative overhead.”

Nell’analisi saranno presi in considerazione i Vendor che sono stati inseriti nel report nell’anno in corso (2018) e per semplicità di verranno ordinati in base ad uno Score calcolato sulla base del QM a cui verrà attribuito il seguente valore:

  • 4 = Leaders
  • 3 = Challengers
  • 2 = Visionaries
  • 1 = Niche Players
  • 0 = Non Classificato

Lo Score attributo a ciascun Vendor, sulla base del quale sono stati ordinati dal valore maggiore a minore, è stato ottenuto con la seguente formula per pesare maggiormente il valore del QM degli ultimi anni:

  • Se QM 2018 > 0 allora lo Score vale (100* QM 2018) + (10 * QM 2017) + QM 2016
  • Se QM 2018 = 0 allora lo Score vale 0

L’obbiettivo è quello di ottenere una classifica del Vendor di soluzioni EPP ordinata in base al miglior posizionamento nei quadrante Gartner nel triennio e in base al miglior Trend di posizionamento nel corso degli anni.

Di seguito i tre MQ di gartner sulla base dei quali è stata eseguita l’analisi:

Risultato

Di seguito i Vendor ordinati in base allo Score calcolato, in base alla considerazioni precedenti dal valore maggiore al minore:

Vendor

QM 2016

QM 2017

QM 2018

Score

Trend

Sophos

4

4

4

444

«

Symantec

4

4

4

444

«

Trend Micro

4

4

4

444

«

ESET

2

1

3

312

­

Kaspersky Lab

4

4

2

244

¯

Microsoft

3

3

2

233

¯

Cylance

2

2

2

222

«

SentinelOne

2

2

2

222

«

Carbon Black

0

2

2

220

«

CrowdStrike

0

2

2

220

«

F-Secure

2

1

2

212

­

Panda Security

2

1

2

212

­

Malwarebytes

0

1

2

210

­

Cisco

0

0

2

200

Endgame

0

0

2

200

McAfee

0

0

2

200

Palo Alto Networks

0

2

1

120

¯

Bitdefender

2

1

1

112

«

Comodo

0

1

1

110

«

FireEye

0

0

1

100

Fortinet

0

0

1

100

In base alla classifica ottenuta i leader della categoria Endpoint Protection Platforms del triennio 2016-2018 sono Sophos, Symantec e Trend Micro mentre ESET sta aumentato la sua competitività.

Di seguito gli aspetti positivi dei primi 3 Vendor della classifica ottenuta evidenziati nel report Gartner del 2018:

Pro di Sophos

  • Intercept X clients report strong confidence in not only protecting against most ransomware, but also the ability to roll back the changes made by a ransomware process that escapes protection.
  • Intercept X is available as a stand-alone agent for organizations that are unable to fully migrate from their incumbent EPP vendor.
  • The exploit prevention capabilities focus on the tools, techniques and procedures that are common in many modern attacks, such as credential theft through Mimikatz.
  • The Sophos Central cloud-based administration console can also manage other aspects of the vendor’s security platform, from a single console, including disk encryption, server protection, firewall, email and web gateways.
  • Root Cause Analysis provides a simple workflow for case management and investigation for suspicious or malicious events.
  • Root Cause Analysis capabilities are available to macOS, along with protection against cryptographic malware.

Pro di Symantec

  • Symantec seems to have finally found a stable footing with its management team bringing stability across the company.
  • SEP 14 and, most recently, SEP 14.1 have proven to be very stable and efficient on resources. Clients report that the addition of ML and other advanced anti-malware capabilities have improved threat and malicious software detection, and containment.
  • Symantec ATP, its EDR-focused solution, provides good capabilities for detection and response, and existing SEP customers will benefit from its use of the existing SEP agent.
  • Symantec has started to embrace a cloud-first strategy with the introduction of its latest product updates, including SEP Cloud and EDR Cloud, which provide a cloud-based console with feature parity to the on-premises management console.
  • Symantec’s broad deployment across a very large deployment population of both consumer and business endpoints provides it with a very wide view into the threat landscape across many verticals.

Pro di Trend Micro

  • Trend Micro participates in a wide range of third-party tests, with good results overall, and the OfficeScan client delivers functionality that other traditional vendors provide in their separate EDR add-on, such as IOA-driven behavioral detection.
  • The virtual patching capabilities can reduce pressure on IT operational teams, allowing them to adhere to a strategic patch management strategy without compromising on security.
  • For customers looking for a single strategic vendor, Trend Micro has strong integration across the endpoint, gateway and network solutions to enable real-time policy updates and posture adjustments.
  • Trend Micro offers managed detection and response services, in its Advanced Threat Assessment Service, to augment the technology with expert analysis and best practices.

Di seguito invece gli aspetti negativi dei Vendor che hanno avuto un trend in discesa rispetto al 2017, inteso come cambio di quadrante, evidenziati nel report Gartner del 2018.

Contro di Kaspersky Lab secondo Gartner

  • Gartner clients report that the management console, Kaspersky Security Center, can appear complex and overwhelming, especially when compared to the fluid, user-centric design of newer EPP and EDR vendor management consoles.
  • The mainstream EDR capabilities were introduced into the Kaspersky Anti Targeted Attack Platform in late 2017, one of the last vendors to begin adding these features.
  • The EDR investigation lacks step-by-step, guided investigations for less experienced organizations, but Kaspersky Lab can provide training on using its products for advanced topics like digital forensics, malware analysis and incident response.
  • The Kaspersky Endpoint Security Cloud — a cloud-based management solution — is currently available only for SMB customers. Larger organizations looking for cloud-based management must deploy and maintain the management server in AWS or Azure.

Conro di Microsoft secondo Gartner

  • The biggest challenge continues to be the scattered security controls, management servers, reporting engines and dashboards. Microsoft is beginning to center its future management and reporting around the Windows Defender Security Center platform, which is the management interface for the whole Windows Defender suite, including ATP. Microsoft Intune is replacing System Center as the primary management tool.
  • To access advanced security capabilities, organizations need to sign up for the E5 tier subscription, which clients report as being more expensive than competitive EPP and EDR offerings, reducing the solution set’s overall appeal.
  • Microsoft relies on third-party vendors to provide malware prevention, EDR and other functionality on non-Windows platforms, which may lead to disparate visibility and remediation capabilities and additional operational complexities.
  • The advanced security capabilities are only available when organizations migrate to Windows 10. It does much less to address all other Windows platforms currently in operation.

Contro di Palo Alto Networks secondo Gartner

  • There is currently no cloud-based management option; customers must use an on-premises management server.
  • While Traps collects endpoint forensics data, it does not provide any response capabilities or postevent remediation tools. Organizations that do not use a Palo Alto Networks NGFW will need to take a multivendor approach to gain these capabilities.
  • Traps lacks EDR capabilities beyond simple IOC searching, making investigation hard without an additional product.
  • Palo Alto Networks acquired LightCyber in early 2017, but has not yet used the technology to improve the limited detection and response capabilities in Traps.
  • Traps displayed a high rate of false positives in AV-TEST testing between August and October 2017.

Conclusioni

Ovviamente come già scritto precedente prima di trarre conclusioni è necessaria la lettura del documento a cui è affiancato il QM Gartner, inoltre le considerazioni relative ai vendor ovviamente prendono in esame la situazione che vi era alla data di pubblicazione del report, quindi, ad esempio, nel caso del QM Gartner del 2018 ovviamente alcune affermazioni relative a funzionalità del prodotto o alle scelte tecno – commerciali del Vendor che hanno portato al posizionamento potrebbero non essere corrette se valutate dopo il 24 gennaio 2018.

L’analisi dell’evoluzione del posizionamento nel quadrante sulla base della formula che abbiamo proposto può ovviamente non essere condivisibile, ma sicuramente la valutazione del Vendor sulla base di più report può aiutare a determinare la scelta di un prodotto della categoria Endpoint Protection Platforms che dovrà essere utilizzato per alcuni anni sebbene debba essere impiegato per gestire una delle problematiche IT più dinamiche come la protezione di workstations, smartphones e tablets da rischi di sicurezza. In ogni caso la classifica può essere rivista inserendo nel calcolo dello Score dei parametri che vadano a pesare la presenza e l’implementazione di determinate funzionalità indispensabili nell’infrastruttura IT oggetto della valutazione.

L’analisi che abbiamo proposto può quindi essere utilizzata come metro di valutazione per la scelta di una soluzione EPP, ma anche come parametro di confronto per valutare una soluzione presentata durante un incontro commerciale o ancora come strumento per giustificare le propria scelta nei confronti della Direzione aziendale.

Microsoft rende ancora più semplice portare distribuzioni Linux nel WSL di Windows 10

Facebooktwittergoogle_plusredditlinkedin

Microsoft ha annunciato di aver sviluppato un tool che faciliterà il funzionamento di Linux all’interno del Windows Subsystem for Linux, dedicato ai maintainer ed agli sviluppatori di distribuzioni Linux custom. Questo WSL-DistroLauncher è già liberamente scaricabile dal canale Github di Microsoft e, come è facile concludere, è totalmente OpenSource.

Tara Raj, del team WSL di Microsoft, commenta così l’introduzione di questo progetto:

We know that many Linux distros rely entirely on open-source software, so we would like to bring WSL closer to the OSS community

Sappiamo che molte distribuzioni Linux si basano interamente su software OpenSource, quindi vogliamo portare WSL più vicino alla community OSS

A dispetto di quanto qualcuno afferma (vedi questo articolo dal titolo “The End of Windows” che prospetta come il sistema operativo Microsoft Windows, così come lo conosciamo, sia finito) ecco come il WSL-DistroLauncher rappresenta un altro passo verso l’interoperabilità totale, un altro netto distacco dal passato. Sì, è il 2018, sì, Microsoft ha un canale Github e sì, Microsoft produce software OpenSource.

Nel frattempo, se qualcuno si stesse domandando come sono le performance dei WSL rispetto alle distribuzioni classiche, ecco che Phoronix propone un test comparativo dal titolo “Windows 10 vs. Windows WSL vs. Linux – Ubuntu / openSUSE / Debian / Clear Linux” dal quale emerge chiaramente come le distribuzioni operanti in ambiente WSL all’interno del confronto siano perdenti. Inevitabile, visto che si sta parlando comunque di sottosistemi (quindi per quello che riguarda l’I/O e le performance disco sofferenti del “doppio passaggio”), ma i dati non sono così allarmanti. Soprattutto considerando che l’ambito pensato per i WSL è prevalentemente quello dello sviluppo e non della produzione.

Microsoft Windows Server 2019 supporterà al meglio Linux e Kubernetes

Facebooktwittergoogle_plusredditlinkedin

In un recente post sul blog di Windows Server, Microsoft ha annunciato Windows Server 2019 e per gli utenti Linux sono solo buone notizie.

Gli ambiti principali in cui vengono descritti i miglioramenti sono i seguenti:

  • Hybrid cloud scenarios: integrazione completa dei diversi progetti all’interno del contesto Azure;
  • Security: le shielded virtual machines, speciali VM il cui accesso è consentito solamente attraverso le così dette guarded fabric (interfacce sicure specifiche), introdotte con Windows Server 2016 supportano ora Linux.
  • Application Platform: moltissimi i miglioramenti al Windows Subsystem di Linux (WSL, di cui abbiamo parlato spesso) con un’attenzione particolare al porting degli script Linux in Windows, applicando standard basati su OpenSSH, Curl e Tar. Un’altra grossissima novità è rappresentata dal supporto beta a Kubernetes, con moltissime componenti aggiornate per interagire con i cluster Kubernetes.
  • Hyper-converged infrastructure (HCI): aggiornamenti introdotti in ottica scale, performance e affidabilità per fornire il supporto a quello che sta diventando uno standard di mercato, ossia l’utilizzo del pieno potenziale (quindi multi funzione) delle macchine utilizzate.

La disponibilità di Windows Server 2019 sarà a partire dalla seconda metà del 2018 e sarà una versione LTS, con lo stesso supporto esteso che hanno RHEL e Ubuntu.

StackOverflow: Linux è più popolare di Windows per gli sviluppatori

Facebooktwittergoogle_plusredditlinkedin

Ogni anno Stack Overflow, il famoso sito di domande e risposte tanto caro agli sviluppatori di ogni angolo del globo, organizza un questionario per capire l’andamento delle preferenze dei suoi utenti in fatto di linguaggi preferiti e di OS, per lo sviluppo e per l’erogazione di tutte quelle applicazioni che, in un modo o nell’altro, hanno contribuito a sviluppare.

Ed è stato pubblicato in questi giorni il risultato del sondaggio di quest’anno che, grazie ai più di 100.000 sviluppatori partecipanti al questionario di 30 minuti (contenente domande che andavano dall’etica nello sviluppo fino alle intelligenze artificiali), si può dire rappresenti un bello spaccato della categoria.

Troviamo delle conferme di risultati degli anni precedenti, da JavaScript come linguaggio di programmazione più usato (sono 6 anni che “vince”) e Node.js come framework, alla prevalenza di database MySQL e SQL Server sopra tutti gli altri; spicca quest’anno però un’altra statistica: Linux ha sorpassato Windows come piattaforma scelta dagli sviluppatori per il loro lavoro, passando dal 32,9% degli intervistati che utilizzavano l’OS OpenSource nel 2016 al 48,3% degli stessi nel 2017.

Linux and Windows Desktop or Server are the most common choices that our respondents say they have done development work for this year. Linux is once again the most loved platform for development, with serverless infrastructure also loved this year.

Linux e Windows Desktop o Server sono le scelte più comuni tra gli intervistati su cui hanno fatto lavoro di sviluppo questo anno. Linux ancora una volta è la piattaforma più amata per lo sviluppo, con l’infrastruttura serverless molto apprezzata quest’anno.

Sicuramente è un ottimo passo per l’OS di Torvalds, e il sorpasso – per la prima volta – nell’uso di Visual Studio Code su Visual Studio come IDE di sviluppo più popolare potrebbe essere complice di questo risultato; Visual Studio Code, infatti, a differenza della sua controparte “old school”, è portabile e gira, tutto sommato, molto bene sui sistemi Linux, facilitando la migrazione di uno sviluppatore da un sistema Microsoft al pinguino, che si ritroverebbe con lo stesso IDE e, magari, un ambiente sottostante più simile a quello in cui la sua applicazione sarà poi erogata. Magari su Azure e magari sempre sotto Linux!

Voi usate tutti Linux per sviluppare, vero?

Windows Server 2019 preview build

Facebooktwittergoogle_plusredditlinkedin

Fino ad ora, Windows 10 e Windows Server 2016 erano andati avanti più o meno a pari passo, con delle build simili. Ma se per Windows 10 sembra chiaro che si avrù un continuo sviluppo, per Windows Server, la scelta dei mettere l’anno nel nome, tente a rendere il prodotto “vecchio” dopo un po’ di […]

Problemi di riavvio di Windows Server 2016

Facebooktwittergoogle_plusredditlinkedin

Con gli ultimi aggiornamenti può succedere che lo spegnimento di Windows Server 2016 si blocchi nello stato “Getting Windows ready – Don’t turn off your computer”. In realtà spesso non è bloccato ma dopo varie decine di minuti (a volte anche 20-30) il sistema di slocca. Il problema sembra legato alla KB4088787 o comunque ad […]

Utilizzo di Azure DNS per la validazione automatica di Let’s Encrypt

Facebooktwittergoogle_plusredditlinkedin

In ICTPower ci siamo occupati a più riprese della Certification Authority Let’s Encrypt, ed abbiamo visto come è possibile utilizzarla in diversi scenari.

In Ambienti OpenSource, con la validazione basata su Apache, In un altro articolo abbiamo proposto lo scenario che si può utilizzare con IIS come base per la validazione.

In questo articolo vediamo quali sono le modalità di validazione per il rilascio ed il rinnovo dei certificati sulla base di ambienti DNS, in questo modo è possibile utilizzare un servizio DNS, anche in hosting, per la gestione del ciclo di vita dei certificati gestiti da Let’s Encrypt. Le procedure proposte si basano sul client Win-Acme (WACS) e quindi in ambiente Windows.

Let’s Encrypt utilizza, analogamente a quanto visto per la validazione tramite servizi WEB, un’automazione che provvede a gestire determinati record all’interno del DNS.

Figura 1 Validazione tramite servizio DNS generico

Nella figura 1 è riportato un esempio di come Win-Acme, tramite le opzioni avanzate, permette di utilizzare il DNS per la validazione.

Nell’esempio sopra Win-Acme ricerca uno script a cui passare “hostname, record name e token“, e se opportunamente eseguito interagisce con il servizio DNS in modo da “scrivere” all’interno queste informazioni che lette dalla CA prima del rilascio del certificato, attestano che il richiedente è il reale proprietario del dominio.

E’ quindi chiaro che la disponibilità da parte del fornitore del servizio DNS ad una gestione automatizzata è fondamentale.

Nel panorama Italiano, Aruba non permette questo tipo di automazione (almeno da richiesta fatta al supporto tecnico nel mese di febbraio 2018), ma come vedremo in seguito questo non è necessariamente un limite.

Esistono diversi gestori di servizi DNS che rilasciano nelle gallery relative alle automazioni, script nati per far interagire i client CertBot con il loro DNS in modo da automatizzare le richieste verso Let’s Encrypt.

La maggioranza delle automazioni finora sono relative ad ambienti Linux.

Nel nostro caso utilizziamo invece Azure-DNS per la validazione da parte della CA, non ci occuperemo di come effettuare la delega al servizio Azure della risoluzione per il dominio, questa attività è trattata in dettaglio in questo articolo e si presuppone sia già stata effettuata.

Prima di procedere con la richiesta del certificato vero e proprio è necessario configurare il servizio Azure-DNS in modo che permetta l’accesso ad un “utente” con le credenziali minime per poter creare e cancellare record all’interno del Database DNS.

Questa tipologia di accesso è possibile con la creazione di un Service Principal Account
che possiamo definire come una identità di livello applicativo.

     Assign permissions to the app identity that are different than your own permissions. Typically, these permissions are restricted to exactly what the app needs to do.

Per poter creare una identità di questo tipo possiamo utilizzare Azure Powershell e con l’utilizzo di alcune command let procedere alla sua creazione, l’accesso all’ambiente PS avviene direttamente dal portale Azure

Figura 2 accesso alla Cloud Shell

La preparazione dell’ambiente non è immediata e può richiedere anche più di un minuto, terminato l’accesso, disponiamo di un ambiente comandi direttamente sulla sottoscrizione.

Per procedere alla creazione del Principal account che verrà utilizzato per l’automazione è sufficiente utilizzare questi comandi

$Password = ConvertTo-SecureString -String “InserireQuiLaPassword” -AsPlainText -Force

New-AzureRmADServicePrincipal -DisplayName LetsEncrypt -Password $Password

Figura 3 creazione del service principal

In questo modo è stato creato l’account “Letsencrypt” con la relativa password ed è necessario assegnare i permessi di accesso alla zona DNS relativa al dominio per il quale stiamo richiedendo il certificato

Figura 4 attribuzione dei permessi

Accedendo alla gestione della zona robimassa.cloud tramite Access Control (IAM) si attribuisce il ruolo di DNS Zone Contributor al Service Principal Letsencrypt creato in precedenza.

La preparazione dell’ambiente relativo al servizio DNS è completata e prima di procedere alla generazione del certificato è utile recuperare alcune informazioni che saranno poi richieste dal client Win-Acme.

  • Tenant ID (directory ID) ossia l’identificativo della Directory a cui ci stiamo riferendo
  • Client ID l’identificativo del Service Principal creato prima
  • Secret la password definita per il Principal
  • DNS Subscription ID l’identificativo del Servizio DNS in questo caso (robimassa.cloud)
  • DNS Resource Group Name il resource group definito per la risorsa DNS pubblica

In questa guida si fa riferimento al dominio robimassa.cloud, forse è superfluo specificarlo, ma il dominio DEVE essere un dominio pubblico regolarmente raggiungibile e quindi acquistato tramite i normali canali commerciali, nello specifico questo dominio è stato acquistato da Aruba.

Generazione del certificato

Il client Win-Acme dovrà essere eseguito con l’opzione –centralsslstore in modo da permettere l’archiviazione dei certificati (SAN o singolo Host) all’interno di una cartella, questo è necessario nel nostro caso in quanto i certificati rilasciati non vengono associati in automatico ad un Host Web, ma sono archiviati per un utilizzo successivo.

letsencrypt.exe –centralsslstore C:\letsencrypt-san\

vengono richieste a questo punto le impostazioni di base che sono quelle viste in figura 1 ad eccezione della validazione, per la quale dovremo selezionare l’opzione 1 ossia [dns-01] Azure DNS

Figura 5 richiesta validazione su Azure DNS

Proseguendo dovremo fornire le indicazioni relative all’accesso automatico del client come riportato sopra, ed al termine completata l’esecuzione, verranno salvati i certificati nella directory.

Figura 6 richiesta certificato

A questo punto il certificato è correttamente salvato in formato pfx e disponibile ad essere utilizzato, può ancora essere definito un utente con cui verrà eseguita periodicamente la task di rinnovo.

Se fosse necessario verificare i certificati emessi è possibile, sempre client Win-Acme la procedure di verifica.

Figura 7 verifica dei certificati emessi

Riferimenti

Generazione di certificati SAN con Let’s Encrypt ed utilizzo in Microsoft Exchange

Facebooktwittergoogle_plusredditlinkedin

Come abbiamo già avuto modo di analizzare in articoli precedenti, Let’s Encrypt, in quanto CA, permette anche il rilascio di certificati di tipo SAN (Subjet Alternative Names), ossia certificati che sono emessi e quindi sono validi per più nomi host di uno stesso dominio oppure per nomi host differenti di domini differenti.

La possibilità di ottenere certificati come indicato, non è da confondere con l’emissione di certificati di tipo Wildcard (*) ossia di un certificato valido per tutti gli host di un singolo dominio

Sono esempi di certificati di tipo SAN rilasciati da Let’s Encrypt i seguenti

  • mail.robimassa.cloud
  • autodiscover.robimassa.cloud

esempi di certificati per uno stesso dominio ma per host differenti

  • web.robimassa.it
  • portale.robimassa.cloud

esempi di certificati per host in domini differenti.

Per quanto riguarda i certificati Wildcard, Let’s Encrypt ha annunciato che nel gennaio del 2018 avrebbe emesso questo tipo di certificati, ma recentemente stato pubblicato un annuncio che informa dello slittamento del rilascio di questa funzione.

Exchange può utilizzare certificati di questo tipo emessi da Let’s Encrypt

Nel caso di questo sevizio, per l’accesso alle risorse mail dobbiamo dichiarare in DNS un record di tipo “A” riferito al portale webmail, ed un record, sempre di tipo “A” con nome autodiscover

Per una descrizione più dettagliata sull’uso e sulla funzione di questa informazione dichiarata in DNS è possibile leggere l’articolo Autodiscover service

In modo molto semplicistico possiamo dire che l’informazione ottenuta con “autodiscover” sia essa in un record di tipo A o in un record di tipo SRV permette una identificazione automatica di risorse di servizi di collaborazione come Exchange a partire da un indirizzo mail in formato utente@dominio.com.

Fatta questa premessa, passiamo ad analizzare in quale modalità è possibile ottenere certificati di tipo SAN con Let’s Encrypt

In ambiente Windows è utilizzabile il tool Let’s Encrypt-win-simple di Lone Coder, che proprio recentemente ha cambiato il nome del proprio programma

New name

This is the first release of this program under a new name. Going forward we will call it “Windows ACME Simple”, which can be shortened to “win-acme” or “WACS”. The reason is that we want to avoid any confusion people might have about this programs relationship with the ISRG sponsored Let’s Encrypt project.

To be clear, we are not an ISRG supported client, just an independent group of people who want to help people managing Microsoft Windows machines to secure the web.

Let’s Encrypt literally wrote the book on the ACME protocol and is obviously the most popular service implementing it, but in fact everyone is free to run their own ACME server and we might see a lot more of them in the future. Therefore it also makes sense to drop “Let’s Encrypt” from the name of this program.

Per effettuare la richiesta del certificato alla CA è necessario scaricare il tool da github e copiarlo localmente per poi estrarre il contenuto.

Il client ACME (Automatic Certificate Management Environment) quale è appunto win-acme, è gestibile a riga di comando, pertanto dovremo prima creare una cartella in cui saranno salvati i certificati in formato .pfx rilasciati dalla CA e successivamente eseguire il comando letsencrypt.exe –centralsslstore C:\letsencrypt-san\

L’opzione –centralsslstore è utilizzata per
definire il percorso per il salvataggio dei certificati che dovranno poi essere importati in Exchange tramite Powershell

Figura 1 richiesta certificato

Dovremo selezionare la modalità per il rilascio di nuovi certificati con opzioni avanzate “M” e successivamente specificare i vari nomi fqdn per cui stiamo richiedendo i certificati, ognuno separato da virgola nell’esempio che è indicato la richiesta è per l’host mail.robimassa.cloud ed autodiscover.robimassa.cloud

Figura 2 Impostazioni per la validazione

Successivamente verrà chiesta la modalità di validazione, ed il modo più rapido, se si esegue la richiesta dei certificati da un server IIS, è di consentire la verifica automatica direttamente tramite il server Web.

Procedendo con la richiesta vera e propria, e conclusa la procedura, nella cartella C:\letsencrypt-san\ troviamo i due certificati in formato PFX, uno per sito.

Sarà sufficiente procedere all’importazione del certificato in IIS che verrà utilizzato per OWA

Figura 3importazione certificato in IIS

Oppure in caso di sistemi distribuiti su più Web Server Bilanciati, utilizzare la funzione di centralized ssl certificate support a questo punto il https è attivo con il certificato SAN segnato per i due host

Importazione del certificato in Exchange

Per quanto riguarda invece l’importazione dei certificati in Exchange sarà necessario eseguire il cmd-let Powershell Import-ExchangeCertificate come descritto in questo articolo.

Metodi di validazione alternativi

Esistono altri metodi di validazione da parte di Lets’Encrypt per determinare che il richiedente del certificato sia effettivamente il proprietario del dominio, uno di questi è il metodo basato su DNS.

Il client Acme in questo caso si deve “appoggiare” ad un programma esterno che ricevendo in input I parametri corretti si occupa di creare sul DNS il TXT record opportunamente configurato. Questo record, sarà poi letto dalla CA prima dell’emissione dei certificati.

Siccome il processo di rinnovo è automatizzato e quindi eseguito periodicamente alla scadenza dei certificati, il servizio DNS deve poter consentire un interoperabilità di questo tipo.

E’ consigliabile quindi la verifica della disponibiltà di automazione da parte del DNS.

Figura 4 validazione tramite DNS

Figura 5 certificato SAN

Considerazioni

Anche in questo caso Let’s Encrypt si dimostra una Certification Authority che in modo gratuito permette di attivare i protocolli di sicurezza sui propri servizi. Come già detto in precedenza, è di prossimo rilascio l’emissione di certificati WildCard, che completerà l’offerta dei servizi della CA.

Riferimenti

https://letsencrypt.org/

https://www.ictpower.it/guide/utilizzo-e-configurazione-di-lets-encrypt-in-ambiente-linuxapache.htm