Firmware fog per Dreamboxweb.mclink.it/MK0134/pub/dreambox/Guida-fogimg.pdf · Firmware fog per...

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 [email protected].

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.

http://www.info-sat.org/

mailto:[email protected]

Firmware fog per Dreambox 7000

Indice Generale Indice Generale 1 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 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 3 Suggerimenti................................................................................................37

iii


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 4 Possibili Evoluzioni.......................................................................................43

iv


1 1 IntroduzioneQuesto 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.

5



1.1 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 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


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.

7


1.3 1.3 Linee GuidaIn 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 1.3.1 Considerazioni Generali sulla SicurezzaIl 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



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-

9


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.

10


Questi due aspetti sono esaminati nelle due sezioni seguenti.

1.3.2 1.3.2 Livello di Sicurezza Presente nel FirmwareA 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-

11


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 1.3.3 Tipo d'Uso PrevistoI 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


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.

13


2 2 Cosa c’è Sotto al CofanoQualcosa deve pur esserci altrimenti che scrivo a fare?

2.1 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 2.1.1 Kernel LinuxVersione: 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 2.1.2 EnigmaVersione: 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.

15

http://cvs.tuxbox.org/

http://www.kernel.org/


2.1.3 2.1.3 Scripts di InitPoiché 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:

16


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-

17


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 2.1.4 Utenti, Gruppi Preimpostati e PasswordsLa 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


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 <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 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.

19


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 2.1.5 Software BusyboxVersione: 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.

20

http://www.busybox.net/


2.1.6 2.1.6 Shadow PasswordsVersione: 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 2.1.7 Software di Rete Avviato da inetdIn 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 2.1.7.1 Server TelnetVersione: 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.


Nessuno tranne quello di non avviare telnetd riabilitando il server in inetd.conf!

2.1.7.2 2.1.7.2 Server FTP VsftpdVersione: 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.

21

http://vsftpd.beasts.org/


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.


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

http://vsftpd.beasts.org/vsftpd_conf.html


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 2.1.8 Software di Rete Standalone Avviato da Enigma

2.1.8.1 2.1.8.1 Software SambaVersione: 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).

23

http://www.samba.org/


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'im-postazione 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.


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 confi-gurazione di Samba, unix password sync, che se impostata a yes, do-vrebbe consentire, con il comando smbpasswd, il cambiamento contempora-neo della password di Samba e di quella di sistema.

Questo parametro è correntemente impostato nel file smb.conf, tuttavia smb-passwd non funziona come previsto e le passwords non vengono sincronizza-te. In un primo momento pensavo che il problema fosse dovuto alla non corret-ta impostazione di un'altro parametro, passwd chat, ma dopo una serie infi-nita di tentativi ho desistito, anche perché ho constatato su Internet che moltis-simi 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 sempli-cemente inviando il comando smbpasswd senza sudo e senza il nome dell'u-tente. 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 pas-

24


sword di sistema. Certo che se le cose funzionassero come dovrebbero, usan-do 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 Sam-ba.

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 crip-tata 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 mi-nuti 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 è suf-ficiente 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 ma-nager 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 an-che le passwords trasmesse sulla rete per autenticarsi, come se fossero pas-swords 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 confi-gurazione potrebbe risultare un po' più complicata perché dovrete aggiustare le cose sia lato client che server.

2.1.8.2 2.1.8.2 Interfaccia Web di EnigmaL'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 se-

25


zione relativa a queso software.

2.2 2.2 Principale Software Extra Contenuto nell'ImmagineSeguono le descrizioni per il software non standard presente nell'immagine.

2.2.1 2.2.1 Software SudoVersione: 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 ri-nunciare, 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 se-tuid impostato.

Oltre a questo vi è da dire che sudo prevede una serie di funzionalità aggiunti-ve 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.


Se intendete editare il file di configurazione /var/etc/sudoers, usate sem-pre il comando visudo preposto allo scopo. Questo infatti, oltre ad eseguire il lock del file sudoers per prevenire eventuali modifiche contemporanee effet-tuate 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 configurazio-ne mal formata. Se il file sudoers fosse infatti mal formato, il comando sudo rifiuterebbe l'esecuzione tagliandovi fuori dall'amministrazione della macchina.

26

http://www.gratisoft.us/sudo/


2.2.2 2.2.2 Editor NanoVersione: 1.2.4 (Disponibile nel CVS)

Links: http://www.nano-editor.org

