InSecurity

Da piu' parti, per qualche strano motivo, mi e' stato chiesto di scrivere qualche cosa sul tema "sicurezza". Forse qualcuno e' convinto che io sia una specie di genio dell'argomento. Ci tengo invece a precisare che io non ne so quasi un tubazzo e la maggioranza delle cose che faccio sono dovute ad esperienza vissuta sulla mia pellaccia piu' che a studi e teoria varia.

Questo documento e' piu' orientato alla sicurezza dal punto di vista sistemistico, quindi per sysadmin e molto meno per normali utenti, per quello e' sempre meglio riferirsi a questo vecchissimo documento.

Quindi, tenendo presente la mia attitudine al bofonchiamento incoerente, andiamo ad incominciare.

Il termine "sicurezza informatica" e' entrato nel linguaggio comune solo da pochi anni, prima era il dominio assoluto di enti come la CIA, poi, di botto, inizio' a diventare molto piu' importante e "vicino a casa".

Il termine si e' anche esteso con il tempo. Negli anni '80 significava per lo piu' "non installare ca$$ate senza passarle prima ad un antivirus" e "chiudi la porta prima di andartene", poi si e' esteso a "cosa e' installato sul server" e "dove hai lasciato il tuo portatile" ed infine siamo arrivati ai giorni nostri quando i termini 'firewall', 'crittografia' e 'vulnerability' sono diventati quasi di uso comune.

All'inizio si supponeva che il 'computer' fosse gestito solo da personale specializzato (operatori o amministratori), mentre i normali utenti facevano solo gli utenti, poi con l'aumentare delle capacita' e lo scendere dei prezzi si e' incominciato a diffondere il concetto che chiunque potesse gestire un sistema.

La cosa ha cominciato a diventare endemica quando i vari sistemi Windows hanno iniziato a soppiantare i vari Novell/IBM a livello di singolo ufficio o di dipartimento aziendale. Il motivo era fondamentalmente economico: una rete di pc con un server Windows costava meno che un mainframe IBM o un server Novell con una batteria di terminali ed un sistemista per tenerlo in funzione. E l'interfaccia di Windows era appositamente studiata per apparire sufficientemente semplice dal far pensare a chi pagava per il prodotto di poterlo amministrare senza rivolgersi a specialisti (che sono costosi). Il che fece si' che un sacco di gente decidesse su due piedi che si poteva anche fare a meno del sistemista e "fare da se".

Con questo non voglio dire che l'attivita' sistemistica sia impossibilmente complicata o richieda una intelligenza fuori dal normale. Quello che richiede sono in sostanza certe conoscenze di base, una buona voglia di imparare ed una certa forma mentis. E sono queste due ultime che spesso "fregano".

Spiego meglio: dal punto di vista hardware i computers non sono cambiati molto negli ultimi 30 anni, siamo passati da 8 a 64 bit, da pochi Kilobytes di memoria a Giga bytes, da una manciata di Megahertz a parecchi Gigahertz, insomma e' aumentata la capacita' e la velocita' ma poco altro e' cambiato nell'hardware. Direi che il cambiamento piu' drastico che si e' avuto e' stato l'avvento del networking.

Quello che e' cambiato e' l'uso che se ne fa. Ogni giorno una qualche ditta cerca di sbarcare il lunario prendendo un vecchio concetto, rivestendolo con un nuovo acronimo e cercando di rivenderlo ad un prezzo piu' alto.

Quindi date delle conoscenze di base che, bene o male, cambiano molto poco (tcp/ip, routing, networking basilare insomma, come cappero funziona un processore et similia), si tratta di mettersi a cercare di capire cosa cavolo e' nuovo-acronimo-del-giorno a che cosa assomiglia (o cosa copia senza vergogna) ed a che cosa serve (a parte cercare di ingrossare il portafogli di chi lo vende). Per questo occorre (ovviamente) la voglia e l'attitudine a cercarsi le informazioni e studiarsele. E questa attitudine non si puo' ne' comperare ne' ottenere dal computer. Deve stare nella zucca.

