Rapporto CESI. Cliente: Oggetto: Ordine: CESI A1/ COMUNICA/VULNERA/2003/04. Note: N. pagine: 52 N. pagine fuori testo: 57 Data: 30/06/2003

Transcript

1 Rapporto CESI A3/ Pag.1/52 Cliente: Ricerca di Sistema Oggetto: Infrastrutture di Prova per le Funzioni di Affidabilità e Sicurezza Ordine: CESI A1/ Note: COMUNICA/VULNERA/2003/04 senza l'autorizzazione scritta del CESI questo documento può essere riprodotto solo integralmente N. pagine: 52 N. pagine fuori testo: 57 Data: 30/06/2003 Elaborato: FIA - Giovanna Dondossola, Giuseppe Mauri Verificato: FIA - Emanuele Ciapessoni Approvato: FIA - Emanuele Ciapessoni, Anna Rosa Tiramani CESI Via R. Rubattino 54 Capitale sociale Euro Registro Imprese di Milano Centro Elettrotecnico Milano - Italia interamente versato Sezione Ordinaria Sperimentale Italiano Telefono Codice fiscale e numero N. R.E.A Giacinto Motta SpA Fax iscrizione CCIAA P.I. IT

2 Rapporto CESI A3/ Pag.2/52 Indice SOMMARIO INTRODUZIONE INFRASTRUTTURA DI PROVA CARATTERIZZAZIONE DI UNO SCENARIO DI ATTACCO TECNOLOGIE PER LA SICUREZZA DA UTILIZZARE NELLA INFRASTRUTTURA DI PROVA TIPOLOGIE DI SOFTWARE DA INSTALLARE NELLA INFRASTRUTTURA DI PROVA I COMPONENTI DELL INFRASTRUTTURA DI PROVA Componenti per effettuare una prova in bianco su un ToE PROVE DI VULNERABILITÀ DI IPV COLLEZIONE DI INFORMAZIONI SUL SISTEMA SCANNING DEL SISTEMA DA ATTACCARE RICERCA DEGLI SNIFFER IN RETE ANALISI DEL TRAFFICO DEL SISTEMA DA ATTACCARE IMPERSONIFICAZIONE DELL UTENTE ATTACCO DI TIPO MITM ATTACCO DI TIPO DOS COMUNICAZIONE TRAMITE RETE PRIVATA VIRTUALE RETE PRIVATA VIRTUALE IPSEC Il protocollo AH Modalità transport e tunnel VPN DEPAUDE VULNERABILITÀ DELLA RETE PRIVATA VIRTUALE IPSEC VULNERABILITÀ DI IPSEC INFRASTRUTTURA DI PROVA DELLA VPN IPSEC Regole di filtraggio dei Gateways Istallazione di IPSEC PROVA DELLE VULNERABILITÀ DELLA VPN Collezione di informazioni sui Gateways Scanning dei Gateways DoS dei Gateway Attacco al meccanismo di crittografia della VPN TECNOLOGIE DI SICUREZZA CONCLUSIONI...49 BIBLIOGRAFIA...50 ANNESSO...52 Copyright 2003 by CESI. All rights reserved - Activity code 33340F Keywords: 18060P 25460C 49055U 51201H 60130L

3 Rapporto CESI A3/ Pag.3/52 Indice delle Figure Figura 1: Schema hardware dell Infrastruttura di Prova Figura 2: Distribuzione temporale di un attacco e della relativa difesa Figura 3: Mappa di una rete eseguita con Cheops Figura 4: Esiti della scansione di un sistema Windows Figura 5: Esiti della scansione di un sistema Linux Figura 6: Scansione rete [1-120] con un rivelatore di sniffer Figura 7: Contenuto di un pacchetto scambiato tra due macchine Figura 8: VPN DepAuDE Figura 9: Infrastruttura di Prova della VPN DepAuDE Figura 10: Infrastruttura di Prova di IPSEC: versione minimale Figura 11: Infrastruttura di prova della VPN IPSEC: versione estesa Figura 12: Architettura sicura Indice delle Tabelle Tabella 1: Tecniche e relative tecnologie di cyber-security...14 Tabella 2: Strumenti dell Infrastruttura di Prova Tabella 3: Sistemi Operativi da considerare in una infrastruttura di prova Tabella 4: Strumenti utilizzati per attaccare e per difendere Tabella 5: Risultati interrogazione WHOIS database Tabella 6: Risultati interrogazione ARIN database Tabella 7: Comandi per raccogliere informazioni su alcuni domini Tabella 8: Esempi di output di telnet a webserver Tabella 9: Esempi di output di nmap Tabella 10: Esempi di output di ping Tabella 11: Esempi di output di traceroute Tabella 12: Privacy e Sicurezza in tre implementazioni del protocollo IP Tabella 13: Tipi di attacco di una VPN IPSEC Tabella 14: Funzioni di sicurezza Copyright 2003 by CESI. All rights reserved - Activity code 33340F Keywords: 18060P 25460C 49055U 51201H 60130L

