Presentation is loading. Please wait.

Presentation is loading. Please wait.

INTRUSION DETECTION SYSTEM

Similar presentations


Presentation on theme: "INTRUSION DETECTION SYSTEM"— Presentation transcript:

1 INTRUSION DETECTION SYSTEM
Implementation of an all-in-one IDS machine Professor: Massimiliano Rak Student: Pasquale Cirillo Matr.: A18/45

2 SUMMARY Objective Security requirements Intrusion Detection Systems
IDS classification Sensor Soft-Hardering NIDS/IPS SNORT Basic Analysis and Security Engine (BASE): SNORT WEB Interface Honeypot Systems Honeypot classification Nepenthes Amun SURFids Antivirus Installation Penetration Test Penetration Testing Software: Metasploit

3 Objective Assumptions
Implement a Distributed Intrusion Detection System based on the SURFcert IDS Project Install HoneyPot to support the IDS Test the system Assumptions The Distributed Intrusion Detection System (D-IDS) considered is based on a client-server approach where the client is called a sensor. These sensors often contain a honeypot and/or a passive analysis tool like Snort However, we refer to an All-In-One Machine to simplify the installation and the configuration of the tools Obiettivo del progetto è stato quello di implementare un sistema di Intrusion Detection utilizzando un NetworkIDS e diversi Honeypot. In particolare, lo stesso sistema è stato testato attraverso un software di Penetration Testing per valutare la bontà delle informazioni acquisite e l’efficienza degli honeypot installati. L’architettura dell’IDS cui sarà fatto riferimento è distribuita: esso prevede un tunnel server centrale che gestisce le connessioni a vari sensori passivi. Un logging server offre un’interfaccia web per la visualizzazione dei dati e la loro analisi. Nonostante ciò, per semplicità di gestione e dato che lo scopo ultimo non è quello di testare l’architettura in sé ma l’efficienza degli honeypot installati, i tool saranno installati e configurati su di un’unica macchina considerando tutte le possibili problematiche che ne possono derivare in termini di sicurezza.

4 What is Security? Secutity Objectives:
ISO AND ISO DEFINITION Information security is all about protecting and preserving information. It’s all about protecting and preserving the confidentiality, integrity, authenticity, availability, and reliability of information. Secutity Objectives: Ensure the application of the CIA Paradigm: Confidentiality: the information must be accessible only by the authorized users Integrity: the information must be modified only by the authorized users. All others unauthorized access must be blocked Availability: the information must be always available for the authorized users in the time and modes provided by the security policies Ogni violazione di un sistema comporta una perdita di natura economica e di tempo, creando notevoli costi per le aziende e le istituzioni, senza contare le perdite incalcolabili dovute alla sottrazione di documenti importanti o alla compromissione di sistemi critici. In un ambiente di questo tipo, ogni misura atta a prevenire, rilevare o fermare un attacco informatico è vista come una misura necessaria. In questo contesto si pone, quindi, la sicurezza informatica la cui definizione secondo gli standard ISO è: qualsiasi cosa atta a preservare e proteggere la confidenzialità, l’integrità, l’autenticità, la disponibilità e la affidabilità dell’informazione. Per confidenzialità si intende che le informazioni devono essere accessibili solo ed esclusivamente agli utenti autorizzati; per integrità si intende che i dati devono poter essere modificati solo dagli utenti autorizzati; per disponibilità si intende che le informazioni devono essere accessibili agli utenti autorizzati nei tempi e nei metodi previsti dalle policy di sicurezza; per autenticità si intende che deve essere garantita per ogni informazione la certezza che essa appartenga a chi dice di averla generata.

5 Security Area Attack Definition
BRUCE SCHENEIER DEFINITION (‘Secrets and Lies’) Prevention: block any threat or attack Detection: eventually the prevention fails, with the detection it seeks to control attacks in progress Reaction: after detected an attack, it responds to attackers Attack Definition An attack is any attempt to destroy, expose, alter, disable, steal or gain unauthorized access to or make unauthorized use of any tangible or intangible thing that has value to an organization Passive attack: the attacker attempts to learn or make use of information from the system but does not affect system resources Active attack: the attacker attempts to alter system resources or affect their operation Alla sicurezza informatica possono essere associati più comportamenti o può essere inserita in ambito che comprendono: La prevenzione atta a garantire che qualsiasi minaccia o attacco venga bloccato La rilevazione atta a garantire che un attacco in atto venga rilevato nel caso in cui la prevenzione fallisce La reazione che si pone come conseguenza della rilevazione ed è atta a garantire che, rilevato un attacco, il sistema venga modificato in modo da bloccare l’attacco in atto. Un attacco informatico, invece, è definito come qualunque tentativo abusivo di sovvertire o aggirare le policy di sicurezza di un sistema al fine di violarlo, comprometterlo o anche solo accedervi senza esserne autorizzati. Gli attacchi possono essere passivi e attivi: i primi mirano ad intercettare o leggere i dati senza modificarli; i secondi mirano ad alterare o distruggere i dati o alterare lo stato stesso del sistema. Gli attacker cercano di sfruttare maliziosamente eventuali bachi o vulnerabilità presenti nel sistema.

6 IDS Definition IDS Components
An intrusion detection system (IDS) is a device or software application that monitors network and/or system activities for malicious activities or policy violations and produces reports to a Management Station IDS Components Sensors: one or more sensors are typically used to receive information from the network or from controlled hosts Console: is used to monitor the status of network and hosts Engine: used to analyze the data collected by the sensors, provides to detect possible intrusions Database: the analysis engine is based on a database that stores the rules used to identify security breaches Riprendendo la suddivisione della sicurezza di Bruce Schneier, possiamo certamente dire che prima o poi i meccanismi di prevenzione come i firewall, il cui scopo è quello di bloccare qualsiasi accesso non autorizzato e ogni pacchetto malformato o sospetto, prima o poi falliscono. Quando questi falliscono bisogna rilevare le intrusioni: è qui che entrano in gioco gli IDS. Un IDS è uno strumento hardware o software che ha lo scopo di monitorare le attività che vengono effettuate in una rete o in un computer al fine di rilevare eventuali eventi dannosi, sospetti o anomali per poter rilevare intrusioni o accessi non autorizzati. Infatti, una delle principali caratteristiche di un IDS è rimanere passivamente in ascolto del traffico, analizzarlo costantemente alla ricerca di una anomalia o di una corrispondenza con delle regole che se presente farà scattare un allarme. Generalmente, un IDS è composto da: Sensori: vengono solitamente utilizzati uno o più sensori per ricevere le informazioni dalla rete o dagli host controllati Console: viene utilizzata per monitorare lo stato della rete e dei computer Motore: impiegato per analizzare i dati prelevati dai sensori, provvede ad individuare possibili intrusioni Database: il motore di analisi si basa su un database in cui sono memorizzate le regole impiegate per identificare violazioni della sicurezza

