EUCIP IT Administrator Modulo 5 - Sicurezza Informatica 5 – codice maligno Alberto Bosio AICA © 2005.

Presentazione sul tema: "EUCIP IT Administrator Modulo 5 - Sicurezza Informatica 5 – codice maligno Alberto Bosio AICA © 2005."— Transcript della presentazione:

1 EUCIP IT Administrator Modulo 5 - Sicurezza Informatica 5 – codice maligno
Alberto Bosio AICA © 2005

2 programmi Programmi compilati Programmi interpretati Macro
C, Basic, Pascal Programmi interpretati PERL, PHP Comandi shell (shell script) Macro Strumento macro di office Esempio della firma di un documento word contenete macro AICA © 2005

3 Filtraggio e validazione dell’input
GIGO : garbage in garbage out A fronte di input scorretti si otterranno risultati scorretti Filtraggio dati Esempio l’età di una persona non può essere un numero negativo Problemi : Buffer overflow Divisione di un numero per 0 AICA © 2005

4 Filtraggio e validazione dell’input
Database Esempio di sql injection Select autorizzato from utenti where id=$utente and pwd = $pass $utente = pippo $pass = caio ; insert into utenti (id,pwd,autorizzato) values (‘uno’,’due’,’si’) Quello che ottengo è Select autorizzato from utenti where id=pippo and pwd = caio ; insert into utenti (id,pwd,autorizzato) values (‘uno’,’due’,’si’) AICA © 2005

5 Buffer overflow Buffer e Stack Il buffer è un blocco contiguo di memoria che risiede nella memoria del PC e che immagazzina dati relativi all'applicazione. In C un buffer viene chiamato array, questi ultimi possono essere dichiarati statici o dinamici: le variabili statiche sono allocate al momento del caricamento sul segmento dati, quelle dinamiche sono allocate al momento del caricamento sullo stack. L'overflow consiste nel riempire un buffer oltre il limite. Per la realizzazione di un exploit di buffer overflow vengono sfruttati gli array dinamici. AICA © 2005

6 Buffer overflow Organizzazione della memoria di un processo (Stack) Per comprendere il funzionamento dei buffer sullo stack bisogna capire il sistema con cui il computer gestisce la memoria di un processo, questi processi sono divisi in tre parti, testo, dati e stack. La regione testo è fissa e contiene il codice del programma in modalità di sola lettura, e per questa ragione un eventuale tentativo di scrittura provoca una violazione di segmento. La regione dati contiene i dati inizializzati e non inizializzati, in questa parte vengono immagazzinate le variabili statiche. La dimensione di questa area può essere cambiata con la chiamata di sistema brk(). AICA © 2005

7 Buffer overflow Vulnerabilità di buffer overflow e attacchi Il motivo di fondo di un attacco di buffer overflow è di prendere il controllo del programma eseguito e nel caso che il software abbia sufficienti privilegi di prendere il controllo dell'host stesso. E' consuetudine per l'attaccante di scegliere un applicativo che "gira" come root per poter avere direttamente una shell di root sul sistema attaccato, questo è anche uno dei motivi per cui software come sendmail (che gira come root) sono stati tra i più utilizzati per attacchi di buffer overflow. Fortunamente questo non è sempre possibile in quanto per poter ottenere una shell di root chi attacca il sistema deve preparare il codice da utilizzare, da far eseguire nello spazio d'indirizzamento del programma, permettere all'applicativo di saltare a quella porzione di codice con parametri esatti, caricati nei registri e nella memoria. AICA © 2005

8 Buffer overflow Modalità di utilizzo di Codice di Attacco Per poter far eseguire codice di attacco al sistema ci sono due strade perseguibili: - Sfruttare il codice esistente - Inserire codice eseguibile L'attaccante fornisce in input al programma una stringa che verrà caricata in un buffer, ad esempio in un'applicazione web tramite POST da form di questa stringa o tramite il metodo di GET La stringa inviata ovviamente non sarà casuale ma conterrà delle istruzioni per la CPU del sistema vittima usando i buffer del software attaccato. AICA © 2005

9 Buffer overflow Vantaggi di questo sistema: - Il buffer può essere localizzato ovunque (Stack, Heap area dati statici) - Non serve nessun buffer overflow in quanto quantità sufficienti di dati possono essere passati al programma senza oltrepassare il limite del buffer. AICA © 2005

