The network hole

Come ripromessomi, rieccomi qui a prendere nota di come tappare un buco di cui ero consapevole ma che finora ho ignorato visto i rischi relativamente bassi.

Poi è arrivato KeRanger. Gli “espertoni” dicono che non dobbiamo preoccuparci, tanto al massimo sono stati infettati 6500 Mac, e loro – solo per questione fortuita – non erano tra gli sfigati: che peccato!

In realtà dovremmo cominciare a farlo perché là fuori c’è qualcuno intenzionato a colpire la fascia di utenti smaliziata: è un po’ strano, perché colpire utonti di solito è economicamente molto più fattibile, ma è successo. Cioè: a scaricare Transmission dal sito di Transmission e lanciarlo sul Mac avrei potuto anche essere io. Il passo successivo, quello di controllare l’hash dei file per ogni applicazione da installare, è roba da Snowden.

Aspetti negativi: gli antivirus per questo tipo di attacchi basati sulla tempestività SONO INUTILI.

Come mitigare:

  1. installare ed usare qualcosa come QUBE OS, ma anche questo è roba da Snowden.
  2. backup: funziona solo se il backup supporta la history dei file, funzionalità abbastanza comune (lo fa CrashPlan e il backup server di Windows Home Server). Perché se il backup mantiene solo l’ultima copia, potrebbe essere quella già criptata

Un altro aspetto collegato è il fatto che ormai da sempre tutti i miei contenuti, documenti/multimedia/ecc., sono depositati su un server NAS centralizzato, e questi sono accessibili con le stesse credenziali che uso quotidianamente. Da questa riflessione sviluppatasi nel forum è venuto fuori che avere permessi di scrittura su un NAS usando le stesse credenziali è altrettanto pericoloso: un’applicazione malevola potrebbe cancellare tutte le mie foto, criptarle o distruggerle in qualsiasi altra maniera irreparabile. Per questo tipo di evenienza, che copre anche il guasto hardware degli hard-disk, c’è la copertura di CrashPlan online, ma dover scaricare TB di dati non è il massimo della convenienza.

Ieri sono arrivato alla conclusione che avere un unico set di credenziali con permessi di scrittura è nocivo, sbagliato e va risolto: prima meglio che poi. E ieri ho risolto: rimossi i permessi di scrittura a tutti gli utenti interattivi di casa, ovvero gli umani, e assegnati permessi di scrittura solo ad amministratori e bot protetti da password diverse. C’era solo un piccolo problema da superare: Windows non permette di usare due credenziali diverse quando si accede a due share diverse di uno stesso server.

In poche parole, non si può usare Topolino per accedere a \\SERVER\topolino ed usare Paperino per accedere a \\SERVER\paperino. Ora se solo fosse possibile avere due “nomi” per lo stesso “SERVER”, visto che le credenziali sono legate al nome del server, si sarebbe a cavallo.

Questo per fortuna è possibile in un paio di modi:

  • se sul server si usa SAMBA, intesa come l’implementazione Linux/Unix del protocollo SMB, allora è semplicissimo. Basta aggiungere una riga in cima al file di configurazione (smb.conf). Esempio:
    netbios aliases = SERVER TOPOLINO PAPERINO
    Una volta riavviato il servizio nmbd, si può raggiungere il server usando uno qualsiasi dei nomi indicati. Per Windows sembreranno server diversi, quanto basta per assicurarsi la possibilità di usare appunto credenziali diverse.
  • se si tratta di un server Windows o altra roba e se il server Windows ha un indirizzo IP statico, allora basta aggiungere la coppia “indirizzo_IP aliasserver” al file in \WINDOWS\SYSTEM32\etc\drivers\hosts e risolvere la questione (sfortunatamente sul lato client)
  • in ogni altro caso, il consiglio è di passare ad Ubuntu Server 16.04: supporta ZFS nativamente e a tanta bell’altra roba (dieci anni fa, altri tempi)

A questo punto si tratta solo di creare le share con diversi permessi ed il gioco è fatto.

Data la centralizzazione del controllo, il primo metodo è preferibile al secondo, ma in ogni caso dal punto di vista operazionale sono identici.

Alla fine della giornata, se anche facessi girare il malware usando le mie credenziali, il danno sarebbe comunque limitato alla macchina su cui gira. Se anche questa è regolarmente backuppata possiamo veramente “smettere di preoccuparci”.