L'editor ‘facile facile’ anche per principianti. Usato anche da visudo (vedi so-pra) 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 2.2.3 Libreria OpenSSLVersione: 0.9.7a (Disponibile nel CVS)

Links: http://www.openssl.org

La libreria OpenSSL è un pezzo ‘da novanta’ e non credo abbia bisogno di pre-sentazioni, 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 li-breria ed è stato risolto con le ultime versioni nei rispettivi branch. Non ho in-stalato una versione più recente per i motivi precedentemente esposti ed an-che 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 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 dimen-sione finale dell’immagine. Non credo, tuttavia che questa sia una grande man-canza.

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 an-che 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

http://www.openssh.com/portable.html

http://www.openssh.com/

http://www.openssl.org/

http://www.nano-editor.org/


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 ser-ver 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ò connet-tere 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 (po-tremmo 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 con-temporaneamente, 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 sul-la 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 connet-tendosi 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_Dream-box>: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 smb-mount, il comando per montare i volumi condivisi da Samba o servers Windo-ws, 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 condivi-sioni SMB, non accetta la specificazione di una porta diversa da quella di de-

28


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 spe-cificazione di porte alternative, quindi è probabile che questa funzionalità ven-ga aggiunta in futuro anche a Mac OS X. Su Mac OS X quindi, per fare il tunne-ling 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 necessa-rio che la porta 139 non sia già aperta, che non sia cioè in funzione sul compu-ter client il server Samba.

In connessioni ai servers dall'esterno (da Internet) mediante tunneling (la situa-zione più comune per la quale è conveniente usare il tunneling) è assai proba-bile 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 de-fault 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ò di-ventare 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 fun-zione.

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. At-traverso connessioni Wireless a 54Mb/s il trasferimento di files di grosse di-mensioni è 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 infe-riore) 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


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. No-nostante questo, il punto 2, se intendete avviare syslogd, è da tenere in con-siderazione 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 si-curo 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 evi-denziato gli aspetti che mi sembravano più interessanti. Per un suo uso avan-zato (quale la connessione senza password) vi rimando alla documentazio-ne.ufficiale.


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 sicurez-za potete allora decidere di rigenerare le chiavi di sshd in /var/etc/ssh con sudo ssh-keygen … Fate riferimento alla documentazione ufficiale per mag-giori 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 preim-postata 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 sa-pete già da quali indirizzi ip effettuerete le connessioni, potete imporre voi stes-si le restrizioni adeguate per sshd nel file /var/etc/hosts.allow.

30


Il software OpenSSH in questa immagine è lo strumento principale per connet-tersi 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 con-nettersi 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 vo-lete aggiungere ancora un po’ di sicurezza, potete modificare il files di configu-razione /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 aper-te sugli hosts connessi ad internet alla ricerca di quelle più sensibili e potenzia-le bersaglio di un potenziale attacco.

2.2.5 2.2.5 Software StunnelVersione: 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 protocol-lo SSL le comunicazioni tra un software client e un software server in modo tra-sparente 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 soft-ware client e da quello server, sulle macchine dove è necessario offrire il sup-porto 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 sfrut-tando le possibilità di secure shell descritte sopra. La principale differenza ri-spetto a quest'ultimo metodo di protezione è la maggiore trasparenza per l'u-tente, una volta installato e configurato correttamente, ed il supporto per SSL-v3/TLSv1 e l'autenticazione mediante certificati digitali.

In questa immagine stunnel è configurato per offrire i servizi SSLv3 all'inter-faccia 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 ca-tena e questo è il modo migliore che ho trovato per porvi riparo, anche se par-zialmente. Un ulteriore passo per rendere il Dreambox ancora più sicuro, sareb-be quello di modificare il codice di Enigma in modo tale da offrire una configu-razione 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

http://www.stunnel.org/

http://stunnel.mirt.net/


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 direc-tory /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 restri-zioni 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 al-tri servers, perché penso che l'uso di SSL sia adeguato per connessioni dall'e-sterno della vostra rete (da Internet).


Il certificato digitale autofirmato (self signed) /var/etc/stunnel/stun-nel.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 ade-guato 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 acce-dere 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 sy-slogd qualora decidiate di attivarlo in fase di avvio.

2.2.6 2.2.6 Software TCP WrappersVersione: 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 ser-vers 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 sup-porto al software che desidera gestire direttamente questi meccanismi di pro-tezione. Normalmente i software che includono il supporto per tale libreria ven-gono 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

http://ftp.porcupine.org/pub/security/index.html

http://www.porcupine.org/


