%% ids.tex
%%
%% Copyright (C) 2003-2018 Simone Piccardi and Truelite Srl.
%%
%% This work is licensed under the Creative Commons Attribution-ShareAlike 4.0
%% International License. To view a copy of this license, visit
%% \url{http://creativecommons.org/licenses/by-sa/4.0/} or send a letter to
%% Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.
%%
%% Corso Linux : Dispense dei corsi GNU/Linux di Truelite
%%
%% S. Piccardi Dec. 2003
%% 
%% ids.tex: sezione sugli IDS
%%

%
% To avoid these definition when included from outside
%
\providecommand{\setflag}{\newif \ifwhole \wholefalse} \setflag

\ifwhole\else
\documentclass[10pt,twoside]{book} 
\usepackage[paperwidth=18.91cm,paperheight=24.589cm,
inner=2.5cm,outer=1.8cm,bottom=3.3cm,top=2.3cm]{geometry}

\input{../commons/packages2}
\input{../commons/front2}

\makeindex

\begin{document}

\pagenumbering{roman}

\begin{titlepage}
    \centering
    \phantom{}
    \vfill
    {\Huge \textbf{\textsf{Introduzione agli}}}

    \vspace{.3cm}
    {\Huge \textbf{\textsf{Intrusion Detection System}}}
    \vfill
    {\huge \textsf{Simone Piccardi}}

    {\large \textsf{piccardi@truelite.it}}
    
    \vspace{2.5cm} {\textsf{Truelite Srl \hfill http://www.truelite.it \hfill
      info@truelite.it}}
\end{titlepage}

\ClearShipoutPicture

\newcommand{\clearemptydoublepage}{\newpage{\pagestyle{empty}
\cleardoublepage}}

\newcommand{\CopyrightRange}{2003-2014}
\newcommand{\BookFullTitle}{Introduzione agli IDS}
\newcommand{\BookEdition}{Prima edizione}
\input{../commons/seconda}

\clearemptydoublepage
%\ifx\hcode\undefined\else
\tableofcontents
%\fi
\clearemptydoublepage
%\include{macro}
%\include{pref}
\clearemptydoublepage
\mainmatter

\fi


\chapter{Sistemi di \textit{Intrusion Detection}}
\label{cha:ids}


\section{Cosa sono e a cosa servono gli \textit{IDS}}
\label{sec:ids_whatis}

In questa prima sezione faremo una breve introduzione teorica sul significato
e le motivazioni che portano all'uso dei cosiddetti \textsl{sistemi di
  rilevamento delle intrusioni}, a cui, da qui in avanti, faremo sempre
riferimento con la sigla IDS, derivante dalla denominazione inglese
\textit{Intrusion Detection System}. Forniremo poi una panoramica sulle
modalità di classificazione che vengono adoperate per distinguere fra loro le
varie tipologie di programmi che rientrano in questa categoria generica.


\subsection{La sicurezza e gli IDS}
\label{sec:ids_and_security}

Come abbiamo illustrato in sez.~\ref{sec:security_whatis} nell'informatica
sono state adottate varie definizioni del termine sicurezza che ne
caratterizzano il significato secondo vari aspetti; nel nostro caso ci siamo
rifatti alla definizione che si basa sul soddisfacimento dei tre obiettivi
fondamentali della \textsl{confidenzialità}, \textsl{integrità} e
\textit{disponibilità}.

Il paradigma classico della sicurezza cerca di realizzare questi obiettivi
identificando utenti e risorse del sistema, e definendo una opportuna
relazione fra di essi (vedi sez.~\ref{sec:security_services}). In generale
pertanto si deve disporre di un \textsl{meccanismo di identificazione} per
consentire l'accesso agli utenti, e di un \textsl{meccanismo di controllo},
basato su una opportuna serie di permessi, che consente loro di eseguire nel
sistema solo le operazioni che gli sono state consentite.

In sostanza il meccanismo si basa sulla risposta alle due domande
``\textsl{chi sei?}'' e ``\textsl{cosa puoi fare?}''. Di norma questo viene
fatto attraverso una procedura di autenticazione, e l'uso estensivo dei
permessi degli utenti. Il caso classico è quello dell'uso di username e
password per l'autenticazione e l'uso dei permessi di utenti e gruppi per
l'accesso; entrambe le funzionalità sono state ampiamente estese, ma il
concetto di base resta lo stesso.

Tutto questo ovviamente funziona fintanto che l'implementazione dei programmi
che gestiscono questi aspetti del sistema è corretta. Il problema è che la
perfezione non è di questo mondo, ed esistono e sono esistite molte
vulnerabilità dei programmi che opportunamente sfruttate rendono in grado
un attaccante di superare o rendere inefficaci sia le procedure di
autenticazione che quelle di controllo.

Questo è ancora più evidente nel caso dei sistemi in rete. Internet in
particolare non è nata per garantire controllo degli accessi e non è provvista
di meccanismi di identificazione o riservatezza; chiunque può, nel momento
stesso in cui vi ha accesso, leggere quanto vi transita ed immettervi i suoi
pacchetti. A livello del protocollo fondamentale, IP, non esiste nessun
meccanismo di controllo o autenticazione. Benché da varie parti si sia corsi
ai ripari, introducendo a vari livelli (SSL, IPSEC, VPN) alcune di queste
funzionalità, resta il fatto che provvedere un meccanismo di autenticazione e
controllo degli accessi a livello di rete è molto complesso e le difficoltà di
gestione crescono enormemente.

Gli IDS nascono allora proprio dalla consapevolezza dei limiti intrinseci del
paradigma di sicurezza basato sull'autenticazione ed il controllo degli
accessi, e si fondano sulla constatazione che usualmente una violazione della
sicurezza si manifesta attraverso un comportamento anomalo del sistema, che è
quello che un IDS è progettato per rilevare. In sostanza dalle due precedenti
domande ``\textsl{chi sei?}'' e ``\textsl{cosa puoi fare?}'' con un IDS si
passa a porsi la domanda ``\textsl{perché stai facendo questo?}''.

Tutto ciò ci fa capire che in realtà un IDS non è un sostituto degli altri
meccanismi di sicurezza, quanto piuttosto un ausilio a supporto del controllo
della loro efficacia, un ausilio di grande efficacia certamente, ma che
richiede la presenza di un'efficace politica di sicurezza perseguita con
costanza, e l'attenzione da parte di personale qualificato. Perciò non si
pensi di installare un IDS per non doversi preoccupare più della sicurezza,
sarebbe assolutamente inutile, lo si installi solo quando ci si vuole, per
scelta consapevole, \textsl{preoccupare} della sicurezza. 



\subsection{Tipologia degli IDS}
\label{sec:ids_tipology}

In generale un IDS non si sostituisce mai ai vari controlli effettuati dai
meccanismi di sicurezza posti a salvaguardia di un sistema, ma piuttosto cerca
di scoprire un loro fallimento. In caso di violazione, o di tentativo di
violazione di un sistema vengono infatti compiute azioni ``\textsl{anomale}''
che nelle normali operazioni non verrebbero mai eseguite; identificando
quest'ultime diventa possibile scoprire la presenza di un eventuale intruso. 
Una delle difficoltà maggiori nell'uso efficace di un IDS è proprio quella di
identificare tali azioni, e non confonderle con azioni assolutamente
legittime, ancorché poco usuali. 

In generale si hanno due metodologie principali per riconoscere le anomalie
del sistema. Il primo e più diretto è quello chiamato \textit{misuse
  detection}, cioè la rilevazione diretta di un utilizzo non consentito di
alcune risorse. In genere questo viene fatto attraverso una qualche forma di
rappresentazione (di norma con una serie di regole, più o meno complesse) che
permetta di definire e osservare quali sono i comportamenti anomali da
controllare. 

Il limite di questo metodo è che occorre identificare con chiarezza il
\textit{misuse}, e se qualcuno utilizza un attacco che non era stato previsto
questo verrà ignorato. A questo problema risponde la seconda metodologia,
detta \textit{anomaly detection} che cerca di classificare (in genere su base
statistica, con vari modelli e meccanismi) il comportamento normale,
identificando così come sospette tutte le deviazioni significative da esso; il
grande vantaggio di questo approccio è la sua generalità, dato che è
automaticamente in grado di adattarsi per riconoscere nuovi schemi di attacco.
La difficoltà sta nella scelta dei modelli da utilizzare (cosa misurare, come
impostare le soglie di allarme, ecc.) che permettano di selezionare in maniera
adeguata, vale a dire sostenibile per il controllo da parte
dell'amministratore, le eventuali situazioni sospette.

Una seconda classificazione degli IDS è quella che distingue fra quelli che
eseguono le loro operazioni \textit{on-line}, in tempo reale, rispondendo
immediatamente quando riconoscono un tentativo di intrusione, e quelli che
operano \textit{off-line}, che sono in grado di effettuare il riconoscimento
solo eseguendo una verifica in un momento successivo sulla base dei dati
raccolti. 

Nel primo caso (un esempio di IDS di questo tipo è \texttt{snort}, che
vedremo in sez.~\ref{sec:ids_snort}), vengono generati degli opportuni allarmi
(i cosiddetti \textit{alert}) all'accadere di certe situazioni. Di norma
questo viene fatto esaminando gli eventi correnti all'interno di una certa
finestra temporale, e al rilevamento di possibili intrusioni vengono attivati
gli allarmi, che a loro volta possono innescare azioni successive. 

In questo caso una delle possibilità è quella di approntare delle contromisure
automatiche volte a bloccare le operazioni coinvolte nell'azione di
intrusione, come ad esempio bloccare il traffico di rete verso certe
macchine. Questo è quello che fanno i cosiddetti IPS (\textit{Intrusion
  Prevention System}), che vengono proposti come il passo successivo agli
IDS.\footnote{anche il citato \texttt{snort} ha la possibilità di implementare
  questo tipo di politiche.}  Una reazione automatica di questo tipo espone
però al rischio di poter essere sfruttata da un attaccante che abbia
identificato la presenza di tali contromisure per rendere inutilizzabile il
servizio con un attacco simulato, con il risultato di far fallire il terzo
degli obiettivi fondamentali della sicurezza, la \textit{disponibilità}.

In genere il limite degli IDS che operano in tempo reale è quello delle
risorse necessarie per eseguire i controlli, dato che questi possono essere
molto pesanti sia dal punto di vista computazionale che dal punto di vista
dello stoccaggio dei dati. Negli IDS \textit{offline} invece l'analisi viene
svolta successivamente in un secondo tempo, e pertanto si può spendere più
tempo non essendo necessaria la risposta immediata.

In genere con gli IDS che operano \textit{offline} si ha la capacità di una
analisi molto più completa e dettagliata, e potendo operare senza limiti di
tempo, si possono anche trattare moli di dati non analizzabili in tempo reale;
il problema è che essi, per definizione, sono utilizzabili solo dopo che è
avvenuto un incidente o un attacco. In alcuni casi però (come \texttt{aide},
che vedremo in sez.~\ref{sec:ids_integrity_scan}) l'uso di un IDS di questo
tipo può essere estremamente utile per rilevare il tipo di intrusione e porvi
rimedio senza essere costretti a soluzioni più drastiche come la
reinstallazione.

In molti casi oggi esistono degli IDS (come avviene per lo stesso
\texttt{snort} che tratteremo in sez.~\ref{sec:ids_snort}) che sono in grado
di fornire una combinazione di queste due caratteristiche, gestendo sia la
generazione di allarmi \textit{on-line} che la registrazione degli eventi
relativi ad un allarme per consentirne una successiva, e molto più accurata,
analisi \textit{off-line}. 

L'ultima classificazione degli IDS prevede altre due categorie, la prima è
quella degli IDS \textit{host-based}, in cui il controllo viene eseguito su
una singola stazione, relativamente alle attività registrate dall'IDS sulla
stessa. Un esempio è sempre \texttt{aide}, che rientra in questa categoria,
così come gli analizzatori dei file di log; ma esistono numerose alternative,
spesso anche combinabili fra loro. Torneremo su questo argomento in
sez.~\ref{sec:ids_local}.

La seconda categoria è quella degli IDS \textit{network-based}, in cui viene
invece controllato il traffico su una rete alla ricerca di tracce di
intrusione fra i pacchetti in transito. In genere si tende a identificare
questi ultimi, di cui \texttt{snort} è il più noto e quello che tratteremo in
dettaglio, che più propriamente dovrebbero essere chiamati NIDS (cioè
\textit{Network Intrusion Detection System}), con gli IDS generici.


\section{Tecniche di rilevamento}
\label{sec:ids_scanners}

Uno dei compiti principali nelle attività di gestione della sicurezza è quello
della ricerca delle possibili falle che possono comprometterla.  Pertanto
diventa fondamentale, per poter affrontare poi il funzionamento degli IDS,
conoscere ed analizzare i principali strumenti di analisi, scansione e ricerca
delle vulnerabilità, che sono gli stessi che potrebbero essere usati contro di
voi per rilevare i vostri punti deboli da un eventuale attaccante.

Per questo motivo in questa sezione prenderemo in esame alcune tipologie di
strumenti usati tipicamente per la raccolta di informazioni sulle macchine ed
i servizi presenti su una rete, per intercettare ed analizzare il traffico di
rete e per la scansione delle vulnerabilità presenti. Per ciascuna tipologia
presenteremo il principale programma disponibile su GNU/Linux per svolgere il
relativo compito.


\subsection{I \textit{portscanner}}
\label{sec:ids_portscanner}

\itindbeg{portscanner}

Uno degli strumenti principali per l'analisi della propria rete, e per la
ricerca di eventuali punti deboli e possibilità di accesso non autorizzato è
il cosiddetto \textit{portscanner}. Un \textit{portscanner} è semplicemente un
programma in grado di rilevare quali servizi di rete sono attivi su una
macchina o in una intera rete, eseguendo una scansione sulle porte (in genere
TCP, ma anche UDP) per identificare quali di esse sono correntemente
utilizzate da un qualche demone di sistema per fornire servizi.

Come tutti gli strumenti di analisi usati per la sicurezza un
\textit{portscanner} può essere usato sia per scopi offensivi (la ricerca di
servizi vulnerabili da attaccare) che difensivi (la ricerca di servizi
vulnerabili o inutili da chiudere), in generale è comunque uno strumento
indispensabile per verificare in maniera effettiva la propria rete, dato che
in presenza di una macchina compromessa non si può avere nessuna fiducia nei
programmi diagnostici eseguiti su detta macchina (ad esempio \texttt{netstat}
per tracciare le connessioni attive), che potrebbero essere stati a loro volta
compromessi.

Infatti, in caso di violazione di una macchina, uno dei primi passi eseguiti
di solito da chi ha effettuato l'intrusione è quello di predisporre una
\itindex{backdoor} \textit{backdoor} e poi modificare lo stesso kernel o i
programmi che potrebbero rilevarne la presenza (come \texttt{ps}, \texttt{ls},
\texttt{netstat}) installando un \itindex{rootkit} \textit{rootkit}. È chiaro
che se il sistema è stato modificato in modo da mascherare una eventuale
intrusione, usare i programmi dello stesso per effettuare controlli, in
particolare per rilevare porte aperte in ascolto per connessioni remote, non è
una procedura affidabile.

In questi casi diventa essenziale poter usare un \textit{portscanner} partendo
da una macchina fidata (o da una distribuzione live su CDROM), sia come
meccanismo di verifica e controllo della propria rete, che come strumento per
la scoperta della presenza di eventuali servizi anomali, abusivi o
semplicemente non previsti o non disabilitati.  Inoltre è prassi comune (ed
anche consigliata) usare un \textit{portscanner} a scopo diagnostico per
verificare l'efficacia delle impostazioni di un firewall e l'effettiva
funzionalità dello stesso.

Nel caso di GNU/Linux, ma lo stesso vale per la gran parte degli altri sistemi
unix-like, ed esiste una versione anche per Windows, il \textit{portscanner}
di gran lunga più utilizzato è \index{comando!\texttt{nmap}} \texttt{nmap}, in
genere presente in tutte le distribuzioni,\footnote{nel caso di Debian basta
  installare il pacchetto omonimo.} e comunque reperibile su