7 CIDF The Common Intrusion Detection Framework (CIDF) is an effort to develop protocols and application programming interfaces so that intrusion detection research projects can share information and resources and so that intrusion detection components can be reused in other systems Some of the ideas involved in CIDF have encouraged the creation of an Internet Engineering Task Force (IETF) working group, named the Intrusion Detection Working Group (IDWG) CIDF Components Visto il continuo sviluppo di nuovi e più sofisticati IDS, è avanzato il tentativo di standardizzare l’architettura di tali sistemi. Fu Teresa Lunt, allora dipendente dell’Information Technology alla DARPA, a definire CIDF (Common Intrusion Detection Framework). Alcune soluzioni proposte nel progetto, hanno incoraggiato la creazione di un Internet Engineering Task Force working group chiamato Instrusion Detection Working Group. In particolare, il framework prevede che gli IDS siano costituiti da quattro componenti indipendenti che comunicano tra loro mediante message passing. Tali componenti si scambiano le informazioni come ‘oggetti di intrusion detection generalizzati’ definiti dallo standard come gidos. CIDF adopts a view of Intrusion Detection Systems in which they consist of discrete components which communicate via message passing The four kinds of components exchange data in the form of ‘generalized intrusion detection objects (gidos)’ which are represented via a standard common format

8 CIDF Components (Continue)
Event generators (‘E-boxes’): the role of an event generator is to obtain events from the larger computational environment outside the intrusion detection system and provide them in the CIDF gido format to the rest of the system Event analyzers (‘A-boxes’): they receive gidos from other components, analyze them, and return new gidos (which presumably represent some kind of synthesis or summary of the input events) Event databases (‘D-boxes’): these components simply exist to give persistence to CIDF gidos Response units (‘R-boxes’): they consume gidos which direct them to carry out some kind of action on behalf of other CIDF components, and they carry out this action. This includes such things as killing processes, resetting connections, altering file permissions, etc I quattro componeti sono: Event generators: il loro ruolo è quello di ottenere informazioni/eventi dall’ambiete circostante all’IDS quali riguardanti traffico di rete, record di audit degli hosts o delle applicazioni. Tali informazioni vengono fornite secondo il formato gido al resto del sistema Event Analyzers: ricevono i gidos dagli altri componenti e li analizzano, restituendo messaggi più sintetici riguardanti tutti gli eventi ricevuti Event Databases: immagazzinano le informazioni per analisi a lungo tempo se necessario Response Units: consumano i gidos che sono diretti a loro e attuano delle azioni di risposta. Queste includono uccisione di processi, reset di connessioni, modifica di permessi sui file

9 IDS Classification Sources NIDS – Network-Based IDS
HIDS – Host-Based IDS Application-Based IDS Hybrid IDS Detection Mechanism Misuse Detection Anomaly Detection Protocol Analysis DIDS – Distributed IDS IPS – Intrusion Prevention System Gli IDS vengono classificati sia in base alle risorse che devono monitorare sia in base al tipo di controllo che attuano. Distinguiamo tra i primi i network-based IDS, gli host-based IDS e gli application-based IDS; tra i secondi i sistemi basati sulle Signatures e Pattern Matching, i sistemi di rilevamento euristico o anomaly-based e i sistemi basati sulla protocol analysis. Categoria a parte è costituita dagli IDS distribuiti e da quelli che sono considerati l’evoluzione degli IDS, gli IPS.

10 NIDS (1/2) Objective Monitor a network segment Functioning
Change the operating mode of the network interface by placing it in promiscuous mode in such a way as to be listening on every packet on the network segmet Analyze all network traffic looking for a match with known attack signatures, or looking for statistically anomalous traffic Obiettivo dei NIDS è quello di monitorare un segmento di rete. Per far ciò, tale IDS modifica la modalità operativa dell’interfaccia di rete ponendola in modalità promiscua in maniera tale da essere in ascolto su ogni pacchetto che transita. Ciò significa che la scheda di rete passa ai livelli superiori non solo i pacchetti diretti al MAC della scheda stessa e quindi all’IDS, ma tutti i pacchetti che transitano su quel segmento di rete. Si comporta come un vero e proprio sniffer. Lo scopo del network-IDS è quello di analizzare tutto il traffico di rete alla ricerca di un match con signature di attacchi noti, oppure alla ricerca di traffico statisticamente anomalo. I pacchetti vengono passati ad un detection engine che tramite delle policy e regole definite decide se si è in presenza di un presunto attacco.

11 NIDS (2/2) Detect Buffer overflows, format string attacks, transmission of suspicious files Port Scanning, SYN attacks or based on fragmentation of packets Spoofed IP addresses Disadvantages Not be able to block the flow of packets in the presence of an attack Inability to deal with encrypted traffic Powerful HW to handle high volume of traffic Problems with fragmented packets Detect intrusions but do not know their results Require considerable resources to keep logs Frequent updating of signatures La tipologia di attacchi che un NIDS riesce a rilevare sono: Buffer overflow, format string attack, trasmissione di file sospetti Port Scanning, attacchi SYN o basati su frammentazione di pacchetti Indirizzi IP spoofed Uno degli svantaggi del network-IDS è quello di non poter bloccare il flusso di pacchetti in presenza di un attacco. Svantaggi: Impossibilità di gestire il traffico cifrato HW potente per gestire mole di traffico elevata Problemi con pacchetti frammentati Rilevano tentativi di intrusione ma non ne conoscono l’esito Richiedono notevole risorse per poter conservare i log Frequente aggiornamento delle signatures

12 HIDS Objective Monitor and analyze a single Host Functioning
Analysis of system logs, audit logs, security logs, system call and the changes undergone by the file system For each element are stored its attributes and performed a checksum calculation with hash functions. The data are compared with the checksum to detect an attack Advantages Understand if the attack was successful or not Analyze cypher messages Disadvantages Subject of attacks Un host-based IDS è specializzato nell’analisi e monitoraggio dei computer. Consiste principalmente in un componente detto agente che analizza la macchina alla ricerca di un’intrusione rilevata attraverso l’analisi dei log del sistema, l’audit log, i security log, le system call e le modifiche subite dal file system. Per far ciò, subito dopo l’installazione, c’è una raccolta di dati che riguardano gli elementi da monitorare: per ogni elemento vengono memorizzati i suoi attributi e viene effettuato un calcolo del checksum con funzioni di HASH. Su questi dati si basano le comparazioni degli oggetti per vedere se sono stati compromessi da un attacco. Il vantaggio principale è che essendo installati sulla macchine che si vuole proteggere, a differenza dei NIDS, si riesce a capire se l’attacco è riuscito o no. Questo è un vantaggio ma anche uno svantaggio in quanto l’attaccante, se è stato in grado di introdursi nel sistema può disattivare l’IDS o modificarne i file, il database oppure terminare il processo. Tali problemi vengono spesso risolti con ulteriori tecniche per rilevare violazioni sul proprio database.

13 Application IDS Hybrid IDS Objective
An application IDS will work solely with the application itself They tend to be tailored to a specific product Functioning An IDS will report when anomalous activity is detected most usually using logs generated by the application Hybrid IDS Spesso considerati come un sotto-categoria degli HIDS, gli application IDS hanno lo scopo di proteggere esclusivamente un’applicazione. Essi tendono ad essere su misura per un prodotto specifico, ad esempio, Microsoft Internet Information Server (IIS) all'interno di gruppi di applicazioni che forniscono servizi visibili esternamente come server web, database e server di posta. Un IDS segnalerà un'attività anomala analizzando i log generati dall'applicazione. Gli Hybrid IDS sono anche conosciuti con il nome di NNIDS. Essenzialmente sono network-based ma installati su di un solo host. Proprio per questo riescono a monitorare solo il traffico di rete che è diretto a loro stessi. Il vantaggio rispetto ad un NIDS è che riescono a rilevare il traffico crittografato prima che possa causare un’intrusione nel sistema. Known as NNIDS (Network Node IDS) an Hybrid IDS is network-based but installed on a single Host Analyze the network traffic that is directed to themselves Advantage: detect encrypted traffic before it can cause an intrusion into the system