Il demone tcpd è invece in grado di offrire il meccanismo di protezione descrit-to, a tutti i software lanciati da inetd. In pratica inetd, invece di lanciare di-rettamente il server per il quale si desidera la protezione descritta, avvia il de-mone 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 pos-sa 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 con-trollo dei pacchetti sia in entrata che in uscita. Un firewall inoltre è sempre ‘in li-nea’ 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 fi-rewall 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 fi-les 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 in-fatti 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 è normalmen-te impiegata per connessioni dirette da pc a pc o quando il client dhcp non rie-sce 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 inseri-re ben 16 blocchi separati, cosa che naturalmente ho evitato di fare. Per coe-renza 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 que-sti.

33


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 approfondi-menti sulla sintassi dei file hosts.allow e hosts.deny vi rimando al sito dell'auto-re.


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 2.2.7 Libreria Berkeley DBVersione: 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 ne-cessaria in quanto prerequisito essenziale del pacchetto Netatalk. Ho installato non solo la libreria ma anche i tools per la gestione dei databases creati da Ne-tatalk, in quanto potrebbero rivelarsi utili nel caso in futuro si dovessero riscon-trare 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 2.2.8 Software NetatalkVersione: 2.0.3

Links: http://netatalk.sourceforge.net

Una sommaria descrizione dei servizi AFP e del protocollo AppleTalk è gia sta-ta nella premessa, pertanto evito di ripetermi.

L'installazione Netatalk offerta è ‘quasi’ completa. Le mancanze di maggior ri-lievo da segnalare sono la mancanza del supporto al sistema di stampa CUPS e la mancanza del supporto all'autenticazione tramite Kerberos. Ho tuttavia in-stallato 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 diffi-cile 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

http://netatalk.sourceforge.net/

http://www.oracle.com/database/berkeley-db/index.html


servers (smbd di Samba e afpd di Netatalk) vi sconsiglio di montare contempo-raneamente le stessa condivisione con SMB e AFP, perché potrebbero verifi-carsi problemi dovuti al lock dei files.

Probabilmente, visto che i due servers offrono funzionalità simili, la scelta mi-gliore è 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'accor-tezza 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 van-tarmi un po’, infatti, dopo uno scambio di opinioni con uno dei programmatori sulla mailing lists di Netatalk, alcune delle mie piccole modifiche fanno ora par-te 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'au-tenticazione in chiaro per supportare anche i mac più datati.


Vi ricordo che Mac OS X ha la capacità di essere configurato in modo da avvi-sarvi 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'in-vio della password in chiaro.

L'autenticazione DHX è molto più sicura di quella offerta, ad esempio, da Sam-ba. Se i dati che volete condividere con l'esterno non sono sensibili, potete an-che rischiare di aprire la porta 548 del vostro firewall al mondo esterno e dirot-tare 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_clr-txt.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 eventual-mente 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 funzio-

35


nalità interessante, supportata dal client e dal server AFP di Apple. Con le op-zioni di configurazione -advertise_ssh e -fqdn [nomeserver:porta] il server afpd è in grado di avvisare il client che è disponibile il tunneling attra-verso . In tali condizioni il client di Mac OS X è in grado di impostare il tunne-ling in modo automatico, risparmiandovi di inviare i relativi comandi da termi-nale.

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 quel-la 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 sfrutta-ta sul client Mac OS X, dovrete averne selezionato la relativa impostazione dal-la finestra di connessione al server di Mac OS X. Attenzione, perché solo l'ulti-ma 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 ri-schio di connettersi ‘in chiaro’ senza esserne consapevoli.

36


3 3 SuggerimentiIn qust’ultima parte mi soffermo su alcuni aspetti legati all’uso di questa imma-gine dal punto di vista operativo, in parte riepilogando alcuni suggerimenti già dati precedentemente.

3.1 3.1 Dove Installare l’ImmagineVi 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 vi-vamente 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 firm-ware 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 persona-lizzazioni, una volta installata, per mezzo del software fornito nell’imma-gine e le condivisioni preimpostate.

