Datastore NFS nascosti in ESXi 6

Oggi utilizzando VMware ESXi 6 mi è capitata una cosa strana. La rimozione di un datastore NFS causava l'eliminazione del datastore dall'elenco in VCenter, ma non nel file di configurazione di ESXi. Questo causava l'impossibilità di ricreare il datastore con il medesimo nome, in quanto per ESXi già presente nel sistema.

Ho scoperto che basta editare con vi il file /etc/vmware/esx.conf eliminando i mount NFS che si trovano sotto la voce /nas//. Io ho riavviato l'host per precauzione.

Controller SATA Marvell e la rimozione sicura dei dischi inteni

Vivere in un mondo dominato dall'hot plug è una cosa positiva. Vorrei però avere il controllo su cosa è hot plug e su cosa non lo è. Ad esempio, in un semplice PC di casa, i dischi interni vorrei non fossero troppo hot plug.

Il controller Marvell 91xx presente sulla mia piastra Asus però non è molto daccordo con il mio ragionamento. Per lui tutto è hot plug.

Capita però che per rimuovere una pendrive usb in modo sicuro accidentalmente si sbagli e di rimuovano gli HD...

Teoricamente Marvell avrebbe pensato a questo ed infatti in gestione dispositivi di Windows, alla voce Marvell 91xx SATA 6G Controller dovrebbe trovarsi una scheda "Policies" per disattivare il riconoscimento dei dischi interni come dischi rimovibili. L'opzione però è latitante in tutte le versioni dei driver che io abbia provato.

Fortunatamente qualche buona anima pia in questo mondo si è messo a fare reverse engeneering ed ha scoperto la chiave del registra che disattiva questo comportamento.

Ecco la chiave in questione:


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E97B-E325-11CE-BFC1-08002BE10318}\0001 (oppure 0000 o 0002)
The DriverPolicySet value is a string (REG_SZ) which can be set to:
0 - Disable all policies.
1 - Enable driver caching only.
2 - Enable safe removal only.
3 - Enable both driver caching and safe removal.

Errore durante disinstallazione Kaspersky 6.0.3

Oggi in un vecchio PC Windows XP SP3 con antivirus Kaspersky version 6.0.3 mi sono in un problema abbastanza fastidioso. Nemmeno utilizzando il removal tool Kaspersky la disinstallazione va a buon fine. Un eventuale reinstallazione o riparazione provoca un errore di "la memoria non poteva essere written".

Fortunatamente si tratta di un errore conosciuto dalla community Kaspersky, più precisamente è un problema che affligge la versione 6, e in maniera più specifica la versione 6.0.3. Per la disinstallazione basta utilizzare il tool: KisKav6Remove

Rinominare le U2F Security Keys in WordPress

Tempo fa parlai di come integrare il supporto U2F in WordPress attraverso due plugin.

Da allora ho sempre utilizzato u2f-login svilupatto da shield-9. La cosa che mi ha sempre reso perplesso è l'impossibilità di modificare il nome della chiavetta registrata. Nel caso avessimo più U2F keys a tutte sarà affibbiato il nome "New Security Key"...

La modifica del nome non è tutto banale e richiede di mettere mano al database.

Nella tabella wp_usermeta, se fate una ricerca per il vostro user id e dovreste trovare vari record u2f_registered_key, a seconda del numero di chiavi di sicurezza che avete registrato. Bisognerà editare il contenuto di questi record. Nel campo meta_value, verso la fine, tra le tante informazioni troverete la voce "name" seguita da s:16. Tra le virgolette troverete il famigerato "New Security Key".
Per editare il nome della chiavetta registrata sarà sufficiente inserire il nome che più desiderate tra le virgolette. Dopodiché dovrete sostituire quel numero 16 con il numero di caratteri contenuti nella stringa del nome (anche gli spazi contano ovviamente).

Salvate il record e avrete cambiato il nome.

Salut

Dropbox introduce il supporto per U2F

Il supporto allo standard U2F arriva anche per Dropbox. Ora già due grandi colossi dell'IT (Google e ora anche Dropbox) prevedono questo metodone come secondo fattore di autenticazione. Speriamo che molti altri prendano questa strada, e che magari, in un futuro non troppo lontano, anche gli istituti bancari (PayPal in primis) introducano questo fantastico sistema. Addio a tutti i token generator che ci portiamo dietro.

Alcuni potrebbero obbiettare che le app per iPhone e Android che permettono di generare gli OTP (Google Authenticator in primis) possano essere già un'ottima soluzione al problema di avere un secondo fattore di autenticazione solido. E io condordo in pieno. Il difetto di queste app a mio avviso è che sono fortemente legate al telefono, un dispositivo che un giorno c'è e il giorno dopo non c'è più: perchè è stato sostituito, smarrito, rubato oppure semplicemente formattato. Una volta che questo succede è necessario effettuare le operazioni di recupero della password per ogni servizio che va ad utilizzare l'OTP.