10 Buffer overflow Il secondo sistema prevede che il codice sia già adatto ad ottenere ciò che si vuole ed è già presente nello spazio di indirizzamento del software. A questo punto chi attacca deve solo parametrizzare il codice affinchè il programma esegua la parte di codice desiderata ed atta ad offendere l'host e il software vittima. Questi sistemi per essere attuati si basano sulla modifica del flusso del programma in modo da consentire il salto al codice d'attacco. Il metodo per ottenere questo è di sfruttare falle nelle applicazioni dovute al mancato controllo sulla lunghezza nei parametri di input con il risultato di "rompere" il buffer dove l'attaccante potrà sovrascrivere la parte adiacente allo stato del programma con una a propria scelta. AICA © 2005

11 Buffer overflow Tecnica tipica di attacco La tecnica più utilizzata per eseguire un exploit di buffer overflow consiste nell'individuare una variabile automatica soggetta a possibile overflow e invia al programma una stringa molto grande in grado di far tracimare il buffer per poter cambiare il record di attivazione. Con questo sistema l'iniezione del codice maligno e la corruzione del buffer non avvengono contemporaneamente. L'attaccante può iniettare il codice in un buffer senza farlo andare in overflow e far tracimare un altro buffer corrompendo il puntatore di quest'ultimo e farlo puntare al codice maligno. Il buffer che andrà in overflow non deve avere controlli sulla sua dimensione, altrimenti sarà possibile farlo traboccare solo di pochi byte. In questo caso il codice risiederà in un buffer sufficientemente grande e che sarà richiamato dal buffer in overflow. Se l'attaccante sta cercando di utilizzare codice già presente deve parametrizzare il codice per utilizzarlo ai suoi scopi. AICA © 2005

12 Cross-site scripting La grande diffusione dei siti a contenuto dinamico che utilizzano linguaggi lato server (come ASP e PHP) ha favorito lo sviluppo di particolari tecniche di hacking ideate per colpire gli utilizzatori delle applicazioni web. Una delle tecniche più conosciute prende il nome di Cross Site Scripting, spesso abbreviata con CSS (oppure XSS, per non confondere la sigla con quella dei fogli di stile nelle pagine web). AICA © 2005

13 Cross-site scripting Il CSS permette ad un aggressore di inserire codice arbitrario come input di una web application, così da modificarne il comportamento per perseguire i propri fini illeciti. Se uno script consente questo tipo di attacco, è facile confezionare un URL ad hoc e inviarlo all'utente che sarà vittima del sotterfugio. All'utente, ignaro di questa modifica, sembrerà di utilizzare il normale servizio offerto dal sito web vulnerabile. Pagine web o sono i mezzi ideali per portare a termine l'attacco. AICA © 2005

14 Cross-site scripting Quando utilizziamo un servizio che richiede l'inserimento di username e password, spesso questi dati vengono registrati sul nostro computer sotto forma di Cookie (un file di testo) per non doverli digitare ogni volta. Per ovvi motivi di sicurezza, i dati contenuti nel cookie sono accessibili solo dal sito web che li ha creati. Ma supponiamo che il sito in questione utilizzi una applicazione vulnerabile al CSS: l'aggressore potrà iniettare un semplice JavaScript che legge il cookie dell'utente e lo riferisce. Il browser dell'utente permetterà la lettura, perchè in effetti il JavaScript viene eseguito da un sito autorizzato a leggere il cookie! AICA © 2005

15 Cross-site scripting Il risultato immediato è evidente: l'aggressore avrà accesso al cookie e, a seconda delle informazioni contenute, sarà in grado di leggere la nostra posta, oppure di utilizzare il nostro nickname nel forum che frequentiamo (e i nostri privilegi, se ad esempio siamo amministratori), e così via. AICA © 2005

16 Cross-site scripting Oltre al danno, la beffa: il Cross Site Scripting solitamente richiede un intervento attivo da parte della vittima per poter funzionare: anche il click su un link in una pagina web o in un messaggio di posta elettronica può nascondere insidie di questo tipo. Facciamo dunque attenzione ai link sospetti: se contengono i tag <script> all'interno, o se troviamo codice esadecimale (utilizzato perchè viene interpretato normalmente dal server ma nasconde agli occhi dell'utente gli indizi che potrebbero allarmarlo), pensiamoci due volte prima di aprirli! AICA © 2005

