Implementare reti wireless sicure con 802.1x ed EAP-TLS con Windows Server 2016

Facebooktwittergoogle_plusredditlinkedin

Per permettere l’accesso alle nostre reti wireless molto spesso utilizziamo delle chiavi di cifratura WPA2, che rimangono le stesse per diverso tempo, e che spesso vengono anche consegnate ad utenti ospiti delle nostre reti. Chiunque disponga della chiave può quindi accedere alla WLAN e non sempre nelle nostre infrastrutture ci preoccupiamo di cambiarla periodicamente, considerando anche che dovremmo farlo su tutti gli access point e su tutti i client.

Per garantire un metodo più affidabile di autenticazione e autorizzazione, da anni è possibile implementare una struttura di protezione WLAN basata sul protocollo 802.1x, uno standard IEEE per l’autenticazione dell’accesso alla rete che può anche essere utilizzato per la gestione delle chiavi di protezione WPA2. Il suo utilizzo non è limitato alle reti senza fili, ma può essere implementato in numerosi switch di fascia alta nelle reti LAN cablate. Per approfondimenti sul funzionamento del protocollo 802.1x vi rimando alla pagina https://it.wikipedia.org/wiki/IEEE_802.1x

In questo articolo vedremo come implementare l’uso del protocollo 802.1x per le nostre reti wireless (ma analogo ragionamento può essere fatto per le reti cablate) utilizzando un server di autenticazione RADIUS creato con Windows Server 2016 ed EAP-TLS. EAP-TLS offre un processo di autenticazione molto sicuro, che sostituisce le semplici password con certificati digitali lato client e lato server, tramite l’utilizzo di una Certification Authority (PKI), creando di fatto quella che viene chiamata Mutual Authentication.

EAP-TLS con Mutual Authentication è attualmente l’implementazione più sicura per l’accesso alle reti wireless o alle reti cablate. I client autenticano il server RADIUS ed il server RADIUS chiede ai client di autenticarsi, richiedendo loro un certificato digitale.

Pertanto questo tipo di autenticazione, basato su certificati digitali sia computer che utente, permette l’accesso solo a chi possiede il certificato corretto e, nel caso la connessione avvenga tramite rete wireless, subito dopo l’autenticazione viene rilasciata una chiave WPA2 unica per utente (o per computer) ed unica per ogni sessione di connessione!

Per creare una infrastruttura di accesso che supporti questo protocollo affronteremo diversi passaggi:

  1. Creazione della Certification Authority e relativa configurazione
  2. Configurazione dei gruppi di accesso in Active Directory
  3. Creazione del server RADIUS di autenticazione utilizzando il ruolo Network Policy Server (NPS)
  4. Rilascio dei certificati per i client
  5. Configurazione degli Access Point per il supporto all’802.1x
  6. Configurazione dei client per il supporto all’EAP-TLS nelle reti wireless

Figura 1: Schema dell’infrastruttura necessaria all’implementazione del protocollo 802.1 con EAP-TLS

Creazione della Certification Authority (CA)

Per creare una certification authority si utilizza il ruolo Active Directory Certificate Services. Procedete all’installazione del ruolo in una macchina Windows Server.

Figura 2: Installazione del ruolo Active Directory Certificate Services in Windows Server 2016

Aggiungete il Role Services di Certification Authority e di Certification Authority Web Enrollment, che vi darà la possibilità di rilasciare i certificati per i vostri client anche attraverso un’interfaccia web.

Figura 3: Aggiunta dei Role Services per il ruolo di CA

Terminata l’installazione sarà necessario configurare la nostra Certification Authority. Cliccate quindi sul link Configure Active Directory Certificate Services in the destination computer.

Figura 4: Installazione del ruolo completata. È necessario però configurarlo

Dopo aver cliccato sul link si aprirà un wizard di configurazione. Configurare entrambi i Role Services che avete appena installato, come mostrato in figura:

Figura 5: Scelta dei Role Services da configurare

Il primo passaggio consiste nell’indicare se volete creare una CA di tipo Enterprise o Standalone. Nel nostro ambiente di dominio utilizzeremo una CA di tipo Enterprise.

Figura 6: Scelta del tipo di Certification Authority da installare

Poiché si tratta del primo server che installiamo, scegliamo di creare una Root CA. Per chi è poco pratico di Certification Authority e vuole conoscere nel dettaglio le differenze, consiglio la lettura dell’articolo Types of Certification Authorities