Con le chiavi di sicurezza invece si ha uno strumento dedito ad un unico scopo. Una stessa chiave permette il login a più servizi e pià chiavi possono essere associate al medesimo servizio. Questo ci permette di avere una chiave U2F sempre con noi, e una di backup in un posto sicuro. Potremmo ad esempio utilizzare una chiave Yubico, molto robuste e con funzionalità avanzate, come chiave primaria e una Plug-UP come secondaria, dato il suo costo di soli 5€.

Già in questo stato Dropbox prevedere la possibilità di associare molteplici chiavi U2F ad un unico account.

Questo è il post sul blog ufficiale Dropbox.

U2F is the WAY!

Compilare pam-u2f e integrarlo nell'autenticazione in Linux

Premetto che su CentOS 6 questo è ancora un work in progess, probabilmente sbaglierò io qualcosa, ma i binari e le librerie prodotte non riescono a instaurare una comunicazione corretta tra bus USB e sistema, anche se la Yubikey viene vista correttamente dal sistema.
La compilazione di pam-u2f richiede parecchie dipendenze e le librerie necessarie non sono disponibile nei repo ufficiali (incluso epel).

Preso dalla frustrazione ho tirato su una VM CentOS 7 e con grande soddisfazione ho trovato alcune librerie necessarie (json-c e hidapi) in epel. In questo caso la compilazione va a buon fine in maniera semplice semplice e possibile applicare il modulo pam-u2f a tutte quelle applicazioni pam-aware. Lo stesso vale per Debian 8.

Nel caso non sapeste cosa e come funzioni PAM, consiglio la lettura di questo ottimo articolo. Vi darà un'infarinatura generale sulle potenzialità di PAM, uno strumento spesso non considerato.

INSTALLAZIONE

Per prima cosa installiamo un po' di pacchetti necessari, per la guida prenderò in considerazione installazioni CentOS 6 e CentOS 7:

Da tenere in considerazione che alcuni pacchetti come json-c (presente nei repo, ma non adeguato) e hidapi non sono disponibili nei repo ufficiali di CentOS 6. Fare riferimento alla nota a piè di pagina.

Ora andiamo a scaricare il software Yubico

I primi due pacchetti vanno compilati allo stesso modo. Basta entrare in ogni cartella e dare i seguenti comandi:

Arrivati a pam-u2f sarà necessario creare dei link simbolici per pkg-config (nel caso non fosse presente bisognerà installarlo).

Il modulo pam_u2f.so verrà installato in /lib/security/ (32 bit) o /lib/x86_64-linux-gnu/security/ (64 bit). Controlliamo che il modulo abbia i permessi di esecuzione e andiamo avanti.
Verrà installato anche un piccolo binario (pamu2fcfg) che tornerà molto utile nella configurazione del modulo.

Ricordate che se non utilizzate l'utente root dovete inserire in /etc/udev/rules.d la regoletta udev che permette anche agli utenti non-root di accedere al device. Nel pacchetto libu2f-host sono presenti due regole 70-u2f.rules, una per le versioni più recenti di udev e uno per quelle più datate.

Per fare il reload delle rules di udev basta dare il comando:

CONFIGURAZIONE

A questo punto il grosso del lavoro è stato fatto. Però prima di mettere mano al file pam del servizio su cui vogliamo attestare il secondo fattore di autenticazione (ad esempio /etc/pam.d/sshd), dobbiamo andare a creare una mappa che associa la chiave x ad determinato utente.
Per fare questo andiamo a creare un /etc un file u2f_mappings (potete chiamarlo come volete) al cui interno andremo a metterci l'output dell'utility pamu2fcfg.
Ad ogni utente potranno essere associate più chiavi, basterà separare la tupla KeyHandle e UserKey con dei :

Quando andremo a lanciare il comando pamu2fcfg la nostra Yubikey inizierà a lampeggiare, basterà toccarla per far comparire sullo schermo le informazioni di cui avremmo bisogno. Se nessun parametro aggiuntivo viene fornito la Yubikey sarà associata all'account correntemente loggato e come appid e origin sarà utilizzato il valore della variabile d'ambiente $HOSTNAME.

Per attivare il secondo fattore di autenticazione U2F andiamo a inserire questa riga nel file di configurazione PAM.

Questo è solamente un esempio, poi sta a voi associare il corretto control flag e la PAM activity.

L'elenco degli argomenti che pam_u2f accetta sono disponibili a questa pagina.

Una piccola nota conclusiva.
U2F è sicuramente un protocollo di autenticazione interessante. Però si vede lontano un miglio che è pensato per essere applicato al mondo web. E quindi da il suo meglio quando viene implementato tra un webserver e un browser. Per carità pam_u2f funziona. Però difficilmente può essere implementato come sistema di autenticazione per accedere a una macchina remota. Esistono già delle patch per integrare U2F in OpenSSH, ma secondo me questo è un ottimo sistema per farsi del male, tanto tanto male.

UPDATE CentOS 6