4 Rapporto CESI A3/ Pag.4/52 Tabella degli Acronimi ADAR Ambiente Distribuito per l Automazione e il Recupero di anomalie AH Authentication Header ARP Address Resolution Protocol ASFA Ambiente di Specifica di Funzioni di Automazione BSL Basic Service Layer CERT Computer Emergency Response Team COTS Commercial Off The Shelf DNS Domain Name Server DoS Denial of Service EP Encapsulation Protocol ESP Encapsulating Security Payload FTP File Transfer Protocol HTTP HyperText Transfer Protocol ICMP Internet Control Message Protocol ICT Information and Communication Technology IdP Infrastruttura di Prova IDS Intrusion Detection System IDRS Intrusion detection & Response System IETF Internet Engineering Task Force IKE Internet Key Exchange IP Internet Protocol IPSEC Internet Protocol SECurity IPv4 Internet Protocol Version 4 IPv6 Internet Protocol Version 6 ISAKMP Internet Security Association and Key Management Protocol ISP Internet Service Provider L2TP Layer 2 Tunnelling Protocol LAN Local Area Network MAC Medium Acces Control MITM Man In The Middle PGW Physical Gateway PKI Public Key Infrastructure QoS Quality Of Service SA Security Association Copyright 2003 by CESI. All rights reserved - Activity code 33340F Keywords: 18060P 25460C 49055U 51201H 60130L

5 Rapporto CESI A3/ Pag.5/52 SHA SPD TCP ToE TTL UDP URL VPN WAN Secure Algorithm Security Policy Database Transmission Control Protocol Target of Evaluation Time To Live User Datagram Protocol Uniform Resource Locator Virtual Private Network Wide Area Network Copyright 2003 by CESI. All rights reserved - Activity code 33340F Keywords: 18060P 25460C 49055U 51201H 60130L

6 Rapporto CESI A3/ Pag.6/52 STORIA DELLE REVISIONI Numero Data Protocollo Lista delle modifiche e/o dei paragrafi modificati revisione 1 A3/ Creazione

7 Rapporto CESI A3/ Pag.7/52 SOMMARIO Il rapporto presenta inizialmente le caratteristiche di una classe di Infrastrutture di Prova per Sistemi di Automazione distribuiti su larga scala (a livello di rete WAN) tramite reti aperte tipo Internet. Due istanze specifiche di Infrastrutture di Prova vengono poi utilizzate per presentare un approccio alla costruzione di un architettura di Sistema sicura per passi successivi e guidato dai risultati delle prove. Scopo dell architettura è connettere in maniera più sicura possibile un impianto automatizzato al suo Centro di Controllo, proteggendo il sistema di automazione da tentativi di attacco provenienti da persone esterne al sistema e connesse a Internet. Un primo insieme di prove riguarda i Sistemi che comunicano tramite il protocollo standard IPv4. A seguito dei risultati delle prove di vulnerabilità del protocollo IPv4 vengono individuati due protocolli di comunicazione sicuri, basati sulla rete pubblica IP, che integrano servizi di tunnelling, autenticazione e crittografia. Il primo protocollo selezionato, IPSEC, è standard e disponibile nella nuova versione IP. Il secondo protocollo, sviluppato nel Progetto Europeo DepAuDE fornisce delle funzionalità aggiuntive finalizzate al miglioramento di tempi e probabilità di consegna dei pacchetti dell IP standard. Utilizzando un protocollo sicuro per la comunicazione tra Centro di Controllo e Impianto controllato si eliminano un certo numero di possibilità di attacco individuate in [VULNERA,2002] e dimostrate dal primo insieme di prove. Successivamente si utilizza una specifica Infrastruttura di Prova per effettuare un secondo insieme di prove di vulnerabilità relative al protocollo IPSEC. Le prove effettuate dimostrano che l'utilizzo di un protocollo sicuro non è ancora sufficiente ad eliminare tutte le tipologie di attacco. Vengono quindi identificate e descritte alcune tecnologie di sicurezza da integrare in un'architettura di Sistema ritenuta più robusta. Il presente rapporto riassume i risultati principali dell'attività svolta: il capitolo 1 introduce l argomento, le motivazioni e gli obiettivi delle Infrastrutture di Prova il capitolo 2 caratterizza le Infrastrutture di Prova in termini di tecnologie di sicurezza informatica, strumenti software e componenti hardware il capitolo 3 descrive un Infrastruttura utilizzata per provare le vulnerabilità del protocollo IPv4 il capitolo 4 presenta la tecnologia di comunicazione Virtual Private Network (nel seguito VPN), due specifiche realizzazioni di VPN, IPSEC e la VPN DepAuDE il capitolo 5 racconta le vulnerabilità della VPN IPSEC il capitolo 6 si focalizza sulle tecnologie di sicurezza da introdurre nella Infrastruttura di Prova. il capitolo 7 valuta i risultati raggiunti dall attività svolta.