-quack

Pubblicato sabato 19 marzo 2016 alle 12:19 AM - 55 commenti so far
Archiviato in: Windows, Security, Linux

Il pianoforte sulla testa

Apple ce la manda a dire:

Apple lawyer says meeting FBI demand would help hackers 'wreak havoc'

Cioè se loro aiutano l’FBI a sbloccare il telefono, gli acheri di tutto il mondo occuperanno il pianeta. Chissà perché però ogni volta che il tono si avvicina ad una minaccia che se facciamo XYZ allora l’utente rischia di essere colpito da un pianoforte sulla testa, io divento estremamente scettico.

Notare un paio di cose: Apple non ha MAI detto non si può fare. Cosa strana perché ad esempio su un Nexus propriamente configurato una cosa del genere NON SI PUÒ fare. Se sblocchi il bootloader per aggiornare il firmware perdi i dati. Sul telefono di Apple, non so se solo sul modello in questione o meno, invece a quanto pare SI PUÒ. Lo può fare Apple che potrebbe generare un firmware ad-hoc e legato a quel specifico numero di seriale, ma chiaramente non vuole.

Io mi son fatto un paio di idee. La prima: Apple da sempre ci sguazza nel fare la figura del Davide contro Golia, tipicamente Microsoft. Adesso che i ruoli si sono invertiti al marketing di Apple serve un nuovo Golia. Chi meglio del “governo americano” può assumere questo ruolo? Persino quel cattivissimo di Trump, nel suo chiedere il boicottaggio dei prodotti Apple, riesce a rendere più simpatica l’azienda di Cupertino.

La seconda: è in scena una lotta di potere tra l’azienda e il governo, americano o chicchessia, su chi debba avere l’ultima parola in casi del genere. Se fosse posta così la questione davvero molti dei pundits che prendono per oro colato quello che esce dalle bocche degli avvocati di Cupertino se la berrebbero così facilmente?

Terza: insistono col dire che l’FBI vuole una backdoor. Ci distraggono dal fatto che la backdoor c’è già e non hanno nessuna intenzione di toglierla. Perché?

-quack

P.S. per backdoor intendo il fatto che se si può aggiornare il firmware (upgrade o downgrade) di un iPhone “bloccato” allora siamo di fronte ad una porta di servizio.

Update: Piccola correzione, sostituendo Android con “Nexus propriamente configurato”. Perché ovviamente non c’è garanzia che tutti i vendor seguano correttamente le specifiche.

Update 2: Sono riuscito a trovare la richiesta dell’FBI che dice:

[Provide] the FBI with a signed iPhone Software file, recovery bundle, or other Software Image File (“SIF”) that can be loaded onto the SUBJECT DEVICE. The SIF will load and run from Random Access Memory (“RAM”) and will not modify the iOS on the actual phone, the user data partition or system partition on the device’s flash memory. The SIF will be coded by Apple with a unique identifier of the phone so that the SIF would only load and execute on the SUBJECT DEVICE. The SIF will be loaded via Device Firmware Upgrade (“DFU”) mode, recovery mode, or other applicable mode available to the FBI. Once active on the SUBJECT DEVICE, the SIF will accomplish the three functions specified in paragraph 2. The SIF will be loaded on the SUBJECT DEVICE at either a government facility, or alternatively, at an Apple facility; if the latter, Apple shall provide the government with remote access to the SUBJECT DEVICE through a computer allowed the government to conduct passcode recovery analysis.

In poche parole, nella richiesta dell’FBI, c’è già il vincolo che l’update funzioni solo sul telefono in questione. Allora come è possibile che un update vincolato a funzionare solo su quel telefono possa permettere “agli acheri di conquistare il mondo”? Perché Apple mente così spudoratamente?

Pubblicato martedì 1 marzo 2016 alle 7:38 PM - 16 commenti so far
Archiviato in: Apple

Feature Parity

Oggi, nella migrazione da XEN a KVM/VFIO, sono riuscito a raggiungere una milestone eccezionale: feature parity tra i due sistemi, ma con estrema – molto estrema – semplificazione di architettura. Ho dovuto fare una quantità di esperimenti interessanti, tempo che non considero perso in quanto per me altamente educativo.