14 Misuse Detection To detect an intrusion, uses a pattern matching algorithms, which are the true engine of the IDS Signatures database constantly updated Control all incoming packets looking for a match with the signatures present in the database Stateful Pattern Matching Analysis is used to detect an attack performed with a string payload divided into multiple packets Advantages Low number of false alarms Disadvantages High computational load New signatures are not recognized Frequent updates of the database Gli IDS basati sulle Signature e Pattern Matching controllano tutti i pacchetti in ingresso alla ricerca di un match con le signature presenti in un apposito database per verificare che non abbiano un payload già conosciuto e ritenuto anomalo. Per rilevare un’intrusione, quindi, fanno uso di particolari algoritmi di Pattern Matching che sono il vero e proprio motore dell’IDS: se la stringa rilevata dall’IDS e una di quelle contenute nel database delle signature coincidono, l’algoritmo riconosce l’attacco e applicherà delle regole predefinite informando, tramite una console, l’amministratore di quanto avvenuto. Questo lavoro richiede un grande carico computazionale poiché richiede che tutti i pacchetti vengano confrontati con tutte le signature presenti nel database. Le firme sono composte da sei campi: il protocollo, l’IP sorgente, la porta sorgente, l’IP destinatario, la porta destinataria, il payload con exploit. Se durante l’analisi tutti i campi coincidono con una signature nota verrà generato l’allarme. Ciò significa che se la stringa del payload venisse divisa in più pacchetti, l’attacco non verrebbe rilevato. Per risolvere tale problema, si è introdotta una Stateful Pattern Matching Analysis dove i pacchetti non vengono analizzati in maniera indipendenti ma nell’ambito della connessione. I difetti più grandi di questo tipo di sistemi è che richiedono un aggiornamento continuo dei database e che se gli attacchi presentano firme simile ma non perfettamente uguali a quelle note, l’attacco non viene rilevato.

15 Anomaly Detection Search abnormal behavior which differs from a system model which characterizes the correct operations Require a learning phase: Self learning: the model is learned from examples Programmed learning: require in-depth mathematic knowledge to create models Advantages Very flexible technique since Allow to detect unknown attacks Disadvantages High number of false alarms Questa tipologia di IDS è nata per sopperire alle limitazioni introdotte dai sistemi basati su pattern matching. Il rilevamento delle intrusioni euristico ricerca un comportamento anomalo che si discosta da un modello del sistema che ne caratterizza il corretto funzionamento. In pratica, l’IDS andrà a rilevare qualsiasi comportamento che devia dal modello e genererà l’allarme. Questa tecnica è molto flessibile in quanto permette di rilevare anche attacchi non noti. Gli IDS anomaly-based hanno bisogno di una fase di apprendimento. Esistono principalmente due tipi di tecniche: Self learning: il modello viene appreso da degli esempi Programmati: richiedono conoscenze matematiche approfondite per creare i modelli Gli svantaggi principali di questi sistemi è che generano molti falsi allarmi data anche la difficoltà della fase di apprendimento.

16 Protocol Analysis Based on the control of the technical specifications of the protocols defined in the RFC Generate an alarm for each violation in the standard protocol: i.e.: SYN-FLOOD Attack Advantages Decrease the number of false alarms Disadvantages Management of ambiguity in RFC Tali sistemi si basano sui controlli delle specifiche tecniche dei protocolli: per ogni violazione viene generato un allarme. Tuttavia, possono nascere dei problemi su ambiguità presenti negli RFC che possono portare ad implementazioni differenti dello stesso protocollo. Tale aspetto complica quindi il lavoro dei sistemi basati sulla Protocol Analysis.

17 DIDS Constituted by sensors and central monitor system
Sensor generates logs that track the attacks and sends they in the central system The central system collects the data and create a global repository Communication between the sensors and central system provided with encrypted VPN Disadvantages Sensor heterogeneity requires a standard communication interface Inherits all the IDS sensors disadvantage Un IDS distribuito è un’architettura composta da sensori che possono essere a loro volta dei network-based IDS o degli host-based IDS che riportano le informazioni ad un sistema centrale di coordinamento e analisi. Ogni sensore genera dei log che tengono traccia degli attaccati subiti che vengono raccolti nel sistema centrale come un repository globale. Vista l’eterogeneità dei sensori non tutti possono essere gestiti allo stesso modo dal sistema centrale utilizzando un’unica interfaccia. La comunicazione tra i sensori e il sistema centrale viene effettuata su canali sicuri quali VPN crittografate.

18 IPS Evolution of IDS To achieve the ability to prevention, in addition to the normal capacity of an IDS, the IPS implement instruments to block malicious traffic in real time Capabilities Block the intrusion through actions such as termination of a network connection Change the security policies when an attack is detected Gli Intrusion Prevention System sono conosciuti anche come Intrusion Detection and Prevention System e sono stati sviluppati in un’ottica di evoluzione degli IDS. Per realizzare la capacità di prevention, oltre alle normali capacità di un IDS, gli IPS implementano strumenti per bloccare il traffico malevolo in tempo reale. Le loro funzionalità principali sono: Bloccare l’intrusione tramite azioni quali la terminazione di una connessione di rete Modificare le policy di sicurezza al rilevamento della minaccia

19 System Architecture All-in-one machine: IP: Attacker: IP: L’architettura a cui faremo riferimento è costituita da due macchine installate su VM: sulla all-in-one machine è installato e configurato l’IDS; in particolare sarà effettuato un sofr-hardering per la messa in sicurezza della macchina, sarà installato il NIDS SNORT e i due Honeypot Nepenthes e Amun che saranno in funzione in maniera alternata. Sulla seconda macchina, sarà invece installato il Penetration Tool Metasploit per simulare eventuali attacchi e iniezione di exploit. All-in-one machine is constituded by a NIDS and two Honeypots that alternatively work. BASE and SurfnetIDS have been installed to provide a web interface to analyze the IDS logs On the attacker machine Metasploit Penetration Software has been used to perform a penetration test

20 Sensor Soft-Hardering (1/2)
Set permission 500 on wget – curl – GET – links – ftp – telnet whereis wget curl GET links lynx ftp tftp telnet wget: /usr/bin/wget /usr/bin/X11/wget /usr/share/man/man1/wget.1.gz curl: /usr/bin/curl /usr/bin/X11/curl /usr/share/man/man1/curl.1.gz GET: /usr/bin/GET /usr/bin/X11/GET /usr/share/man/man1/GET.1p.gz links: /usr/bin/links /usr/bin/X11/links /usr/share/man/man1/links.1.gz lynx: ftp: /usr/bin/ftp /usr/bin/X11/ftp /usr/share/man/man1/ftp.1.gz tftp: telnet: /usr/bin/telnet /usr/bin/telnet.netkit /usr/bin/X11/telnet /usr/bin/X11/telnet.netkit /usr/share/man/man1/telnet.1.gz chmod 500 wget curl GET links ftp telnet.netkit Install RootKit Hunter and start scan Ref.: Install Fail2Ban script: apt-get install fail2ban Nell’ottica di implementare un IDS a cui verranno associati successivamente degli honeypot su un’unica macchina con tutti gli svantaggi che di seguito saranno illustrati, la prima cosa che è stata fatta è quella di mettere in sicurezza la macchina stessa limitando il numero di servizi a cui l’attaccante potrebbe accedere. Questo è stato fatto principalmente rendendo eseguibili solo da terminale servizi come ‘wget, curl, get, ftp, telnet…’. Passo successivo è stato quello di installare RootKit Hunter, un rootkit detector che permette di rilevare se un attaccante ha compromesso il sistema. Una volta installato, è utile lanciare una prima scansione per permettere al software di generare gli hash sui file del sistema e salvare tali informazioni nel proprio database, informazioni che saranno utilizzate poi come confronto. L’unico accesso autenticato che bisogna necessariamente proteggere è il demone SSH che lavora sulla porta 22. Per far ciò possiamo installare uno script, fail2ban, che permetterà di contrastare eventuali attacchi bruteforce e che bannerà l’IP dell’attaccante per un tempo stabilito.