8 Rapporto CESI A3/ Pag.8/52 Alcuni dettagli relativi al protocollo IPSEC utilizzato, alle prove effettuate presso il Laboratorio del JRC e alle tecnologie di sicurezza si possono trovare nell'annesso 1 redatto in lingua Inglese 1. 1 Nota alla lettura: per ragioni di uniformità e coerenza nell'uso di termini specialistici del settore in cui lo Studio si colloca, il presente rapporto fa ampio uso di termini e acronimi inglesi. Gli autori si scusano per l'eventuale disagio provocato ad un pubblico purista della lingua italiana. Analogamente gli autori si scusano per l uso massiccio di acronimi, purtroppo inevitabile e imperversante nel mondo delle tecnologie ICT.

9 Rapporto CESI A3/ Pag.9/52 1 INTRODUZIONE La sopravvivenza (da survivability) è una proprietà dei sistemi software che si riferisce alla capacità di portare a termine la loro missione entro un preciso limite temporale in presenza di attacchi, guasti o incidenti. Per assolvere al loro compito in modo continuativo questi sistemi devono essere in grado di evolvere nel tempo implementando nuove funzionalità create da un ambiente che cambia, e sfruttando le opportunità offerte dai progressi tecnologici. Un assunzione fondamentale alla base della survivability è che nessun componente singolo può essere reso immune in modo esaustivo a tutti i possibili attacchi, incidenti o errori di progetto [Fisher and Lipson, 1999]. Questa affermazione è sopportata dal fatto che: 1) le tecniche e i metodi di verifica usati comunemente dall ingegneria del software hanno notevoli lacune 2) di solito le assunzioni alla base dei disegni sono in parte sbagliate come ad esempio l ipotizzare che i requisiti sono completi e corretti, che non ci sono errori nel disegno, che non è stato introdotto codice dannoso, che non ci sono utenti maliziosi, che il sistema non è stato modificato impropriamente, che l hardware si comporta in un modo sufficientemente prevedibile e infine che il guasto peggiore è stato considerato 3) le persone umane non sono infallibili 4) esistono sempre delle situazioni incontrollabili quali i disastri naturali 5) la comunità degli sviluppatori tende a rallentare lo sviluppo di idee nuove e a sviluppare concetti pratici e consolidati 6) non è possibile prevedere tutti i possibili scenari, specialmente le interdipendenze tra le diverse parti di sistemi complessi 7) i sistemi complessi sono costruiti con componenti commerciali (COTS). Questi prodotti sono ben conosciuti ad un ampio spettro di persone, inclusi gli utenti maliziosi. I COTS sono sempre largamente testati e le loro vulnerabilità note, e quindi pronte per essere sfruttate [Neumann, 1995; Brooks, 1995; Fisher and Lipson, 1999; Ghosh and Voas, 1999]. Scopo dell attività riportata nel documento è definire un'infrastruttura di Prova delle proprietà di sicurezza di Sistemi di Automazione Elettrici distribuiti a livello geografico e caratterizzati da un architettura aperta, cioè basata sulla rete pubblica Internet. Il documento caratterizza i componenti e le funzionalità di un'infrastruttura in grado di dimostrare, con delle Prove di Laboratorio che simulano le situazioni di anomalia, che l architettura del Sistema di Automazione oggetto di valutazione è sufficientemente robusta, cioè in grado di soddisfare i requisiti di sicurezza, di prestazioni e di disponibilità della comunicazione per l'automazione elettrica descritti in [VULNERA 01,2003]. In particolare l Infrastruttura di Prova deve dimostrare che l architettura del sistema è in grado di proteggere i suoi componenti da attacchi che originano in qualche stadio del percorso di comunicazione