17 Cross-site scripting Qualsiasi tipo di applicazione web può essere a rischio, se non implementa opportuni controlli sull'input degli utenti. Vediamo una semplice classificazione in base all'origine del programma: Script casalinghi: la relativa semplicità dei moderni linguaggi lato server permette la creazione di script da utilizzare sui siti web personali. Spesso però le tecniche basilari della programmazione sicura non sono conosciute e gli script offrono molti punti vulnerabili agli attacchi di CSS. Applicazioni web diffuse: le applicazioni web create appositamente per essere diffuse e utilizzate in migliaia di siti (forum, chat, sistemi di gestione dei portali) solitamente sono sviluppate con un maggiore attenzione ai problemi della sicurezza. Ciò non esclude la scoperta periodica di nuove sviste nella programmazione che aprono le porte al Cross Site Scripting. Server web: ancora più pericolosi sono i bug XSS quando riguardano i server web, applicazioni molto diffuse e che solitamente non lasciano presagire la vulnerabilità a questo tipo di attacco. L'unico vantaggio in questo caso è la possibilità di accorgersi tempestivamente dell'attacco in corso, tramite l'analisi dei log del server. AICA © 2005

18 Cross-site scripting Esempi di attacchi reali
Per meglio comprendere i meccanismi del Cross Site Scripting, vediamo due esempi reali riguardanti uno dei forum in PHP più diffusi e il server web di Microsoft. Per il primo esempio consideriamo l'advisory per vBulletin e pubblicata su NTBugtraq. Il forum in questione consente di interagire con il programma di messaggistica AOL Instant Messenger, ma il parametro "aim" dell'URL (che viene stampato poi nella pagina) non è filtrato in alcun modo. Proviamo dunque a inserire un JavaScript come valore della variabile e vediamo cosa succede: AICA © 2005

19 Cross-site scripting Lo script viene inserito nel codice html della pagina e quindi interpretato dal browser dell'utente. Il risultato sarà una popup contenente tutti i dati contenuti nel cookie salvato dal forum: username, password, ultima visita e così via. Anche se i valori sono in forma cifrata, possono essere utilizzati dall'aggressore per sostituirsi a noi. Sicuramente i tag all'interno dell'indirizzo possono destare sospetti. Ma se li sostituiamo con un più criptico codice esadecimale (ad esempio il tag <script> si traduce in %73%63%72%69%70%74) sarà più difficile che la vittima si accorga dell'inganno. Attenzione dunque agli indirizzi che presentano una quantità anomala di segni percentuale "%". AICA © 2005

20 Cross-site scripting Neanche i web server sono immuni dagli attacchi di Cross Site Scripting, anche se in questo caso si tratta di bug più difficili da scoprire e da sfruttare. Il server web di Microsoft IIS 5.0, uno dei più utilizzati, ha avuto in passato vari problemi con l'interpretazione delle estensioni supportate per default. Uno di questi riguardava la possibilità di un attacco XSS tramite la preparazione di un indirizzo URL molto lungo che il server non riusciva a gestire (SecurityFocus Bugtraq) . AICA © 2005

21 Cross-site scripting Normalmente la richiesta di una pagina inesistente con estensione .IDC dovrebbe generare un errore di codice 404. Il bug però faceva in modo che il server restituisse una pagina di errore non standard, contenente l'intero URL richiesto senza alcun controllo sull'input. Come abbiamo visto, quando un JavaScript viene inserito in una pagina html, il browser dell'utente lo interpreta come se facesse parte della pagina originale. Bastava quindi inserire lo script all'interno dell'URL per vederlo eseguito: AICA © 2005

22 Cross-site scripting Il parametro <long_buffer> sta per un insieme di caratteri casuali, in modo che la lunghezza totale dell'URL superi i 334 caratteri. Questa è la lunghezza minima del buffer per la quale il server inizia a mostrare il comportamento anomalo. Consideriamo che il JavaScript è solo uno dei linguaggi che si possono iniettare nelle pagine tramite il CSS: anche VBScript, ActiveX, Flash si prestano al "gioco". AICA © 2005

23 Cross-site scripting bug riscontrati nelle applicazioni web solitamente vengono risolti in breve tempo e le patch sono integrate nelle versioni successive degli script. Per la falla di vBulletin che abbiamo analizzato è necessario scaricare una versione successiva del forum dal sito ufficiale di Jelsoft Enterprises. Per risolvere il bug di IIS 5.0 è necessario installare il Service Pack 3 di Windows 2000 oppure eliminare l'estensione IDC dal mapping delle applicazioni nel pannello di controllo del servizio Internet Microsoft. AICA © 2005