Figura 7: Scelta del tipo di Certification Authority da utilizzare

Per poter rilasciare i certificati, la vostra Root CA deve avere una chiave privata. Scegliete di creare una nuova Private Key e proseguite con il wizard.

Figura 8: Creazione della nuova chiave privata per la Root CA

La scelta del provider per la crittografia può avere un impatto determinante per la sicurezza, le performance e la compatibilità dei certificati rilasciati dalla vostra CA. Lasciate le impostazioni predefinite e proseguite nel wizard. Poiché le Cryptographic Options sono molto importanti, vi rimando alla lettura dell’articolo Cryptographic Options for CAs

Figura 9: Scelta del provider per la crittografia

Scegliete il nome della vostra CA, in modo che sia facilmente riconoscibile.

Figura 10: Scelta del nome della Certification Autority

Scegliete il periodo di validità del certificato della Root CA

Figura 11: Scelta del periodo di validità del certificato della Root CA

Specificate dove volete che venga salvato il database ed il file di log della CA

Figura 12: Percorsi di installazione del database del file di log della CA

Confermate tutte le configurazioni che avete inserito nel wizard e cliccate sul pulsante Configure:

Figura 13: Conferma delle configurazioni degli Active Directory Certificate Services

Dopo pochi istanti avrete creato e configurato la vostra Certification Authority!

Figura 14: Creazione della CA completata

Configurazione del Network Policy Service (NPS)

Per implementare la nostra infrastruttura basata su RADIUS e protocollo 802.1x ci serviremo di un server Windows in cui installeremo il ruolo di Network Policy Service (NPS). Indipendentemente dal metodo di autenticazione che utilizzerete per le vostre reti wireless (EAP-TLS, PEAP-TLS oppure PEAP-MS-CHAP v2), sarà obbligatorio installare sul Server NPS un certificato digitale che ne permetta il riconoscimento come server di autenticazione.

Per questo motivo sarà necessario distribuire tramite la nostra CA il certificato corretto, creato dal template RAS and IAS Server. Un certificate template viene utilizzato dalla CA per definire il formato ed il contenuto del certificato, per specificare quale utente o quale computer potranno richiederlo e per definirne tutte le caratteristiche e gli usi. Per maggiori informazioni potete leggere l’articolo Certificate Templates Overview

Aprite quindi la console della Certification Authority e dal nodo Certificate Template fate clic col tasto destro scegliendo New –> Certificate Template to Issue

Figura 15: Scelta del nuovo certificate template da distribuire

Per permettere al vostro server NPS di ottenere il certificato valido per poter essere utilizzato con RADIUS server, aggiungetelo in Active Directory al gruppo RAS and IAS Servers. Il gruppo infatti ha la possibilità, di default, di ottenere il certificato dal template RAS and IAS Server che abbiamo appena distribuito.

Figura 16:Aggiunta del server NPS01 al al gruppo RAS and IAS Servers in Active Directory

Riavviate il server NPS in modo tale che possa ottenere nel proprio token Kerberos il SID del gruppo RAS and IAS Servers e, dopo esservi autenticati, aprite una nuova console MMC, aggiungete lo snap-in dei Certificati Computer e procedete alla richiesta del certificato per il server NPS01, come mostrato in figura:

Figura 17: Richiesta di un nuovo certificato sul server NPS01

Se avrete effettuato correttamente tutte le operazioni, vedrete tra le opzioni disponibili la possibilità di richiedere il certificato dal template RAS and IAS Server.

Figura 18: Richiesta del certificato dal template RAS and IAS Server

Installazione del ruolo di Network Policy and Access Services sul server RADIUS

Procedete all’installazione del ruolo Network Policy and Access Services sul server NPS01, come mostrato nelle due figure:

Figura 19: Aggiunta del ruolo Network Policy and Access Services

Figura 20: Aggiunta del ruolo NPS completata

Lanciate la console del Network Policy Server e dalla scheda Getting Started scegliete dal menù a tendina che volete implementare lo scenario di RADIUS Server for 802.1x Wireless or Wired Connections. Cliccate sul link Configure 802.1x, come mostrato in figura:

Figura 21: Scelta dello lo scenario di RADIUS Server for 802.1x Wireless or Wired Connections nella scheda Getting Started