\url{http://www.insecure.org/nmap/index.html}. Noi esamineremo soltanto la
versione a riga di comando, segnaliamo però l'esistenza di una versione
grafica, \index{comando!\texttt{zenmap}} \texttt{zenmap}, con la quale si può
perdere un sacco di tempo a muovere le dita fra tastiera e mouse per fare le
stesse cose.\footnote{in realtà con la versione 5.x il programma, un tempo
  chiamato semplicemente \index{comando!\texttt{nmapfe}} \texttt{nmapfe}, si è
  arricchito della capacità di registrare i dati delle varie scansioni
  effettuate, e mantenere una sorta di \textit{knowledge base}.}

La principale caratteristica di \texttt{nmap} è la sua enorme flessibilità, il
programma infatti è in grado di eseguire i \textit{portscan} con una grande
varietà di metodi, ponendo una grande attenzione ad implementare anche quelli
che permettono o di mascherare la propria attività o di non farsi
identificare. In questo modo è in grado di rilevare la presenza di firewall,
di determinare il sistema operativo usato da una macchina e di ricavare le
versioni degli eventuali server installati, nonché di analizzare i servizi
RPC.  Inoltre, sia pure con funzionalità più limitate, può essere utilizzato
anche senza avere i privilegi di amministratore.

Nella sua forma più elementare il comando richiede soltanto di specificare
l'indirizzo della macchina (o della rete) da analizzare; quello che nella
pagina di manuale viene chiamato \textsl{bersaglio} (o \textit{target}). Si
possono anche indicare più bersagli con una lista separata da spazi e questi
possono essere specificati sia attraverso il loro hostname che con l'indirizzo
IP numerico. Si possono inoltre specificare intere reti da analizzare che
devono essere indicate con la notazione CIDR, e questa è anche una delle
caratteristiche più importanti di \texttt{nmap}, che lo rende un ausilio di
grande utilità per rilevare le macchine presenti su una rete di cui non si sa
nulla.

Oltre alla semplice indicazione di un indirizzo di rete il comando supporta
anche una sintassi che permette di specificare il bersaglio del
\textit{portscan} in maniera alquanto sofisticata, specificando elenchi di
indirizzi separati da virgole (cioè con il carattere ``\texttt{,}''),
intervalli separati da ``\texttt{-}'', e anche caratteri jolly come
``\texttt{*}''.  Inoltre questi possono essere usati in qualunque parte
dell'indirizzo, per cui è legittimo, anche se poco leggibile, anche un
bersaglio del tipo ``\texttt{192.168.1,2.1,2,100-200}''.

Specificando più bersagli o una intera rete verranno visualizzati in sequenza
i risultati per ciascuna delle singole macchine che vengono trovate attive via
via che la relativa scansione viene terminata. Dato che la scoperta di quali
macchine sono presenti su una rete può essere una operazioni lunga, qualora se
ne abbia già un elenco lo si può fornite al comando passandoglielo con
l'opzione \texttt{-iL}. Questa richiede come parametro un nome di file da cui
leggere l'elenco degli indirizzi da controllare, il cui formato richiede
semplicemente che questi siano espresse come elenco (separato con spazi,
tabulatori, o a capo) di una qualunque delle forme supportate sulla riga di
comando; si possono anche inserire commenti, dato che tutto quello che segue
il carattere \texttt{\#} verrà ignorato.

Quando si indicano intere reti si possono escludere dalla scansione un certo
numero di macchine con l'opzione \texttt{-{}-exclude}, che richiede come
parametro l'elenco dei relativi indirizzi separati da virgole (e senza spazi).
Questo può risultare utile per rendere più evidente la presenza di macchine
non previste rispetto a quelle note, o per evitare di eseguire il
\textit{portscan} su macchine critiche.

Un possibile esempio elementare dell'uso di \texttt{nmap}, in cui si esegue la
scansione per una singola macchina identificata tramite il suo indirizzo IP è
il seguente:
\begin{Console}
# \textbf{nmap 192.168.1.2}
Starting Nmap 5.21 ( http://nmap.org ) at 2011-04-04 19:38 CEST
Nmap scan report for davis.fi.trl (192.168.1.2)
Host is up (0.0061s latency).
Not shown: 990 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
25/tcp   open  smtp
53/tcp   open  domain
80/tcp   open  http
111/tcp  open  rpcbind
443/tcp  open  https
636/tcp  open  ldapssl
2049/tcp open  nfs
3306/tcp open  mysql
9102/tcp open  jetdirect
MAC Address: 52:54:00:D3:BD:31 (QEMU Virtual NIC)

Nmap done: 1 IP address (1 host up) scanned in 0.14 seconds
\end{Console}

La grande potenza di \texttt{nmap} è nella enorme flessibilità con cui lo si
può usare, ed il programma supporta una innumerevole serie di opzioni che
consentono di controllare le sue caratteristiche. Data l'ampiezza delle stesse
prenderemo in considerazione solo quelle più significative, per un elenco
completo si può fare riferimento alla pagina di manuale, accessibile con
\texttt{man nmap}, che contiene una documentazione molto dettagliata; un breve
riassunto può invece essere ottenuto eseguendo direttamente il comando come
\texttt{nmap -h} o invocandolo senza argomenti.

Le opzioni sono suddivise in varie categorie: per indicare la tecnica di
scansione utilizzata, per indicare la tecnica di rilevazione della presenza
delle macchine, per indicare le temporizzazioni del \textit{portscan} ed
infine quelle generiche. Molte sono, rispetto all'utilizzo normale,
identificate da due lettere, la prima viene usata per specificare una
funzionalità generica, la seconda per indicare con quale metodo realizzarla. 

Si tenga presente che per poter essere usato, dovendo creare nella maggior
parte dei casi dei pacchetti costruiti \textsl{ad-hoc}, \texttt{nmap} richiede
i privilegi di amministratore. Qualora questi non siano disponibili e le
modalità di \textit{portscan} richieste li prevedano, il programma terminerà
con un messaggio di errore. Esiste comunque la possibilità di usarlo, con
funzionalità limitate, anche da utente normale.

\begin{table}[tbhp]
  \centering
  \footnotesize
  \begin{tabular}{|l|p{10cm}|}
    \hline
    \textbf{Opzione}&\textbf{Descrizione}\\
    \hline
    \hline
    \texttt{-sS} & \textit{TCP SYN scan}. Esegue una scansione dei servizi
                   attivi su TCP inviando un singolo pacchetto TCP con
                   il flag SYN attivo.\\ 
    \texttt{-sT} & \textit{TCP Connect scan}. Esegue una scansione dei servizi
                   attivi su TCP, effettuando una normale connessione TCP.\\ 
    \texttt{-sF} & \textit{Stealth FIN scan}. Invia un singolo pacchetto TCP 
                   con il flag FIN attivo.\\
    \texttt{-sX} & \textit{Xmas Tree scan}. Esegue una scansione dei servizi
                   attivi su TCP inviando un singolo pacchetto TCP
                   con i flag FIN, URG, e PUSH attivi.  \\ 
    \texttt{-sN} & \textit{Null scan} Esegue una scansione dei servizi
                   attivi su TCP inviando un singolo pacchetto TCP
                   senza nessun flag attivo.\\
    \texttt{-sM} & \textit{Maimon scan}. Esegue una scansione con la tecnica
                   scoperta da Uriel Maimon, usa un pacchetto TCP con i flag
                   FIN/ACK che viene scartato per le porte aperte su molti
                   sistemi derivati da BSD.\\
    \texttt{-sI} & \textit{Idle scan}. Esegue una scansione dei servizi
                   attivi su TCP sfruttando un'altra macchina.\\
    \texttt{-sA} & \textit{ACK scan}. Analizza il comportamento di un
                   firewall inviando pacchetti TCP con il solo flag ACK per
                   verificare se le relative porte sono filtrate.\\  
    \texttt{-sW} & \textit{Window scan}.  Analizza il comportamento di un
                   firewall per verificare il filtraggio delle porte come il
                   precedente \textit{ACK scan} ma permette di distinguere in
                   alcuni casi porte aperte da porte chiuse fra quelle non
                   filtrate.\\ 
    \texttt{-sU} & \textit{UDP scan}. Esegue una scansione sulle porte UDP.\\
    \texttt{-sY} & \textit{SCTP INIT scan}. Esegue una scansione sulle porte
                   del protocollo SCTP analoga al \textit{SYN scan}.\\ 
    \texttt{-sZ} & \textit{SCTP COOKIE ECHO scan}. Esegue una scansione sulle
                   porte del protocollo SCTP con una modalità alternativa.\\ 
    \texttt{-sO} & \textit{IP protocol scan}. Cerca di determinare i
                   protocolli supportati direttamente sopra IP.\\
    \texttt{-b}  & esegue un \textit{FTP bounce attack}, una tecnica basata
                   sull'appoggiarsi ad un server FTP vulnerabile, ormai
                   inefficace e deprecata.\\
    \hline
    \texttt{-sR} & \textit{RPC scan}. Cerca di verificare se le porte trovate
                   aperte corrispondono a servizi di tipo RPC, può essere
                   usato in congiunzione con gli altri tipi di scansione.\\ 
    \texttt{-sV} & \textit{Version detection}. Esegue un controllo sui servizi
                   trovati attivi per identificarne la versione, può essere
                   usato in congiunzione con gli altri tipi di scansione.\\
    \texttt{-sC} & \textit{Script scan}. Esegue una scansione facendo ricorso
                   agli appositi script di analisi forniti con il programma,
                   consentendo ricerche di informazioni molto complesse e 
                   sofisticate.\\
    \hline
    \texttt{-sL} & \textit{List scan}. Stampa semplicemente la lista degli IP
                   della rete specificata, con le eventuali risoluzioni
                   inverse.\\
    \texttt{-sP} & \textit{Ping scan}. Verifica soltanto la presenza attiva
                   di una macchina con la relativa tecnica di \textit{ping} 
                   (vedi tab.~\ref{tab:nmap_ping_options}).\\
    \hline
  \end{tabular}
  \caption{Opzioni di \texttt{nmap} per l'indicazione delle tecniche di
    scansione.} 
\label{tab:nmap_scan_options}
\end{table}

Le opzioni che indicano la metodologia di scansione sono riassunte in
tab.~\ref{tab:nmap_scan_options}, esse iniziano tutte con \texttt{-s} (con
l'eccezione di \texttt{-b} che comunque è deprecata) cui segue una seconda
lettera che specifica la tecnica da utilizzare. Se non si indica niente la
metodologia utilizzata di default dipende da chi esegue la scansione: se il
processo ha i privilegi di amministratore verrà eseguito un \textit{SYN scan},
altrimenti \texttt{nmap} utilizzerà il \textit{Connect scan}.

Vale la pena addentrarsi nella spiegazione delle tecniche di scansione usate
da \texttt{nmap} in quanto questo ci permette di capire meglio sia le
metodologie utilizzate dagli attaccanti per identificare i servizi presenti
sulle macchine, che i criteri con cui i sistemi antintrusione, su cui
torneremo più avanti, cercano di rilevare i tentativi di analisi. Una delle
caratteristiche di \texttt{nmap} infatti è quella di supportare tutte le
tecniche che rendono il più difficoltoso possibile individuare la presenza di
un \textit{portscan} o identificare chi lo sta eseguendo. 

La forma più elementare di \textit{portscan}, e l'unica utilizzabile dagli
utenti non privilegiati, è il \textit{Connect scan}, che usa la ordinaria
interfaccia dei socket, eseguendo una normale connessione su ciascuna porta.
In questo caso le connessioni su delle porte aperte verranno rilevate per la
risposta del rispettivo server e chiuse immediatamente dopo, mentre quelle su
delle porte chiuse saranno abortite con un errore o non riceveranno affatto
risposta; il primo caso è il comportamento standard di uno stack TCP/IP, che
richiede l'emissione di un pacchetto RST ad ogni tentativo di connessione su
una porta chiusa, il secondo caso è quello un cui si sia installato un
firewall che scarta i relativi pacchetti. Lo svantaggio di questo metodo è che
può essere rilevato anche soltanto dall'analisi dei file di log, per gli
errori generati dai servizi che rilevano una connessione che viene chiusa
immediatamente dopo l'apertura, senza che ci sia stato nessun traffico.

Come accennato la tecnica di scansione eseguita di default quando si è
amministratori è il \textit{SYN scan}, che viene chiamata anche
\textsl{semi-apertura} (o \textit{half-open}) in quanto si limita a eseguire
la prima parte dell'apertura di una connessione TCP, cioè l'invio di un
pacchetto SYN. Questa tecnica identifica le porte aperte per la risposta
standard di un SYN+ACK, mentre in caso di porta chiusa si avrà l'emissione di
un pacchetto RST. 

Questo metodo non necessita di concludere la connessione, ed alla ricezione
dell'eventuale SYN+ACK il kernel stesso si incaricherà di rispondere con un
RST; questo perché il SYN originale non è stato inviato da un processo
nell'aprire una connessione, ma con un pacchetto creato ad arte da
\texttt{nmap}. Questo significa che il SYN+ACK ottenuto in risposta non
corrisponde a nessuna connessione esistente, per cui il nostro kernel reagirà
secondo lo standard emettendo a sua volta un pacchetto RST interrompendo così
la connessione prima che essa venga stabilita. Il risultato finale è che il
server in ascolto non si accorgerà di niente dato che la connessione non
inizia neanche.  Il problema di questa tecnica di scansione è che è la più
comune e anche i programmi di sorveglianza più semplici, come
\textit{synlogger}, sono in grado di rilevarla.

Per cercare di rendere meno visibili i \textit{portscan} sono state elaborate
altre tecniche che permettono di ottenere lo stesso risultato del \textit{SYN
  scan} usando dei pacchetti TCP con diverse combinazioni dei flag, che non
vengono rilevati dai programmi di sorveglianza più semplici (anche se nessuna
di queste tecniche è efficace con programmi di rilevazione evoluti come
\texttt{snort}) ma permettono di passare attraverso quei firewall che si
limitano a bloccare i pacchetti SYN per le nuove connessioni. Questa significa
anche che tecnica non è comunque efficace con Linux, se si è usato
\texttt{iptables} per bloccare le connessioni entranti utilizzando filtro
sugli stati. 

Tutte queste tecniche di scansione si basano sul fatto che la
standardizzazione del protocollo TCP prescrive che se una porta è chiusa
deve essere emesso un pacchetto RST come risposta a qualunque pacchetto in
arrivo verso di essa, mentre in caso di porta aperta eventuali pacchetti
``\textsl{spuri}'' in arrivo devono essere semplicemente scartati. Questo
permette di distinguere i due casi e riconoscere le porte aperte; se invece si
ricevono dei messaggi di errore (con i relativi pacchetti ICMP) la porta può
considerarsi senz'altro filtrata da un firewall (si potrebbe ottenere questo
comportamento con il target \texttt{REJECT} di \texttt{iptables}) dato che
questo tipo di risposta non è prevista dallo standard del TCP.

Nel caso del cosiddetto \textit{Stealth FIN} (\texttt{-sF}) viene utilizzato
un pacchetto con il solo flag FIN (quello usato per la chiusura di una
connessione), per il cosiddetto \textit{Xmas Tree scan} (\texttt{-sX}) si usa
un pacchetto, illegale dal punto di vista del protocollo, che attiva i flag
FIN, URG e PUSH, mentre per il cosiddetto \textit{Null scan} (\texttt{-sN}) si
usa un pacchetto in cui vengono disattivati tutti i flag. Il programma inoltre
supporta l'opzione \texttt{-{}-scanflags} che permette di usare una qualunque
combinazione di flag del protocollo TCP, anche se non tutte le combinazioni
possono dare risultati utili. Il problema con questo tipo di scansione è che
alcune implementazioni del protocollo TCP (in particolare quella di Windows)
non seguono lo standard e rispondono con dei pacchetti RST anche quando le
porte sono aperte, rendendo inefficace la scansione; in compenso questo
comportamento permette di identificare il sistema operativo.

Una ulteriore variante di scansione è il cosiddetto \textit{Maimon scan}
(\texttt{-sM}), che sfrutta una particolarità delle risposte riscontrate con
alcuni sistemi derivati da BSD scoperta da Uriel Maimon, (la tecnica è
descritta sul numero 49 di \textit{Phrack Magazine}) per i quali in risposta
all'invio di un pacchetto con i flag FIN/ACK non viene sempre inviato il
canonico RST, ma il pacchetto viene scartato in caso di porta aperta,
consentendone così il riconoscimento.

Infine una delle tecniche più sofisticate per il \textit{portscan} su TCP
utilizzata da \texttt{nmap} è quella del cosiddetto \textit{Idle scan}, che
permette di eseguire una scansione completamente anonima, facendo figurare
come sorgente della scansione l'indirizzo IP di una altra macchina usata come
intermediario (che viene chiamata \textit{zombie host}). La tecnica si attiva
con l'opzione \texttt{-sI} seguita dall'IP dello \textit{zombie host}; ;a
scansione usa di default la porta 80 dello \textit{zombie host} per le sue
rivelazioni, si può specificare una porta diversa specificando l'indirizzo di
quest'ultimo come \texttt{indirizzo:porta}.

L'\textit{Idle scan} funziona utilizzando il campo di \textit{fragmentation
  ID} dell'intestazione dei pacchetti IP, che viene usato nella gestione della
frammentazione per identificare, in fase di riassemblaggio, tutti i pacchetti
appartenenti allo stesso pacchetto originario che è stato
frammentato.\footnote{il campo viene usato insieme all'indirizzo IP, se non ci
  fosse si avrebbe la possibilità di ambiguità per pacchetti frammentati
  provenienti dallo stesso IP.} La maggior parte dei sistemi operativi si
limitano ad incrementare questo campo ogni volta che inviano un pacchetto,
cosicché se la macchina non è sottoposta a traffico, è immediato determinarne
e prevederne il valore, basta eseguire un \textit{ping} sulla macchina
bersaglio e leggerlo dai pacchetti di risposta.

Se allora si esegue un \textit{SYN scan} usando come indirizzo IP sorgente
quello dello \textit{zombie host} questo riceverà le risposte al posto nostro,
risposte che saranno un SYN+ACK nel caso di porta aperta (cui risponderà con
un RST, non avendo iniziato la connessione) o un RST in caso di porta chiusa. 
Nel primo caso lo \textit{zombie host} invia un pacchetto, nel secondo no, per
cui osservando il \textit{fragmentation ID} si potrà dedurre la risposta della
macchina sottosta a \textit{portscan}. 

Ovviamente perché questo sia possibile occorre trovare un candidato valido per
fare da \textit{zombie host}, una macchina cioè che presenti una
implementazione dello stack TCP/IP vulnerabile (quasi tutte, fanno eccezione
Linux, Solaris e OpenBSD), e che non presenti traffico; in generale le
stampanti di rete sono dei candidati ideali. La verifica della fattibilità
dell'\textit{Idle scan} viene fatta automaticamente da \texttt{nmap} che
esegue una serie di controlli prima di eseguire la scansione (fermandosi
qualora non sia possibile).

Tutto questo mette in grado un attaccante di eseguire una scansione in maniera
completamente anonima, facendo figurare l'indirizzo di un'altra macchina come
sorgente della stessa. Anche per questo motivo non è mai il caso di
prendersela troppo per un \textit{portscan}, considerato che il soggetto di
una vostra eventuale reazione potrebbe essere a sua volta una vittima.

Alle precedenti tecniche di scansione completa, si aggiungono due tipologie di
scansione che forniscono informazioni parziali, e consentono di capire se una
porta è filtrata o meno tramite la presenza di un firewall. La prima è il
cosiddetto \textit{ACK scan} (\texttt{-sA}), che invia un pacchetto TCP con il
solo flag ACK; in tal caso la risposta prevista dallo standard TCP è un
pacchetto RST, che se ricevuto consente di identificare la porta come non
filtrata (ancorché non si possa stabilire se essa è aperta o chiusa), mentre
l'assenza di risposta, o la risposta con un qualsiasi altro messaggio di
errore via ICMP è indice della presenza di un qualche meccanismo di
filtraggio. 

Come variante del precedente si può usare il cosiddetto \textit{Window scan}
(\texttt{-sW}) che consente di riconoscere in caso di risposta con un
pacchetto RST se la porta è aperta o meno, grazie al fatto che alcuni sistemi
restituiscono nel pacchetto RST un valore positivo per la dimensione della
finestra TCP\footnote{la \textit{Window size} è una delle informazioni
  inserite nei pacchetti TCP che serve ad indicare all'altro capo della
  connessione quanti byte di dati si vorrebbero ricevere, in modo da
  ottimizzare le trasmissioni.} se la porta è aperta, o nullo se la porta è
chiusa.

Le tecniche di scansione illustrate fino a qui riguardano soltanto il
protocollo TCP, esistono comunque anche servizi forniti su UDP, ed
\texttt{nmap} consente di eseguire una scansione anche su di essi con
l'opzione \texttt{-sU}. La tecnica consiste nell'inviare pacchetti UDP di
lunghezza nulla su ogni porta, ma si può anche mandare un pacchetto di
dimensione fissa con dati casuali usando l'opzione aggiuntiva
\texttt{-{}-data-length}. Se la porta è chiusa la risposta dovrebbe essere un
pacchetto ICMP di tipo \textit{port unreachable}, altrimenti si assume che la
porta sia aperta o filtrata da un firewall; per alcune porte (53/DNS,
161/SMTP) vengono però usati pacchetti di test specifici per il relativo
protocollo, che possono permettere di capire se la porta è aperta o meno
ottenendo una risposta.

Questa tecnica di rilevazione però non è molto affidabile per una serie di
motivi: anzitutto se un firewall blocca i pacchetti ICMP \textit{port
  unreachable} di risposta tutte le porte figureranno come aperte o filtrate;
lo stesso problema si presenta se ad essere bloccati dal firewall sono i
pacchetti UDP indirizzati verso le porte di destinazione. In entrambi i casi
non si riceverà risposta, ma non si potrà concludere in maniera certa che il
servizio è attivo e le porte pertanto potranno risultare o aperte o filtrate.

La scansione inoltre può risultare particolarmente lenta in quanto alcuni
sistemi operativi limitano il numero di pacchetti ICMP di tipo
\textit{destination unreachable}\footnote{un pacchetto ICMP \textit{port
    unreachable} è uno dei diversi possibili pacchetti di tipo
  \textit{destination unreachable}.} che possono essere emessi (nel caso di
Linux c'è un massimo di 1 al secondo, con Windows invece il limite non
esiste). Anche se \texttt{nmap} è in grado di rilevare questo comportamento ed
evitare l'invio di pacchetti che comunque non riceverebbero risposta, questo
comunque rallenta di molto la scansione e per esempio per ottenere il seguente
risultato si è dovuto aspettare circa una ventina di minuti:
\begin{Console}
# \textbf{nmap -sU 192.168.1.2}
Starting Nmap 5.21 ( http://nmap.org ) at 2011-04-05 12:34 CEST
Nmap scan report for davis.fi.trl (192.168.1.2)
Host is up (0.00080s latency).
Not shown: 995 closed ports
PORT     STATE         SERVICE
53/udp   open          domain
67/udp   open|filtered dhcps
111/udp  open          rpcbind
123/udp  open          ntp
2049/udp open          nfs
MAC Address: 52:54:00:D3:BD:31 (QEMU Virtual NIC)

Nmap done: 1 IP address (1 host up) scanned in 1066.72 seconds
\end{Console}

Con la versione 5 di \texttt{nmap} è inoltre possibile effettuare scansioni
anche con il nuovo protocollo SCTP, anche se queste restano meno utili in
quanto detto protocollo non è molto utilizzato. Per queste scansioni sono
previste due apposite opzioni, \texttt{-sY} che effettua un \textit{SCTP INIT
  scan}, analogo al \textit{SYN scan}, ed \texttt{-sZ} che effettua un
\textit{SCTP COOKIE ECHO scan}, usando una modalità di rilevamento più occulta
ma meno affidabile. Un esempio, di scarso interesse non essendovi servizi
attivi, è il seguente:
\begin{Console}
# \textbf{nmap -sY 192.168.1.4}
Starting Nmap 5.21 ( http://nmap.org ) at 2011-04-05 19:13 CEST
Nmap scan report for parker.fi.trl (192.168.1.4)
Host is up (0.00012s latency).
All 42 scanned ports on parker.fi.trl (192.168.1.4) are filtered
MAC Address: 00:0E:A6:F4:DA:AA (Asustek Computer)

Nmap done: 1 IP address (1 host up) scanned in 1.69 seconds
\end{Console}

L'ultima tecnica di scansione vera e propria è quella che permette di rilevare
il supporto per ulteriori protocolli trasportati direttamente su IP (oltre ai
classici TCP e UDP ed al nuovo SCTP) pur non essendo propriamente un
\textit{portscan}, dato che si esegue la scansione sul numero di protocollo
dell'intestazione IP e non su un numero di porta, che non esiste per
protocolli che non fan parte del livello di trasporto. Questa viene scansione
viene attivata con l'opzione \texttt{-sO}, e viene eseguita inviando pacchetti
IP vuoti, con la sola indicazione del protocollo nell'intestazione (con
l'eccezione dei protocolli TCP, UDP, ICMP, SCTP, e IGMP per i quali esistono
appositi pacchetti di prova).

Se il protocollo non è implementato la risposta prevista dallo standard è la
restituzione un pacchetto ICMP \textit{protocol unreachable}, che comporta la
classificazione del protocollo come chiuso, se si riceve una qualche altra
risposta lo si classifica come aperto, mentre in caso di ricezione di un tipo
diverso di pacchetto ICMP di \textit{destination unreachable} lo si marca come
filtrato. Se non si riceve alcuna risposta lo stato è indefinito ed il
protocollo è marcato come filtrato o chiuso. Dato che di nuovo è necessario
osservare una risposta di tipo \textit{destination unreachable} valgono le
precedenti osservazioni fatte riguardo la scansione su UDP (cioè che la
scansione è lenta). Un esempio del risultato è il seguente:
\begin{Console}
# \textbf{nmap -sO 192.168.1.2}
Starting Nmap 5.21 ( http://nmap.org ) at 2011-04-05 12:58 CEST
Nmap scan report for davis.fi.trl (192.168.1.2)
Host is up (0.00089s latency).
Not shown: 248 closed protocols
PROTOCOL STATE         SERVICE
1        open          icmp
2        open|filtered igmp
6        open          tcp
17       open          udp
103      open|filtered pim
136      open|filtered udplite
138      open|filtered unknown
253      open|filtered experimental1
MAC Address: 52:54:00:D3:BD:31 (QEMU Virtual NIC)

Nmap done: 1 IP address (1 host up) scanned in 277.58 seconds
\end{Console}

Si noti come nei risultati dei \textit{portscan} illustrati finora,
\texttt{nmap} faccia riferimento ad uno stato delle porte per cui ha
effettuato una scansione; i nomi di questi stati, ed il relativo significato,
sono riportati in tab.~\ref{tab:nmap_states}.  I risultati più comuni per la
scansione di una porta sono due, che questa risulti chiusa (\texttt{closed}) o
bloccata da un firewall (\texttt{filtered}). Il primo caso è quello che si
ottiene normalmente per le macchine a cui si ha accesso diretto (ad esempio
quelle sulla propria rete locale) mentre il secondo è comune per le macchine
direttamente esposte su Internet, che sono di solito protette da un firewall.

Come si può notare negli esempi precedenti \texttt{nmap} riporta sempre (nella
riga ``\texttt{Not shown:}'') un riassunto esplicativo dello stato delle porte
per le quali non ha ottenuto nessuna informazione significativa, mentre elenca
esplicitamente soltanto le porte aperte o non filtrate. In alcuni casi, quando
il programma non è in grado di determinare un risultato possono anche essere
riportati più stati. In realtà le possibili ambiguità sono solo
due:\footnote{nella documentazione di \texttt{nmap} queste due situazioni sono
  considerate come altri due stati.} si può ottenere \texttt{open|filtered}
nelle scansioni in cui è possibile non ricevere risposta anche se la porta è
aperta (ad esempio con UDP), ed in questo caso l'assenza di risposta ha lo
stesso risultato di un firewall che scarta i pacchetti. Si può invece ottenere
\texttt{closed|filtered} solo con l'\textit{Idle scan} quando il programma non
è in grado di distinguere fra una porta chiusa ed una filtrata.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|p{8cm}|}
    \hline
    \textbf{Stato}&\textbf{Significato}\\
    \hline
    \hline
    \texttt{open}       & la porta è raggiungibile ed è stato rilevato un
                          programma in ascolto su di essa con cui è possibile
                          interagire.\\
    \texttt{closed}     & la porta è raggiungibile ma nessun programma è in
                          ascolto su di essa.\\
    \texttt{filtered}   & la porta non è raggiungibile a causa della presenza
                          di un meccanismo di filtraggio (firewall o altro)
                          che non consente di determinare niente al suo
                          riguardo.\\
    \texttt{unfiltered} & la porta è raggiungibile, ma \texttt{nmap} non è in
                          grado di determinare se sia aperta o chiusa.\\
    \hline
  \end{tabular}
  \caption{Gli stati riportati da \texttt{nmap}.} 
\label{tab:nmap_states}
\end{table}

Si tenga presente inoltre che \texttt{nmap} considera come filtrate sia le
porte per le quali non riceve risposta (ad esempio perché il firewall scarta
tutti i pacchetti ad esse inviati) o per le quali riceve una risposta che le
qualifica come tale (un ICMP di \textit{destination unreachable} con codice
\textit{communication administratively prohibited}), o non coerente con quanto
dettato dagli standard (ad esempio pacchetti ICMP con codice non
corrispondente a quello che ci si aspetterebbe), indice di una risposta
generata da un sistema di protezione, come quelle che si possono far generare
a \texttt{iptables} con il target \texttt{REJECT}.

Nonostante quel che possa pensare chi cerca di nascondere la presenza di un
firewall con questo tipo di accorgimenti, di queste due possibili situazioni
la più frustrante per un attaccante è la prima, perché rende la scansione
molto più difficile e lenta, in quanto \texttt{nmap} per essere sicuro che
l'assenza di risposta è reale e non dovuta a problemi di rete, deve ripetere
vari tentativi di accesso. Visto poi che nascondere la presenza di un firewall
non sorte nessun effetto maggiore di sicurezza, e comporta un carico
amministrativo maggiore, l'uso di questa pratica non ha poi molto senso.

Altre opzioni classificate fra quelle di tab.~\ref{tab:nmap_scan_options},
piuttosto che eseguire una scansione vera e propria, servono ad indicare la
richiesta di ulteriori controlli. Una di queste è \texttt{-sR}, che invia su
ogni porta trovata aperta dei comandi RPC nulli; in questo modo è possibile
determinare quali di queste porte sono associate ad un servizio
RPC.\footnote{La sigla RPC (\textit{Remote Procedure Call}) indica una
  tipologia di servizi che viene utilizzata per fornire ai programmi la
  possibilità di eseguire delle ``\textsl{funzioni remote}'' (cioè chiamate da
  una macchina, ma eseguite su un'altra) attraverso una opportuna interfaccia;
  sono caratterizzati dall'usare porte allocate dinamicamente, il cui valore è
  desumibile contattando un apposito servizio, il \textit{portmapper}, che
  ascolta sempre sulla porta 111.}  L'opzione può essere attivata per gli scan
TCP ed UDP, e se usata da sola implica un \textit{SYN scan}. Un esempio del
risultato dell'uso di questa opzione è il seguente:
\begin{Console}
# \textbf{nmap -sR 192.168.1.2}
Starting Nmap 5.21 ( http://nmap.org ) at 2011-04-06 11:17 CEST
Nmap scan report for davis.fi.trl (192.168.1.2)
Host is up (0.0040s latency).
Not shown: 990 closed ports
PORT     STATE SERVICE              VERSION
22/tcp   open  unknown
25/tcp   open  unknown
53/tcp   open  unknown
80/tcp   open  unknown
111/tcp  open  rpcbind (rpcbind V2) 2 (rpc #100000)
443/tcp  open  unknown
636/tcp  open  unknown
2049/tcp open  nfs (nfs V2-4)       2-4 (rpc #100003)
3306/tcp open  unknown
9102/tcp open  unknown
MAC Address: 52:54:00:D3:BD:31 (QEMU Virtual NIC)

Nmap done: 1 IP address (1 host up) scanned in 1.42 seconds
\end{Console}

Con l'opzione \texttt{-sV} invece si richiede, una volta eseguita la
scansione, un tentativo di connessione sui servizi trovati attivi per
determinare, sulla base delle risposte ottenute, una versione che verrà poi
stampata all'interno del risultato della scansione. Questa opzione ricomprende
anche i risultati di \texttt{-sR} che pertanto oggi è praticamente
inutilizzata. L'opzione \texttt{-sV} può essere abbinata a qualunque scansione
delle porte, e supporta anche una serie di opzioni ausiliarie che controllano
il comportamento del sistema di rilevamento di versione, per le quali si
rimanda alla pagina di manuale; se non ne viene specificata nessuna tipologia
di scansione verrà eseguito un \textit{SYN scan}. Un esempio dell'uso di
questa opzione è il seguente:
\begin{Console}
# \textbf{nmap -sV 192.168.1.4}
Starting Nmap 5.21 ( http://nmap.org ) at 2011-04-06 11:44 CEST
Nmap scan report for parker.fi.trl (192.168.1.4)
Host is up (0.00011s latency).
Not shown: 993 closed ports
PORT     STATE SERVICE     VERSION
22/tcp   open  ssh         OpenSSH 5.1p1 Debian 5 (protocol 2.0)
25/tcp   open  smtp        Postfix smtpd
80/tcp   open  http        Apache httpd 2.2.9 ((Debian))
111/tcp  open  rpcbind     2 (rpc #100000)
631/tcp  open  ipp         CUPS 1.3
2000/tcp open  cisco-sccp?
6566/tcp open  unknown
MAC Address: 00:0E:A6:F4:DA:AA (Asustek Computer)
Service Info: Host:  parker.truelite.it; OS: Linux

Service detection performed. Please report any incorrect results at http://nmap.
org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 11.22 seconds
\end{Console}

La più sofisticata fra le opzioni per la richiesta di scansioni aggiuntive è
però \texttt{-sC}, che richiede l'intervento dell'\textit{Nmap Scripting
  Engine} che consente di far eseguire sulle porte identificate da
\texttt{nmap} tutte le operazioni aggiuntive che si vogliono tramite opportuni
script in LUA, in questo modo ad esempio diventa possibile eseguire un
programma di password cracking su una porta aperta, o effettuare ulteriori
operazioni di scansione per informazioni relative al servizio presente su di
essa.

Con \texttt{nmap} vengono forniti anche una serie di script
``\textsl{ufficiali}'' elaborati all'interno del progetto, e si può
controllare quali di questi devono essere eseguiti con l'opzione
\texttt{-{}-script}. Se non si indica nulla vengono eseguiti gli script di
default (l'opzione \texttt{-sC} è equivalente ad usare
\texttt{-{}-script=default}) altrimenti si può specificare con questa opzione
una lista (in elenco separato da virgole) di nomi di file, directory,
categorie di script da eseguire, si possono anche specificare delle
espressioni complesse con gli operatori logici \texttt{not}, \texttt{and} e
\texttt{or} ed utilizzare i caratteri jolly.

In genere gli script sono installati in una directory di default,\footnote{su
  Debian è \texttt{/usr/share/nmap/scripts}} usata anche come base per i
pathname relativi, ma se ne può specificare un'altra con l'opzione
\texttt{-{}-datadir}. Quando si indica una directory vengono usati come script
tutti i file con estensione \texttt{.nse}. Un esempio di invocazione del
comando potrebbe essere:
\begin{Console}
# \textbf{nmap -sC 192.168.1.4}
Starting Nmap 5.21 ( http://nmap.org ) at 2011-12-23 21:00 CET
Nmap scan report for parker.fi.trl (192.168.1.4)
Host is up (0.00037s latency).
Not shown: 993 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
| ssh-hostkey: 1024 98:98:89:2b:fc:3f:09:e8:37:06:28:34:77:f0:a6:bc (DSA)
|_2048 26:f6:d3:cb:64:85:88:e3:c5:7a:9a:fc:09:84:cf:94 (RSA)
25/tcp   open  smtp
|_smtp-commands: EHLO parker.truelite.it, PIPELINING, SIZE 10240000, VRFY, ETRN,
 STARTTLS, ENHANCEDSTATUSCODES, 8BITMIME, DSN
80/tcp   open  http
|_html-title: Site doesn't have a title (text/html).
111/tcp  open  rpcbind
| rpcinfo:  
| 100000  2    111/udp  rpcbind  
| 100024  1  32768/udp  status   
| 100000  2    111/tcp  rpcbind  
| 391002  2    826/tcp  sgi_fam  
|_100024  1  44427/tcp  status   
631/tcp  open  ipp
2000/tcp open  cisco-sccp
6566/tcp open  unknown
MAC Address: 00:0E:A6:F4:DA:AA (Asustek Computer)

Nmap done: 1 IP address (1 host up) scanned in 2.10 seconds
\end{Console}

% TODO, aggiungere maggiori informazioni sugli script

Esistono infine altre due opzioni di \texttt{nmap} che pur essendo elencate in
tab.~\ref{tab:nmap_scan_options} non effettuano una vera scansione, ma cercano
solo di elencare le macchine presenti: con \texttt{-sL} viene semplicemente
fatta una lista di tutti gli indirizzi che corrispondono alle specifiche degli
argomenti del comando, con relativa, se presente, risoluzione inversa degli
stessi. In questo caso non viene inviato nessun pacchetto verso le
destinazioni finali, ma talvolta si possono ottenere informazioni interessanti
anche solo per i nomi.

Leggermente più sofisticata è l'opzione \texttt{-sP} con cui \texttt{nmap} si
limitata a cercare di verificare la presenza di una macchina sulla rete, senza
eseguire nessuna scansione. Da questo deriva il nome \textit{Ping scan} dato a
questa opzione, in quanto lo scopo dell'operazione diventa identico a quello
del comando \texttt{ping}. Si tenga presente che tutte le volte che si
richiede una scansione effettiva, viene comunque effettuato preventivamente un
controllo sulla effettiva raggiungibilità di una macchina corrispondente ad un
certo indirizzo; questa opzione si limita a riportare solo i risultati di
detto controllo, senza poi effettuare la scansione.

Dato che la rilevazione della presenza o meno di una macchina attiva su un
certo indirizzo può andare incontro a problemi, \texttt{nmap} prevede una
serie di metodi di rilevazione, che possono essere attivati con le varie
opzioni illustrate in tab.~\ref{tab:nmap_ping_options}. L'uso dei normali
pacchetti ICMP \textit{echo request} (quelli usati da \texttt{ping}) può
infatti risultare inefficace, per il fatto che molti amministratori di sistema
disabilitano la risposta o filtrano questi pacchetti in varie maniere.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|l|}
    \hline
    \textbf{Opzione}&\textbf{Descrizione}\\
    \hline
    \hline
    \texttt{-P0} & Deprecato nelle nuove versioni, usare \texttt{-PN}.\\ 
    \texttt{-PN} & Disabilita la rilevazione di attività.\\ 
    \texttt{-PT} & Usa il \textit{TCP ping} (deprecata in favore di
                   \texttt{-PS} e \texttt{-PA}).\\ 
    \texttt{-PS} & Usa un pacchetto TCP con flag SYN attivo.\\ 
    \texttt{-PA} & Usa un pacchetto TCP con flag ACK attivo.\\ 
    \texttt{-PU} & Usa un pacchetto di prova basato su UDP.\\ 
    \texttt{-PE} & Usa un pacchetto ICMP \textit{echo request} (un normale
                   \textit{ping}).\\ 
    \texttt{-PP} & Usa una pacchetto ICMP \textit{timestamp request}.\\ 
    \texttt{-PM} & Usa una pacchetto ICMP \textit{netmask request}.\\ 
    \texttt{-PO} & Usa dei pacchetti vuoti di alcuni protocolli IP.\\ 
    \texttt{-PY} & Usa un pacchetto SCTP con un \textit{chunk} INIT
                   minimale.\\  
    \texttt{-PR} & Usa una richiesta ARP (se il bersaglio è sulla propria
                   LAN).\\   
%    \texttt{-PB} & È il metodo di default, è la combinazione di \texttt{-PE} e
%                   \texttt{-PT}.\\   % rimosso, pare ...
    \hline
  \end{tabular}
  \caption{Opzioni di \texttt{nmap} per l'indicazione delle modalità di
    rilevamento dell'attività di una macchina.} 
\label{tab:nmap_ping_options}
\end{table}

Con le versioni recenti del comando se il bersaglio è nella propria rete
locale \texttt{nmap} esegue sempre la ricerca con una semplice richiesta di
ARP, dato che questa sarebbe preliminare all'invio di qualunque altro
pacchetto di rete. Anche qualora si specificassero esplicitamente delle
opzioni di ricerca queste verrebbero ignorate essendo la risposta alla
richiesta di ARP sufficiente a determinare la disponibilità della macchina
cercata.

Qualora invece il bersaglio sia posto al di fuori della propria rete locale la
ricerca viene eseguita utilizzando sia i normali pacchetti ICMP \textit{echo
  request}, che attraverso il cosiddetto \itindex{TCP~ping} \textit{TCP
  ping}. Nelle versioni recenti del programma se non si specifica niente viene
usata una combinazione di varie tecniche: per la precisione un \textit{ICMP
  echo request}, un SYN sulla porta 443, un ACK sulla porta 80, ed un
\textit{ICMP timestamp request}, corrispondenti alla combinazione di opzioni
\texttt{-PE -PS443 -PA80 -PP}.

Le modalità di rilevazione possono comunque essere modificate qualunque sia la
tecnica di scansione utilizzata,\footnote{fa eccezione l'\textit{Idle scan},
  in tal caso infatti effettuare una rilevazione porterebbe a far conoscere al
  bersaglio il nostro indirizzo IP, quando invece si sta usando una opzione
  che serve a nasconderlo, pertanto in tal caso \texttt{nmap} si ferma
  avvisando dell'incoerenza e suggerendo l'uso di \texttt{-PN} o \texttt{-P0}
  a seconda della versione.}  con le opzioni illustrate in
tab.~\ref{tab:nmap_ping_options}, che possono essere usate anche in
combinazione fra di loro. Specificando cioè una o più di queste opzioni
saranno usate le relative tecniche di rilevazione, e si considererà attiva una
macchina che risponda ad almeno una di esse.  Si possono anche disabilitare
del tutto le operazioni di rilevazione con l'opzione \texttt{-P0} (deprecata
nelle versioni più recenti in favore di \texttt{-PN}).

La principale modalità alternativa di rilevazione era \texttt{-PT}, usata per
indicare l'utilizzazione del cosiddetto \textit{TCP ping}. Questo consiste
nell'inviare un pacchetto TCP con il flag ACK attivo su una porta non
filtrata. Se si riceve un RST in risposta significa che la macchina è attiva,
e dato che in genere la porta 80 non viene mai filtrata non specificando nulla
questa è quella usata di default. L'opzione funziona anche per utenti senza
privilegi di amministratore, nel qual caso invece di un pacchetto ACK viene
usata una normale connessione.

Nelle versioni recenti di \texttt{nmap} però \texttt{-PT} è deprecata in
quanto il \textit{TCP ping} è stato suddiviso in due diverse opzioni,
\texttt{-PA}, per il cosiddetto \textit{TCP ACK ping}, che è equivalente a
\texttt{-PT}, e \texttt{-PS} per il cosiddetto \textit{TCP SYN ping}, in cui
al posto di un ACK viene usato un SYN, che riesce pertanto a passare
attraverso firewall \textit{stateful} che scarterebbe in quanto non validi i
pacchetti con un ACK iniziale.

Con l'opzione \texttt{-PU} si effettua la rilevazione inviando un pacchetto
UDP vuoto alla porta o alla lista di porte indicate, a meno di non specificare
una lunghezza di dati con l'opzione addizionale \texttt{-{}-data-length},
valida anche per \texttt{-PO}. Il protocollo prevede che se la porta non è
aperta venga emesso in risposta un pacchetto ICMP \textit{port unreachable} in
risposta.  Dato che molti servizi non rispondono quando ricevono pacchetti
vuoti il modo più affidabile per utilizzare questa tecnica è di utilizzare
porte che si sanno essere chiuse, in modo da avere il messaggio di errore in
risposta. La tecnica infatti serve a rilevare l'attività di una macchina, non
l'apertura di una porta (per questo di default viene usata la porta 40125 che
è altamente improbabile venga usata da qualche servizio). L'assenza di
risposte comunque non è significativa, dato che un firewall può filtrare i
pacchetti UDP.

Con il supporto per il protocollo SCTP le versioni recenti consentono di
effettuare una rilevazione sfruttando anche questo con l'opzione \texttt{-PY},
in questo caso viene inviato un pacchetto minimale di tipo INIT sulla porta
80, se questa è chiusa verrà risposto con un pacchetto di ABORT altrimenti
verrà inviato INIT-ACK,\footnote{se il sistema operativo della macchina su cui
  gira \texttt{nmap} supporta il protocollo (come avviene con Linux), il
  kernel genererà una direttamente un risposta di ABORT.} in entrambi i casi
\texttt{nmap} potrà concludere che la macchina è attiva. 

In tutti questi controlli eseguiti tramite porte si può richiedere, al posto
del default, l'uso di un numero di porte qualsiasi da aggiungere come
parametri in forma di lista separate da virgole di numeri di porta singoli, o
di intervalli separati con il carattere ``\texttt{-}''.  Un esempio di uso di
queste opzioni potrebbe essere allora ``\texttt{-PS80,25,443}'' o
``\texttt{-PA110,20-23}''. La sintassi richiede che non vi siano spazi fra
l'opzione e la susseguente lista, né all'interno di questa.

Sulle versioni recenti del comando è inoltre presente l'opzione \texttt{-PO}
con si può effettuare la rilevazione inviando dei pacchetti vuoti di alcuni
protocolli incapsulati in IP; se non si specifica nulla vengono usati dei
pacchetti vuoti dei protocolli ICMP, IGMP e IPIP, ma si può specificare una
lista per numeri o nome. I pacchetti generati, a parte ICMP, IGMP, TCP ed UDP,
contengono soltanto l'indicazione del protocollo a livello di IP e nessuna
ulteriore intestazione. Il rilevamento avviene qualora si riceva una risposta
dello stesso protocollo o un pacchetto ICMP \textit{protocol unreachable}.

Le altre tecniche di rilevamento utilizzano tutte pacchetti ICMP: con
l'opzione \texttt{-PE} si attiva l'uso del classico ICMP \textit{echo
  request}, come alternative si possono usare \texttt{-PP} che utilizza un
ICMP \textit{timestamp request} e \texttt{-PM} che utilizza un ICMP
\textit{netmask request}. Per ciascuno di questi pacchetti lo standard prevede
un opportuno pacchetto di risposta, che indica che la macchina interrogata è
attiva.  Il problema comune di queste tecniche è che molti firewall non fanno
passare questo tipo di pacchetti, rendendo impossibile la rilevazione. 

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|p{8cm}|}
    \hline
    \textbf{Parametro}&\textbf{Descrizione}\\
    \hline
    \hline
    \texttt{Paranoid}  & Esegue una scansione serializzata, con intervalli di 5
                         minuti fra l'invio di un pacchetto ed un altro, per
                         cercare di sfuggire alla rilevazione di eventuali
                         NIDS eseguendo la scansione in modalità estremamente
                         lenta.\\
    \texttt{Sneaky}    & È analoga alla precedente, ma l'intervallo fra i
                         pacchetti è impostato a 15 secondi, rendendola un po'
                         meno insopportabilmente lenta.\\  
    \texttt{Polite}    & Cerca di eseguire una scansione in maniera
                         \textsl{gentile}, evitando di caricare in maniera
                         eccessiva la rete bersaglio: serializza i pacchetti c
                         con un intervallo di 0.4 secondi fra l'uno e
                         l'altro.\\   
    \texttt{Normal}    & É l'opzione di default, parallelizza la scansione,
                         con l'obiettivo di essere il più veloci possibile ma
                         al cercando al contempo di mantenere limitato il  
                         carico sulla rete bersaglio.\\ 
    \texttt{Aggressive}& Questa opzione rende alcune scansioni (in particolare
                         il \textit{SYN scan}) nettamente più veloci, ma 
                         carica in maniera massiccia la rete.\\ 
    \texttt{Insane}    & Mira alla massima velocità possibile, anche a scapito
                         dell'accuratezza, richiede una connessione molto
                         veloce.\\  
    \hline
  \end{tabular}
  \caption{Valori dei parametri per l'opzione \texttt{-T} di \texttt{nmap}.} 
\label{tab:nmap_time_options}
\end{table}

Un'altra classe di opzioni è quella relativa al controllo delle
temporizzazioni utilizzate nell'eseguire una scansione, (le attese per le
risposte, i \textit{timeout}, la frequenza dell'emissione dei pacchetti,
ecc.). L'elenco completo delle opzioni, che permettono un controllo completo
di tutte le tempistiche, è disponibile nella pagina di manuale, fra queste ci
limitiamo a segnalare solo l'opzione generica \texttt{-T} che permette di
specificare, attraverso un ulteriore parametro fra quelli indicati in
tab.~\ref{tab:nmap_time_options}, una serie di \textsl{politiche} di
scansione, che impostano dei valori predefiniti per le varie temporizzazioni,
secondo quanto descritto nella tabella citata.

Infine \texttt{nmap} supporta una serie di opzioni generali, non
classificabili in nessuna delle categorie precedenti, le più significative
delle quali sono riportate in tab.~\ref{tab:nmap_generic_options}. Molte
di queste sono volte ad attivare funzionalità che rendano più difficile
riconoscere l'esecuzione di un \textit{portscan}, o la sorgente dello stesso. 
Al solito per la documentazione completa si può fare riferimento alla pagina
di manuale. 

Una prima opzione generale che vale la pena di citare è \texttt{-p}, che
permette di indicare l'insieme di porte da controllare, l'opzione richiede un
parametro ulteriore che specifichi detto insieme la cui sintassi prevede sia
una lista di porte singole (separate da virgole) che un intervallo fra due
estremi separati da un meno, che una combinazione di entrambi.  Il default è
controllare ogni porta fra 1 e 1024, più tutte quelle elencate nella lista dei
servizi allegata al pacchetto, usualmente mantenuta in
\texttt{/usr/share/nmap/nmap-services}.  Qualora la scansione coinvolga sia
TCP che UDP si possono specificare degli insiemi separatamente apponendo i
parametri ``\texttt{T:}'' e ``\texttt{U:}'', un esempio di valore possibile è
\texttt{-p T:1-48000,U:0-1024}.

Una seconda opzione significativa è \texttt{-D} che permette di specificare
una lista di indirizzi IP (separati da virgole) da usare come esca per
mascherare l'effettiva provenienza del \textit{portscan}; nella lista può
essere inserito il valore \texttt{ME} per indicare la posizione in cui si
vuole che venga inserito il proprio indirizzo, altrimenti questa sarà scelta
casualmente. Si tenga presente che i provider più attenti filtrano i pacchetti
in uscita con indirizzi falsificati, per cui il tentativo può fallire; inoltre
alcuni programmi di rilevazione dei \textit{portscan} non troppo intelligenti
reagiscono automaticamente bloccando il traffico verso gli IP da cui vedono
provenire un \textit{portscan}, il che può permettervi di causare un
\itindex{Denial~of~Service~(DoS)} \textit{Denial of Service}, che può
diventare ancora più pesante se fra gli indirizzi suddetti immettete anche il
localhost.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|p{8cm}|}
    \hline
    \textbf{Opzione}&\textbf{Descrizione}\\
    \hline
    \hline
    \texttt{-f} & attiva la frammentazione dei pacchetti usati per gli scan su
                  TCP. L'intestazione del protocollo viene suddivisa in tanti
                  pacchetti molto piccoli per cercare di sfuggire alla
                  rilevazione da parte di eventuali NIDS o al filtro dei
                  firewall.\footnotemark\\ 
    \texttt{-v} & aumenta le informazioni stampate e tiene al corrente dello
                  stato della scansione, usata una seconda volta stampa ancora
                  più informazioni.\\ 
    \texttt{-A} & abilita le funzionalità che la pagina di manuale identifica
                  come ``\textsl{addizionali, avanzate o aggressive}'' (a
                  seconda dei gusti). In sostanza una abbreviazione per una
                  serie di altre opzioni come \texttt{-sV} o \texttt{-O}.\\ 
    \texttt{-6} & abilita il supporto per IPv6.\\ 
    \texttt{-p} & permette di specificare una lista delle porte da
                  analizzare nella scansione.\\
    \texttt{-D} & permette di specificare una lista di indirizzi IP da usare
                  come esca per mascherare l'effettiva provenienza del
                  \textit{portscan}.\\
    \texttt{-g} & permette di impostare la porta sorgente (da specificare come
                  parametro) nei pacchetti usati per la scansione.\\  
    \texttt{-n} & blocca la risoluzione degli indirizzi (e la presenza di
                  tracce sui DNS dei bersagli).\\ 
    \hline
  \end{tabular}
  \caption{Principali opzioni generiche di \texttt{nmap}.} 
\label{tab:nmap_generic_options}
\end{table}

\footnotetext{questo non è efficace con NIDS e firewall evoluti come
  \texttt{snort} o il \textit{netfilter} di Linux che riassemblano i pacchetti
  prima di esaminarli; inoltre questi pacchetti di dimensioni ridotte possono
  causare il crash di quei sistemi operativi non in grado di gestirli.} 

Un'ultima nota specifica va dedicata all'opzione \texttt{-O}, che attiva il
meccanismo per l'identificazione del sistema operativo del bersaglio
attraverso la rilevazione della cosiddetta \textit{TCP/IP fingerprint}; un
esempio di questo tipo di scansione (dove si è usata anche l'opzione
\texttt{-v} per incrementare la stampa delle informazioni ottenute) è il
seguente:
\begin{Console}
# \textbf{nmap -O -v 192.168.1.141}
Starting nmap 3.75 ( http://www.insecure.org/nmap/ ) at 2004-12-01 15:25 CET
Initiating SYN Stealth Scan against localhost (127.0.0.1) [1663 ports] at 15:25
Discovered open port 25/tcp on 127.0.0.1
Discovered open port 22/tcp on 127.0.0.1
Discovered open port 631/tcp on 127.0.0.1
The SYN Stealth Scan took 0.18s to scan 1663 total ports. 
For OSScan assuming port 22 is open, 1 is closed, and neither are firewalled
Host localhost (127.0.0.1) appears to be up ... good. 
Interesting ports on localhost (127.0.0.1):
(The 1660 ports scanned but not shown below are in state: closed)
PORT    STATE SERVICE
22/tcp  open  ssh
25/tcp  open  smtp
631/tcp open  ipp
Device type: general purpose
Running: Linux 2.4.X|2.5.X|2.6.X
OS details: Linux 2.5.25 - 2.6.3 or Gentoo 1.2 Linux 2.4.19 rc1-rc7)
Uptime 11.871 days (since Fri Nov 19 18:31:51 2004)
TCP Sequence Prediction: Class=random positive increments
                         Difficulty=4416598 (Good luck!) 
IPID Sequence Generation: All zeros

Nmap run completed -- 1 IP address (1 host up) scanned in 2.332 seconds
\end{Console}

In sostanza \texttt{nmap} esegue una analisi delle risposte inviate ad una
serie di pacchetti di prova per identificare le caratteristiche dello stack
TCP/IP del sistema che risponde, identificandolo rispetto ad una serie di
risposte note.  Come si vede l'opzione permette di determinare (dai tempi
inseriti nei pacchetti) l'uptime del sistema analizzato, di verificare il
meccanismo di generazione del campo \textit{fragmentation ID} e capire se il
bersaglio è utilizzabile per un \textit{Idle scan} (qualora venga riportato il
valore \texttt{incremental}). Infine l'opzione misura la predicibilità dei
numeri di sequenza dello stack TCP, un indice di quanto può essere
difficoltoso creare dei pacchetti artefatti per inserirsi su una connessione. 

\itindend{portscanner}

\subsection{Gli \textit{sniffer}}
\label{sec:ids_sniffer}

\itindbeg{sniffer}
 
Uno \textit{sniffer} è un programma utilizzato per leggere ed analizzare tutto
il traffico di rete che arriva ad una certa macchina. In genere uno sniffer è
utilizzato da chi può avere acceso alla rete locale per osservarne il
traffico.  Il nome è dovuto all'uso di questi programmi per
``\textsl{annusare}'' le password inviate in chiaro sulle connessioni, ma oggi
il loro utilizzo in tal senso (con la diffusione di SSH e della cifratura
delle connessioni) è drasticamente ridotto.

In compenso uno \textit{sniffer} resta uno strumento indispensabile per
l'analisi del traffico su una rete, ed in genere un NIDS non è altro che uno
sniffer molto sofisticato in grado di individuare automaticamente il traffico
sospetto.  Ma al di là della sicurezza uno \textit{sniffer} ha moltissimi
altri impieghi, a partire da quello didattico di poter mostrare il flusso dei
pacchetti per capire il funzionamento dei protocolli di rete, a quello di
individuare le fonti di maggior \textit{rumore} su una rete, ed isolarle e
rimuoverle per aumentarne l'efficienza.

In genere uno \textit{sniffer} opera direttamente al livello di collegamento
fisico della rete, che nella stragrande maggioranza dei casi è realizzato
attraverso il protocollo \textit{ethernet}. Una delle caratteristiche delle
schede ethernet è che esse di norma leggono soltanto il traffico diretto a
loro (che corrisponde cioè al \textit{MAC address} della scheda) o inviato in
\textit{broadcast} su tutta la rete locale. Le schede sono però anche in grado
di lavorare nella cosiddetta \textsl{modalità promiscua} (il cosiddetto
``\textit{promiscuous mode}'' dell'interfaccia) leggendo tutto il traffico che
vedono passare.

Inizialmente le reti locali basate su ethernet erano costituite da tante
schede interconnesse fra loro attraverso un unico cavo BNC, sostituito in
seguito da singoli cavi agganciati ad un \textit{hub};\footnote{si chiamano
  \textit{hub} quegli apparati di rete in grado di ricevere il traffico da
  ciascuna scheda e ritrasmetterlo a tutte le altre, la cui sola differenza
  rispetto al vecchio cavo BNC è quella di replicare il segnale su tutte le
  schede, senza bloccare tutto in caso di rottura del cavo; oggi sono
  praticamente scomparsi.} la caratteristica di entrambe queste configurazioni
era che una volta che una scheda inviava un pacchetto sulla rete locale questo
veniva reinviato a tutte le schede che ne facevano parte. Pertanto leggendo
tutto il traffico in arrivo su una singola scheda si poteva leggere anche
quello relativo a comunicazioni fra macchine diverse dalla propria.

Con l'evolversi della tecnologia però gli \textit{hub} ormai sono stati
totalmente sostituiti dagli \textit{switch},\footnote{anche questo è un
  dispositivo hardware in grado di connettere varie schede ethernet in una
  unica rete, ma in maniera più efficiente, creando una tabella dei MAC
  address associati alle schede collegate su ciascuna porta, ed inviando su
  detta porta soltanto il traffico ad essa relativo.} che sono in grado di
inoltrare il traffico direttamente da una scheda di rete all'altra, evitando
che ad una scheda arrivino pacchetti di rete non indirizzati esplicitamente a
lei.

Dato che con l'uso degli \textit{switch} una macchina riceve solo il traffico
direttamente diretto a lei, è diventato abbastanza difficile utilizzare uno
\textit{sniffer} come strumento diagnostico per tutta una rete, non essendo
più possibile accedere direttamente a tutto il traffico che passa su di
essa. Può essere possibile farlo ancora se è disponibile la capacità
(provvista solo dagli \textit{switch} di fascia alta) di effettuare il
\textit{mirroring} del traffico su una porta (cosa che normalmente comporta
problemi di prestazioni) altrimenti per poter leggere il traffico diretto ad
altri tutto si dovrà usare la macchina con lo \textit{sniffer} come
\textsl{ponte}\footnote{in genere in una rete ethernet si chiama
  \textsl{ponte} (\textit{bridge} in inglese) un dispositivo in grado di
  collegare fra loro due segmenti di rete separati in modo da farli apparire
  come una rete unica; un \textsl{ponte} è anche in grado di sapere quali
  indirizzi fisici sono situati fra le sue due sponde e gestire opportunamente
  il passaggio dei pacchetti da una parte all'altra, tenendo conto anche della
  presenza di eventuali altri ponti (e di diversi possibili cammini di arrivo)
  nella rete completa.} (tramite il supporto per il \textit{bridging} del
kernel) in una posizione che le permetta di osservare il traffico che
interessa.\footnote{un risultato analogo si può ottenere inserendo la macchina
  con lo \textit{sniffer} su un \textit{hub}, posto che se ne possieda ancora
  uno, a cui collegare tutte le macchine di cui si vuole controllare il
  traffico, avendo la consapevolezza che questo degraderà notevolmente le
  prestazioni della rete.}

Vista tutte queste difficoltà nell'intercettare il traffico su reti basate su
\textit{switch} si potrebbe pensare che questo abbia avuto la conseguenza di
rendere il compito quasi impossibile per eventuali attaccanti; questo
purtroppo non è vero, in quanto esistono tecniche con cui è possibile saturare
uno \textit{switch}, (in sostanza basta inviare un sufficiente numero
  di falsi valori per MAC address e saturare la tabella di corrispondenza fra
  porte e schede)
% TODO trovare informazioni su questo argomento
e farlo comportare come un \textit{hub}.  E se questo è in genere
relativamente semplice ed efficace per un attaccante, non lo è per nulla per
l'utilizzo legittimo della rete, che così viene a perdere efficienza nella
trasmissione dei dati. Inoltre, come vedremo più avanti, esistono tecniche
alternative che consentono comunque di intercettare il traffico fra altre
macchine nella stessa rete locale senza dover importunare lo \textit{switch}.

Esistono tuttavia degli \textit{switch} più sofisticati che possono prevenire
questo tipo di comportamento, e bloccare l'uso di una porta da parte dei
pacchetti ethernet il cui indirizzo fisico non sia quello stabilito. Questo
però ha il costo di una maggiore difficoltà di configurazione e della
necessità di gestire in prima persona i cambiamenti dovuti alla sostituzione
delle schede o allo spostamento dei computer.  In ogni caso può essere
opportuno installare un programma come \texttt{arpwatch} (vedi
sez.~\ref{sec:ids_monitor}) che è in grado di tenere sotto controllo una
intera rete ethernet e segnalare l'apparire di un nuovo indirizzo e tutti gli
eventuali cambiamenti nelle corrispondenze fra MAC address e numeri IP. 

\itindend{sniffer}

Il primo e più elementare \textit{sniffer} utilizzabile su GNU/Linux (ed in
moltissimi altri sistemi) è \index{comando!\texttt{tcpdump}} \texttt{tcpdump}.
Il programma è nato come strumento di controllo di una rete, ed è in sostanza
una interfaccia a riga di comando per la libreria \textsf{libpcap} (nome che
deriva da \textit{Packet Capture}) che è quella che viene utilizzata anche da
tutti gli altri \textit{sniffer} e che esegue il lavoro di cattura dei
pacchetti. Dovendo modificare le proprietà dell'interfaccia ed usare l'accesso
ai livelli più bassi dei protocolli di rete, è chiaro che uno \textit{sniffer}
può essere utilizzato soltanto se si hanno i privilegi di amministratore.

Se lanciato senza parametri \texttt{tcpdump} imposta in modalità promiscua la
prima interfaccia ethernet che trova attiva ed inizia a stampare a video le
intestazioni di tutti i pacchetti che vede arrivare fintanto che non lo si
interrompe con un SIGINT (cioè premendo \texttt{C-c}), nel qual caso stamperà
anche una serie di statistiche relative ai pacchetti che è stato in grado di
processare. Qualora infatti il traffico sia troppo elevato il programma
scarterà quelli che non riesce a trattare.

Usando l'opzione \texttt{-w} si possono salvare i pacchetti letti su un file,
passato come argomento, così da poterli analizzare in un secondo momento;
l'opzione richiede come argomento il nome del file o ``\texttt{-}'' per
indicare lo \textit{standard output}. Quando si catturano pacchetti su un file
è in genere il caso di usare anche l'opzione \texttt{-s} per indicare al
comando di catturare anche i dati in essi contenuti; di default infatti
\texttt{tcpdump} cattura solo i primi 68 byte, che in genere sono sufficienti
per analizzare le intestazioni dei principali protocolli, ma che non bastano
se si vuole ricostruire l'intero flusso di dati. L'opzione richiede che si
passi come argomento il numero massimo di byte da catturare, ed il valore
nullo può essere usato per richiedere la cattura di tutti i dati.
 
Usando l'opzione \texttt{-c} si può specificare un numero totale di pacchetti,
letti i quali il comando terminerà. Con l'opzione \texttt{-r} si possono
leggere i pacchetti precedentemente salvati su un file (da specificare come
parametro) invece che dalla rete. Con l'opzione \texttt{-n} si richiede di non
effettuare la risoluzione inversa degli indirizzi, che oltre a rallentare il
programma causa a sua volta traffico di rete per le richieste al DNS. 

Infine con l'opzione \texttt{-i} si può richiedere al comando di ascoltare su
una specifica interfaccia di rete da indicare con lo stesso nome (passato come
parametro) con cui viene mostrata da \texttt{ifconfig}.  L'opzione \texttt{-i}
può essere ripetuta più volte per ascoltare su più interfacce, o si può usare
il nome \texttt{any} per richiedere l'ascolto su tutte le interfacce
disponibili, questa opzione però comporta che la cattura non venga eseguita
ponendo l'interfaccia in modo promiscuo.  Le altre opzioni più rilevanti di
\texttt{tcpdump} sono state riportate in tab.~\ref{tab:tcpdump_options}. Al
solito l'elenco completo ed una descrizione dettagliata delle stesse è
disponibile nella relativa pagina di manuale, accessibile con \texttt{man
  tcpdump}.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|p{8cm}|}
    \hline
    \textbf{Opzione}&\textbf{Descrizione}\\
    \hline
    \hline
    \texttt{-c \textsl{count}}& legge esattamente \texttt{count} pacchetti.\\ 
    \texttt{-e}       & stampa anche i dati relativi al protocollo di
                        collegamento fisico (il MAC address).\\ 
    \texttt{-i \textsl{iface}}& specifica una interfaccia su cui ascoltare.\\ 
    \texttt{-n}       & non effettua la risoluzione degli indirizzi.\\ 
    \texttt{-p}       & non porta l'interfaccia in modo promiscuo.\\ 
    \texttt{-q}       & diminuisce le informazioni stampate a video.\\ 
    \texttt{-r \textsl{file}} & legge i pacchetti dal file \texttt{file}.\\ 
    \texttt{-s \textsl{bytes}}& cattura il numero di byte specificato per
                                ciascun pacchetto, un valire nullo richiede la
                                cattura di tutto il pacchetto.\\ 
    \texttt{-t}       & non stampa la temporizzazione dei pacchetti.\\ 
    \texttt{-v}       & aumenta le informazioni stampate a video.\\ 
    \texttt{-w \textsl{file}} & scrive i pacchetti letti sul file
                               \texttt{file}.\\  
    \texttt{-C \textsl{size}} & crea un nuovo file con numero progressivo ogni
                                qual volta i dati acquisiti superano la
                                dimensione \texttt{\textsl{size}} (indicata
                                in milioni di byte).\\ 
    \texttt{-F \textsl{file}} & usa il contenuto di \texttt{file} come
                                filtro.\\  
%    \texttt{-} & .\\ 
    \hline
  \end{tabular}
  \caption{Principali opzioni di \texttt{tcpdump}.} 
\label{tab:tcpdump_options}
\end{table}

La caratteristica più importante di \texttt{tcpdump} è che consente di
indicare, specificando come argomento del comando una espressione di
filtraggio, quali pacchetti devono essere catturati e visualizzati fra tutti
quelli che transitano per l'interfaccia, in modo da non essere sommersi nel
normale traffico di rete e selezionare solo quanto interessa analizzare. Dato
che questa funzionalità è stata implementata per la prima volta su BSD essa
viene anche detta \itindex{Berkley~Packet~Filter} \textit{Berkley Packet
  Filter} e talvolta viene indicata con la sigla BPF.

In realtà questa funzionalità è fornita direttamente dalla libreria
\textsf{libpcap}, che contiene il codice che realizza effettivamente la
\textsl{cattura} dei pacchetti sulle interfacce di rete. Questo significa che
le espressioni del \itindex{Berkley~Packet~Filter} \textit{Berkley Packet
  Filter} vengono interpretate direttamente dalla libreria, e quindi restano
le stesse per tutti quegli \textit{sniffer} (o altri programmi, come
\texttt{snort}) che si appoggiano a \textsf{libpcap} per la lettura dei
pacchetti.

Vale pertanto la pena esaminare un po' più in profondità la sintassi delle
regole del \itindex{Berkley~Packet~Filter} \textit{Berkley Packet Filter} dato
che questo consente di specificare espressioni generiche che restano valide
tanto per \texttt{tcpdump} come per molti altri programmi che vedremo in
seguito.

Le espressioni di filtraggio sono composte da una o più \textsl{primitive},
cioè delle espressioni elementari che permettono di identificare una certa
classe di traffico di rete, sulla base dei criteri di corrispondenza che
esprimono. Tutto il traffico per cui la condizione espressa dal filtro è vera
verrà catturato, i restanti pacchetti non verranno considerati. 

Ciascuna \textsl{primitiva} è composta da un \textsl{identificatore} (che può
essere un nome o un numero) preceduto da uno o più \textsl{qualificatori} che
indicano cosa sia il nome o il numero espresso dall'\textsl{identificatore}. I
\textsl{qualificatori} si possono classificare in tre diversi tipi:
\begin{basedescript}{\desclabelwidth{3cm}\desclabelstyle{\nextlinelabel}}
\item[\textsl{di tipo}] specifica il tipo dell'\textsl{identificatore}
  seguente; sono tipi possibili solo i \textsl{qualificatori}
  ``\texttt{host}'', ``\texttt{net}'' e ``\texttt{port}'' che identificano
  rispettivamente un indirizzo IP, una rete o una porta, ad esempio
  ``\texttt{host davis}'', ``\texttt{net 192.168.2}'' o ``\texttt{port 25}''.
  Qualora non si specifichi nessun tipo si assume che si tratti di un
  \texttt{host}.
\item[\textsl{di direzione}] specifica una direzione per il traffico che si
  intende selezionare, le direzioni possibili sono ``\texttt{src}'',
  ``\texttt{dst}'', ``\texttt{src or dst}'' e ``\texttt{src and dst}'', ad
  esempio ``\texttt{src davis}'' o ``\texttt{dst net 192.168.2}''.  Qualora
  non si specifichi nulla si assume che si tratti di \texttt{src and dst}. 
\item[\textsl{di protocollo}] specifica un protocollo di rete a cui limitare
  la corrispondenza in una regola, i protocolli possibili sono
  ``\texttt{ether}'', ``\texttt{fddi}'', ``\texttt{tr}'', ``\texttt{ip}'',
  ``\texttt{ip6}'', ``\texttt{arp}'', ``\texttt{rarp}'', ``\texttt{decnet}'',
  ``\texttt{tcp}'' e ``\texttt{udp}''; possibili esempi sono ``\texttt{arp net
    192.168.2}'', ``\texttt{ether dst davis.truelite.it}'' o ``\texttt{tcp
    port 22}''.  Qualora non si specifichi nulla verranno utilizzati tutti i
  protocolli compatibili con il tipo di \textsl{identificatore} utilizzato (ad
  esempio se si specifica \texttt{host davis} si sottintende \texttt{ip or arp
    or rarp}).
\end{basedescript}

Oltre ai valori precedenti si hanno disposizione delle ulteriori parole chiavi
speciali come \texttt{gateway} e \texttt{broadcast}, la prima serve per
indicare un pacchetto che usa come gateway l'\texttt{host} specificato di
seguito, mentre la seconda serve per selezionare i pacchetti
\textit{broadcast} inviati sulla rete. Altre due espressioni speciali sono
\texttt{less} e \texttt{greater} che permettono di effettuare selezioni sulla
dimensione (rispettivamente minore o maggiore del valore specificato). 

La potenza delle espressioni di filtraggio di \textsf{libpcap} sta però nel
fatto che le primitive supportano anche degli operatori logici e aritmetici e
possono essere combinate fra di loro in maniera flessibile e potente.  Abbiamo
già intravisto l'uso delle espressioni logiche \texttt{or} e \texttt{and}, cui
si aggiunge anche la negazione ottenibile con \texttt{not}.  Qualunque
primitiva può essere combinata con queste espressioni, inoltre queste stesse
espressioni logiche possono anche essere formulate anche in una sintassi
simile a quella del linguaggio C, nella forma ``\texttt{||}'',
``\texttt{\&\&}'' e ``\texttt{!}''.  Le primitive inoltre possono essere
raggruppate attraverso l'uso delle parentesi ``\texttt{(}'' e
``\texttt{)}''\footnote{attenzione che questi, come alcuni dei caratteri usati
  per le espressioni logiche, sono interpretati dalla shell, e devono pertanto
  essere adeguatamente protetti quando li si vogliono utilizzare nella riga di
  comando.} ed anche a detti gruppi si riapplicano gli operatori logici, con
il solito ovvio significato.

Un breve elenco di possibili primitive è il seguente, per un elenco più lungo
e dettagliato si può di nuovo fare riferimento alla pagina di manuale di
\texttt{tcpdump}:
\begin{basedescript}{\desclabelwidth{3cm}\desclabelstyle{\nextlinelabel}}
\item[\texttt{dst host ip}] vera per i pacchetti il cui indirizzo IP di
  destinazione, specificato sia in notazione \textit{dotted decimal} che in
  forma simbolica, è \texttt{ip}. 
\item[\texttt{src host ip}] vera per i pacchetti il cui indirizzo IP sorgente
  è \texttt{ip}. 
\item[\texttt{host ip}] vera per i pacchetti che hanno \texttt{ip} come
  indirizzo sorgente o di destinazione. 
\item[\texttt{dst net nw}] vera per i pacchetti con indirizzo di destinazione
  nella rete \texttt{nw}, specificata sia con un nome presente in
  \texttt{/etc/network}, che in formato dotted decimal, che in formato CIDR. 
\item[\texttt{src net nw}] vera per i pacchetti con indirizzo sorgente nella
  rete \texttt{net}. 
\item[\texttt{dst port port}] vera per i pacchetti TCP e UDP con porta di
  destinazione \texttt{port} (specificata sia per valore numerico che nome
  presente in \texttt{/etc/services}). 
\item[\texttt{src port prt}] vera per i pacchetti TCP e UDP con porta
  sorgente \texttt{port}. 
\item[\texttt{ip proto prot}] vera per i pacchetti IP contenenti pacchetti di
  protocollo \texttt{prot}, specificato sia per valore numerico che per nome
  presente in \texttt{/etc/protocols}. 
\item[\texttt{tcp}] abbreviazione per \texttt{ip proto tcp}. 
\item[\texttt{udp}] abbreviazione per \texttt{ip proto udp}. 
\item[\texttt{icmp}] abbreviazione per \texttt{ip proto icmp}. 
\end{basedescript}

Allora se per esempio si vogliono leggere tutti i pacchetti relativi ad una
certa connessione TCP, una volta che siano noti indirizzi e porte sorgenti e
destinazione, si potrà effettuare la selezione con un comando del tipo:
\begin{Console}
# \textbf{tcpdump \bslash( src 192.168.1.2 and src port 33005 \bslash}
\textbf{and dst 192.168.1.141 and dst port 22 \bslash) or \bslash}
\textbf{\bslash( src 192.168.1.141 and src port 22 \bslash}
\textbf{and dst 192.168.1.2 and dst port 33005 \bslash)}
tcpdump: listening on eth0
16:36:53.822759 IP ellington.fi.trl.59485 > 192.168.2.2.ssh: Flags [P.], seq 48:
96, ack 97, win 400, options [nop,nop,TS val 90566618 ecr 3088734915], length 48
16:36:53.829040 IP 192.168.2.2.ssh > ellington.fi.trl.59485: Flags [P.], seq 97:
193, ack 96, win 158, options [nop,nop,TS val 3088743391 ecr 90566618], length 9
6
16:36:53.829061 IP ellington.fi.trl.59485 > 192.168.2.2.ssh: Flags [.], ack
193, win 400, options [nop,nop,TS val 90566619 ecr 3088743391], length 0
... 
\end{Console}
dove nella prima primitiva fra parentesi si selezionano i pacchetti uscenti da
una macchina e diretti sull'altra, e nella seconda primitiva si selezionano i
pacchetti di risposta uscenti dall'altra che tornano indietro. 

L'output del programma varia a seconda del tipo di pacchetti catturati, ma per
ciascuno di essi viene sempre stampata una riga iniziante con marca temporale
seguita dal tipo di protocollo del contenuto. Se poi i pacchetti sono, come
nel caso del precedente esempio, relativi ad un protocollo del livello di
trasporto vengono sempre stampati indirizzi e porte sorgente e destinazione,
nella forma:
\begin{Example}
nome.macchina.sorgente.numeroporta > IP.MACCHINA.DESTINAZIONE.nomeporta:
\end{Example}
con tanto di risoluzione dei nomi, a meno che questa non sia stata
disabilitata con l'opzione \texttt{-n}; a questo possono seguire dati
specifici del protocollo, come quelli del TCP dell'esempio precedente.

\begin{figure}[!htb]
  \centering
  \includegraphics[scale=0.5]{images/wireshark1} 
  \caption{Finestra di avvio di \texttt{wireshark}.}
  \label{fig:wireshark_start_win}
\end{figure}

Benché \texttt{tcpdump} offra la possibilità di analizzare nei dettagli tutto
il traffico, e possa fornire tutte le informazioni necessarie, richiede anche
una certa conoscenza dei protocolli di rete, dato che presenta le informazioni
in una modalità non proprio di interpretazione immediata. Per questo motivo
sono stati realizzati altri \textit{sniffer} in grado di fare lo stesso lavoro
nella cattura, ma di presentare i risultati in maniera più
\textsl{amichevole}. Il più importante di questi è senz'altro
\index{comando!\texttt{wireshark}} \texttt{wireshark},\footnote{in precedenza
  il programma era noto come \texttt{ethereal}, il nome è stato cambiato per
  questioni relative ai marchi.} la cui schermata di avvio è mostrata in
fig.~\ref{fig:wireshark_start_win}.

Come si può notare in questo caso si ha a che fare con un programma dotato di
una interfaccia grafica molto sofisticata, comprensiva di un sistema di
\textit{help on line}. Il programma può eseguire la stampa o il salvataggio su
disco dei dati o la lettura degli stessi da precedenti sessioni di cattura,
anche se eseguite da altri programmi, con una ampia capacità di decodificare i
vari formati in cui questi possono essere stati memorizzati. Ma in realtà la
vera potenza di \texttt{wireshark} non sta tanto nella ricchezza delle sue
funzionalità quanto nella infrastruttura di cui è dotato.

La caratteristica più interessante di \texttt{wireshark} infatti è quella di
mettere a disposizione una interfaccia ben definita e molto funzionale per i
cosiddetti \textit{protocol dissector}. Il programma cioè può essere esteso in
maniera relativamente semplice per effettuare una vera e propria
\textsl{dissezione anatomica} del traffico di rete, in modo da presentare le
informazioni in maniera efficace e facilmente comprensibile, provvedendo ad
identificare parecchie centinaia di protocolli diversi, dal livello di rete
fino a quello di applicazione, e classificare di conseguenza i dati raccolti.
In questo modo diventa poi possibile identificare, all'interno dei singoli
pacchetti, tutti i dettagli ed i particolari relativi al contenuto.

Si tenga presente però che questa ricchezza di funzionalità ha un costo in
termini di sicurezza, dato che eseguire una validazione corretta dei dati in
ingresso per qualunque tipo di traffico è estremamente complesso, e questo
porta ad una grande quantità di problemi di sicurezza per errori presenti nei
\textit{protocol dissector}. La finestra di avvio di
fig.~\ref{fig:wireshark_start_win} è quella ottenuta quando il programma viene
lanciato da un utente normale, quando lo si lancia con privilegi di
amministratore si ottiene un'ulteriore finestra con un messaggio di avviso che
ne sconsiglia l'uso dato in questo caso qualcuno potrebbe, sfruttando una di
queste vulnerabilità ed inviando pacchetti opportunamente malformati,
compromettere la macchina.

Il problema è che per poter effettuare la cattura dei pacchetti i privilegi di
amministratore sono necessari, per cui non esiste una soluzione semplice al
problema che non sia quella di eseguire la cattura in maniera indipendente
salvando i dati su un file, ed eseguire il programma in un secondo tempo per
analizzare gli stessi. Il comando \texttt{wireshark} infatti prende come
argomento un nome di file da cui leggere i dati, ed è in grado di leggere una
grande varietà di diversi formati, riconoscendoli automaticamente. Si può
comunque caricare un file in un qualunque momento, con la voce \textsf{Open}
nel menù \textsf{File} o cliccando sulle icone della sezione \textit{File}
della finestra di avvio.

\begin{figure}[!htb]
  \centering \includegraphics[scale=0.5]{images/wireshark2}
  \caption{Finestra di selezione delle interfacce di \texttt{wireshark}.}
\label{fig:wireshark_iface_sel}
\end{figure}

Qualora lo si voglia usare in maniera interattiva occorrerà invece assumersi
il rischio di subire un attacco ed accettare di andare avanti sulla finestra
di avvio. A questo punto per far partire una sessione di cattura basterà
premere su una delle interfacce mostrate nella sezione \textit{Interface List}
della finestra di avvio (presenti solo quando lo si invoca come
amministratore), altrimenti si potrà ottenere una finestra di selezione delle
interfacce, illustrata in fig.~\ref{fig:wireshark_iface_sel}, cliccando sulla
prima icona a sinistra nella barra sotto il menù o selezionando la voce
\textsf{Interfaces} nel menù \textsf{Capture}.

La finestra di selezione riporta tutte le interfacce rilevate da
\texttt{wireshark} elencate con i loro nomi, più una interfaccia virtuale che
le accorpa tutte, chiamata \texttt{any} come per \texttt{tcpdump}. Nella
finestra viene anche mostrata tempo reale una statistica del flusso di
pacchetti sulle varie interfacce. Si può far partire una cattura premendo sul
pulsante \textsf{Start} corrispondente all'interfaccia scelta, ma si possono
anche impostare le opzioni di cattura premendo sul pulsante \textsf{Options},
che farà apparire la apposita finestra, illustrata in
fig.~\ref{fig:wireshark_capture_opt}. Questa stessa finestra può essere
ottenuta direttamente premendo sulla seconda icona nella barra sotto il menù o
o selezionando la voce \textsf{Options} nel menù \textsf{Capture}.

\begin{figure}[!htb]
  \centering \includegraphics[scale=0.5]{images/wireshark3}
  \caption{Finestra di impostazione delle opzioni di cattura di
    \texttt{wireshark}.}
\label{fig:wireshark_capture_opt}
\end{figure}

Da questa finestra si possono impostare i parametri della sessione di
cattura. In particolare è possibile riscegliere l'interfaccia su cui ascoltare
nel campo di testo \textsf{Interface} (dotato anche di tendina per la
selezione fra quelle disponibili identificate dal programma), si può indicare
un file su cui salvare i dati nel campo di testo \textsf{File} (dotato di
pulsante per attivare la finestra di selezione dei file), ma soprattutto si
può inserire una espressione di filtraggio per selezionare i pacchetti da
catturare nel campo di testo \textsf{Capture Filter}, usando la sintassi del
\itindex{Berkley~Packet~Filter} \textit{Berkley Packet Filter} illustrata in
precedenza. Inoltre premendo sul bottone associato si può salvare o
selezionare il filtro su di una tabella, assegnandogli un nome in modo da
poterlo riutilizzare in seguito senza doverlo riscrivere.

Il resto della finestra consente di impostare tutte le altre caratteristiche
della sessione di cattura, come da relative indicazioni auto-esplicative. Una
volta completate le impostazioni si potrà far partire la sessione di cattura
premendo sul pulsante \textsf{Start}.

\begin{figure}[!htb]
  \centering \includegraphics[scale=0.5]{images/wireshark4}
\caption{Finestra principale di \texttt{wireshark}.} 
\label{fig:wireshark_main_win}
\end{figure}

Una volta avviata la cattura il programma inizierà a mostrare i pacchetti
ricevuti nella sua finestra principale, riportata in
fig.~\ref{fig:wireshark_main_win}, le cui righe inizieranno a scorrere
progressivamente. A meno di non aver impostato dei limiti nelle opzioni di
cattura (la sezione \textsf{Stop Capture} in
fig.~\ref{fig:wireshark_capture_opt}), questa proseguirà indefinitamente e
dovrà essere fermata esplicitamente o premendo sul pulsante di stop (la quarta
icona della barra sotto il menù) o selezionando la voce \textsf{Stop} dal menù
\texttt{Capture}.

Tutti i dati vengono inseriti nella finestra principale che è divisa in tre
sezioni principali. Nella prima parte in alto viene mostrata la lista dei
pacchetti catturati, numerati progressivamente. Di questi viene riportato il
tempo di cattura relativo all'inizio della sessione, gli indirizzi
destinazione e sorgente (IP, a meno che non si tratti di pacchetti ARP) il
protocollo ed un breve sunto delle informazioni contenute. Per visualizzare il
contenuto di un pacchetto particolare basta selezionarlo con il mouse, e nella
sezione centrale comparirà il risultato della sua \textsl{dissezione}, mentre
nella sezione finale verrà visualizzato il contenuto del pacchetto espresso in
valori esadecimali e in caratteri ASCII. Un esempio è mostrato in
fig.~\ref{fig:wireshark_main_win2} dove si è selezionata la parte relativa al
protocollo TCP.

\begin{figure}[!htb]
  \centering \includegraphics[scale=0.5]{images/wireshark5}
\caption{Finestra principale di \texttt{wireshark}, nella selezione di una
  parte del pacchetto.} 
\label{fig:wireshark_main_win2}
\end{figure}


Sopra la tre sezioni viene riportato un campo testo che permette di inserire
un ulteriore filtro di selezione. Questo non va confuso con il precedente
filtro di cattura, che opera solo in fase di acquisizione dei pacchetti e
supporta esclusivamente la sintassi del \itindex{Berkley~Packet~Filter}
\textit{Berkley Packet Filter}; in questo caso infatti il filtro è sulla
visualizzazione dei pacchetti catturati, e permette di utilizzare tutte le
informazioni che il \textit{protocol dissector} ha estratto dai pacchetti.  Si
può anche costruire il filtro direttamente con l'interfaccia grafica, premendo
sul relativo pulsante, che farà comparire una apposita finestra di
composizione e salvataggio dei filtri.

Come accennato la sezione centrale della finestra di \texttt{wireshark}
contiene il risultato della dissezione dei pacchetti, organizzato in una
struttura a livelli, a partire dai dati relativi al \textit{frame} ethernet
letto direttamente sull'interfaccia (tempo di arrivo, numero progressivo,
dimensione), ai dati relativi al protocollo di collegamento fisico, quello di
rete (o equivalente posto sopra il collegamento fisico, come ARP), il livello
di trasporto, quello di applicazione, ulteriori protocolli interni, ecc.

Per ciascun nuovo protocollo che viene trovato all'interno del precedente
viene creata una riga in questa sezione, che porta con sé l'indicazione del
protocollo cui fa riferimento, e i relativi dati principali: così per ethernet
sono mostrati i MAC address destinazione e sorgente del pacchetto, per IP i
relativi indirizzi, per TCP le porte, i numeri di sequenza e di
\textit{acknowledgement}, e così via per gli ulteriori protocolli contenuti
nel pacchetto. 

Tutte queste righe possono poi essere espanse ad albero per esporre il
contenuto completo delle intestazioni dei relativi protocolli, suddivise per i
vari campi (ciascuno avrà ovviamente i propri valori). Premendo su una di
queste righe, o su uno dei campi all'interno, si avrà l'effetto di
evidenziare, nella sezione finale dove sono riportati i dati in forma binaria,
la relativa sezione del pacchetto. 

La grande flessibilità di \texttt{wireshark} comunque non si ferma qui,
premendo il tasto destro del mouse su un pacchetto si può attivare un menù
contestuale che permette ad esempio di identificare tutto lo stream TCP (o il
flusso dati UDP) di cui questo fa parte, visualizzandone il contenuto in una
nuova finestra o generare al volo un filtro sulla base delle proprietà di quel
pacchetto (queste funzionalità si possono ottenere anche dalle relative voci
nel menù \textsf{Analyze}). Se invece si clicca su uno dei campi della
finestra di dissezione si può generare un filtro di selezione sulla base di
quel campo.

Inoltre dal menù \textsf{Statistics} si hanno a disposizione una serie di
funzioni statistiche che permettono di ottenere sommari sul traffico rilevato,
come quello strutturato per gerarchia di protocolli (voce \textsf{Protocol
  Hierarchy}); quello che traccia tutte le conversazioni (voce
\texttt{Conversations}) identificate dal programma ai vari livelli dei
protocolli, quello che traccia i capi della comunicazione (voce
\texttt{Endpoints}) e molti altri.

Come si può vedere anche da questa breve e sommaria introduzione
\texttt{wireshark} è uno strumento di analisi estremamente potente e
sofisticato. Non staremo ad approfondirne ulteriormente le caratteristiche,
essendo quanto illustrato sufficiente per le esigenze di queste dispense, per
una trattazione più accurata si può fare riferimento alla guida utente,
disponibile su \url{http://www.wireshark.org/} anche in formato PDF, o
esercitarsi un po' con le funzionalità dell'interfaccia utente.

%
% ettercap
%

L'ultimo programma che tratteremo in questa sezione è
\index{comando!\texttt{ettercap}} \texttt{ettercap}, che più che uno
\textit{sniffer} è uno strumento per eseguire attacchi di
\itindex{man-in-the-middle} \textit{man-in-the-middle}. A differenza degli
altri \textit{sniffer} infatti \texttt{ettercap} non si limita a leggere i
pacchetti che arrivano su una interfaccia della propria macchina, ma è in
grado di mettere in atto tutta una serie di tecniche che lo rendono in grado
di intercettare (e modificare al volo) il traffico fra altre macchine, anche
quando ci si trova su una rete basata su switch.

Con la nuova versione 0.7 il programma è stato radicalmente modificato e le
sue funzionalità sono state ampliate, in particolare sono state previste due
modalità principali di cattura dei pacchetti (\textit{sniffing}), denominate
\textit{bridged} e \textit{unified}. La prima, specificata a riga di comando
dalla opzione \texttt{-B}, prevede che si abbiano due schede di rete con cui
creare un bridge da cui far passare il traffico; in tal caso si deve avere la
possibilità interporsi fisicamente, ma si ottiene il vantaggio di essere
totalmente trasparenti.

Dati gli stringenti requisiti di accesso fisico per poter utilizzare la prima,
la modalità usata normalmente dal programma è la seconda (nel senso che se
lanciato a riga di comando viene attivata di default senza dover specificare
altro) chiamata \textit{unified} proprio in quanto consente di unificare le
operazioni di cattura con quelle di attacco e con quelle di eventuale
filtraggio e modifica dei pacchetti intercettati.

In questa modalità infatti \texttt{ettercap} disabilita il reinoltro dei
pacchetti del kernel in quanto questo compito viene assunto dal programma
stesso, che può così eseguire quanto serve per gli attacchi
\itindex{man-in-the-middle} \textit{man-in-the-middle} ed applicare eventuali
modifiche ai pacchetti in transito. Se la funzionalità di \textit{IP
  forwarding} restasse attiva anche il kernel reinoltrerebbe i pacchetti che
risulterebbero doppi. Si tenga presente che questo comportamento da luogo a
problemi quando si esegue \texttt{ettercap} su un \textit{gateway} (cosa che è
comunque sconsigliata), poiché il programma opera sempre su una sola
interfaccia ed esegue il reinoltro solo su quella, quindi i pacchetti in
transito fra interfacce diverse non verrebbero instradati, per questo caso è
disponibile un \textit{Unoffensive Mode} (opzione \texttt{-u}) che non
disabilita l'\textit{IP forwarding}.

Se lanciato a riga di comando il comando richiede sempre due argomenti che
identificano le macchine bersaglio poste ai due capi della comunicazione che
si vuole intercettare. Non esiste in genere il concetto di sorgente e
destinazione in quanto il flusso è bidirezionale, ma qualora si usino tecniche
che consentano solo di intercettare una sola direzione della connessione, il
primo dei due argomenti indica il sorgente ed il secondo la destinazione.

I bersagli sono espressi nella forma generica \texttt{MAC-addr/IP-addr/port},
qualora non si specifichi uno dei tre valori si intende che questo può essere
qualsiasi, pertanto \texttt{/192.168.1.1/} indica la macchina con
quell'indirizzo IP e porta qualunque, mentre \texttt{//110} indica un
indirizzo IP qualunque e la porta 110. Per specificare l'indirizzo IP si può
usare una sintassi estesa che consente di specificare un insieme di indirizzi,
con elenchi di indirizzi o intervalli, mentre se si specifica un \textit{MAC
  address} questo deve essere unico. Infine con l'opzione \texttt{-R} si può
invertire la selezione dell'indirizzo specificato di seguito.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|p{8cm}|}
    \hline
    \textbf{Opzione}&\textbf{Descrizione}\\
    \hline
    \hline
    \texttt{-i \textsl{iface}}& specifica una interfaccia al posto di quella
                                di default.\\ 
    \texttt{-w \textsl{file}} & scrive i pacchetti letti sul file \texttt{file}
                                nel formato di \texttt{tcpdump} (pcap).\\
    \texttt{-r \textsl{file}} & legge i pacchetti in formato pcap 
                                dal file \texttt{file}.\\ 
    \texttt{-L \textsl{file}} & scrive i dati letti sui file \texttt{file.ecp}
                                per i pacchetti e \texttt{file.eci} per le
                                informazioni.\\ 
    \texttt{-l \textsl{file}} & scrive solo le informazioni essenziali
                                raccolte sul file \texttt{file.eci}.\\ 
    \texttt{-k \textsl{file}} & scrive la lista delle macchine rilevate come 
                                presenti sulla rete.\\ 
    \texttt{-j \textsl{file}} & legge la lista delle macchine presenti sulla
                                rete.\\  
    % \texttt{-n}               & specifica una \textit{netmask} da usare al
    %                             posto di quella presente sull'interfaccia.\\ 
    \texttt{-R}               & inverte la indicazione di un bersaglio
                                (seleziona ciò che non corrisponde).\\ 
    \texttt{-z}               & non esegue la scansione iniziale della rete.\\ 
    \texttt{-u}               & attiva l'\textit{unoffensive mode}, non
                                disabilitando il reinoltro dei pacchetti sulle
                                interfacce.\\
    \texttt{-P \textsl{plugin}}&esegue il \textit{plugin} indicato.\\ 
    \texttt{-T}               & esegue il programma in modalità testuale.\\ 
    \texttt{-C}               & esegue il programma in modalità semigrafica.\\ 
    \texttt{-G}               & esegue il programma in modalità grafica .\\ 
    \texttt{-D}               & esegue il programma come demone.\\ 
    \texttt{-B \textsl{iface}}& attiva il \textit{bridged sniffing} usando
                                insieme l'interfaccia di default (o quella
                                specificata con \texttt{-i}) e
                                \textsl{iface}.\\
    \texttt{-M \textsl{mode}} & attiva la modalità di attacco per il
                                \textit{man-in-the-middle} indicata da
                                \textsl{mode} che può assumere i valori:
                                \texttt{arp} per l'\textit{arp poisoning},
                                \texttt{icmp} per l'\textit{ICMP redirect},
                                \texttt{dhcp} per il \textit{DHCP spoofing},
                                \texttt{port} per il \textit{port stealing}.\\ 
%    \texttt{-} & .\\ 
    \hline
  \end{tabular}
  \caption{Principali opzioni di \texttt{ettercap}.} 
\label{tab:ettercap_options}
\end{table}

Se non si specifica nessun argomento il programma chiede di specificare
tramite una opportuna opzione l'interfaccia di gestione che si intende usare.
Le scelte possibili sono tre, con \texttt{-T} si attiva l'interfaccia testuale
semplice, con \texttt{-C} si attiva l'interfaccia testuale semigrafica basata
sulla libreria \textit{ncurses}, con \texttt{-G} si attiva l'interfaccia
grafica basata sulle librerie GTK.\footnote{se si è installato la versione con
  il relativo supporto, che su Debian ad esempio questa è disponibile solo se
  si è installato il pacchetto \texttt{ettercap-gtk}.} In genere l'uso più
comune è con una di queste ultime due, ed al solito quella testuale ha il
vantaggio di poter essere usata con un uso di risorse molto più ridotto.

Si può però lanciare \texttt{ettercap}, con l'opzione \texttt{-D}, anche in
modalità non interattiva, in cui il programma lavora registrando tutti i
risultati su dei file di log. In questo caso occorre specificare con
\texttt{-L} il file su cui si vuole vengano salvati i pacchetti e dati (nel
formato interno di \texttt{ettercap}). Detto file potrà essere analizzato in
un secondo tempo con il programma \index{comando!\texttt{etterlog}}
\texttt{etterlog}, che consente di estrarre dal traffico tutte le informazioni
che interessano. Quando il traffico analizzato è molto questa modalità non
incorre nei rallentamenti dovuti alla interazione con l'interfaccia di
gestione.

In modalità non interattiva si dovrà inoltre indicare con \texttt{-l} il file
su cui si vuole che vengano salvate le informazioni più importanti ottenute
dal programma, come le password intercettate. Si tenga presente che
\texttt{ettercap} una volta configurata l'interfaccia per la cattura dei
pacchetti lascia cadere i privilegi di amministratore per girare come utente
\texttt{nobody}, per cui si devono specificare un file o una directory
scrivibili da chiunque (come \texttt{tmp}) o indicare un utente alternativo
che possa scrivere nella directory indicata con la variabile di ambiente
\texttt{EC\_UID}.

Le principali opzioni del programma, utilizzate in genere soltanto in questo
caso, dato che in modalità interattiva il comportamento viene controllato
tramite le operazioni effettuate sull'interfaccia di gestione, sono illustrate
in tab.~\ref{tab:ettercap_options}.

\begin{figure}[!htb]
  \centering \includegraphics[scale=0.5]{images/ettercap1}
\caption{La schermata iniziale \texttt{ettercap} nella versione semigrafica.} 
\label{fig:ettercap_start_window}
\end{figure}

In fig.~\ref{fig:ettercap_start_window} si è riportata la schermata iniziale
che si ottiene con l'interfaccia semigrafica delle \textit{ncurses}, che è
quella che tratteremo più estensivamente. In questa schermata si devono
impostare le modalità di cattura dei pacchetti, che una volta scelte si
applicheranno per il resto della sessione di lavoro; dal menù \textsf{Sniff}
si seleziona la modalità di cattura (fra \textit{unified} e \textit{bridged}),
e dal menù \textsf{Options} si impostano le eventuali opzioni ulteriori (come
l'\textit{unoffensive mode}). La selezione, oltre che dai menù, può essere
effettuata premendo i relativi caratteri sulla tastiera, corrispondenti in
genere alle lettere delle opzioni di tab.~\ref{tab:ettercap_options}. Dal menù
\textsf{File} si possono anche leggere dati già acquisiti, ma non tratteremo
questo caso.

\begin{figure}[!htb]
  \centering \includegraphics[scale=0.5]{images/ettercap3}
  \caption{La schermata di \texttt{ettercap} per la lista delle macchine sulla
    rete.}
\label{fig:ettercap_main_win}
\end{figure}

Una volta scelta la modalità verrà presentata una ulteriore finestra per la
selezione della (o delle) interfacce da utilizzare per la cattura, dopo di che
si verrà portati nella finestra principale del programma, che si è riportata
in fig.~\ref{fig:ettercap_main_win}. La finestra è divisa in due parti, nella
parte superiore vengono visualizzate le informazioni relative alle varie
funzionalità del programma (bersagli, lista delle macchine, delle connessioni,
ecc.) mentre nella parte inferiore vengono mostrati i messaggi per l'utente.

\begin{figure}[!htb]
  \centering \includegraphics[scale=0.5]{images/ettercap5}
  \caption{La schermata di \texttt{ettercap} con il menù per la ricerca delle
    macchine sulla rete.}
\label{fig:ettercap_hosts_menu}
\end{figure}

Inoltre la prima riga della finestra contiene il menù delle operazioni su cui
ci si può spostare con le frecce, e selezionare una voce posizionandosi e poi
premendo l'invio. Si può passare da una finestra all'altra e ritornare sul
menù utilizzando il testo di tabulazione. Si può far partire e fermare la
cattura dal menù \textsf{Start}, selezionare i bersagli dal menù
\textsf{Target}, visualizzare le informazioni raccolte da \textsf{View},
attivare un attacco di \textit{man-in-the-middle} da \textsf{Mitm}, ma in
genere il primo passo è ottenere la lista delle macchine presenti sulla rete,
cosa che normalmente si fa dal menù \textsf{Hosts}, illustrato in
fig.~\ref{fig:ettercap_hosts_menu}.

E da questo menù che si può effettuare una scansione della rete per ottenere
le macchine presenti, che viene eseguita inviando una richiesta di ARP per
tutti gli IP della rete associata all'interfaccia su cui si sta eseguendo la
cattura, vale a dire inviare una richiesta di \textit{ARP reply} in
\textit{broadcast} per ogni IP della rete, che sarà pertanto ricevuta da tutte
le macchine presenti.  Questo metodo presenta però l'inconveniente di essere
particolarmente ``\textsl{rumoroso}'' sulla rete (si parla infatti di
\textit{ARP storm}) e molti IDS sono in grado di accorgersi di questo
comportamento anomalo. Per questo motivo il programma è in grado di leggere
una lista delle macchine da un file o salvarla qualora la si sia ottenuta.

\begin{figure}[!htb]
  \centering \includegraphics[scale=0.5]{images/ettercap4}
  \caption{La schermata di \texttt{ettercap} che mostra l'elenco dei profili
    raccolti in maniera passiva.}
\label{fig:ettercap_profiles_list}
\end{figure}

Si tenga presente che fintanto che non si abilita la cattura dal menù
\textsf{Start} (o con \texttt{C-w}) il programma non acquisirà nessun
pacchetto, e che non è necessario selezionare i bersagli o individuare le
macchine presenti per attivare la cattura; si può infatti anche far partire
l'acquisizione senza altre operazioni ed il programma si limiterà ad ascoltare
tutto il traffico mandando l'interfaccia in modalità promiscua, raccogliendo
una serie di informazioni come IP e MAC address, sistema
operativo,\footnote{il programma è dotato anche un sistema di \textit{passive
    fingerprinting} che usa le stesse tecniche di \texttt{nmap} per
  identificare i vari sistemi operativi sulla base del loro peculiare
  comportamento sulla rete.} ecc. che potranno essere visualizzate dal menù
\textsf{View} nella voce \textsf{Profiles} (accessibile direttamente con il
tasto ``\texttt{O}''), il cui risultato è mostrato in
fig.~\ref{fig:ettercap_profiles_list}.

Da queste informazioni ottenute in modo passivo è possibile salvare una lista
delle macchine rilevate premendo ``\texttt{d}'' (chiederà di indicare un nome
di file), o convertirla direttamente per l'uso come lista di macchine premendo
``\texttt{c}'' (diventerà così disponibile nell'elenco della relativa pagina
del menù \textsf{Hosts}, cui si accede direttamente anche premendo
``\texttt{h}''). Si tenga presente che le informazioni raccolte comprendono
tutti gli indirizzi IP rilevati nel traffico, compresi quelli remoti, in
genere questi non servono nella lista da convertire come elenco di macchine, e
si possono rimuovere premendo ``\texttt{l}'', iniziale che sta per
\textit{local}, inoltre si può anche ridurre la lista ai soli indirizzi remoti
premendo ``\texttt{r}''. Sempre da questa schermata si possono vedere i
dettagli delle informazioni raccolte per ciascuna macchina spostandosi con le
frecce per selezionarla e premendo invio.

\begin{figure}[!htb]
  \centering \includegraphics[scale=0.5]{images/ettercap6}
  \caption{La schermata di \texttt{ettercap} la lista delle macchine sulla
    rete.}
\label{fig:ettercap_host_list}
\end{figure}

Una volta ottenuta la lista delle macchine, sia con una scansione diretta che
convertendo le informazioni raccolte passivamente, si avrà un risultato come
quello mostrato in fig.~\ref{fig:ettercap_host_list}. Da questa schermata si
potrà eseguire direttamente la selezione dei bersagli da attaccare spostandosi
su uno degli IP elencati, e premendo i tasti ``\texttt{1}'' o ``\texttt{2}''
per selezionarlo come primo o secondo. Questa è anche la lista delle macchine
che verranno prese in considerazione qualora si indichi un bersaglio generico,
pertanto se si vuole evitare di attaccare una di queste macchine si può
premere ``\texttt{d}'' per rimuoverla dalla lista.

\begin{figure}[!htb]
  \centering \includegraphics[scale=0.5]{images/ettercap8}
  \caption{La schermata di \texttt{ettercap} con la selezione dei bersagli.}
\label{fig:ettercap_target_selection}
\end{figure}

A questo punto si potrà verificare la relativa presenza dal menù
\texttt{Target} (accessibile direttamente premendo ``\texttt{T}'').  Si
otterrà così un risultato come quello mostrato in
fig.~\ref{fig:ettercap_target_selection}. Si tenga presente che da detto menu
si potranno anche impostare direttamente i bersagli con ``\texttt{C-t}''. 

Il funzionamento di \texttt{ettercap} prevede che le varie metodologie di
attacco vengano utilizzate per intercettare il traffico fra le macchine
specificate come \textit{Target 1} e quelle specificate come \textit{Target
  2}. Dal punto di vista della cattura dei pacchetti non esiste il concetto di
sorgente e destinazione, dato che il traffico viene intercettato in maniera
generica e quindi in entrambi i sensi, ma certi tipi di attacco consentono di
interporsi solo su una direzione del traffico, in tal caso la direzione è
definita e verrà intercettato il traffico da una macchina indicata come
\textit{Target 1} ad una specificata come \textit{Target 2}.

Fintanto che non si attivano attacchi specifici \texttt{ettercap} si limiterà
ad acquisire i pacchetti che vede passare sulla propria interfaccia di rete,
questi possono essere anche tutti quelli che servono se si usa la modalità
\texttt{bridged}, ma come detto questo implica la possibilità di una
interposizione fisica.  

\begin{figure}[!htb]
  \centering \includegraphics[scale=0.5]{images/ettercap9}
  \caption{La schermata di \texttt{ettercap} con la selezione degli attacchi.}
\label{fig:ettercap_mitm_selection}
\end{figure}

Per questo le funzionalità più interessanti di \texttt{ettercap} sono quelle
che si attivano dal menù \textsf{Mitm} che consente di scegliere quali fra le
varie tecniche per eseguire attacchi di \textit{man-in-the-middle} disponibili
deve essere usata in modo da ottenere che il traffico interessato possa
arrivare al programma anche senza una interposizione fisica. Il menù è
riportato in fig.~\ref{fig:ettercap_mitm_selection}, dove è stata selezionata
la prima modalità di attacco; scegliendo le varie voci si possono attivare le
altre.

La principale tecnica usata da \texttt{ettercap}, e la più efficace, è quella
denominata \textit{ARP poisoning} che consiste nell'inviare risposte alle
richieste di ARP con il proprio MAC address, sovrascrivendo le risposte degli
altri in modo da farsi inviare i pacchetti diretti a qualcun altro. Il
problema risiede nell'insicurezza intrinseca del protocollo ARP, che non
prevede nessun tipo di autenticazione, per cui gli indirizzi contenuti nei
pacchetti ARP vengono automaticamente inseriti nella tabella di ARP del
kernel.

Quello che accade normalmente cioè è che se si riceve una risposta di ARP,
anche se non è stata fatta una richiesta, il kernel inserirà i relativi dati
nella tabella di ARP con lo scopo di diminuire il traffico sulla rete. Allora
basta mandare dei falsi pacchetti ARP con il proprio MAC address alle due
macchine di cui si vuole intercettare il traffico, indicando noi stessi come
la macchina cui inviare il traffico relativo all'IP dell'altra (secondo lo
schema in fig.~\ref{fig:ids_arp_poison}). 

\begin{figure}[!htb]
  \centering \includegraphics[width=10cm]{images/arp_poison}
\caption{Schema di funzionamento dell'\textit{ARP poisoning}.} 
\label{fig:ids_arp_poison}
\end{figure}

Benché esistano dei tentativi di contromisura (ad esempio Linux non accetta
risposte di ARP se non precedute da una richiesta fatta da lui), in realtà
nessun kernel blocca le \textsl{richieste} di ARP, che quando ricevute
prevedono di nuovo l'inserimento dell'indirizzo del richiedente nella propria
tabella; pertanto su può tranquillamente \textsl{avvelenare} la cache di una
macchina eseguendo una falsa richiesta di ARP in cui si associa il proprio
\textit{MAC address} all'IP di qualcun altro.

Questo consente a \texttt{ettercap} di \textsl{avvelenare} la cache usando
semplicemente in modalità alternata falsi pacchetti ARP di risposta o di
richiesta. Dato che il funzionamento di una rete prevede che tutti i pacchetti
diretti ad un certo IP vengano inviati alla scheda con il corrispondente
\textit{MAC address} nella tabella di ARP, si potranno ricevere tutti i
pacchetti destinati alla macchina con il suddetto IP, e se al contempo si è
avvelenata pure la cache di quest'ultima, indicando di nuovo il proprio
\textit{MAC address} in corrispondenza dell'IP del vero mittente, si avrà un
classico attacco di \textit{man-in-the-middle} in cui tutti i pacchetti del
traffico fra le due macchine viene intercettato da \texttt{ettercap}.

In questo modo il programma può analizzare tutto il traffico fra due macchine
anche se la rete è basata su \textit{switch} dato che i pacchetti vengono
comunque mandati al \textit{MAC address} dell'attaccante. Inoltre siccome il
traffico passa dalla macchina dell'attaccante, \texttt{ettercap} è anche in
grado di modificare il traffico inserendo dei dati, o cancellandoli o
sostituendoli, ed il tutto avviene in maniera completamente trasparente
rispetto ai protocolli del livello di rete, proprio in quanto l'operazione
viene eseguita direttamente sui protocolli del livello di collegamento fisico.

\begin{figure}[!htb]
  \centering \includegraphics[scale=0.5]{images/ettercap10}
\caption{La schermata di \texttt{ettercap} con la lista delle connessioni
  rilevate nell'intercettazione del traffico fra due macchine.} 
\label{fig:ids_ettercap_conn_list}
\end{figure}

Una volta effettuato l'\textsl{avvelenamento} il programma potrà (se si è
attivata la cattura dei pacchetti) intercettare il traffico fra le macchine
sottoposte all'attacco, ed osservare le connessioni di rete fra queste. Le
connessioni riconosciute da \texttt{ettercap} vengono riportate in una tabella
come quella riportata in fig.~\ref{fig:ids_ettercap_conn_list} cui si accede
dalla voce \textsf{Connections} del menù \textsf{View} o premendo
``\texttt{C}''.

Selezionando (tramite le frecce) la connessione che si vuole intercettare e
premendo invio si potrà accedere ai contenuti del traffico della stessa,
presentato in due finestre affiancate per indicare le due direzioni dello
stesso (se disponibili), come mostrato in
fig.~\ref{fig:ids_ettercap_conn_cont}.  Il programma comunque è in grado di
riconoscere il passaggio in chiaro delle password sui principali protocolli e
quando rilevate le stampa direttamente sull'area di notifica in basso.

\begin{figure}[!htb]
  \centering \includegraphics[scale=0.5]{images/ettercap11}
  \caption{La schermata di \texttt{ettercap} con il traffico intercettato in
    una connessione.}
\label{fig:ids_ettercap_conn_cont}
\end{figure}

Le altre tecniche di attacco sono meno efficaci, e pertanto meno
utilizzate. Quella denominata \textit{ICMP redirect} si basa sull'invio alla
propria vittima dei menzionati di ``\textsl{falsi}'' pacchetti ICMP di questo
tipo con l'IP del gateway, che indicano la propria macchina come migliore
strada di uscita, in questo modo la vittima invierà il suo traffico in uscita
verso \texttt{ettercap},\footnote{a meno che non sia stata configurata per non
  accettare questi pacchetti, questo su Linux può essere fatto scrivendo uno
  zero sul file \texttt{accept\_redirects} dentro la sottodirectory di
  \texttt{/proc/sys/net/ipv4/conf/} relativa a ciascuna interfaccia.} che
provvederà a reinviarlo al gateway dopo averlo intercettato.

Questa tecnica consente di intercettare soltanto i pacchetti in uscita verso
internet, non è possibile però ottenere le risposte, perché il gateway non
accetterà mai un \textit{ICMP redirect} per una rete a cui ha già accesso
diretto, pertanto si avrà solo una metà della connessione. 

Un attacco dagli effetti analoghi è quello denominato \textit{DHCP spoofing}
in cui \texttt{ettercap} si finge un server DHCP e cerca di sostituirsi a
quello reale nel fornire una risposta alla vittima, in cui indica se stesso
come gateway. In questo modo di nuovo la vittima invierà verso l'attaccante i
pacchetti destinati alle connessioni la rete esterna, che provvederà a
reinviarli al vero gateway dopo averli intercettati. Anche in questo caso si
potrà osservare solo una metà del traffico (quello in uscita).


\subsection{I \textit{security scanner}}
\label{sec:ids_nessus}

Un \textit{security scanner} è un programma in grado analizzare una rete alla
ricerca di servizi vulnerabili. In genere esso è pure in grado di compiere
direttamente una serie di attacchi per verificare l'effettiva vulnerabilità
dei servizi rilevati, con maggiore o minore profondità e dettaglio a seconda
della implementazione. 

Di nuovo si tratta di uno strumento che può essere usato sia da un attaccante
che da chi deve provvedere alla sicurezza del sistema. In questo caso è di
fondamentale importanza per tenere sotto controllo la propria rete, e come
mezzo preventivo per rilevare potenziali problemi prima che lo faccia qualcuno
con intenzioni peggiori delle vostre. 

Il problema principale che si può avere con un \textit{security scanner} è
dovuto al fatto che quelli più evoluti eseguono la ricerca ed il rilevamento
delle vulnerabilità attaccando effettivamente i servizi
disponibili,\footnote{alcuni programmi o test si limitano ad una banale
  verifica della versione del servizio usato, da confrontare contro un elenco
  di versioni vulnerabili.}  per cui il loro uso può causare malfunzionamenti
dei servizi, la loro interruzione, ed addirittura, nel caso di sistemi
operativi poco stabili, al crash della macchina.

Per questo motivo l'uso di uno \textit{scanner} su macchine in produzione può
essere estremamente pericoloso, e si deve sempre stare attenti a quello che si
fa per non mettere a rischio i propri servizi. Inoltre si deve essere
consapevoli che l'uso di uno \textit{scanner} è del tutto equivalente ad un
tentativo di intrusione, ed è necessario essere certi di avere anche il
diritto legale di poter compiere una attività potenzialmente pericolosa per il
sistema informatico che si vuole esaminare. 

Un altro problema comune degli \textit{scanner} è quello dell'affidabilità
delle loro rilevazioni. Un primo problema è che è possibile che eventuali
vulnerabilità presenti non vengano rilevate (i cosiddetti \textsl{falsi
  negativi}). Questo avviene perché una vulnerabilità, pur essendo stata
scoperta, non è detto sia fra quelle verificate dal programma che si sta
usando, per questo conviene sempre utilizzare uno \textit{scanner} che
fornisca un meccanismo di aggiornamento e comunque interessarsi a come detto
aggiornamento viene effettuato. 

Il secondo problema è quello della rilevazione di vulnerabilità inesistenti (i
cosiddetti \textit{falsi positivi}), in genere per l'utilizzo di test
difettosi, o basati solo sul controllo della versione dei servizi.  Questo è
un caso molto comune e può facilmente causare dei falsi positivi in quanto è
del tutto normale, come fa tra l'altro Debian per le sue distribuzioni
stabili, correggere i problemi di sicurezza con degli opportuni patch, senza
aggiornare tutto il programma, che così viene riportato, non essendo cambiata
la versione, come vulnerabile.

In entrambi i casi è comunque regola da seguire quella di prendere le
segnalazioni di uno \textit{scanner} per quello che sono: un'utile traccia per
tenere sotto controllo la presenza di servizi inutili o obsoleti, da rimuovere
o aggiornare, e non la certificazione della sicurezza o meno di una rete.
Anche un risultato negativo non deve comunque lasciare tranquilli, gli
\textit{scanner} possono solo controllare le vulnerabilità loro note, e non
può quindi sostituire una politica di controllo degli accessi basata su
firewall o sugli altri meccanismi di protezione interni ai servizi.

Fino a qualche anno fa nel caso di GNU/Linux parlare di \textit{scanner} di
sicurezza significava sostanzialmente parlare di \textit{Nessus}. Dalla
versione 3 però il programma è diventato proprietario, ed è stato sostituito
da un fork portato avanti da un progetto denominato \textit{OpenVAS}
(\textit{Open Vulnerability Assessment System}), che ha ripreso il codice
della ultima versione libera e lo ha sviluppato. Come per la versione da cui
origina, anche \textit{OpenVAS} è un programma di analisi modulare basato su
plug-in ed una architettura client/server. La potenza del programma consiste
esattamente nella combinazione in questi due aspetti, che lo rendono un
sistema di analisi potente e flessibile.

Avendo a disposizione una architettura in cui il server è la parte che si
occupa di eseguire i test di sicurezza, si possono dislocare diversi server su
diverse macchine, in modo da avere diversi punti di vista sulla stessa
rete. L'architettura a plug-in consente inoltre una grande flessibilità nella
gestione dei test da eseguire, ciascuno di essi infatti è scritto in forma di
plug-in, sia in C, che in un linguaggio di scripting dedicato, il NASL
(\textit{Nessus Attack Scripting Language}), progettato per scrivere con
facilità nuovi test di sicurezza. É pertanto anche molto semplice avere
estensioni e nuovi test, ed esiste un database on-line continuamente
aggiornato dagli sviluppatori.

La struttura del programma si è molto evoluta, e nelle versioni più recenti le
funzionalità sono state suddivise in diversi demoni separati e specializzati
che comunicano via rete e che possono essere interrogati dai relativi client
per raccogliere informazioni ed elaborare rapporti, mentre in precedenza
prevedevano semplicemente un programma client che pilotava direttamente il
server che eseguiva le scansioni.

\begin{figure}[!htb]
  \centering \includegraphics[width=10cm]{images/openvas}
\caption{Architettura delle varie componenti di OpenVAS.} 
\label{fig:openvas_architecture}
\end{figure}

L'architettura di OpenVAS nelle versioni più recenti è schematicamente
illustrata in fig.~\ref{fig:openvas_architecture}; il cuore del sistema è
\texttt{openvassd}, l'\textit{OpenVAS Scanner}, un demone che attinge ad un
elenco di \textit{Network Vulnerability Test} (NVT, nella nomenclatura del
programma) ed esegue direttamente le scansioni che gli vengono richieste
attraverso l'uso di un protocollo di comunicazione chiamato OTP
(\textit{OpenVAS Transfer Protocol}).

I client però non interagiscono direttamente con lo scanner, ma si appoggiano
ad un demone di gestione, \texttt{openvasmd}, l'\textit{OpenVAS Manager}, che
cura l'interazione fra gli stessi, cui offre un protocollo di comunicazione
denominato OMT (\textit{OpenVAS Management Protocol}) e lo \textit{scanner}
per gestire richieste e risposte tramite il protocollo OTP. Inoltre il manager
si appoggia al demone \texttt{openvasad}, l'\textit{OpenVAS Administrator},
che gestisce gli i criteri di accesso e gli utenti di OpenVAS, utilizzando il
protocollo OAP (\textit{OpenVAS Administration Protocol}) fornito da
quest'ultimo.

A queste tre componenti server si aggiungono i vari client che consentono agli
utenti di richiedere le scansioni ed ottenere i relativi risultati (che in
genere interagiscono sia con \texttt{openvasmd} via OMP che con
\texttt{openvasad} via OAP.  Il programma ne prevede ben tre, un programma a
riga di comando, un programma con interfaccia grafica, ed una applicazione
web.

Fra le distribuzioni solo Debian forniva un pacchetto ufficiale che però è
piuttosto arretrata rispetto allo sviluppo corrente\footnote{al momento della
  stesura di queste note la versione corrente è la 6.0, mentre su Debian
  Squeeze è disponibile il pacchetto della 2.0 e sulle versioni successive il
  pacchetto del programma non viene più fornito.}  il progetto comunque
distribuisce direttamente dal suo sito web (\url{http://www.openvas.org})
versioni in pacchetti delle varie versioni già pronte per le principali
distribuzioni, con tanto di istruzioni, per cui non staremo a trattare i
dettagli dell'installazione.

Una volta che si siano installate tutte le componenti il sistema prevede che
tutte le comunicazioni siano cifrate con SSL ed è pertanto necessario generare
sia i certificati che la relativa \textit{Certification Authority}; questo può
essere fatto direttamente in fase di installazione se previsto nei pacchetti,
o manualmente in un secondo tempo, i vari file vengono installati sotto
\texttt{/var/lib/openvas/CA/} per i certificati e sotto
\texttt{/var/lib/openvas/private/CA/} per le chiavi.

Per generare manualmente i certificati usati dallo \textit{scanner} e la
relativa \textit{Certification Authority} si può usare il comando
\index{comando!\texttt{openvas-mkcert}} \texttt{openvas-mkcert} che richiede
l'inserimento delle solite informazioni illustrate in
tab.~\ref{tab:x509_informations}. Se i file esistono già il comando ne stampa
il pathname rifiutandosi di proseguire fintanto che non si specifica l'opzione
\texttt{-f} che forza la sovrascrittura; il comando può eseguire una
generazione veloce con l'opzione \texttt{-q} in cui vengono inseriti valori
predefiniti per le informazioni di tab.~\ref{tab:x509_informations}, senza
stare a richiederle interattivamente, si avrà pertanto un risultato del tipo:
\begin{Console}
# \textbf{openvas-mkcert -q}
/var/lib/openvas/private/CA created
/var/lib/openvas/CA created
\end{Console}

Come illustrato in fig.~\ref{fig:openvas_architecture} lo scanner viene
realizzato dal demone \index{demone!\texttt{openvassd}} \texttt{openvassd} che
viene lanciato dallo script \texttt{/etc/init.d/openvas-scanner} (si tenga
presente che almeno su Debian l'installazione non imposta l'avvio automatico
di questi servizi, che devono essere attivati esplicitamente). Se eseguito a
riga di comando il programma parte in modalità demone; per lanciarlo in
maniera interattiva e farlo restare collegato sul terminale occorre
specificare l'opzione \texttt{-f}. 

Di default il servizio si pone in ascolto solo su \texttt{localhost}, e sarà
quindi raggiungibile in maniera diretta solo localmente, se lo si vuole in
ascolto su un indirizzo generico occorrerà utilizzare l'opzione
\texttt{-a}. Su Debian sia l'indirizzo che la porta su cui \texttt{openvassd}
si pone in ascolto vengono impostati in \texttt{/etc/default/openvas-scanner}
e sono utilizzati dallo script di avvio per lanciare opportunamente il demone.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|p{10cm}|}
    \hline
    \textbf{Opzione}&\textbf{Descrizione}\\
    \hline
    \hline
    \texttt{-c \textsl{file}}& usa il file di configurazione specificato al
                               posto di \texttt{/etc/openvas/openvassd.conf}.\\
    \texttt{-a \textsl{addr}}& specifica l'indirizzo IP su ascolta il demone,
                               il default è \texttt{127.0.0.1}.\\ 
    \texttt{-p \textsl{port}}& specifica la porta su cui si pone in ascolto il
                               server (il default è 9391).\\ 
    \texttt{-S \textsl{ip1},...}& specifica la lista degli indirizzi che
                               verranno usati come IP sorgente nelle scansioni
                               (devono essere fra quelli assegnati alla
                               macchina).\\
    \texttt{-f}      & mantiene il server attivo sul terminale.\\
    \texttt{-s}      & stampa le opzioni di configurazione.\\
%    \texttt{-} & .\\
    \hline
  \end{tabular}
  \caption{Principali opzioni di \texttt{openvassd}.} 
  \label{tab:ids_openvassd_options}
\end{table}

Le altre opzioni principali di \texttt{openvassd} sono riportate in
tab.~\ref{tab:ids_openvassd_options}, l'elenco completo è nella pagina di
manuale (accessibile con \texttt{man openvassd}). Nella stessa pagina di
manuale sono indicate anche le direttive che possono essere usate nel file di
configurazione del programma,
\index{configurazione!\texttt{/etc/openvas/openvassd.conf}}
\texttt{/etc/openvas/openvassd.conf}, che consentono di impostare le posizione
dei vari file e directory ed una serie di altre caratteristiche di
funzionamento. Il file ha la forma di una direttiva assegnata al relativo
valore; se il file non è presente il programma funziona ugualmente, assumendo
che si vogliano usare i valori di default. La configurazione corrente può
essere stampata con l'opzione \texttt{-s}.

Una volta lanciato lo \textit{scanner} il secondo passo per utilizzare
\textit{OpenVAS} è attivare il \textit{manager} con il demone
\texttt{openvasmd}. Anche in questo caso la cosa deve essere fatta
esplicitamente tramite lo script di avvio
\texttt{/etc/init.d/openvas-manager}, ma perché questo sia possibile occorrono
alcune operazioni preliminari, occorre infatti, perché questo possa comunicare
con lo \textit{scanner}, predisporre un opportuno certificato client. Per far
questo si può usare il comando \index{comando!\texttt{openvas-mkcert-client}}
\texttt{openvas-mkcert-client}.

Il comando consente di creare un certificato client per la connessione allo
scanner, per questo deve essere lanciato con l'opzione \texttt{-n} seguita dal
nome dell'utente, che verrà registrato anche come utente per lo
\textit{scanner}, l'opzione \texttt{-i} installa il certificato per l'uso da
parte del \textit{manager}. Seguendo quanto indicato nelle istruzioni di
installazione ed utilizzando \texttt{om} come nome utente, sarà cioè
necessario eseguire il comando:
\begin{Console}
# \textbf{openvas-mkcert-client -n om -i}
Generating RSA private key, 1024 bit long modulus
..++++++
......................................................................++++++
e is 65537 (0x10001)
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [DE]:State or Province Name (full name) [Some-State
]:Locality Name (eg, city) []:Organization Name (eg, company) [Internet Widgits 
Pty Ltd]:Organizational Unit Name (eg, section) []:Common Name (eg, your name or
 your server's hostname) []:Email Address []:Using configuration from /tmp/openv
as-mkcert-client.13157/stdC.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'DE'
localityName          :PRINTABLE:'Berlin'
commonName            :PRINTABLE:'om'
Certificate is to be certified until Dec 26 16:38:54 2012 GMT (365 days)

Write out database with 1 new entries
Data Base Updated
User om added to OpenVAS.
\end{Console}

Una volta predisposto il certificato si potrà avviare il \textit{manager}, il
comando prevede come opzioni principali \texttt{-p}, per impostare la porta su
cui ascolta per le connessioni, e \texttt{-s} per impostare la porta su cui
contattare lo \textit{scanner}; nel caso di Debian queste impostazioni sono
mantenute nel file \texttt{/etc/default/openvas-manager} ed utilizzate
direttamente dallo script di avvio per lanciare il demone.

Il comando inoltre prevede le due opzioni speciali \texttt{-{}-rebuild} e
\texttt{-{}-update} per rispettivamente ricostruire e aggiornare il database
delle informazioni ottenute dallo \textit{scanner}. Le altre opzioni
principali sono riportate in tab.~\ref{tab:ids_openvasmd_options}, per
l'elenco completo si rimanda al solito alla pagina di manuale accessibile con
\texttt{man openvasmd}.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|l|}
    \hline
    \textbf{Opzione}&\textbf{Descrizione}\\
    \hline
    \hline
    \texttt{-p \textsl{port}} & indica la porta su cui il servizio è in
                                ascolto.\\ 
    \texttt{-s \textsl{port}} & indica la porta su cui contattare lo
                                \textit{scanner}.\\ 
    \texttt{-a \textsl{addr}} & specifica l'indirizzo IP su cui il servizio è
                                in ascolto.\\ 
    \texttt{-l \textsl{addr}} & specifica l'indirizzo IP su cui contattare lo
                                \textit{scanner}.\\  
    \texttt{-{}-update} & aggiorna il database delle informazioni dallo
                          \textit{scanner}.\\ 
    \texttt{-{}-rebuild}& ricostruisce il database delle informazioni dallo
                          \textit{scanner}.\\  
%    \texttt{-} & .\\ 
    \hline
  \end{tabular}
  \caption{Principali opzioni di \texttt{openvasmd}.} 
  \label{tab:ids_openvasmd_options}
\end{table}

Come accennato una delle caratteristiche più interessanti di \textit{OpenVAS}
è quella di eseguire le scansioni tramite l'uso dei \textit{Network
  Vulnerability Test}, che sono distribuiti in maniera indipendente dal
programma. Per la gestione degli NVT viene fornito un apposito programma,
\index{comando!\texttt{openvas-nvt-sync}} \texttt{openvas-nvt-sync}; se si è
in rete il programma si incarica di scaricare automaticamente le ultime
versioni di tutti i test di sicurezza dal sito del progetto ed installarle
nella relativa directory (il default è \texttt{/var/lib/openvas/plugins}). Una
volta scaricati la prima volta il grosso degli NVT per ottenere gli eventuali
aggiornamenti basterà rieseguire il comando. Un esempio di uso del comando è
il seguente:
\begin{Console}
# \textbf{openvas-nvt-sync} 
[i] This script synchronizes an NVT collection with the 'OpenVAS NVT Feed'.
[i] The 'OpenVAS NVT Feed' is provided by 'The OpenVAS Project'.
[i] Online information about this feed: 'http://www.openvas.org/openvas-nvt-feed.html'.
[i] NVT dir: /var/lib/openvas/plugins
[i] rsync is not recommended for the initial sync. Falling back on http.
[i] Will use wget
...
zyxel_pwd.nasl
zyxel_pwd.nasl.asc
[i] Download complete
[i] Checking dir: ok
[i] Checking MD5 checksum: ok
\end{Console}

Una volta scaricati i test occorrerà reinizializzare il sistema, per questo
sarà necessario fermare i servizi e riavviarli, in particolare sarà necessario
riavviare manualmente lo \textit{scanner} per fargli eseguire il caricamento
iniziale degli NVT, che è una operazione piuttosto lunga in quanto questi sono
alcune decine di migliaia. Pertanto il semplice riavvio del servizio risulterà
piuttosto lento, lanciando invece \texttt{openvassd} su un terminale si
otterrà qualcosa del tipo:
\begin{Console}
# \textbf{openvassd}
Loading the plugins... 10302 (out of 23988)
...
All plugins loaded                                   
\end{Console}
vedendo un progressivo crescere del numero fino al completamento del
caricamento.  Il passo successivo è riavviare anche il \textit{manager}
riaggiornando per la presenza dei nuovi test, per questo le istruzioni di
installazione consigliano l'esecuzione preventiva dei comandi:
\begin{Console}
# \textbf{openvasmd --rebuild}
\end{Console}
che consentono di ricostruire (o creare quando eseguiti la prima volta) il
database delle informazioni, senza il quale il programma non parte, a questo
si aggiunge la compilazione dei dati informativi SCAP (\textit{Security
  Content Automation Protocol}) e CERT (\textit{Computer Emergency Readiness
  Team}) relativi alle vulnerabilità che si ottengono con i comandi:
\begin{Console}
# \textbf{openvas-scapdata-sync}
# \textbf{openvas-certdata-sync}
\end{Console}

Una volta avviati lo \textit{scanner} ed il \textit{manager} il terzo servizio
necessario per usare \textit{OpenVAS} è l'\textit{administrator}, realizzato
dal programma \texttt{openvasad}. 


\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|p{8cm}|}
    \hline
    \textbf{Opzione}&\textbf{Descrizione}\\
    \hline
    \hline
    \texttt{-a \textsl{addr}} & specifica l'indirizzo IP su cui il servizio è
                                in ascolto.\\ 
    \texttt{-p \textsl{port}} & indica la porta su cui il servizio è in
                                ascolto.\\ 
    \texttt{-c \textsl{cmd}}  & esegue un comando OAP (valori possibili
                                \texttt{add\_user}, \texttt{remove\_user},
                                \texttt{list\_users}).\\
    \texttt{-r \textsl{role}} & indica il ruolo da assegnare quando si crea un
                                utente, può assumere i valori \texttt{admin} o
                                \texttt{user}.\\
    \texttt{-n \textsl{nome}} & indica il nome utente.\\ 
    \texttt{-w \textsl{pass}} & indica la password.\\ 
    \texttt{-f}      & mantiene il server attivo sul terminale.\\
%    \texttt{-} & .\\ 
    \hline
  \end{tabular}
  \caption{Principali opzioni di \texttt{openvasad}.} 
  \label{tab:ids_openvasad_options}
\end{table}

Si tenga presente inoltre che i precenti passi riguardano solo
l'autenticazione e cifratura del dialogo fra le sue componenti; oltre a questo
\textit{OpenVAS} supporta un suo database indipendente degli utenti, in modo
da poter gestire chi si può collegare ai servizi e quali test può eseguire.
Pertanto per poterlo utilizzare si deve prima creare almeno un utente con il
comando \index{comando!\texttt{openvas-adduser}} \texttt{openvas-adduser};
questo è di uso immediato e si limita richiedere i dati dello stesso sul
terminale con qualcosa del tipo:
\begin{Console}
# \textbf{openvas-adduser} 
Using /var/tmp as a temporary file holder.

Add a new openvasd user
---------------------------------


Login : \textbf{piccardi}
Authentication (pass/cert) [pass] : 
Login password : 
Login password (again) : 

User rules
---------------
openvasd has a rules system which allows you to restrict the hosts that piccardi has the right to test.
For instance, you may want him to be able to scan his own host only.

Please see the openvas-adduser(8) man page for the rules syntax.

Enter the rules for this user, and hit ctrl-D once you are done:
(the user can have an empty rules set)


Login             : piccardi
Password          : ***********

Rules             : 


Is that ok? (y/n) [y] \textbf{y}
user added.
\end{Console}

Il programma chiede un username e un metodo di autenticazione che per default
(selezionato premendo invio) è tramite password, che dopo deve essere immessa
per due volte (la seconda per conferma) la password. Di seguito possono essere
specificate delle regole di accesso. Le regole prendono le parole chiavi
\texttt{accept} e \texttt{deny} (il cui significato è evidente) seguite da una
rete specificata in notazione CIDR. È inoltre possibile utilizzare la parola
chiave \texttt{default} per indicare una politica di accesso di default; un
esempio, preso dalla pagina di manuale, è il seguente:
\begin{Example}
accept 192.168.1.0/24
accept 192.168.3.0/24
accept 172.22.0.0/16
default deny
\end{Example}
queste devono essere immesse come testo una per riga e l'immissione deve
essere conclusa con l'invio di un carattere di \textit{end-of-file} (vale a
dire \texttt{C-d}). 

Completata l'immissione delle regole (che in genere si può lasciare vuota
premendo subito \texttt{ctrl-D}) viene stampato un riassunto delle
impostazioni di cui il programma chiede conferma. Sempre sulla pagina di
manuale si trovano tutte le istruzioni dettagliate relative al funzionamento
del comando. È altresì disponibile il comando
\index{comando!\texttt{openvas-rmuser}} \texttt{openvas-rmuser} che consente
di rimuovere un utente con qualcosa del tipo:
\begin{Console}
# \textbf{openvas-rmuser}
Login to remove : \textbf{piccardi}
user removed. 
\end{Console}

Una volta eseguite le predecenti operazioni di preparazione (impostare un
utente, aggiornare i plug-in, avviare il server) si potrà lanciare il client
con il comando \texttt{openvas}. Questo è un programma ad interfaccia grafica,
che partirà con la finestra principale posizionata sulla sezione di login,
secondo quanto illustrato in fig.~\ref{fig:ids_openvas2}.

\begin{figure}[!htb]
  \centering \includegraphics[scale=0.5]{images/nessus2}
\caption{Finestra di login di \texttt{openvas}.} 
\label{fig:ids_openvas2}
\end{figure}

Come si può notare gran parte della finestra del programma è occupata
dal selettore delle funzionalità, che si scelgono con le linguette in
alto; la parte più bassa della finestra contiene tre bottoni che
consentono rispettivamente di avviare la scansione, di caricare i
risultati di una scansione precedente o di uscire dal programma. La
sezione centrale contiene la parte di finestra relativa alle varie
funzionalità, che nel caso del login è divisa in due parti: in quella
superiore sono disposti i campi per scegliere il server a cui
collegarsi, specificandone indirizzo e porta, mentre nella parte
inferiore ci sono i campi per l'username e la password, da fornire per
poter utilizzare il server.

Una volta immessi username e password e premuto il pulsante per il
login, quando ci si collega la prima volta si presenterà una finestra
di accettazione del certificato SSL, passata la quale il programma si
sposterà da solo nella sezione di selezione dei plugin, illustrata in
fig.~\ref{fig:ids_openvas3}, avvisando al contempo, con una ulteriore
finestra in pop-up, che i plug-in potenzialmente pericolosi sono stati
disabilitati.

\begin{figure}[!htb]
  \centering \includegraphics[scale=0.5]{images/nessus3}
\caption{Finestra di selezione dei plugin di \texttt{openvas}.} 
\label{fig:ids_openvas3}
\end{figure}

Nella sezione di selezione dei plugin la parte alta della finestra mostra le
classi di attacchi possibili, elencate una per riga, con una checkbox che
mostra se la classe è abilitata o meno.  Selezionando una riga con il mouse
vengono mostrati tutti i plugin contenuti nella relativa classe nella parte
bassa della finestra, uno per riga, contenente, oltre la solita checkbox, pure
una eventuale icona che identifica il plugin come \textsl{pericoloso}. 
Selezionando uno di questi col mouse viene visualizzata una finestra con una
breve descrizione della vulnerabilità e del comportamento del plugin. 

Nella parte centrale della finestra una serie di bottoni consentono di
impostare i plugin da utilizzare, consentendo ad esempio di abilitare
solo quelli non classificati \textsl{pericolosi}. Questi ultimi sono
quelli che, qualora attivati, tentano una verifica diretta delle
vulnerabilità e possono pertanto causare il crash dei rispettivi
servizi (e con Windows in vari casi anche del sistema operativo). Si
tenga presente comunque che la classificazione è basata sulla
esperienza dell'autore del plugin, e non c'è nessuna assicurazione sul
fatto che un plugin non classificato pericoloso non lo sia
davvero. Pertanto si eviti di usare \texttt{openvas} nei confronti di
macchine in produzione, a meno di non essere disposti a correre il
rischio di renderle non più tali.

Una volta scelti i plugin che si vogliono utilizzare, prima di poter
iniziare una scansione, occorre selezionare il bersaglio della
stessa. Questo si fa dalla sezione \textsf{Target selection} della
finestra principale, come illustrato in fig.~\ref{fig:ids_openvas4}. Il
bersaglio può essere immesso nel relativo campo (o letto anche da un
file). Basta inserire un indirizzo di una macchina o quello di una
rete in notazione CIDR. Se si usa un indirizzo simbolico relativo ad
un dominio la relativa checkbox permette di ottenere dal DNS un elenco
delle macchine presenti nello stesso attraverso un trasferimento di
zona. La parte bassa della finestra contiene i risultati delle
precedenti sessioni di scansione, che vengono salvate se si attiva la
relativa checkbox.

\begin{figure}[!htb]
  \centering \includegraphics[scale=0.5]{images/nessus4}
\caption{Finestra dei bersagli della scansione di \texttt{openvas}.} 
\label{fig:ids_openvas4}
\end{figure}

Le restanti sezioni permettono di configurare altre funzionalità; le
principali sono quella per le opzioni relative alle singole scansioni
(\textsf{Scan option}), in cui si può stabilire l'intervallo di porte da
esaminare, le modalità di uso del portscanner ed altre opzioni relative alla
esecuzione della scansione, e quella delle preferenze (\textsf{Prefs.})  che
permette di specificare tutta una lunga serie di impostazioni relative alle
modalità con cui \texttt{openvas} esegue i vari programmi a cui si
appoggia.\footnote{ad esempio Openvas utilizza \texttt{nmap} per eseguire un
  portscan preliminare per determinare su quali porte sono presenti servizi, e
  può invocare ulteriori programmi esterni come Hydra per cercare di eseguire
  un attacco a forza bruta per il login su servizi che richiedono
  autenticazione.}

Completate le impostazioni si potrà avviare la scansione, ed il server
inizierà le sue operazioni (si tenga presente che la cosa può richiedere molto
tempo) durante le quali il client mostrerà una finestra di progresso del tipo
di quella riportata in fig.~\ref{fig:ids_openvas5}. Nel nostro caso si è
eseguita una scansione su una sola macchina, che è l'unica riportata, ma
\texttt{openvas} consente di analizzare anche intere reti, nel qual caso la
finestra riporterà lo stato di tutte le scansioni in corso. La finestra
consente, coi relativi pulsanti, di interrompere le singole scansioni o una
intera sessione.

\begin{figure}[!htb]
  \centering \includegraphics[scale=0.5]{images/nessus5}
\caption{Finestra del progresso delle operazioni di \texttt{openvas}.} 
\label{fig:ids_openvas5}
\end{figure}

Una volta completata la scansione \texttt{openvas} genererà un rapporto
dei risultati ottenuti in una finestra apposita, come quella riportata
in fig.~\ref{fig:ids_openvas6}. Questa riassume sulla sinistra in alto
la lista reti analizzate, selezionando una rete comparirà in basso la
lista delle macchine ivi presenti per le quali si è eseguita la
scansione. Una volta selezionata una macchina compariranno nella parte
alta a destra due ulteriori sotto-finestre, la prima contenente la
lista dei servizi che sono stati rilevati, affiancati da una icona che
identifica la gravità di eventuali problemi (assente se non ve ne
sono) affiancata a destra da un elenco dei problemi rilevati.
Selezionando uno dei problemi per i quali esiste un rapporto
quest'ultimo verrà mostrato nella parte inferiore della finestra. Un
apposito pulsante consente di salvare l'intero rapporto su disco in
diversi formati, compreso quello di una directory contenente grafici e
dati in formato HTML pronti per essere pubblicati su web.
 
\begin{figure}[!htb]
  \centering \includegraphics[scale=0.5]{images/nessus6}
\caption{Finestra dei rapporti dei risultati di \texttt{openvas}.} 
\label{fig:ids_openvas6}
\end{figure}


\subsection{I monitor di rete}
\label{sec:ids_monitor}

Benché non si tratti strettamente di strumenti di ricerca di vulnerabilità,
vale la pena parlare di una serie di programmi che servono per fare delle
sommarie analisi del traffico, che possono essere di aiuto ad identificare
traffico sospetto. La differenza principale fra questi programmi e un NIDS è
che essu è che questi in genere servono per scopi diversi (più che altro
monitoraggio) dalla rilevazione di intrusioni, anche se poi tornano utili per
le informazioni che sono in grado di fornire.

Il primo di questi programmi è \index{comando!\texttt{iptraf}}
\texttt{iptraf}, una specie di incrocio fra uno \textit{sniffer} vero e un
programma per l'analisi del traffico, \texttt{iptraf} utilizza una interfaccia
utente semplice, che lavora comunque in modalità testuale, basata sulle
librerie \textsl{ncurses}.

\begin{figure}[!htb]
  \centering \includegraphics[scale=0.5]{images/iptraf2}
\caption{Menù principale di \texttt{iptraf}.} 
\label{fig:ids_iptraf2}
\end{figure}

L'uso del programma è immediato in quanto basato su menù e maschere, sia pure
testuali; una volta lanciato ci presenterà la schermata di avvio, e basterà
premere un tasto per ottenere il menù principale delle opzioni, riportato in
fig.~\ref{fig:ids_iptraf2}. 

Questo presenta molteplici opzioni, e per entrare nel dettaglio di tutte le
possibilità offerte dal programma conviene leggere la documentazione allegata,
che nel caso di Debian viene installata in \texttt{/usr/share/doc/iptraf}; in
particolare può essere di aiuto il manuale d'uso presente nella sottodirectory
\texttt{html}, che illustra le molteplici funzionalità del programma. 

Le funzionalità di analisi \texttt{iptraf} sono elencate nella parte superiore
del menù di fig.~\ref{fig:ids_iptraf2}, e possono essere selezionate
spostandosi con i tasti di freccia e premendo invio una volta posizionati su
quella prescelta.  Si possono inoltre impostare le configurazioni tramite
l'apposita voce del menù, così come si possono creare dei filtri (utilizzando
una serie di maschere accessibili una volta selezionato la relativa voce). Non
entreremo nei dettagli di queste configurazioni ulteriori lasciando
l'esplorazione delle stesse come esercizio.

\begin{figure}[!htb]
  \centering \includegraphics[scale=0.5]{images/iptraf3}
\caption{Menù di selezione delle interfacce di \texttt{iptraf}.} 
\label{fig:ids_iptraf3}
\end{figure}

La prima voce del menù, \texttt{IP traffic monitor}, consente una analisi
dettagliata del traffico IP. Una volta selezionata verrà mostrato un ulteriore
menù di scelta (mostrato in fig.~\ref{fig:ids_iptraf3}) che permette di
selezionare l'interfaccia di rete su cui porsi in ascolto (o di ascoltare su
tutte quante); si potrà selezionare una delle voci del menù spostandosi con i
tasti di freccia e poi attivarla premendo invio. Selezionata l'interfaccia
verrà attivata la finestra di osservazione del traffico, riportata in
fig.~\ref{fig:ids_iptraf4}, in cui vengono mostrati i risultati della cattura
dei pacchetti in tempo reale.