Ad esempio all’inizio ero indeciso su quale distro scegliere tra le tre papabili:

  • arch-Linux, scartata immediatamente quando ho scoperto di cosa si tratta il repository AUR: roba distribuita in codice sorgente e mantenuta a tempo perso; anche Crashplan è distribuito purtroppo così e non mi fido di affidare l’applicazione per il backup a gente che dedica spiragli di tempo come me.
  • Fedora: VFIO è nato e sviluppato in Red-Hat. Però santa pazienza, su Fedora bisogna combattere coi draghi solo per installare un server XRDP. Non sto scherzando. La tentazione è stata grande perché le istruzioni più complete su VFIO sono scritte con Fedora in mente.
  • Ubuntu. Familiarità uber all. Ma anche qui il dilemma: LTS o no? Alla fine ho scelto LTS ferma a due anni fa ben conscio che alcune feature interessanti saranno disponibili nella nuova LTS in dirittura di arrivo per Aprile.

Il risultato interessante è che il servizio rippatutto, non senza dolori, adesso gira su una Micro-VM con XP. Avessi più tempo lo riscriverei in Java, ma le funzionalità Text To Speech su Linux sono alquanto primitive (le voci ricordano il SAM dei tempi andati su un C64). Il software di backup e il pool ZFS girano finalmente direttamente sull’host. Nel frattempo ho dovuto imparare come configurare AppArmor e una quantità non irrilevante di cosette, come ad esempio il fatto che il file da configurare per AppArmor è /etc/apparmor.d/abstractions/libvirt-qemu (aggiungere il file di script e sed alla lista).

Risultato finale: anche se parziale, sono soddisfatto.

-quack

P.S. ho comprato un case nuovo, vista l’abbondanza di spazio verticale nella nuova ubicazione. Ho intenzione di installare un adattatore 4x3 e rendere i dischi dati facilmente raggiungibili scopo creazione di un futuro server ridondante per la pace dei sensi.

Pubblicato martedì 16 febbraio 2016 alle 3:36 AM - 7 commenti so far
Archiviato in: Virtualizzazione

2016, fuga da

È arrivato il nuovo anno e approfittando delle vacanze natalizie ho messo a punto il mio piano di fuga. Della fuga da Windows ne ho già parlato, ma in questi giorni sto fuggendo da Solaris. Non è bello sapere di avere un sistema che gira su software in fin di vita. Il mio fedele Solaris para-virtualizzato, in esecuzione su XCP 1.5 BETA, non è più supportato nelle versioni successive. Ho guardato nel frattempo verso KVM che mi sembra molto più stabile con l'idea di avere un host che faccia anche da server SMB e risparmiare una macchina virtualizzata coi suoi costi. Armato di un nuovo HD di provenienza saldi da Black Friday ho fatto il backup del Pool. La mossa successiva è stata quella di installare il Pool su una VM Ubuntu con supporto ZFS ora che pare sia abbastanza stabile: ovviamente non tutto è filato liscio, la tabella delle partizioni di 3 HD su 4 era corrotta: strano che Solaris riuscisse a far partire il Pool in queste condizioni, ma armato di backup ho provato parted. Ho rifatto la tavola delle partizioni da zero e recuperato la partizione, un HD alla volta, e provato che i dati fossero ancora lì. Sistemato l'ultimo HD il Pool è stato importato con successo su Ubuntu. Purtroppo per chissà quale baco misterioso il Pool non è più importabile su Solaris, ma a questo punto poco importa.
Il passo successivo è stato quello di configurare SMB coi suoi permessi, piccoli grattacapi, ma dal punto di vista del Server Windows su cui gira CrashPlan tutto sembra uguale e la cosa è molto, estremamente incoraggiante (il backup di 1.8TB di dati spalmati su 125.701 file è appena completato con successo).
Prossimo passo è quello di spostare CrashPlan da Windows ad Ubuntu, ma sembrerebbe un gioco da ragazzi ampiamente documentato. Se tutto dovesse andare liscio il passaggio a KVM da Xen dovrebbe essere praticamente indolore. Reinstallerei la Workstation di Windows 7 da zero su KVM, visto che l'HD su cui gira al momento è quasi privo di spazio, ma terrò da parte i tre vecchi HD che non si sa mai.
Sorprese positive: SMB è stato più facile da configurare di Solaris una volta letta la paginetta di documentazione appropriata. E siccome Solaris usava CIFS la banda è pressoché raddoppiata: non che sia una cosa importantissima, ma come piccolo bonus extra non ci si può lamentare.
Il passo finale è quello di fare qualche test e decidere il sistema operativo host: sono indeciso tra Ubuntu per la velocità di messa in piedi e ArchLinux per il footprint incredibilmente limitato. Ma questa è una decisione che posso prendere con calma. L'importante è essere uscito da quel brutto vicolo cieco di un ammasso di sistemi arrivati a fine corsia (XCP, Windows Home Server, Solaris). Per i prossimi 4-5 anni dovrei essere a posto.