10 Rapporto CESI A3/ Pag.10/52 tra la Rete di Impianto e i Centri Remoti interconnessi all automatismo di impianto. Il lavoro si è focalizzato sugli attacchi relativi agli strati 3/Network-7/Application del modello ISO/OSI.

11 Rapporto CESI A3/ Pag.11/52 2 INFRASTRUTTURA DI PROVA Un Infrastruttura di Prova (IdP nel seguito) per l Automazione Elettrica rappresentata in Figura 1 si definisce essere una architettura di componenti di Informazione e Comunicazione (ICT) appositamente studiata per consentire di costruire un insieme significativo (coerente e consistente) di prove in grado di affermare la robustezza, o identificare le debolezze, di un sistema distribuito di automazione connesso al Sistema Elettrico (o a una sua parte). La robustezza di un sistema ICT si caratterizza in relazione ai rischi potenziali a cui il sistema è esposto a causa di vulnerabilità, threats e attacchi di varia natura e origine [VULNERA, 2002]. Prima di introdurre le tecniche, il software e i componenti di una IdP, ci sembra utile capire la dinamica di uno scenario d attacco, al fine di pervenire ad una corretta determinazione delle difese necessarie, nonché del tempo disponibile per attuarle efficacemente. FreeBDS Solaris Windows NT/2k/XP PC Multi OS Linux GSM/ GPRS Sniffer & Antisniffer Switched Ethernet FireWall VPN Router TCP/IP WAN FireWall DHCP DNS Network IDS IIS W2k Apache Linux DMZ Site A: Potential configuration for the control centre (it has a DMZ, but not RT comunication) (Mainly ICT Domain) Attacker 1 Attacker 2 Protocol Analyser & Antisniffer VPN TCP/IP WAN GSM/ GPRS Router FireWall Solaris Windows NT/2k/XP Switched Ethernet PC Multi OS Linux Host IDS Gateway PLC Switched Ethernet Industrial PC 2 FireWall DHCP DNS Network IDS Gateway Industrial PC 1 Site B: It does not have a DMZ, it has a RT subnet (AUTOMATION Domain) Figura 1: Schema hardware di un Infrastruttura di Prova.

12 Rapporto CESI A3/ Pag.12/ Caratterizzazione di uno scenario di attacco Un processo di attacco è articolato in quattro fasi realizzative: fase di hiding: si espleta tramite, ad esempio, mascheramento della linea telefonica, utilizzo di sistemi ponte, cancellazione di Logs sui sistemi di partenza, abuso di ISP collezione di informazioni (scan test) o fase di ricognizione: si espleta mediante esportazione della DNS Zone utilizzo di tools TCP/IP di tipo Host e Port Scanner determinazione delle vulnerabilità verifiche manuali con Raw Server Query, Web/FTP, SMTP, Authentication, Router/Firewall, conoscenze sui bachi del software fase di intrusione (penetration test): sfruttamento delle vulnerabilità scoperte nella fase precedente, penetrazione nel sistema preso di mira, esplorazione del sistema attaccato fase di post-attacco: rimozione delle tracce. Una esemplificazione di attacco è rappresentata nella Figura 2: inizialmente un potenziale attaccante raccoglie le informazioni ed esegue dei test. In questo periodo chi difende il sistema attaccato (in gergo il Security Officer) dovrebbe essere in grado di riconoscere le azioni dell attaccante, e di organizzare rapidamente gli strumenti per evitare l attacco vero e proprio. Se fallisce il riconoscimento preventivo dell attacco, ed anche la predisposizione delle contromisure, sopraggiunge l attacco vero e proprio che si protrae fino a quando non vengono prese delle contromisure di contenimento opportune. attacker reconnaissance test attacks damage occurs detections counteraction repression & reduction restore defender Figura 2: Distribuzione temporale di un attacco e della relativa difesa.