Alla fine ho scoperto l'inghippo nelle distribuzioni CentOS 6. Semplicemente con il kernel 2.6.32, di default presente in tutte le CentOS 6, le yubikey non viene riconosciuta. Probabilmente qualche problema con libusb o hidapi. Utilizzando un Kernel 3.10 o addirittura 4.1 (disponibili su ElRepo) tutto funziona like a charm.

Alcuni pacchetti come hidapi e json-c non sono disponibili e quindi vanno compilati a mano.

https://github.com/signal11/hidapi
https://github.com/json-c/json-c

Anche in questo caso, una volta compilati e installate queste librerie sarà necessario creare dei link simbolici dei file .pc installati ("find / | grep -i hidapi | grep -i *.pc") per il pkg-config. I link andranno creati in in /usr/share/pkgconfig/.
La compilazione di questi due pacchetti è la prima cosa da fare in una CentOS 6 in quanto sono necessari per le librerie u2f.

OpenKeyChain: chiavi PGP sempre con noi.

In questi giorni sto smanettando un po' con le Yubikey, ho già scritto qualcosa nel blog e presto arriveranno altri post. Oggi volevo cogliere l'occasione di consigliarvi questa appalicazione, OpenKeyChain. La utilizzo già da diversi mesi, ed è un utility veramente ottima per gestire le miei chiavi PGP.

Proprio la settimana scorsa OpenKeyChain ha introdotto il supporto alle Yubikey. Il funzionamento estremamente semplice e banale unito ad un'interfaccia veramente intuitiva ne fanno un must.

Provatela. 😉

MAC telnet server/client su CentOS

Per chi non lo sapesse MAC telnet è un'implementazione L2 (layer 2) di telnet. E' possibile trovarla in tutti i prodotti Mikrotik, in modalità sia client che server. Questo protocollo di comunicazione è molto comodo per vari aspetti. Mentre, dal punto di vista della sicurezza è un vero e proprio buco nero, in quanto si porta dietro tutte le criticità di telnet e per di più lavora ad un livello più basso del modello OSI.

Il sistema però risulta comodo e molto efficace, anche non avendo assegnato nessun IP ad un determinato host noi riusciremo ad accedervi, identificandolo con il proprio MAC address.

Un'anima pia ha sviluppato un pezzo di codice per linux che realizza proprio questa funzionalità. Va a implementare un server MAC telnet con corrispettivo client, il MAC ping e un tool di discovery per apparati Mikrotik.

Tutte le info sono disponibili a questo indirizzo, mentre i sorgenti sono disponibili su GitHub.

Personalmente la ho testata su CentOS ed in seguito posterò anche lo script di init per distro CentOS/RedHat.

L'installazione non è complicata, sono però necessari i tool di sviluppo in quando non sono riuscito a trovare un pacchetto .rpm già pronto per l'uso. Compilazione terminata sarà necessario editare il file /etc/mactelnetd.users e aggiungere gli utenti e relative password abilitati al login via MAC telnet.

Quando il servizio è in esecuzione sarà possibile effettuare il login sull'host da un qualsiasi Mikrotik fisicamente collegato in L2. Non è cosa da poco. Molto comodo in casi di emergenza dove la macchina non è più utilizzabile via SSH.

La criticità maggiore è che appunto qualsiasi device che deve in L2 il nostro server sarà in grado di tentare un login. Tutti i tentativi di login vengono loggati in /var/log/messages però proprio perchè si opera ad un così basso livello non sarà possibile applicare regole di fail2ban per bloccare eventuali tentativi attacchi brute-force. Scordatevi iptables. Sarà necessario usare un firewall layer 2.

Auto login in FOP2

Questo è un piccolo reminder per il futuro.
Nel caso qualcuno di voi utilizzasse FOP2 è possibile effettuare l'auto login inderendo questo URL nella barra degli indirizzi

Dove 200 è l'interno e 1234 è la password.

Syntax highlighting per Asterisk

Da un annetto circa sono entrato nel magico mondo di Asterisk. E solo dopo un anno mi è venuto in mente di cercare i syntax highlighting. Premettiamo che il 99,9% delle volte lavoro via SSH e utilizzo il comodissimo mcedit per editare i file. Anche perchè probabilmente impiegherei di più a modificare il file in locale e uploadarlo nel PBX. L'unica soluzione che mi permette di modificare i file di configurazione direttamente live sulla macchina è utilizzare sshfs. Se qualche visitatore ha idee migliore queste sono ben accette.

Torniamo a noi!

Per Sublime Text, un editor che va molto di moda in questo periodo, per gli sviluppatori che vogliono fare i fighetti :D, ho trovato questo plugin. Installabile anche tramite packpagecontrol. Funzionerà anche con Atom? Scopritelo voi! 😀

Quest'altro plugin invece è per gli amanti di Notepad++.

Ma se riesco a trovare highlighting per mcedit (sempre che esista) state pur sicuri che lo caricherò. :)

Divertitevi a scrivere dialplain.