\begin{figure}[!htb]
  \centering \includegraphics[scale=0.5]{images/iptraf4}
\caption{Finestra del monitor del traffico di \texttt{iptraf}.} 
\label{fig:ids_iptraf4}
\end{figure}

Come si può notare in fig.~\ref{fig:ids_iptraf4} la finestra di osservazione è
suddivisa in due parti; la prima e più ampia, posta in alto, contiene il
traffico TCP, classificato automaticamente per connessioni. Ciascuna
connessione è indicizzata in prima colonna tramite la coppia
\texttt{indirizzo:porta} dei due estremi della connessione che sono riportate
su due righe adiacenti collegate. Le colonne successive indicano il numero di
pacchetti emessi nelle due direzioni, i flag attivi (presi dall'ultimo
pacchetto rilevato ed aggiornati in tempo reale) ed infine l'interfaccia di
provenienza degli stessi.

La seconda sezione della finestra, di dimensioni più ridotte e posta in basso
contiene invece i dati relativi al traffico dovuto a pacchetti non TCP,
riportando in prima colonna il nome del relativo protocollo. Nel caso
illustrato in fig.~\ref{fig:ids_iptraf4} è facile identificare il traffico
come relativo a delle richieste UDP effettuate sul DNS.

In questa seconda finestra vengono riassunte brevemente le informazioni
essenziali trovate nelle intestazioni dei relativi protocolli. Nel caso di UDP
viene mostrata prima la dimensione di ciascun pacchetto ed a seguire indirizzi
e porta sorgente e destinazione, per finire con l'interfaccia. Nel caso di
ICMP viene mostrato il tipo di pacchetto, seguito dalla dimensione e dagli
indirizzi sorgente e destinazione; al solito chiude l'interfaccia su cui è
stato catturato il pacchetto. 