21 Sensor Soft-Hardering (2/2)
Configure /etc/fail2ban/fail2ban.conf: Set log file as path /var/log/fail2ban.log and /etc/fail2ban/jail.conf: bantime = 3600 [ssh] enabled = true port = ssh filter = sshd logpath = /var/log/auth.log maxretry = 3 Tali configurazione possono essere settate nel file /etc/fail2ban/jail.conf. In particolare, lo script, analizzando il file di log /var/log/auth.log, quando rileverà 3 tentativi di accesso falliti da un indirizzo IP lo bannerà per 3600 sec (1 ora) utilizzando il firewall iptables/ipfw/shorewall.

22 SNORT (1/3) Snort® is an open source network intrusion prevention and detection system (IDS/IPS) Combine the benefits of signature, protocol, and anomaly-based inspection Install Snort with mysql support apt-get install snort-mysql Configure /etc/snort/snort.conf # Setup the network addresses you are protecting ipvar HOME_NET /32 ipvar EXTERNAL_NET !$HOME_NET # List of the ports you run web servers on portvar HTTP_PORTS 80 # List of ports you want to look for SHELLCODE on portvar SHELLCODE_PORTS !80 # Path to your rules files var RULE_PATH /etc/snort/rules # Target-based IP defragmentation preprocessor frag3_global: max_frags 65536 SNORT è un NIDS/IPS open source capace di eseguire il logging dei pacchetti e l'analisi del traffico in tempo reale su reti IP. SNORT esegue l'analisi di protocollo, la ricerca/matching di contenuti all'interno dello stream di dati raccolto, permette di individuare una grande varietà di attacchi basandosi su l'uso delle firme e del rilevamento di anomalie di protocollo. SNORT agisce anche da IPS (con la dovuta estensione) permettendo quindi di interfacciarsi con il firewall di sistema per bloccare gli host che stanno attaccando il sistema tentando quindi di prevenirne la violazione. L’installazione avviene tramite le APT. Per la sua configurazione è importante settare l’indirizzo della nostra rete, i porti utilizzati per il webserver, le lista dei porti dove analizzare gli Shellcode, il path che contiene le regole,

23 SNORT (2/3) ... # Detect anomalies
preprocessor frag3_engine: policy linux detect_anomalies preprocessor stream5_global: max_tcp 8192, track_tcp yes, track_udp no preprocessor stream5_tcp: policy linux, use_static_footprint_sizes # HTTP normalization and anomaly detection preprocessor http_inspect: global iis_unicode_map unicode.map 1252 preprocessor http_inspect_server: server default profile all ports { } oversize_dir_length 500 # FTP/Telnet normalization and anomaly detection preprocessor ftp_telnet: global encrypted_traffic yes inspection_type stateful preprocessor ftp_telnet_protocol: telnet normalize ayt_attack_thresh 200 # Portscan detection preprocessor sfportscan: proto { all } scan_type { all } memcap { } sense_level { high } logfile { pscan } # Database parameters output database: log, mysql, user=snort password=XXX dbname=snort host=localhost # Site specific rules include $RULE_PATH/local.rules include $RULE_PATH/badtraffic.rules include $RULE_PATH/exploit.rules E alcuni preprocessor per abilitare la ricerca di anomalie, per decodificare il traffico telnet, ftp, per attivare il rilevamento dei portscan, il setting del db e l’attivazione delle regole.

24 SNORT (3/3) Create Snort Database Download and import Snort DB scheme
mysql -u root mysql>set password for create database snort; grant insert,select on root.* to set password for grant create,delete,insert,select,update on snort.* to grant create,delete,insert,select,update on snort.* to snort; exit Download and import Snort DB scheme mysql -u root -d snort -p < create_mysql Create init script in /etc/init.d #!/bin/sh -e snort -c /etc/snort/snort.conf -D -u snort -g snort -y Start SNORT snort -c /etc/snort/snort.conf -D -u snort -g snort -y Configurato Snort, bisogna creare il database su cui memorizzare le informazioni, opzionalmente creare un semplice init file e lanciarlo.

25 BASE (1/2) BASE (Basic Analysis and Security Engine) is a web interface to perform analysis of intrusions that snort has detected on the network Download BASE and install it in the webserver webroot mkdir /var/www/base mv * /var/www/base Install dependencies apt-get install libphp-adodb php5-gd php-pear pear install Image_Color pear install Image_Canvasalpha pear install Image_Graphalpha Download and Install AdoDB (database abstraction library for PHP) Ref.: Per una gestione ottimale dell'IDS, in questo caso di SNORT, è conveniente adoperare una console/interfaccia che ci permetta di avere accesso ai log in maniera strutturata. Possiamo utilizzare come interfaccia di gestione per SNORT il sistema Basic Analysis and Security Engine (BASE) che ha la semplicità di essere gestibile via web server, di essere open source e di essere facilmente adattabile/modificabile. Per installarlo, basta scaricare il pacchetto dal sito ufficiale del progetto, decomprimerlo nella webroot del webserver e installare alcune dipendenze tra le quali AdoDB. Le uniche configurazioni da settare sono il path di adodb e i dati di accesso al db snort.

26 BASE (2/2) Configure base_config.php
mv base_conf.php.dist base_config.php $BASE_urlpath = "/base"; $DBlib_path = "/var/www/adodb/ "; $DBtype = "mysql"; $alert_dbname = "snort"; $alert_host = "localhost"; $alert_port = ""; $alert_user = "snort"; $alert_password = "passwd_snortdb"; Add dynamic extensions in /etc/php5/apache2/php.ini extension=mysql.so extension=gd.so Restart Apache2 and Start BASE Per una gestione ottimale dell'IDS, in questo caso di SNORT, è conveniente adoperare una console/interfaccia che ci permetta di avere accesso ai log in maniera strutturata. Possiamo utilizzare come interfaccia di gestione per SNORT il sistema Basic Analysis and Security Engine (BASE) che ha la semplicità di essere gestibile via web server, di essere open source e di essere facilmente adattabile/modificabile. Per installarlo, basta scaricare il pacchetto dal sito ufficiale del progetto, decomprimerlo nella webroot del webserver e installare alcune dipendenze tra le quali AdoDB. Le uniche configurazioni da settare sono il path di adodb e i dati di accesso al db snort. Può essere necessario inserire delle estensioni al file di configurazione di apache.