13 Rapporto CESI A3/ Pag.13/52 Una volta bloccato l attacco, occorre rimediare ai danni subiti e riportare il sistema nella condizione iniziale. La fase di collezione delle informazioni è particolarmente rilevante: dalle esemplificazioni che introdurremo in seguito si può capire quali informazioni (estraibili da tools/comandi di sistema disponibili) costituiscono la base di un tentativo di attacco. 2.2 Tecnologie per la Sicurezza da utilizzare nella Infrastruttura di Prova Dall analisi delle vulnerabilità delle applicazioni ICT del settore elettrico condotta in [VULNERA 01,2003] risulta evidente che è necessario progettare soluzioni che adattino/integrino diverse tecnologie per la sicurezza cibernetica. Le configurazioni dei più moderni sistemi di protezione e controllo delle reti elettriche sono basate su sistemi di dispositivi ad intelligenza distribuita, in cui le reti di controllo sono connesse a reti di archiviazione e servizi in un sistema gerarchico di reti di reti. Esistono diverse tecniche che possono essere usate per salvaguardare IED, PLC, RTU, controllori di processo, sistemi SCADA, e in linea di principio qualsiasi tipo di dispositivo digitale programmabile utilizzato per la protezione ed il controllo dei sistemi elettrici. Le modalità più tipiche per combattere le intrusioni nei computer comprendono l autenticazione dei partecipanti alla comunicazione, la messa in sicurezza della connessione tra i siti, il criptaggio della comunicazione tra i siti, e l identificazione delle intrusioni se e quando si verificano nella rete. La Tabella 1 elenca le principali funzioni e le relative tecnologie per la pratica della Sicurezza. Restrizione degli accessi e Autenticazione dell utente La restrizione degli accessi può essere sia fisica che logica. L autenticazione dell utente si realizza quando si ha una mappatura unoad-uno tra l utente ed il meccanismo di autenticazione. Le tecnologie utilizzate per i due scopi sono simili. Una semplice restrizione degli accessi si ottiene, ad esempio, assegnando la stessa password o PIN ad un certo numero di utenti. I dispositivi di autenticazione utilizzano tre tipi di vettori, o una combinazione di questi: quello logico, quello fisico e quello biologico. Consideriamo esempi di ciascun vettore. Passwords/PINs: l inserimento di un unica password o PIN consente al sistema di protezione di identificare la persona come utente legittimo Dispositivi ID: sono (di solito) meccanismi elettromagnetici che forniscono l autenticazione a partire da dati fisici ( Cosa possiedi ). Esempi di dispositivi ID elettromagnetici sono carte di credito,

14 Rapporto CESI A3/ Pag.14/52 Accountability Crittografia Sicurezza della rete Anti-intrusioni Verifica vulnerabilità software Servizi di supporto Soluzioni architetturali SmartCard, strisce magnetiche, codici a barre Biometrica: comprende i meccanismi nel vettore di autenticazione biologico: impronte digitali, modelli della retina, timbro della voce, modelli facciali. Vengono usati per autorizzazione dell accesso sia locale sia remoto audit logs: registrano tentativi validi o non validi di autenticazione utenti e di inizio e fine sessione, in modo che per ciascun accesso o tentativo di accesso al sistema esista un record di dati. Tramite Log files o firme digitali Scrittura cifrata o convenzionale che può essere compresa solo da chi ne conosce la chiave. E utilizzata per proteggere i pacchetti di dati mentre transitano dalla sorgente alla destinazione. Solo i destinatari delle informazioni saranno in grado di riconvertirle nella forma originaria. E alla base di molte tecnologie di sicurezza. Si realizza tramite: Firewall Rete Privata Virtuale (VPN) Infrastruttura di chiavi pubbliche (PKI) Si realizza con Intrusion Detection (and Response) Systems a livello di host o di rete Intrusion Tolerant Systems Forensic Systems: prove controllate tramite tecnologia Honeypot Vulnerability Scanner Backup & Recovery Tecnologie di fault tolerance, uso di ridondanze Tabella 1: Tecniche e relative tecnologie di cyber-security Le tecnologie di sicurezza necessarie per la protezione di un sistema devono essere integrati in un architettura opportuna. L idea alla base dell architettura proposta nel Progetto Europeo MAFTIA 2 è che i componenti del ToE possono essere monitorati internamente o esternamente per rilevare comportamenti erronei. Alcuni componenti possono avere la capacità di recuperare autonomamente gli errori rilevati. Gli errori rilevati devono essere riportati ad un componente del sistema responsabile della diagnosi e della gestione delle intrusioni a livello di tutto il sistema. 2 Malicious-and Accidental-Fault Tolerance for Internet Applications, IST