Benché non si possa apprezzare dalle figure, entrambe le finestre di
osservazione sono \textsl{navigabili}. Si può passare dall'una all'altra con
il tasto di tabulazione, ed inoltre le finestre scorrono quando riempite, e
una volta posizionatisi su di esse ci si può muovere al loro interno con i
soliti tasti di freccia per rivedere il traffico precedente, ed effettuare uno
scroll con i tasti di pagina su e pagina giù. Chiude la finestra di
osservazione una riga riassuntiva sul numero di pacchetti catturati ed il
flusso di dati su TCP ed una di aiuto che riassume i tasti utilizzabili. 

Oltre alla osservazione dettagliata del flusso dei pacchetti, \texttt{iptraf}
consente anche la raccolta di statistiche relative all'uso della rete. Dalla
seconda voce del menù principale si ottiene una finestra di statistiche
generali (mostrata in fig.~\ref{fig:ids_iptraf5}), che raccoglie i dati
relativi a tutte le interfacce presenti sul sistema, e che riporta un sommario
delle informazioni essenziali relative a ciascuna interfaccia. 

\begin{figure}[!htb]
  \centering \includegraphics[scale=0.5]{images/iptraf5}
\caption{Finestra delle statistiche generali di \texttt{iptraf}.} 
\label{fig:ids_iptraf5}
\end{figure}