27 Honeypot: ‘barattolo di miele’
What is an Honeypot? HW or SW that works as bait or trap for potential hackers or malware Provide services that are open and visible from internet and easy to break Identify and analyze the attacks, intrusion techniques, the flaws of the system and the malicious code Advantages Quality and quantity of the information that it collects Low number of false positives compared to IDS Disadvantages They may themselves be compromised and therefore can bring risks to the infrastructure that hosts them Nel caso in cui sia il sistema di prevenzione sia il sistema di rilevazione fallissero non ci resta che giocare un’ultima carta. Si tratta dei sistemi Honeypot, letteralmente ‘barattolo di miele’ o per rendere meglio l’idea una ‘stanza del tesoro’. L’idea del loro funzionamento è attrarre gli attaccanti per poterli intrappolare e osservare. Un Honeypot, più formalmente, è un sistema Hw o Sw che funziona come esca o trappola per potenziali hacker o malware; il suo scopo è quello di individuare e analizzare gli attacchi, le tecniche di intrusione, le falle del sistema e il codice malevolo che si vuole far scaricare alla macchina compromessa in modo tale da utilizzare tali informazioni per migliorare la sicurezza. Un honeypot, quindi, cerca di ingannare l’attaccante simulando di essere un server che fa parte della rete e che sembra contenere informazioni preziose. Allo stesso tempo, mette a disposizione dei servizi aperti e visibili che risultano facilmente violabili. Il loro pregio è la quantità di informazione che riesce a collezionare, nonché il numero relativamente basso di falsi positivi rispetto agli IDS poiché ogni pacchetto che entra è ritenuto sospetto. Lo svantaggio principale è che essendo gli honeypot esposti ad attacchi possono a loro volta essere compromessi e quindi possono portare rischi all’infrastruttura che li ospita.

28 Honeypot Classification
Scope Production Honeypots: used to protect organizations in real production operating environments. They are implemented parallel to data networks or IT Infrastructures and are subject to constant attacks 24/7 Research Honeypots: are not implemented with the objective of protecting networks. They represent educational resources of demonstrative and research nature whose objective is centered towards studying all sorts of attack patterns and threats Interaction Level Low Interaction Honeypots: work exclusively emulating operating systems and services. The attacker’s activities are limited to the Honeypot’s level and quality of emulation High Interaction Honeypots: constitute a complex solution because they involve the utilization of operating systems and real applications implemented in real hardware, without using emulation software Gli honeypot vengono classificati in base al loro scopo e secondariamente in base al livello di interazione con il sistema su cui vengono installati. Vengono, quindi, suddivisi in Honeypot di Produzione e Honeypot di Ricerca per quanto riguardo lo scopo; in Honeypot di basso livello e alto livello per quanto riguarda l’interazione. Gli Honeypot di produzione permettono di rilevare gli attacchi o le intrusioni destinati ai sistemi di produzione. Quando i firewall e gli IDS non riescono a bloccare o rilevare l’attacco, entra in gioco l’honeypot che viene posto all’interno della DMZ oppure vicino ai server di produzione in modo tale da risultare una preda appetibile per l’attaccante. Gli honeypot di produzione aggiungono poco valore alla prevenzione poiché non prevengono le intrusioni né le dissuadono. Il loro scopo principale è quello di subire attacchi. Danno, invece, valore al rilevamento delle minacce e alla reazione in quanto essendo un sistema diverso da quello di produzione, sarà più semplice analizzarne i log poiché puliti e evitano lo spegnimento dei server di produzione stessi. Gli Honeypot di ricerca, invece, vengono impiegati ai soli fini di raccolta delle informazioni. Vengono inseriti in contesti universitari o società con obiettivi di ricerca che hanno come scopo quello di studiare nuove tipologie di attacchi per generare gli adeguati strumenti di prevenzione. Per quanto riguarda la seconda classificazione, ci si riferisce alle risorse e ai permessi che vengono concessi all’honeypot: maggiori sono le risorse e i permessi e maggiore sarà la capacità dell’honeypot di catturare informazioni. Ovviamente, all’aumentare di questi privilegi aumenterà anche la probabilità che il sistema venga completamente compromesso. Gli honeypot a bassa interazione offrono essenzialmente servizi emulati, non esiste alcun servizio reale. La quantità di informazione che viene raccolta è bassa. Gli honeypot ad alta interazione offrono, invece, servizi reali: vengono utilizzate macchine reali con applicazioni reali. L’attaccante ha accesso a tutto il sistema operativo e ha una considerevole quantità di risorse a sua disposizione. Il rischio di violazione del sistema è molto alto, ma altrettanto alta è la qualità delle informazioni raccolte.

29 Considerations on the Honeypots
Advantages Clean logs Minimal resources when offers emulated services The true value of a honeypot for a company is when it can be demonstrated that the security systems adopted have not been enough to keep out the bad guys Disadvantages Cannot detect events that do not see them as recipients It is a system designed to be attached, if not well configured and isolated can be a point of access for the attacker Disabling: the attacker disables the honeypot and / or changes the log files Violation: the attacker is able to use the honeypot for making illegal activities Un honeypot non risolve i problemi di sicurezza di un’azienda. Ciò nonostante, i suoi vantaggi risiedono nel fatto che i log generati sono puliti, nel senso che non essendo un sistema di produzione traccia esclusivamente gli attacchi ad esso indirizzato; possono tracciare e rilevare attacchi nuovi; spesso hanno bisogno di requisiti minimale poiché offrono servizi emulati. Il vero valore di un Honeypot per un’azienda è quando esso riesce a dimostrare che i sistemi di sicurezza adottati non sono stati sufficienti a tenere alla larga i malintenzionati. Uno dei grandi svantaggi degli honeypot è che non riescono a registrare gli eventi che non vedono come destinatari l’honeypot stesso. Un altro svantaggio risiede nella sua natura: essendo un sistema pensato per essere attaccato, se non bene configurato e isolato può risultare un punto di accesso per l’attaccante che vuol compromettere il sistema. Oltretutto, se l’honeypot venisse rilevata dall’attaccante, potrebbe essere ignorata, o ancor più grave, l’attaccante potrebbe fornire falsi dati e rendere inattendibili le informazioni raccolte in maniera da disorientare l’amministratore. Due problemi sono da considerare: il Disabling e la Violation. Con la prima si intende l’azione secondo cui l’attaccante, introdottosi nel sistema, disabilita l’honeypot e/o ne modifica i log rendendone inutilizzabili i dati. Con il secondo si intende l’azione secondo cui l’attaccante riesce ad utilizzare l’honeypot per attività illecite facendone ricadere la colpa sull’amministratore.

30 Nepenthes (1/4) Nepenthes is a low-interacion Honeypot and a versatile tool to collect malware It acts passively by emulating known vulnerabilities and downloading malware trying to exploit these vulnerabilities Install Nepenthes apt-get install nepenthes Configure /etc/nepenthes/nepenthes.conf # need to add the the sqlhandler and log-surfnet lines // SQL handler "sqlhandlerpostgres.so", "", "" // logging "logdownload.so", "log-download.conf", "" // "logirc.so", "log-irc.conf", "" // needs configuration "logsurfnet.so", "log-surfnet.conf", "" // needs configuration Nepenthes è un honeypot a bassa interazione che emula vulnerabilità note per collezionare informazioni circa i potenziali attacchi. Nepenthes è designato ad emulare le vulnerabilità che i worm utilizzano per diffondersi, e catturare questi worm. Esistono diversi moduli per emulare vulnerabilità, scaricare i file, sottomettere i file scaricati, gestire gli shellcode degli exploit, ecc. Per i sistemi Debian/Ubuntu Nepenthes è presente già nei repository, per cui l’installazione può essere lanciata semplicemente tramite un solo comando senza la necessità di dover compilare interamente il tool. La configurazione consiste nell’attivare gli handler da utilizzare. I download handler indicano i vari protocolli utilizzati per permettere al worm/attaccante di scaricare il binario sul Sensore. I submit handler indicano i vari metodi di sottomissione del binario. I moduli vulnerabilità invece indicano le vulnerabilità che andremo a simulare con il nostro honeypot.

