Firmware fog per Dreambox - e altro
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Firmware fog per Dreambox
… e altro
Autore: fog (alias fog@infosat sui forums di www.info-sat.org). Tutti i diritti riser-
vati. Per qualsiasi ridistribuzione o uso del contenuto del presente documento
inviare una richiesta a mk0134@mclink.it.
Responsabilità: L'autore declina ogni responsabilità per qualsiasi danno imputa-
bile ad inesattezze o errori contenuti nella presente guida o nel software (firm-
ware) 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
iiiFirmware 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
ivFirmware fog per Dreambox 7000
1 Introduzione
Questo firmware, espressamente realizzato per il Dreambox 7000, nasce ini-
zialmente per gioco e per sperimentare e mettere un po’ ‘sotto torchio’ su Mac
OS X il cross developement kit del Dreambox. Recentemente sono infatti riusci-
to, 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 con-
figurazione 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 pro-
tocollo 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 que-
sta immagine possa fare contenti gli utenti Mac. Il protocollo Appletalk su
Mac OS X è stato affiancato dal più recente Rendezvous/Bonjour che of-
fre 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 ser-
ver e il trasferimento dei files avviene sempre mediante connessioni
TCP/IP), sulle versioni precedenti dell'OS del Mac, Appletalk può (in alcu-
ni casi deve, come nella versioni di Mac OS precedenti la 8) anche esse-
re 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.
5Firmware 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 rimar- rete 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 Dream- box ed al momento non ho assolutamente intenzione né la possibilità di com- petere con chi da anni ha accumulato una notevole esperienza nella program- mazione 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 speran- ze iniziali riposte nella casa madre sono state, nel corso degli anni, in gran par- te disattese. La seconda ragione è che, se anche avessi tempi e mezzi per fare una rivolu- zione, probabilmente le prime attenzioni si rivolgerebbero in ogni caso alla co- struzione 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. Chiun- que 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 'fortifi- care' 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, installa- ta su pen USB o Hard disc da arricchire con i plugins indispensabili (e purtrop- po 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 bi- naries installati. Ad esempio copiare semplicemente sudo o afpd e relativa li- breria libatalk.so potrebbe non funzionare in quanto tali software potreb- bero avere bisogno di funzioni presenti in altre librerie (libc.so ad esempio) che sull'immagine scelta come base d'installazione potrebbero essere non pre- senti. 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 cor-
so del tempo. Se anche da un lato offre discrete possibilità di personalizzazio-
ne ed addizione di nuove funzionalità (skins e plugins) la struttura principale ri-
sulta poco modulare e strutturata. A tale proposito e solo a titolo di esempio
basti pensare al fatto che il percorso per le registrazioni è codificato diretta-
mente all'interno del codice (che mi ricordi esiste appena una direttiva #defi-
ne 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 mo-
dello 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 di-
versi 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 ab-
biamo incitato una sorta di 'gara all'immagine più bella e più stabile'. La situa-
zione 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 immagi-
ne spesso si limita alla scelta di quale software includere o meno. Niente o
quasi, per continuare con gli esempi, è stato fatto per facilitare il programmato-
re o anche l'utente esperto per la realizzazione in un modo standard di pac-
chetti software da installare su hard disc o dispositivi di memoria USB. É evi-
dente che da utente Mac ho il palato esigente, tuttavia non pretendo l'esisten-
za 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 paragona-
bili 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.
7Firmware 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 pre- cedentemente, ha lo scopo di rendere il nostro Dreambox un po’ più sicuro. Scusate se alcune divagazioni possono sembrare sproporzionate all'argomen- to trattato, anché perché sicuramente lo sono. Ci siamo spesso incontrati sui forum di http://www.info-sat.org/ (sul quale que- sta 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 pro- babilmente mi conoscono già come un gran chiaccherone e non voglio smen- tirmi. 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 si- curo 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 matema- tiche 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'intrec- cio 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 si- curezza giudicata inizialmente accettabile non è detto che questa rimanga tale, senza ulteriori e continui sforzi di miglioramento e di monitoraggio. Di grandez- za 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 ul- timo, 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 esi- stono esempi molto più sottili). Un'aspetto della sicurezza, che in alcuni casi diventa paradossale, è che que- sta è più facile da implementare in una serie di casi estremi e a due a due op- posti e che dal punto di vista concettuale corrispondono a situazioni del tipo 'o tutto o nulla'. Ad esempio è molto più facile raggiungere una sicurezza accetta- 8
Firmware fog per Dreambox 7000
bile nei due casi limite:
1) Un computer la cui unica funzione sia quella di offrire un servizio al mon-
do intero (ad esempio un server FTP con accesso anonimo).
2) Un computer usato per memorizzare dati sensibili ma che non debba for-
nire 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 situazio-
ne reale è ben diversa, con frequenza sempre maggiore, infatti, assistiamo al ri-
lascio di aggiornamenti software il cui solo scopo è quello di tappare falle o ri-
parare 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 pre-
sentano 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à ter-
mine 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 sovrapposi-
zione tra determinate funzioni, giocano un ruolo importante sia per quanto ri-
guarda l'analisi dello stato di sicurezza di un determinato sistema sia per quan-
to riguarda l'implementazione di un determinato livello di sicurezza in casi con-
creti. Non poteva essere altrimenti, visto che in ogni situazione reale comples-
sa ci comportiamo più o meno nello stesso modo: cerchiamo di scomporla o
rappresentarla nel minor numero di aspetti indipendenti. Il concetto di ortogo-
nalità, 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'indipenden-
za per scomporre, inquadrare, classificare … una teoria, un'equazione … pro-
babilmente 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 si-
9Firmware 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 implementa-
re un servizio di home-banking su una macchina che contemporaneamente of-
fre 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 rag-
giungere il grado di sicurezza desiderato, tanto più facile sarà mantenere tale li-
vello di sicurezza nel corso del tempo o incrementare il livello di sicurezza qua-
lora 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 desi-
derato, è 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 offro-
no 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 pen-
sare 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, tra-
sformandolo nell'anello più debole e fragile dell'intera catena (e con que-
sto torniamo al discorso sull'ortogonalità).
Meglio scendere di piano, perché il fumo che vedo ora è diventato nero! Que-
sta 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.
10Firmware 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, an-
che 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 accetta-
bile.
D'accordo, ma cosa vuol dire accettabile?
Accettabile vuol dire introdurre una serie di strumenti universalmente ricono-
sciuti 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 clas-
sico dilemma dell'uovo e della gallina ed in un certo senso è proprio così. For-
se è meglio passare direttamente all'esemplificazione.
Molti di noi, almeno quelli abituati ad usare un sistema Linux o UNIX, hanno di-
mestichezza con i tools fondamentali ed i criteri impiegati per ottenere la sicu-
rezza di ‘base’ in una macchina multiutente basata su UNIX o ad esso ispirata.
Tools quali sudo, l'impostazione data dal meccanismo delle Shadow Pas-
swords, la disabilitazione dell'utente root, … sono tutte cose che probabilmen-
te 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 emer-
gere, visto che, ad esempio, le Shadow Passwords erano già supportate) il no-
stro Dreambox di questi strumenti o impostazioni, in modo da farlo assomiglia-
re 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 sicu-
rezza, 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 conside-
rando 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 total-
11Firmware 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'a- spetto 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 comu- ne 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 aggior- namento 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 esperi- mento 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 pensan- do ad un uso degli stessi di tipo privato e personale o da parte di utenti di fidu- cia su una rete locale o anche attraverso internet per mezzo degli strumenti forniti (il server SSH e Stunnel). Devo inoltre sottolineare che, qualora il Dream- box sia collegato in una rete permanentemente connessa ad Internet (caso or- mai frequente) tramite un router, ritengo indispensabile, per completare il qua- dro di sicurezza preimpostato, che quest'ultimo o altro dispositivo svolga an- che le funzioni di firewall per la rete. Credo che l'ultimo requisito sia frequente- mente rispettato visto che, nella maggioranza dei casi, la connessione perma- nente 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 incondizio- 12
Firmware fog per Dreambox 7000
nato o ad utenti non di fiducia al server FTP) siete sulle vostre gambe. Mi rac-
comando solo, in questo caso, di leggere attentamente i manuali di configura-
zione dei vari servers e soprattutto (vedi discorsi sull'ortogonalità) di non me-
scolare 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 com-
pletamento del quadro di sicurezza, nelle spiegazioni che seguono, relative al
software installato, dò qualche consiglio sulle configurazioni più opportune per
questo dispositivo.
13Firmware 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'obiet-
tivo. È 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 aggiunti-
vi. 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 ver-
sione del kernel di Linux. Infatti se anche è vero che i sorgenti di base corrison-
dono a questa versione è altrettanto vero che questi sono 'pesantemente' mo-
dificati 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 ulti-
me corrisspondono a loro volta, in discreta parte, alla configurazione del ker-
nel, eseguita in batch prima della compilazionene del kernel stesso. Secondo il
mio modo di vedere, in questa situazione, è difficile attribuire una corrispon-
denza del numero di versione del kernel del Dreambox con quelle ufficiali e di-
sponibili nel source tree di riferimento del kernel di Linux.
Rispetto alla versione normalmente compilata con i firmware ufficiali, Ho ag-
giunto i moduli di rete necessarri per il supporto del protocollo AppleTalk. I mo-
duli 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'im-
magine, ad eliminare tutti i plugins e gli skins extra (ad eccezione dello skin
Small usato come default) normalmente presenti anche nelle immagini ufficiali.
15Firmware 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 sostan-
ziale) lo script di init rcS in modo da aggirare tale comportamento. Nelle im-
magini ufficiali (ed anche in tutte quelle di sviluppatori indipendenti che ho avu-
to 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 teleco-
mando (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 fla-
shtool veniva eseguito a seguito di una nuova installazione firmware, ho im-
piegato un po' di tempo a recuperare il codice di uscita da Enigma quando vie-
ne eseguito un aggiornamento del software in flash, ancora una volta a confer-
ma della scarsa linearità e intricatezza del software Enigma che inoltre è prati-
camente sprovvisto di documentazione o codice ben commentato.
In ogni modo, quello che è importante osservare ai nostri fini è che, per la pre-
senza del loop ora descritto, lo script rcS resta in esecuzione per tutto il tem-
po 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 even-
tualmente presente, normalmente usato per 'customizzare' il boot del Dream-
box da parte dell'utente). Questo fatto crea un problema per l'avvio di tutti i de-
moni di rete che hanno bisogno di conoscere lo stato e l'indirizzo IP dell'inter-
faccia 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 back-
ground da rcS che monitora lo stato dell'interfaccia ethernet e non appena ri-
leva 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 se-
guenti operazioni:
16Firmware 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 .DreamboxSetupDo-
ne e per le ragioni di questa impostazione vedi la sezione successiva ri-
guardo gli utenti preimpostati sul sistema)
2) Ad ogni avvio imposta i permessi su /tmp in modo tale che il gruppo ad-
min abbia i permessi in lettura e scrittura (per i motivi vedi anche in que-
sto caso la sezione successiva riguardo gli utenti preimpostati sul siste-
ma) 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 cor-
retto funzionamento di Netatalk e Samba e forza Samba (che eventual-
mente è 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 fun-
zionato, 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'in-
terfaccia 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 in-
corporato 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 an-
che 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 (customizza-
zione 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. Probabil-
mente fwpro, che modifica lo script rcS, fa delle assunzioni precise sulla posi-
zione di alcuni elementi in rcS. Il risultato, spostando /var/etc/init in fon-
do 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 Enig-
17Firmware 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, pos- sono 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 impor- tante conoscere stato e configurazione della rete. L'intera procedura di avvio probabilmente non è sufficientemente robusta (soprattutto se pensiamo a quel- lo 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 infor- ma 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 è natural- mente costituito dall'arcinoto comando sudo (vedi più avanti) e l'utente preim- postato per i compiti amministrativi (facente parte cioè dei sudoers) è drea- madm. Ho anche creato un'altro utente meno privilegiato: dreamuser. Le home direc- tories 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 corri- spondono 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 facilita- zione 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, na-
turalmente 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 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 al-
tri 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 se-
tuid impostato, sul Dreambox questo non accade e per motivi di sicurezza non
conviene assolutamente impostarlo. Il comando passwd è infatti un link simbo-
lico 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 possi-
bile 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 se-
paratamente 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 interpun-
zione, 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 pas-
swords molto lunghe si preferisce usare il termine passphrases perché in que-
sto caso può essere abbastanza sicuro usare la giustapposizione di parole an-
che presenti in un dizionario) mentre le passwords di tipo crypt sono limitate ad
8 caratteri, quelli forniti in eccesso vengono infatti eliminati dall'algoritmo.
19Firmware fog per Dreambox 7000
C'è ancora di più: il comando passwd con l'opzione -a sha1 genera la pas-
sword 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 racchiu-
de 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 me-
diante 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 Busy-
box 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 Busy-
box 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'im-
magine 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.
20Firmware 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ù regi-
strata 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 sup-
porto 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 at-
traverso 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 comple-
tamente 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 ‘confi-
nare’ 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 di-
rectories 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 quan-
to 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.
21Firmware 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 ac- cesso all'intero file system del Dreambox. Suggerimento: inserite, nel file /var/etc/vsftpd.chroot_list, l'elenco degli utenti per i quali desidera- te disabilitare la funzionalità di essere confinati alla propria home directory Attenzione, il precedente suggerimento ha l'effetto desiderato in quanto l'op- zione chroot_local_user in vsftpd.conf è stata abilitata, se non lo fos- se, 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/tux- box (in particolare sui files in /var/etc/, /bin e /sbin) anche per quanto ri- guarda 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 dis- solverà. 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 diver- se discussioni illuminanti in proposito. Proprio per questo, Vsftpd è stato co- struito 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 vo- stro 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 norma- le 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 que- sto protocollo. 22
Firmware fog per Dreambox 7000
In futuro, se sarà fattibile l'installazione dell'ultima versione di Vsftpd con il sup-
porto 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 com-
pletamente riscritto e vi consiglio di dargli un'occhiata in quanto ho commenta-
to i punti più importanti.
Da segnalare:
1) Autenticazione mediante passwords cifrate (le passwords per l'autentica-
zione di Samba risiedono nel file separato /var/etc/smbpasswd ac-
cessibile 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 re-
lativa al pacchetto Tcp Wrappers (Samba ha le funzioni della libreria dei
Tcp Wrappers built-in ed il codice relativo è stato adattato a Samba pren-
dendolo proprio dal pacchetto Tcp Wrappers)
4) Due condivisioni impostate e attivate:
EnigmaConf che corrisponde a /var/tuxbox ed è accessibile dal grup-
po 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 com-
mentate 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 ad-
min e dbusers e quindi dagli utenti dreamadm e dreamuser (serve ovvia-
mente per scaricare le registrazioni sull'hard disc del Dreambox).
23Puoi anche leggere