In questo caso viene riservata una riga per ogni interfaccia presente, il cui
nome viene indicato nella prima colonna. Seguono una serie di colonne che
riportano il totale dei pacchetti catturati ed una loro suddivisione
elementare in pacchetti IP, non IP, pacchetti IP rovinati, più una stima del
traffico sostenuto nella colonna finale, che comparirà solo quando è stata
raccolta una statistica sufficiente. Come per la finestra di osservazione i
dati vengono aggiornati in tempo reale.

A partire dalla terza voce del menù si può ottenere una finestra con
delle statistiche più dettagliate per ciascuna interfaccia di rete.
In questo caso prima di arrivare alla finestra illustrata in
fig.~\ref{fig:ids_iptraf6} si dovrà nuovamente scegliere l'interfaccia
da un menù, analogo a quello di fig.~\ref{fig:ids_iptraf3}, dopo di
che saranno mostrate le relative statistiche che mostrano non solo il
totale dei pacchetti ma anche la loro suddivisione per protocolli,
l'ammontare del traffico in byte, e l'andamento del traffico in
ingresso ed in uscita.

\begin{figure}[!htb]
  \centering \includegraphics[scale=0.5]{images/iptraf6}
\caption{Finestra delle statistiche dettagliate per interfaccia di
  \texttt{iptraf}.} 
\label{fig:ids_iptraf6}
\end{figure}

Come visto l'uso di un programma come \texttt{iptraf} consente sia di elencare
le connessioni presenti, che di ottenere delle statistiche generali sul
traffico, cosa che può essere di aiuto nella rilevazione di traffico anomalo,
oltre che per la semplice osservazione dello stato della propria rete.

Un secondo programma che consente di monitorare il traffico di rete è
\index{comando!\texttt{iptop}} \texttt{iftop}, il cui scopo è analogo a quello
di \texttt{iptraf}. Il programma in questo caso più semplice e non presenta
una interfaccia semigrafica tentando di porsi come applicazione del concetto
del comando \texttt{top} alle connessioni di rete. Il suo principale vantaggio
rispetto a \texttt{iptraf} è di essere in grado di segnalare, oltre alle
connessioni esistenti, la quantità di traffico su ciascuna di esse in tempo
reale ed in forma semigrafica, rendendo molto evidente eventuali anomalie.
 
\begin{figure}[!htb]
  \centering \includegraphics[scale=0.5]{images/iftop1}
\caption{Finestra di \texttt{iftop}.} 
\label{fig:ids_iftop1}
\end{figure}

Il comando non richiede nessun argomento o opzione obbligatoria, e se lanciato
senza specificare niente si pone in ascolto sulla prima interfaccia ethernet
attiva, stampando brevemente nome dell'interfaccia e relativo MAC address
prima di occupare l'intera area del terminale e mostrare ogni due secondi le
connessioni presenti, ordinate per quantità di traffico, come illustrato in
fig.~\ref{fig:ids_iftop1}. 

La schermata del comando riporta in alto la scala usata per illustrare la
quantità di traffico illustrata in forma di istogramma nelle righe seguenti;
ciascuna connessione occupa due righe (una per direzione del traffico) con
l'indicazione delle macchine fra cui avviene il traffico ed un riassunto del
rate rilevato (in bits/secondo) negli ultimi 2, 10 e 40 secondi. Lo stesso
valore viene visualizzato in forma grafica invertendo il colore della riga
corrispondente in modo da ottenere un istogramma del traffico in forma
orizzontale; per facilitare la visualizzazione viene usata una
rappresentazione logaritmica.


% TODO inserire trattazione della quarta opzione

% TODO inserire ntop e iftop


% Obsoleto
% Il primo di questi è \index{comando!\texttt{etherape}} \texttt{etherape}.
% Benché il programma sia nato solo per fornire una rappresentazione grafica
% piuttosto sommaria del traffico (si osservi l'esempio in
% fig.~\ref{fig:ids_etherape}), la immediatezza della presentazione dei dati
% permette di capire con facilità le origini del traffico, e la presenza di
% eventuali anomalie.

% \begin{figure}[!htb]
%   \centering \includegraphics[scale=0.5]{images/etherape1}
% \caption{Esempio di sessione di analisi del traffico di \texttt{etherape}.} 
% \label{fig:ids_etherape}
% \end{figure}

% In particolare diventa immediato identificare le fonti della maggior parte del
% carico e se alcune macchine presentano un traffico anomalo. Il programma
% rappresenta il traffico con delle linee di diversi colori fra i singoli host e
% identifica il tipo di traffico relativo a ciascun protocollo con il relativo
% colore riportato nella colonna a sinistra. 


Di fronte alle possibilità di intercettazione del traffico che un programma
come \texttt{ettercap} fornisce, l'unica contromisura possibile è l'uso di
\index{demone!\texttt{arpwatch}} \texttt{arpwatch}, un programma nato per
tenere sotto controllo una rete ethernet e segnalare la presenza di nuovi
indirizzi hardware e tutti gli eventuali cambiamenti nelle corrispondenze fra
MAC address e numeri IP. Il programma si mette in ascolto sulla rete e segnala
via e-mail tutti i cambiamenti rilevati; in questo modo dopo un periodo
iniziale di stabilizzazione in cui vengono identificate tutte le macchine
presenti si otterrà un avviso tutte le volte che un nuovo MAC address farà la
sua comparsa sulla rete.

Un programma di questo tipo è di grande aiuto per rilevare il traffico
sospetto generato localmente da utenti che cercano di evitare eventuali
controlli eseguiti a livello di IP andando ad operare direttamente su
ethernet, per rilevare i tentativi di \textit{ARP poisoning} e per verificare
l'ingresso di nuove macchine in una rete. 


Il funzionamento normale di \texttt{arpwatch} prevede che il programma venga
eseguito in background come demone analizzando tutto il traffico ARP
sull'interfaccia che gli viene specificata a riga di comando con l'opzione
\texttt{-i}, registrando le corrispondenze IP/MAC su un file che di default è
\texttt{arp.dat}.  Tutte le anomalie rilevate saranno inviate all'indirizzo
specificato con l'opzione \texttt{-m} tramite il comando specificato con
l'opzione \texttt{-s}. Le altre principali opzioni sono riportate in
tab.~\ref{tab:ids_arpwatch_option}, l'elenco completo è nella pagina di
manuale. 

\begin{table}[!htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|p{8cm}|}
    \hline
    \textbf{Opzione}&\textbf{Descrizione}\\
    \hline
    \hline
    \texttt{-d}  & abilita il debug ed esegue il programma
                   interattivamente. \\  
    \texttt{-f}  & specifica un file da cui leggere le corrispondenze fra
                   indirizzi IP e MAC, se diverso da \texttt{arp.dat}. \\ 
    \texttt{-i}  & specifica l'interfaccia su cui osservare il traffico (il
                   default è la prima). \\ 
    \texttt{-m}  & specifica l'indirizzo di e-mail cui inviare gli avvisi. \\ 
    \texttt{-p}  & disabilita il \textsl{modo promiscuo} per l'interfaccia. \\ 
    \texttt{-r}  & legge i dati da un file (passato come parametro) invece che
                   dall'interfaccia. \\ 
    \texttt{-s}  & specifica il programma da usare per inviare le e-mail di
                   avviso. \\  
%    \texttt{}  & . \\ 
    \hline
  \end{tabular}
  \caption{Le principali opzioni di \texttt{arpwatch}.} 
\label{tab:ids_arpwatch_option}
\end{table}

Il programma manda i suoi errori sul syslog, e necessita di un file
\texttt{arp.dat} (la directory usata di default è \texttt{/var/lib/arpwatch})
da cui leggere le coppie di corrispondenza fra indirizzi IP/MAC rilevate in
precedenza; se il file non esiste deve essere creato vuoto.  Inoltre nel caso
di Debian viene fornito uno script di avvio che legge il contenuto del file
\texttt{/etc/arpwatch.conf} e si mette in ascolto sulle interfacce ivi
specificate, inviando gli avvisi agli indirizzi ivi specificati; il file ha un
formato molto semplice, un estratto è:
\begin{FileExample}[label=arpwatch.conf]
eth0    -N -p -m root+eth0@example.com
eth1    -N -p -m root+eth1@example.com
\end{FileExample}
con il semplice formato di:
\begin{Example}
<interfaccia> <opzioni ...>
\end{Example}

Qualora vengano rilevate delle anomalie \texttt{arpwatch} genera dei messaggi
di allarme, che poi possono essere inviati via e-mail ad un amministratore, o
registrati sul \textit{syslog} (in genere entrambi). Un elenco di questi
messaggi, insieme al relativo significato, è riportato in
tab.~\ref{tab:ids_arpwatch_alarm}. 

\begin{table}[!htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|p{8cm}|}
    \hline
    \textbf{Messaggio}&\textbf{Descrizione}\\
    \hline
    \hline
    \texttt{new activity}            & rileva un nuovo abbinamento fra IP e
                                       MAC address.\\ 
    \texttt{new station}             & rileva un MAC address mai visto
                                       prima.\\ 
    \texttt{flip flop}               & l'indirizzo è passato da quello visto 
                                       per ultimo a quello visto
                                       come penultimo.\\ 
    \texttt{changed ethernet address}& L'indirizzo IP è passato ad un nuovo
                                       MAC address.\\ 
    \texttt{ethernet broadcast}      & si è osservato un indirizzo di
                                       broadcast in un MAC address o come
                                       sorgente in un pacchetto ARP.\\
    \texttt{ip broadcast}            & si è osservato un indirizzo di
                                       broadcast sull'IP di una macchina.\\
    \texttt{bogon}                   & si è rilevato un indirizzo IP non
                                       corrispondente alla sottorete su cui si
                                       affaccia l'interfaccia.\\
    \texttt{ethernet mismatch}       & il MAC address non corrisponde a quello
                                       indicato come sorgente nel pacchetto
                                       ARP.\\
    \texttt{reused old ethernet address}& analogo a \texttt{flip flop} ma
                                       il passaggio è riferito ad un indirizzo
                                       precedente il penultimo. \\ 
%    \texttt{}  & . \\ 
    \hline
  \end{tabular}
  \caption{I messaggi di allarme di \texttt{arpwatch}.} 
\label{tab:ids_arpwatch_alarm}
\end{table}

Un possibile esempio dell'utilizzo di \texttt{arpwatch} è il seguente. Appena
installato ed avviato il programma per la prima volta otterremo una serie di
e-mail del tipo:
\begin{FileExample}[label=arpwatch-new-station-mail]
X-Original-To: root+eth0@monk.truelite.it
From: Arpwatch <arpwatch@monk.truelite.it>
To: root+eth0@monk.truelite.it
Subject: new station (parker.truelite.it)

            hostname: parker.truelite.it
          ip address: 192.168.1.1
    ethernet address: 0:48:54:62:18:6f
     ethernet vendor: Digital Semi Conductor 21143/2 based 10/100
           timestamp: Monday, June 7, 2004 17:47:49 +0200
\end{FileExample}
per tutte le macchine presenti sulla rete. Se poi però proviamo ad utilizzare
\texttt{ettercap} per avvelenare la cache di \texttt{zorn.truelite.it}
otterremo anche:
\begin{FileExample}[label=arpwatch-changed-mail]
X-Original-To: root+eth0@monk.truelite.it
From: Arpwatch <arpwatch@monk.truelite.it>
To: root+eth0@monk.truelite.it
Subject: changed ethernet address (parker.truelite.it)

            hostname: parker.truelite.it
          ip address: 192.168.1.1
    ethernet address: 0:10:dc:c0:6c:b2
     ethernet vendor: Micro-Star International Co., Ltd. 
old ethernet address: 0:48:54:62:18:6f
 old ethernet vendor: Digital Semi Conductor 21143/2 based 10/100
           timestamp: Monday, June 7, 2004 17:53:39 +0200
  previous timestamp: Monday, June 7, 2004 17:52:49 +0200
               delta: 50 seconds
\end{FileExample}
il che ci mostra chiaramente come ci sia stato un tentativo di modificare la
scheda di rete a cui vengono inviati i pacchetti destinati all'indirizzo
\texttt{192.168.1.1}. 




\section{I \textsl{sistemi antintrusione locali}}
\label{sec:ids_local}

Come accennato in sez.~\ref{sec:ids_whatis} esistono varie tipologie di IDS,
in questa sezione ci occuperemo di quelli che si possono chiamare
\textsl{sistemi antintrusione locali}, cioè di quei programmi che permettono
di rilevare in tempo reale o verificare a posteriori eventuali tentativi di
intrusione su una singola macchina. 


\subsection{Programmi di verifica di sicurezza.} 
\label{sec:ids_chkrootkit}

Un programma di verifica di sicurezza è tutto sommato molto simile a
quello che potrebbe essere un \textit{antivirus} su un sistema non
unix-like; infatti benché con GNU/Linux per la struttura del sistema i
virus siano sostanzialmente inefficaci\footnote{nell'uso da parte di
un utente normale un virus non ha nessuna possibilità di modificare i
programmi di sistema, danneggiare quelli di altri utenti, o effettuare
una qualunque operazione privilegiata, per cui risulta di scarsa
efficacia.} l'installazione di un \textit{rootkit} o di un
\textit{trojan} da parte di un eventuale intruso che ha sfruttato una
vulnerabilità del sistema ha sostanzialmente lo stesso
effetto,\footnote{in realtà questo vale solo per i cosiddetti
\textit{worm}, \textit{rootkit} e \textit{trojan} hanno il solo scopo
di consentire all'attaccante un successivo accesso alla macchina,
anche se questa ha corretto la vulnerabilità, e non hanno normalmente
nessun effetto \textsl{infettivo} nei confronti di altre macchine.}
con la modifica di alcuni programmi di sistema e l'installazione di
altri che consentano un accesso da remoto.

Il principio di un programma di scansione di sicurezza è allora quello di
eseguire una serie di controlli per rilevare la presenza di eventuali
\itindex{rootkit} \textit{rootkit} o \itindex{trojan} \textit{trojan} sulla
base del comportamento degli stessi, (la cosiddetta \textit{signature}) che si
suppone nota in precedenza.  In sostanza, come per un antivirus, si ha a
disposizione un database dei \textit{rootkit} noti, e si analizza il sistema
alla ricerca delle modifiche che questi possono avere effettuato agli altri
programmi, all'inserimento di file e directory per eventuali \itindex{backdoor}
\textit{backdoor} e alla presenza di file di log (in cui in genere vengono
memorizzate le informazioni raccolte \textsl{sniffando} sia la rete che
l'attività sul sistema).

Il problema che si pone nell'uso di questo tipo di programmi è che essi sono
in grado di rilevare solo la presenza di \textit{rootkit}, \textit{trojan} o
\textit{backdoor} che gli siano noti, qualora venga usato un \textit{rootkit}
sconosciuto al programma o modificato in maniera da non essere riconosciuto,
la loro efficacia cesserà immediatamente. Per questo motivo sono stati
sviluppati sistemi alternativi in grado di superare questo problema. 

Nel caso di GNU/Linux uno dei programmi più utilizzati per questo compito è
\texttt{chkrootkit}, nato, come il nome stesso suggerisce, per verificare la
presenza di eventuali \textit{rootkit} installati su una macchina. In realtà
\index{comando!\texttt{chkrootkit}} \texttt{chkrootkit} non si limita al
controllo dei soli \itindex{rootkit} \textit{rootkit} e effettua anche una
serie di ulteriori verifiche per identificare eventuali \itindex{trojan}
\textit{trojan} o \itindex{backdoor} \textit{backdoor} o altri programmi
indesiderati.

L'uso del programma è tutto sommato elementare, basta eseguirlo (ovviamente
con i privilegi di amministratore) da un terminale e questo stamperà a video
l'elenco dei suoi risultati, con un qualcosa del tipo:
\begin{Console}
# \textbf{chkrootkit}
ROOTDIR is `/'
Checking `amd'... not found
Checking `basename'... not infected
Checking `biff'... not infected
... 
Checking `write'... not infected
Checking `aliens'... no suspect files
Searching for sniffer's logs, it may take a while... nothing found
Searching for HiDrootkit's default dir... nothing found
Searching for t0rn's default files and dirs... nothing found
Searching for t0rn's v8 defaults... nothing found
Searching for Lion Worm default files and dirs... nothing found
Searching for RSHA's default files and dir... nothing found
Searching for RH-Sharpe's default files... nothing found
... 
Searching for ShKit rootkit default files and dirs... nothing found
Searching for anomalies in shell history files... nothing found
Checking `asp'... not infected
Checking `bindshell'... not infected
Checking `lkm'... nothing detected
Checking `rexedcs'... not found
Checking `sniffer'... 
lo: not promisc and no packet sniffer sockets
Checking `w55808'... not infected
Checking `wted'... nothing deleted
Checking `scalper'... not infected
Checking `slapper'... not infected
Checking `z2'... nothing deleted
\end{Console}
ovviamente in questo caso il problema resta quello che se è stato installato
un \textit{rootkit} non noto, esso non sarà rilevato. 

