Firmware fog per Dreambox
… e altro
Autore: fog (alias fog@infosat sui forums di www.info-sat.org). Tutti i diritti riservati. Per qualsiasi ridistribuzione o uso del contenuto del presente documento
inviare una richiesta a [email protected].
Responsabilità: L'autore declina ogni responsabilità per qualsiasi danno imputabile ad inesattezze o errori contenuti nella presente guida o nel software (firmware) per Dreambox distribuito insieme alla presente. Questa è più o meno la
formula di rito che resta comunque valida. Nella sostanza, ho realizzato questo
lavoro per hobby e scopi personali e lo rendo pubblico solo perché penso che
forse possa essere di spunto o di aiuto per altri che come me condividono la
passione per il ricevitore Dreambox ed il software che lo fa funzionare, molto è
inoltre lasciato alle vostre capacità e naturalmente, buon senso.
Firmware fog per Dreambox 7000
Indice Generale
1 Introduzione....................................................................................................5
1.1 A chi non è Rivolta Questa Immagine.....................................................6
1.2 A chi è Rivolta Questa Immagine?..........................................................6
1.3 Linee Guida.............................................................................................8
1.3.1 Considerazioni Generali sulla Sicurezza..........................................8
1.3.2 Livello di Sicurezza Presente nel Firmware....................................11
1.3.3 Tipo d'Uso Previsto.......................................................................12
2 Cosa c’è Sotto al Cofano.............................................................................15
2.1 Cambiamenti al Software ‘Standard’....................................................15
2.1.1 Kernel Linux...................................................................................15
2.1.2 Enigma...........................................................................................15
2.1.3 Scripts di Init..................................................................................16
2.1.4 Utenti, Gruppi Preimpostati e Passwords......................................18
2.1.5 Software Busybox..........................................................................20
2.1.6 Shadow Passwords.......................................................................21
2.1.7 Software di Rete Avviato da inetd..................................................21
2.1.7.1 Server Telnet...........................................................................21
2.1.7.2 Server FTP Vsftpd...................................................................21
2.1.8 Software di Rete Standalone Avviato da Enigma..........................23
2.1.8.1 Software Samba.....................................................................23
2.1.8.2 Interfaccia Web di Enigma......................................................25
2.2 Principale Software Extra Contenuto nell'Immagine.............................26
2.2.1 Software Sudo...............................................................................26
2.2.2 Editor Nano....................................................................................27
2.2.3 Libreria OpenSSL...........................................................................27
2.2.4 Software OpenSSH (Portable).......................................................27
2.2.5 Software Stunnel............................................................................31
2.2.6 Software TCP Wrappers................................................................32
2.2.7 Libreria Berkeley DB......................................................................34
2.2.8 Software Netatalk..........................................................................34
3 Suggerimenti................................................................................................37
iii
Firmware fog per Dreambox 7000
3.1 Dove Installare l’Immagine....................................................................37
3.2 Appena Installata ’Immagine.................................................................37
3.3 Creazione di Directories e Installazione di files.....................................38
3.3.1 Installazione di Plug-ins, Settings e Skins di Enigma....................38
3.3.2 Installazioni in Aree Protette...........................................................38
3.3.3 Installazione di Emulatori CA (Emus).............................................39
3.4 Creazione di Nuovi Utenti e Gruppi.......................................................39
3.4.1 Creazione delle Home Directories..................................................40
3.4.2 Esempio di Creazione di Un’utente................................................40
4 Possibili Evoluzioni.......................................................................................43
iv
Firmware fog per Dreambox 7000
1 Introduzione
Questo firmware, espressamente realizzato per il Dreambox 7000, nasce inizialmente per gioco e per sperimentare e mettere un po’ ‘sotto torchio’ su Mac
OS X il cross developement kit del Dreambox. Recentemente sono infatti riuscito, con opportune modifiche a diversi files di configurazione ed ai patches di
Linux distribuiti con il CVS, a far funzionare il CDK anche sotto Mac OS X. Ho
già postato tempo fa su www.info-sat.org le modifiche e le istruzioni relative
alla compilazione su Mac OS X.
Dopo i primi tentativi, hanno preso forma quelli che poi sarebbero diventati gli
obiettivi principali di questa realizzazione e tra loro correlati:
1) Fornire un'immagine software che, nella sua configurazione di default
fosse sufficientemente sicura se paragonata agli standard, presi ad
esempio, ai quali ci hanno da tempo abituato le diverse distribuzioni
Linux, Unix e non ultimo Mac OS X.
2) Riesaminare il software di rete normalmente fornito con il Dreambox (in
primo luogo i servers FTP e Samba) in modo da fornire per esso una configurazione di default che tenesse in considerazione gli obiettivi definiti al
punto 1 ed al tempo stesso ne sfruttasse meglio le potenzialità.
3) Aggiungere i servizi di rete offerti dal pacchetto Netatalk, in particolare il
server AFP (Apple Filing Protocol) configurato in modo da offrire i propri
servizi sia attraverso TCP/IP che attraverso il protocollo Appletalk (il protocollo di rete legacy di Apple e che consente il browsing dei servers di
rete AFP sui computer clients). AFP è ancora il metodo di condivisione
più usato su Mac OS X e spero che la scelta di includere Netatalk in questa immagine possa fare contenti gli utenti Mac. Il protocollo Appletalk su
Mac OS X è stato affiancato dal più recente Rendezvous/Bonjour che offre servizi simili su TCP/IP per quanto riguarda il browsing dei servizi di
rete. Sulle versioni più recenti di Mac OS X Appletalk può essere usato
solo per le funzioni di browsing dei servers di rete (la connessione al server e il trasferimento dei files avviene sempre mediante connessioni
TCP/IP), sulle versioni precedenti dell'OS del Mac, Appletalk può (in alcuni casi deve, come nella versioni di Mac OS precedenti la 8) anche essere impiegato come protocollo di trasporto (anche se le prestazioni sono
nettamente inferiori a quelle ottenibili via TCP/IP). Le ultime osservazioni
solo per sottolineare che potrete connettervi al vostro Dreambox anche
con computer Mac vecchi di una quindicina d'anni e anche più.
Fatta questa premessa è opportuno sottolineare a chi può interessare questo
firmware, anche per non generare false aspettative.
5
Firmware fog per Dreambox 7000
1.1 A chi non è Rivolta Questa Immagine
È doveroso evidenziare da subito che se siete alla ricerca dell'ultimo grido in
fatto di miglioramenti dell'interfaccia grafica di Enigma e relativi pugins lasciate
perdere e non provate neppure ad installare questa immagine perché ne rimarrete delusi. Detto in altri termini niente nuovi plugins, emu, skins, superpannelli
di controllo od altre modifiche ad hoc al software Enigma scaricabile dal CVS.
Le motivazioni di questo fatto sono principalmente due e tra loro correlate.
La prima è che sto muovendo i primi passi nella programmazione per il Dreambox ed al momento non ho assolutamente intenzione né la possibilità di competere con chi da anni ha accumulato una notevole esperienza nella programmazione di Enigma ed è stato capace di fornire miglioramenti al software (nella
forma di plugins o di modifiche al software principale) senza i quali la passione
per il Dreambox si sarebbe spenta da tempo in molti di noi visto che le speranze iniziali riposte nella casa madre sono state, nel corso degli anni, in gran parte disattese.
La seconda ragione è che, se anche avessi tempi e mezzi per fare una rivoluzione, probabilmente le prime attenzioni si rivolgerebbero in ogni caso alla costruzione di una base più solida e sicura del software installato.
1.2 A chi è Rivolta Questa Immagine?
Le osservazioni precedenti rispondono già in parte a questa domanda. Chiunque si sia già posto il problema di come rendere più sicuro il Dreambox potrà
trovare utile avere a disposizione questo firmware sia come spunto per 'fortificare' quello a lui preferito, attraverso la lettura dei vari files di configurazione e
scripts di init in essa contenuti sia come immagine base di partenza, installata su pen USB o Hard disc da arricchire con i plugins indispensabili (e purtroppo in essa mancanti) e quelli preferiti. Non nascondo che entrambi gli approcci
presentano dei limiti oggettivi e/o delle difficoltà anche legate alle capacità e
alle conoscenze della singola persona.
Nel primo caso può non essere sufficiente la semplice copiatura dei files binari
e di configurazione nelle posizioni corrispondenti dell'immagine preferita. Il
CDK infatti, per salvare spazio, al momento di creazione dell'immagine finale,
installa le librerie eliminando tutti i 'simboli' e le funzioni non usate dai vari binaries installati. Ad esempio copiare semplicemente sudo o afpd e relativa libreria libatalk.so potrebbe non funzionare in quanto tali software potrebbero avere bisogno di funzioni presenti in altre librerie (libc.so ad esempio)
che sull'immagine scelta come base d'installazione potrebbero essere non presenti. La soluzione migliore, in questo caso, è forse quella di copiare in blocco
il software di questa immagine in una directory dedicata su pen USB o Hard
disc, modificare gli scripts di init (prendendo come riferimento quelli presenti
nella mia immagine) impostando la variabile d'ambiente LD_LIBRARY_PATH in
modo opportuno, rigenerare i links necessari ai vari files di configurazione, al
6
Firmware fog per Dreambox 7000
file passwd e shadow nelle directories originali /etc e /var/etc, ecc. ecc.
ecc. Insomma, una soluzione per utenti esperti e disposti a perdere un po' di
tempo.
Nel secondo caso (personalizzazione di questa immagine) i limiti sono imposti
dal modo stesso in cui il software Enigma si è evoluto (o non evoluto?) nel corso del tempo. Se anche da un lato offre discrete possibilità di personalizzazione ed addizione di nuove funzionalità (skins e plugins) la struttura principale risulta poco modulare e strutturata. A tale proposito e solo a titolo di esempio
basti pensare al fatto che il percorso per le registrazioni è codificato direttamente all'interno del codice (che mi ricordi esiste appena una direttiva #define nei sorgenti c++) oppure al fatto che la rete venga configurata in un paio di
punti all'interno del codice (nei quali viene avviato anche Samba se impostato
nelle preferenze dall’utente) ed anche in questo caso i nomi dei comandi sono
addirittura hard coded. Che dire poi della scelta di avviare Samba con Enigma
e lasciare i servers FTP e Telnet alla configurazione manuale di inetd?
Quello che voglio dire è che manca totalmente in Enigma una visione coerente
di come gestire la rete e i relativi software e meno che mai Enigma offre un modello e facilities per il programmatore che voglia aggiungere nuove funzionalità.
Tutto questo è, secondo il mio parere responsabilità della casa madre che
poco ha investito nel corso degli anni nel software, che in fondo è il vestito che
rende il suo prodotto un prodotto di successo. Tutto questo ha costretto i diversi sviluppatori indipendenti di software per Dreambox, che via via si sono
susseguiti lasciando tracce più o meno profonde, a reinventare continuamente
la ruota per implementare particolari funzionalità che fossero in accordo con la
loro particolare visione di cosa doveva fare il Dreambox.
Una responsabilità dell'attuale situazione di stallo però l'abbiamo anche noi
(utenti e sviluppatori/assemblatori indipendenti) che, invece di unire le forze abbiamo incitato una sorta di 'gara all'immagine più bella e più stabile'. La situazione attuale è sotto gli occhi di tutti, i limiti fisici (grandezza RAM e FLASH)
del Dreambox sono stati da tempo raggiunti e l'assemblaggio di un un immagine spesso si limita alla scelta di quale software includere o meno. Niente o
quasi, per continuare con gli esempi, è stato fatto per facilitare il programmatore o anche l'utente esperto per la realizzazione in un modo standard di pacchetti software da installare su hard disc o dispositivi di memoria USB. É evidente che da utente Mac ho il palato esigente, tuttavia non pretendo l'esistenza sul Dreambox di Frameworks od un livello di astrazione paragonabili a quelli
di questo sistema operativo, ma tra il 'nulla' e la 'quasi' perfezione ed anche
considerando le potenzialità effettive della macchina Dreambox (non paragonabili a quelle dei PC più recenti) qualcosa deve pur esserci.
Fine della lunga divagazione, scusate dello sfogo, ma alcuni di questi pensieri
mi pesano da diverso tempo.
7
Firmware fog per Dreambox 7000
1.3 Linee Guida
In questa sezione desidero soffermarmi più da vicino sulle considerazioni che
mi hanno guidato nella realizzazione di questa immagine che, come detto precedentemente, ha lo scopo di rendere il nostro Dreambox un po’ più sicuro.
Scusate se alcune divagazioni possono sembrare sproporzionate all'argomento trattato, anché perché sicuramente lo sono.
Ci siamo spesso incontrati sui forum di http://www.info-sat.org/ (sul quale questa immagine per il Dreambox dovrebbe essere resa disponibile) parlando degli
argomenti più disparati e forse questa è un'occasione per conoscerci meglio.
Le persone con cui ho avuto l'onore di scambiare opinioni sui vari threads probabilmente mi conoscono già come un gran chiaccherone e non voglio smentirmi. Di solito osservo ma quando parto a scrivere è difficile fermarmi.
1.3.1 Considerazioni Generali sulla Sicurezza
Il computer più sicuro è quello che rimane sempre spento e forse neanche
quello perché può sempre arrivare la ‘Banda Bassotti’.
Già questa premessa fa intuire che l'arte di assemblare hardware e software sicuro e configurare quest'ultimo in modo da garantire una sicurezza accettabile,
non è di quelle facili.
Il tema della sicurezza coinvolge inoltre aspetti tecnici e teorici che richiedono
conoscenze molto specialistiche, basti solo pensare alle conoscenze matematiche richieste che stanno dietro alle ricerche avanzate sulla crittografia, sulla
quale sono basati buona parte dei metodi di protezione usati dai vari software.
La crittografia, tuttavia, non esaurisce in alcun modo il tema della sicurezza
che, anche se riferita al solo settore dei computer, risulta piuttosto dall'intreccio complicato di diverse discipline. Con riferimento ai computer, ma credo che
l'affermazione valga anche in senso più generale, la sicurezza è allo stesso
tempo un bersaglio in movimento ed una entità di grandezza non misurabile in
senso assoluto. In movimento perché anche partendo da una condizione di sicurezza giudicata inizialmente accettabile non è detto che questa rimanga tale,
senza ulteriori e continui sforzi di miglioramento e di monitoraggio. Di grandezza non misurabile in senso assoluto perché, ovviamente, il grado di sicurezza
giudicato accettabile è sempre il risultato di compromessi e varia in funzione
del tipo di servizi che si vuole offrire, della sensibilità dei dati presenti e non ultimo, in un mondo collegato da reti di tutti i tipi, della possibilità che ha il nostro
sistema (computer) d'interagire con altri, potendo, nei fatti, alterare lo stato di
sicurezza di questi ultimi (l'esempio più lampante è dato dai virus anche se esistono esempi molto più sottili).
Un'aspetto della sicurezza, che in alcuni casi diventa paradossale, è che questa è più facile da implementare in una serie di casi estremi e a due a due opposti e che dal punto di vista concettuale corrispondono a situazioni del tipo 'o
tutto o nulla'. Ad esempio è molto più facile raggiungere una sicurezza accetta8
Firmware fog per Dreambox 7000
bile nei due casi limite:
1) Un computer la cui unica funzione sia quella di offrire un servizio al mondo intero (ad esempio un server FTP con accesso anonimo).
2) Un computer usato per memorizzare dati sensibili ma che non debba fornire alcun servizio al mondo esterno.
Naturalmente, negli esempi riportati, ho fatto l'ipotesi che il software impiegato
fosse ideale, cioè privo di bugs o crepe nella sua implementazione. La situazione reale è ben diversa, con frequenza sempre maggiore, infatti, assistiamo al rilascio di aggiornamenti software il cui solo scopo è quello di tappare falle o riparare a bugs che si ripercuotono sulla sicurezza stessa. Ancora un argomento
a favore della sicurezza vista come bersaglio mobile e in continua evoluzione.
Per tornare al discorso principale: sono sempre le situazioni di mezzo che presentano le maggiori difficoltà, e tutte le situazioni reali sono situazioni di mezzo.
Potrei continuare con diversi altri esempi ma credo sia sufficiente.
Ho espresso il concetto solo per evidenziare che i concetti di 'indipendenza' /
'disomogeneità' (che si possono riassumere con il termine di ortogonalità termine sempre più in voga per esprimere tali concetti e che non a caso hanno
una forte similitudine con il concetto di otrogonalità in matematica) intesi
come sussistenza d'indipendenza tra determinati fattori o scarsa sovrapposizione tra determinate funzioni, giocano un ruolo importante sia per quanto riguarda l'analisi dello stato di sicurezza di un determinato sistema sia per quanto riguarda l'implementazione di un determinato livello di sicurezza in casi concreti. Non poteva essere altrimenti, visto che in ogni situazione reale complessa ci comportiamo più o meno nello stesso modo: cerchiamo di scomporla o
rappresentarla nel minor numero di aspetti indipendenti. Il concetto di ortogonalità, espresso in questi termini, può sembrare banale, ma sono sempre le
cose banali che nascondono i significati più profondi. Qualcuno potrà anche
obiettare che esiste anche l'intuito, che tutto coglie in un solo pensiero, ma un
genio senza un esercito di raziocinanti costretti a usare principi d'indipendenza per scomporre, inquadrare, classificare … una teoria, un'equazione … probabilmente rimarrebbe un genio incompreso.
Pur restando ai piani alti, è bene tornare al tema della sicurezza, vedo infatti già
del fumo bianco salire dalle parti basse di qualche lettore.
Come detto, il concetto di ortogonalità, per quanto riguarda la sicurezza, è un
valido aiuto sia nell'analisi di un sistema esistente che nella pianificazione di
uno da costruire. Questo ultimo aspetto è quello che ci riguarda più da vicino e
costituisce un criterio essenziale per:
1) Pianificare i servizi che desideriamo implementare sul nostro sistema
classificandoli secondo un criterio di ortogonalità.
2) Per ognuno dei servizi stabiliti al punto precedente, stabilire il grado di si9
Firmware fog per Dreambox 7000
curezza necessario per ognuno di essi e quindi individuare gli strumenti
necessari per raggiungere tale grado di sicurezza.
Per quanto riguarda il punto 1, è importante sottolineare che, quanti più servizi
tra loro indipendenti/disomogenei (ortogonali) intendiamo implementare, tanto
più difficile e delicata sarà la fase descritta al punto 2. A tale proposito basti
pensare che a nessuno verrebbe in mente (almeno spero di no!) di implementare un servizio di home-banking su una macchina che contemporaneamente offre un servizio di libero accesso attraverso qualche protocollo di condivisione.
Per quanto riguarda il punto 2 è invece importante sottolineare che quanto
maggiore è l’indipendenza (ortogonalità) tra i vari strumenti individuati per raggiungere il grado di sicurezza desiderato, tanto più facile sarà mantenere tale livello di sicurezza nel corso del tempo o incrementare il livello di sicurezza qualora ce ne fosse bisogno. A tale proposito, non a caso ho parlato di sistema e
non di macchina o computer in quanto un fattore, che aumenta notevolmente
l’indipendenza tra i vari sistemi usati per raggiungere il livello di sicurezza desiderato, è proprio quello di implementare tali strumenti su macchine o computer
differenti da quella che offre i servizi. Un'esempio per tutti di tale fatto sono i
routers e i firewalls.
È per considerazioni generali di questo tipo che un po' storco il naso quando,
tra le funzionalità elencate in un nuovo firmware per Dreambox, vedo quelle di
firewall (e magari anche di router! Per non parlare poi delle immagini che offrono Open VPN tra il software installato!). E questo anche senza considerare che
un firewall/router sul Dreambox:
1) È come mettere il carro davanti ai buoi se prima non si è posto rimedio
agli aspetti di 'base' della sicurezza come ho cercato di fare realizzando
questa immagine.
2) Può costituire un sovraccarico notevole per una macchina destinata ad
uno scopo totalmente diverso.
3) Può generare false aspettative nell'utente, che potrebbe arrivare a pensare di affidare ad esso compiti delicati per i quali non è assolutamente
adeguato, e concentrare in esso funzionalità di sicurezza non solo per i
servizi residenti sul Dreambox ma anche per l'intera rete domestica, trasformandolo nell'anello più debole e fragile dell'intera catena (e con questo torniamo al discorso sull'ortogonalità).
Meglio scendere di piano, perché il fumo che vedo ora è diventato nero! Questa lunga introduzione mi serve infatti per dire due cose:
1) Con questa immagine il Dreambox non diventa Fort Knox;
2) La configurazione dei vari software presenti nell'immagine è stata fatta
pensando ad un uso privato e personale degli stessi.
10
Firmware fog per Dreambox 7000
Questi due aspetti sono esaminati nelle due sezioni seguenti.
1.3.2 Livello di Sicurezza Presente nel Firmware
A questa domanda, posta in termini così generali (i titoli di una sezione hanno
le loro esigenze), non so proprio come rispondere, a meno di non continuare
con altre pagine di dissertazioni, che a questo punto sarebbero fuori luogo, anche per me.
In termini molto più semplici è forse meglio riassumere quello che ho cercato di
fare con questa realizzazione al fine di garantire un livello di sicurezza accettabile.
D'accordo, ma cosa vuol dire accettabile?
Accettabile vuol dire introdurre una serie di strumenti universalmente riconosciuti come idoonei per fornire una sicurezza accettabile per le situazioni d'uso
previste per la nostra macchina. Sembra il cane che si morde la coda o il classico dilemma dell'uovo e della gallina ed in un certo senso è proprio così. Forse è meglio passare direttamente all'esemplificazione.
Molti di noi, almeno quelli abituati ad usare un sistema Linux o UNIX, hanno dimestichezza con i tools fondamentali ed i criteri impiegati per ottenere la sicurezza di ‘base’ in una macchina multiutente basata su UNIX o ad esso ispirata.
Tools quali sudo, l'impostazione data dal meccanismo delle Shadow Passwords, la disabilitazione dell'utente root, … sono tutte cose che probabilmente conosciamo e che sui sistemi basati su UNIX sono presenti o impiegate da
parecchi anni come strumenti fondamentali su cui fondare la sicurezza di base.
Quello che ho cercato di fare è stato semplicemente dotare (o anche far emergere, visto che, ad esempio, le Shadow Passwords erano già supportate) il nostro Dreambox di questi strumenti o impostazioni, in modo da farlo assomigliare un po' di più, sul piano della sicurezza, ai cugini PC che usano un sistema
operativo basato su UNIX/Linux.
La domanda veramente sorprendente, quindi, è un'altra. Visto che fin dall'inizio
il Dreambox ha offerto servizi di rete (server FTP, interfaccia Web ecc.) che a
parer mio esigevano almeno una minima preoccupazione per l'aspetto sicurezza, come mai nessuno (che io sappia) lo ha fatto prima?
Il lavoro che ho fatto è stato senz'altro faticoso e a tratti noioso, ma non credo
assolutamente che possa essere classificato tra quelli ‘difficili’, anche considerando che ho fatto questo come hobby senza dedicargli il tempo pieno (a parte
la scrittura di questa introduzione … eh! eh!).
Quindi, se avete fiducia nell'efficacia dei metodi usati in questo firmware per
aggiungere sicurezza (che, ripeto, sono ormai divenuti uno standard), dovreste
considerare il livello di sicurezza raggiunto accettabile. So di finire ancora con
un giro di parole ma spero di essere stato capito.
Quanto detto vale per quanto riguarda la fiducia nei metodi e criteri generali
usati per aggiungere sicurezza. Vi è un'altro aspetto che spesso viene total11
Firmware fog per Dreambox 7000
mente sottovalutato ed è quello della fiducia implicitamente riposta sia nei
tools che implementano i criteri di sicurezza scelti sia più in generale, in tutto il
software che viene eseguito sulla macchina. A quest'aspetto ho già accennato
all'inizio di questa sezione. Merita tuttavia richiamarlo ancora perché è spesso
il più sottovalutato ed anche perché diversi software inclusi in questo firmware
(una discreta parte di quelli ‘standard’ ed ‘extra’ presenti nel CVS) sono un po'
datati. Non ho fatto una ricerca approfondita delle implicazioni che quest'aspetto può avere sulla sicurezza ed ho resistito alla tentazione di sostituire i
software già presenti nel CVS con versioni più recenti (in particolare Busybox,
Samba e OpenSSL) per due ragioni.
La prima e più ovvia ragione è che parte del lavoro era già stato fatto, mentre la
seconda è dovuta vincoli sulla dimensione finale dell’immagine. È regola comune infatti che il codice di un software cresca di dimensione nel corso della sua
evoluzione ed è assai probabile che se avessi seguito il percorso di un aggiornamento completo alle ultime versioni, avrei superato le dimensioni massime
consentite per un immagine firmware, dettate dalla dimensione della flash del
Dreambox 7000, visto che l’immagine attuale non supera questo limite per una
manciata di kB. Inoltre, come detto nell’ultima parte di questa guida, il software
e le configurazioni presenti in questa immagine costituiscono un primo esperimento di ‘fattibilità’, e si presterebbero meglio ad una distribuzione nella forma
di pacchetto da installare su un dispositivo di memoria USB o su hard disc.
1.3.3 Tipo d'Uso Previsto
I diversi servers presenti in questa immagine sono stati preconfigurati pensando ad un uso degli stessi di tipo privato e personale o da parte di utenti di fiducia su una rete locale o anche attraverso internet per mezzo degli strumenti
forniti (il server SSH e Stunnel). Devo inoltre sottolineare che, qualora il Dreambox sia collegato in una rete permanentemente connessa ad Internet (caso ormai frequente) tramite un router, ritengo indispensabile, per completare il quadro di sicurezza preimpostato, che quest'ultimo o altro dispositivo svolga anche le funzioni di firewall per la rete. Credo che l'ultimo requisito sia frequentemente rispettato visto che, nella maggioranza dei casi, la connessione permanente ad internet viene realizzata tramite ADSL per mezzo di router/firewall
provvisti di modem ADSL o porta ethernet connessa ad un modem ADSL.
Vista la disponibilità di hard disc dalla capacità ormai impressionante e dal
prezzo abbordabile, con l'aggiunta di qualche utente ed eventualmente gruppo
(le linee guida per la loro creazione sono date in seguito), il Dreambox potrebbe
diventare un piccolo NAS per scopi personali. Sicuramente mancano tools che
ne agevolino la configurazione ed altri che completino ulteriormente il quadro
(sto pensando al demone syslogd e ad una configurazione ponderata dei
logs di sistema), tuttavia, per esigenze personali e non esagerate, la sicurezza
offerta dovrebbe essere sufficiente.
Se avete intenzione di modificare le impostazioni iniziali per destinare i servers
ad un uso diverso da quello sopra descritto (ad esempio accesso incondizio12
Firmware fog per Dreambox 7000
nato o ad utenti non di fiducia al server FTP) siete sulle vostre gambe. Mi raccomando solo, in questo caso, di leggere attentamente i manuali di configurazione dei vari servers e soprattutto (vedi discorsi sull'ortogonalità) di non mescolare tipi di servizi, ad esempio usare il Dreambox sia come NAS personale
che come server per un accesso meno ristretto. Un'ultima raccomandazione,
per il caso in cui vogliate configurare un'accesso meno ristretto ai servers, è
quella di creare una DMZ nella quale collocare il Dreambox (esistono ormai
router/firewall con DMZ a prezzi non esagerati).
Poiché ho considerato la presenza di un firewall come prerequisito per il completamento del quadro di sicurezza, nelle spiegazioni che seguono, relative al
software installato, dò qualche consiglio sulle configurazioni più opportune per
questo dispositivo.
13
Firmware fog per Dreambox 7000
2 Cosa c’è Sotto al Cofano
Qualcosa deve pur esserci altrimenti che scrivo a fare?
2.1 Cambiamenti al Software ‘Standard’
Il progetto di fornire una base software più sicura unitamente all'aggiunta di
software extra di grosso calibro si è rivelato subito più impegnativo di quanto
potesse sembrare all'inizio. Non era infatti sufficiente modificare qualche file di
configurazione, compilare ed installare il software extra per raggiungere l'obiettivo. È stata necessaria innanzitutto un'analisi preliminare del software di base
normalmente fornito con il Dreambox per valutare come questo rispondesse
sia alle richieste di sicurezza sia alle necessità dei pacchetti software aggiuntivi. Riporto di seguito i principali cambiamenti effettuati al software di base sia
in fase di compilazione che in quella di configurazione/installazione
2.1.1 Kernel Linux
Versione: 2.6.9 (?)
Links: http://www.kernel.org/
Non a caso ho inserito un punto interrogativo tra parentesi nel numero di versione del kernel di Linux. Infatti se anche è vero che i sorgenti di base corrisondono a questa versione è altrettanto vero che questi sono 'pesantemente' modificati mediante patches ricavati per la maggior parte da versioni successive
del kernel (parliamo di qulche centinaio di files modificati) ed in parte minore
corrispondenti a modifiche 'ad hoc' per l'hardware del Dreambox. Queste ultime corrisspondono a loro volta, in discreta parte, alla configurazione del kernel, eseguita in batch prima della compilazionene del kernel stesso. Secondo il
mio modo di vedere, in questa situazione, è difficile attribuire una corrispondenza del numero di versione del kernel del Dreambox con quelle ufficiali e disponibili nel source tree di riferimento del kernel di Linux.
Rispetto alla versione normalmente compilata con i firmware ufficiali, Ho aggiunto i moduli di rete necessarri per il supporto del protocollo AppleTalk. I moduli sono inseriti nel corretto ordine in fase di avvio della macchina (script
start_daemon in /etc/init.d).
2.1.2 Enigma
Versione: CVS Ottobre 2006
Links: http://cvs.tuxbox.org/
Per le ragioni esposte precedentemente, Enigma non ha subito modifiche,
sono stato anzi costretto, per i vincoli imposti sulla dimensione finale dell'immagine, ad eliminare tutti i plugins e gli skins extra (ad eccezione dello skin
Small usato come default) normalmente presenti anche nelle immagini ufficiali.
15
Firmware fog per Dreambox 7000
2.1.3 Scripts di Init
Poiché l'interfaccia ethernet viene attivata e configurata da Enigma nella fase di
avvio, senza possibilità, da parte di altro software residente sulla macchina di
modificare tale comportamento, ho dovuto modificare in modo sostanziale (la
modifica stessa si limita a poche righe ma il cambiamento è comunque sostanziale) lo script di init rcS in modo da aggirare tale comportamento. Nelle immagini ufficiali (ed anche in tutte quelle di sviluppatori indipendenti che ho avuto modo di verificare) normalmente lo script principale di avvio rcS termina in
un loop che interroga con cadenza regolare lo stato di Enigma circa le azioni
da intraprendere. A seconda delle scelte effettuate dall'utente tramite il telecomando (o anche tramite l'interfaccia web di Enigma), il loop termina in uno dei
seguenti modi:
1) arresta la macchina;
2) riavvia la macchina;
3) riavvia la macchina eseguendo il comando /bin/flashtool a seguito
dell'installazione di un nuovo firmware ;
4) riavvia il demone dccamd.
I file binari flashtool e ddcamd fanno parte del software fornito dalla Dream
Multimedia in forma binaria dei quali di più non sono in grado di dire se non del
fatto che, dal nome si può supporre che dccamd sia il demone che si occupa
della codifica dreamcrypt. Anche se con l'intuito era facile supporre che flashtool veniva eseguito a seguito di una nuova installazione firmware, ho impiegato un po' di tempo a recuperare il codice di uscita da Enigma quando viene eseguito un aggiornamento del software in flash, ancora una volta a conferma della scarsa linearità e intricatezza del software Enigma che inoltre è praticamente sprovvisto di documentazione o codice ben commentato.
In ogni modo, quello che è importante osservare ai nostri fini è che, per la presenza del loop ora descritto, lo script rcS resta in esecuzione per tutto il tempo in cui è in esecuzione Enigma ed obbiga ad eseguire prima di esso tutti gli
altri comandi o scripts aggiuntivi (compreso lo script /var/etc/init eventualmente presente, normalmente usato per 'customizzare' il boot del Dreambox da parte dell'utente). Questo fatto crea un problema per l'avvio di tutti i demoni di rete che hanno bisogno di conoscere lo stato e l'indirizzo IP dell'interfaccia ethernet, in quanto l'interfaccia è attivata da Enigma stessa in funzione
delle impostazioni fissate dall'utente.
Ho risolto il problema creando uno script (start_daemons) lanciato in background da rcS che monitora lo stato dell'interfaccia ethernet e non appena rileva che è attiva e configurata con un indirizzo IP lancia i servers facenti parte
del pacchetto. Oltre a questo lo script start_daemons esegue anche le seguenti operazioni:
16
Firmware fog per Dreambox 7000
1) Imposta ‘una tantum’ i permessi su /var/tuxbox in modo tale che il
gruppo admin abbia i permessi in lettura e scrittura (l'impostazione è
controllata dall'esistenza o meno del file nascosto .DreamboxSetupDone e per le ragioni di questa impostazione vedi la sezione successiva riguardo gli utenti preimpostati sul sistema)
2) Ad ogni avvio imposta i permessi su /tmp in modo tale che il gruppo admin abbia i permessi in lettura e scrittura (per i motivi vedi anche in questo caso la sezione successiva riguardo gli utenti preimpostati sul sistema) ed in modo adeguato i permessi su importanti files per la sicurezza.
3) Carica i moduli del kernel necessari per il funzionamento di AppleTalk.
4) Prima dell'avvio dei servers di rete esegue una modifica al volo dei files
di configurazione /var/etc/hosts e /var/etc/smb.conf per il corretto funzionamento di Netatalk e Samba e forza Samba (che eventualmente è stato già avviato da Enigma) a ricaricare la configurazione.
Ho trovato quest'ultimo passo necessario affinché funzionasse (almeno su
Mac) il browsing delle condivisioni di rete, sia quelle attivate da Samba che
quelle attivate da Netatalk. Osservo infatti che fino ad ora, con le immagini da
me provate e con Mac OS X come client, il browsing Samba non ha mai funzionato, in altri termini non è mai apparso il nome del Dreambox nella cartella
Network del Mac. Un ruolo essenziale è giocato dal file /var/etc/hosts che,
nella configurazione di default è impostato in modo scorretto, dal momento
che sia al nome localhost che al nome Dreambox è associato l'indirizzo dell'interfaccia di loopback 127.0.0.1. Ad ogni modo lo script start_daemons
dovrebbe essere ben commentato e per ulteriori dettagli basta leggerlo.
Anche il loop finale che lancia Enigma e precedentemente descritto è stato incorporato in uno script a parte (start_enigma) lanciato in background dallo
script principale rcS subito prima di start_daemons. Questa modifica forse
non era proprio necessaria (lo script start_daemons dovrebbe funzionare anche se lanciato prima del loop finale in rcS), ma avendo ormai imboccato una
strada ho cercato, anche per ragioni estetiche, di perseguirla fino in fondo. La
logica vorrebbe infatti che, anche se alcuni scripts sono lanciati in background,
la sequenza finale di avvio del Dreambox fosse: avvia Enigma (che imposta la
rete) -> avvia i servers di rete -> avvia lo script /var/etc/init (customizzazione da parte dell'utente).
Purtroppo non ho potuto spostare /var/etc/init in fondo alla procedura di
avvio in quanto ho riscontrato che tale spostamento interferisce negativamente
con fwpro qualora l'immagine sia installata su pen USB o hard disc. Probabilmente fwpro, che modifica lo script rcS, fa delle assunzioni precise sulla posizione di alcuni elementi in rcS. Il risultato, spostando /var/etc/init in fondo alla sequenza di avvio, è che ogni volta che il Dreambox viene avviato, dopo
qulache secondo si rispegne. La sequenza finale di avvio è quindi: avvia lo
script /var/etc/init (customizzazione da parte dell'utente) -> avvia Enig17
Firmware fog per Dreambox 7000
ma (che imposta la rete) -> avvia i servers di rete.
Ho voluto entrare nei dettagli delle modifiche apportate alla procedura di avvio
perché penso che oltre a poter essere di aiuto agli utenti meno smaliziati, possono essere uno spunto per chiunque abbia la necessità di creare uno script di
init di customizzazione per una qualsiasi immagine e per il quale sia importante conoscere stato e configurazione della rete. L'intera procedura di avvio
probabilmente non è sufficientemente robusta (soprattutto se pensiamo a quello che siamo abituati a vedere su Mac OS X, il cui launchd è da molti invidiato)
ma dopo diversi giorni di prove sembra funzionare. Infine, è l'unica soluzione
che ho trovato senza dover mettere le mani al codice di Enigma.
2.1.4 Utenti, Gruppi Preimpostati e Passwords
La prima preoccupazione è stata quella di rendere ‘inoffensivo’ o detto in altri
termini disabilitare il ‘superutente’ root. Questo è stato fatto seguendo uno dei
metodi più usati nei vari ambienti Unix e cioè impostando nel file passwd,
come shell di root il comando inoffensivo nologin, che semplicemente informa l'utente che l'account non è disponibile ed esce. Disabilitare root comporta
necessariamente la creazione di almeno un utente con compiti amministrativi e
l'introduzione di un tool che consenta di eseguire tali compiti. Il tool è naturalmente costituito dall'arcinoto comando sudo (vedi più avanti) e l'utente preimpostato per i compiti amministrativi (facente parte cioè dei sudoers) è dreamadm.
Ho anche creato un'altro utente meno privilegiato: dreamuser. Le home directories dei due nuovi utenti sono rispettivamente /var/tuxbox per dreamadm
e /hdd/movie per dreamuser e penso che qualcuno abbia già chiaro il perché
di tale scelta. Le funzioni degli utenti e delle rispettive home directories corrispondono infatti anche a come sono state preimpostate le condivisioni per
FTP, Samba e Netatalk e spiegate successivamente.
Per ciascuno dei nuovi utenti ho preimpostato un gruppo con lo stesso id e
nome dell'utente e che costituisce il gruppo principale dell'utente stesso ed al
quale non dovrebbero essere associati altri utenti.
Ho inoltre creato due gruppi che, come funzionalità corrispondono a quelle dei
due utenti preimpostati. Il primo gruppo è admin (al quale appartengono root e
dreamadm) mentre il secondo è dbusers (al quale appartiene dreamuser).
Nell'impostazione dei gruppi mi sono ispirato allo schema usato su Mac OS X.
In particolare la creazione di un gruppo unico per ogni utente con lo stesso id
dell'utente garantisce una maggiore sicurezza delle home directories.
Spero che l'impostazione iniziale da me data per utenti e gruppi, unitamente
alle spiegazioni appena esposte, possa stabilire una linea guida ed una facilitazione per l'eventuale inserimento di nuovi utenti.
La password preimpostata per tutti i nuovi utenti e l'utente root è quella a cui
ormai siamo da sempre abituati e cioè Dreambox.
18
Firmware fog per Dreambox 7000
Suggerimenti per la sicurezza
Se volete sfruttare le impostazioni di sicurezza offerte da questa immagine, naturalmente la prima cosa da fare, una volta effettuato il login con secure shell
come utente dreamadm, sarà quella di cambiare le password di tutti gli utenti
inviando il comando sudo passwd <nome_utente> per ognuno dei tre
utenti del sistema: root, dreamadm e dreamuser.
Una cosa imortante da osservare è che il comando passwd non si comporta
nel modo in cui normalmente siamo abituati e l'uso di sudo è necessario. In altri termini non è possibile inviare semplicemente il comando passwd senza
nome utente per cambiare la password dell'utente correntemente connesso.
Questo accade perché, anche se normalmente il comando passwd ha il bit setuid impostato, sul Dreambox questo non accade e per motivi di sicurezza non
conviene assolutamente impostarlo. Il comando passwd è infatti un link simbolico a busybox e impostarne il bit setuid equivale ad impostare il bit setuid di
busybox che fa capo alla maggior parte dei comandi presenti sul Dreambox
(vedi oltre per una descrizione del funzionamento di busybox).
Riconosco che questo aspetto costituisce un limite nel caso vogliate creare
nuovi utenti e consentire loro la modifica autonoma della password. Una possibile soluzione potrebbe essere quella di creare o trovare un utlity adatta allo
scopo ma, attenzione!!! Un utility per il cambio password mal scritta e con il bit
setuid impostato è un potenzale pericolo capace di distruggere in un batter di
ciglio tutta la sicurezza faticosamente impostata. Forse ancor meglio sarebbe
ricompilare Busybox senza il supporto per il comando passwd e compilare separatamente tale comando prendendolo dalle util-linux. Se questa immagine
avrà un riscontro terrò in considerazione questa possibilità per un eventuale
seconda versione.
Scegliete le nuove passwords in modo adeguato: uno o due segni di interpunzione, presenza di maiuscole e minuscole e, soprattutto, parole difficilmente
rintracciabili in un dizionario. Esistono molti metodi per costruire password di
questo tipo e che allo stesso tempo siano facili da ricordare.
Le passwords (come spiegato più avanti) sono memorizzate in forma cifrata nel
file /var/etc/shadow. La password preimpostata di default Dreambox è
quella di tipo crypt classica di UNIX (password cifrata con algoritmo DES a 56
bit). La cosa interessante è che Busybox, come default, genera le passwords
con algoritmo MD5, molto più sicure delle passwords di tipo crypt e quindi,
una volta modificate le passwords, queste saranno tutte cifrate con algoritmo
MD5 (anche questo ormai uno standard sulla gran parte delle distribuzioni
Linux/UNIX).
Le passwords cifrate in MD5 possono avere lunghezza arbitraria (con passwords molto lunghe si preferisce usare il termine passphrases perché in questo caso può essere abbastanza sicuro usare la giustapposizione di parole anche presenti in un dizionario) mentre le passwords di tipo crypt sono limitate ad
8 caratteri, quelli forniti in eccesso vengono infatti eliminati dall'algoritmo.
19
Firmware fog per Dreambox 7000
C'è ancora di più: il comando passwd con l'opzione -a sha1 genera la password con l'algoritmo SHA1, ancora più sicuro dei precedenti.
Esiste un tipo di password cifrata ancora più sicuro?
La risposta è sì e si tratta delle passwords bcrypt (algoritmo blowfish) anche se
tali tipi di password non sono supportate da Busybox.
Usato per la prima volta su OpenBSD, l'algoritmo bcrypt si sta diffondendo ad
altre distribuzioni Linux/UNIX. Penso tuttavia che le password di tipo MD5 o
SHA1 fornsiscano, al momento, un livello di sicurezza adeguato per il nostro
Dreambox.
2.1.5 Software Busybox
Versione: 1.0.1 (Disponibile nel CVS)
Links: http://www.busybox.net/
Come molti sapranno, Busybox è il software tuttofare del Dreambox e racchiude le funzionalità di un discreto numero di tools che sono standard sulle varie
distribuzioni Linux/Unix.
Le diverse funzionalità di Busybox vengono assolte in funzione del nome con
cui viene invocato il comando busybox stesso. Questo viene realizzato mediante una serie di link simbolici a busybox, ognuno con il nome dell'utility
rimpiazzata da busybox.
Il parco di utilities standard che busybox può sostituire e che in gergo Busybox vengono chiamate applets è abbastanza ampio e viene stabilito in fase di
compilazione di Busybox stessa.
Visto che ora il Dreambox si rivela per quello che in realtà è sempre stato e cioè
una macchina multiutente, non poteva non mancare la compilazione in Busybox degli applets per la gestione di gruppi e utenti. I nuovi applets sono:
1) adduser (aggiunta di un nuovo utente);
2) addgroup (aggiunta di un nuovo gruppo);
3) deluser (cancellazione di un utente esistente);
4) delgroup (cancellazione di un gruppo esistente).
Ho tolto invece l'applet che offre le funzionalita di vi. Ho infatti inserito nell'immagine l'editor Nano molto più semplice da usare anche per i meno esperti e
credo sufficiente per le eventuali operazioni di editing dei files di configurazione
sul Dreambox.
20
Firmware fog per Dreambox 7000
2.1.6 Shadow Passwords
Versione: Supportate da Busybox e dalle librerie di Sistema
Le Shadow Passords rappresentano un metodo, ormai standard su quasi tutte
le distribuzioni Linux/Unix, per incrementare in modo significativo la sicurezza.
Con le Shadow Passwords la password criptata di ogni utente non è più registrata nel file /var/etc/passwd (che per ragioni che non sto a spiegare ma
intuibili deve essere accessibile in lettura a tutti gli utenti) ma nel file separato
/var/etc/shadow accessibile solo a root. La cosa strana che ho notato è
che, nonostante Busybox e le librerie di sistema del Dreambox offrano il supporto alle Shadow Passwords, questa funzionalità non è mai stata sfruttata.
Bene, ora lo è.
2.1.7 Software di Rete Avviato da inetd
In considerazione del fatto che nell'immagine è stato installato il pacchetto
TCP Wrappers, il file di configurazione inetd.conf del ‘superdemone’ inetd
è stato modificato in modo che tutti i servers avviati da inetd siano lanciati attraverso tcpd, il demone fornito con TCP Wrappers (vedi oltre).
2.1.7.1
Server Telnet
Versione: vedi Busybox
Visto che nell'immagine è presente il server sshd che può rimpiazzare completamente il server telnetd, ho disabilitato quest'ultimo, commentando la riga
corrispondente nel file inetd.conf. Telnet è intrinsecamente poco sicuro, tutti
i dati, compresa la password di autenticazione, viaggiano in chiaro sulla rete.
Suggerimenti per la sicurezza
Nessuno tranne quello di non avviare telnetd riabilitando il server in
inetd.conf!
2.1.7.2
Server FTP Vsftpd
Versione: 1.1.0 (Disponibile nel CVS)
Links: http://vsftpd.beasts.org/
Il file di configurazione di vsftpd (vsftpd.conf) è stato modificato in modo
da sfruttare una caratteristica interssante offerta dal software, quella di ‘confinare’ ogni utente nella propria home directory. In altri termini, come si dice in
gergo, ogni utente, una volta connesso al server FTP, è chrooted nella propria
home directory. In questo modo, per come sono state impostate le home directories l'utente dreamuser è confinato alla directory /hdd/movie (sempre
che abbiate installato un hard disc naturalmente). Questa funzionalità è stata
disabilitata, nel modo descritto di seguito, per l’utente dreamadm che, in quanto amministratore, deve poter accedere anche ad altre parti del file system, in
particolare la directory /tmp, sulla quale ha accesso in scrittura, per scaricare
un nuovo firmware.
21
Firmware fog per Dreambox 7000
Potete modificare questo comportamento di vsftpd per ogni singolo utente
impostato o aggiunto in seguito sul Dreambox, in modo che questo abbia accesso all'intero file system del Dreambox. Suggerimento: inserite, nel file
/var/etc/vsftpd.chroot_list, l'elenco degli utenti per i quali desiderate disabilitare la funzionalità di essere confinati alla propria home directory
Attenzione, il precedente suggerimento ha l'effetto desiderato in quanto l'opzione chroot_local_user in vsftpd.conf è stata abilitata, se non lo fosse, l'effetto del file /var/etc/vsftpd.chroot_list sarebbe esattamente il
contrario e cioè tutti gli utenti in questo file sarebbero confinati alla propria
home directory.
Maggiori dettagli sulla configurazione del server vsftpd li trovate qui:
http://vsftpd.beasts.org/vsftpd_conf.html.
In ogni caso, se decidete di consentire a degli utenti di accedere all'intero file
system, trattenetevi dal cambiare i permessi sui files al di fuori di /var/tuxbox (in particolare sui files in /var/etc/, /bin e /sbin) anche per quanto riguarda l’utente dreamadm che già accesso all’intero filesystem. Dico questo
perché già immagino qualcuno che pensa a questa possibilità, così da tornare
alla vita facile di prima, dove anche questi files si editavano via FTP o anche
Samba. Agendo in questo modo, una parte della sicurezza preimpostata si dissolverà.
Vi raccomando infine di fare una visita sul sito dell'autore di Vsftpd che risulta
essere anche un grande esperto di sicurezza. Sul sito si possono trovare diverse discussioni illuminanti in proposito. Proprio per questo, Vsftpd è stato costruito avendo la sicurezza come primo obiettivo e da questo punto di vista,
probabilmente, è il campione dei vari servers FTP in circolazione.
L'ultima versione disponibile supporta anche connessioni sicure tramite SSL
(appoggiandosi alla libreria OpenSSL) e visto che Stunnel non è in grado di
proteggere (o può proteggere solo parzialmente) le connessioni FTP (vedi più
avanti), se questa immagine susciterà un certo interesse potrei verificare se è
fattibile l'aggiornamento alla nuova versione.
Suggerimenti per la sicurezza
La password per l'autenticazione viene inviata in chiaro, pertanto trattenetevi
dall'aprire il server FTP al mondo esterno (Internet) e tenete ben chiuse sul vostro firewall le porte di default sulle quali opera FTP. Purtroppo, con la versione
correntemente installata di Vsftpd, non vedo soluzioni alternative (quali l'utilizzo
di ssh o stunnel come successivamente consigliato per Samba o Netatalk)
per connettervi al server FTP in modo sicuro dal mondo esterno con un normale client FTP, se non quella di realizzare una VPN.
Comunque un momento … un’alternativa esiste ed è rappresntata da SFTP,
offerto da OpenSSH e descritto nella sezione relativa a questo software. Molti
clients FTP (ad esempio Transmit su Mac OS X) supportano infatti anche questo protocollo.
22
Firmware fog per Dreambox 7000
In futuro, se sarà fattibile l'installazione dell'ultima versione di Vsftpd con il supporto diretto di SSL le possibilità di scelta potrebbero aumentare.
2.1.8 Software di Rete Standalone Avviato da Enigma
2.1.8.1
Software Samba
Versione: 1.9.18p8 (Disponibile nel CVS)
Links: http://www.samba.org
La compilazione/installazione di Samba è stata modificata in modo da leggere
direttamente il file di configurazione smb.conf in /var/etc ed aggiungendo il
tool smbpasswd a supporto dell'autenticazione mediante passwords cifrate (di
tipo lan manager o NTLM). Il file di configurazione preimpostato è stato completamente riscritto e vi consiglio di dargli un'occhiata in quanto ho commentato i punti più importanti.
Da segnalare:
1) Autenticazione mediante passwords cifrate (le passwords per l'autenticazione di Samba risiedono nel file separato /var/etc/smbpasswd accessibile solo a root).
2) Condivisione di tipo user e non più share come in precedenza.
3) Introduzione nella sezione [global] di smb.conf dei parametri hots
allow e hosts deny per limitare l'accesso alle condivisioni.
La configurazione di tali parametri è identica a quella da me impostata
nei file /var/etc/hosts.allow e /var/etc/hosts.deny, pertanto,
riguardo la loro impostazione, vi rimando alla discussione successiva relativa al pacchetto Tcp Wrappers (Samba ha le funzioni della libreria dei
Tcp Wrappers built-in ed il codice relativo è stato adattato a Samba prendendolo proprio dal pacchetto Tcp Wrappers)
4) Due condivisioni impostate e attivate:
EnigmaConf che corrisponde a /var/tuxbox ed è accessibile dal gruppo admin e quindi dall'utente dreamadm (serve per scaricare/modificare
settings, skins, plugins ).
UploadFW che corrisponde a /tmp ed è anche questa accessibile dal
gruppo admin e quindi dall’utente dreamadm (serve per scaricare nuove
immagini da installare in flash).
5) Due condivisioni impostate, ma non attivate (le linee relative sono commentate nel file /var/etc/smb.conf con il carattere #), per agevolare
gli utenti che hanno installato un hard disc e/o un dispositivo di memoria
USB (le condivisioni sono commentate nel file ):
Movies, che corrisponde ad /hdd/movie, è accessibile dai gruppi admin e dbusers e quindi dagli utenti dreamadm e dreamuser (serve ovviamente per scaricare le registrazioni sull'hard disc del Dreambox).
23
Firmware fog per Dreambox 7000
USB Che corrisponde ad /var/mnt/usb ed è accessibile dal gruppo
admin e quindi dall'utente dreamad.
Affinché l’utente dreamadm abbia evetualmente i permessi in scrittura sulla
condivisione Movies (utile per cancellare le registrazioni o scaricare nuovi files
di tipo MPEG TS) è necessario cambiare proprietario e permessi sulla directory
/hdd/movie e il suo contenuto in questo modo:
sudo chown root:admin /hdd/movie
sudo chmod ug+rw /hdd/movie
Come accennato, parlando degli scripts di init, il file smb.conf viene editato
in fase di avvio. In particolare viene impostato il parametro interface con
l'indirizzo ip e maschera di sottorete impostati da Enigma. Ho notato che l'impostazione di questo parametro era necessaria (insieme alla modifica del file
/var/etc/hosts) perché il browsing delle condivisioni Samba funzionasse
sul mio client Mac. Evitate quindi di modificare la linea in cui compare questo
parametro.
Suggerimenti per la sicurezza
Come per le passwords di sistema memorizzate nel file /var/etc/shadow, la
prima cosa da fare è quella di cambiare le password di Samba per ognuno dei
tre utenti di sistema con il comando sudo smbpasswd <nome_utente>. È
ovvio che per non complicarvi la vita inserirete le stesse passwords inserite
precedentemente. A tale proposito osservo che è prevista un'opzione di configurazione di Samba, unix password sync, che se impostata a yes, dovrebbe consentire, con il comando smbpasswd, il cambiamento contemporaneo della password di Samba e di quella di sistema.
Questo parametro è correntemente impostato nel file smb.conf, tuttavia smbpasswd non funziona come previsto e le passwords non vengono sincronizzate. In un primo momento pensavo che il problema fosse dovuto alla non corretta impostazione di un'altro parametro, passwd chat, ma dopo una serie infinita di tentativi ho desistito, anche perché ho constatato su Internet che moltissimi altri utenti avevano lo stesso problema. Forse il problema può essere stato
risolto dalle versioni più recenti di Samba.
Questo per dire che, se lo desiderate, potete anche commentare la linea in cui
il parametro unix password sync viene impostato, così facendo potrete
cambiare la password dell'utente con cui avete effettuato il login anche semplicemente inviando il comando smbpasswd senza sudo e senza il nome dell'utente. Lasciando il parametro impostato a yes la procedura appena descritta
genera infatti un errore.
Personalmente non vedo differenze tra lasciare impostato il parametro a yes
oppure no, Io l'ho lasciato perché in questo modo il metodo di cambiamento
delle passwords di Samba è coerente con quello del cambiamento delle pas24
Firmware fog per Dreambox 7000
sword di sistema. Certo che se le cose funzionassero come dovrebbero, usando Samba, ci si potrebbe dimenticare del comando passwd e modificare le
password solo con il comando smbpasswd.
Un approffondimento è necessario per quanto riguarda le passwords di Samba.
Come detto, in questa immagine, Samba usa il proprio file di password
/var/etc/smbpasswd, nel quale, per ogni utente, sono memorizzate due
versioni criptate della relativa password. La prima versione è la password criptata di tipo lan manager (usata, credo, dai sistemi operativi Microsoft fino alle
versioni 98/Millennium) mentre la seconda versione è la passowrd criptata di
tipo NTLM usata a partire da Windows NT (non ricordo se NT3.5 o NT4).
Entrambi i tipi di password, per gli algoritmi di cifratura usati, prestano il fianco
a diverse critiche e sono stati scritti fiumi di parole in proposito.
In particolare è stato sottolineato che una password di tipo lan manager con
un'attacco offline basato su dizionario potrebbe essere recuperata in pochi minuti da un bambino di 9-10 anni dotato di un computer di recente generazione.
Per questo motivo il file smbpasswd è accessibile solo a root e deve rimanere
così protetto. Il fatto che sia presente la password di tipo lan manager (non c'è
bisogno cioè di tentare di decifrare la password NTLM dal momento che è sufficiente decifrare la password cifrata con l'algoritmo più debole, quella di tipo
lan manager appunto) deve far considerare la lettura di questo file equivalente
alla lettura della password in chiaro.
Per quanto riguarda l'accesso a Samba, questo è vero anche in senso letterale.
Infatti, per autenticarsi a Samba, è necessaria solo la password cifrata (lan manager o NTLM) e non quella in chiaro.
Per considerazioni analoghe e nonostante le passwords trasmesse sulla rete
siano ulteriormente criptate (credo con algoritmo DES), è bene considerare anche le passwords trasmesse sulla rete per autenticarsi, come se fossero passwords in chiaro.
Per questi motivi trattenetevi dall'aprire Samba al mondo esterno (Internet) e
tenete ben chiuse sul vostro firewall le porte sulle quali opera. Se proprio avete
necessità di accedere al server Samba dal mondo esterno e non siete dotati di
una VPN potete farlo mediante le facilities di tunnelling offerte da sshd (come
spiegato più avanti) o da stunnel, anche se in questo secondo caso la configurazione potrebbe risultare un po' più complicata perché dovrete aggiustare
le cose sia lato client che server.
2.1.8.2 Interfaccia Web di Enigma
L'interfaccia Web di Enigma è accessibile anche attraverso la porta TCP 443
(https) per mezzo del software Stunnel che consente l'incapsulamento dei dati
mediante i protocolli SSL/TLSv1. Per ulteriori dettagli sul funzionamento di
Stunnel ed osservazioni o consigli per la sicurezza, consulate più avanti la se25
Firmware fog per Dreambox 7000
zione relativa a queso software.
2.2 Principale Software Extra Contenuto nell'Immagine
Seguono le descrizioni per il software non standard presente nell'immagine.
2.2.1 Software Sudo
Versione: 1.6.8p12
Links: http://www.gratisoft.us/sudo
Alzi la mano chi non conosce sudo! A parte gli scherzi, per gli scopi prefissi
nella costruzione di questa immagine sudo era un tool a cui non si poteva rinunciare, per gran parte delle operazioni da terminale (stop/avvio di servers,
cambio di passwords ecc.) dovrete digitare, una volta effettuato il login come
dreamadm:
sudo <nome_comando> …
Il file di configurazione /var/etc/sudoers è impostato in modo tale che tutti
gli utenti appartenenti al gruppo admin sono abilitati all'esecuzione di sudo.
Qualcuno potrebbe obiettare che esiste il comando su (che fa parte degli
applets di Busybox) ma avendo disabilitato l'utente root, il comando su non
può essere usato per impersonare root. Con gli altri utenti su funziona, a patto
di
digitare:
sudo su <nome_utente>, questo perché il comando su (cioè busybox)
non ha, per i motivi di sicurezza già esposti per il comando passwd, il bit setuid impostato.
Oltre a questo vi è da dire che sudo prevede una serie di funzionalità aggiuntive rispetto al normale comando su, in particolare funzionalità di logging e la
capacità di definire un controllo molto preciso di quali operazioni ogni singolo
utente è abilitato a fare, tramite il file di configurazione sudoers.
Potete recarvi sul sito dell'autore per avere maggiori dettagli oppure se avete
un computer Linux/Unix leggere le pagine del relativo manuale da terminale.
Suggerimenti per la sicurezza
Se intendete editare il file di configurazione /var/etc/sudoers, usate sempre il comando visudo preposto allo scopo. Questo infatti, oltre ad eseguire il
lock del file sudoers per prevenire eventuali modifiche contemporanee effettuate da un altro utente (aspetto forse poco importante per il suo uso sul
Dreambox) effettua anche una verifica formale della sintassi del file prima di
scrivere le modifiche sul disco, avvisandovi nel caso riscontri una configurazione mal formata. Se il file sudoers fosse infatti mal formato, il comando sudo
rifiuterebbe l'esecuzione tagliandovi fuori dall'amministrazione della macchina.
26
Firmware fog per Dreambox 7000
2.2.2 Editor Nano
Versione: 1.2.4 (Disponibile nel CVS)
Links: http://www.nano-editor.org
L'editor ‘facile facile’ anche per principianti. Usato anche da visudo (vedi sopra) per editare il file /var/etc/sudoers.
Se dovrete editare i files di configurazione del software fornito dovrete spesso
digitare da terminale (e come utente dreamadm): sudo nano <nome_file>.
2.2.3 Libreria OpenSSL
Versione: 0.9.7a (Disponibile nel CVS)
Links: http://www.openssl.org
La libreria OpenSSL è un pezzo ‘da novanta’ e non credo abbia bisogno di presentazioni, su di essa si appoggiano diversi software inclusi nell'immagine, in
particolare (oltre a OpenSSH, Netatalk (per l'autenticazione cifrata DHX) e
Stunnel (ovviamente per il protocollo SSL). Recentemente è stato scoperto che
la versione installata soffre di un bug che può essere utilizzato per realizzare
degli attacchi tipo DOS. Il bug è presente sia nella serie 0.9.7 che 0.9.8 della libreria ed è stato risolto con le ultime versioni nei rispettivi branch. Non ho instalato una versione più recente per i motivi precedentemente esposti ed anche perché, considerando il tipo d’uso previsto per questa immagine (non ho
tuttavia effettuato ricerche approfondite sulle possibili conseguenze del bug),
questo bug può, al momento, non essere considerato critico.
2.2.4 Software OpenSSH (Portable)
Versione: 3.5p1 (Disponibile nel CVS)
Links: http://www.openssh.com, http://www.openssh.com/portable.html
Del pacchetto software, ho installato solo il server SSH (sshd) con il relativo
sottosistema SFTP (sftp-server) ed il tool scp per la copia sicura remota di
files su una rete. Non ho installato il client SSH per i limiti imposti sulla dimensione finale dell’immagine. Non credo, tuttavia che questa sia una grande mancanza.
Una particolarità importante del server SSH (sshd) è quella di consentire oltre
al login da terminale (in questo sostituendo telnet, rlogin, o rsh), anche il
tunnelling protetto dei protocolli TCP/IP verso il server (è inoltre possibile anche l'operazione inversa).
Questa funzionalità può tornare utile per connettersi occasionalmente al server
Samba o Netatalk in modo protetto, dall'esterno della rete locale (da Internet)
alla quale è connesso il nostro Dreambox. Il comando da eseguire sul terminale
del computer client per effettuare il login al Dreambox e contemporaneamente
il tunneling di un un particolare servizio TCP/IP verso il server è:
27
Firmware fog per Dreambox 7000
ssh <nome_utente>@<ip_db> \
-L <porta_client>:127.0.0.1:<porta_server>
Ad esempio, volendosi connettere, tramite il tunneling offerto da sshd, al server AppleShare afpd di Netatalk si potrebbe prima effettuare il login sul
Dreambox tramite il seguente comando:
ssh dreamadm@<ip_Dreambox> -L 10548:127.0.0.1:548
Una volta eseguito il login sul Dreambox, dal computer client ci si può connettere al server afpd sul Dreambox collegandosi all'indirizzo ip
127.0.0.1:10548.
La connessione al server afpd interessa di fatto gli utenti Mac OS. In questo
caso, selezionato nel Finder il menù ‘connessione al server…’, nella finestra di
connessione inseriremo l'indirizzo 127.0.0.1:10548. L'indirizzo ip
127.0.0.1 è l'indirizzo dell'interfaccia di loopback del nostro computer (potremmo anche aver usato localhost) e costituisce l'endpoint del tunnelling,
mentre 10548 è la porta sulla quale è stato ‘dirottato’ il traffico dalla porta di
default di afpd che è 548. Come porta su cui dirottare il traffico AFP avremmo
potuto benissimo scegliere un altra porta libera non privilegiata (>1024), la
scelta 10548 è una solo convenienza.
Con una stessa connessione SSH si può fare il tunneling di più servers contemporaneamente, semplicemente inserendo più opzioni -L con le relative
mappature di porta.
È anche importante osservare che, per effettuare il tunneling, non è necessario
effettuare il login con ssh sulla stessa macchina che ospita il server del quale
si deve fare il tunneling come mostrato nell'esempio precedente. Infatti, se sulla rete del nostro Dreambox, fosse presente un'altro computer sul quale è in
funzione il server sshd e tale computer avesse accesso al server afpd sul
Dreambox è possibile fare il tunneling del server afpd sul Dreambox connettendosi con ssh al computer sul quale è in funzione sshd. In questa seconda
circostanza la sintassi del comando per connesioni AFP al Dreambox sarebbe:
ssh <nome_utente>@<ip_serverssh> -L 10548:<ip_Dreambox>:548
Per le connessioni al server Samba la sintassi è uguale, basta sostituire alla
porta 548 la porta 139.
Per analogia con il caso precedente si potrebbe poi sostituire la porta 10548
con la porta 10139. Purtroppo questo funziona su Linux (credo che smbmount, il comando per montare i volumi condivisi da Samba o servers Windows, accetti la specificazione di una porta alternativa a quella di default) ma non
su Mac OS X. Su Mac OS X infatti il Finder ed il relativo comando da terminale
mount_smbfs, sul quale il Finder stesso si appoggia per montare le condivisioni SMB, non accetta la specificazione di una porta diversa da quella di de28
Firmware fog per Dreambox 7000
fault.
Il comando mount_smbfs di Mac OS X è derivato da quello di FreeBSD. Ho
notato che nelle ultime versioni di FreeBSD questo comando supporta la specificazione di porte alternative, quindi è probabile che questa funzionalità venga aggiunta in futuro anche a Mac OS X. Su Mac OS X quindi, per fare il tunneling del server Samba sul Dreambox dovrete eseguire:
sudo ssh dreamadm@<ip_Dreambox> -L 139:127.0.0.1:139
Oppure anche, effettuando il tunneling tramite un altro computer sulla rete del
Dreambox:
sudo ssh <nome_utente>@<ip_serverssh> \
-L 139:<ip_Dreambox>:139'
Notate che in questi casi è stato usato sudo, poiché con il comando apriamo
sul computer client la porta 139 che è una porta privilegiata (<1024) che solo
root può aprire. Perché il precedente comando funzioni è ovviamente necessario che la porta 139 non sia già aperta, che non sia cioè in funzione sul computer client il server Samba.
In connessioni ai servers dall'esterno (da Internet) mediante tunneling (la situazione più comune per la quale è conveniente usare il tunneling) è assai probabile che la rete del Dreambox sia schermata da un router con NAT. In questo
caso l'indirizzo ip al quale connettervi diventa l'indirizzo internet del router e
dovrete impostare il router in modo tale che mappi la porta 22 (la porta di default di SSH) sull'indirizzo di rete locale del computer sul quale è in funzione il
server sshd (l'indirizzo del Dreambox o l'indirizzo di un altro computer scelto
per accettare i logins SSH dall'esterno).
Le due principali controindicazioni del tunneling tramite ssh sono:
1) Un carico di lavoro sulla macchina che esegue il server sshd che può diventare notevole in caso di connessioni molto veloci.
2) Ad ogni server al quale vi connettete mediante tunneling, le connessioni
appariranno provenire dalla macchina stessa sul quale il server è in funzione.
Per quanto riguarda il punto 1, ho fatto delle prove con Mac OS X come client,
connettendomi al Dreambox con ssh e facendo il tunneling di AFP e SMB. Attraverso connessioni Wireless a 54Mb/s il trasferimento di files di grosse dimensioni è circa due volte più lento con AFP e circa 3-4 volte più lento con
Samba.
Attraverso connessioni da Internet (dove la banda a disposizione è molto inferiore) la penalizzazione non sembra incidere in modo significativo.
Il punto 2 costituisce un problema per l'analisi dei files di log dei vari servers.
29
Firmware fog per Dreambox 7000
Per i motivi descritti nell'ultima parte di questa guida, il server di log syslogd
non è avviato in fase di avvio del Dreambox e per gli stessi motivi non è stata
prestata particolare attenzione alla configurazione dei logs dei vari servers. Nonostante questo, il punto 2, se intendete avviare syslogd, è da tenere in considerazione quando effettuate il tunneling.
Osservo, infine, che non è possibile fare il tunneling di FTP e questo sia per il
fatto che FTP opera su due porte (la porta 21 di ‘controllo’ e la porta 20 ‘dati’)
sia per il modo di operare stesso di FTP.
Un’altro possibile uso del Software OpenSSH è quello per trasferire in modo sicuro files da e verso il Dreambox attraverso il sottosistema SFTP o il tool scp.
Nel primo caso avrete bisogno di un client FTP che supporti anche SFTP (ad
esempio Transmit su Mac OS X) oppure, se il vostro computer è basato su
UNIX/Linux usare da terminale sftp (anch’esso parte del software OpenSSH e
normalmente incluso nella maggioranza delle distribuzioni Linux/Unix).
OPENSSH prevede molti parametri e files di configurazione, qui ho solo evidenziato gli aspetti che mi sembravano più interessanti. Per un suo uso avanzato (quale la connessione senza password) vi rimando alla documentazione.ufficiale.
Suggerimenti per la sicurezza
Le chiavi pubbliche e private presenti nell’immagine in /var/etc/ssh sono
state generate in fase di compilazione/installazione del pacchetto. Anche se
l’eventualità che tali chiavi possano essere usate per un attacco al vostro
Dreambox è remota, dal momento che tale immagine è stata resa pubblica,
essa non può essere considerata uguale a zero. Per ridurre tale possibilità ed
eventualmente impostare le chiavi in accordo con le vostre richieste di sicurezza potete allora decidere di rigenerare le chiavi di sshd in /var/etc/ssh con
sudo ssh-keygen … Fate riferimento alla documentazione ufficiale per maggiori dettagli. Ricordo che è importante che le chiavi private siano accessibili
solo a root (permessi uguali a 600), altrimenti sshd si rifiuta di avviarsi e che
forse è opportuno eseguire tale operazione con Telnet (riabilitando telnetd in
inetd.conf solo temporaneamente) per non rischiare di essere tagliati fuori
dall’amministrazione della macchina.
Anche OpenSSH è stato compilato con il supporto per i TCP Wrappers (vedi
anche la sezione relativa ai TCP Wrappers). Tuttavia la configurazione preimpostata in /var/etc/hosts.allow, a differenza degli altri servers, consente
l’accesso mediante SSH da qualsiasi host, questo in considerazione del fatto
che SSH può essere usato per accedere al Dreambox dall’esterno (da Internet)
ed anche perché, essendo l’unico mezzo per effettuare qualsiasi modifica alle
impostazioni iniziali, non volevo che inizialmente fossero poste delle restrizioni.
Se non avete bisogno di accedere al Dreambox da postazioni remote o se sapete già da quali indirizzi ip effettuerete le connessioni, potete imporre voi stessi le restrizioni adeguate per sshd nel file /var/etc/hosts.allow.
30
Firmware fog per Dreambox 7000
Il software OpenSSH in questa immagine è lo strumento principale per connettersi in modo sicuro al nostro Dreambox. Se avete impostato le passwords in
modo adeguato, come suggerito precedentemente nella sezione relativa agli
utenti e gruppi, SSH può essere considerato sufficientemente sicuro per connettersi anche da postazioni remote su Internet. Se avete tali esigenze potete
aprire la porta del vostro router/firewall e rimapparla sull'indirizzo di rete locale
del vostro Dreambox come spiegato precedentemente. In questo caso, se volete aggiungere ancora un po’ di sicurezza, potete modificare il files di configurazione /var/etc/ssh/sshd_config impostando il parametro Port in
modo che sshd operi su una porta diversa dalla 22 che è quella standard, in
modo da nascondervi un po’ ai malintenzionati che scandagliano le porte aperte sugli hosts connessi ad internet alla ricerca di quelle più sensibili e potenziale bersaglio di un potenziale attacco.
2.2.5 Software Stunnel
Versione: 4.2.0
Links: http://stunnel.mirt.net, http://www.stunnel.org
Il demone stunnel ha la funzione di offrire servizi SSL ai software che non
supportano questo protocollo. Ha infatti la capacità di incapsulare nel protocollo SSL le comunicazioni tra un software client e un software server in modo trasparente per i due software. È importante sottolineare che stunnel offre il
supporto SSL sia ai clients che ai servers in modo indipendente e impostato
dai parametri di configurazione. Naturalmente è necessario aver installato e
correttamente configurato stunnel, a seconda del supporto offerto dal software client e da quello server, sulle macchine dove è necessario offrire il supporto SSL.
Il risultato dell'incapsulazione nel protocollo SSL da parte di stunnel di dati
che altrimenti viaggerebero in chiaro sulla rete, è simile a quello ottenuto sfruttando le possibilità di secure shell descritte sopra. La principale differenza rispetto a quest'ultimo metodo di protezione è la maggiore trasparenza per l'utente, una volta installato e configurato correttamente, ed il supporto per SSLv3/TLSv1 e l'autenticazione mediante certificati digitali.
In questa immagine stunnel è configurato per offrire i servizi SSLv3 all'interfaccia Web di Enigma. Per connettervi con un browser a questa interfaccia, ora
potete convenientemente usare l'indirizzo https://<ip_Dreambox>.
L'interfaccia Web di Enigma rappresenta uno dei punti più deboli dell'intera catena e questo è il modo migliore che ho trovato per porvi riparo, anche se parzialmente. Un ulteriore passo per rendere il Dreambox ancora più sicuro, sarebbe quello di modificare il codice di Enigma in modo tale da offrire una configurazione per l'interfaccia di rete associata al Web server di Enigma, che, con la
presenza di stunnel, potrebbe essere impostata su quella di loopback con
l’indirizzo ip 127.0.0.1.
31
Firmware fog per Dreambox 7000
Il demone stunnel è stato compilato con il supporto per i TCP Wrappers (vedi
la relativa sezione). Tuttavia, poiché ho configurato stunnel, nel file
/var/etc/stunnel.conf, in modo che giri confinato (chrooted) nella directory /var/lib/stunnel, esso non è in grado di accedere ai files
/var/etc/hosts.allow e /var/etc/hosts.deny. Se volete configurare i
TCP Wrappers anche per stunnel, dovrete creare e configurare, con le restrizioni desiderate, i files /var/lib/stunnel/var/etc/hosts.allow e
/var/lib/stunnel/var/etc/hosts.deny.
Non ho configurato i TCP Wrappers per stunnel, come invece fatto per gli altri servers, perché penso che l'uso di SSL sia adeguato per connessioni dall'esterno della vostra rete (da Internet).
Suggerimenti per la sicurezza
Il certificato digitale autofirmato (self signed) /var/etc/stunnel/stunnel.pem è stato generato da me e per considerazioni simili a quelle già fatte
per le chiavi del server SSH, potrete giudicare opportuno generare un nuovo
certificato personale. Le istruzioni su come generare un certificato digitale adeguato per Stunnel le trovate sui siti elencati per questo software.
Come detto Stunnel è preconfigurato per offrire una protezione all’interfaccia
Web di Enigma sulla porta standard HTTPS (443). Se avete necessità di accedere a tale interfaccia dall’esterno (Internet) potete modificare le impostazioni
del vostro firewall/router con modalità simili a quelle già descritte per Open
SSH. Naturalmente Stunnel può essere configurato per proteggere altri servizi.
Un’utilizzo interessante potrebbe essere quello per proteggere il demone syslogd qualora decidiate di attivarlo in fase di avvio.
2.2.6 Software TCP Wrappers
Versione: 7.6
Links: http://www.porcupine.org, http://ftp.porcupine.org/pub/security/index.html
I TCP Wrappers sono un pacchetto presente in quasi tutte le distribuzioni
Linux/Unix da diversi anni e non ha ancora perso il loro smalto. Il software,
creato dal grande Wietse Venema, autore, fra l'altro, dell'arcinoto mail server
Postfix e grande esperto di sicurezza, ha lo scopo di limitare l'accesso ai servers di rete a clients di fiducia, dove la fiducia è data o no in base all'indirizzo ip
(o classe di indirizzi ip di appartenenza) del client.
Il pacchetto si compone di una libreria e di un demone. La libreria offre un supporto al software che desidera gestire direttamente questi meccanismi di protezione. Normalmente i software che includono il supporto per tale libreria vengono linkati in modo statico a questa libreria in fase di compilazione, pertanto
la libreria non è stata inclusa nel pacchetto.
Tutti i software extra di questa immagine che prevedevano il supporto per i
TCP Wrappers (Netatalk e Stunnel) sono stati compilati con tale supporto.
32
Firmware fog per Dreambox 7000
Il demone tcpd è invece in grado di offrire il meccanismo di protezione descritto, a tutti i software lanciati da inetd. In pratica inetd, invece di lanciare direttamente il server per il quale si desidera la protezione descritta, avvia il demone tcpd che effettua il controllo di protezione e se riscontra che il client è
autorizzato ad accedere al server, lancia quest'ultimo in modo che il client possa connettersi ad esso.
Superficialmente gli effetti ottenibili con i TCP Wrappers assomigliano a quelli
di un firewall. In parte è così anche se si deve sottolineare che un firewall ha un
modo di operare completamente diverso ed offre molti più strumenti per il controllo dei pacchetti sia in entrata che in uscita. Un firewall inoltre è sempre ‘in linea’ mentre tcpd, una volta avviato il server, il controllo è lasciato totalmente a
quest'ultimo.
Il grande pregio dei TCP Wrappers, che tuttavia non possono sostituire un firewall vero e proprio, sta nel loro modo elegante e leggero di operare. In altri
termini, sono totalmente trasparenti per il server (il prerequisito è che i servers
possano essere lanciati da un superserver come inetd) e richiedonono risorse
hardware minime alla macchina.
I
file
che
regolano
le
autorizzazioni
alle
connessioni
sono
/var/etc/hosts.allow e /var/etc/hosts.deny. Ho preimpostato tali files in modo da negare l'accesso a tutti gli hosts tranne quelli appartenenti alle
classi di indirizzi ip maggiormente usate nelle reti locali. Possono accedere infatti ai vari servers lanciati da inetd oppure al server afpd di Netatalk tutti gli
indirizzi ip del tipo 10.x.x.x e 192.168.x.x oltre all'indirizzo di loopback
127.0.0.1.
Esistono altre due classi di indirizzi ip impiegate per uso privato.
La prima è costituita dal blocco di indirzzi 169.254.0.0/16 ed è normalmente impiegata per connessioni dirette da pc a pc o quando il client dhcp non riesce ad ottenere un indirizzo IP da un server dhcp.
La seconda è costituita dal blocco di indirzzi 172.16.0.0/12 ed è anch'essa
impiegata nelle reti locali.
Il motivo per cui non ho inserito quest’ultima classe di indirizzi è dovuto al fatto
che la versione built-in dei TCP Wrappers di Samba (in Samba i permessi sugli
indirizzi ip sono impostati in /var/etc/smb.conf) non sembra riconoscere la
forma compatta 172.16.0.0/12 (blocco CIDR), pertanto includere gli indirizzi
nella forma alternativa usata per gli altri blocchi mi avrebbe costretto ad inserire ben 16 blocchi separati, cosa che naturalmente ho evitato di fare. Per coerenza con la configurazione di Samba quindi, anche il file
/var/etc/hosts.allow riporta la stessa serie di indirizzi.
Se la vostra rete locale non rientra nella classe di indirizzi preimpostata dovrete
riconfigurare il file /var/etc/hosts.allow, cosa comunque auspicabile per
restringere l'accesso agli indirizzi della vostra rete locale, o sottogruppo di questi.
33
Firmware fog per Dreambox 7000
Le restrizioni preimpostate sono globali, in altri termini hanno effetto su tutti i
servers protetti dai TCP Wrappers. È tuttavia possibile un controllo più fine dei
permessi per ognuno dei servers supportati. Per questo ed ulteriori approfondimenti sulla sintassi dei file hosts.allow e hosts.deny vi rimando al sito dell'autore.
Suggerimenti per la sicurezza
Vi consiglio di modificare il /var/etc/hosts.allow in modo da restringere
nella configurazione globale l’accesso da parte di hosts gli indirizzi ip dei quali
fanno parte della vostra rete locale (o suo sottoinsieme) e restringere l’accesso
a shhd (provvisto di una configurazione dedicata) secondo l’uso che prevedete
di fare di SSH.
2.2.7 Libreria Berkeley DB
Versione: 4.2.52
Links: http://www.oracle.com/database/berkeley-db/index.html
Questo è un altro pacchetto di quelli pesanti. La sua installazione si è resa necessaria in quanto prerequisito essenziale del pacchetto Netatalk. Ho installato
non solo la libreria ma anche i tools per la gestione dei databases creati da Netatalk, in quanto potrebbero rivelarsi utili nel caso in futuro si dovessero riscontrare problemi con i databases creati da Netatalk (se i databases dovessero
corrompersi potrebbe essere necessario, ad esempio, ricrearli).
Cosa strana da segnalare, nonostante la mole del pacchetto e a differenza di
tutto l'altro software da me aggiunto, non ho dovuto impazzire (questo è vero
più che altro per Netatalk) per configurarlo, compilarlo e installarlo, tutto è filato
liscio senza bisogno di patches.
2.2.8 Software Netatalk
Versione: 2.0.3
Links: http://netatalk.sourceforge.net
Una sommaria descrizione dei servizi AFP e del protocollo AppleTalk è gia stata nella premessa, pertanto evito di ripetermi.
L'installazione Netatalk offerta è ‘quasi’ completa. Le mancanze di maggior rilievo da segnalare sono la mancanza del supporto al sistema di stampa CUPS
e la mancanza del supporto all'autenticazione tramite Kerberos. Ho tuttavia installato tutte le utilities e il software relativo al server di stampa. Quest'ultimo
tuttavia non è operativo in quanto manca un sistema di stampa lpr/lpd. Se
qualcuno ha voglia di compilarne ed installarne uno, non dovrebbe essere difficile far diventare il Dreambox anche un server di stampa AppleTalk.
Le condivisioni attivate o preimpostate (ma lasciate commentate nel file
/var/etc/netatalk/AppleVolumes.default) sono le stesse di Samba.
Poiché lo script di init start_daemons è impostato per avviare entrambi i
34
Firmware fog per Dreambox 7000
servers (smbd di Samba e afpd di Netatalk) vi sconsiglio di montare contemporaneamente le stessa condivisione con SMB e AFP, perché potrebbero verificarsi problemi dovuti al lock dei files.
Probabilmente, visto che i due servers offrono funzionalità simili, la scelta migliore è quella di decidere quale server risponde meglio alle vostre esigenze e
disabilitare l'altro, commentando la linea corrispondente nello script
start_daemons. Se invece avete più computers con OS differenti tra loro o
volete far diventare il Dreambox un piccolo NAS aggiungendo qualche utente e
creando nuove condivisioni, potete lasciarli entrambi attivati, avendo l'accortezza di evitare, se possibile, di montare contemporaneamente le condivisioni
comuni.
Netatalk mi ha portato via un po' di tempo per compilarlo ed ho dovuto creare
diversi patches perché tutto funzionasse a dovere. Dico questo solo per vantarmi un po’, infatti, dopo uno scambio di opinioni con uno dei programmatori
sulla mailing lists di Netatalk, alcune delle mie piccole modifiche fanno ora parte dei sorgenti ufficiali.
L'autenticazione a Netatalk avviene mediante plugins detti uams collocati in
/var/etc/netatalk/uams.
I metodi di autenticazione permessi sono abilitati nel file di configurazione
/var/etc/afpd.conf. I plugins preimpostati sono uams_clrtxt.so e
uams_dhx_passwd.so. Il primo effettua l'autenticazione inviando la password
in chiaro, mentre il secondo usa l'autenticazione cifrata DHX. Ho incluso l'autenticazione in chiaro per supportare anche i mac più datati.
Suggerimenti per la sicurezza
Vi ricordo che Mac OS X ha la capacità di essere configurato in modo da avvisarvi se deve inviare la password in chiaro o disabilitare completamente questo
metodo di autenticazione. Naturalmente il consiglio è quello di lasciare sempre
attivata la funzione di avviso ed eventualmente disabilitare completamente l'invio della password in chiaro.
L'autenticazione DHX è molto più sicura di quella offerta, ad esempio, da Samba. Se i dati che volete condividere con l'esterno non sono sensibili, potete anche rischiare di aprire la porta 548 del vostro firewall al mondo esterno e dirottare questa porta verso il Dreambox. Io non lo farei visto che esistono metodi
più sicuri per farlo.
Se proprio volete procedere per questa via, è essenziale eliminare uams_clrtxt.so nel file di configurazione afpd.conf.
I metodi più sicuri per connettersi dall’esterno tuttavia, sono naturalmente
quelli offerti da ssh, già descritti in dettaglio nella relativa sezione, ed eventualmente l'uso di stunnel. Nel secondo caso dovrete però installare stunnel
anche sulle macchine client e configurarlo in modo appropriato.
Per quanto riguarda invece il tunneling con ssh il server afpd offre una funzio35
Firmware fog per Dreambox 7000
nalità interessante, supportata dal client e dal server AFP di Apple. Con le opzioni di configurazione -advertise_ssh e -fqdn [nomeserver:porta] il
server afpd è in grado di avvisare il client che è disponibile il tunneling attraverso . In tali condizioni il client di Mac OS X è in grado di impostare il tunneling in modo automatico, risparmiandovi di inviare i relativi comandi da terminale.
Il problema è che il parametro nomeserver deve essere un nome di dominio
fully-qualified. Non ho quindi preimpostato tali opzioni nel file afpd.conf. Per
divertimento, e per vedere se la funzionalità descritta funziona sulla vostra rete
locale, potete provare ad inserirle usando dreambox come nomeserver ed
aggiungendo nel file /var/etc/hosts del vostro Mac questa linea:
<ip_Dreambox>
dreambox
Se avete un nome DNS fisso con il quale raggiungere il vostro router (o magari
il Dreambox stesso!), con un po’ d’ingegno potete attivare questa funzionalità e
sfruttarla accedendo da una postazione remota su Internet. Resta tuttavia il
problema che dovrete aprire la porta 548 sul router/firewall e dirottarla su quella del Dreambox (se siete dietro un NAT). Questo sembra necessario affinché il
server afpd possa comunicare al client della possibilità di fare il tunneling.
Sembra che quello che abbiamo fatto uscire dalla porta rientri dalla finestra
(sempre che abbia bene interpretato la documentazione di Netatalk che su
questo punto è un po’ confusa) e il gioco secondo me non vale assolutamente
la candela, soprattutto considerando i problemi che presentano le versioni di
Mac OS pre-Tiger descritti i seguito.
Se proprio volete provare, considerate che, affinché tale funzionalità sia sfruttata sul client Mac OS X, dovrete averne selezionato la relativa impostazione dalla finestra di connessione al server di Mac OS X. Attenzione, perché solo l'ultima versione di Mac OS X, Tiger, ha la capacità di avvisarvi quando il tunneling
non può essere stabilito (anche in questo caso dovrete selezionarne la relativa
opzione dalla finestra di collegamento al server). Pertanto tale funzionalità può
essere definita ‘sicura’ solo usando Tiger, con le versioni precedenti c’è il rischio di connettersi ‘in chiaro’ senza esserne consapevoli.
36
Firmware fog per Dreambox 7000
3 Suggerimenti
In qust’ultima parte mi soffermo su alcuni aspetti legati all’uso di questa immagine dal punto di vista operativo, in parte riepilogando alcuni suggerimenti già
dati precedentemente.
3.1 Dove Installare l’Immagine
Vi consiglio d’installare l’immagine con Flash Wizard o il plugin ‘fwpro’ per
Enigma su un dispositivo di memoria USB o su hard disc, mentre sconsiglio vivamente la sua installazione nella memoria flash del ricevitore e questo per due
motivi:
1) Non ho personalmente testato l’immagine installata nella memoria flash.
Non credo che vi siano problemi in questo tipo d’installazione, tuttavia il
fatto che io non abbia testato questo tipo d’installazione vi dovrebbe
scoraggiare dal provarla.
2) L’immagine, per i vincoli imposti sulla dimensione delle immagini per il
Dreambox 7000, è sprovvista di skins e diverse funzionalità aggiuntive
(offerte nella forma di plugins di Enigma) ormai standard su tutti i firmware a disposizione. Poiché l’installazione su memoria USB o hard disc
ha vincoli di spazio molto meno stringenti di quelli imposti dalla memoria
flash, è molto più facile aggiungere tali funzionalità ed effettuare personalizzazioni, una volta installata, per mezzo del software fornito nell’immagine e le condivisioni preimpostate.
3.2 Appena Installata ’Immagine
Per non vanificare la maggiore sicurezza offerta da questa immagine rispetto
alla maggioranza che si trova in circolazione, naturalmente, la prima cosa da
fare è quella di cambiare la password di default (dreambox) dei tre utenti esistenti (root, dreamadm e dreamuser). Come spiegato precedentemente, una
volta effettuato il login con ssh in questo modo:
ssh dreamadm@<ip_dreambox>
dovrete cambiare sia le passwords di sistema per ogni utente con il comando:
sudo passwd <nome_utente>
sia le passwords di Samba per ogni utente con il comando:
sudo smbpasswd <nome_utente>
Le passwords di root e dreamadm possono essere uguali, infatti dreamadm,
37
Firmware fog per Dreambox 7000
essendo tra i sudoers (gli utenti che possono eseguire il comando sudo) ha la
stessa ‘potenza’ di root mentre root è disabilitato. Vi consiglio invece di usare
una password differente per l’utente dreamuser. Tale utente ed il gruppo relativo dbusers hanno infatti privilegi inferiori rispetto ai precedenti e sono stati inseriti più che altro come prototipi per l’eventuale creazione di nuovi utenti ai
quali non è consentita l’amministrazione della macchina.
3.3 Creazione di Directories e Installazione di files
Per ripristinare alcune delle funzionalità mancanti in questa immagine sarà necessario installare alcuni files in directories esistenti o crearne di nuove per l’installazione. Le sezioni seguenti offrono alcuni consigli su come compiere queste operazioni.
3.3.1 Installazione di Plug-ins, Settings e Skins di Enigma
Come detto precedentemente, l’accesso a /var/tuxbox e quindi alle diverse
directories dove installare plugins, skins e settings, è offerto in lettura e scrittura
mediante i diversi metodi di condivisione descritti precedentemente e cioè FTP
(Vsftpd), SFTP (Open SSH), SMB (Samba) e AFP (Netatalk)
3.3.2 Installazioni in Aree Protette
Per zone protette intendo le directories alle quali è assegnato come proprietario e gruppo l’utente root (uid=0) e il gruppo wheel (gid=0) e che non offrono
l’accesso in scrittura ad altri utenti né sono esportate mediante i diversi servers
di condivisione presenti. In particolare quindi, mi riferisco alle directories /bin,
/sbin, /lib, /etc, /var ed ovviamente la root directory /.
Nonostante l’installazione dell’immagine con Flas Wizard Pro o il plugin fwpro,
consenta la modifica del contenuto delle directories /, /bin, /sbin, /lib,
/etc, la directory normalmente usata per aggiungere nuove funzionalità o modificare la configurazione di funzionalità esistenti è la directory /var.
Per implementare alcune funzionalità assenti in questa immagine (prima fra tutte l’assenza di emus per la decodifica di canali cifrati) può quindi rendersi necessaria la creazione di nuove directories in queste zone protette, in particolare
la directory /var. Il modo più conveniente (anche se meno diretto rispetto a
quanto normalmente siamo abituati a fare) è quello di creare le directories da
terminale con il comando:
sudo mkdir <nuova_directory>
trasferire i files da installare nella nuova directory nella directory /tmp con uno
dei mezzi di condivisione disponibili e quindi spostare con il seguente comando questi files nella directory precedentemente creata con il comando:
sudo mv /tmp/<nuovo_file> /<nuova_directory>
38
Firmware fog per Dreambox 7000
È forse opportuno, per mantenere il livello di sicurezza, impostare proprietario,
gruppo e permessi sulla nuova directory ed i files in essa contenuti in modo
analogo a quelli standard delle aree protette con i seguenti comandi:
sudo chown -R root:wheel /<nuova_directory>
sudo chmod -R go-w /<nuova_directory>
3.3.3 Installazione di Emulatori CA (Emus)
Non sono un grande esperto di emulatori. Tuttavia dalle (poche) informazioni
che ho potuto leggere credo che i più importanti emulatori in circolazione non
richiedano la modifica al codice standard di Enigma per poter funzionare correttamente e possano quindi essere installati e configurati manualmente seguendo le linee guida per l’installazione di files e directories date nella precedente sezione. Non ho fatto ancora test personali a tale proposito e questo
aspetto può al momento essere lasciato al ‘banco di prova’ degli utenti.
Ad ogni modo, è forse utile dare qualche suggerimento di tipo generale. Normalmente gli emulatori vengono installati in /var/bin mentre le eventuali librerie accessorie vengono installate in /var/lib ed i files di configurazione in
/var/etc. È inoltre opportuno modificare i file di init di avvio in modo che
venga avviato l’emulatore desiderato al posto di dccamd.
Per quanto riguarda quest’ultimo aspetto, fate attenzione che il metodo normalmente proposto per l’installazione manuale di diversi emulatori non funzionerebbe (o meglio, funzionerebbe ma diversi servers non verrebbero avviati).
Tale metodo, suggerisce infatti la creazione del file di init /var/etc/init
che bypassa l’avvio di Enigma nello script rcS in /etc/init.d, occupandosi
lui stesso di tale avvio ed avviando al posto di dccamd l’emulatore scelto.
Il funzionamento scorretto di questo metodo dipende da come è stata riorganizzata in questa immagine l’avvio dei diversi servers in rcS e già spiegato precedentemente nella sezione dedicata agli scripts di avvio.
Se, come consigliato, avete installato l’immagine su memoria USB o hard disc,
probabilmente, il modo migliore per avviare un emulatore nella fase di avvio
della
macchina,
è
quello
di
editare
direttamente
lo
script
/etc/init.d/start_enigma commentando la linea in cui compare dccamd
ed inserendo il demone corrispondente all’emulatore scelto. Naturalmente questi sono solo consigli di tipo generale, e non entrano nei dettagli che possono
variare da un emulatore a un altro.
3.4 Creazione di Nuovi Utenti e Gruppi
La creazione di nuovi utenti e gruppi è un’operazione che normalmente richiede un’attenta pianificazione preliminare di privilegi e funzionalità da assegnare
ad essi. A seconda del numero di utenti da inserire e della differenziazione delle
39
Firmware fog per Dreambox 7000
diverse funzionalità, tale operazione può diventare, senza l’ausilio di tools specifici, lunga, noiosa e soprattutto incline agli errori, potendo mettere a rischio la
sicurezza della macchina che fino a quel momento era tenuta sotto controllo.
Nonostante questo, ritengo che l’uso degli applets di Busybox per la gestione
di utenti e gruppi, se usato in modo accorto e consapevole, possa essere sufficente per l’aggiunta di qualche utente, allo scopo di usare il Dreambox come
piccolo NAS personale.
Per mantenere il livello di sicurezza preimpostato è importante seguire questa
semplice linea guida:
ad ogni nuovo utente creato è necessario associare un nuovo gruppo che corrisponde al gruppo principale dell’utente stesso ed inoltre a tale gruppo non
devono appartenere altri utenti.
Questa operazione è svolta in modo automatico dall’applet adduser di Busybox quando non viene forzata l’assegnazione del nuovo utente ad un gruppo
esistente mediante l’opzione -G <nome_gruppo>.
Forse è il caso di dare ulteriori dettagli.
3.4.1 Creazione delle Home Directories
Normalmente la home directory di un utente viene automaticamente impostata
da adduser alla directory /home/<nome_utente> (nell’immagine firmware
/home è in realtà un link simbolico a /var/home). La directory <nome_utente> viene creata automaticamente da adduser con i permessi correttamente
impostati.
Probabilmente /home non è il luogo migliore per la creazione delle home directories. La necessità di creare nuovi utenti per trasformare il Dreambox in un
piccolo NAS ha infatti probabilmente un senso se il Dreambox è provvisto di
hard disc. In questa circostanza è evidente che che le home directories verranno create sull’hard disc. Sarà quindi necessario creare sull’hard disc la directory che conterrà le diverse home directories degli utenti che aggiungeremo nella
fase successiva. Una buona scelta potrebbe essere /hdd/Homes che possiamo creare con:
sudo mkdir /hdd/Homes
Successivamente protremo aggiungere gli utenti con adduser specificando
esplicitamente l’home directory con l’opzione -h.
3.4.2 Esempio di Creazione di Un’utente
Supponiamo di aver creato la directory delle homes directories come nell’esempio precedente e di voler aggiungere l’utente “Mario Rossi” con nome
utente mrossi ed home directory /hdd/Homes/mrossi. Questo può essere
fatto con il seguente comando:
40
Firmware fog per Dreambox 7000
sudo adduser -g “Mario Rossi” -h /hdd/Homes/mrossi
Verrà chiesto l’inserimento della password per l’utente ed una seconda conferma per la stessa.
L’opzione -g consente di specificare il campo GECOS dell’uetente. Il campo
GECOS consente di inserire informazioni specifiche dell’utente. Frequentemente si inserisce in questo campo il nome e cognome dell’utente.
Una volta completato, il comando adduser avrà eseguito le seguenti operazioni:
1) avrà aggiunto l’utente mrossi al file /var/etc/passwd;
2) avrà aggiunto la password di mrossi al file /var/etc/shadow;
3) avrà creato il gruppo mrossi (con gid uguale all’uid dell’utente) nel file
/var/etc/group;
4) avrà creato (se già non esisteva) e con i permessi correttamente impostati la home directory di mrossi /hdd/Homes/mrossi.
Se intendete assegnare al nuovo utente i privilegi particolari corrispondenti ad
uno dei due ‘gruppi di sistema’ preimpostati (cioè dreamadm e dbusers) dovrete editare manualmente con nano il file /var/etc/group con il comando:
sudo nano /var/etc/group
Ad esempio, se volete garantire a mrossi i privilegi di amministratore (corrispondenti principalmente al fatto che l’utente può usare il comando sudo digitando la propria password), la riga del file /var/etc/group relativa al gruppo
admin avrà l’aspetto seguente:
admin:x:80:root,dreamadm,mrossi
Se intendete creare le condivisioni per le homes directories in Samba e/o per
garantire al nuovo utente l’accesso alle condivisioni Samba preimpostate per i
gruppi di sistema (nel caso abbiate aggiunto il nuovo utente ad uno di tali gruppi) sarà necessario aggiungere l’utente mrossi al file /var/etc/smbpasswd
con il comando:
sudo smbpasswd -a mrossi
Verrà, anche in questo caso, chiesta la password seguita da un’ulteriore richiesta di conferma. Questo passo è necessario per garantire l’accesso ai servizi
Samba da parte del nuovo utente per il modo in cui l’autenticazione è stata
configurata in Samba, modo già descritto in dettaglio nella sezione relativa a
questo software.
Per la creazione delle condivisioni delle homes directories in Samba e Netatalk
41
Firmware fog per Dreambox 7000
(non preimpostate nell’immagine firmware) vi rimando alla documentazione ufficiale di questi software.
Per rimuovere in modo completo l’utente mrossi, potrete eseguire in sequenza
le seguenti operazioni:
1) Effettuate, se necessario, un backup della home directory dell’utente
mrossi.
2) Cancellate l’utente mrossi:
sudo deluser mrossi
3) Cancellate il gruppo primario dell’utente mrossi:
sudo delgroup mrossi
4) Rimuovete la home directory dell’utente mrossi:
sudo rm -r /hdd/Homes/mrossi
5) Editate il file /var/etc/group (‘sudo nano /var/etc/group’) eliminando mrossi dai gruppi di sistema ai quali eventualmente era stato
aggiunto.
Purtroppo la versione di Samba presente nell’immagine non consente (tramite
il comando smbpasswd) di cancellare un utente precedentemente inserito nel
file /var/etc/smbpasswd. Pertanto, se avete inserito l’uetnte mrossi anche
nel file /var/etc/smbpasswd, è opportuno cancellare manualmente la riga
corrispondente a mrossi in questo file con nano (‘sudo nano
/var/etc/smbpasswd’).
42
Firmware fog per Dreambox 7000
4 Possibili Evoluzioni
Come detto, questa immagine rappresenta un primo ‘esperimento’ per affrontare in modo abbastanza sistematico le problematiche della sicurezza del nostro Dreambox. È evidente che la forma migliore di distribuzione del software e
delle relative configurazioni in essa contenute, probabilmente sarebbe quella di
‘pacchetto’ da installare su hard disc o su dispositivo di memoria USB in un
modo tale da affiancare ed integrare le funzionalità dei firmware già installati (in
flash, memoria USB o hard disc).
Per il momento non ho voluto affrontare le problematiche correlate ad una tale
forma di distribuzione (che in realtà presenta aspetti più difficili di quanto possa
sembrare ad una prima analisi) e concentrarmi sulla possibilità del raggiungimento di certi obiettivi. Questo non vuol dire che gli utenti già esperti nell’operare da terminale e desiderosi d’implementare una maggiore sicurezza sul
Dreambox, non possano trovare qualche utilità nell’uso di questo firmware.
Penso inoltre che le spiegazioni date nella precedente sezione possano essere
d’aiuto anche agli utenti meno smaliziati.
Se fosse possibile rilasciare questa immagine nella forma di ‘paccheto’ come
sopra descritto, i vincoli imposti sulla dimensione del pacchetto verrebbero
meno e sarebbe possibile pensare a diversi miglioramenti. I primi che mi vengono in mente sono:
1) Preimpostazione dei logs di sistema ed avvio del demone syslogd.
2) Supporto per l’autenticazione PAM (ormai uno standard su quasi tutte le
distribuzioni Linux/Unix)
3) Aggiornamento di alcuni software (i software già presenti nel CVS) alle
versioni più recenti.
4) Inserimento di tools per facilitare la gestione di utenti e gruppi e dei servers.
Per quanto riguarda l’ultimo punto, forse la scelta migliore sarebbe quella dell’installazione di un server Web dedicato allo scopo, quale ad esempio Webmin, che consenta di amministrare in modo semplice ed intuitivo il Dreambox
da un qualsiasi computer connesso in rete al Dreambox.
La scelta di Webmin, che conosco abbastanza bene, comporterebbe anche
l’installazione del linguaggio Perl ed al momento non sono in grado di dire se
microperl (un’interprete Perl rivolto alle installazioni embedded) possa essere
sufficiente, così come non sono in grado di dire se Webmin possa costituire
una via praticabile.
Qualcuno forse potrà obiettare, in parte non a torto, che, rispetto al lavoro fatto, era più semplice cercare di installare una distribuzione standard di Linux sul
Dreambox. Potrei semplicemente rispondere con parte della verità e cioè che a
43
Firmware fog per Dreambox 7000
me piace fare le cose ‘da zero’. In realtà la risposta è più complessa e tra i motivi principali per i quali non ho seguito una via del genere vi sono seguenti:
1) Non volevo far diventare il Dreambox un personal computer
2) Desideravo riesaminare un po’ più da vicino i diversi aspetti coinvolti nella realizzazione di un firmware per Dreambox e la realizzazione di questa
immagine me ne ha dato in parte l’opportunità.
Esistono molti altri aspetti (non affrontati in questa guida) del modo in cui normalmente i diversi firmware disponibili per Dreambox sono strutturati ed installati. Tali modalità si sono consolidate nel corso degli anni e forse sarebbe il
caso di riesaminarle con occhio critico. Tuttavia è probabilmente opportuno lasciare tali aspetti alla discussione e al di fuori di questa guida.
44