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

Potrebbero interessarti anche:
Commenti (55): [ Pagina 1 di 2  - più vecchi ]
26. Snake
lunedì 21 marzo 2016 alle 1:47 PM - chrome 49.0.2623.87 Windows 10
   

A parte che basta un net share /d per eliminare un autenticazione a una share, 

Su Windows 10 pare di no

NET SHARE

sharename

          sharename=drive:path [/GRANT:user,[READ | CHANGE | FULL]]

                               [/USERS:number | /UNLIMITED]

                               [/REMARK:"text"]

                               [/CACHE:Manual | Documents| Programs | BranchCache | None]

          sharename [/USERS:number | /UNLIMITED]

                    [/REMARK:"text"]

                    [/CACHE:Manual | Documents | Programs | BranchCache | None]

          {sharename | devicename | drive:path} /DELETE

 

          sharename \\computername /DELETE

   
27. Snake
lunedì 21 marzo 2016 alle 1:48 PM - chrome 49.0.2623.87 Windows 10
   

Se /d era l'alias di /delete, serve ad ELIMINARE le share, sia locali che remote, non a deautenticare l'utente.

   
28. Paperino
lunedì 21 marzo 2016 alle 6:05 PM - chrome 49.0.2623.87 Linux
   

A parte che basta un net share /d per eliminare un autenticazione a una share, 

Sì, si può fare ma è una rottura di pelotas, oltre a non poter essere automatizzabile e ad avere un altro paio di contro-indicazioni. Con la soluzione di cui sopra, dare permessi di scrittura ad un account che gira in un servizio, diventa un gioco da ragazzi.

Non mi sembra una soluzione così ovvia, forse dovrei brevettarla.

   
29. FOLBlog
lunedì 21 marzo 2016 alle 9:40 PM - chrome 49.0.2623.87 Windows unknown
   

A parte che basta un net share /d per eliminare un autenticazione a una share

NET SHARE /D interrompe la condivisione.
E' un comando lato server, non lato client.

Qui serve un comando per disconnettere la sessione attuale del client con un comando impartito dal client, non dal server.

 

   
30. FOLBlog
lunedì 21 marzo 2016 alle 10:26 PM - chrome 49.0.2623.87 Windows unknown
   

Secondo me stiamo parlando di fuffa.

Senza offesa, sicuro di aver ben capito di cosa stiamo parlando?

..non ho capito perché sarebbe un problema autenticarsi con due utenti

Non è un problema, è impossibile nella stessa sessione.
Una volta effettuato il login come utente A sul PC Client (cioè avviata la sessione client), puoi accedere ad una share di rete utilizzando solo una coppia di credenziali e quelle credenziali determinano i diritti di quell'utente.
Per poter accedere alla stessa share con altre credenziali devi effettuare il logout dal PC client (o riavviarlo), cioè interrompere la sessione attuale con cui sei già autenticato presso il server che condivide la cartella che ci interessa, e poi accedere con altre credenziali.
Qui si sta discutendo come fare i backup da un client e, contemporaneamente, consentire all'utente di accedere alle cartelle che li memorizzano con un altra coppia di credenziali con diritti RO.
Nessuna fuffa.

   
31. Paperino
martedì 22 marzo 2016 alle 12:16 AM - chrome 49.0.2623.87 Windows 7
   

Qui serve un comando per disconnettere la sessione attuale del client con un comando impartito dal client, non dal server.

net USE /D \\server\share

   
32. Snake
martedì 22 marzo 2016 alle 1:12 AM - chrome 49.0.2623.87 Windows 10
   

a me non disconnette, mi restituisce solo

The network connection could not be found.

   
33. FOLBlog
martedì 22 marzo 2016 alle 8:08 AM - chrome 37.0.0.0 Android 4.4.2
   

@Paperino
Quel comando disconnette un utente.
Ma funziona solo sul server, non sul client.

   
34. Paperino
martedì 22 marzo 2016 alle 6:11 PM - chrome 49.0.2623.87 Linux
   

Ma funziona solo sul server, non sul client.

No, sono dieci anni che lo uso sul client. Notare la differenza tra quanto scritto da Mah (net share /d) e quanto scritto da me (net use /d). Lo uso proprio per quei casi in cui devo testare credenziali diverse. Se poi hanno cambiato qualcosa da Windows 8 in poi, non so.

   
35. Mah...
martedì 22 marzo 2016 alle 6:28 PM - firefox 45.0 Windows 10
   

sì scusate, ho scritto una minchiata... ovviamente è net use /d, non net share /d ... Sono fuso, mi servono ferie...

   
36. Snake
martedì 22 marzo 2016 alle 7:03 PM - chrome 49.0.2623.87 Windows 10
   