24 Cross-site scripting Molti dei bug relativi al Cross Site Scripting possono essere risolti implementando una procedura di validazione dell'input negli script. Gli sviluppatori dovrebbero quindi cercare di essere sensibili ai temi della sicurezza, anche se non indispensabili al fine dell'applicazione. In qualità di utenti possiamo fare attenzione ai link che apriamo e alla presenza di anomalie. La disattivazione del supporto JavaScript o l'impostazione del livello Alto di protezione possono contrastare i codici nocivi ma creano problemi alla normale navigazione. Ricordiamo inoltre che le connessioni criptate tramite SSL (riconoscibili dall'url che inizia con https) non offrono una protezione aggiuntiva per queste falle. AICA © 2005

25 Cross-site scripting : approfondimenti
HOWTO: Prevent Cross-Site Scripting Security Issues Cross-site Scripting Overview Cross-Site Scripting: Frequently Asked Questions Quick Start: What Customers Can Do to Protect Themselves from Cross-Site Scripting Hacker! Nuove tecniche di protezione, ed. Apogeo, pp AICA © 2005

26 DoS l DoS, scritto con la maiuscola al primo e terzo posto, è la sigla di denial of service, letteralmente negazione del servizio. In questo tipo di attacco si cerca di portare il funzionamento di un sistema informatico che fornisce un servizio, ad esempio un sito web, al limite delle prestazioni, lavorando su uno dei parametri d'ingresso, fino a renderlo non più in grado di erogare il servizio. Anche limitando il discorso al blocco di un sito web, esistono, e sono stati utilizzati, parecchi modi di ottenere questo risultato. AICA © 2005

27 DoS : su singolo host Syn-Flood
Il più banale, e storicamente il primo, si chiama Syn-Flood o Syn-Flooding, letteralmente "inondazione di pacchetti di tipo Syn". Tutte le volte che un utente fa click su di un link di una pagina web richiede l'apertura di una connessione (di tipo TCP) verso quel sito; questo avviene seguendo una serie di passi, il primo dei quali consiste nell'invio di un pacchetto TCP che richiede l'apertura di una connessione. Le regole di funzionamento del protocollo TCP esigono che il sistema risponda allocando alcune risorse (in pratica memoria) per la connessione. Se si programma opportunamente un semplice PC, è possibile richiedere l'apertura di diverse migliaia di connessioni al secondo, che "inondando" il server, ne consumano rapidamente tutta la memoria, bloccandolo o mandandolo in crash. Il problema di questo tipo di attacco è che il computer attaccante deve poter mandare il flusso di pacchetti attraverso la connessione ad Internet fino al server attaccato; poiché le connessioni che sono normalmente disponibili, sia per i buoni che per i cattivi, sono lente, questo diventa impossibile. AICA © 2005

28 DoS : su singolo host Smurf
Una modalità di attacco più sofisticata, detta Smurf, utilizza un flusso di pacchetti modesto, in grado di passare attraverso una normale connessione via modem, ed una rete esterna, che sia stata mal configurata, che agisce da moltiplicatore di pacchetti, i quali si dirigono infine verso il bersaglio finale lungo linee di comunicazione ad alta velocità. Si noti che questo tipo di attacco è possibile solo in presenza di reti che abbiano grossolani errori di configurazione dei sistemi (detti router) che le collegano tra loro e con Internet. AICA © 2005

29 Attacchi da più hosts DDoS
Una variante di tale approccio è il DDoS (Distributed Denial of Service) dal funzionamento identico ma realizzato utilizzando numerose macchine attaccanti. AICA © 2005

30 DDoS Gli attaccanti tendono ad non esporsi direttamente, dato che per le forze dell'ordine sarebbe relativamente semplice risalire ai computer utilizzati per l'attacco. Gli attaccanti, per evitare di essere individuati e per avere a disposizione un numero sufficiente di computer per l'attacco inizialmente, infettano un numero elevato di computer con dei virus o worm che lasciano aperte delle backdoor a loro riservate. I computer che sono controllati dall'attacante vengono chiamati zombie. Quando il numero di zombie è ritenuto adeguato, o quando scatta una specifica data, i computer infetti si attivano e sommergono il server bersaglio di false richieste. Con l'avvento della banda larga il fenomeno dei DDOS sta assumendo proporzioni preoccupanti, dato che attualmente esistono milioni di persone dotate di una connessione ad Internet molto veloce e permanente ma con scarse o nulle conoscenze e contromisure riguardanti la sicurezza informatica. AICA © 2005

