[Ninux-Wireless] Risultati smanettamento di ieri al Giovedì Nerd a Roma

leonardo mail a leonardo.ma
Mar 24 Set 2013 14:43:42 CEST


On 09/20/2013 07:13 PM, Nemesis wrote:
> 
> Mi sembra alquanto limitante per un software che mira ad essere
> flessibilee configurabile ed utilizzato da molte realtà. Io ad esempio
> lo sto già utilizzando a lavoro per alcune coseche non c'entrano nulla
> con ninux e questo mi da la possibilità di lavorarci di più.

Se sviluppi cercando di mantere un occhio di riguardo per la sicurezza,
ti devi sempre immaginare gli scenari problematici. Ad esempio, se te
salvi le credenziali in chiaro e qualcuno entra nel tuo server (o trova
una vulnerabilità nella tua applicazione) ha in mano tutte le password
di tutti gli utenti che l'hanno salvata. Considerando che spesso la
gente ri-usa le password, rischi di essere un single point of failure
che può portare molti danni e molti utenti incazzati.

>   * poter disabilitare lo storage delle credenziali da configurazione
>   * cifrare le pwd con un algoritmo asimmetrico e rendere impossibile la
>     decrittazione via interfaccia web

Se chi ti attacca ha accesso al server non serve, la chiave privata deve
stare sul server, altrimenti non la puoi utilizzare. L'attaccante si
prende la chiave e decifra le password. Se salvi le password altrove
devi comunque avere un modo per richiederle quando servono, e lo può
fare anche l'attaccante.

Quindi, qualsiasi cosa tu voglia fare, è insicuro salvare le password
in chiaro, o cifrate. Al limite hashate (con salt), ma cosi' non le puoi
utilizzare come vuoi te.

>   * inseriresolo credenziali readonly
>   * usare SNMP, MUNIN, oppure un API HTTP readonly
>   * far salvare la chiave SSH del server dentro al device, così come fa
>     AirControl ad esempio

Io non vedo una soluzione pulita che non coinvolga un po' di
configurazione sui nodi. Se puoi fare qualche assunzione su cosa è
installato sui nodi, è tutto più facile (a partire da quelle soluzioni
che hai citato).
Se non puoi, allora la cosa migliore è che ti faccia dare la password
una volta sola, non la salvi, la usi solo per connetterti con ssh e far
girare uno script di configurazione che attiva uno dei servizi, o crea
un utente con pochi privilegi e ci installa la tua chiave pubblica.
Questo rende la vita più difficile ad un attaccante pigro ed evita che
ti salvi nel db la password di gmail degli utenti. Ma sinceramente,
forse è meglio se nella pagina di configurazione di un nodo metti una
descrizione passo passo di come attivare gli stessi servizi, lo fai fare
all'utente e poi ti ci colleghi e verifichi che sia andato tutto bene.
Oppure, se è solo per la configurazione iniziale, dai direttamente uno
script agli utenti da copia&incollare su una shell (o da scaricare con
wget) che estrae i dati in un file di testo e ti fai uploadare il file.

> PS:per alcune funzionalità mi sto ispirando ad Ubiquiti AirControl, in
> quanto lo trovo uno strumento davvero grandioso, peccato che funzioni
> solo con ubiquiti e che sia centralizzato e proprietario

Però proprio il fatto che sia centralizzato e proprietario, lo rende
almeno in apparenza meno vulnerabile, perchè lavora in un contesto molto
più controllato.

my 2 € cent.
leonardo.


-- 
www.leonardo.ma / twitter: @leobowski
gpg Key ID: 52FDAD1E



Maggiori informazioni sulla lista Wireless