15 Rapporto CESI A3/ Pag.15/52 Una tecnica emergente per la protezione dei sistemi ICT è l effettuazione di prove controllate tramite Honeynet. L assunzione fondamentale di questa tecnica è che, per analizzare le vulnerabilità e progettare sistemi in grado di difendersi, occorre la disponibilità di dati sugli attacchi. La tecnologia Honeynet definisce con precisione il processo di collezione dei dati sugli attacchi e, attraverso una vasta gamma di sensori, raccoglie i dati sugli attacchi reali che diventano disponibili per comprendere meglio le minacce a cui il sistema è sottoposto. 2.3 Tipologie di software da installare nella Infrastruttura di Prova Va osservato che allo stato attuale degli strumenti disponibili si rende necessario installare e confrontare più strumenti (sia commerciali sia gratuiti) di una stessa classe di tecnologie. L'integrazione di più tipi di strumenti consente di ottenere risultati attendibili. Gli strumenti commerciali garantiscono una maggior copertura dei tipi di sistemi considerati, mentre gli strumenti gratuiti forniscono un aggiornamento tempestivo della base di conoscenza delle vulnerabilità note. La seguente matrice mostra come alcuni strumenti dell Infrastruttura di Prova possano essere utilizzati sia per l'attacco che per la difesa di una architettura da valutare (indicata con il nome di Target of Evaluation ToE). Tipicamente un amministratore di sistema applica gli strumenti di analisi (sniffers, analizzatori di protocollo) per scoprire le vulnerabilità dei propri sistemi ed applica gli hardening tools per ridurle il più possibile. Il difensore del sistema attaccato utilizza strumenti di detection (firewall, IDS) per rilevare informazioni su eventuali tentativi di attacco. La capacità di rilevare un'intrusione è un prerequisito alla possibilità di attuare qualsiasi azione di difesa o di ripristino della configurazione corretta. Gli attaccanti invece utilizzano gli strumenti di analisi per recuperare informazioni sui nodi da colpire e stress/hacking tools per colpire il bersaglio. Entrambe le classi di strumenti sono necessari per effettuare una prova in bianco su un architettura reale. STRUMENTI Probing and dell Infrastruttura Stressing Difesa e Monitoraggio Target of Evaluation (ToE) Scanners X X Stress tools X X Hacking tools X X Firewalls X X Sniffers X X X Anti-sniffers X X X Rivelatori di Anti-sniffers X X Protocol Analysers X X X Forensic Tools X X X

16 Rapporto CESI A3/ Pag.16/52 IDS Host based X X IDS Network Based X X Tabella 2: Strumenti dell Infrastruttura di Prova. 2.4 I componenti dell Infrastruttura di Prova L hardware che si deve utilizzare per costituire il core di una Infrastruttura di Prova deve essere tale da consentire di provare e validare gli strumenti, nonché di riprodurre i componenti architetturali più diffusi. Quindi deve comprendere l hardware di supporto per diversi sistemi operativi (Windows, Unix e Linux), per ospitare le applicazioni di interesse (IDS, Firewall, Sniffer, Analizzatori di protocollo, Vulnerability scanner, Forensic tools) spesso attive contemporaneamente. Per ragioni di sicurezza l'infrastruttura di Prova deve essere isolata da eventuali reti aziendali e da Internet Componenti per effettuare una prova in bianco su un ToE La soluzione migliore per valutare le vulnerabilità di un sistema ToE è studiare il sistema stesso. Nel caso in cui ciò non fosse possibile, si rende necessario riprodurre in laboratorio l architettura, utilizzando i componenti reali: IED, hardware e software 3. Sebbene la tipologia dei sistemi da studiare sia alquanto vasta, è possibile definire un set di componenti necessari per le prove iniziali del laboratorio e successivamente da utilizzare per tenere aggiornati gli strumenti disponibili e valutarne di nuovi. Tra questi componenti indispensabili, vi sono le piattaforme più diffuse ed alcuni applicativi. Di seguito in Tabella 3 sono elencati i componenti ritenuti indispensabili per formare il nocciolo di un laboratorio che possa simulare un discreto numero di ToE. Microsoft: NT W2k XP UNIX: Solaris; Linux: - Red Hat, - Suse, - Mandrake, - Debian. FreeBSD. Real Time OS: VxWorks, RMOS 32. Tabella 3: Sistemi Operativi da considerare in una Infrastruttura di Prova Gli strumenti software che devono essere disponibili in un simile laboratorio devono coprire le diverse tecnologie utilizzate sia da coloro che attaccano, sia da coloro che difendono. La seguente Tabella 4 3 che dovranno opportunamente essere reperiti di volta in volta non essendo ragionevole disporre di una vasta gamma di IED.