Partirà un wizard che vi guiderà nella configurazione. Nella prima schermata scegliete lo scenario. Nel nostro caso vogliamo rendere sicura una rete wireless.

Figura 22: Scelta del tipo di connessione per l’802.1x

Nella seconda schermata aggiungere il vostro RADIUS Client, cioè l’Access Point che invierà le richieste di connessione al vostro server NPS. Indicate anche uno Shared Secret, che dovrete successivamente inserire nel pannello di configurazione dell’Access Point.

Figura 23: Aggiunta del RADIUS Client (Wireless Access Point)

Figura 24: Potete aggiungere tutti i RADIUS Client che volete utilizzare nella vostra rete wireless sicura

Nella terza schermata scegliete il metodo di autenticazione. Nel nostro caso utilizzeremo i certificati digitali da installare sui pc client che vogliono accedere alla rete wireless (protetta con 802.1x ed EAP-TLS). Scegliete Microsoft: Smart Card or other certifcate e dal pulsante Configure assicuratevi di selezionare il certificato corretto per il vostro server NPS (cioè il certificato generato dal template RAS and IAS Server della vostra CA):

Figura 25: Scelta del metodo di autenticazione

Nella quarta schermata scegliete il gruppo di utenti o di computer di Active Directory che sarà autorizzato ad accedere alla rete wireless. Io ho aggiunto il gruppo Domain Computers

Figura 26: Scelta del gruppo di Active Directory che sarà autorizzato ad accedere alla rete wireless

Se utilizzate le VLAN nella vostra infrastruttura, sarà necessario effettuare ulteriori configurazioni. Maggiori informazioni sono contenute nell’articolo Configure Network Policies

Figura 27: Configurazioni relative alle VLAN

A questo punto il vostro wizard sarà terminato e verranno create una Connection Request Policy ed una Network Policy, entrambe chiamate Secure Wireless Connections.

Figura 28: Configurazione del server NPS completata

Configurazione dei computer client

Terminata la configurazione del server RADIUS è necessario configurare i client. Come prima operazione ci occuperemo di distribuire i certificati ai client che saranno autorizzati ad accedere alla rete wireless. Per poterlo fare ci serviremo di un template e delle group policy. Per poter distribuire i certificati utilizzando le GPO dovremo creare un template adatto a tale scopo.

Creazione del template per la distribuzione dei certificati ai computer del dominio

Dalla console Certificate Templates duplicate il template chiamato Computer per poterne generare uno nuovo, come mostrato in figura:

Figura 29: Duplicazione del template Computer

Dalle proprietà del nuovo template, provvedete a configurare un nuovo nome, ad indicare una durata per i certificati emessi e ad aggiungere alla scheda Security il gruppo di Computer di Active Directory che potrà richiederne i certificati che verranno da esso generati. Se volete utilizzare le GPO per la distribuzione dei certificati non dimenticatevi di selezionare l’opzione AutoEnroll, come mostrato nelle figure seguenti:

Figura 30: Definizione del nome del nuovo template certificati

Figura 31: Permesso di esportare la chiave privata

Figura 32: Aggiunta del gruppo di Active Directory autorizzato e selezione dell’AutoEnroll

Figura 33: Scelta delle informazioni da inserire nei certificati emessi

Terminata la creazione del template, collegatevi alla console di gestione della Certification Authority e distribuite il nuovo template certificato che avete creato, come mostrato nelle figure seguenti:

Figura 34: Aggiunta del nuovo certificate template alla CA

Figura 35: I due certificate template creati e distribuiti dalla nostra CA

Distribuzione del certificato computer utilizzando le Group Policy

Per distribuire il certificato Computer nel nostro dominio tramite le Group Policy vi basta creare una nuova GPO, collegarla alla OU dove si troveranno i computer autorizzati ad utilizzare la rete wireless e da Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Policies modificare la voce Certificate Services Client – Auto-Enrollment come mostrato in figura:

Figura 36: Auto-Enrollment dei certificati tramite GPO

Tutti i template certificato che saranno configurati per l’Auto-Enrollment per i gruppi di computer di Active Directory verranno distribuiti tramite questo metodo. Nessuno ovviamente vi vieta di installare manualmente i certificati sui vostri computer.

Effettuate un gpupdate sui vostri computer, magari utilizzando la PowerShell Invoke-GPUpdate e assicuratevi che abbiano ricevuto un certificato digitale

Figura 37: Certificati digitali emessi dalla CA e distribuiti tramite Group Policy