Cio' che non si conosce, non si capisce, se non si capisce vi puo' mozzicare le chiappe. Quindi dovrete armarvi di pazienza e tempo, acquistare (gasp!) libri, eventualmente seguire corsi, studiare ed applicarvi.

Solo che se uno studia (che so io) i dettagli della virtualizzazione con Xen invece che con VMWare e che differenza c'e' tra Oracle e DB2, non puo' nello stesso tempo andare a firmare i contratti o giocare a fare il CEO.

Ed e' per questo che il 'capo' della situazione invece di "fare da me" farebbe moooolto meglio a decidere di investire i quatrini adeguati ed assumere un sistemista decente per il tempo necessario. Purtroppo in molti casi il vantaggio a breve termine (il conto corrente) e' tutto quello che si riesce a considerare.

Il lavoro di un sistemista si puo' dividere in 3 attivita' principali: quella che va sotto il nome di supporto utenti, gioia e delizia di tutti, dove si tratta di spiegare all'utonto di turno come usare o non usare quello che dovrebbe essere lo strumento principale di lavoro, quella che va sotto il (generico) nome di problem solving, che consiste nel non strozzare gli utenti (origine in genere dei problemi) e nel trovare un modo funzionale di toglierli dai guai, ed infine, ma non meno importante, c'e' quella vasta parte che e' il "supporto sistemi" vero e proprio, che e' in genere noiosa e ripetitiva.

In alcuni casi quest'ultima attivita' puo' essere automatizzata o resa meno noiosa utilizzando (o se il sistemista in questione e' inventivo, sviluppandoseli da solo) degli appositi tool, ma nella maggioranza dei casi si tratta di applicare il cervello e la pazienza e verificare giornalmente che cosa succede, perche' e se e' il caso di farci qualche cosa oppure no.

Ed e' quest'ultima attivita' che e' in genere ignorata o seriamente sottostimata da tutti i "wannabe" sysadmin e non-sysadmin-che-pero'-fanno-i-sysadmin e che e' poi l'origine di tutti i problemi di sicurezza che ci ritroviamo.

Non vorrei insistere troppo con sta' cosa, ma nella maggioranza dei casi in cui si verificano dei problemi di origine sistemistica, la causa puo' in genere essere rintracciata tra la sedia e la tastiera.

Un sysadmin dovrebbe avere in ogni caso una certa "attitudine" che non cambia mai. E qui' mi permetto di andare un attimino fuori tema... nel mio commento di qualche tempo fa' mi riferivo (tra le altre cose) al nome assegnato ai vari server/client.

Ho ricevuto diversi commenti che piu' o meno dicevano "ma io ho un pc che uso per i test, perche' devo dargli un nome diverso da 'localhost'?" Chiamarlo "testpcforX.miodominio.com" era troppo difficile? Il punto e' che se hai una certa forma mentis (aka: dare alle macchine dei nomi in un certo modo) non la cambi per una macchina, anche se non e' altro che un pc di test. Anche se non e' in rete. Anche se nessuno a parte te la vedra' mai. Perche' ce lo hai ingranato nel cervello, come pettinarsi in un certo modo o lavarsi i denti in una certa maniera. Fa parte di te e lo fai senza nemmeno pensarci.

Altri commenti che sono stati zappati riguardavano la consultazione dei files di log con la giustificazione che "sono sempre uguali". Certo che sono (quasi) sempre uguali! Quale parte di "noioso e ripetitivo" non era chiara? Il punto e' che se non li controlli tutti i foxxuti giorni non ti accorgerai mai di quando non sono uguali!

Quindi per tutti gli aspiranti o pretendenti sysadmin: se non volete pedalare non comperate una bicicletta. Se lo fate, sappiate che la strada e' quasi sempre in salita ed il vento e' quasi sempre contro di voi.

Purtroppo, a causa dell'atteggiamento dei vari produttori di hardware e software di ri-rilasciare la stessa roba ma con minimi cambiamenti, e' quasi impossibile dare delle indicazioni specifiche che non diventino obsolete prima ancora di aver finito di scrivere. Quindi mi limitero' a dei consigli abbastanza generici.

