Figura 377.13. Separazione tra la rete interna da proteggere e la zona demilitarizzata (DMZ).
|
|
[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico] [volume] [parte]
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 intento, non si può dire a cosa gli può servire, 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), 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, 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, per cui 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[Invio]
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, riconoscendone così la presenza e il nome: dinkel.brot.dg.
bruto@krampus:~$ finger nobody@vittima.brot.dg[Invio]
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 parola d'ordine (viene descritto più avanti l'uso possibile di file come .rhosts e .shosts).
bruto@krampus:~$ finger pippo@vittima.brot.dg[Invio]
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 tale utenza per tentare di impadronirsene. Di solito si tratta di utenti creati solo per fare qualche prova (pippo, prova, guest, backdoor, ecc.), lasciati lì e dimenticati. Niente di meglio quindi, considerato che spesso questi hanno delle parole d'ordine banali e individuabili facilmente.
La condivisione del file system attraverso il protocollo NFS può essere verificata facilmente attraverso un comando come showmount. La conoscenza delle porzioni condivise del file system aggiunge un tassello in più alle informazioni che può raccogliere l'ipotetico aggressore.
bruto@krampus:~$ /usr/sbin/showmount -e vittima.brot.dg[Invio]
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 l'occasione.
Si osservi l'esportazione della directory /home/; di sicuro viene concessa anche la scrittura. Se l'ipotetico aggressore fosse in grado di innestare 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 parola d'ordine).
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[Invio]
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 servente DNS determinato, si può usare nslookup con l'opzione -q=any. L'esempio seguente verifica le informazioni riferite al dominio unipg.it; come si può vedere dal risultato non ci sono informazioni superflue.
$ nslookup -q=any unipg.it[Invio]
unipg.it
origin = teseo.unipg.it
mail addr = postmaster.unipg.it
serial = 2002101001
refresh = 86400
retry = 1800
expire = 604800
minimum = 86400
unipg.it mail exchanger = 10 egeo.unipg.it.
Name: unipg.it
Address: 141.250.1.4
unipg.it nameserver = dns2.nic.it.
unipg.it nameserver = teseo.unipg.it.
unipg.it nameserver = dedalo.unipg.it.
unipg.it nameserver = giannutri.caspur.it.
Authoritative answers can be found from:
unipg.it nameserver = dns2.nic.it.
unipg.it nameserver = teseo.unipg.it.
unipg.it nameserver = dedalo.unipg.it.
unipg.it nameserver = giannutri.caspur.it.
egeo.unipg.it internet address = 141.250.1.4
dns2.nic.it internet address = 193.205.245.8
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
|
Per questo si può usare anche host con l'opzione -a, benché i risultati siano leggermente diversi:
$ host -a unipg.it[Invio]
unipg.it SOA teseo.unipg.it postmaster.unipg.it (
2002101001 ;serial (version)
86400 ;refresh period (1 day)
1800 ;retry interval (30 minutes)
604800 ;expire time (1 week)
86400 ;default ttl (1 day)
)
unipg.it MX 10 egeo.unipg.it
unipg.it A 141.250.1.4
unipg.it NS dns2.nic.it
unipg.it NS teseo.unipg.it
unipg.it NS dedalo.unipg.it
unipg.it NS giannutri.caspur.it
|
Infine, anche dig con l'argomento ANY:
$ dig ANY unipg.it[Invio]
; <<>> DiG 9.2.1 <<>> ANY unipg.it ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15138 ;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 4, ADDITIONAL: 5 ;; QUESTION SECTION: ;unipg.it. IN ANY ;; ANSWER SECTION: unipg.it. 32777 IN SOA teseo.unipg.it. \ |
Il protocollo SNMP (Simple network management protocol, parte lv) ha lo scopo di consentire il controllo di apparecchiature raggiungibili attraverso la rete, fornendo un modo per pubblicare delle informazioni, che in parte possono anche essere rese modificabili. Molte apparecchiature che si collegano alla rete offrono questo servizio, comportandosi come «agenti SNMP». Il problema sta nel fatto che, di norma, l'accesso al servizio avviene attraverso la comunità predefinita public, ma, peggio ancora, le informazioni pubblicate potrebbero contenere i dati necessari ad accedere per modificarne la configurazione (di solito attraverso un servente HTTP integrato).
Pertanto, ogni volta che si inserisce un componente di rete, occorre sospettare la presenza del servizio SNMP, anche se questo non serve per i propri scopi, provvedendo eventualmente a cambiare il nome della comunità per l'accesso senza autenticazione.
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 file system ridotto, dove la radice corrisponde alla directory ~ftp/.
All'interno di questo piccolo mondo ci sono solitamente dei programmi di servizio, 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 parole d'ordine cifrate: un aggressore sarebbe in grado di scoprire le parole d'ordine reali degli utenti. A dire il vero, questa directory ~ftp/etc/ dovrebbe impedire la lettura del suo contenuto (01118), ma ciò serve solo a non fare conoscere quali file sono contenuti, mentre tutti sanno che c'è comunque 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 spiega, sul piano teorico, in che modo un aggressore potrebbe riuscire a farsi spedire via posta elettronica il contenuto del file /etc/passwd reale del sistema.(1)
L'aggressore potrebbe creare un file per il forward (il proseguimento dei messaggi) contenente un comando, cosa consentita da Sendmail. In pratica, si potrebbe trattare del contenuto seguente:
|
Come si vede, si tratta di un condotto 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, nell'ipotesi che quella directory risulti 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 parole d'ordine.
In questo caso, è molto probabile che per l'aggressore non sia poi tanto facile cancellare le tracce lasciate (cosa senza dubbio positiva). 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 (il secondo deve risiedere 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 parola d'ordine, 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.
|
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 ...[Invio]
L'esempio mostra l'utente tizio che accede all'elaboratore vittima.brot.dg, utilizzando lì il nominativo-utente pippo, senza dover indicare alcuna parola d'ordine.
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 «#», facendo in modo che corrisponda a un suo indirizzo IP di comodo, ecco che quel commento servirebbe solo ad aggiungere un nuovo accesso senza parola d'ordine.
Alcuni servizi e alcuni programmi sono pericolosi per loro natura. 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 servente, all'interno della quale si articolano le varie directory specifiche di ogni cliente che deve potersi connettere.
Tra queste directory ci potrebbe essere /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 poi tentare di decifrare le parole d'ordine degli utenti di quel sistema senza disco.
Il problema diventa più grave se i file passwd e group sono comuni a tutti i clienti, al limite anche al servente stesso. Infatti, per semplificare le cose, potrebbero essere stati utilizzati 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.
|
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.
Generalmente, il NIS utilizzato con i sistemi GNU, include il TCP wrapper, riconoscendo così i file /etc/hosts.allow e /etc/hosts.deny, cosa che dovrebbe limitare tale 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 del servizio.
A parte queste considerazioni, il tipo di NIS che si utilizza normalmente fa viaggiare nella rete tutte le informazioni che amministra, comprese le parole d'ordine 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; poi, analizzando il contenuto dei vari file, potrebbe estrarre tutte le informazioni che gli servono sugli utenti. Quello che si vuole esprimere 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 utile 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.(2)
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 un condotto. 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 un condotto.
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 affermato 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.
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 parola d'ordine.
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 parola d'ordine. 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 tale sistema di fiducia.
Eventualmente, i rapporti di fiducia possono essere basati, piuttosto che sui nomi, sugli indirizzi IP. Ciò servirebbe a ridurre i rischi, ma non a sufficienza: se il transito (il routing) non è completamente sotto controllo, qualcuno potrebbe dirottare gli instradamenti a proprio vantaggio.
Per ridurre i rischi dovuti all'uso della fiducia incondizionata, si possono proteggere alcuni servizi attraverso chiavi di riconoscimento (come nel caso dei protocolli SSL/TLS e SSH), con cui il servente può identificare il cliente, mentre 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 vengono usate in seguito per certificare la propria identità: la chiave privata non viene divulgata e serve 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 chiave pubblica rispettiva.
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 parole d'ordine utilizzate per l'accesso remoto).
A questo si può porre rimedio solo con un buon sistema di cifratura, come avviene attraverso il protocollo SSH. Tuttavia, il problema rimane per tutti quei servizi per i quali non è prevista tale 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, noti normalmente con il nome rootkit. 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.
Le reti locali vanno organizzate almeno a due livelli, isolando la porzione esposta all'esterno (DMZ) da quella interna.
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 serventi NFS nei sistemi GNU/Linux non lo consentono in ogni caso). Inoltre, è bene cercare almeno di limitare l'esportazione alla sola lettura.
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 un'attenzione particolare alla protezione dei serventi 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 (il Portmapper) e l'elenco dei processi (alcuni servizi potrebbero essere indipendenti sia dal supervisore dei servizi di rete che dal sistema delle RPC).
È importante che siano attivi solo i servizi necessari.
Quando possibile è opportuno utilizzare l'avvio dei servizi attraverso il controllo del supervisore dei servizi di rete e del TCP wrapper. Quando non si intende fornire un servizio, conviene almeno monitorarne le richieste attraverso l'ausilio del TCP wrapper (questo particolare viene chiarito nel capitolo 381).
Ridurre o eliminare del tutto la «fiducia» basata esclusivamente sul nome del cliente.
Utilizzare parole d'ordine oscurate e un comando passwd che non consenta l'utilizzo di parole d'ordine troppo semplici (generalmente è già così nella maggior parte delle distribuzioni GNU/Linux).
Fare a meno di gestire gruppi di lavoro abbinati a parole d'ordine: una parola d'ordine di gruppo è un segreto senza valore.
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 parole d'ordine oscurate 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 file system alla ricerca di alterazioni nei file. Per questo si utilizzano programmi come AIDE e Tripwire.
|
Figura 377.13. Separazione tra la rete interna da proteggere e la zona demilitarizzata (DMZ).
|
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 parole d'ordine.
Definizione della scadenza di ogni utenza.
Eliminazione di utenti generici (come il tipico utente guest).
Verifica che tutti gli utenti abbiano una parola d'ordine, oppure che queste siano disabilitate attraverso un asterisco (o qualunque altro carattere impossibile) nel campo corrispondente.
Verifica che tutti gli utenti di sistema non possano essere utilizzati per accedere, a causa della presenza di un asterisco nel campo della parola d'ordine.
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 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.
Eliminazione dei bit SUID e SGID negli script di shell (anche se questo non dovrebbe causare problemi con i sistemi 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 zero) ogni mese.
Copia di sicurezza incrementale (livello uno) almeno ogni due settimane.
Utilizzo di sistemi di memorizzazione WORM,(3) come i CD-R, per le copie di sicurezza di livello zero.
Kevin Fenzi, Linux Security HOWTO
<http://www.linux.org/docs/ldp/howto/HOWTO-INDEX/howtos.html>
Dan Farmer, Wietse Venema, Improving the Security of Your Site by Breaking Into it, 1995
<http://www.alw.nih.gov/Security/Docs/admin-guide-to-cracking.101.html>
Christopher Klaus, Backdoors, 1997
Steven M. Bellovin, There Be Dragons, 1992
David A. Curry, Improving the security of your UNIX systems, 1990
CERT (Computer Emergency Response Team) Coordination Center
Mathematics and Computing Science Dept. of Eindhoven University of Technology (the Netherlands, Europe)
Appunti di informatica libera 2007.02 --- Copyright © 2000-2007 Daniele Giacomini -- <daniele (ad) swlibero·org>
1) L'idea è tratta da Improving the security of your site by breaking into it, di Dan Farmer e Wietse Venema.
2) Per accedere a una sessione grafica da una postazione remota si usa preferibilmente VNC attraverso un tunnel cifrato, come si può leggere nel capitolo 227.
3) Un sistema di memorizzazione che consente la scrittura una volta sola e non permette la cancellazione successiva (salvo il caso della distruzione fisica).
Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome introduzione_ai_problemi_di_sicurezza_con_la_rete.htm
[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico]