% TODO documentare tiger
% TODO documentare rootkit hunter


\subsection{Programmi per la verifica di integrità}
\label{sec:ids_integrity_scan}

Come accennato in precedenza per \texttt{chkrootkit}, un qualunque sistema di
rilevazione di \textit{rootkit} basato su controlli effettuati in base alla
conoscenza di cosa viene modificato o inserito nel sistema, è destinato a
fallire non appena l'attaccante utilizzi una metodologia diversa. 

Esistono però delle caratteristiche comuni di qualunque \textit{rootkit}, ed è
pertanto possibile superare il precedente problema sfruttando questo fatto. Ad
esempio un \textit{rootkit}, nel momento in cui cerca di nascondere le tracce
del suo operato, dovrà necessariamente modificare il comportamento di
programmi come \texttt{ps}, \texttt{netstat}, \texttt{lsof}, ecc. Per questo
motivo una strategia efficace è semplicemente quella di mettere sotto
osservazione tutti i file critici di un sistema, per poterne verificare
l'integrità in qualunque momento successivo.\footnote{esiste una eccezione a
  tutto ciò, che consiste nel realizzare il \textit{rootkit} direttamente nel
  kernel, in modo da far sparire alla radice tutte le tracce; un esempio di
  questo è \texttt{adore}, realizzato come modulo del kernel che effettua la
  cancellazione di tutta una serie di tracce; in tal caso si dovrà utilizzare
  un equivalente sistema di controllo realizzato allo stesso livello.}

Il problema che si pone nell'attuare questa strategia è che una eventuale
compromissione del sistema può comportare anche quella del sistema di
verifica, pertanto il meccanismo per essere veramente efficace prevede una
modalità di operazione che comporti la registrazione dello stato originario
del sistema (e dello stesso programma di verifica) in un supporto che non
possa essere compromesso (cioè su un mezzo che sia fisicamente accessibile in
sola lettura) dal quale poi effettuare il controllo. 

L'\textit{Advanced Intrusion Detection Environment}, in breve
\index{comando!\texttt{aide}} \texttt{aide}, è un programma che permette di
costruire un database di una serie di proprietà, come permessi, numero di
inode, dimensioni, tempi di accesso ed una serie di hash crittografici,
relativo all'insieme dei file che si vogliono tenere sotto controllo, per
poter verificare in un momento successivo tutti gli eventuali cambiamenti
delle stesse.

Tipicamente l'uso del programma comporta che l'amministratore esegua la
creazione del database (da eseguire con il comando \texttt{aide -{}-init},
anche se Debian mette a disposizione uno script apposito) una volta completata
l'installazione della macchina, prima che questa venga posta in rete e sia
esposta a possibili intrusioni. Si dovrà poi provvedere a salvare il database,
il programma di controllo ed il relativo file di configurazione su un mezzo
appropriato che sia impossibile da modificare da parte un eventuale
attaccante; in genere si tratta di un floppy o di un CDROM o di una chiave
USB: comunque di un mezzo per il quale sia possibile impostare l'accesso in
sola lettura a livello fisico. 

Nel caso di Debian l'installazione è elementare, essendo disponibile
direttamente il pacchetto \texttt{aide} che installa tutto il necessario,
compresi gli script eseguiti quotidianamente da \textit{cron} per controllare
lo stato dei file. La prima schermata di installazione, mostrata in
fig.~\ref{fig:ids_aide1}, notifica la scelta di default per l'utente a cui
inviare la posta dei rapporti periodici, suggerendo al contempo come
modificare in un momento successivo l'impostazione nel file di configurazione
di \texttt{aide} che in Debian è tenuto sotto
\index{configurazione!\texttt{/etc/aide/aide.conf}}
\texttt{/etc/aide/aide.conf}.

\begin{figure}[!htb]
  \centering \includegraphics[scale=0.5]{images/aide1}
\caption{Prima finestra di configurazione dell'installazione di
  \texttt{aide}.} 
\label{fig:ids_aide1}
\end{figure}

Una volta letta la schermata e premuto invio, la configurazione ne propone una
seconda, riportata in fig.~\ref{fig:ids_aide2}, che chiede se creare il
database.  Nel caso specifico abbiamo scelto di farlo subito, in caso
contrario sarebbe stata mostrata un'altra schermata per ricordare che per
creare il database in un secondo momento è disponibile un apposito script,
\texttt{aideinit}. 

\begin{figure}[!htb]
  \centering \includegraphics[scale=0.5]{images/aide2}
\caption{Seconda finestra di configurazione nell'installazione di
  \texttt{aide}.} 
\label{fig:ids_aide2}
\end{figure}

Una volta creato il database (di default Debian lo crea in
\texttt{/var/lib/aide/aide.db}) è necessario salvare su un supporto apposito
non solo il quest'ultimo ma anche file di configurazione e programma, in
quanto un eventuale compromissione permetterebbe all'attaccante di modificare
la versione presente sul sistema.  Per questo il controllo deve essere sempre
fatto con l'immagine del programma salvata sul mezzo in sola lettura, per
essere sicuri di usare un programma non compromesso. Nel caso di Debian
\texttt{aide} viene installato linkato in maniera statica, in modo da impedire
all'attaccante di comprometterne il funzionamento sostituendo delle librerie. 

Una volta creato il database si potrà controllare l'integrità dei file messi
sotto controllo con il comando \texttt{aide -{}-check}. In generale però, dato
che l'operazione non comporta sostanzialmente un carico aggiuntivo
significativo, è preferibile utilizzare il comando nella forma \texttt{aide
  -{}-update}, che oltre al rapporto sulle differenze trovate, permette di
creare una nuova versione del database, salvato nel nuovo file
\texttt{/var/lib/aide/aide.db.new}.  Questo è anche quello che viene fatto dal
\textit{cron job} installato dal pacchetto che gira tutte le notti, e invia
una e-mail con il rapporto dei cambiamenti all'amministratore (a meno di non
aver modificato l'impostazione di default). 

In generale avere dei cambiamenti non è un sinonimo di intrusione, il caso più
comune è che questi sono del tutto legittimi: ad esempio possono essere state
installate delle nuove versioni di alcuni programmi, o modificate alcune delle
configurazioni. Pertanto il rapporto deve essere verificato costantemente, e
qualora le modifiche trovate siano legittime, si potrà evitare di vedercele
riproposte tutte le volte salvando la nuova versione del database al posto
della precedente.  Quando si è sicuri del nuovo database si può provvedere a
ripetere l'operazione utilizzando la versione sul supporto in sola lettura,
provvedendo a salvare anche il nuovo database che può prendere a tutti gli
effetti il posto del precedente. 

Occorre ovviamente effettuare il controllo in condizioni di sicurezza, ad
esempio disconnettendo la macchina durante il controllo con il database
precedente (da fare sempre dal supporto in sola lettura) e la produzione ed il
salvataggio del nuovo file, per evitare eventuali modifiche \textsl{al
  volo}\footnote{poco probabili, ma nelle questioni di sicurezza la paranoia è
  una virtù.} da parte di un eventuale intruso. Una buona politica può essere
quella di eseguire l'aggiornamento in maniera periodica, verificando cosa è
cambiato dalla volta precedente, in modo da avere sempre un file di controllo
sufficientemente recente. 

La parte più critica nell'utilizzo di \texttt{aide} (come di ogni programma
simile) è proprio la scelta di quali file tenere sotto controllo. Questo è
controllato dal contenuto del file di configurazione del programma,
\texttt{aide.conf}. Il file prevede tre tipi diversi di direttive; le prime
sono le righe di configurazione, nella forma \texttt{parametro=valore}, esempi
possibili sono le linee:
\begin{Example}
database=file:/var/lib/aide/aide.db
\end{Example}
che specifica dove è mantenuto il database di \texttt{aide}, o:
\begin{Example}
database_out=file:/var/lib/aide/aide.db.new
\end{Example}
che specifica il file in cui viene creato il nuovo database quando si esegue
\texttt{aide -{}-update}. L'elenco completo dei parametri predefiniti e dei
possibili valori è documentato, insieme a tutte le altre caratteristiche del
file, nella relativa pagina di manuale, accessibile con \texttt{man
  aide.conf}. 

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|l|}
    \hline
    \textbf{Gruppo}&\textbf{Descrizione}\\
    \hline
    \hline
       \texttt{p}&     permessi del file \\
       \texttt{i}&     numero di inode \\
       \texttt{n}&     numero di link\\
       \texttt{u}&     utente proprietario \\
       \texttt{g}&     gruppo proprietario\\
       \texttt{s}&     dimensione\\
       \texttt{b}&     numero di blocchi \\
       \texttt{m}&     tempo di ultima modifica\\
       \texttt{a}&     tempo di ultimo accesso \\
       \texttt{c}&     tempo di ultimo cambiamento dell'inode\\
       \texttt{S}&     dimensione crescente\\
       \texttt{md5}  & md5 checksum\\
       \texttt{sha1} & sha1 checksum\\
       \texttt{rmd160}&rmd160 checksum\\
       \texttt{tiger}& tiger checksum\\
       \texttt{R}&     \texttt{p} + \texttt{i} + \texttt{n} + \texttt{u}
                       + \texttt{g} + \texttt{s} + \texttt{m} + \texttt{c}
                       + \texttt{md5}\\
       \texttt{L}&     \texttt{p} + \texttt{i} + \texttt{n} +
                       \texttt{u} + \texttt{g}\\
       \texttt{E}&     gruppo vuoto\\
       \texttt{>}&     file di log (\texttt{p} + \texttt{u} + \texttt{g} 
                       + \texttt{i} + \texttt{n} + \texttt{S})\\
       \texttt{crc32}& crc32 checksum\\
       \texttt{haval}& haval checksum\\
       \texttt{gost} & gost checksum\\
%    \texttt{-} & .\\ 
    \hline
  \end{tabular}
  \caption{Gruppi predefiniti per le proprietà dei file in
    \texttt{aide.conf}.}  
\label{tab:ids_aide_groups}
\end{table}

Se il parametro non corrisponde a nessuno dei valori predefiniti l'espressione
viene allora considerata come la definizione di un nuovo \textsl{gruppo}; i
gruppi sono la modalità con cui \texttt{aide} identifica le proprietà di un
file da tenere sotto controllo, alcuni di questi \textsl{gruppi} sono
predefiniti ed identificati dalle espressioni riportate in
tab.~\ref{tab:ids_aide_groups}, un nuovo gruppo può essere specificato con una
espressione del tipo:
\begin{Example}
# Custom rules
Binlib = p+i+n+u+g+s+b+m+c+md5+sha1
ConfFiles = p+i+n+u+g+s+b+m+c+md5+sha1
\end{Example}
in cui si sommano gruppi predefiniti o altri gruppi definiti in precedenti (ma
è supportata anche l'operazione di sottrazione per gruppi già definiti). 

Il secondo tipo di righe presenti nel file di configurazione sono le righe di
selezione dei file da tenere sotto controllo; queste sono di tre tipi, quelle
normali che iniziano sempre per ``\texttt{/}'', quelle di uguaglianza che
iniziano con ``\texttt{=}'' che servono ad aggiungere file al database e
quelle di negazione che iniziano con ``\texttt{!}'' che permettono di
deselezionare file selezionati dalle precedenti. Ciascuna di queste è una
espressione regolare da usare come corrispondenza con il pathname assoluto di
un file, per cui qualcosa del tipo \texttt{=/etc} corrisponde con qualunque
file dentro \texttt{/etc}. 

Il terzo ed ultimo tipo di direttive sono le righe che esprimono dei
\textsl{macro}-comandi, (è previsto un linguaggio elementare che permette di
definite variabili e eseguire blocchi condizionali) inizianti sempre per
\verb|@@|, queste sono quelle che definiscono le variabili come
\texttt{MAILTO} che sono usate dallo script del \textit{cron job}. Di nuovo
per una lista completa e relativa spiegazioni si può fare riferimento alla
pagine di manuale. 

Nel caso di Debian viene usato un file con valori di default ragionevoli ed
una serie di regole predefinite, ma in ogni caso la scelta dei file da tenere
sotto controllo dipende sempre dal compito delle varie macchine, e un po' di
lavoro di personalizzazione è sempre necessario. In questo il ciclo di
revisione del database dopo i controlli, con l'adattamento della
configurazione per inserire nel controllo solo i file (o le proprietà) la cui
variazione è significativa, è di fondamentale importanza. 


%
% TODO: sostituire con qualcosa di più attuale e mantenuto
% vedi: Samhain, OSSEC, Osiris
%

%%
%% ### OBSOLETE BEGIN ###
%% Materiale obsoleto sul LIDS, 
%% non includere nelle nuove versioni
%%
\ifx\obsoletesection\undefined

\relax
\else

\subsection{Il progetto \textit{LIDS}}
\label{sec:ids_lids}

Come accennato in sez.~\ref{sec:ids_tipology} una delle possibili tipologie di
IDS è quella in cui vengono osservate le operazioni compiute sul sistema per
rilevare (e bloccare) i tentativi di eseguire operazioni non autorizzate. Nel
caso di GNU/Linux una implementazione di questa tipologia di IDS è realizzata
dal progetto LIDS (\textit{Linux Intrusion Detection System}). 

L'architettura classica della gestione dei privilegi in un sistema unix-like
ha il sostanziale problema di fornire all'amministratore dei poteri troppo
ampi (in quanto non soggetto a nessun controllo di accesso), questo significa
ad esempio che delle eventuali protezioni (come quella di rendere immutabili
dei file o montare un filesystem in sola lettura) possono comunque essere
revocate. Questo fa sì che la compromissione dell'utente di amministrazione
comporti di solito la totale inefficacia di qualunque misura di protezione. 

Inoltre il fatto di disporre di un kernel modulare apre alla possibilità di
utilizzare tutta una nuova classe di \textit{rootkit} basati sull'inserimento
di opportuni moduli nel kernel. Diventa così possibile fornire sia una
\textit{backdoor} per l'accesso remoto dell'attaccante, che l'occultamento
della stessa in maniera del tutto trasparente per i programmi che girano in
user space, rendendo molto meno efficaci (se non inutili) misure di protezione
che controllano l'integrità dei file come quella di \texttt{aide}. 

Per migliorare la sicurezza del sistema a partire dai kernel della serie 2.2 è
stato introdotto un meccanismo di protezione aggiuntivo, detto
\itindex{capabilities} \textit{capabilities}, che consente di suddividere i
privilegi tradizionalmente associati all'amministratore in un insieme di
\textsl{capacità} distinte, il cui elenco si è riportato in
tab.~\ref{tab:ids_capabilities}, che possano essere abilitate e disabilitate
separatamente da ciascun processo.

\begin{table}[!htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|p{8cm}|}
    \hline
    \textbf{Capacità}&\textbf{Descrizione}\\
    \hline
    \hline
    \texttt{CAP\_CHOWN}  & la capacità di cambiare proprietario e gruppo
                           proprietario di un file.\\ 
    \texttt{CAP\_DAC\_OVERRIDE} & la capacità di evitare il controllo dei
                                  permessi (lettura, scrittura ed esecuzione,
                                  detti anche \textit{discrectionary access
                                    control}, da cui il nome) dei file.\\ 
    \texttt{CAP\_DAC\_READ\_SEARCH}& la capacità di evitare il controllo dei
                                  permessi (lettura ed esecuzione) per le
                                  directory. \\ 
    \texttt{CAP\_FOWNER}    & la capacità di evitare il controllo della
                              proprietà di un file per le operazioni che la
                              richiedono (come i cambiamenti dei tempi). \\ 
    \texttt{CAP\_FSETID}    & la capacità di non modificare suid e sgid quando
                              si modifica un file.\\ 
    \texttt{CAP\_IPC\_LOCK} & la capacità di eseguire un blocco della 
                              memoria. \\ 
    \texttt{CAP\_IPC\_OWNER}& la capacità di evitare il controllo dei permessi
                              per le operazioni sugli oggetti di
                              intercomunicazione fra processi (SysV IPC).\\ 
    \texttt{CAP\_KILL}      & la capacità di mandare segnali a qualunque
                              processo.\\
    \texttt{CAP\_LEASE}     & la capacità di creare dei \textit{file lease} su
                              qualunque file.\\
    \texttt{CAP\_LINUX\_IMMUTABLE}& la capacità di impostare gli attributi
                              \textit{immutable} e \textit{append only} per i
                              file su un filesystem \textsl{ext2}.\\ 
    \texttt{CAP\_MKNOD}     & la capacità di creare file di dispositivo.\\
    \texttt{CAP\_NET\_ADMIN}& la capacità di eseguire alcune operazioni
                              privilegiate sulla rete (impostare le opzioni
                              privilegiate dei socket, abilitare il
                              multicasting, impostare interfacce di rete e
                              tabella di instradamento).\\
    \texttt{CAP\_NET\_BIND\_SERVICE}& la capacità di porre in ascolto server
                              su porte riservate.\\
    \texttt{CAP\_NET\_BROADCAST}& la capacità di consentire l'uso di socket in
                              broadcast e multicast.\\
    \texttt{CAP\_NET\_RAW}  & la capacità di usare socket \texttt{RAW} e
                              \texttt{PACKET} (quelli che permettono di creare
                              pacchetti nei protocolli di basso livello).\\
    \texttt{CAP\_SETGID}    & la capacità di manipolare i group ID dei
                              processi (sia il principale che i supplementari,
                              che quelli trasmessi tramite i socket unix
                              domain).\\
    \texttt{CAP\_SETPCAP}   & la capacità di impostare o rimuovere le capacità
                              (limitatamente a quelle che il processo
                              chiamante ha nel suo insieme di capacità
                              permesse) da qualunque processo.\\
    \texttt{CAP\_SETUID}    & la capacità di manipolare gli user ID del
                              processo (e trasmettere un valore arbitrario
                              tramite i socket unix domain)\\
    \texttt{CAP\_SYS\_ADMIN}& la capacità di eseguire una serie di compiti
                              amministrativi (come impostare le quote,
                              attivare e disattivare la swap, montare,
                              rimontare e smontare filesystem, ecc.). \\
    \texttt{CAP\_SYS\_BOOT} & la capacità di fare eseguire un reboot del
                              sistema. \\
    \texttt{CAP\_SYS\_CHROOT}&la capacità di eseguire un \textit{chroot}.\\ 
    \texttt{CAP\_SYS\_MODULE}&la capacità di caricare e rimuovere moduli del
                              kernel. \\ 
    \texttt{CAP\_SYS\_NICE} & la capacità di modificare le priorità dei
                              processi. \\ 
    \texttt{CAP\_SYS\_PACCT}& la capacità di usare le funzioni di
                              \textit{accounting}.\\
    \texttt{CAP\_SYS\_RAWIO}& la capacità di eseguire operazioni sulle porte
                              di I/O.\\ 
    \texttt{CAP\_SYS\_RESOURCE}& la capacità di superare le limitazioni sulle
                                 risorse, aumentare le quote disco, usare lo
                                 spazio disco riservato all'amministratore.\\ 
    \texttt{CAP\_SYS\_TIME} & la capacità di modificare il tempo di sistema.\\ 
    \texttt{CAP\_SYS\_TTY\_CONFIG}& la capacità di simulare un \textit{hangup}
                              della console.\\ 
    \hline
  \end{tabular}
  \caption{Le \textit{capabilities} definite nel kernel a partire dal 2.4.20.} 
\label{tab:ids_capabilities}
\end{table}

Le caratteristiche standard delle \textit{capabilities} prevedono che si possa
eliminare da un processo una di queste capacità, con la possibilità di
impedire che esso possa riacquisirla. Si possono così ridurre in maniera
mirata le capacità dei singoli processi, anche se eseguiti con privilegi di
amministratore; il problema di questo meccanismo è che nell'attuale
implementazione nel kernel standard devono essere i programmi stessi ad
utilizzare le opportune funzioni, e cancellare esplicitamente le
\itindex{capabilities} \textit{capabilities} non essenziali al loro interno.

Per tutta questa serie di motivi è nato il progetto LIDS (sigla che sta per
\textit{Linux Intrusion Detection System}) che consiste in un insieme di patch
al kernel che consentono di inserire una serie di regole di accesso molto più
raffinate di quelle standard, che il progetto chiama genericamente ACL
(\textit{Access Control List}).  Queste ACL sono sostanzialmente di due tipi,
quelle che restringono le operazioni che si possono compiere sui file
permettendo di indicare quali sono i processi che possono compierle, e quelle
che restringono le \textit{capabilities} che possono essere assegnate ai
singoli programmi; le prime sono applicate all'avvio del kernel, mentre le
seconde vengono attivare solo quando il kernel viene ``\textsl{sigillato}''. 

Il primo problema della architettura di sicurezza standard di Linux è che i
permessi sui file possono essere specificati solo come proprietà dei file
stessi, non esiste un meccanismo per restringere l'accesso al singolo
programma. Inoltre anche se con alcuni filesystem si possono usare degli
ulteriori permessi speciali, come l'immutabilità (impostabile con
\texttt{chattr +i}) o il permessi di scrittura solo in append (impostabile con
\texttt{chattr +a}), entrambe queste restrizioni sono revocabili. 

Per questo motivo LIDS integra direttamente nel \textit{Virtual File System}
del kernel la sua infrastruttura di ACL, che così non vengono a dipendere da
un supporto specifico nel sottostante filesystem. I permessi che LIDS
definisce sono quattro, riportati in tab.~\ref{tab:ids_LIDS_file_ACL}, e come
si vede oltre alla immutabilità e alla sola scrittura in \texttt{append} c'è
pure la possibilità di far sparire i file dal filesystem. Questa ultima
funzionalità sarebbe di scarsa utilità se non fosse per il fatto che tutte
queste capacità di accesso possono essere impostate singolarmente per ciascun
programma. Si può così indicare quali processi possono accedere e cosa possono
fare su base individuale, bloccando completamente l'accesso agli altri, anche
se eseguiti con i privilegi di amministratore. 

\begin{table}[!htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|p{8cm}|}
    \hline
    \textbf{Capacità}&\textbf{Descrizione}\\
    \hline
    \hline
    \texttt{DENY}  & impedisce l'accesso all'inode, in sostanza il file 
                     scompare dal filesystem come se non esistesse.\\ 
    \texttt{READ}  & permette l'accesso in sola lettura, il file non può
                     essere in alcun modo modificato (è equivalente
                     all'impostazione dell'attributo \textit{immutable} con
                     \texttt{chattr +i}).\\ 
    \texttt{APPEND}& permette l'accesso in lettura, e la scrittura sul file
                     solo in \textit{append} (è equivalente all'impostazione
                     dell'omonimo attributo con \texttt{chattr +a}).\\ 
    \texttt{WRITE} & permette un accesso generico, tutto funziona come  
                     se LIDS non ci fosse.\\ 
    \hline
  \end{tabular}
  \caption{Le quattro ACL per i file definite da LIDS.} 
\label{tab:ids_LIDS_file_ACL}
\end{table}

La seconda estensione delle capacità di controllo di accesso di LIDS consiste
nelle ACL relative alle \textit{capabilities}; queste non solo possono essere
rimosse definitivamente, ma possono essere sia rimosse globalmente per il
sistema assegnate singolarmente a ciascun processo indipendentemente dal fatto
che esso supporti o meno il controllo delle stesse al suo interno. Esse
possono inoltre essere applicate genericamente a tutto il sistema o essere
applicate selettivamente ai processi lanciati da un altre; infine LIDS
introduce nuove \textit{capabilities} o estende alcune di quelle già presenti
nel kernel. 

\begin{figure}[!htb]
  \centering \includegraphics[scale=0.5]{images/lids1}
\caption{Opzioni di configurazione di LIDS in un kernel 2.4.x.} 
\label{fig:ids_LIDS_cfg2.4}
\end{figure}

Il progetto è diviso in due parti, un insieme di patch al kernel che
implementano le varie funzionalità, e dei programmi in user space, (in
sostanza due, \texttt{lidsadm} e \texttt{lidsconf}), che permettono di gestire
il sistema.  Il primo passo per l'uso di LIDS è la sua installazione, cioè la
ricompilazione di un kernel che supporti le relative funzionalità. Le
attuali\footnote{al momento della scrittura di queste dispense.}  versioni
sono due, la versione 1.2.x fa riferimento ai kernel stabili della serie
2.4.x, mentre la nuova 2.x si applica ai nuovi kernel della serie 2.6.x
utilizzando l'infrastruttura dei \textit{Linux Security Modules} in essi
introdotta.

Per entrambe le versioni il primo passo è di applicare le patch, per poi
configurare il kernel. Nel caso del kernel 2.4.x questo abilita la presenza di
una nuova voce dal titolo \texttt{Linux Intrusion Detection System} nel menù
principale, all'interno della quale si possono abilitare tutte le varie
funzionalità di LIDS, una parte di queste vengono riportate in
fig.~\ref{fig:ids_LIDS_cfg2.4} dove è mostrata la finestra di configurazione
relativa a detta opzione. 

A parte abilitare esplicitamente il supporto per LIDS le opzioni principali
sono quelle che permettono di restringere i terminali su cui è possibile
disattivare le protezioni (con \texttt{Allow switching LIDS protections}),
l'attivazione di un rilevatore di portscan interno al kernel (con \texttt{Port
  Scanner Detector in kernel}, ma in genere è preferibile utilizzare allo
scopo un NIDS come \texttt{snort}) la possibilità di restringere le operazioni
anche su specifiche operazioni sui socket (con \texttt{Enable security
  network}). 

Come accennato nel caso di un kernel 2.6.x il patch si basa su una serie di
funzionalità già presenti nel kernel (in particolare i \textit{Linux Security
  Modules}), per cui oltre alle nuove opzioni specifiche di LIDS, che come
illustrato in fig.~\ref{fig:ids_LIDS_cfg2.6} compaiono nella apposita sezione
\texttt{Security Option}, occorrerà abilitare anche delle altre opzioni. In
particolare oltre alle opzioni specifiche che riprendono quelle del 2.4,
occorrerà abilitare, nella sezione \texttt{Criptographic option}, i moduli di
crittografia ed in particolare il modulo per il supporto dello SHA256 che
viene usato per cifrare la password di sblocco di LIDS. 

\begin{figure}[!htb]
  \centering \includegraphics[scale=0.5]{images/lids2}
\caption{Opzioni di configurazione di LIDS in un kernel 2.6.x.} 
\label{fig:ids_LIDS_cfg2.6}
\end{figure}

Come si può vedere in fig.~\ref{fig:ids_LIDS_cfg2.6} le opzioni relative a
LIDS sono sostanzialmente le stesse del 2.4.x, la differenza in questo caso è
che oltre ad abilitare LIDS occorre mantenere disabilitate alcune delle altre
funzionalità di sicurezza presenti nel kernel, come \texttt{Default Linux
  Capabilities} e \texttt{NSA SELinux Support} che confliggono con LIDS. 

Una volta creato un kernel con il supporto per LIDS, prima di utilizzarlo è
necessaria una fase di configurazione preliminare. L'uso di LIDS infatti
permette di rendere inutilizzabili un gran numero di funzionalità normalmente
usate dai programmi, per cui occorre una configurazione iniziale che consenta
di abilitare le normali operazioni di avvio. In caso di necessità si può
lanciare il kernel disabilitando tutte le protezioni di LIDS passando al boot
l'argomento \texttt{lids=0}. 

La configurazione di LIDS è completamente mantenuta nella directory
\index{configurazione!\texttt{/etc/lids/}} \texttt{/etc/lids}; questa
directory viene protetta di default da LIDS, ed è pertanto marcata come
inaccessibile fin dall'avvio.  Fino alla versione 1.1.x la configurazione
standard prevedeva che la directory contenesse almeno i file riportati in
tab.~\ref{tab:ids_LIDS_conf_files}.

\begin{table}[!htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|p{8cm}|}
    \hline
    \textbf{File}&\textbf{Descrizione}\\
    \hline
    \hline
    \texttt{lids.cap} & Lista delle \textit{capabilities} da attivare e
                        disattivare per il sistema.\\ 
    \texttt{lids.conf}& File di configurazione delle ACL dei file.\\
    \texttt{lids.net} & Configurazione degli allarmi inviati via posta 
                        elettronica.\\
    \texttt{lids.pw}  & Password di accesso alla console non ristretta.\\
    \hline
  \end{tabular}
  \caption{I file di configurazione standard di LIDS.} 
\label{tab:ids_LIDS_conf_files}
\end{table}

Il file \texttt{lids.cap} contiene la lista delle \textit{capabilities} da
abilitare e disabilitare per tutto il sistema una volta che questo viene
\textsl{sigillato} invocando \index{comando!\texttt{lidsadm}} \texttt{lidsadm}
con l'opzione \texttt{-I}.\footnote{vedremo più avanti che a partire dalla
  versione 1.2.x di LIDS sono stati introdotti gli \textsl{stati} del sistema
  ed è diventato possibile applicare delle \textit{capabilities} specifiche
  fin all'avvio.}  Il formato del file prevede una riga per ognuna delle
\textit{capabilities}, che inizia con un ``\texttt{+}'' per abilitarla e con
un ``\texttt{-}'' per disabilitarla; il segno è seguito dal numero che la
identifica seguito a sua volta dal nome (lo stesso di
tab.~\ref{tab:ids_capabilities}) separato con un ``\texttt{:}''. Un estratto
di questo file (preso dal pacchetto \texttt{lidstool-2.4} di Debian e tolti i
commenti) è:
\begin{Example}
+6:CAP_SETGID
+7:CAP_SETUID
+8:CAP_SETPCAP
-9:CAP_LINUX_IMMUTABLE
-10:CAP_NET_BIND_SERVICE
+11:CAP_NET_BROADCAST
-12:CAP_NET_ADMIN
\end{Example}

Il file \texttt{lids.cap} contiene le \textit{capabilities} applicate a tutti
i processi nel sistema, queste però, come vedremo a breve, possono anche
essere assegnate ai singoli processi attraverso l'uso delle ACL.  Si tenga
presente che oltre alle \textit{capabilities} presenti nel kernel standard
(quelle di tab.~\ref{tab:ids_capabilities}) LIDS ne definisce altre
tre\footnote{prima della versione 1.1.1pre5 LIDS oltre a \texttt{CAP\_HIDDEN}
  definiva solo \texttt{CAP\_INIT\_KILL} che preveniva l'invio dei segnali
  solo ai processi figli di \texttt{init}.} ad uso interno, che sono riportate
in tab.~\ref{tab:ids_LIDS_capabilities}. 

\begin{table}[!htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|p{8cm}|}
    \hline
    \textbf{File}&\textbf{Descrizione}\\
    \hline
    \hline
    \texttt{CAP\_HIDDEN}& Permette di nascondere la presenza dei processi;
                          qualora la si assegni ad un processo questo scompare
                          da \texttt{/proc} ed è pertanto invisibile a comandi
                          come \texttt{ps}, \texttt{top}, e affini. Questo
                          però non nasconde altre possibili tracce della
                          presenza di un processo, come eventuali connessioni
                          di rete o file da esso creati.\\ 
    \texttt{CAP\_PROTECTED}  & Permette di bloccare l'invio di un qualunque
                               segnale al processo a cui è stata impostata
                               questa \textit{capabilities}.\\ 
    \texttt{CAP\_KILL\_PROTECTED}& Permette di inviare i segnali anche ai
                                   processi che sono stati precedentemente
                                   protetti con \texttt{CAP\_PROTECTED}.\\ 
    \hline
  \end{tabular}
  \caption{Le \textit{capabilities} specifiche di LIDS.} 
\label{tab:ids_LIDS_capabilities}
\end{table}

Il secondo file di configurazione generale è \texttt{lids.pw}, che contiene la
password usata per ottenere un accesso non ristretto, cioè quella che nella
documentazione viene chiamata una \textsl{sessione libera} (una \textit{LIDS
  free session} o LFS, come viene chiamata nella documentazione di LIDS), in
sostanza un terminale a cui le restrizioni di LIDS non si
applicano.\footnote{si noti però come nelle opzioni di configurazione del
  kernel siano anche presenti delle possibili restrizioni sui terminali su cui
  una tale sessione può essere ottenuta; ad esempio si può richiedere che essa
  sia accessibile solo da console o su un terminale seriale.} Per impostare
(creare o modificare) la password si deve usare il comando \texttt{lidsconf}
con l'opzione \texttt{-P}, che la scriverà sul file da dove sarà controllata
dal comando \texttt{lidsadm} quando si vuole accedere ad una sessione libera.

Il file \texttt{lids.net} viene utilizzato solo se si è abilitata l'opzione
per inviare messaggi di allarme via rete. Questa è la caratteristica di LIDS
che lo rende a tutti gli effetti un \textit{Intrusion Detection System}, cioè
la capacità di rilevare e registrare tutti i tentativi di accesso non
autorizzato, e di inviare i relativi avvisi via posta elettronica ad un
amministratore. Il file contiene l'assegnazione di una serie di variabili (in
stile variabili di ambiente della shell) con cui si controlla l'invio di detti
allarmi, specificando un mittente, un destinatario ed un oggetto per le email;
un esempio di questo file, preso dall'installazione di Debian (tolti i
commenti), è il seguente:
\begin{Example}
MAIL_SWITCH= 1
MAIL_RELAY=127.0.0.1:25
MAIL_SOURCE=lids.truelite.it
MAIL_FROM= LIDS_ALERT@lids.truelite.it
MAIL_TO= piccardi@truelite.it
MAIL_SUBJECT= LIDS ALert
\end{Example}
che illustra tutte le impostazioni disponibili (il nome delle variabili è
autoesplicativo). 

L'ultimo file di configurazione, \texttt{lids.conf}, è quello che contiene la
gran parte della configurazione di LIDS, essendovi memorizzata la lista delle
ACL. Con le versioni precedenti la 1.2.x il kernel leggeva questo file
all'avvio, attivando tutte le regole in esso contenute; con la versione 1.2.x
è stato introdotto il concetto di \textsl{stato} del sistema, e le ACL possono
essere specificate non solo per l'avvio, ma per ciascuno degli stati riportati
in tab.~\ref{tab:ids_LIDS_ACL_states}. 

\begin{table}[!htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|p{8cm}|}
    \hline
    \textbf{File}&\textbf{Descrizione}\\
    \hline
    \hline
    \texttt{BOOT}    & è lo stato di LIDS durante l'avvio. Inizia con il boot
                       e viene mantenuto fino a quando il kernel non
                       viene sigillato con il comando \texttt{lidsadm -I}.\\ 
    \texttt{POSTBOOT}& è lo stato di LIDS durante le usuali operazioni. Si
                       attiva con il comando \texttt{lidsadm -I}.\\
    \texttt{SHUTDOWN}& è lo stato di LIDS durante lo shutdown. Ci si porta in
                       questo stato da \texttt{POSTBOOT} con il comando
                       \texttt{lidsadm -S -{}- +SHUTDOWN}.\\ 
    \texttt{GLOBAL}  & indica uno stato qualunque, una regola specificata per
                       questo stato si applica in generale.\\
    \hline
  \end{tabular}
  \caption{I quattro stati per le ACL definiti da LIDS.} 
\label{tab:ids_LIDS_ACL_states}
\end{table}