-quack

Pubblicato giovedì 7 gennaio 2016 alle 12:29 AM - 3 commenti so far
Archiviato in: Virtualizzazione

Nexus 5X: il buono, il brutto, il cattivo

È da un po’, diversi giorni, che uso il Nexus 5X con l’account aziendale. A causa di questo mi è stato detto che, vista la quantità di dogfood che devo necessariamente sorbirmi, non posso fare osservazioni accurate sulle prestazioni in generali o sulla durata della batteria a causa del fatto che il dogfood tende ad essere poco attento a questi due fattori importanti. Ciononostante le mie impressioni sono prettamente positive. E allora senza colpo ferire passiamo al…

BUONO

Lettore di impronte: l’account aziendale, in quasi tutte le versioni, richiede misure di sicurezza aggiuntive come ad esempio l’obbligo di avere il dispositivo criptato o impostare un PIN. Da questo punto di vista il lettore di impronte del 5X con la sua posizione strategica è una vera e propria manna che mi consente di sbloccare il dispositivo con il semplice gesto di sollevarlo dal tavolo (o estrarlo dalla tasca).

Hardware in generale: semplicemente eccezionale, a me lo stile Nexus piace parecchio e lo si dovrebbe capire dal fatto che questo è il mio quinto Nexus. Lo schermo è un tocchettino più grande e dà la possibilità di spremere più icone nell’home screen.

Camera: sulla qualità generale della camera tanto di cappello. 12MP sul retro, 5MP sul fronte, performance ottime anche in condizioni di luce meno che soddisfacenti. Non che sia un patito delle foto fate col cellulare, ma la qualità c’è.

Tempi di ricarica: USB-C in quick-charge mode significa 1% al minuto circa. Da scarico ci metto al massimo novanta minuti per ricaricarlo al 100%. Ottimo.

Supporto a Google-Fi: questo per me è un grande vantaggio. Sono di principio contrario ai piani a pacchetto (paghi tot al mese per X minuti o Y GB; se sfori c’è la penale, se non sfori ci perdi) e Google-Fi va nella direzione giusta, ma ci vuole un dispositivo che supporti lo switching tra rete cellulare e Wi-Fi in maniera seamless. Nexus 6 e Nexus 5X lo supportano. Son passato proprio ieri a Google-Fi e staremo a vedere.

BRUTTO

USB-C: la porta USB-C supporta solo USB2 dal punto di vista del trasferimento dati; mi importa poco, perché è da parecchio che non trasferisco via USB ma è una gran rottura di scatole per via del dover cambiare cavetti e adattatori, almeno fino a quando lo standard non diventa più ubiquo.

Led Notifiche: di default è disabilitato, questo mi lascia presagire che in futuro possa essere rimosso. Io lo trovo molto comodo, se così fosse sarebbe un vero peccato.

CATTIVO

Rimozione di alcune feature: è stata rimossa la stabilizzazione ottica (credo, mi pare che il Nexus 5 ce l’avesse) e la ricarica wireless, anche quella molto comoda; la seconda non è una grossa perdita visto che la velocità di ricarica sarebbe estremamente bassa e la batteria comunque, anche in condizioni svantaggiose, sembra riuscire a tenere testa al carico di lavoro giornaliero.

Bottomline: come in passato, nel passaggio da Nexus 4 a Nexus 5 (ouch, scopro di non averne mai parlato!), ho sofferto un po’ con l’upgrade; ho l’impressione però che i pro supereranno presto con la forza dell’abitudine i pochi contro e di tornare al Nexus 5 mi sembrerà presto impensabile come tornare oggi indietro al Nexus 4.

-quack

Pubblicato mercoledì 11 novembre 2015 alle 6:11 AM - 0 commenti so far
Archiviato in: Google, Cellulopoli