17 Rapporto CESI A3/ Pag.17/52 elenca per ogni classe di tecnologie gli strumenti che sono ritenuti più rilevanti al momento della stesura di questo rapporto 4 per attaccare e difendere sistemi operativi quali Windows, Unix e Linux. Per quanto riguarda i sistemi operativi Real Time (VxWorks e RMOS32), al momento non sono conosciuti strumenti di attacco, tuttavia ciò non significa che non ne esistano o che non ne verranno creati in futuro. Scanners Stress/Hacking Tools: Firewalls: Sniffers: Anti-Sniffer/ Rilevatori di Anti- Sniffer: Protocol Analyser: Forensic Tools: Intrusion Detection Systems: File Integrity Checker: Internet topology mapper Cheops (ping + traceroute + nmap) su Linux Port scanners nmap su Linux Saint UDP traffic generators: UDP flood Blast Shockwave Buffer Overflow: fatti in casa Hijacking: HUNT Dsniff FW su PC: Chekpoint su Linux/W2K/XP ZoneAlarm su W2K/XP Outpost FW su HW dedicati: Chekpoint (Nokia box) Ethereal su Windows Sniffer Pro LAN PromiScan su Windows AntiSniff Sentinel Sysmon Sniffer Pro LAN Ethereal su Windows Carbonite Forensic Toolkits Vision Host based sulle macchine del ToE: ISS LANguard su Windows Tripwire Internet Scanners ISS Nessus Stealth Scanner SATAN Tabella 4: Strumenti utilizzati per attaccare e per difendere Password Cracker: LC4 su Windows Switch Hacking tools: gli attacchi agli Switch sono specifici per ciascun modello Servono almeno due FW per provare una connessione VPN tra centro di controllo e rete controllata. Network based su PC dedicato multi OS Linux/W2K/XP/freeBSD. Necessitano di HW dedicato: SNORT su Linux ISS 4 Tale elenco dovrebbe essere tenuto costantemente aggiornato per considerare l evoluzione delle vulnerabilità dell ICT.