L'introduzione degli stati ha comportato la presenza di ulteriori file di
configurazione per ciascuno di essi, sia per le ACL dei file di
\texttt{lids.conf}, che per le \textit{capabilities} di \texttt{lids.cap}.  A
partire dalla versione 1.2.x di LIDS infatti la configurazione impostata in
questi due file si applica solo allo stato \texttt{GLOBAL} che viene
usato per le regole che devono essere sempre applicate; è possibile però
definire anche una configurazione che vale solo all'interno di ciascuno degli
altri tre stati, e queste saranno inserite in opportuni file di configurazione
separati, riportati in tab.~\ref{tab:ids_LIDS_state_conf_files}. 

\begin{table}[!htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|l|}
    \hline
    \textbf{File}&\textbf{Descrizione}\\
    \hline
    \hline
    \texttt{lids.boot.cap}     & Configurazione delle \textit{capabilities}
                                 all'avvio.\\ 
    \texttt{lids.boot.conf}    & Configurazione delle ACL dei file 
                                 all'avvio.\\
    \texttt{lids.postboot.cap} & Configurazione delle \textit{capabilities}
                                 nelle operazioni normali.\\ 
    \texttt{lids.postboot.conf}& Configurazione delle ACL dei file nelle
                                 operazioni normali.\\
    \texttt{lids.shutdown.cap} & Configurazione delle \textit{capabilities}
                                 allo shutdown.\\ 
    \texttt{lids.shutdown.conf}& Configurazione delle ACL dei file 
                                 allo shutdown.\\
    \hline
  \end{tabular}
  \caption{I file di configurazione standard di LIDS.} 
\label{tab:ids_LIDS_state_conf_files}
\end{table}

Tutti questi file contengono una lista di ACL, quelli per le
\textit{capabilities} hanno lo stesso formato di \texttt{lids.cap}, mentre
quelli per i file sono analoghi a \texttt{lids.conf}. Quest'ultimo però non
viene mai creato a mano, in quanto la scelta architetturale di LIDS è di
indicare al suo interno i file per \textit{inode} e non per nome, per cui è
piuttosto complesso inserire a mano tutti i dati.\footnote{questo comporta
  anche che l'amministratore deve aggiornare questi file usando l'opzione
  \texttt{-U} di \texttt{lidsconf} quando esegue qualche modifica al sistema,
  dato che eventuali nuovi file (o sostituti di vecchi) non è detto conservino
  lo stesso numero di inode.} 

Oltre ai nuovi file di configurazione delle ACL degli stati con la versione
1.2.x è stato introdotto anche il file \texttt{lids.ini}, per fornire a LIDS
una serie di valori di configurazione iniziale, da usare al boot. Il file ha
il formato di una assegnazione (analoga a quella di una variabile di shell), e
deve essere presente.  Al momento supporta solo l'utilizzo della variabile
\texttt{ACL\_DISCOVERY}, questa, qualora impostata ad 1, disattiva le
restrizioni di LIDS ma continua la rilevazione delle violazioni delle stesse,
stampando sulla console non solo i messaggi di errore ma anche le ACL ad esse
relative. In questo modo si può ottenere direttamente da LIDS stesso l'elenco
delle ACL necessarie all'avvio del sistema (chiaramente occorre valutare le
cose con attenzione, specie per ACL che coinvolgano programmi come
\texttt{bash}). 

Come accennato, anche a causa dell'utilizzo dei numeri di inode, i file di
configurazione delle ACL dei file (i \texttt{.conf} per intendersi) vengono
normalmente creati attraverso l'uso del comando
\index{comando!\texttt{lidsconf}} \texttt{lidsconf},\footnote{fino alla
  versione 1.1.0 di LIDS questo veniva fatto con il comando \texttt{lidsadm},
  poi la gestione delle ACL è stata modificata.} il cui compito principale è
appunto quello di inserire in maniera opportuna una ACL al loro interno.
Quando il comando viene usato per questo scopo esso dovrà essere invocato
nella forma:
\begin{Example}
lidsconf -A  [-s subject] -o object [-t from-to] [-i level] -j target
\end{Example}

Con le versioni a partire dalla 1.2.0 l'opzione \texttt{-A}, che indica che si
vuole aggiungere una ACL, può prendere come argomento uno dei valori di
tab.~\ref{tab:ids_LIDS_ACL_states}, nel qual caso l'ACL sarà salvata nel file
di configurazione corrispondente. Lo stesso dicasi quando si usa l'opzione
\texttt{-D} per cancellare una ACL.\footnote{nel caso si dovrà anche
  specificare quale tramite \textsl{oggetto} e \textsl{soggetto} della
  stessa.} 

Una ACL deve sempre avere un \textsl{oggetto} (specificato con \texttt{-o}) a
cui viene applicata. L'oggetto può essere sia un file che una directory, nel
qual caso essa sarà applicata anche a tutti i file e le sottodirectory in essa
contenuti. Si può inoltre specificare come oggetto anche una delle
\texttt{capabilities}, utilizzando il relativo nome di
tab.~\ref{tab:ids_capabilities} o tab.~\ref{tab:ids_LIDS_capabilities}. 

Con l'opzione \texttt{-j} si indica poi il tipo di accesso che si consente;
questo per file e directory può essere solo uno dei quattro valori di
tab.~\ref{tab:ids_LIDS_file_ACL}, mentre se l'oggetto è una
\textit{capability} l'unico valore possibile è \texttt{GRANT}. 

