Successivo: Conclusioni Su: Worm: il verme di Precedente: Difese

Lezioni e Questioni irrisolte

L'incidente del Worm insegnò tante lezioni importanti. Fece venir fuori tanti problemi di cui si parlerà spesso anche in futuro. Tra questi segnaliamo i seguenti:

• Minimo Privilegio. Questo principio base della sicurezza è frequentemente ignorato e ciò può portare a dei problemi; è superfluo dare più privilegi di quanti non ne servano effettivamente.
• ``Abbiamo incontrato il nemico ed era uno di noi''. L'autore del Worm ha dato un contributo al campo della computer security perché era in ogni caso un insider; infatti l'attacco non proveniva da una sorgente esterna che aveva ottenuto informazioni riservate, ed il nascondere le informazioni, come per esempio i sorgenti del sistema operativo, non aiutava a prevenire questo incidente.
• La diversità va bene. Visto che il Worm si diffondeva sui sistemi operativi più diffusi su Internet e sui due tipi di macchine più diffuse, la maggior parte delle macchine sulla rete furono in pericolo. Una maggiore varietà di implementazioni va probabilmente meglio della uniformità. Questa è una analogia diretta con il mondo biologico nel quale c'è la necessità di creare diversità genetiche.
• ``La cura non deve essere peggiore della malattia''. Chuck Cole puntualizzò questa cosa e Cliff Stoll [Sto89] pensò che fosse più caro prevenire tali attacchi invece di ripulire tutto dopo un'eventuale attacco. Le copie di backup vanno bene. Potrebbe essere più economico fare un ripristino dai backup, invece di provare a capire quali danni ha provocato l'intruso
• Le difese devono esserci ma a livello di host e non a livello di rete. Mike Muuss e Cliff Stoll hanno reso questo punto abbastanza evidente. La rete effettua la sua funzione in modo corretto e non dovrebbe dare problemi; i problemi gravi si trovano purtroppo in diversi programmi applicativi. Alcuni tentativi di sistemare i problemi a livello di rete sono sconsiderati. Possiamo fare un'analogia con il sistema delle autostrade: ognuno può guidare verso casa vostra e probabilmente irrompere in casa vostra, ma ciò non significa che, per evitare ciò, noi chiuderemo le autostrade o metteremo delle guardie armate sulle rampe di uscita.
• Fare il logging delle informazioni è importante. L'interazione tra i daemon inetd e telnetd, loggando la sorgente degli attacchi del Worm dava un brutto colpo a tali irruzioni, ma purtroppo tanti siti non avevano abbastanza informazioni di logging per identificare la sorgente o il tempo dell'infezione. Ciò ostacolò fortemente tali risposte, poiché le persone dovevano installare nuovi programmi che loggavano più informazioni. D'altro canto, fare il logging tendeva ad accumulare tante informazioni molto velocemente e raramente tali informazioni venivano consultate. Per questo venivano automaticamente cancellate: se loggiamo informazioni vitali, ma vediamo che vengono velocemente cancellate, non abbiamo migliorato la situazione di molto.
• Rinnegare l'efficacia di tali attacchi è facile. Internet è sorprendentemente vulnerabile a tali attacchi. Tali attacchi sono abbastanza difficili da prevenire, ma potremmo essere molto più preparati nell'identificare la provenienza di tali attacchi di quanto non siamo oggi. Per esempio, oggi non è difficile scrivere un programma che faccia andare in crash una Sun Workstation o altre macchine che implementano il Network File System di SUN (NFS). Questa cosa è molto grave visto che tali macchine sono le più diffuse tra quelle connesse ad Internet.
• Potrebbe essere una buona idea istituire un deposito centrale in cui memorizzare tutti i fix. Anche i venditori di software dovrebbero parteciparvi. Anche gli utenti finali, che si accontentano solo che il loro lavoro venga portato a termine, dovrebbero essere educati sull'importanza di installare i security fixes. Un tentativo in tale direzione è stato intrapreso dal Computer Emergency Response Team [CERT].
• Reazioni di panico dovrebbero essere evitate. L'apertura e la libera circolazione delle informazioni in ogni punto della rete è una prerogativa che dovrebbe essere preservata [6]. La connettività di rete si dimostrò di grande aiuto nella fase di difesa e di analisi durante la crisi del Worm, malgrado alcuni siti si isolarono da soli.
• Il Worm utilizzava il meccanismo dei trusted host Tutto ciò veniva fatto esaminando i file in cui erano listate tali informazioni. Spesso gli host e gli account erano configurati per essere trusted reciprocamente. Una volta che il Worm trovava un tale condidato, si cercava di istanziare su quelle macchine usando la possibilità di remote execution copiandosi sulle macchine remote come se fosse un utente autorizzato effettuando delle operazioni ``remote'' standard. Per prevenire futuri attacchi simili è necessario che il meccanismo di accesso remoto sia revocato e possibilmente rimpiazzato con qualche altra cosa. Un meccanismo che sembra promettere bene è il Kerberos authentication server del progetto Athena del MIT [Ker88]. Questo schema usa chiavi per sessioni dinamiche che devono essere aggiornate periodicamente. Per questo, un invasore non può far uso di schemi di autorizzazione ``statici'' presenti nel file system. Tale sistema di autenticazione conserva le password su di un server centrale che fa il ``logging'' delle richieste di autenticazione, in modo da nascondere la lista dei nomi degli utenti validi su quel sistema. Però, una volta noto un nome di utente, il ``ticket'' di autenticazione è ancora vulnerabile ad un attacco con dizionario. Recentemente [Jon95] si è riuscito ad attaccare direttamente il protocollo TCP in modo che un attaccante potesse redirigere uno stream TCP attraverso una macchina permettendogli di scavalcare le protezioni offerte da sistemi one-time password [SKEY] o da autenticazione su ticketing [Ker88]. Una connessione TCP è vulnerabile a chiunque si trovi sul path seguito dalla connessione ed abbia degli strumenti adeguati .

Successivo: Conclusioni Su: Worm: il verme di Precedente: Difese