31 Nepenthes (2/4) Configure /etc/nepenthes/vulniis.conf
# Active preferred vulnerability modules "vulnbagle.so", "vulnbagle.conf", "" "vulndameware.so", "vulndameware.conf", "" "vulndcom.so", "vulndcom.conf", "" "vulnftpd.so", "vulnftpd.conf", "" "vulniis.so", "vulniis.conf", "" Configure /etc/nepenthes/vulniis.conf vulniis { ports ("443","8080"); accepttimeout "30"; }; Modify /etc/nepenthes/log-surfnet.conf server " "; // must be ip user "nepenthes"; pass "password"; db "idsserver"; Setteremo la porta del web server fittizio alla 8080 invece della 80 poiché sulla 80 abbiamo attivo il vero web server Apache. Assumendo, infine, di voler utilizzare surfids come logserver, inseriamo i dati per l’accesso al database nel file di configurazione log-surfnet.conf.

32 Nepenthes (3/4) Create init script in /etc/init.d Start Nepenthes
#!/bin/sh check=`ps -ef | grep -v grep | grep -v init.d | grep -v postgres | grep nepenthes | wc -l` echo "CHECK: $check" if [ $check != 0 ]; then neppid=`ps -ef | grep -v grep | grep -v init.d | grep -v postgres | grep nepenthes | grep none | awk '{print $2}' | head -n1` echo "PID: $neppid" `kill -9 $neppid` fi /bin/nepenthes -u nepenthes -g nepenthes -l none -R -D --chroot=/etc/nepenthes Start Nepenthes nepenthes -u nepenthes -g nepenthes -l none -R -D --chroot=/ etc/nepenthes Per l’avvio automatico possiamo creare come fatto con SNORT un init script. Non ci resta che avviare Nepenthes.

33 Nepenthes (4/4) Attacker starts nmap
nmap -sS -PN -v Starting Nmap 5.21 ( ) at :23 CET Initiating ARP Ping Scan at 23:23 Scanning [1 port] Completed ARP Ping Scan at 23:23, 0.04s elapsed (1 total hosts) Initiating Parallel DNS resolution of 1 host. at 23:23 Completed Parallel DNS resolution of 1 host. at 23:23, 0.04s elapsed Initiating SYN Stealth Scan at 23:23 Scanning [1000 ports] Discovered open port 1025/tcp on Discovered open port 135/tcp on Discovered open port 445/tcp on Discovered open port 143/tcp on Discovered open port 139/tcp on Discovered open port 80/tcp on Discovered open port 110/tcp on Discovered open port 443/tcp on Discovered open port 8080/tcp on Discovered open port 993/tcp on Discovered open port 2105/tcp on Discovered open port 10000/tcp on Discovered open port 465/tcp on Discovered open port 3372/tcp on Discovered open port 2107/tcp on Completed SYN Stealth Scan at 23:23, 1.17s elapsed (1000 total ports) Nmap scan report for Host is up ( s latency). Not shown: 976 closed ports PORT STATE SERVICE 21/tcp open ftp 22/tcp open ssh 25/tcp open smtp 42/tcp open nameserver 80/tcp open http 110/tcp open pop3 135/tcp open msrpc 139/tcp open netbios-ssn 143/tcp open imap 443/tcp open https 445/tcp open microsoft-ds 465/tcp open smtps 993/tcp open imaps 995/tcp open pop3s 1023/tcp open netvenuechat 1025/tcp open NFS-or-IIS 2103/tcp open zephyr-clt Per controllare che tutto funzioni, possiamo avviare il tool nmap che ci restituirà la lista dei servizi emulati da Nepenthes con i relativi porti. Una miriade di porte aperte ed ipotetici servizi disponibili, che già dopo pochi minuti di attività dell'honeypot attirano diversi attacchi automatizzati.

34 Amun (1/4) Amun is a low-interaction Python Honeypot
It has a modular implementation as Nepenthes: Amun Kernel Request Handler Vulnerability Modules Shellcode Analyzer Download Modules Logging Modules Install Amun # need to install some more python modules (PostgreSQL adapter for the Python programming # language) apt-get install python-psycopg2 # download the package from the subversion repository of Amun cd /opt/ svn co https://amunhoney.svn.sourceforge.net/svnroot/amunhoney amunhoney cd /opt/amunhoney Amun è un honeypot a basso livello di interazione programmato in linguaggio Python. La sua struttura è modulare come per Nepenthes, i principali moduli sono i seguenti: • Amun Kernel • Request Handler • Vulnerability Modules • Shellcode Analyzer • Download Modules • Logging Modules Fondamentalmente Amun segue lo stesso approccio di Nepenthes: simula le vulnerabilità conosciute e tenta di scaricare qualsiasi file che gli viene offerto. L’utilità di Amun risiede nel fatto che affiancandola a Nepenthes ci permette di ampliare il numero di vulnerabilità emulate e di effettuare un confronto tra i due Honeypot. L’installazione di Amun parte dall’installazione di alcune dipendenze quali la versione di PostgreSQL per il linguaggio Python. Continua con il download del pacchetto e con la configurazione del tool.

35 Amun (2/4) Configure /opt/amunhoney/conf/amun.conf
# if you also run other honeypot comment out the modules listening on the same ports ### define ports for vulnerability modules ### (can be changed while running) # You will also need to uncomment the modules in the vuln_modules section: vuln_modules: # vuln-ms08067, Surfids In the log_modules section uncomment the log-surfnet module: ### define logging modules log_modules: log-surfnet # log-syslog Configure /opt/amunhoney/conf/log-surfnet.conf [Log-Surfnet] sensorIP: In particolare è necessario modificare il file amun.conf definendo i porti per i moduli di vulnerabilità e definendo quali moduli attivare. Per inglobare Amun con SurfIDS bisogna attivare il modulo log-surfnet e configurare il file log-surfnet.conf settando i dati per il database.

36 Amun (3/4) Start Amun … PGHost: enter-ip-database PGPort: 5432
PGUser: nepenthes PGPass: enter-your-password PGDB: idsserver # To download binaries to the normal surfids location: cd /opt/amunhoney/malware mv md5sum md5sum.orig ln -s /opt/surfnetids/binaries md5sum # change the file /opt/amunhoney/submit_modules/submitmd5/submit_md5.py # modify filename = "malware/md5sum/%s.bin" % (md5hash) # in filename = "malware/md5sum/%s" % (md5hash) Start Amun ./amun_server.py Nel caso in cui si vuole scaricare i binari dei malware rilevati da Amun nella directory di SurfIDS bisogna eseguire i comandi riportati e modificare submit_md5.py. Per avviare Amun basta semplicemente posizionarsi nella cartella del tool ed eseguire il file amun_server.py.