31 DDoS Reflected DDoS Una particolare categoria di DDoS è il cosí detto Reflected DDoS. In questa particolare tipologia di attacco, il computer attaccante produce delle richieste di connessione verso server con connessioni di rete molto veloci utilizzando come indirizzo di provenienza non il proprio bensí quello del bersaglio dell'attacco. In questo modo i server risponderanno affermativamente alla richiesta di connessione non all'attaccante ma al bersaglio dell'attacco. Una tale scenario vede immediatamente esaurirsi le risorse del bersaglio. AICA © 2005

32 DDoS Quest'ultimo tipo di attacco è particolarmente subdolo perché, a causa della natura delle risposte, è difficilmente schermabile dall'utente comune: infatti se si filtrassero le risposte dei server verrebbe compromessa la funzionalitá stessa della connessione di rete impedendo, di fatto, la ricezione anche delle informazioni desiderate. Le risposte dei server, sollecitate dall'attaccante, sono infatti indistinguibili da quelle generate da una richiesta legittima della vittima. Il problema si sta presentando con maggiore incidenza da quando Microsoft ha deciso di rendere le "Raw Sockets", interfaccia di accesso al TCP/IP, facilmente disponibili. Le RAW sockets permettono appunto di cambiare l'indirizzo di provenienza del pacchetto per sostituirlo con quello della vittima, fatto che è strumentale per questo tipo di attacco. AICA © 2005

33 adware advertiseware o, più brevemente, adware.
programmi shareware gratuiti in quanto il loro uso è condizionato all'accettazione di piccoli banner pubblicitari che vengono periodicamente visulizzati durante il loro utilizzo: sono questi che compensano la distribuzione gratuita. Questi programmi richiedono la registrazione on-line, consistente nel fornire il vostro indirizzo ed eventualmente altri dati trattati a fini statistici. Generalmente alla registrazione di questi programmi, fanno seguito continue ... dirette o conseguenti al banner eventualmente cliccato. E' etico? Molti dicono di no; alcuni possono dire sì. AICA © 2005

34 adware Gli adware, per loro natura (cioé di programmi), fanno o possono fare di tutto, anche leggere i dati nel vostro computer. Ovviamente questa non è una buona notizia, però ci sono due soluzioni: installare un firewall che limiti la condivisione delle informazioni in rete e/o un programma che individui e cancelli i cyber-intrusi. AICA © 2005

35 spyware Programmi che possono esaminare sistemi o monitorarne di nascosto l'attività e trasmettere informazioni riservate ad altri computer. Tra le informazioni che possono essere raccolte e diffuse in modo attivo o passivo da Spyware: password, dati di log-in, numeri di account, informazioni riservate, file individuali e altri documenti personali. Spyware può anche raccogliere e distribuire informazioni legate al computer dell'utente, alle applicazioni eseguite sul computer, all'uso del browser Internet o ad altre abitudini legate all'utilizzo del computer. AICA © 2005

36 spyware I programmi spyware tentano spesso di rimanere inosservati, nascondendosi attivamente o semplicemente non rivelando la propria presenza nel sistema agli utenti. I programmi spyware possono essere scaricati da siti Web (tipicamente in shareware o freeware), messaggi di e istantanei. Un utente può anche attivare inconsapevolmente lo spyware accettando il contratto di licenza d'uso di un programma ad esso collegato o visitando un sito Web che scarica lo spyware con o senza un contratto di licenza d'uso. AICA © 2005

37 Esempi di uso illecito di MIME
Virus Kurnikova Sfruttava una falla di outlook Veniva inviata una mail Content-type = image/jpg Allegato : kurnikova.jpg.exe Il client mail visualizzava l’allegato con l’icona associata ai file di immagine L’utente l’apriva A quel punto il SO si accorgeva che in reltà l’allegato è un eseguibile ed eseguiva il virus AICA © 2005

