AICA Corso IT Administrator: modulo 5 AICA © 2005 1 EUCIP IT Administrator Modulo 5 - Sicurezza...

AICA © 2005 1

AICACorso IT Administrator: modulo 5

EUCIP IT AdministratorModulo 5 - Sicurezza Informatica

5 – codice maligno

Alberto Bosio

AICA © 2005 2


programmi

• Programmi compilati– C, Basic, Pascal

• Programmi interpretati– PERL, PHP

– Comandi shell (shell script)

• Macro – Programmi interpretati

– 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 outA fronte di input scorretti si otterranno risultati scorretti

• Filtraggio datiEsempio 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 StackIl 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 attacchiIl 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 AttaccoPer 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 GETLa 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 attaccoLa 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



• 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 e-mail sono i mezzi ideali per portare a termine l'attacco.

AICA © 2005 14



• 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



• 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



• 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



• 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



• 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 2.2.6 e 2.2.7 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:

www.host.com/forum/member.php?s=&action=aimmessage&aim=<script>alert(document.cookie)</script>

AICA © 2005 19



• 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



• 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



• 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



• http://www.host.com/<long_buffer><script_da_eseguire>.idc• http://www.host.com/

<long_buffer><script>alert(document.cookie)</script>.idc

• 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



• 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



• 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– http://support.microsoft.com/default.aspx?scid=kb;en-

us;252985&sd=tech

• Cross-site Scripting Overview– http://www.microsoft.com/technet/security/news/csoverv.mspx

• Cross-Site Scripting: Frequently Asked Questions– http://www.microsoft.com/technet/security/news/crsstfaq.mspx

• Quick Start: What Customers Can Do to Protect Themselves from Cross-Site Scripting– http://www.microsoft.com/technet/security/news/crsstqs.mspx

• Hacker! 4.0 - Nuove tecniche di protezione, ed. Apogeo, pp. 612 - 613

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 e-mail ed eventualmente altri dati trattati a fini statistici. Generalmente alla registrazione di questi programmi, fanno seguito continue e-mail... 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-mail 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 email ...

• AntiVirus centrale per email: 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 email: 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 Email 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 Corso IT Administrator: modulo 5 AICA © 2005 1 EUCIP IT Administrator Modulo 5 - Sicurezza...

Documents

Transcript of AICA Corso IT Administrator: modulo 5 AICA © 2005 1 EUCIP IT Administrator Modulo 5 - Sicurezza...