Figura 38: Certificato ricevuto dal client tramite la GPO

Configurazione degli Access Point per il supporto all’802.1x

La configurazione dei Wireless Access Point per il supporto all’802.1x varia da modello a modello. In genere trovate la configurazione sotto la voce Wireless
Security, scegliendo WPA2-Enterprise, WPA-Enterprise oppure Open with 802.1X. Nel mio caso ho scelto di utilizzare una chiave WPA2, che verrà data al computer solo dopo che sarà avvenuta l’autenticazione. Ho ovviamente dichiarato qual è il server RADIUS da utilizzare (NPS01) e lo Shared Secret che avevo precedentemente impostato nel wizard di creazione della Network Policy.

Figura 39: Configurazione del Wireless Access Point per l’utilizzo di WPA2-Enterprise

Configurazione dei client per la connessione alla rete wireless

Per configurare manualmente il client a connettersi alla rete protetta con il protocollo 802.1x è necessario effettuare delle operazioni. Spostatevi nel pannello di controllo del vostro client (Io sto usando Windows 10 versione 1709), andate in Network and Sharing Center e scegliete di configurare una connessione manuale verso una rete wireless, come mostrato in figura:

Figura 40: Connessione manuale ad una rete wireless in Windows 10

Inserite il nome della rete wireless a cui volete collegarvi e scegliete come Security type la voce WPA2-Enterprise

Figura 41: Scelta del nome della rete wireless e del metodo di autenticazione

Nel passaggio successivo cliccate sul pulsante Change Connection setting

Figura 42: Modifica delle opzioni della connessione

Spostatevi nella scheda Security e assicuratevi che nel Security type ci sia WPA2-Enterprise, nell’Encryption type ci sia AES e in Authentication method ci sia Microsoft: Smart Card or other certificate. Cliccate sul pulsante Settings per selezionare se volete utilizzare una Smart Card oppure un certificato presente sul computer e controllate di aver selezionato Use Simple Certificate Selection, nel caso sul vostro computer siano installati diversi certificati.

Figura 43: Modifica delle configurazioni di Security per la rete wireless

Cliccando sul pulsante Advanced settings potrete anche forzare come metodo di autenticazione la Computer Authentication, come mostrato in figura:

Figura 44: Opzioni avanzate della scheda Security

Confermate le impostazioni cliccando su OK e provate a collegarvi alla rete wireless. Se tutto sarà stato configurato correttamente vi riuscirete a collegare in pochissimi istanti.

È possibile verificare le configurazioni della rete wireless in qualsiasi momento accedendo al Network and Sharing Center, cliccando sul nome della rete wireless e scegliendo Wireless Properties dalla scheda Wi-Fi status, come mostrato in figura:

Figura 45: Modifica delle configurazioni della rete Wi-Fi

Configurazione dei client per la connessione alla rete wireless tramite Group Policy

Per semplificare la connessione alla rete wireless protetta con 802.1x è possibile anche utilizzare le Group Policy. In effetti la connessione manuale è alquanto impegnativa, non alla portata di tutti gli utenti ed è necessario collegarsi a tutti i pc client per poterla effettuare. Con le GPO, esattamente come abbiamo fatto con i certificati digitali per i computer, l’operazione diventa invece molto semplice.

Create una Group Policy e collegatela alla OU dove si trovano i computer che volete configurare. Spostatevi nel ramo Computer Configuration\Policies\Windows Settings\Security Settings\Wireless Network (IEEE 802.11) Policies e cliccando con il tasto destro scegliete Create a New Wireless Network Policy for Windows Vista and Later Releases, come mostrato in figura:

Figura 46: Creazione di una nuova Wireless Network Policy

Nella scheda che si aprirà, scegliete un nome per la vostra policy e cliccate su Add per aggiungere le configurazioni di una nuova rete wireless di tipo Infrastruttura, come mostrato in figura:

Figura 47: Aggiunta della nuova rete wireless

Nelle proprietà del nuovo profilo della rete wireless che volete aggiungere, inserite il nome dell’SSID della rete e cliccate sul pulsante Add

Figura 48: Aggiunta dell’SSID della rete wireless

Cliccate sulla scheda Security e configuratela con le informazioni visualizzate nella figura seguente:

Figura 49: Configurazione delle Security per la rete wireless

Completate la configurazione cliccando su OK.

