Spero che nessuno abbia a male per quello che sto per scrivere. In effetti è stato scritto qualche tempo fa e ci sono delle inesattezze (ad esempio quando si parla di Decreto Legge Urbani mi riferisco alla primissima versione), e poi non sono mai stato un grosso esperto di sicurezza. Sono solo i miei 2 euro-centesimi.
Documento sulla sicurezza
Salve a tutti, sono Flameeyes. So di non essere molto conosciuto come personalità, almeno sulla rete italiana, ma alcuni di voi potrebbero conoscermi per essere il maintainer dei driver LIRC per il kernel 2.6, oppure per i file ebuild per gentoo non ufficiali che creo e distribuisco sul mio sito.
In questo documento vorrei poter dire qualcosa a riguardo della sicurezza. Si tratta di un argomento che mi sta molto a cuore, almeno negli ultimi tempi.
Storia di una sicurezza
Devo ammettere che non ero un patito della sicurezza fino a qualche tempo fa, ma quando poi ho letto il libro di Mitnick “L’arte dell’inganno”, ho cominciato a pensare che le norme di completa sicurezza che stavo ignorando per il mio sistema locale, poi sarebbero andate dimenticate quando mi sarei messo a lavorare seriamente, fino a rendere il mio lavoro rischioso e attaccabile facilmente.
Ho cominciato quindi col cambiare utente principale, passare ad un utente non privilegiato anziché entrare direttamente con root, a impostare delle password differenziate dove ce ne fosse stato bisogno, e poi, quando ho acquistato il mio iBook, a cominciare a rendere sicura la mia connessione di rete.
Ho iniziato a considerare preziose le informazioni che avevo memorizzate sul sistema e ho pensato bene di non permettere in ogni caso l’accesso a tutto il filesystem con samba, anche se era impostato per aprirsi solo sull’interfaccia di rete che dà alla mia rete privata.
Poi è venuto il Decreto Legge Urbani, che io intendo come un attacco alla privacy degli individui. Con questa legge, i provider dovrebbero cominciare a loggare tutti i dati che passano sulle linee degli utenti. Oltre che molto dispendiosa come pratica, e quindi dubito effettivamente ci saranno ISP che lo faranno, questo significherebbe lasciare disponibili a qualsiasi tecnico dell’isp tutti i dati che solitamente si mandano in clear text.
Come poter risolvere tutto questo?
Innanzitutto ho pensato che con il portatile ora a mia disponsizione, avrei voluto probabilmente accedere da remoto ai dati del mio MLdonkey, ma che non volevo assolutamente che il mio isp, o i tecnici della eventuale rete locale da cui mi collegavo (solitamente da scuola) potessero sniffare la mia password di accesso o i dati che MLdonkey mi spediva. Per risolvere tutto questo ho voluto preparmi un certificato self-signed da assegnare ad Apache, e poi si è risolto tutto semplicemente reimpostando Apache in modo da proxare le richieste fatte sulla connessione ssl (aperta all’ip pubblico) sulla connessione webadmin di mldonkey (aperta solo sull’ip locale). In questo modo, non sarebbero stati possibili sniffing dei dati di passaggio.
Il problema successivo era la gestione delle email: volevo poter accedere all’elenco delle mie email da qualsiasi punto mi trovassi, sia in rete locale, sia in esterno, sia con defiant (il mio pc fisso/server) sia con voyager (il portatile iBook). Un’alternativa era data dall’uso di IMAP4, ma lasciare le mie email, anche quando non strettamente personali, sul server del mio ISP non mi divertiva affatto. Aggiungiamo che i server del mio ISP non sono accessibili dall’esterno della loro rete, e abbiamo capito in che guaio ero. Ho cominciato a vagliare tutte le possibilità, finché ho capito che la cosa migliore era impostare un server IMAP4 direttamente sul mio computer e accedere a quello anche da voyager.
Come server ho usato tutta la suite Courier, che mi ha fornito praticamente tutto quello di cui avevo bisogno, senza andare a perder tempo con qmail, postfix od altro.
Certo, potreste dire che a questo punto non siamo in una situazione di sicurezza estrema (qmail è solitamente considerato tale), e ammetto di aver scelto Courier più che altro per la facilità di configurazione e installazione, senza andare a controllare effettivamente se c’erano state vulnerabilità aperte ultimamente, ma passatemi che questa soluzione sia più sicura di quella di tenere tutto sui server del proprio provider.
Con fetchmail, ho impostato il recupero di tutta la mia posta dalle varie caselle che utilizzo, e il reinoltro su una casella locale, a cui courier è configurato per filtrare la posta tramite il suo maildrop, così da cancellare almeno parte dello spam e organizzare in un albero decente le mailing lists, come facevo prima con KMail. Per evitare di saturare la banda, ma al tempo stesso minimizzare il tempo in cui le email restano a disposizione sul server del provider, ho deciso di impostare il tempo di fetch a 5 minuti. In questo modo, la posta rimane per un minimo tempo sul server del provider, ed è poi disponibile sul mio, dove posso godere di maggior fiducia sull’accesso fisico alla macchina.
Per finire, per mettere a disposzione di voyager le email anche quando non sono in casa, ho deciso di impostare anche Courier over SSL, così da cifrare tutta la comunicazione che avviene tra voyager e defiant.
Il problema ora resta l’invio della posta, che avviene sempre tramite il server smtp del mio provider, o, peggio, che non riesce ad essere eseguito perché non sono connesso con la connessione del provider. Purtroppo questo problema devo ancora risolverlo, perché se impostassi Courier per permettere l’invio autenticato delle mail dall’esterno, rischierei di venire bloccato dalla DUL che certi ISP o certe società utilizzano, almeno finché ho il 56k. Quando tornerò ad ADSL verificherò se il mio ip è coperto da DUL oppure no, se non lo è il caso è chiuso, altrimenti, ci si pone nello stesso problema di prima.
Nota: ho risolto impostando SMTP-over-SSL (SMTP classico è inusabile perché Wind blocca la connessione alla porta 25), e poi re-routando le mail tramite l’smtp del mio provider. Ovviamente tutto richiede autenticazione 🙂
Per evitare comunque ulteriori rischi, ho deciso di tornare ad utilizzare, come in passato, la firma e la codifica delle email, almeno quelle confidenziali. Per farlo, usando KMail mi basta avere installato e configurato GNU Privacy Guard, clone opensource e freesoftware di Pretty Good Privacy. Sotto MacOSX, ho rintracciato MacGPG che mette a disposizione dei pacchetti precompilati per il supporto di GPG sotto MacOSX, nel mio caso Panther, e link ad alcuni pacchetti per aggiungere il supporto ai servizi gpg e per avere un plugin funzionante per Apple’s Mail (visto che tra l’altro PGP Freeware non ha i plugins). A questo punto, le mie comunicazioni potevano essere considerate quasi sicure.
Il problema ancora si pone sulle mail non cifrate che transitano tra me e il mio provider, ma questo problema è superiore alle mie possibilità al momento, perché bisognerebbe che, in massa, gli utenti di tale provider richiedessero l’accesso SSL ai suoi server anziché il solo accesso plaintext.
Sicurezza dove ce n’è poca
Questa storia si riferisce ad un singolo sistema che aveva bisogno di essere messo in modalità sicura, e ad un terminale che doveva collegarsi semplicemente a questo sistema.
Un altro grosso problema su Internet è il web semi-amatoriale.
Credo che tutti un giorno o l’altro abbiano desiderato potersi installare un CMS sul proprio computer e aprirsi un sito più professionale di quelli hostati su Lycos o Altervista. Beh a me è capitato, e se vogliamo essere precisi, io ho scritto il CMS.
Drakeadmin nasce, sotto il nome di siteadmin, come backoffice per la nuova veste che doveva assumere il mio sito, www.dragons.it, prima che questo chiudesse. Purtroppo, non è mai stato utile per quella sua funzione originaria, proprio per la chiusura, ma dal Dragone nacque il Drake.
La natura “backoffice” del drake si palesa quando si nota che non offre un’interfaccia utente come fanno PostNuke o PHPNuke, ma solo un’interfaccia di configurazione.
Questa poi rilascia una serie di servizi che il webmaster può inserire nelle pagine web. Questo aiuta a formare un layout molto più dinamico di quello su tre colonne della maggior parte dei CMS.
Nulla vieta, poi, di usare il solo newser (come io faccio sul mio sito) e mantenere il resto del sito statico.
Certo, può essere scomodo agli inizi, ma se combinato con lo Smarty Template Engine, che viene fornito assieme al Drakeadmin in quanto esso stesso lo usa per il rendering dei servizi e delle sue stesse pagine amministrative, diventa molto potente.
Un altro asso nella manica nella natura del Drakeadmin è il fatto che può essere installato in modo trasparente su un server SSL.
Mentre PHPNuke e PostNuke non distinguono la parte backoffice dalla parte utente, Drakeadmin lo fa, palesemente, in questo modo, installando la parte backoffice sotto SSL, i dati di configurazione, le password e i cookie, saranno cifrati e indecifrabili da terzi. A meno di attacci MITM, ovviamente.
Purtroppo, anche il Drakeadmin ha le sue lacune. Non ho ancora avuto modo di aggiunger certe cose che mi sarebbero piaciute a livello di sicurezza degli utenti, ma soprattutto devo ancora trovare il tempo di implementare una funzione che non mi pare di aver ancora visto altrove: la cifratura delle email spedite.
Pensateci bene, quanti di voi utilizzano abitualmente forum e sistemi integrati di gestione dei siti? E quanti hanno ricevuto mail con conferme di password e via dicendo? Sarebbe molto facile per uno smanettone sgamato farsi passare come il software del sito, con gli utenti, più o meno allocchi che siano.
Ma se riuscissimo a firmare tutte le email che il software invia, non sarebbe più possibile una cosa del genere, perché l’utente controllerebbe la firma prima di convincersi che la mail sia effettivamente del server.
Questo sarà il mio obiettivo principale nella prossima release 1.2 di Drakeadmin.
Trasferimenti sicuri
Credo che il vademecum del buon sistemista debba sempre comprendere un piccolo divagamento sui sistemi quali ssh e sftp.
Per quanto riguarda ssh, c’è talmente tanto da dire che credo che tutti ne abbiano sentito parlare prima o poi. Impostare un server ssh sotto Linux è quasi banale, mentre sotto Windows la faccenda si complica (non è comunque impossibile, usando Cygwin mi è stato possibile installarlo ai tempi di Dragons.it). Una volta fatto questo, l’impostazione del server sftp è veramente una stupidaggine. Ma se ci pensiamo bene, sftp non è nato per il trasferimento di grandi volumi di dati. Prima di tutto è lento, tremendamente lento, a meno di file di testo che possono essere ben compressi, poi non supporta il resume, e questo ne impedisce l’uso su sistemi client abbastanza instabili o con connessioni scadenti (come la mia).
Ho provato a cercare un’alternativa ad FTP per il trasferimento di grandi quantitativi di dati, poiché questo è veramente obsoleto, passando tutto in chiaro. Purtroppo, non sono ancora riuscito a trovare qualcosa di valido: FTP over TLS è poco supportato dai server (io son riuscito a farlo andare solo col mio buon ProFTPd), e praticamente NON supportato dai client linux (ho provato NcFTP e gFTP). Inoltre, a quanto mi è stato dato modo di capire, solo la connessione di comando è cifrata, mentre i dati rimangono passati in chiaro.
Per parlare di vera sicurezza nella trasmissione, sto cercando un protocollo che possa essere messo al posto di FTP senza dover perderci tempo, che supporti resume e tutte le principali funzioni di FTP, e che al tempo stesso sia tunnellabile tramite SSL.
Non so se questo protocollo esista di già, ma spero che, nel caso esso non esista, qualcuno possa leggere queste mie pagine e iniziare a lavorarci sopra.
Ringraziamenti e scuse
Non sono un esperto di sicurezza, quindi probabilmente ho detto una marea di cazzate. Non vorrei neanche esser preso per uno che vuole far pubblicità al suo programma (in fondo non ci guadagno mica nulla…). Quindi non prendete per oro colato quello che scrivo, ma consideratelo uno sfogo (l’ho scritto tra le 2 e le 4 di notte.. fate voi) di un aspirante sistemista annoiato.
Per quanto riguarda i ringraziamenti, beh di sicuro ringrazio i miei mentori all’interno del VElug, a cominciare da mydecay, senza dimenticare gli altri ovviamente (iNquis, iSaac_, fabioFVZ, Albertoz, mala, mardok, Sun, roger…), Ghisha che mi da sempre una mano quando ho bisogno, Judas che mi ascolta sfogarmi ogni volta che qualche servizio non va, il_guru che è sempre stato un buon amico e collega, e dio solo sa quanti ne ho dimenticati di ringraziare 😉