Come già accennato, la sicurezza locale comincia con la localizzazione fisica del computer. Noi partiamo dal presupposto che il vostro computer sia ubicato in modo da soddisfare i vostri criteri di sicurezza. Finchè parliamo di sicurezza locale, bisogna anche distinguere i singoli utenti, in modo che nessun utente sia in grado di usare i permessi o l'identità di un altro. Questo vale in generale e in particolare nel caso dei permessi di root, dal momento che l' utente root è, nel sistema, una presenza onnipotente, in grado di diventare ogni utente locale e di leggere ogni file locale.

Linux non memorizza le password in chiaro ovvero in forma non cifrata e confronta la password immessa con quella archiviata. Altrimenti, se venisse rubato il file con tutte le password, tutti gli account del sistema sarebbero compromessi. Linux salva invece le password in forma cifrata: ogni volta che immettete la vostra password, questa viene cifrata e solo allora paragonata con quella archiviata. Un procedimento del genere funziona solo se non è possibile evincere la password vera e propria dalla forma cifrata, cosa che assicurano i cosiddetti algoritmi a trappola, che funzionano solo in una direzione. Un aggressore che sia riuscito ad impadronirsi della password cifrata non potrà semplicemente a sua volta ricalcolare la password dall'algoritmo per avere la password in chiaro, ma dovrà provare tutte le combinazioni di lettere possibili, finchè non trovi quella che coincide con la vostra. Considerando che ogni password può constare anche di otto lettere, le combinazioni possibili sono fin troppe...

Negli anni '70, un argomento a favore della sicurezza di questo metodo era che l'algoritmo usato era molto lento e necessitava alcuni secondi per cifrare una password. I computer moderni però sono in grado di eseguire fino a milioni di crittogrammi al secondo. Per questo motivo, le password di oggi non devono essere visibili ad ogni utente (per un utente normale, /etc/shadow non è leggibile) e le password non devono essere facili da indovinare – per il caso che, a causa di un errore, le password diventino visibili. Camuffare una password come Fantasia in F@nt@s13 non è molto d'aiuto: queste regole di scambio sono un gioco facile per certi programmi che si servono anche di dizionari per indovinare la password. La cosa migliore sono combinazioni di lettere che, messe assieme, non formano alcuna parola sensata e che hanno un significato solo per voi (ad esempio, le iniziali delle parole di una frase o del titolo di un libro, come Il Nome della Rosa di Umberto Eco, da cui verrebbe fuori una bella password: INdRdUE9). Per indovinare una password come Inter o Robi76, poi, non c'è neanche bisogno di conoscervi a fondo.

Non consentite il caricamento daI dischetto o dal CD-ROM rimuovendo i lettori o impostando una password per l'accesso al BIOS ed il BIOS in modo da consentire il boot esclusivamente dal disco rigido.

Generalmente, i sistemi Linux vengono inizializzati con un boot loader che permette di passare opzioni supplementari al kernel da avviare. Per quello che riguarda la sicurezza, tali opzioni sono molto critiche, perchè il kernel non funziona solo con diritti root, ma assegna fin dall'inizio i diritti root. Se usate come boot loader potete impedire ciò impostando un'ulteriore password in /boot/grub/menu.lst (si veda Section 7.4.5, “Impostare la boot password”).

Qui vale il principio: lavorare sempre con i minori privileggi possibili. Non è assolutamente necessario leggere o scrivere una e- mail come root. Se il programma e-mail (MUA = Mail User Agent) con il quale lavorate ha un bug, la gravità delle conseguenze per voi dipenderà dai permessi con i quali lavoravate al momento dell'attacco. Qui si tratta quindi di ridurre quanto più possibile i danni.

I singoli diritti dei più di 200.000 file di una distribuzione di SUSE sono stati assegnati in modo molto oculato. L'amministratore di un sistema dovrebbe installare software o file supplementari solo con la massima cura e fare particolarmente attenzione all'assegnazione dei permessi sui file. Amministratori esperti e coscienziosi, quando usano il comando ls, aggiungono sempre l'opzione -l per avere un elenco dettagliato dei file assieme ai pemessi di accesso in modo da poter riconoscere subito diritti impostati erroneamente. Un attributo impostato in modo errato può significare non solo che i file potrebbero venire sovrascritti o cancellati, ma anche che i file modificati potrebbero venire eseguiti da root o che i file di configurazione possano essere utilizzati con permessi di root. In questo modo l'aggressore avrebbe la possibilità di estendere notevolmente i suoi permessi. Questo tipo di attacchi vengono chiamati "uova del cuccù", perchè il programma (l'uovo) viene eseguito (covato) da un utente estraneo (l'uccello): proprio come il cuccù, che fa covare le sue uova da altri uccelli.