37 Amun (4/4) Attacker starts nmap
nmap -sS -PN -v Starting Nmap 5.21 ( ) at :18 CET Initiating ARP Ping Scan at 18:18 Scanning [1 port] Completed ARP Ping Scan at 18:18, 0.01s elapsed (1 total hosts) Initiating Parallel DNS resolution of 1 host. at 18:18 Completed Parallel DNS resolution of 1 host. at 18:18, 0.05s elapsed Initiating SYN Stealth Scan at 18:18 Scanning [1000 ports] Discovered open port 23/tcp on Discovered open port 443/tcp on Discovered open port 1025/tcp on Discovered open port 80/tcp on Discovered open port 8080/tcp on Discovered open port 587/tcp on Discovered open port 143/tcp on Discovered open port 110/tcp on Discovered open port 22/tcp on Discovered open port 139/tcp on Discovered open port 445/tcp on Discovered open port 554/tcp on Discovered open port 42/tcp on Discovered open port 1023/tcp on Discovered open port 1080/tcp on Completed SYN Stealth Scan at 18:18, 1.31s elapsed (1000 total ports) Nmap scan report for Host is up ( s latency). Not shown: 966 closed ports PORT STATE SERVICE 21/tcp open ftp 22/tcp open ssh 23/tcp open telnet 25/tcp open smtp 42/tcp open nameserver 80/tcp open http 110/tcp open pop3 135/tcp open msrpc 139/tcp open netbios-ssn 143/tcp open imap 443/tcp open https 445/tcp open microsoft-ds 554/tcp open rtsp 587/tcp open submission 617/tcp open sco-dtmgr …

38 SURFIDS The SURFids is a Distributed Intrusion Detection framework
It is based on the following rules: The sensor should run out-of-the-box The sensor should be completely passive and therefore maintenance free The D-IDS should not generate any false positive alerts A sensor should be able to run in a standard LAN Comparison of statistics generated by sensors and groups of sensors should be possible The detection tools are installed on a central server (called tunnel server) Distributed sensors connect to the tunnel server and tunnel all their layer 2 and higher traffic to the tunnel server All information is presented to the users by a webinterface (logging server) SURFids è un Sistema Distribuito per il Rilevamento delle Intrusioni basato su sensori passivi. Gli attuali Sistemi Distribuiti per il Rilevamento delle Intrusioni (DIDS) sono per la maggior parte basati su un approccio client/server dove il client è chiamato sensore. Questi sensori spesso contengono un honeypot e/o tool di analisi passiva come SNORT. Questo approccio ha quatto svantaggi principali: Il sensore deve essere aggiornabile per aggiungere nuovi honeypot e nuove firme. Il sensore può essere vulnerabile agli exploit usati contro l'honeypot ed il software di analisi passiva. Il DIDS genererà falsi positivi. L'installazione e la gestione del sensore non è plug and play. L'approccio SURFids invece, si propone le seguenti regole: Il sensore dovrebbe essere completamente passivo e quindi esente da manutenzione. Il DIDS non dovrebbe generare nessun falso positivo. Un sensore dovrebbe essere capace di girare in una LAN standard. Dovrebbe essere possibile la comparazione di statistiche generate dai sensori e da gruppi di sensori. L'architettura SURFids è composta da diversi client/sensori, con la possibilità che questi siano situati in reti differenti, appartenenti ad organizzazioni differenti. Questi client/sensori utilizzano OpenVPN per creare un tunnel diretto al DIDS server. Successivamente, il DIDS server provvederà ad eseguire una richiesta DHCP attraverso il tunnel alla LAN del client/sensore. Questa richiesta permette al DIDS server di ottenere un indirizzo IP sulla LAN del client/sensore e poi di attaccarsi su un'interfaccia virtuale. Il DIDS server sarà allora virtualmente presente sulla LAN del client/sensore e gli attaccanti penseranno di stare attaccando un host della LAN del client/sensore. Lo schema globale del framework è mostrato in figura.

39 SURFIDS Components Tunnel/Honeypot Server
The tunnel end-point on the server is called a tap device Tap device is a virtual interface which delivers the traffic from the tunnel on the server. The tap device will receive an IP address from the client network address pool. This will make the server virtually present in the client network Sensor The only purpose of the sensor is to be a transparent bridge between the client network and the tunnel/honeypot server The sensor manages the creation and destruction of the tunnel that is used to connect the tunnel/honeypot server to the client network Logging Server The logging server consists of two parts, the database and a web interface The database is used to store the analysis information from the honeypot server. This information is presented to the users by a web interface Il Tunnel/Honeypot Server può essere suddiviso in Tunnel Server e Honeypot. Il sensore farà partire la creazione del tunnel diretto al server tramite l’esecuzione di OpenVPN su entrambe le parti. L’endpoint lato tunnel server è chiamato Tap Device. Il tap device è un’interfaccia virtuale utilizzata per spedire il traffico dal tunnel sul server: questo viene fatto richiedendo un indirizzo ip dalla rete dov’è presente il client sul quale è installato il sensore stesso. In questo modo, è come se il sistema IDS fosse presente nella stessa rete del sensore. Per quanto riguarda il sensore, esso ha il solo compito di inizializzare il tunnel, di gestirlo ed eventualmente distruggerlo. SurfIDS prevede che il sensore sia installato a partire da una penna USB. Infine, il Logging Server si suddivide nel database che contiene le informazioni ottenute dagli Honeypot e dall’interfaccia grafica che ne permetterà l’analisi.

40 SURFIDS Installation (1/6)
Logging Server Installation # add the SURFids key to your local key chain wget -q -O- | sudo apt-key add – # create a file /etc/apt/sources.list.d/surfids.list with the content: deb lenny main # to start the SURFids logging server installation we use apt-get apt-get update apt-get install surfids-logserver sendmail sendmail-bin Set database Host Insert Admin database user Create a postgresql user: sudo -u postgres createuser -s -d -r -P <adminuser> Set admin user password Set database listening port Set database name Set SURFids database user and SURFids user password Set nepethes, pof, argos user password Download the latest GeoIP database L’installazione del Loggin-Server parte dallo scaricamento della chiave di Surfids. In seguito, bisogna creare un file contenente il repository dove prelevare i pacchetti necessari tramite il comando apt-get. Durante l’installazione sarà chiesto di inserire informazioni circa l’host dove risiede il database (nel nostro caso è lo stesso host dove installeremo il tunnel server e abbiamo installato gli honeypot, ma per incrementare la sicurezza è consigliato utilizzare un server remoto), la creazione di un utente postgres se non già presente, l’inserimento del porto del db, inserimento di username e passoword per i tool nepenthes, pof, argos e lo scaricamento del db per la geolocalizzazione.

41 SURFIDS Installation (2/6)
Logging Server Configuration # configuration file is located at /etc/surfnetids/surfnetids-log.conf ####################### # Database connection # ####################### # User info for the logging user in the postgresql database $c_pgsql_pass = "enter_password_here"; $c_pgsql_user = "idslog"; # Postgresql database info $c_pgsql_host = "localhost"; $c_pgsql_dbname = "idsserver"; # The port number where the postgresql database is running on $c_pgsql_port = "5432"; # Enable or disable the download option of binaries in the webinterface $c_download_binaries = 1; ####################### # GeoIP Location Info # ####################### # Enable GeoIP location database to enable source IP country identification. $c_geoip_enable = 1; La configurazione del Loggin Server passa per la modifica di un unico file in cui dovranno essere settati i parametri di accesso al database. Inoltre, potrà essere settato il download dei binari dalla webinterface e abilitata la geolocalizzazione IP.