38 Esempi di uso illecito delle macro
Virus Melissa Sfruttava le macro in outllok express Si diffondeva via posta inviandosi ai primi 50 nomi presenti in rubrica Office esiste anche su Mac, di conseguenza macro affette da virus possono colpire anche sistemi apple AICA © 2005

39 Esempi di uso illecito degli Applet
Dialer applet che utilizzano un computer o un modem per comporre un numero di accesso o un sito Internet a pagamento, tipicamente a tariffe elevate. I dialer possono installarsi (o meno) con o senza l'autorizzazione esplicita dell'utente e possono svolgere la loro attività a sua insaputa AICA © 2005

40 Come difendersi Visualizzare sempre le estensioni dei file
Non attivare automaticamente preview ecc. Non attivare automaticamente Outlook da IE e viceversa In generale mai attivazioni automatiche basate sul tipo di file Disattivare o limitare le macro in Outlook, Word ... AICA © 2005

41 Come difendersi Disattivare Java, ActiveX e JavaScript
Usare un Web Proxy Filtering e Firewall (vedi 5.7) Usare un buon AntiVirus (vedi 5.5.2) Non andare in chat Verificare i cookies Scegliere un buon programma di posta e di navigazione, e tenerli aggiornati AICA © 2005

42 Codice virale (maligno)
Virus : è un frammento di programma che viene eseguito solo quando il programma che lo ospita è eseguito, non si propaga da solo Worm: Si propaga e si attiva da solo Cavallo di Troia: programma con funzionalità nascoste che danneggiano o aprono porte di accesso al nemico (backdoor) AICA © 2005

43 Virus Distribuzione o Riproduzione: parassita, bootsector, multipartizione Azione: sua effettiva attività Innesco (trigger): Immediato bomba logica bomba a tempo Virus polimorfici e cifrati AICA © 2005

44 Worm & Cavallo di Troia WORMS: si propagano da soli sfruttando debolezze di programmi e sistemi operativi, spesso utilizzano più di un metodo di propagazione TROJANS: programmi installati dall'utente ma con delle proprietà nascoste, i.e. permettere l'accesso remoto ad altri Bufale (hoax): finte notizie di virus propagate con Catene di Sant Antonio che spingono gli utenti a fare disastri da soli AICA © 2005

45 Worm & Cavallo di Troia Rootkit: in genere worms o trojans per sistemi operativi Unix/Linux, sfruttando problemi nei programmi suid acquistano le credenziali di root, controllano la macchina ed aprono backdoor AICA © 2005

46 Metodi di Infezione Floppy, CDROM, DVD, ZIP, nastri ... Email
Servizi Internet aperti Pagine Web Documenti con Macro ...... AICA © 2005

47 AntiVirus Agiscono sui file presenti sui dischi ed in memoria RAM
Si basano sulle FIRME Problema con i virus polimorfi (istruzioni NOP..) Problema dell'aggiornamento ! Alcuni adottano anche ANALISI EURISTICHE Uso delle SANDBOX per analisi eseguibili ed in determinate situazioni (MBR ecc.) AICA © 2005

48 AntiVirus Locali: Fanno scansione a richiesta e/o periodica di ciò che si è richiesto: solo disco, solo floppy, solo ... AntiVirus centrale per esamina i messaggi di posta PRIMA che arrivino nella casella del destinatario Conosce i protocolli (smtp, imap, pop3) e si inserisce come un proxy tra mittente e destinatario AICA © 2005

49 AntiVirus AntiVirus centrale per estrae tutti gli allegati secondo il loro tipo MIME Verifica che non vi siano Virus in ogni allegato Se trova un Virus parcheggia il messaggio in una area apposita e invia un messaggio di avviso al destinatario Problema con le restrizioni della Privacy ? AICA © 2005

50 AntiVirus Aggiornamento dell' AntiVirus: solo dopo che un Virus è in giro può essere preparata la sua FIRMA Inizio 2002: aggiornarsi settimanalmente Fine 2002: aggiornarsi quotidianamente Giugno 2003: aggiornarsi ogni 2 ore !!!!!!!!!!! AICA © 2005

51 Come difendersi EDUCARE gli utenti
Avere un Antivirus sia centralizzato (aggiornato ogni 2 ore) che su ogni macchina meglio se di vendor diversi Installare tutte le patch di tutti i programmi (!!) Attenzione a comportamenti anomali Avere buoni backup dei dati e procedure di reinstallazione Avere una buona Sicurezza di rete AICA © 2005