I sistemi di SUSE dispongono dei file permissions, permissions.easy, permissions.secure e permissions.paranoid che si trovano nella directory /etc. Qui vengono stabiliti i permessi paritcolari come p.es. directory con accesso in scrittura per tutti (world writable) o setuser-ID-bit per file, cioè il programma non viene eseguito coi diritti del proprietario del processo che lo ha iniziato, ma coi diritto del proprietario del file che è generalmente root. L'amministratore ha a disposizione il file /etc/permissions.local in cui può fissare le proprie modifiche.

La scelta del file da usare per l'assegnazione dei permessi nel caso di programmi di configurazione SUSE, si lascia eseguire comodamente con sotto ‘Sicurezza’. Per ulteriori informazioni leggete il file /etc/permissions e la pagina di manuale del comando chmod (man chmod).

Ogni qualvolta un programma elabora dei dati che stanno o stavano in un modo o nell'altro sotto la sfera di influenza di un utente, è sempre bene essere prudenti. Questa prudenza vale soprattutto per il programmatore dell' applicazione: questi deve assicurare che i dati vengano interpretati correttamente dal programma, che i dati non vengano scritti in aree della memoria troppo piccole e che i dati vengano elaborati in modo consistente.

Si ha un buffer overflow quando si scrive in un'area del buffer, senza badare alla dimensione effettiva del buffer. Potrebbe essere che i file (provenienti dall'utente) abbiano bisogno di più spazio di quello disponibile nel buffer: a causa di questo sfondamento dei limiti del buffer, può accadere che un programma, sulla base dei soli dati che deve elaborare, esegua sequenze di programmi che si trovano sotto l'influenza dell'utente e non del programmatore. Questo è un grave errore, specialmente se il programma viene eseguito con diritti speciali (si veda la sezione Section 27.4.2.4, “Permessi di accesso”). I format string bug funzionano un po' diversamente, ma anche questi utilizzano le immissioni dell'utente per fuorviare il programma.

Questi errori di programmazione vengono normalmente sfruttati da programmi che vengono eseguiti con privilegi alti, cioè programmi setuid e setgid. Potete quindi proteggere il vostro sistema e voi stessi da tali errori, togliendo dai programmi particolari diritti di esecuzione. Anche qui vale il principio dei minori diritti possibili (vd. paragrafo Section 27.4.2.4, “Permessi di accesso”).

Poichè i buffer overflow e format string bug sono degli errori nel modo di processare i dati degli utenti, questo tipo di bug può essere sfruttato non solo se si dispone già di un login locale: molti degli errori conosciuti possono venire sfruttati anche tramite un collegamento di rete. Per questo, buffer overflow e format string bug non si lasciano classificare nettamente come attinenti ai soli computer locali o alla rete.

Esistono virus anche per Linux! I virus conosciuti sono stati scritti dai loro autori come proof-of-concept, come prova dunque che il programma funziona. Ma finora non ne è ancora stato avvistato nessuno in libera circolazione.

Per diffondersi, i virus hanno bisogno di un ospite, senza non possono sopravvivere. Questo ospite può essere un programma o una parte importante della memoria (per il sistema) come p.es. il master_boot_record e questo ospite deve essere sovrascrivibile dal codice di programma del virus. Grazie alle sue capacità multi user, Linux offre la possibilità di limitare l'accesso in scrittura ai file, in particolar modo ai file sistema. Se lavorate come root, aumentate la possibilità che il vostro sistema venga contagiato da un tale virus. Se, invece, vi attenete alla regola dei minori privilegi possibili, sarà difficile contaggiare il vostro sistema Linux con un virus. Inoltre, non dovreste mai eseguire sconsideratamente un programma preso da Internet e di cui ignorate l'origine. I pacchetti rpm della SUSE portano una firma cifrata; questa firma digitale è la garanzia per l'accuratezza del modo in cui sono stati assemblati i pacchetti SUSE. Virus sono una prova del fatto che anche un sistema che presenta un elevato grado di sicurezza diventa vulnerabile quando l'amministratore o l'utente opera in modo sconsiderato per quando riguarda la sicurezza.