42 SURFIDS Installation (3/6)
# The key used for the Googlemap API $c_googlemap_key = "enter_googlemap_key_here"; # Generate a GnuPG key used to sign mail-reports: gpg --gen-key # and insert the key in # Maillog GNUPG passphrase. $c_passphrase = "enter_gnupg_passphrase_here"; ################# # Sandbox ################# # Settings needed to retrieve the Norman reports from the mailbox they were sent to # login credentials $c_mail_username = ' _username'; $c_mail_password = ' _pass'; # mailhost and port $c_mail_mailhost = 'mailhost'; $c_mail_port = '995'; # replace the “enter_database_pass_here” text with the actual password needed for connecting with the database in /opt/surfnetids/webinterface/.htaccess Quest’ultima utility può essere settata solo se in possesso di una chiave utilizzata per le google API. Uno dei settaggi più importanti è l’inserimento della chiave utilizzata per firmare le mail di avviso inviate in caso di attacco.

43 SURFIDS Installation (4/6)
Tunnel Server Installation # Add the Dapper repository in sources.list: deb / hardy main universe # to start the SURFids tunnel server installation we use apt-get apt-get update apt-get install surfids-tunnel Set OpenVPN key size Insert attribute for certificates Set Xinetd listening address Set IP address of tunnel server that is accepting the OpenVPN connections Set the password used by the sensor to communicate with the tunnel server Tunnel Server Configuration # configuration file is located at /etc/surfnetids/surfnetids-tn.conf #################### # SURF IDS Options # #################### # The root directory for the SURF IDS files (no trailing forward slash). $c_surfidsdir = "/opt/surfnetids"; Per l’installazione del Tunnel Server bisogna aggiungere un Dapper repository nella sources.list in quanto il Tunnel Server utilizza una versione più vecchia di OpenVPN. Come per il logging server, anche qui utilizziamo le apt per l’installazione del tool. La configurazione consiste nel settare la directory principale di surfids,

44 SURFIDS Installation (5/6)
####################### # Database connection # ####################### # User info for the logging user in the postgresql database $c_pgsql_pass = "enter_password_here"; $c_pgsql_user = "idslog"; # Postgresql database info $c_pgsql_host = "enter_database_servername_here"; $c_pgsql_dbname = "idsserver"; # The port number where the postgresql database is running on. $c_pgsql_port = "5432"; ################ # Mail logging # ################ # Maillog From: address. This is the addres that appears in the From header. $c_from_address = 'enter_ _address_here'; # Maillog GNUPG passphrase. $c_passphrase = "enter_GNU_passphrase_here"; # Prefix for the subject of reports $c_subject_prefix = "[SURF IDS] "; Nell’inserimento dei dati per il database e il settaggio del servizio di avviso .

45 SURFIDS Installation (5/6)
Add Local Static Sensor to SURFids database cd /opt/surfnetids/logtools ./localsensor.pl -p /opt/surfnetids/logtools/localsensor.pl -i eth0 -s Nepenthes -o Evil_Sensor Open the web interface available at Per concludere, non ci resta che inserire nel database di surfids le informazioni del sensore statico locale e avviare l’interfaccia utente.

46 AV Installation (1/3) Local scan of Suspicious Files with:
F-Prot AVAST ClamAV Create a Directory cd /opt mkdir scanner cd scanner Install ClamAV apt-get install unzip libwww-perl apt-get -y install clamav Freshclam Install F-Prot # Download fp-Linux.x86.32-ws.tar.gz from F-Prot official website tar -xvf fp-Linux.x86.32-ws.tar.gz cd f-prot ./install-f-prot.pl Non avendo un modulo per il submit in remoto dei file sospetti, SURFids utilizza l’altra strada possibile, la scansione in locale. L’implementazione non è complessa: vengono utilizzati i motori di scansione installati sulla macchina per eseguire un controllo dei file sospetti, i risultati vengono poi parsificati da apposite procedure e quindi salvati nel database PostgreSQL. Queste procedure sono automatiche, ma le regole di parsing dei risultati sono da definire. Infatti SURFids mette a disposizione le regole per i detection engine di F-Prot, AVAST, ClamAV. Se si vogliono integrare ulteriori engine bisogna creare delle regole di parificazione dei risultati delle scansioni. La scansione in locale viene avviata tramite uno script in Perl che viene invocato periodicamente dalla schedulazione nel crontab dell’utente root.

47 AV Installation (2/3) Install Avast
# Download avast4workstation tar.gz from AVAST official website tar -xvf avast4workstation tar.gz # Download avast4workstation_ _i386.deb from AVAST official website dpkg -i avast4workstation_ _i386.deb sysctl -w kernel.shmmax= # AVAST requires a free registration to work Configure /opt/surfnetids/scripts/scanbinaries.pl #################### # Define scanners $scanners->{"F-Prot"} = { 'cmd' => "/opt/scanner/f-prot/fpscan -v 2 --report --adware", 'update' => "/opt/scanner/f-prot/fpupdate", 'version' => "/opt/scanner/f-prot/fpscan --version | grep \"F-PROT Antivirus version\" | awk -F'(' '{print \$1}' | awk '{print \$NF}'", 'batchmode' => 0, };

48 AV Installation (3/3) Add to crontab … $scanners->{"AVAST"} = {
'cmd' => "/opt/scanner/avast4workstation-1.3.0/bin/avast -n", 'update' => "/opt/scanner/avast4workstation-1.3.0/bin/avast-update", 'version' => "/opt/scanner/avast4workstation-1.3.0/bin/avast --version | head -n1 | awk -F\"avast \" '{print \$2}'", 'batchmode' => 1, }; $scanners->{"ClamAV"} = { 'cmd' => "clamscan --no-summary", 'update' => "freshclam", 'version' => "clamscan --version | awk '{print \$2}' | awk -F\"/\" '{print \$1}'", 'batchmode' => 0, Add to crontab 00,30 * * * * /opt/surfnetids/scripts/scanbinaries.pl >/dev/null

49 Metasploit: Penetration Test Software
Metasploit® software helps security and IT professionals Identify security issues, verify vulnerability mitigations, and manage expert-driven security assessments Download from for FREE Install it on the attacker machine and test the all-in-one machine: Discover open ports Exploit target system (require registration) Il test di penetrazione è stato effettuando il software Metasploit. Esso può essere scaricato gratuitamente dal sito ufficiale e installato sulle piattaforme windows, linux 32 bit o 64 bit. Il tool, quindi, è stato installato sulla macchina attacker ed è stato simulato appunto un attacco al sistema IDS attraverso un portscan e l’esecuzione automatica di exploit. Quest’ultimo servizio, è disponibile in Metasploit solo nella versione a pagamento o nella versione demo utilizzabile per sette giorni dietro registrazione.

50 Metasploit: Testing Nepenthes
VS + Considerando lo scenario in cui sulla macchina IDS è presente solo Nepenthes, andiamo ad analizzare cosa succede prima sulla macchina dell’attaccante e poi sulla macchina colpita.

51 Metasploit: Testing Nepenthes
VS +

52 Metasploit: Testing Amun
VS + La stessa analisi viene ripetuta nel caso in cui sull’IDS è presente Amun anziché Nepenthes

53 Metasploit: Testing Amun
VS +


Download ppt "INTRUSION DETECTION SYSTEM"

Similar presentations


Ads by Google