Se non si specifica altro la ACL si applica per qualunque accesso all'oggetto;
si può però specificare (con l'opzione \texttt{-s}) anche un \textsl{soggetto}
della ACL, che può essere solo un programma, nel qual caso la ACL si
applicherà soltanto agli accessi eseguiti dello stesso. In generale questo
tipo di ACL viene utilizzato per abilitare l'accesso a singoli programmi una
volta che lo si è disabilitato a livello generale. 

\begin{table}[!htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|l|}
    \hline
    \textbf{Opzione}&\textbf{Descrizione}\\
    \hline
    \hline
    \texttt{-A}& aggiunge una ACL.\\
    \texttt{-D}& cancella una ACL.\\
    \texttt{-Z}& cancella tutte le ACL.\\
    \texttt{-L}& elenca le ACL.\\
    \texttt{-U}& aggiorna i numeri di inode in \texttt{lids.conf}.\\
    \texttt{-P}& crea/modifica la password di accesso in \texttt{lids.pw}.\\
    \texttt{-o}& indica l'\textsl{oggetto} di una ACL.\\
    \texttt{-s}& indica il \textsl{soggetto} di una ACL.\\
    \texttt{-i}& indica il livello di ereditarietà di una ACL.\\
    \texttt{-t}& indica l'intervallo di tempo in cui vale la ACL.\\
    \texttt{-j}& indica il tipo di accesso fornito dall'ACL.\\
    \hline
  \end{tabular}
  \caption{Principali opzioni di \texttt{lidsconf}.} 
\label{tab:ids_lidsconf_options}
\end{table}

Le altre opzioni permettono di definire alcuni attributi ulteriori della ACL,
come un accesso limitato nel tempo (con l'opzione \texttt{-t}) o il livello di
\textsl{ereditarietà} (con l'opzione \texttt{-i}) della stessa, cioè a quanti
livelli di processi figli creati dal programma specificato come soggetto la
ACL continua ad applicarsi. Oltre alla creazione delle ACL il comando prende
pure altre opzioni generiche, le principali delle quali sono riportate in
tab.~\ref{tab:ids_lidsconf_options}. 

Una volta eseguita l'impostazione generale delle ACL ed avviato un kernel con
il supporto per LIDS i processi non avranno più, anche se eseguiti da root, la
possibilità di eseguire azioni pericolose.  Inoltre tutti i tentativi di
violare una delle regole impostate dalle ACL saranno registrati, rendendo
immediato il riconoscimento del programma che sta cercando di eseguire delle
operazioni vietate. 

Questo significa che le ACL devono essere calibrate opportunamente per
consentire un corretto funzionamento del sistema, e questa è la parte più
difficile della configurazione di LIDS. In realtà è sempre possibile andare
per tentativi, dato che gli errori verranno immediatamente segnalati nei log. 
È però anche molto facile trovarsi con un sistema incapace di funzionare a
causa di ACL troppo restrittive; per questo è in genere una buona pratica
partire dalla configurazione di base e andare per tentativi; nella
documentazione di LIDS sono comunque presenti delle liste di ACL già pronte
per l'uso in corrispondenza di vari servizi (Apache, OpenLDAP, BIND, ecc.). 

Si tenga presente comunque che LIDS è pensato per sistemi server, in cui i
programmi che devono essere eseguiti sono ben definiti ed in numero ridotto,
non ha molto senso impiegarlo per una workstation dove gli accessi da
consentire per ottenere il funzionamento di tutti i programmi sono talmente
tanti da rendere molto basso il rapporto fra costo in tempo di configurazione
e benefici in termini di sicurezza. 


Il comando \texttt{lidsconf} permette di modificare le ACL nella
configurazione del sistema, quelle che vengono lette all'avvio dello stesso e
mantenute per tutta la durata delle attività dello stesso. Una volta però che
LIDS è stato attivato queste non possono essere più modificate direttamente,
dato che la directory \texttt{/etc/lids} è automaticamente protetta; inoltre
le nuove impostazioni sarebbero disponibili solo ad un successivo riavvio. 
Per questo con LIDS viene distribuito anche il comando \texttt{lidsadm} che
permette di modificare le impostazioni di sicurezza in maniera temporanea. 

Abbiamo già incontrato l'opzione \texttt{-I} del programma, usata per
\textsl{sigillare} il kernel attivando le restrizioni sulle
\textit{capabilities} (o, per le versioni dalla 1.2.x, portare il kernel nello
stato \texttt{POSTBOOT}). Questa opzione può essere usata una sola volta ed è
l'unica che non richiede autenticazione; la si usa in genere all'interno degli
script di avvio, una volta che si sono completate le operazioni e questi non
hanno più bisogno dei privilegi necessari in fase di boot. 

L'altra opzione principale di \texttt{lidsadm} è \texttt{-S}, che permette di
modificare le impostazione sulle \textit{capabilities}, o alcuni dei flag
interni di LIDS, che devono essere specificati nella forma \texttt{+FLAG} o
\texttt{-FLAG} (in quest'ultimo caso occorre proteggere la interpretazione del
\texttt{-} sulla riga di comando, apponendo un \texttt{-{}-}) rispettivamente
per attivare o rimuovere. In tal caso ovviamente l'utente dovrà essere
autenticato e verrà richiesta la password di accesso memorizzata in
\texttt{lids.pw}. 

Oltre alle \textit{capabilities} generiche di tab.~\ref{tab:ids_capabilities}
e quelle specifiche di LIDS di tab.~\ref{tab:ids_LIDS_capabilities} il comando
permette di impostare alcuni flag interni, uno dei più importanti è
\texttt{LIDS} in quanto è quello che consente di accedere ad una \texttt{LIDS
  Free Session}, cioè di ottenere una sessione (associata al terminale su cui
si è eseguito il comando) in cui le restrizioni di LIDS vengono rimosse. In
questo modo con un comando del tipo:
\begin{Example}
lidsadm -S -- -LIDS
\end{Example}
diventa possibile recuperare tutti i privilegi ordinari di amministrazione ed
eseguire anche i normali compiti (come quelli relativi ad aggiornamenti,
backup ed installazioni) che altrimenti risulterebbero impossibili, senza che
questo avvenga anche per tutti gli altri programmi che stanno girando sul
nostro sistema. Una volta completato il lavoro basterà uscire dalla sessione o
rimuovere i privilegi con \texttt{lidsadm -S +LIDS}. 

\begin{table}[!htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|l|}
    \hline
    \textbf{Flag}&\textbf{Descrizione}\\
    \hline
    \hline
    \texttt{LIDS}        & disabilita LIDS per la sessione corrente.\\
    \texttt{LIDS\_GLOBAL}& disabilita completamente LIDS.\\
    \texttt{RELOAD\_CONF}& rilegge i file di configurazione.\\
    \hline
  \end{tabular}
  \caption{Flag interni di LIDS attivabili con \texttt{lidsadm}.} 
\label{tab:ids_LIDS_flags}
\end{table}

L'elenco completo dei flag interni di LIDS è riportato in
tab.~\ref{tab:ids_LIDS_flags}. Questi permettono di disabilitare completamente
LIDS o di fare rileggere i file di configurazione. Quest'ultima funzionalità è
particolarmente importante in quanto come detto le ACL di \texttt{lids.conf}
identificano i file per inode; pertanto se si è eseguito un aggiornamento i
valori degli inode non saranno più gli stessi, e non solo occorrerà
ricostruire la configurazione (con \texttt{lidsconf -U}), ma anche
ricaricarla. 

Il lavoro più complesso nell'utilizzo di LIDS è quello della creazione del
corretto insieme di ACL. Il caso più comune infatti è quello in cui il sistema
non parte neanche o diventa inutilizzabile in quanto si sono imposte delle
restrizioni eccessive. In questo la modalità \texttt{ACL\_DISCOVERY} può
essere di grande aiuto, permettendo al sistema di funzionare lo stesso
mostrando però quali sono gli accessi non consentiti dalla politica che si è
scelta. Non esiste comunque una ricetta valida per tutte le situazioni, e un
bel po' di lavoro di riconfigurazione sarà comunque necessario. 

In ogni caso ci si ricordi di utilizzare sempre il comando \texttt{lidsadm -I}
per sigillare il kernel al momento opportuno, e di utilizzare una sessione
libera (o usare \texttt{lidsadm -S -{}- +SHUTDOWN}) quando si vuole eseguire lo
shutdown (nello stato \texttt{POSTBOOT} i privilegi vengono rimossi, e ci si
ritroverebbe con un sistema con tutti i processi terminati ma incapace di
smontare i dischi e chiudere il sistema). 

Infine, dato che LIDS è un \textit{Intrusion Detection System}, ci si ricordi
anche di tenere sotto controllo i messaggi di log (o di attivare l'invio degli
stessi via e-mail). Dato che le operazioni sono eseguite direttamente dal
kernel i messaggi appariranno nella facility \texttt{kern}, e saranno del tipo:
\begin{Example}
Jun  7 14:31:17 monk kernel: LIDS: touch (dev 3:1 inode 23152) pid 69 \
   ppid 67 uid/gid (0/0) on (vc/1) : attempt to utime \
   /lib/modules/2.4.25-lids1.2.0/modules.dep for writing  - \
   logging disabled for (60)s
\end{Example}
dato che la priorità è di norma a livello di avvertimento, essi vengono pure
stampati sulla console, si può evitare questo comportamento con l'uso del
comando \texttt{klogd -c 4}. 


%%
%% ### OBSOLETE END ###
%% Materiale obsoleto LIDS, non includere nelle nuove versioni
%%
\fi


\section{I \textit{NIDS} per GNU/Linux}
\label{sec:ids_nids}

In questa sezione prenderemo in considerazione le problematiche relative
all'uso dei \textit{Network Intrusion Detection System} disponibili per
GNU/Linux, cioè a quei sistemi antintrusione specificamente destinati al
controllo del traffico di rete, per riconoscervi segnali o tracce di tentativi
di intrusione o di intrusioni vere e proprie. 

\subsection{La dislocazione di un NIDS}
\label{sec:ids_NIDS_location}

Prima di analizzare il funzionamento di un NIDS specifico come \texttt{snort}
occorre fare alcune considerazioni di carattere generale. Come accennato in
sez.~\ref{sec:ids_sniffer} a proposito degli \textit{sniffer} la presenza di
reti switchate comporta un problema qualora si voglia analizzare il traffico
di una rete, in quanto solo il traffico a lei diretto potrà arrivare alla
macchina sulla quale è posto il sistema antintrusione. 

Questo pone allora una serie di problemi, il primo, di difficile soluzione, è
quello dell'osservazione di tutto il traffico. Questo può essere risolto solo
per quegli switch che sono sufficientemente sofisticati da essere in grado di
deviare il traffico che passa attraverso di loro, usando il cosiddetto
\textit{mirroring}, su una certa porta. 

In questo caso basta piazzare la macchina che fa da NIDS sulla porta di
\textit{mirror} però si pone il problema che su una porta si hanno al massimo
100Mbit, mentre il traffico sullo switch può essere molto superiore, nel qual
caso si perdono pacchetti. Inoltre per alcuni switch l'abilitazione della
modalità di \textit{mirroring} degrada notevolmente le prestazioni. 

Negli switch più semplici questa funzionalità non esiste, per cui l'unica
alternativa è usare un hub, su cui attaccare le macchine del tratto di rete di
cui si vuole osservare il traffico (il router e il firewall) e quella con il
sistema di \textit{intrusion detection}. Questo non consente di osservare
tutto il traffico, ma in genere questo non è necessario, l'inconveniente è che
per flussi di traffico molto elevati si possono avere collisioni saturando
l'\textit{hub}, inoltre con l'inserimento nella rete dell'\textit{hub} si ha
un ulteriore \textit{single point of failure}.\footnote{si chiama così, nella
  struttura di un sistema generico, un componente che, con il suo
  malfunzionamento, compromette l'intero funzionamento del sistema.}

Questo ci lascia con la necessità di scegliere in quale punto della propria
rete inserire il sistema di NIDS. I due punti critici sono fra il router ed il
firewall, in diretto contatto con il traffico esterno, e sulla rete interna. 
Nel primo caso si possono osservare tutti gli attacchi diretti verso la
propria rete, nel secondo solo quelli che passano il filtro del firewall. 

In generale porre il sistema di rilevazione davanti al firewall ha il
vantaggio di mostrare lo stato effettivo degli attacchi che si possono subire,
ma quando il firewall fa anche da NAT si perde la capacità di tracciare la
sorgente di eventuali pacchetti sospetti che provengono dall'interno. Il fatto
che in questo caso si generino grosse quantità di allarmi, rischia di far
abituare chi li controlla ad un esame sommario, rendendo più difficile
l'individuazione di quelli che hanno successo. 

Porre il sistema dietro il firewall ha il vantaggio di rilevare solo gli
attacchi che passano quest'ultimo e generano pertanto meno carico di lavoro
non tanto sul sistema (nel caso di \texttt{snort} questo è trascurabile)
quanto su chi deve eseguire i controlli. Inoltre in questo modo si possono
individuare in maniera diretta le macchine che inviano traffico sospetto, ed
accorgersi di attacchi provenienti dall'interno, spesso i più pericolosi. Però
in questo modo si perde contatto con quelli che sono i pericoli reali che
possono provenire dalla rete e si può ingenerare un falso senso di sicurezza e
perdere la consapevolezza della provenienza degli attacchi, in quanto questi
vengono bloccati dal firewall. 

Su quale sia la scelta migliore la discussione è accesa, esistono buone
ragioni per entrambe le scelte, anche se personalmente, dovendone scegliere
una sola, propenderei per quella interna. Se le risorse lo consentono,
implementarle entrambe può essere la soluzione ideale. La regola d'oro
comunque resta di piazzare un sistema di rilevazione laddove si è sicuri che
poi si sia in grado di esaminarne i dati, la risorsa dell'amministratore che
verifica gli allarmi infatti è quella più preziosa e difficile da ottenere.


%
% TODO: trattare anche argus: http://www.qosient.com/argus/
% ed eventualmente Bro: http://www.bro-ids.org
%


\subsection{Il programma \texttt{snort}}
\label{sec:ids_snort}

Il principale e più usato pacchetto di \textit{network intrusion detection}
per GNU/Linux è \index{demone!\texttt{snort}} \texttt{snort}, un programma in
grado di analizzare in tempo reale il traffico di rete, selezionare e
registrare i pacchetti, eseguire ricerche e corrispondenze sul contenuto, in
modo da riconoscere una gran varietà di attacchi e tentativi di scansione (dai
\textit{portscan} ai tentativi di riconoscimento del sistema operativo, dai
\textit{buffer overflow} agli \textit{shell-code}).

Il programma può operare in tre modalità, come semplice \textit{sniffer}, in
modalità analoga a \texttt{tcpdump}, come sistema per la registrazione dei
pacchetti, e come vero e proprio sistema di rilevamento delle intrusioni. La
forza del programma è la presenza di un linguaggio che permette di creare
complesse regole di selezione per i pacchetti da analizzare, vari meccanismi
di registrazione (dai file di testo, alla registrazione su database) ed un
motore di analisi modulare che consente di inserire nuovi meccanismi di
rilevamento. Inoltre il programma è dotato di un meccanismo per la gestione
degli allarmi, in grado anche esso di inviarli a diversi sistemi di
registrazione. 

L'architettura modulare consente di estendere con facilità sia le capacità di
rilevamento che quelle di registrazione e rendicontazione. I plugin
attualmente disponibili consentono la registrazione su database e in formato
XML, la rilevazione dei pacchetti frammentati artificialmente, la rilevazione
dei \textit{portscan}, la capacità di riassemblare le connessioni TCP, ed un
sistema di rilevazione di anomalie statistiche. 

Per usare \texttt{snort} come sniffer basta lanciarlo con l'opzione
\texttt{-v}, nel qual caso stamperà a video le intestazioni dei pacchetti in
maniera simile a \texttt{tcpdump}, con l'opzione \texttt{-d} si può richiedere
anche la stampa del contenuto dei pacchetti, mentre con \texttt{-e} si
richiede anche la stampa delle intestazioni dei pacchetti a livello di
collegamento fisico. 

Il comando prende come argomento una espressione di filtraggio con la stessa
sintassi del \textit{Berkley Packet Filter} già illustrata in
sez.~\ref{sec:ids_sniffer}. Inoltre con l'opzione \texttt{-i} si può
specificare su quale interfaccia ascoltare, con \texttt{-n} specificare un
numero massimo di pacchetti da leggere e con \texttt{-P} limitare
l'acquisizione di un singolo pacchetto ad una certa dimensione. Un esempio di
uso di \texttt{snort} in questa modalità è il seguente:
\begin{Console}
# \textbf{snort -dev}
Running in packet dump mode
Log directory = /var/log/snort
 
Initializing Network Interface tun0
 
        --== Initializing Snort ==--
Initializing Output Plugins! 
Decoding 'ANY' on interface tun0
 
        --== Initialization Complete ==--
 
-*> Snort! <*-
By Martin Roesch (roesch@sourcefire.com, www.snort.org)
05/19-00:23:26.420194 > l/l len: 0 l/l type: 0x200 B2:C8:0:0:0:0
pkt type:0x4 proto: 0x800 len:0x55
10.1.0.31:38233 -> 192.168.1.2:631 TCP TTL:64 TOS:0x0 ID:49168 IpLen:20 DgmLen:69 DF
***AP*** Seq: 0x667A1D32  Ack: 0xCA6E3122  Win: 0xF944  TcpLen: 32
TCP Options (3) => NOP NOP TS: 22411008 556682494
50 4F 53 54 20 2F 20 48 54 54 50 2F 31 2E 31 0D  POST / HTTP/1.1. 
0A                                               . 
 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 
05/19-00:23:26.420216 > l/l len: 0 l/l type: 0x200 B2:C8:0:0:0:0
pkt type:0x4 proto: 0x800 len:0x59
10.1.0.31:38233 -> 192.168.1.2:631 TCP TTL:64 TOS:0x0 ID:49169 IpLen:20 DgmLen:73 DF
***AP*** Seq: 0x667A1D43  Ack: 0xCA6E3122  Win: 0xF944  TcpLen: 32
TCP Options (3) => NOP NOP TS: 22411008 556682494
43 6F 6E 74 65 6E 74 2D 4C 65 6E 67 74 68 3A 20  Content-Length:
32 37 30 0D 0A                                   270.. 

... 
... 

===============================================================================
Snort analyzed 84 out of 84 packets, dropping 0(0.000%) packets
 
Breakdown by protocol:                Action Stats:
    TCP: 84         (100.000%)         ALERTS: 0
    UDP: 0          (0.000%)          LOGGED: 0
   ICMP: 0          (0.000%)          PASSED: 0
    ARP: 0          (0.000%)
  EAPOL: 0          (0.000%)
   IPv6: 0          (0.000%)
    IPX: 0          (0.000%)
  OTHER: 0          (0.000%)
DISCARD: 0          (0.000%)
===============================================================================
Wireless Stats:
Breakdown by type:
    Management Packets: 0          (0.000%)
    Control Packets:    0          (0.000%)
    Data Packets:       0          (0.000%)
===============================================================================
Fragmentation Stats:
Fragmented IP Packets: 0          (0.000%)
    Fragment Trackers: 0
   Rebuilt IP Packets: 0
   Frag elements used: 0
Discarded(incomplete): 0
   Discarded(timeout): 0
  Frag2 memory faults: 0
===============================================================================
TCP Stream Reassembly Stats:
        TCP Packets Used: 0          (0.000%)
         Stream Trackers: 0
          Stream flushes: 0
           Segments used: 0
   Stream4 Memory Faults: 0
===============================================================================
Snort exiting
\end{Console}

Se si vuole utilizzare \texttt{snort} in modalità di \textit{packet logger}
per archiviare il traffico occorrerà specificare una directory dove verranno
registrati i pacchetti con l'opzione \texttt{-l}. In tal caso tutti i
pacchetti (ed in modalità NIDS pure gli alert) verranno decodificati in ASCII
come per la stampa a video e salvati in questa directory in una gerarchia di
sottodirectory ordinate secondo gli IP di destinazione degli stessi, questo
comporta che compariranno anche gli IP delle macchine sulla propria rete
locale, per evitarlo, e classificare tutti gli IP in relazione a questa si può
usare l'opzione \texttt{-h} per indicare qual'è la nostra rete locale, in
questo modo i pacchetti IP di risposta diretti alla nostra rete locale saranno
comunque classificati sulla base degli IP remoti. 

Utilizzare questa modalità comporta delle forti penalità in termini di spazio
utilizzato e velocità di memorizzazione, in quanto tutto deve essere
convertito in caratteri ASCII, per questo si può usare l'opzione
\texttt{-b}\footnote{con questa opzione \texttt{snort} è tranquillamente in
  grado di acquisire i dati su una interfaccia a 100Mb a pieno traffico.}  che
registrerà il traffico in un unico file binario (nello stesso formato di
\texttt{tcpdump}) con un nome del tipo \texttt{snort.log} dove \texttt{XXX}
indica il tempo in cui il programma è stato lanciato; si può specificare un
nome diverso con l'opzione \texttt{-L}. Si possono anche rileggere i pacchetti
da un file invece che dalla rete con l'opzione \texttt{-r}. 

\begin{table}[!htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|p{8cm}|}
    \hline
    \textbf{Modo}&\textbf{Descrizione}\\
    \hline
    \hline
    \texttt{fast}  & scrive una riga di allarme sul file di default. \\ 
    \texttt{full}  & scrive un allarme completo dell'intestazione del
                     pacchetto che lo ha causato.\\ 
    \texttt{none}  & disabilita gli allarmi.\\ 
    \texttt{unsock}& invia tutta l'informazione su un socket.\\ 
    \hline
  \end{tabular}
  \caption{Le quattro modalità di allarme specificabili con l'opzione
    \texttt{-A} di \texttt{snort}.} 
\label{tab:ids_snort_alert_options}
\end{table}

Infine l'utilizzo principale di \texttt{snort} è come NIDS; in tal caso di
solito si usa l'opzione \texttt{-D} per fare eseguire il programma in
background in modalità demone; questa modalità viene attivata con l'opzione
\texttt{-c} che specifica un file di configurazione da cui leggere le regole
di individuazione del traffico sospetto, i plug-in da usare e le modalità di
registrazione degli allarmi. Delle sei modalità di allarme usate da
\texttt{snort} le quattro che coinvolgono la registrazione su un file sono
controllate dall'opzione \texttt{-A} che specifica uno dei quattro modi
riportati in tab.~\ref{tab:ids_snort_alert_options}. In questo caso gli
allarmi vengono registrati nella directory specificata con \texttt{-l} in una
apposito file separato (\texttt{alert.log}). 

Le altre due modalità prevedono l'invio al sistema del \textit{syslog} con
l'opzione \texttt{-s} che userà la \textit{facility} \texttt{auth} e la
priorità \texttt{alert}. Alternativamente (avendo una versione compilata con
il relativo supporto) si può attivare una finestra di \textit{pop-up} su una
macchina Windows usando l'opzione \texttt{-M}. Vedremo inoltre che con gli
opportuni plug-in sono possibili modalità di registrazione ancora più
sofisticate. 

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|p{8cm}|}
    \hline
    \textbf{Opzione}&\textbf{Descrizione}\\
    \hline
    \hline
    \texttt{-A mode} & specifica la modalità di registrazione degli allarmi.\\
    \texttt{-b}      & richiede la registrazione dei pacchetti in formato
                       binario compatibile con \texttt{tcpdump}.\\ 
    \texttt{-c file} & specifica il file di configurazione che contiene le
                       regole usate in modalità NIDS.\\ 
    \texttt{-d}      & acquisisce anche il contenuto dei pacchetti oltre le
                       intestazioni (in modalità sniffer e logging).\\ 
    \texttt{-D}      & esegue il comando in background in modalità demone.\\ 
    \texttt{-e}      & visualizza/registra anche l'intestazione del pacchetto
                       a livello di collegamento fisico.\\ 
    \texttt{-F file} & legge le regole di selezione dei pacchetti da un file
                       invece che da riga di comando.\\ 
    \texttt{-g group}& gira per conto del gruppo specificato una volta
                       completata l'inizializzazione. \\ 
    \texttt{-h net}  & specifica quale è la rete locale su cui si trova la
                       macchina.\\ 
    \texttt{-i}      & specifica l'interfaccia da cui acquisire i pacchetti.\\ 
    \texttt{-l dir}  & specifica la directory dove registrare i pacchetti e
                       gli allarmi.\\ 
    \texttt{-n}      & indica un massimo di pacchetti da acquisire.\\ 
    \texttt{-N}      & disabilita la registrazione dei pacchetti (mantenendo
                       quella degli allarmi).\\ 
    \texttt{-P len}  & specifica la lunghezza massima dei dati acquisiti
                       all'interno di un pacchetto.\\ 
    \texttt{-r file} & legge i dati da un file invece che dalla rete.\\ 
    \texttt{-s}      & manda i messaggi di allarme al \textit{syslog}.\\ 
    \texttt{-S val=x}& imposta una variabile interna al valore specificato.\\ 
    \texttt{-t dir}  & esegue un \textit{chroot} alla directory specificata
                       dopo l'inizializzazione (tutti i file saranno relativi
                       a quest'ultima).\\ 
    \texttt{-u user} & gira per conto dell'utente specificato una volta
                       completata l'inizializzazione. \\ 
    \texttt{-v}      & stampa le intestazione dei pacchetti sulla console.\\ 
    \texttt{-o}      & modifica l'ordine di scansione delle regole.\\ 
%    \texttt{-} & .\\ 
    \hline
  \end{tabular}
  \caption{Principali opzioni di \texttt{snort}.} 
\label{tab:ids_snort_options}
\end{table}

Il comando supporta inoltre numerose altre opzioni (ad esempio per controllare
l'utente ed il gruppo per conto del quale viene eseguito dopo
l'inizializzazione). Si sono riportate le principali in
tab.~\ref{tab:ids_snort_options}, per l'elenco completo si faccia al solito
riferimento alla pagina di manuale. 


\subsection{La configurazione di \texttt{snort} come NIDS}
\label{sec:ids_snort_conf}

Come accennato in sez.~\ref{sec:ids_snort} per utilizzare \texttt{snort} in
modalità NIDS occorre usare l'opzione \texttt{-c} specificando un opportuno
file di configurazione. Questa è la modalità in cui viene usualmente avviato
come servizio dagli script di avvio, e nel caso di Debian il file di
configurazione usato è \index{configurazione!\texttt{/etc/snort/snort.conf}}
\texttt{/etc/snort/snort.conf}.  Assieme a questo in \texttt{/etc/snort/}
vengono mantenuti anche una serie di ulteriori file, ed in particolare le
regole per la generazione degli allarmi (nella sottodirectory \texttt{rules})
ed i file usati dai vari \textit{plug-in} con cui si possono estendere le
funzionalità di \texttt{snort}.

L'uso di un file di configurazione permette di utilizzare quest'ultimo per
specificare una serie di opzioni e valori in maniera più organica rispetto
alla riga di comando. Inoltre solo attraverso il file di configurazione si
possono impostare le regole di allarme, che costituiscono il cuore delle
funzionalità di NIDS di \texttt{snort}.  Il file ha la solita struttura di una
direttiva per riga, con righe vuote o inizianti per ``\texttt{\#}'' ignorate,
mentre direttive troppo lunghe possono essere scritte su più righe terminate
con una ``\texttt{\bslash}'' che indica la prosecuzione sulla riga successiva. 

Ciascuna direttiva è introdotta da una parola chiave, seguita dalla relativa
serie di parametri. Le direttive sono di vari tipi e controllano tutti gli
aspetti della esecuzione di \texttt{snort}, ad esempio la direttiva
\texttt{config} permette di impostare nel file di configurazione le stesse
proprietà che si specificano a riga di comando (ed anche altre che non hanno
una corrispondente opzione), con un qualcosa nella forma:
\begin{Example}
# sintassi
# config <opzione>: valore
config set_gid: snort
config disable_decode_alerts
\end{Example}
le principali opzioni sono riportate in
tab.~\ref{tab:ids_snort_config_options} l'elenco completo è riportato nello
\textit{Snort User Manual} disponibile su \href{http://www.snort.org/}
{\texttt{http://www.snort.com/}}. 

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|p{8cm}|}
    \hline
    \textbf{Opzione}&\textbf{Descrizione}\\
    \hline
    \hline
    \texttt{disable\_decode\_alerts}& disattiva gli allarmi derivati dalla
                                      decodifica dei pacchetti, è una 
                                      delle varie opzioni nella forma
                                      \texttt{disable\_xxx\_alerts} che
                                      permettono di disabilitare una certa
                                      serie di allarmi, i cui esempi si
                                      trovano nel 
                                      file di configurazione di esempio
                                      distribuito con \texttt{snort} e
                                      presente nella maggior parte delle
                                      distribuzioni.\\
    \texttt{dump\_payload}     & acquisisce e decodifica il contenuto dei
                                 pacchetti, è equivalente all'opzione
                                 \texttt{-d}.\\
    \texttt{decode\_data\_link}& decodifica il contenuto anche le intestazioni
                                 dei pacchetti a livello di collegamento
                                 fisico, è equivalente all'opzione
                                 \texttt{-e}.\\ 
    \texttt{bpf\_file}         & imposta un file da cui leggere le regole di
                                 selezione dei pacchetti, è equivalente
                                 all'opzione \texttt{-F}.\\
    \texttt{daemon}            & esegue il programma in modalità demone, è
                                 equivalente all'opzione \texttt{-D}.\\
    \texttt{set\_gid}          & imposta il gruppo per conto del quale viene
                                 eseguito il programma, è equivalente
                                 all'opzione \texttt{-g}.\\ 
    \texttt{set\_uid}          & imposta l'utente per conto del quale viene
                                 eseguito il programma, è equivalente
                                 all'opzione \texttt{-u}.\\
    \texttt{stateful}          & imposta .\\
    \texttt{verbose}           & stampa l'intestazione dei pacchetti in
                                 console, è equivalente
                                 all'opzione \texttt{-v}.\\
    \texttt{pkt\_count}        & imposta in numero massimo di pacchetti da
                                 acquisire, è equivalente all'opzione
                                 \texttt{-n}.\\
    \texttt{nolog}             & blocca la registrazione dei pacchetti, è 
                                 equivalente all'opzione \texttt{-N}.\\
    \texttt{logdir}            & imposta la directory dove registrare i file
                                 coi pacchetti acquisiti, è equivalente
                                 all'opzione \texttt{-v}.\\
    \texttt{interface}         & imposta l'interfaccia di rete, è equivalente
                                 all'opzione \texttt{-i}.\\
    \texttt{reference\_net}    & imposta l'indirizzo della rete locale, è 
                                 equivalente all'opzione \texttt{-h}.\\
    \texttt{detection}         & imposta il motore di rilevamento.\\
    \texttt{order}             & modica l'ordine di scansione delle regole
                                 (vedi sez.~\ref{sec:ids_snort_rules}), è 
                                 equivalente all'opzione \texttt{-o}.\\
    \hline
  \end{tabular}
  \caption{Principali opzioni della direttiva \texttt{config} nel file di
    configurazione di \texttt{snort}.} 
\label{tab:ids_snort_config_options}
\end{table}

Una seconda direttiva è \texttt{var}, che permette di definire delle variabili
interne da riutilizzare all'interno del file di configurazione, utile
specialmente per parametrizzare le regole di allarme; un possibile esempio di
dichiarazioni di questo tipo (riprese dal file di configurazione installato da
Debian) è la seguente:
\begin{Example}
# sintassi
# var VARIABILE valore
#var HOME_NET $eth0_ADDRESS
var HOME_NET [192.168.1.0/24,172.16.0.0/16]
var EXTERNAL_NET !$HOME_NET
var DNS_SERVERS $HOME_NET
var HTTP_SERVERS $HOME_NET
var HTTP_PORTS 80
\end{Example}

Le variabili possono avere nomi che seguono la stessa sintassi delle variabili
di shell, e di norma si segue anche la stessa convenzione di scriverle in
lettere maiuscole. I valori possono essere specificati sia facendo riferimento
ad altre variabili, anche qui anteponendo un ``\texttt{\$}'' come nella shell,
ma oltre a stringhe e numeri, si possono specificare indirizzi di rete in
notazione CIDR, e liste di valori fra parentesi quadre, inoltre quando si
specificano indirizzi e porte si può usare il carattere ``\texttt{!}'' per
invertire la selezione. 

Come detto più volte la potenza di \texttt{snort} consiste anche nella sua
capacità di utilizzare una serie di estensioni, queste vengono realizzate
nella forma di plugin che permettono di processare i pacchetti una volta che
questi sono stati decodificati, ma prima dell'esecuzione del motore di analisi
e rilevazione delle intrusioni. Per abilitare queste estensioni si utilizza la
direttiva \texttt{preprocessor} seguita dal nome del relativo plugin, più
tutte le opzioni che ciascuno di questi supporta. Di nuovo un esempio di
queste direttive, preso dal file di configurazione di default, è il seguente:
\begin{Example}
# sintassi
# preprocessor <plugin>: opzione
preprocessor flow: stats_interval 0 hash 2
preprocessor frag2
preprocessor stream4: disable_evasion_alerts detect_scans
\end{Example}

In questo caso ciascun plugin comporta una serie di funzionalità e diverse
opzioni ne controllano il comportamento; in particolare molte delle capacità
di rilevamento derivano direttamente dagli stessi plugin. Un elenco dei
principali è il seguente:
\begin{basedescript}{\desclabelwidth{3cm}\desclabelstyle{\nextlinelabel}}
\item[\texttt{flow}] questo plugin ha sostanzialmente uno scopo di servizio e
  serve a classificare i flussi di dati, viene poi utilizzato da altri plugin
  come base per successivi analisi. Al momento viene usato soltanto da
  \texttt{flow-portscan}, ma è previsto che in futuro su di esso si vadano a
  basare anche gli altri plugin per la classificazione degli stati dei
  pacchetti. Il plugin supporta quattro opzioni diverse che controllano
  parametri interni del funzionamento, descritte nel file \texttt{README.flow}
  allegato alla documentazione (su Debian in
  \texttt{/usr/share/doc/snort-doc}). Il plugin non genera nessun tipo di
  allarme. 
\item[\texttt{frag2}] Questo plugin esegue la deframmentazione preventiva dei
  pacchetti IP, rilevando al contempo attacchi basati su questo tipo di
  pacchetti (in genere si tratta di \itindex{Denial~of~Service~(DoS)}
  \textit{Denial of Service}). Le opzioni permettono di controllare parametri
  interni del funzionamento e di solito si lasciano al valore di default. Il
  loro significato si può trovare nei commenti all'interno del file di
  configurazione di default distribuito con il pacchetto. Il pacchetto genera
  degli allarmi se nel riassemblaggio rileva pacchetti di dimensione eccessiva
  ($>64$k), o frammenti troppo piccoli (quelli utilizzati nel cosiddetto
  \textit{teardrop attack}).
\item[\texttt{stream4}] è il plugin che riassembla i flussi di dati TCP e
  rileva tutti i pacchetti anomali, identificando vari tipi di portscan,
  tentativi di \textit{OS fingerprinting},\footnote{chiama così la tecnica,
    usata anche da \texttt{nmap} come accennato in
    sez.~\ref{sec:ids_portscanner}, per rilevare il tipo di sistema operativo
    sulla base delle risposte fornite da quest'ultimo; in questo caso
    \texttt{snort} rileva ovviamente solo le tecniche di
    \textit{fingerprinting} attivo, in cui si inviano pacchetti di test, non
    può ovviamente accorgersi di tecniche passive come quelle usate da
    \texttt{ettercap} cui si è accennato in sez.~\ref{sec:ids_monitor}.} ed
  altre anomalie varie legate a possibili attacchi. Supporta numerose opzioni
  che ne controllano il comportamento, le principali sono
  \texttt{detect\_scans} che attiva il rilevamento e la generazione di allarmi
  in caso di portscan, e \texttt{disable\_evasion\_alerts} che disabilita una
  possibile sorgente di numerosi allarmi, che di norma vengono attivate. La
  descrizione delle altre opzioni si può trovare di nuovo nei commenti
  all'interno del file di configurazione di default distribuito con il
  pacchetto. 
\item[\texttt{stream4\_reassemble}] questo preprocessore riassembla i flussi
  di dati delle connessioni TCP, identificando con questo tutti i pacchetti
  estranei, in questo modo poi si otterrà, per l'uso successivo, un flusso di
  dati già pulito, del quale esaminare solo il contenuto. In genere viene
  sempre abilitato insieme al precedente \texttt{stream4}. 
\item[\texttt{flow-portscan}] questo è un motore di rilevazione di portscan
  che si base sul precedente motore di analisi \texttt{flow} che deve sempre
  essere attivato; questo soprassiede due altri processori usati in precedenza
  (\texttt{portscan1} e \texttt{portscan2}) e pur essendo più complesso è in
  grado di mitigare la frequenza di falsi positivi, e prevede una lunga lista
  di opzioni di configurazione che permettono di controllarne tutti i
  parametri interni; questi sono descritti in dettaglio nel file
  \texttt{README.flow-portscan} allegato alla documentazione. 
\item[\texttt{http\_inspect}] questo preprocessore consente di decodificare e
  normalizzare il traffico HTTP, in modo da rilevare tutti gli attacchi basati
  sull'uso di diverse mappe di caratteri e codifiche, riportando tutto ad una
  codifica standard. Viene usato insieme al successivo
  \texttt{http\_inspect\_server}, entrambi sono descritti in dettaglio nel
  file \texttt{README.http\_inspect} della documentazione allegata. 
\end{basedescript}

Il comando supporta una serie di altri preprocessori, in genere per effettuare
decodifiche di particolari protocolli o analisi specifiche, la relativa
documentazione, scarsa purtroppo, si trova insieme alla documentazione
generale del pacchetto \texttt{snort} o nei commenti del file di
configurazione. 
 
Un'altra direttiva fondamentale per l'uso di \texttt{snort} è \texttt{output},
che governa i molteplici plugin per la registrazione dei dati (sia pacchetti
che allarmi) rilevati dal programma.  Un esempio di queste direttive, ricavato
da quelli contenuti nel file di configurazione di default, è il seguente:
\begin{Example}
# sintassi
# output <plugin>: opzione
output alert_syslog: host=hostname:port, LOG_AUTH LOG_ALERT
output log_tcpdump: snort.log
output database: log, mysql, user=root password=test dbname=db host=localhost
\end{Example}

Come per i preprocessori ciascun plugin di uscita supporta una serie di
funzionalità e la relativa serie di opzioni di configurazione; i principali
plugin sono riportati di seguito, un elenco più completo si trova nello
\textit{Snort User Manual} già citato in precedenza:
\begin{basedescript}{\desclabelwidth{3cm}\desclabelstyle{\nextlinelabel}}
\item[\texttt{alert\_syslog}] invia gli allarmi sul sistema del
  \textit{syslog}, nella sua forma più generale richiede come opzione un
  indirizzo ed una porta da specificare con l'opzione \texttt{host} nella
  forma classica mostrata nell'esempio, seguito eventualmente dalla
  \textit{facility} e dalla priorità cui piazzare gli allarmi. 
\item[\texttt{log\_tcpdump}] permette di indicare un file, come unica opzione,
  su cui registrare i pacchetti nel solito formato usato da \texttt{tcpdump}. 
\item[\texttt{database}] è probabilmente il plugin più evoluto, dato che
  consente di registrare gli eventi di allarmi su un database, eventualmente
  situato anche su una macchina remota.\footnote{è tramite questo plugin che
    si possono usare sistemi di integrazione di allarmi da più fonti come
    ACID, che poi dal database legge i dati e genera automaticamente dei
    rapporti e delle pagina con tutti gli allarmi e le statistiche.} 
\end{basedescript}

La funzionalità più interessante di \texttt{snort}, quella che lo rende uno
degli IDS più interessanti fra quelli disponibili (compresi pure prodotti
proprietari molto costosi), è quella di possedere un motore di analisi per il
rilevamento di traffico sospetto estremamente potente, che è possibile
controllare tramite delle opportune \textsl{regole}, con le quali si possono
generare degli allarmi, eseguire altre azioni, registrare i pacchetti, sulla
base di una enorme lista di proprietà sia dei pacchetti stessi che dei flussi
di dati che le varie funzionalità permettono di identificare, che possono
venire espresse tramite un opportuno linguaggio di scripting elementare, che
permette di creare condizioni e controlli anche molto complessi. 

Data l'ampiezza dell'argomento lo tratteremo a parte in
sez.~\ref{sec:ids_snort_rules}, qui vale la pena solo di ricordare un'ultima
direttiva \texttt{include} che serve appunto per inserire all'interno del file
di configurazione altri file. Questo viene usato principalmente proprio per
includere i file che contengono appunto le cosiddette \textsl{regole} di
\texttt{snort}. In genere infatti sono già state prodotte un vasto insieme di
regole pronte, in grado di identificare le più varie forme di attacchi
possibili, che normalmente vengono fornite su una serie di file a parte,
caricati appunto con questa direttiva, che ha la forma:
\begin{Example}
# sintassi
# include pathname
include classification.config
include reference.config
include $RULE_PATH/local.rules
include $RULE_PATH/bad-traffic.rules
include $RULE_PATH/exploit.rules
... 
\end{Example}
%$


\subsection{Le regole di \texttt{snort}}
\label{sec:ids_snort_rules}

Come accennato la vera potenza di \texttt{snort} sta nel suo motore di
rilevamento, che viene controllato da una serie di regole che vengono
processate dal programma. Questo le applica ai dati che riceve, e sulla base
di quanto in esse specificato è in grado di compiere una serie di azione come
generare allarmi, registrare pacchetti, attivare altre regole. 

Le regole vengono espresse tramite alcune direttive speciali, riportate in
tab.~\ref{tab:ids_snort_rules_type}, chiamate \textsl{azioni} (o \textit{rule
  action}), ciascuna regola è introdotta da una di queste azioni, seguita dal
corpo della regola; quest'ultimo è lo stesso per ciascuna di esse, seguendo
una sintassi comune. 

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|p{8cm}|}
    \hline
    \textbf{Tipo}&\textbf{Descrizione}\\
    \hline
    \hline 
    \texttt{alert}   & genera un allarme secondo quanto specificato nella
                       regola e poi registra il pacchetto.\\
    \texttt{log}     & registra il pacchetto.\\
    \texttt{pass}    & ignora il pacchetto.\\
    \texttt{activate}& genera un allarme ed attiva una regola dinamica.\\
    \texttt{dynamic} & la regola è disattiva fin quando non viene attivata
                       e diventa una regola di registrazione.\\
    \hline
  \end{tabular}
  \caption{Le direttive predefinite per la definizione delle regole di
    \texttt{snort}.}  
\label{tab:ids_snort_rules_type}
\end{table}

Le regole hanno un ordine preciso di scansione, prima vengono utilizzate le
\texttt{alert} per generare gli allarmi, poi le \texttt{pass} per ignorare i
pacchetti che non si vuole siano ulteriormente processati, e poi le
\texttt{log} per registrarli. Quindi l'uso di \texttt{pass} non evita che
siano generati eventuali allarmi; questo è per molti controintuitivo per cui
\texttt{snort} mette a disposizione sia l'opzione \texttt{-o} a riga di
comando che il parametro \texttt{order} per la direttiva \texttt{config} per
cambiare le modalità di questa scansione, processando per prima le regole di
tipo \texttt{pass}. 


A ciascuna azione seguono una serie di campi per la selezione dei pacchetti
cui la regola si applica; il primo di questi indica il protocollo con il nome
utilizzato in \texttt{/etc/protocols} (al momento \texttt{snort} analizza solo
TCP, UDP, ICMP, IP, ma in futuro potranno essercene altri).  I campi
successivi servono per specificare indirizzi e porte dei pacchetti e sono
sempre nella forma:
\begin{Example}
ip-sorgente porta-sorgente -> ip-destinazione porta-destinazione
\end{Example}
dove si può usare per ciascun termine la parola chiave \texttt{any} per
indicare un indirizzo qualunque o indicare gli indirizzi sia singoli che come
reti in notazione CIDR, invertire le selezioni apponendo un ``\texttt{!}'', o
indicare liste di questi elementi separate da virgole e poste fra parentesi
quadre. Per le porte invece si possono indicare degli intervalli separandoli
con il carattere ``\texttt{:}'', un esempio allora potrebbe essere una regola
del tipo:
\begin{Example}
alert tcp ![192.168.1.0/24,10.0.0.0/8] any -> 192.168.1.0/24 111 \
    (content: "|00 01 86 A5|"; msg: "mountd access";)
\end{Example}
inoltre al posto dei valori possono essere usate delle variabili, definite
secondo quanto visto in sez.~\ref{sec:ids_snort_conf}. Infine in un criterio
di selezione si può adoperare l'operatore \texttt{<>}, che indica le coppie
indirizzo porta in entrambe le direzioni (consentendo così di classificare
immediatamente tutto il traffico di una connessione). 

Come l'esempio mostra una volta selezionato il pacchetto in base alle
informazioni essenziali (le porte si devono omettere in caso di pacchetti
ICMP) il resto della regola sia espresso in un ultimo capo, compreso fra
parentesi tonde in cui si inseriscono una serie di \textsl{opzioni} nella
forma \texttt{opzione: valore}, separate da dei ``\texttt{;}'' che indicano la
fine dei parametri passati all'opzione.  Gran parte della potenza di
\texttt{snort} deriva dalle capacità di queste opzioni che sono le più varie,
come quella di analizzare il contenuto dei pacchetti selezionati, e di
produrre messaggi di conseguenza, come nell'esempio. 

In particolare, prima di passare all'elenco di quelle principali, sono da
segnalare due opzioni, che sono usate per la particolare funzionalità indicate
nell'uso delle azioni \texttt{activate} e \texttt{dynamic}. L'idea alla base
di queste azioni è quella di poter creare una regola che viene attivata
dinamicamente (da questo i nomi) in corrispondenza di alcuni eventi, in genere
appunto per registrare tutto il traffico ad essi collegato anche quando
l'evento che ha generato l'allarme è passato. 

Per far questo si deve sempre specificare una coppia di regole, la prima di
tipo \texttt{activate} che identifica l'evento critico (e genera pertanto
anche un allarme), una tale regola ha una opzione obbligatoria,
\texttt{activates}, che deve indicare un numero che identifica la regola
\texttt{dynamic} da attivare. Quest'ultima a sua volta ha una opzione
obbligatoria \texttt{activated\_by} che indica il numero da usare per
attivarla. Un esempio di una coppia di tali regole potrebbe essere il
seguente:
\begin{Example}
activate tcp !$HOME_NET any -> $HOME_NET 143 (flags: PA; \
      content: "|E8C0FFFFFF|/bin"; activates: 1; \
      msg: "IMAP buffer overflow!\";)
dynamic tcp !$HOME_NET any -> $HOME_NET 143 (activated_by: 1; count: 50;)
\end{Example}

Come già detto le opzioni delle regole sono il cuore delle funzionalità di
\texttt{snort}, quello che segue è un elenco delle principali con relativa
spiegazione del significato e dei parametri che le controllano, e degli
effetti che sortiscono nel comportamento del programma, un elenco molto più
dettagliato si può trovare nello \textit{Snort User Manual} già citato più
volte:
\begin{basedescript}{\desclabelwidth{2cm}\desclabelstyle{\nextlinelabel}}
\item[\texttt{msg}] specifica una stringa da riportare come messaggio quando
  utilizzata da regole di allarme o di registrazione dei pacchetti; un
  possibile esempio è:
\begin{Example}
msg: "testo del messaggio";
\end{Example}

\item[\texttt{ttl}] imposta un criterio di corrispondenza sul valore del campo
  TTL del pacchetto, rispetto all'espressione passata come parametro. Questo
  permette di selezionare pacchetti in base a questo valore e può essere
  utilizzato per identificare l'esecuzione di un \texttt{traceroute}; un
  possibile esempio è:
\begin{Example}
ttl: 0;
ttl: >220;
\end{Example}
\item[\texttt{dsize}] imposta un criterio di corrispondenza sulle dimensioni
  del carico dati dei pacchetti, che è molto più efficiente della analisi del
  contenuto per eseguire rilevazioni di eventuali tentativi di \textit{buffer
    overflow}. Supporta varie combinazioni degli operatori \texttt{>} e
  \texttt{<}, anche se in genere si usa solo il primo; possibili esempi sono:
\begin{Example}
dsize: >1000;
dsize: 300<>400;
\end{Example}

\item[\texttt{fragbits}] imposta un criterio di corrispondenza sulla presenza
  dei bit riservati dell'intestazione del protocollo IP.\footnote{la struttura
    dell'intestazione di IP è riportata in fig.~\ref{fig:fw_IP_header}.} 
  Questi sono tre e sono usati principalmente per la gestione dei pacchetti
  frammentati: il \textit{Reserved Bit} (RB), normalmente non utilizzato, è
  selezionabile con \texttt{R}, il \textit{Don't Fragment} bit (DF), usato per
  impedire la frammentazione e richiedere l'emissione di un ICMP
  \textit{fragmentation needed}, è selezionabile con \texttt{D} ed il
  \textit{More Fragments} bit, usato per indicare la presenza di ulteriori
  frammenti, è selezionabile con \texttt{M}. Specificando uno o più di questi
  caratteri si richiede la presenza di tutti e soli i bit corrispondenti;
  usando anche il carattere \texttt{+} si richiede solo tutti quelli indicati
  siano presenti, usando il carattere \texttt{*} si richiede che almeno uno di
  quelli indicati sia presente, mentre usando il carattere \texttt{!} si
  richiede che il flag indicato non sia presente; possibili esempi sono:
\begin{Example}
fragbits: M+;
\end{Example}
  
\item[\texttt{content}] imposta un criterio di corrispondenza sul contenuto
  del carico dati del pacchetto. Il criterio comporta ovviamente una ricerca
  su tutto il traffico è piuttosto pesante dal punto di vista del carico sulla
  macchina, ma è anche la funzionalità che permette di eseguire la rilevazione
  di gran parte degli attacchi che in genere vengono compiuto nei confronti di
  server vulnerabili.  Il vantaggio di questo criterio è che può essere
  ripetuto più volte nella stessa opzione per specificare diversi contenuti e
  ridurre l'incidenza di falsi positivi (una corrispondenza casuale è sempre
  possibile) e permette l'uso di una serie ulteriori di opzioni che permettono
  di estenderne il comportamento. 
  
  L'opzione prende come parametro una espressione che permette di indicare sia
  un contenuto binario che testuale, il contenuto deve essere passato come
  parametro racchiuso fra virgolette, un contenuto binario deve essere
  specificato come bytecode esadecimale eventualmente separato da spazi e
  racchiuso fra delle barre verticali, mentre un contenuto testuale può essere
  scritto direttamente, con l'unica accortezza di proteggere con il carattere
  ``\texttt{\bslash}'' i caratteri riservati ``\texttt{;}'', ``\verb|"|'',
  ``\texttt{:}'' e ``\texttt{\bslash}''; un possibile esempio è:
\begin{Example}
content:"|E8 C0FF FFFF|/bin/sh";
\end{Example}
  
\item[\texttt{flags}] imposta un criterio di corrispondenza sul valore dei
  flag presenti nell'intestazione di un pacchetto TCP, utilizzando i caratteri
  illustrati in tab.~\ref{tab:ids_snort_flag_id}. Come per i flag di IP
  indicando un gruppo di questi caratteri si richiede che siano presenti tutti
  e soli i flag corrispondenti, valgono le stesse estensioni fornite dai
  caratteri ``\texttt{*}'', ``\texttt{+}'' e ``\texttt{!}'' illustrate in
  precedenza. Inoltre in questo caso si può indicare una maschera opzionale,
  in cui si indichi quali degli altri flag non considerare nella
  corrispondenza, così da creare selezioni in cui si richiede la presenza di
  solo certi flag, l'assenza di altri e l'irrilevanza dei restanti. Un
  possibile esempio è:
\begin{Example}
flags:SF,12;
flags: A+;
\end{Example}
  
\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|l|}
    \hline
    \textbf{Flag}&\textbf{Descrizione}\\
    \hline
    \hline 
    \texttt{F}& Flag FIN.\\
    \texttt{S}& Flag SYN.\\
    \texttt{R}& Flag RST.\\
    \texttt{P}& Flag PUSH.\\
    \texttt{A}& Flag ACK.\\
    \texttt{U}& Flag URG.\\
    \texttt{2}& Secondo bit riservato.\\
    \texttt{1}& Primo bit riservato.\\
    \texttt{0}& Nessun bit attivo.\\
    \hline
  \end{tabular}
  \caption{Identificatori dei flag TCP nell'opzione \texttt{flag}.}  
\label{tab:ids_snort_flag_id}
\end{table}

\item[\texttt{ack}] imposta un criterio di corrispondenza sul valore del campo
  di \textit{acknoweledge} di un pacchetto TCP, utilizzato in genere per
  riconoscere il \textit{TCP ping} di \texttt{nmap} illustrato in
  sez,~\ref{sec:ids_portscanner}, che è contraddistinto da un valore nullo di
  tale campo. L'opzione richiede un valore numerico; un esempio è il seguente:
\begin{Example}
ack: 0;
\end{Example}
  
\item[\texttt{itype}] imposta un criterio di corrispondenza sul valore del
  campo \textit{type} di un pacchetto ICMP,\footnote{una spiegazione sul
    significato di questi pacchetti è stata affrontata in
    sez.\ref{sec:fw_icmp_filtering}, ed in tab.\ref{tab:fw_icmp_type} e
    tab.\ref{tab:fw_icmp_code} sono riportati i valori numerici dei vari campi
    del protocollo.}  permettendo la selezione dei vari tipi di pacchetto; un
  possibile esempio è il seguente:
\begin{Example}
itype: 0;
\end{Example}
  
\item[\texttt{icode}] imposta un criterio di corrispondenza sul valore del
  campo \textit{code} di un pacchetto ICMP, utilizzato per gli stessi scopi
  del precedente; un possibile esempio è il seguente:
\begin{Example}
icode: 0;
\end{Example}
  
%%\item[\texttt{icmp\_id}] imposta un criterio di corrispondenza sul valore del
%% campo ID di un pacchetto ICMP che viene

  
\item[\texttt{resp}] permette di indicare una azione di risposta da dare in
  caso di traffico che corrisponde alla regola in cui è usata. L'idea è di
  utilizzare questa opzione per bloccare automaticamente il traffico dalle
  connessioni da cui si identifica un attacco. Come già sottolineato questo è
  molto pericoloso sia perché è facile chiudersi fuori in caso di errore, sia
  perché questa funzionalità può essere usata contro di noi per un
  \itindex{Denial~of~Service~(DoS)} DoS eseguendo apposta un attacco simulato.
  L'opzione prende come parametro una lista delle azioni elencate in
  tab.~\ref{tab:ids_snort_resp_action}, separate da virgole; un possibile
  esempio è il seguente:
\begin{Example}
resp: rst_all
\end{Example}

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|l|}
    \hline
    \textbf{Azione}&\textbf{Significato}\\
    \hline
    \hline 
    \texttt{rst\_snd}  & invia un reset TCP alla sorgente.\\
    \texttt{rst\_rcv}  & invia un reset TCP alla destinazione.\\
    \texttt{rst\_all}  & invia un reset TCP ad entrambi i capi.\\
    \texttt{icmp\_net} & invia un \textit{ICMP Net Unreachable} al mittente.\\
    \texttt{icmp\_host}& invia un \textit{ICMP Host Unreachable} al mittente.\\
    \texttt{icmp\_port}& invia un \textit{ICMP Port Unreachable} al mittente.\\
    \texttt{icmp\_all} & invia tutti i precedenti pacchetti ICMP al mittente.\\
    \hline
  \end{tabular}
  \caption{Significato delle azioni dell'opzione \texttt{resp}.}  
\label{tab:ids_snort_resp_action}
\end{table}

%\item[\texttt{react}] 
  
\item[\texttt{reference}] imposta una (o più se utilizzata più volte)
  referenza per il particolare attacco identificato dalla regola in questione,
  così che questa possa passare nel messaggio di allarme ed essere utilizzata
  per identificare la natura di quest'ultimo. L'opzione richiede due parametri
  separati da virgola, il nome di un ente classificatore (espresso in forma
  della URL del relativo sito, anche se alcuni di essi sono identificati con
  stringhe predefinite) ed l'identificativo usato da questo per lo specifico
  attacco; un possibile esempio è il seguente:
\begin{Example}
reference: bugtraq,5093;
reference: cve,CAN-2002-1235;
\end{Example}
  
\item[\texttt{sid}] definisce un identificatore univoco per la regola in
  questione, in modo che i plugin di uscita possano trattarla velocemente. I
  valori inferiori a 100 sono riservati, quelli da 100 a 1000000 sono
  utilizzati per le regole distribuite insieme a \texttt{snort}, e quelli
  sopra 1000000 per l'uso locale; un possibile esempio è il seguente:
\begin{Example}
sid:1810;
\end{Example}
 
\item[\texttt{classtype}] definisce in quale classe fra tutte quelle in cui
  sono categorizzati i vari tipi di attacco ricade quello identificato dalla
  regola corrente. Una serie di valori sono predefiniti, altro possono essere
  definiti con la direttiva \texttt{config classification} (per una tabella
  completa si faccia riferimento allo \textit{Snort User Manual}); un
  possibile esempio è il seguente:
\begin{Example}
classtype:successful-admin;
\end{Example}

%\item[\texttt{priority}]; un possibile esempio è il seguente:
  
\item[\texttt{tag}] permette di sostituire le regole di tipo \texttt{dynamic}
  consentendo la definizione di un insieme di pacchetti da registrare oltre
  quelli relativi all'allarme. Con questa opzione tutto il traffico
  proveniente dalla sorgente che ha innescato l'allarme può essere
  \textsl{etichettato} e registrato. L'opzione prevede almeno tre parametri:
  il primo indica il tipo di traffico e può essere \texttt{host} per indicare
  tutto il traffico proveniente dall'IP sorgente o \texttt{session} per
  indicare il traffico nella stessa connessione; il secondo indica un numero
  di unità da registrare ed il terzo l'unità stessa (che può essere
  \texttt{packets} o \texttt{seconds}); un possibile esempio è il seguente:
\begin{Example}
tag: session,5,packets;
\end{Example}
  
%% \item[\texttt{flow}] identifica le proprietà del flusso di dati di uno
%%   \textit{stream} TCP selezionando i pacchetti sia in base alla direzione
%%   dello stesso (da o verso il server o il client) o dello stato. Prende come
%%   argomento uno dei valori di tab.~\ref{tab:ids_snort_flow_param} un possibile
%%   esempio è il seguente:
%% \begin{Example}
%% flow:from_server,established;
%% \end{Example}
  
%% \begin{table}[htb]
%%   \centering
%%   \footnotesize
%%   \begin{tabular}{|l|l|}
%%     \hline
%%     \textbf{Parametro}&\textbf{Significato}\\
%%     \hline
%%     \hline 
%%     \texttt{to\_client}  & attivo nelle risposte dal server al client.\\
%%     \texttt{to\_server}  & attivo nelle risposte dal client al server.\\
%%     \texttt{from\_client}& .\\
%%     \texttt{from\_server}& attivo nelle risposte dal client al server.\\
%%     \texttt{established} & .\\
%%     \texttt{stateless}   & .\\
%%     \texttt{no\_stream}  & .\\
%%     \texttt{only_stream} & .\\
%%     \hline
%%   \end{tabular}
%%   \caption{Parametri dell'opzione \texttt{flow}.}  
%% \label{tab:ids_snort_flow_param}
%% \end{table}
  
\item[\texttt{ip\_proto}] imposta un criterio di corrispondenza sul campo di
  protocollo di un pacchetto IP, permettendo di selezionare pacchetti anche
  degli altri protocolli. L'opzione prende come parametro il valore del
  suddetto campo, e si può usare il carattere ``\texttt{!}'' per negare una
  selezione; un possibile esempio è il seguente:
\begin{Example}
ip_proto: 50
\end{Example}
\end{basedescript}


%\subsection{Il pacchetto \texttt{prelude}}
%\label{sec:ids_prelude}

%Una alternativa a \texttt{snort} per quanto riguarda 

\ifwhole\else

\appendix
%\include{ringraziamenti}

\input{../commons/end}

\end{document}
\fi

% LocalWords:  scan tab default SYN flag connect Phrack sez experimental call
% LocalWords:  stealth Xmas tree URG PUSH ping communication prohibited info
% LocalWords:  protocol idle ACK Window RPC list FTP bounce allow org submit
% LocalWords:  attack socket stack RST cookie modules LUA datadir nse search
% LocalWords:  half don't engine options ecr seq interfaces analyze statistics
% LocalWords:  synlogger iptables zombie ID Hierarchy Conversations Endpoints
% LocalWords:  fragmentation Solaris OpenBSD sniffing bridged unified GTK tmp
% LocalWords:  router ICMP port unreachable destination forwarding CEST httpd
% LocalWords:  portmapper echo nobody pcap unoffensive redirect cisco gtk title
% LocalWords:  request timestamp netmask po' dhcp DHCP spoofing stealing view
% LocalWords:  paranoid sneaky polite normal Mitm reply profiles connections
% LocalWords:  timeout IPv redirects fork OpenVAS openvas openvasd commands NVT
% LocalWords:  DNS netfilter crash SSH text rpcinfo Capure etterlog local nvt
% LocalWords:  denial localhost fingerprint sniffer Vulnerability Assessment
% LocalWords:  incremental ethernet MAC address openvassd openvasmd openvasad
% LocalWords:  firmware broadcast promiscuous BNC hub Administrator Squeeze
% LocalWords:  Truelite Srl IDS username SSL IPSEC VPN Certification Authority
% LocalWords:  misuse detection anomaly line off snort alert IPS created sync
% LocalWords:  prevention offline aide host based log LIDS patch NIDS
% LocalWords:  kernel portscanner TCP UDP netstat backdoor ps ls rootkit live
% LocalWords:  CDROM firewall like nmap nmapfe portscan hostname CIDR at mysql
% LocalWords:  starting CET interesting ports the scanned but not shown below
% LocalWords:  closed service tcp ssh smtp domain rpcbind smux printer ipp run
% LocalWords:  ldapssl unknown squid postgres completed seconds null version
% LocalWords:  Windows monk udp filtered dhcpserver snmp syslog Criptographic
% LocalWords:  mdbs daemon nfs ipc protocols icmp igmp zorn OpenSSH Postfix rpc
% LocalWords:  smtpd CUPS dict dictd access denied Elitegroup ECS of
% LocalWords:  root initiating against discovered took to total For OSScan is
% LocalWords:  assuming and neither firewalled appears good device type general
% LocalWords:  purpose running OS details Gentoo rc uptime days since Fri Nov
% LocalWords:  sequence prediction class increments difficulty luck IPID all 
% LocalWords:  Generation zeros switch mirroring bridging arpwatch ip
% LocalWords:  tcpdump libpcap SIGINT ifconfig any iface count administratively
% LocalWords:  BSD Berkley BPF davis src dst ether fddi arp rarp
% LocalWords:  decnet gateway less greater shell dotted decimal nw prt prot eth
% LocalWords:  listening ack win nop DF tos wireshark iptraf ncurses zenmap NIC
% LocalWords:  fig html traffic scroll dissector capture filter acknowledgement
% LocalWords:  stream analize PDF security Nessus plugin client plug scripting
% LocalWords:  NASL language mkcert addr adduser using as holder
% LocalWords:  temporary add new authentication pass cert again rules has which
% LocalWords:  system allows you restrict hosts that right instance may him
% LocalWords:  want able his own only please see for syntax this hit ctrl done
% LocalWords:  can have an empty DN added accept deny rmuser remove removed it
% LocalWords:  update plugins checkbox selection option prefs Hydra
% LocalWords:  antivirus trojan worm signature chkrootkit ROOTDIR checking 
% LocalWords:  found basename infected biff write aliens suspect files logs
% LocalWords:  searching sniffer's take while nothing dirs
% LocalWords:  defaults Lion anomalies history asp lkm
% LocalWords:  bindshell detected rexedcs promisc packet sockets lsof
% LocalWords:  deleted scalper slapper adore advanced inode hash init USB job
% LocalWords:  cron aideinit linkato conf checksum sha rmd tiger crc
% LocalWords:  haval gost custom Binlib ConfFiles pathname MAILTO filesystem pw
% LocalWords:  capabilities CAP CHOWN DAC OVERRIDE discrectionary control READ
% LocalWords:  FOWNER FSETID suid sgid LOCK OWNER SysV KILL LEASE lease
% LocalWords:  immutable append ext MKNOD ADMIN multicasting BIND RAW
% LocalWords:  multicast SETGID group SETPCAP SETUID SYS swap reboot CHROOT TTY
% LocalWords:  chroot MODULE NICE PACCT accounting RAWIO RESOURCE CONFIG hangup
% LocalWords:  chattr Virtual WRITE lidsadm lidsconf 
% LocalWords:  switching protections enable NSA SELinux support
% LocalWords:  lids cap lidstool HIDDEN proc PROTECTED session LFS reassemble
% LocalWords:  RELAY SOURCE FROM SUBJECT ALert POSTBOOT SHUTDOWN shutdown ini
% LocalWords:  GLOBAL DISCOVERY bash subject object from level capability GRANT
% LocalWords:  OpenLDAP RELOAD facility kern Jun touch dev pid ppid uid gid NL
% LocalWords:  attempt utime writing logging disabled klogd etherape ettercap
% LocalWords:  poisoning cache middle storm GW RT dat
% LocalWords:  fingerprinting IPBASED MACBASED ARPBASED PUBLICARP debug
% LocalWords:  SMARTARP activity flip changed bogon mismatch reused old
% LocalWords:  original vendor digital conductor Monday June international Ltd
% LocalWords:  previous mirror Mbit intrusion point failure NAT
% LocalWords:  overflow dump Initializing tun decoding interface len
% LocalWords:  Initialization Roesch pkt TTL IpLen DgmLen AP Seq TcpLen
% LocalWords:  Options TS Content analyzed packets dropping Breakdown Mb
% LocalWords:  action Stats EAPOL IPX OTHER DISCARD wireless fragmented Rebuilt
% LocalWords:  fragment trackers elements used discarded memory faults bpf
% LocalWords:  reassembly flushes segments exiting logger unsock auth config db
% LocalWords:  disable decode alerts Manual payload stateful nolog logdir order
% LocalWords:  reference var HOME EXTERNAL SERVERS preprocessor flow stats frag
% LocalWords:  interval evasion detect scans README DoS teardrop inspect dbname
% LocalWords:  ACID classification RULE PATH rule action activate dynamic msg
% LocalWords:  content mountd activates activated flags FFFFFF bin IMAP ttl
% LocalWords:  traceroute dsize fragbits reserved needed fragments rst
% LocalWords:  bytecode FFFF acknoweledge itype icode resp all snd reset rcv
% LocalWords:  URL bugtraq cve sid classtype successful admin tag knowledge ntp
% LocalWords:  exclude report latency https jetdirect QEMU Maimon Uriel size
% LocalWords:  scanflags length SCTP performed incorrect results unfiltered
% LocalWords:  REJECT chunk ABORT IPIP ethereal page environment

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "sicurezza"
%%% End: 