Figura 50: Completamento della configurazione

Da questo momento il profilo verrà distribuito attraverso le group policy. Effettuate un gpupdate sui vostri computer client oppure utilizzate la PowerShell Invoke-GPUpdate dal domain controller e assicuratevi che i client possano accedere alla rete Wi-Fi protetta.

Conclusioni

La sicurezza è una condizione determinante per la protezione delle nostre infrastrutture e della nostra produzione. Filtrare l’accesso alle reti wireless o alle reti cablate servendosi del protocollo di autenticazione 802.1x con EAP-TLS certamente incrementa il lavoro da fare ma allo stesso tempo permette di essere sicuri che alle nostre reti possano accedere solo i computer autorizzati.

Google saluta Ubuntu e da il benvenuto a Debian

Facebooktwittergoogle_plusredditlinkedin

E’ arrivata la conferma ufficiale da parte di Google: per i client presenti nell’azienda, Big G ha deciso di abbandonare Goobuntu, sviluppata internamente e basata sul famoso Ubuntu di Canonical, in favore di gLinux, basa sul ramo testing di Debian.

Anche in questo caso la decisione di Google è stata quella di prendere un prodotto open source, introdurci delle variazioni – ogni pacchetto di Debian Testing viene preso, ricompilato testato e sistemato, introducendo modifiche o patch, prima di aggiungerlo ai repository utilizzati da gLinux – ed utilizzarlo solo internamente, senza rilasciare alcunchè pubblicamente.

Quindi non perdete tempo cercando di scaricare Goobuntu o gLinux, sono di Google e vivranno solo per Google.

La parte interessante è che Google ha rilasciato anche un whitepaper in cui mostra le scelte architetturali per la gestione di un parco client così ampio (stiamo parlando di circa un quarto di milione di macchine): viene utilizzato il sistema Puppet in modalità Masterless!

Sono quindi i client stessi che scaricano da un punto centralizzato le configurazioni puppet e le applicano in locale sulla macchina. Insieme all’uso di PXE e TFTP per l’installazione via rete di queste immagini.

Quindi, grazie a Puppet ed alla combinazione PXE+TFTP, Google è in grado di reinstallare un qualsiasi client all’interno della sua rete in meno di 30 minuti, in maniera autonoma e senza necessità di intervento umano di qualsiasi tipo.

Il tutto per avere un bel desktop con release recenti del software con un’interfaccia grafica GNOME supportata da Wayland.

Non male insomma, anche se a me piacerebbe mettere le mani su uno di questo OS per dare un occhiata sia al lavoro fatto dall’IT di Google, sia a quanta innovazione NON viene riversata nella comunità.

Siete interessati?

Micro-services in azienda: analisi di Red Hat

Facebooktwittergoogle_plusredditlinkedin

Nel corso dello scorso autunno, Red Hat ha condotto una ricerca realtiva all’adozione dei micro-services sui propri clienti di Red Hat JBoss Middleware e Red Hat OpenShift. La ricerca ha permesso di evidenziare come queste aziende stiano utilizzando i microservizi a loro vantaggio, quali vedono come benefici principali, quali problematiche esistono ancora e come possono essere superate, oltre a come i microservizi possano rappresentare un vantaggio competitivo. Chiaramente queste statistiche si riferiscono a uno specifico gruppo di clienti di Red Hat che utilizzano uno specifico set di strumenti adatti (o adattabili) ai microservizi. Però sono […]

The post Micro-services in azienda: analisi di Red Hat appeared first on vInfrastructure Blog.

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.

SPARC e Solaris: neanche Oracle si salva da Spectre

Facebooktwittergoogle_plusredditlinkedin

In questi giorni anche la californiana Oracle ha -finalmente- rilasciato le patch per fixare i problemi Meltdown/Spectre sulle sue CPU x86.

Insieme a questo, gli utenti delle sue piattaforme SPARC (ricordiamo che un tempo Solaris girava solo su quell’OS) sono stati avvisati che anche questa architettura hardware soffre degli stessi problemi di design che ha causato il problema Spectre su Intel (e le altre x86).

Quanto scovato da The Register, in un documento accessibile solo dal portale clienti, e comunque ben nascosto, indica quanto segue:

Oracle believes that certain versions of Oracle Solaris on SPARCv9 are affected by the Spectre vulnerabilities. […] Oracle is working on producing the patches for all affected versions that are under Premier Support or Extended Support.