Vabbe', di questo non bisognerebbe nemmeno parlarne. Ovviamente c'e' bisogno di un firewall. Ed e' meglio che sia configurato come "tutto chiuso se non specificamente messo ad aperto".

Per definizione, i vari daemon e servizi dovrebbero essere fatti funzionare con i loro utenti definiti, non come root o come utenti privilegiati. La maggioranza dei servizi sono fatti in maniera tale da essere avviati come root e poi 'scendere' a livello di utente non privilegiato per la loro attivita' normale.

Questi 'utenti non privilegiati' non dovrebbero avere necessita' di scrivere niente sul sistema. I log dovrebbero essere gestiti tramite le normali funzioni di logging e non 'scritti' dal demone (l'eccezione lampante qui' e' Apache dove il logging puo' essere separato per ogni vhost e quindi deve essere gestito da Apache stesso).

Controllare quindi i diritti di lettura/scrittura su tutte le varie directory e rimuovere i diritti non necessari al funzionamento.

Ogni servizio che puo' essere ristretto a funzionare in un ambiente limitato (chroot) dovrebbe essere usato in tale modo. Non ha senso il non farlo.

Un discorso diverso pero' e' l'esecuzione di script (cgi, molto spesso php) con diversi utenti a cui e' stato data l'autorizzazione di scrittura sulla sua specifica directory.

Questa tecnica si utilizza nel tentativo (disperato aggiungo io) di limitare i rischi dell'esecuzione contemporanea di molteplici applicazioni, soprattutto su sistemi multi hosting (ovvero, sistemi su cui sono ospitate applicazioni per molteplici persone o aziende).

Personalmente, trovo che sia un palliativo al meglio ed una finta misura di sicurezza al peggio.

Una applicazione web non dovrebbe essere in grado di scrivere sul disco. Se l'applicazione ha delle funzionalita' di upload dovrebbe verificare cosa viene caricato ed i file cosi' creati non dovrebbero poter essere 'eseguiti' come script dal sistema stesso. Ho visto un po' troppi CMS in cui per aggiungere un documento al sito il cms non fa' altro che creare un nuovo file su disco. Questa e' un modo perfetto per avere il sito craccato.