I virus vanno distinti dai cosiddetti vermi informatici che interessano la sicurezza delle reti e non richiedono un sistema ospite per proliferare.

Nella sicurezza locale, si tratta di separare nettamente gli utenti che condividono un computer, ed in particolar modo l'utente root. Per quando riguarda la sicurezza della rete è invece l'intero sistema che va protetto contro attacchi provenienti dalla rete. L'autenticazione dell'utente durante il login attraverso nome di login e password sono parte del concetto della sicurezza locale. Nel caso di il login tramite una connessione via rete bisogna differenziare tra due aspetti di sicurezza: fino all'autenticazione si parla di sicurezza di rete; ad autenticazione avvenuta di sicurezza locale.

Come già accennato, la trasparenza di rete è un caratteristica fondamentale di un sistema UNIX; questo vale particolarmente per X11, il sistema windowing dei sistemi UNIX. Voi potete fare il login su un computer remoto ed inizializzare lì un programma che verrà visualizzato tramite la rete sul vostro computer.

Se un X-client deve venire visualizzato sul nostro X-server attraverso la rete, il server deve proteggere da accessi illeciti le risorse che amministra (il display). Concretamente significa che il programma del client deve ricevere dei diritti. Su X-Windows, questo avviene in due modi: controllo degli accessi basato su host e su cookie. Il primo caso si basa sull'indirizzo IP del computer sul quale deve girare il programma del client e viene controllato con il programma xhost. Il programma xhost amministra un indirizzo IP di un client autorizzato nella mini-banca dati che si trova sul X-server. Basare l'autenticazione esclusivamente su un indirizzo IP non è però molto sicuro. Sul computer, con il programma client, potrebbe essere attivo un secondo utente e questi avrebbe accesso al X-server esattamente come qualcuno che rubi l'indirizzo IP. Per questo qui non vogliamo approfondire questo metodo. La pagina di manuale di xhost vi fornirà maggiori dettagli sul funzionamento (e contiene anche questo avviso!).

Con l'accesso di controllo basato sui cookie viene usata, come mezzo di riconoscimento simile ad una password, una stringa nota solo al X-server e all'utente loggato correttamente. Al login, questi cookies (con questa parola, si intendono i fortune cookies cinesi contenenti una massima o un detto) vengono memorizzati nel file .Xauthority nella directory home dell'utente ed è disponibile in questo modo per ogni client X-Windows che vuole visualizzare una finestra sul X-server. Il programma xauth mette a disposizione dell'utente il tool per analizzare il file .Xauthority. Se cancellate .Xauthority dalla vostra directory home o lo rinominate, non siete più in grado di aprire delle finestre di nuovi X-client. Nella pagina di manuale di Xsecurity (man Xsecurity ) troverete maggiori informazioni sugli aspetti di sicurezza di X-Windows.

ssh (secure shell) è in grado (tramite un collegamento di rete completamente cifrato) di creare in modo trasparente, cioè non direttamente visibile per l'utente, il collegamento ad un X-server: qui si parla di X11-forwarding . Sul lato server, viene simulato un X-server e nella shell sull'host remoto viene impostata la variabile DISPLAY.

	Warning
Se siete del parere che il computer sul quale fate il login non sia sicuro, non create alcun collegamento X Windows. Con l'X11-forwarding attivato, potrebbero collegarsi al vostro X-server, tramite il vostro collegamento ssh, anche aggressori e origliare alla vostra tastiera.

Quanto detto nella sezione sicurezza locale su buffer overflow e format string vale anche per la distinzione in locale e remoto per gli aspetti relativi alla sicurezza della rete. Come anche nella variante locale di questo errore di programmazione, i buffer overflow portano quasi sempre ad avere i permessi di root per i servizi della rete. Altrimenti, l'aggressore potrebbe procurarsi l'accesso ad un account locale (non privilegiato) tramite cui sfruttare altre falle nella sicurezza (locale).