3.2 3.2 Appena Installata ’ImmaginePer 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 esi-stenti (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


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 relati-vo dbusers hanno infatti privilegi inferiori rispetto ai precedenti e sono stati in-seriti più che altro come prototipi per l’eventuale creazione di nuovi utenti ai quali non è consentita l’amministrazione della macchina.

3.3 3.3 Creazione di Directories e Installazione di filesPer ripristinare alcune delle funzionalità mancanti in questa immagine sarà ne-cessario installare alcuni files in directories esistenti o crearne di nuove per l’in-stallazione. Le sezioni seguenti offrono alcuni consigli su come compiere que-ste operazioni.

3.3.1 3.3.1 Installazione di Plug-ins, Settings e Skins di EnigmaCome 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 3.3.2 Installazioni in Aree ProtettePer zone protette intendo le directories alle quali è assegnato come proprieta-rio 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 mo-dificare la configurazione di funzionalità esistenti è la directory /var.

Per implementare alcune funzionalità assenti in questa immagine (prima fra tut-te l’assenza di emus per la decodifica di canali cifrati) può quindi rendersi ne-cessaria 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 coman-do questi files nella directory precedentemente creata con il comando:

sudo mv /tmp/<nuovo_file> /<nuova_directory>

38


È 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 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 cor-rettamente e possano quindi essere installati e configurati manualmente se-guendo le linee guida per l’installazione di files e directories date nella prece-dente 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. Nor-malmente gli emulatori vengono installati in /var/bin mentre le eventuali li-brerie 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 nor-malmente proposto per l’installazione manuale di diversi emulatori non funzio-nerebbe (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 riorga-nizzata in questa immagine l’avvio dei diversi servers in rcS e già spiegato pre-cedentemente 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 que-sti sono solo consigli di tipo generale, e non entrano nei dettagli che possono variare da un emulatore a un altro.

3.4 3.4 Creazione di Nuovi Utenti e GruppiLa creazione di nuovi utenti e gruppi è un’operazione che normalmente richie-de 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


diverse funzionalità, tale operazione può diventare, senza l’ausilio di tools spe-cifici, 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 suffi-cente 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 cor-risponde 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 Busy-box 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 3.4.1 Creazione delle Home DirectoriesNormalmente 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_uten-te> viene creata automaticamente da adduser con i permessi correttamente impostati.

Probabilmente /home non è il luogo migliore per la creazione delle home direc-tories. 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 verran-no create sull’hard disc. Sarà quindi necessario creare sull’hard disc la directo-ry che conterrà le diverse home directories degli utenti che aggiungeremo nella fase successiva. Una buona scelta potrebbe essere /hdd/Homes che possia-mo 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 3.4.2 Esempio di Creazione di Un’utenteSupponiamo di aver creato la directory delle homes directories come nell’e-sempio 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


sudo adduser -g “Mario Rossi” -h /hdd/Homes/mrossi

Verrà chiesto l’inserimento della password per l’utente ed una seconda confer-ma per la stessa.

L’opzione -g consente di specificare il campo GECOS dell’uetente. Il campo GECOS consente di inserire informazioni specifiche dell’utente. Frequentemen-te si inserisce in questo campo il nome e cognome dell’utente.

Una volta completato, il comando adduser avrà eseguito le seguenti opera-zioni:

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 impo-stati 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) dovre-te 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 (corri-spondenti principalmente al fatto che l’utente può usare il comando sudo digi-tando 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 grup-pi) 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 richie-sta 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


(non preimpostate nell’immagine firmware) vi rimando alla documentazione uf-ficiale 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’) eli-minando 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


4 4 Possibili EvoluzioniCome detto, questa immagine rappresenta un primo ‘esperimento’ per affron-tare in modo abbastanza sistematico le problematiche della sicurezza del no-stro 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 raggiungi-mento di certi obiettivi. Questo non vuol dire che gli utenti già esperti nell’ope-rare 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 ven-gono 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 ser-vers.

Per quanto riguarda l’ultimo punto, forse la scelta migliore sarebbe quella del-l’installazione di un server Web dedicato allo scopo, quale ad esempio Web-min, 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 fat-to, 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


me piace fare le cose ‘da zero’. In realtà la risposta è più complessa e tra i mo-tivi 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 nel-la 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 nor-malmente i diversi firmware disponibili per Dreambox sono strutturati ed instal-lati. Tali modalità si sono consolidate nel corso degli anni e forse sarebbe il caso di riesaminarle con occhio critico. Tuttavia è probabilmente opportuno la-sciare tali aspetti alla discussione e al di fuori di questa guida.

44

Firmware fog per Dreamboxweb.mclink.it/MK0134/pub/dreambox/Guida-fogimg.pdf · Firmware fog per...

Documents

Transcript of Firmware fog per Dreamboxweb.mclink.it/MK0134/pub/dreambox/Guida-fogimg.pdf · Firmware fog per...