18 Rapporto CESI A3/ Pag.18/52 3 PROVE DI VULNERABILITÀ DI IPV4 L analisi delle vulnerabilità dei sistemi di automazione dipendenti da una infrastruttura di comunicazione in IPv4 devono riprodurre quanto più possibile le condizioni di reali attacco discusse nel paragrafo 2.1: devono quindi prevedere una collezione di informazioni sul sistema da attaccare, uno scanning per la ricerca delle vulnerabilità, l analisi delle comunicazioni per evidenziare la presenza di contromisure, di eventuali sniffer (parte di un sistema IDS) e di anti-sniffer. A seguito di una analisi di questo tipo viene poi stabilita la strategia d attacco. Di seguito si approfondiscono queste fasi. 3.1 Collezione di informazioni sul Sistema Prima di portare un attacco occorre raccogliere informazioni sui potenziali soggetti target. Per svolgere tale azione in un determinato settore, sono possibili diverse strategie: si può, ad esempio, iniziare con ricerche in Internet con uno dei tanti motori di ricerca, utilizzando una parola chiave comune all insieme di target che operano nel settore desiderato (per esempio il settore elettrico ). Si prosegue con l interrogazione diretta di database on-line quali Whois ( e Arin ( i cui risultati per la parola CESI sono riportati, rispettivamente, in Tabella 5 e Tabella Key Word Search Results: Registered Domains: 33,229,562 On-Hold Domains: 1,917,992 Search Term: cesi Matches Found: > 2001 (limit reached) cesit.com whois record / website 1001cesit.net whois record / website ouncesilverbars.com whois record / website topfinancesites.com whois record / website topreferencesites.com whois record / website topsciencesites.com whois record / website referencesites.com whois record / website computerservicesipswich.com whois record / website officesigns.com whois record / website 9. 1greatdancesite.com whois record / website 10. 1nicesite.com whois record / website 11. 1sourcesite.com whois record / website st choiceservicesinc.com whois record / website st choicesiding.com whois record / website st choicesightseeingtours.com whois record / website 1 st choicesightseeingtours.net whois record / website 1 st choicesightseeingtours.org whois record / website st choicesigns.com whois record / website st choicesingles.com whois record / website st choicesite.com whois record / website

19 Rapporto CESI A3/ Pag.19/52 1 st choicesite.net whois record / website st placesigns.com whois record / website st placesite.com whois record / website stcenturyservicesinc.com whois record / website Tabella 5: Risultati interrogazione WHOIS database Search results for:! CESISI OrgName: CESI (SIC) OrgID: CESISI Address: Via Rubattino, 54 Address: Milano, I City: StateProv: PostalCode: Country: IT Comment: RegDate: Updated: # ARIN WHOIS database, last updated :05 # Enter? for additional hints on searching ARIN's WHOIS database. Tabella 6: Risultati interrogazione ARIN database A questo punto, conoscendo i domini, si può interrogare la rete dei DNS per identificare gli indirizzi IP dei server del nostro target, attraverso l utilizzo di programmi disponibili sui diversi sistemi operativi: per esempio nslookup per Windows e Unix, Dig e Host per Linux. La seguente Tabella 7 mostra il risultato di alcune interrogazioni fatte utilizzando il sistema operativo Linux 5. Un altro comando utile per verificare la presenza dei webserver è il telnet verso la porta 80 rappresentato in Tabella 8. [root@torre root]# dig ; <<>> DiG <<>> ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ; IN A ;; ANSWER SECTION: IN CNAME deneb.cesi.it. deneb.cesi.it IN A ;; Query time: 18 msec ;; SERVER: #53( ) ;; WHEN: Tue Jun 17 16:37: ;; MSG SIZE rcvd: 65 [root@torre root]# dig ; <<>> DiG <<>> ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr aa ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ; IN A ;; ANSWER SECTION: IN CNAME ht1.fr.grpleg.com. 5 Chi attacca utilizza di preferenza un sistema operativo Linux, in quando è molto configurabile, flessibile e difendibile da eventuali contro-attacchi da parte di chi è deputato ad organizzare le barriere difensive dei ToE.

20 Rapporto CESI A3/ Pag.20/52 ht1.fr.grpleg.com IN A ;; AUTHORITY SECTION: fr.grpleg.com IN NS ns.alto.org. fr.grpleg.com IN NS lim.legrand.tm.fr. ;; ADDITIONAL SECTION: ns.alto.org IN A lim.legrand.tm.fr IN A ;; Query time: 246 msec ;; SERVER: #53( ) ;; WHEN: Tue Jun 17 16:30: ;; MSG SIZE rcvd: 167 [root@torre root]# host -l in-addr.arpa domain name pointer torre.cesi.it. [root@torre root]# host -l in-addr.arpa domain name pointer luna.cesi.it. Tabella 7: Comandi per raccogliere informazioni su alcuni domini [root@torre root]# telnet 80 Trying Connected to redirect. ( ). Escape character is '^]'. Tabella 8: Esempi di output di telnet a webserver 3.2 Scanning del Sistema da attaccare Una volta identificato il soggetto da attaccare è importante raccogliere informazioni anche sulla rete da questi posseduta, per esempio costruendone la mappa con un software tipo Cheops che fa una scanning automatico di tutte le macchine in un determinato dominio e produce una rappresentazione grafica. L analisi del suo output testuale da anche informazioni utili sui sistemi operativi installati. La Figura 3 mostra l interfaccia grafica di Cheops, così come nel manuale.