I buffer overflow e format string bug sono indubbiamente le varianti più frequenti di un attacco sferrato da remoto. Nelle mailing list sulla sicurezza, sono reperibili i cosiddetti exploits , programmi cioè che sfruttano lacune rilevate di recente. Anche chi non conosce i dettagli esatti di questa lacuna, è in grado di sfruttarla. Con il passare degli anni si è appurato che la libera disponibilità degli exploitcodes ha aumentato in generale la sicurezza dei sistemi operativi; la cosa dipende certamente dal fatto che i produttori di sistemi operativi sono costretti ad eliminare i bug del loro software. Poichè con il software libero, il codice sorgente è a disposizione di tutti (SUSE Linux fornisce tutti i sorgenti disponibili), ognuno che rileva una lacuna con un exploitcode può anche fare proposte su come risolvere il problema.

L'obiettivo di questo tipo di attacco è bloccare un servizio o addirittura l'intero sistema. Ciò può succedere nei modi più disparati: creare un sovraccarico del sistema bombardandolo con pacchetti insensati o sfruttando cosiddetti remote buffer overflow.

Con un attacco DoS spesso si intende bloccare un servizio. La non disponibilità di un servizio può però avere conseguenze che vanno ben oltre. Si veda man in the middle: sniffing, tcp connection hijacking, spoofing e DNS poisoning.

In generale vale: un attacco dalla rete, nel quale l'aggressore si posiziona tra due interlocutori, viene chiamato attacco del tipo man-in-the-middle. Spesso la vittima neanche se ne accorge. Ecco uno dei tanti scenari possibili: l'aggressore accetta il collegamento e, affinchè la vittima non si accorga di nulla, crea egli stesso un collegamento con il sistema meta. La vittima, senza saperlo, ha aperto un collegamento di rete con il computer sbagliato, visto che questi si spaccia per il computer meta. L'attacco man in the middle più semplice è rappresentato da uno sniffer. Esso origlia ai collegamenti di rete che gli vengono fatti passare davanti (ingl. sniffing, cioè spiare). La cosa diventa più complessa, se l'aggressore nel mezzo cerca di rapire (ingl.hijacking) un collegamento già esistente. Per poter predire i numeri di sequenza TCP esatti del collegamento TCP, l'aggressore deve analizzare per un pò di tempo i pacchetti che gli passano davanti. Quando assume il ruolo della meta del collegamento, la vittima lo nota solo perchè il collegamento viene terminato perchè non valido.

L'aggressore sfrutta soprattutto quei protocolli non protetti, non cifrati per l'hijacking e nei quali l'autenticazione avviene all'inizio del collegamento. Per spoofing si intende l'invio di pacchetti con i dati mittente modificati, si tratta principalmente dell'indirizzo IP. Quasi tutte le varianti di attacco richiedono l'invio di pacchetti falsificati; cosa che sotto Linux/UNIX può venire eseguita solo dal superutente (root).

Molte possibilità di attacco appaiono solo in combinazione con un DoS. Se c'è la possibilità di staccare repentinamente un computer dalla rete (anche se solo per breve tempo), la cosa influenza favorevolmente un attacco attivo, poichè il tutto viene semplificato ulteriormente (dal punto di vista dell' aggressore.

L'aggressore cerca, con i pacchetti di risposta DNS falsificati (spoofed) di avvelenare poisoning la cache di un server DNS cosicchè questi li inoltra ad una vittima che li richiede. Per indurre il server DNS ad accettare le informazioni alterate, di solito l'aggressore deve ricevere ed analizzare alcuni pacchetti del server. Poichè molti server, sulla base del loro indirizzo IP e del loro nome host, hanno degli host classificati come affidabili, un tale attacco (nonostante la complessità) può portare entro pochissimo tempo al risultato desiderato. La premessa è una buona conoscenza del rapporto di fiducia fra questi computer. Dal punto di vista di colui che sferra l'accatto, un DoS come si deve che blocca un server DNS i cui dati devono venire falsificati, nella maggior parte dei casi non è evitabile.

Per evitare tutto questo si consiglia una collegamento cifrato che permette di verificare l'identità del sistema meta del collegamento.

I vermi vengono spesso comparati ai virus. Vi è tuttavia una notevole differenza: un verme non deve contagiare alcun programma ospite ed è tagliato per diffondersi rapidamente nella rete. I vermi conosciuti come Ramen, Lion o Adore sfruttano lacune di sicurezza ben conosciute di programmi di server come bind8 o lprNG. E' relativamente semplice proteggersi dai vermi, perchè di solito trascorrono pochi giorni dalla comparizione di un verme che sfrutta determinate falle e la disponibilità dei pacchetti di aggiornamento. Ciò presuppone, naturalmente, che l'amministratore installi sui propri sistemi tutte le più recenti security update.