Il termine 'mail' e' diventato negli ultimi anni un sinonimo di 'spam'. Il problema e' che un po' troppa gente tende a pensare ad un server di mail come ad un servizio tutto sommato semplice. E lo e'. Il problema e' che per farlo funzionare in maniera decente e' necessario seguire certe regole di condotta e molta gente apparentemente non ha nessuna voglia di applicarsi (qui' si ritorna al discorso della 'forma mentis').

Per definizione, un server di posta dovrebbe ricevere posta solo ed unicamente per i suoi domini e consentire il relay solo dalla sua rete locale o dagli utenti autenticati.

Esistono tanti, forse troppi meccanismi antispam/antivirus che possono essere usati in combinazione con un server di posta, quindi non ve ne suggerisco nessuno, mi limito a dire che dovreste seriamente considerarne uno o piu' di uno. Usarlo e mantenerlo costantemente aggiornato. E se il vostro server di posta non puo' esserne equipaggiato cambiate server di posta.

Una parola sul cosidetto 'backscatter'. Cercate di non ritornare rimbalzi per quanto possibile. Rifiutate la posta non diretta a voi (aka: indirizzi inesistenti) in fase di ricezione o speditela in /dev/null, ma non accettate una mail per poi rispedirla al (presunto) mittente dopo.

Se consentite l'uso di autoresponder assicuratevi che questi non rispondano a mail marcate come spam o provenienti da mailing-list (o da altri sistemi di mailing automatico) e che non rispondano piu' di una volta alla settimana allo stesso indirizzo.

Cercate di educare i vostri utenti all'uso cosciente della mail. Lo so che e' difficile, ma se non ci si prova mai...

Se vogliamo tenere i ladri fuori di casa la prima cosa da fare e' pensare "se io non avessi le chiavi, come farei ad entrare in casa?". Quindi procedere a bloccare tutte le vie che ci vengono in mente.

La stessa cosa si applica alla sicurezza informatica. "Se io volessi accedere a questa macchina senza sapere la password, come potrei fare?".

Il problema in entrambi i casi e' che i "veri" ladri sono in genere molto piu' fantasiosi di quello che pensiamo. Quindi a parte questo, la cosa migliore da fare e' un bel controllo di sicurezza ogni tanto. Il che significa non solo pensarci all'inizio, ma ripetere l'operazione di tanto in tanto in modo che eventuali cose che siano sfuggite la prima volta vengano trovate la seconda.

Il controllo dovrebbe applicarsi sia ai servizi di base (mail, dns...) sia alle varie web-application ospitate. Ed ogni servizio o web application che non passa il controllo dovrebbe essere disabilitata o rimossa fino a che non viene sistemata.

Il fatto che tu sia paranoico non vuole dire che non siano tutti contro di te.

Il che, tradotto, significa: assumere che qualsiasi cosa sia negativa finche' non e' verificato il contrario. Qualunque connession, qualunque accesso deve essere trattato come un potenziale nemico e solo dopo che e' stata verificata la benignita' lo si lascia passare.

"Il prezzo della liberta' e' la vigilanza continua". La frase si applica anche alla sicurezza informatica. Occorre controllare continuamente che le cose funzionino e funzionino come devono. Quindi, controllare i log di sistema alla ricerca di cose fuori dal normale.

Controllare i log delle varie web application in modo da individuare eventuali problemi e (possibilmente) bloccare eventuali vie d'attacco prima che vengano utilizzate.

Io applico (e suggerisco sempre) la "lettura dei log al contrario". Il che significa: rimuovere dal log tutto quello che e' atteso o normale, quello che resta e' quello da considerare. Per esempio: nel log di una web-application ci saranno 10.000 linee che si riferiscono alle varie 'pagine' dell'applicazione. Queste 10.000 linee non ci interessano. Ma una volta rimosse le linee che non corrispondono salteranno all'occhio.

Ovviamente decidere quali sono le 'linee normali' e' un lavoro a tempo pieno gia' di suo...

Stessa cosa vale per la posta elettronica. Le 10.000 linee che dicono "posta consegnata" non ci interessano.

Un piccolo paragrafo di considerazione per il log del firewall: quello che interessa non e' tanto le connessioni che cercano di entrare e sono bloccate, a meno che non ne riceviate un paio di migliaia dallo stesso indirizzo ip, allora avrebbe senso ficcare l'indirizzo nel firewall. Molto piu' importanti sono le connessioni che cercano di uscire perche' possono essere indice di un qualche malfunzionamento o di cose che non dovrebbero esserci.

Ed un ultima considerazione: quando io trovo qualche cosa di poco pulito nel mio log, la prima cosa che faccio e' cercare di capire da dove arriva e quindi mandare una bella mail di avvertimento al sysadmin dall'altra parte. Nel 90% dei casi questo significa mandare una mail all'abuse@ o postmaster@, quindi gestite correttamente quegli indirizzi di mail.

Come si puo' capire, e' impossibile dare delle indicazioni precise al 100% sempre. In molti casi occorre andare avanti un po' a tentoni e non sempre si fa la cosa giusta.

Si' perche' occorre anche tenere sempre presente che failure is always an option. Soprattutto quando si ha a che fare con la gestione sistemi.

I commenti sono aggiunti quando e soprattutto se ho il tempo di guardarli e dopo aver eliminato le cagate, spam, tentativi di phishing et similia. Quindi non trattenete il respiro.

Nessun messaggio this document does not accept new posts

---

Precedente Successivo

Davide Bianchi, lavora come Unix/Linux System Administrator presso una societa' di Hosting in Olanda.

Volete contribuire? Leggete come!.
 
 

Il presente sito e' frutto del sudore della mia fronte (e delle mie dita), se siete interessati a ripubblicare uno degli articoli, documenti o qualunque altra cosa presente in questo sito per cortesia datemene comunicazione (o all'autore dell'articolo se non sono io), cosi' il giorno che faccio delle aggiunte potro' avvisarvi e magari mandarvi il testo aggiornato.