@Paperino:

No, sono dieci anni che lo uso sul client. Notare la differenza tra quanto scritto da Mah (net share /d) e quanto scritto da me (net use /d). Lo uso proprio per quei casi in cui devo testare credenziali diverse. Se poi hanno cambiato qualcosa da Windows 8 in poi, non so.

Su 10, invocato con /d oppure con /?, mi da:

NET USE

[devicename | *] [\\computername\sharename[\volume] [password | *]]

        [/USER:[domainname\]username]

        [/USER:[dotted domain name\]username]

        [/USER:[username@dotted domain name]

        [/SMARTCARD]

        [/SAVECRED]

        [[/DELETE] | [/PERSISTENT:{YES | NO}]]

 

NET USE {devicename | *} [password | *] /HOME

 

NET USE [/PERSISTENT:{YES | NO}]

Temo abbiano cambiato qualcosa.

   
37. Paperino
martedì 22 marzo 2016 alle 7:37 PM - chrome 49.0.2623.87 Linux
   

/D era la scorciatoia di /DELETE

Provate 

net use /DELETE \\server\share

   
38. Paperino
martedì 22 marzo 2016 alle 7:40 PM - chrome 49.0.2623.87 Windows 7
   

BTW, l'help di Windows 7 è identico. Ma /D funziona:

net use /D \\server_rw\_RW_

There are open files and/or incomplete directory searches pending on the connection to \\server_rw\_RW_.

 

Is it OK to continue disconnecting and force them closed? (Y/N) [N]: y

\\server_rw\_RW_ was deleted successfully.

 

   
39. Snake
martedì 22 marzo 2016 alle 9:44 PM - chrome 49.0.2623.87 Windows 10
   

Ho eliminato le credenziali salvate (da rundll32.exe keymgr.dll, KRShowKeyMgr), riavviato, provato a riaccedere non ad una share precisa, ma alla "root", questa volta senza salvare le credenziali.

Con "net use" mi da solo \\server\IPC$

Se provo ad eliminarla con /d ottengo "\\server\IPC$ was deleted successfully."

Nonostante con un "net use" successivo ottengo "There are no entries in the list.", continuo a navigare le share come niente fosse

Sbaglio qualcosa?

   
40. Snake
martedì 22 marzo 2016 alle 9:50 PM - chrome 49.0.2623.87 Windows 10
   

Riavviato, stavolta ho provato ad accedere direttamente alla share senza passare per la root, tipo

\\server\share

Chiede di nuovo le credenziali, mi autentico, sparo un "net use" e mi esce

 

Status       Local     Remote                    Network

 

-------------------------------------------------------------------------------

OK                     \\server\share        Microsoft Windows Network

The command completed successfully.

 

e fin qua ci siamo.

MA!

se riprovo con "net use /d \\server\share", ottengo il solito "was deleted successfully" ma la sessione continua a funzionare

Posso persino tornare alla root ed accedere alle altre share (nonche` alla stessa share che ho appena "rimosso"), nel mentre "net use" continua a restituirmi impassibile "There are no entries in the list."

 

Dove sbaglio?

   
41. Paperino
mercoledì 23 marzo 2016 alle 12:17 AM - chrome 49.0.2623.87 Windows 7
   

Dove sbaglio?

Non vorrei dire... ma Windows 10? Con Windows 7 funziona come dovrebbe.

   
42. Snake
mercoledì 23 marzo 2016 alle 12:56 AM - chrome 49.0.2623.91 Android 6.0.1
   

Fair point

   
43. FOLBlog
mercoledì 23 marzo 2016 alle 7:47 AM - chrome 37.0.0.0 Android 4.4.2
   

@Paperino net use /d serve a disconnettere un percorso di rete associato ad una lettera.
Esempio: \\server\share associato a S:\.
Non chiude la connessione se al server ti colleghi usando il percorso UNC.
Serve in sostanza a disconnettere tutte le unità di rete connesse alle client.
Poi è chiaro che se poi le riconnetti puoi anche usare nuove credenziali.
Ma non è utile nel nostro discorso.
Anche perché presuppone che da qualche parte ci sia uno script in cui si usa net use per connettere una risorsa, con le credenziali in CHIARO.

   
44. Paperino
mercoledì 23 marzo 2016 alle 5:43 PM - chrome 49.0.2623.87 Linux
   

@Paperino net use /d serve a disconnettere un percorso di rete associato ad una lettera. 

No. Net use /d serve "smontare" una share, indipendentemente dal fatto che sia associato ad un drive o meno.

C:\>dir \\server_RW\_RW_
Access is denied.

C:\>net use /user:administrator \\server_RW\_RW_
Enter the password for 'administrator' to connect to 'server_RW':
The command completed successfully.

C:\>dir \\server_RW\_RW_

 Volume in drive \\server_RW\_RW_ is _RW_
 Volume Serial Number is 8B0B-B71E
 Directory of \\server_RW\_RW_

C:\>net use /d \\server_rw\_RW_
\\server_rw\_RW_ was deleted successfully.

C:\>dir \\server_RW\_RW_
Access is denied.

(in realtà il secondo comando non dà access denied ma mostra il contenuto cache-ato del primo; se provi ad accedere però ad uno dei file o folder nella share ti becchi access denied e con explorer ti viene proposto l'inserimento delle credenziali)

Ma non è utile nel nostro discorso. 
Anche perché presuppone che da qualche parte ci sia uno script in cui si usa net use per connettere una risorsa, con le credenziali in CHIARO.

Questo l'ho scritto già sopra spiegando che la soluzione proposta nel post non è poi così banale.

   
45. FOLBlog
venerdì 25 marzo 2016 alle 3:55 PM - chrome 37.0.0.0 Android 4.4.2
   

Esattamente.
In effetti net use serve a "montare" la share
, per usare un termine in uso in ambiente Linux, anche senza associare una lettera.
Net use /d ha effetto solo sulle share montate con net use.
Non quando con Windows accedi ad una share della rete e ti vengono chieste le credenziali (che puoi memorizzare o meno nel gestore dì credenziali).
L'operazione di accesso apre una sessione con il server.
Non c'è modo di chiudere quella sessione con il comando net.
Invece è possibile utilizzare l'alias della share per poter accedere con credenziali differenti.
Con quel trucco è possibile aprire dallo stesso client più sessioni contemporanee sullo stesso server (share) con credenziali differenti.

Infine, ho tentato di usare il comando net use in uno script da eseguire secondo una pianificazione e non ha funzionato, qualsiasi impostazione usassi (mi sono limitato a tentare l'operazione con Windows 8.1 professional): il comando viene ignorato. E solo il comando net use tra tutti quelli presenti nello script. 

   
46. Paperino
venerdì 25 marzo 2016 alle 7:35 PM - chrome 49.0.2623.75 OS X 10.11.3
   

I don't think so...

Cominciamo da capo (ovviamente Windows 7, server SMB Linux)

C:\>net use
New connections will be remembered.

There are no entries in the list.

Apriamo ora \\SERVER_RW\_RW_ con Explorer (e immancabile prompt delle credenziali), e...

C:\>net use
New connections will be remembered.

Status       Local     Remote                    Network
------------------------------------------------------------------------------
OK                     \\server_rw\_RW_          Microsoft Windows Network

The command completed successfully.

Ok. Adesso proviamo a fare net use /d: con la finestra di Explorer aperta:

C:\>net use /d \\server_RW\_RW_
There are open files and/or incomplete directory searches pending on the connection to \\server_RW\_RW_.

Is it OK to continue disconnecting and force them closed? (Y/N) [N]: Y
\\server_RW\_RW_ was deleted successfully.

C:\>klist purge
Current LogonId is 0:0xf607a
        Deleting all tickets:
        Ticket(s) purged!

(comando scoperto oggi, necessario per ripulire le credenziali kerberos cachate da explorer)

E a questo punto se provo ad accedere al server con explorer, mi appare di nuovo la finestra di autenticazione.
Se non si usa klist purge, explorer farà navigare con le credenziali in memoria e la sessione non risulterà su net use.

   
47. Paperino
venerdì 25 marzo 2016 alle 7:39 PM - chrome 49.0.2623.75 OS X 10.11.3
   

(dopo diversi esperimenti però, il tutto non risulta così affidabile)

   
48. Snake
venerdì 25 marzo 2016 alle 8:01 PM - chrome 49.0.2623.87 Windows 10
   

se invece di aprire "\\SERVER_RW\_RW_" apri direttamente "\\SERVER_RW\", funziona lo stesso?

Scoccerebbe in caso provare? (non ho un Win7 sottomano )

   
49. Paperino
venerdì 25 marzo 2016 alle 8:19 PM - chrome 49.0.2623.75 OS X 10.11.3
   

Mi mostra la lista delle share disponibili. Poi se cerco di entrare nel folder _RW_ mi chiede l'autenticazione.

   
50. Paperino
venerdì 25 marzo 2016 alle 8:51 PM - chrome 49.0.2623.75 OS X 10.11.3
   

Scoperta interessantissima: 

www.samba.org/samba/docs/using_samba/ch06.html

[global] netbios aliases = sales accounting admin include = /usr/local/samba/lib/smb.conf.%L
   
51. FOLBlog
venerdì 25 marzo 2016 alle 8:52 PM - chrome 49.0.2623.87 Windows unknown
   

In explorer:
\\192.168.1.116

Richiede credenziali; le inserisco senza memorizzarle.
Vedo l'elenco delle risorse condivise.

Do' il comando net use /D  \\192.168.1.116\IPC$
Esecuzione comando riuscita e non risulta nessuna sessione attiva.

In explorer:
\\192.168.1.116
Vedo l'elenco delle cartelle condivise senza che mi chieda le credenziali.

Il comando NET USE non mostra nessuna sessione.

Se ora tento di accedere ad una cartella condivisa (Download) , mi vengono richieste credenziali.

NET USE mostra la nuova sessione alla SHARE.

Do' il comando 

C:\Users\Enrico>net use /D \\192.168.1.116\Download
File aperti e/o ricerche di directory incomplete in sospeso sulla connessione a \\192.168.1.116\Download.

Continuare la disconnessione e la chiusura anomala? (S/N) [N]: s

Net use ora non mostra nessuna sessione attiva.
Eppure io continuo a poter accedere tranquillamente alla share senza ulteriori richieste di credenziali nonostante, in teoria, le connessioni siano state buttate giù.

Ergo, quel comando funziona solo se il server è Linux?

   
52. Paperino
venerdì 25 marzo 2016 alle 8:55 PM - chrome 49.0.2623.75 OS X 10.11.3
   

No, il fatto è che Explorer una volta autenticatosi si tiene da parte il ticket Kerberos. Se chiudi la finestra prima di fare net use /D il ticket pare venga scartato. Altrimenti si riconnette alla share senza creare una nuova sessione.

Ho avuto difficoltà a trovare un modo di far scartare il ticket di Explorer, anche con il comando klist purge (forse ci sono diversi livelli di caching?)

   
53. FOLBlog
venerdì 25 marzo 2016 alle 9:01 PM - chrome 49.0.2623.87 Windows unknown
   

Comunque, tanto rumore per nulla: l'implementazione con gli alias è la soluzione ideale.

Anche se si leggessero gli alias dai file HOSTS/LMHOSTS, da nessuna parte nel sono memorizzate le credenziali di accesso con diritti RW (tranne che all'interno del programma di backup).
Perciò....ransomware si attacca.

Ora sto mettendo a punto una strategia per rendere una cartella locale accessibile in sola lettura dall'utente locale (o del dominio) ma accessibile totalmente dal programma di backup.
Dovrebbe essere più semplice.
Se si è in dominio, basta configurare un utente del dominio che risulta l'esecutore della procedura di backup pianificata ed attribuire a tutti gli altri utenti/gruppi diritti RO.

Se il PC è utilizzato solo da utenti locali, basta creare un utente ad hoc, attribuirgli opportunamente diritti di accesso alla cartella interessata e poi, eventualmente, nasconderlo dalla videata di logon, in modo che non compaia tra gli utenti che possono effettuare il logon.
Agli altri utenti locali solo diritti RO.

Provo, vedo se fila tutto liscio  e vi fo sapere

   
54. FOLBlog
venerdì 25 marzo 2016 alle 9:08 PM - chrome 49.0.2623.87 Windows unknown
   

No, il fatto è che Explorer una volta autenticatosi si tiene da parte il ticket Kerberos. Se chiudi la finestra prima di fare net use /D il ticket pare venga scartato. Altrimenti si riconnette alla share senza creare una nuova sessione.

Mah...utile, forse, se ti connetti ad una rete con il WiFi...

   
55. Paperino
venerdì 25 marzo 2016 alle 9:52 PM - chrome 49.0.2623.75 OS X 10.11.3
   

Comunque, tanto rumore per nulla: l'implementazione con gli alias è la soluzione ideale.

Concordo, era più che altro per capire meglio la questione.

Io sono riuscito a semplificare ulteriormente grazie al comando di samba include e alla sostituzione %L. Bisogna però forzare il server a rispondere alla porta 139 (anziché quella di default, 445).

Questo significa che ciascun server virtuale può avere una configurazione diversa, e quindi ho potuto separare la share RW da quelle sola lettura, quindi anche accidentalmente non è possibile invertire le credenziali.

Certo che SAMBA su Linux, con tutte le permutazioni e configurazioni possibili, è mostruoso rispetto a quello che si può fare con Windows. 

   
[ Pagina 1 di 2  - più vecchi ]
Lascia un commento:
Commento: (clicca su questo link per gli smiley supportati; regole di ingaggio per i commenti)
(opzionale, per il Gravatar)