Oracle crede che alcune versioni di Oracle Solaris su SPARCv9 sono affette dalle vulnerabilità Spectre. […] Oracle sta lavorando alla produzione delle patch per tutte le versioni affette che siano sotto supporto Premium o Esteso

Il tutto senza la minima indicazione sul quando queste patch saranno rilasciate, se non “una volta che i test sulle patch saranno completati“.

Questi avvisi avvengono qualche giorno dopo il rilascio delle patch per i propri sistemi Oracle Linux ed Oracle Virtualization, avvenuti comunque con estremo ritardo rispetto agli altri OS mainstream disponibili sul mercato (l’uscita ufficiale risale ad un paio di giorni fa).

Le patch contengono inoltre più di altri 200 bug fix per problemi anche grossi dei prodotti Oracle, dalla CVE-2017-10352 legata ad Oracle WebLogic, pubblicata il 19 Ottobre scorso e che permette ad un utente non autenticato tramite una mera chiamata HTTP di mandare in crash il server, alla CVE-2017-5645 che, grazie ad un bug di Log4j, permette di eseguire codice arbitrario da remoto sui sistemi.

Ovviamente Oracle da dei consigli su come affrontare la situazione in attesa dell’arrivo delle patch, che vanno da il “non installare software di cui non si conosce la fonte” sui propri sistemi a “limitare il numero di utenti privilegiati” su di essi; insomma, regole più che altro di buon senso che specifiche per i propri clienti.

La base hardware di installato Oracle è ancora molto forte, essendo sul mercato da parecchio tempo (prima come Sun) e fornendo, in anni in cui non era così facile averli, sistemi parecchio potenti e specializzati, ingegnerizzati molto bene.

Gli ultimi anni hanno portato l’azienda a puntare più sul software e sui servizi che sul “mero ferro”, ma la gestione di queste problematiche è stata comunque non buona.

Che gli irriducibili debbano iniziare a pensare a qualcosa di alternativo?

PC di casa down, LKML down

Facebooktwittergoogle_plusredditlinkedin

Qualche giorno fa si è registrata una certa dose di panico perché il sito lkml.org, che ospita un archivio della mailing-list del kernel linux – metodo normale di dialogo tra gli sviluppatori e canale ufficiale degli annunci del più grande progetto opensource di sempre -,  era completamente offline. E non per poco tempo: giorni!

La causa? Tra le più banali di sempre: guasto al computer che ospita il sito. Sì il computer: in epoca di cloud fa un po’ sorridere, ma il sito (o meglio, il backend) era ospitato in un computer di una casa, e nello specifico in quella dell’olandese Jasper Spaans.

Dato che la sfortuna ci vede benissimo, ha aspettato un viaggio del suddetto per far saltare la corrente elettrica di casa, con riavvio del suddetto. Appena accortosi del problema, Jasper ha imputato il mancato riavvio completo all’impossibilità di inserire la password per LUKS, il sistema di crittografia del disco: il software di collegamento remoto non funzionava, quindi ci avrebbe guardato appena a casa. Niente di grave ma, appena tornato, ha dovuto constatare che il salto di corrente aveva creato un danno vero: scheda madre andata!

Dando spiegazioni del perché il sito sarebbe rimasto giù per un tempo indeterminato, si è scatenata una vera e propria gara di solidarietà, che ha permesso in pochi minuti di trovare un pezzo di ricambio, ritirare su il server e… trasferire il tutto su una VPS (Virtual Private Server – un server privato ospitato in un datacenter remoto), così da scongiurare il ripetersi della situazione.

Chiunque si sia avvicinato al mondo sistemistico si è creato, prima o poi, qualche tipo di server in casa: che sia un server web, mail o per qualche gioco online, l’essere il fornitore per se stessi è un traguardo tanto esaltante quanto comune. Il più delle volte viene usata una macchina dedicata, e spesso a livello domestico si tratta di vecchi PC riciclati al ruolo di server – e Linux è da sempre il SO più indicato per riesumare i vecchi rottami.

Jasper non ha fatto altro che questo, offrendo un sito web al mondo da casa sua, e forse ha ignorato il fatto che quanto erogato dalle sue quattro mura è negli anni diventato molto utile ed utilizzato da tutta la comunità. Ma i tempi sono cambiati ed ora tutto deve passare dal cloud per essere affidabile. O no?

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