Snort: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m 45 revisioni importate da w:Snort: voce da trasferire |
sistemo |
||
Riga 1:
'''SNORT''' è un
▲'''SNORT''' è un [[applicazione|applicativo]] [[open source]] con funzioni di tipo [[Intrusion detection system|IDS]] distribuito con la [[licenza GPL]].
== Intrusion Detection Systems Snort ==
L'IDS viene installato collegando una o più sonde configurate per analizzare ogni pacchetto che circola nella rete, garantendo un ottimo punto di osservazione su tutti i movimenti nella nostra rete
Per implementare Snort in una rete e realizzare un buon sistema di ''intrusion detection'' è opportuno disporre di 2 macchine, ciascuna dotata di due schede di rete e un ''hub''. La prima macchina funzionerà da sensore, l’altra verrà utilizzata per archiviare i log e per permettere il monitoraggio delle statistiche da remoto. ▼
▲== Requisiti Hardware ==
▲Per implementare Snort in una rete e realizzare un buon sistema di intrusion detection è opportuno disporre di 2 macchine, ciascuna dotata di due schede di rete e un hub. La prima macchina funzionerà da sensore, l’altra verrà utilizzata per archiviare i log e per permettere il monitoraggio delle statistiche da remoto.
Più grande sarà la rete da monitorare, migliori dovranno essere le caratteristiche tecniche delle macchine usate. Bisognerà infatti disporre di una quantità sufficiente di memoria RAM, di un adeguato spazio per archiviare i log e di una CPU sufficientemente rapida per processare tutti i pacchetti in tempo reale.
Per poter quantificare le risorse necessarie è opportuno valutare:
* la dimensione della rete in cui sarà posto il sensore NIDS;
Line 45 ⟶ 33:
=== Il Packet Decoder ===
Il ''packet decoder'' è il componente responsabile dell’analisi dei pacchetti. Esso ne determina il protocollo e la struttura, generando allarmi qualora vengano identificati pacchetti malformati. Si configura modificando il file di configurazione /etc/snort.conf come segue:
<nowiki>
Line 63 ⟶ 51:
config disable_tcpopt_alerts
# Stop Alerts on invalid ip options
config disable_ipopt_alerts </nowiki>
Terminata l’analisi, i pacchetti vengono inviati ai preprocessori.
Line 77 ⟶ 64:
La configurazione globale è identificata dalla stringa:
<nowiki>
preprocessor http_inspect: global [opzioni di configurazione]
I parametri che possono essere configurati sono:
* iis_unicode_map [filename (located in the config dir)] [codemap (integer)]
Line 85 ⟶ 71:
che genera un allarme se viene rilevato traffico HTTP su porte non standard; è opportuno non attivare questa opzione se è prevista una configurazione server di default.
La sezione dedicata ai server ha due modalità di configurazione: default e IP. La stringa che identifica la configurazione di default è:
<nowiki>
preprocessor http_inspect_server:
server default [server options]</nowiki>
mentre quella IP, che identifica la configurazione di indirizzi IP individuali, è:
Line 97 ⟶ 81:
<nowiki>
preprocessor http_inspect_server:
server [IP] [server options] </nowiki>
Le opzioni specificabili sono:
Line 105 ⟶ 88:
<nowiki>
preprocessor http_inspect_server: server 1.1.1.1 profile all ports { 80 3128 }
* ports { [port] [port] . . . }
che indica su quale porta è attivo il servizio HTTP. Il traffico cifrato SSL non potrà essere decodificato.
Line 140 ⟶ 123:
flow_depth 0 \
ascii yes \
oversize_dir_length 300
Dal precedente codice si deduce che il file contenente la mappa Unicode è unicode.map, l’indirizzo IP del server HTTP è 1.1.1.1 il quale è attivo sulle porte 80,3128 e 8080. Non sarà ispezionato il payload dei pacchetti di risposta del server, ma saranno decodificati gli URL contenenti caratteri ASCII che potranno avere una lunghezza massima di 300 caratteri.
Line 150 ⟶ 132:
<nowiki>
preprocessor flow: stats_interval 0 hash 2
I parametri che possono essere configurati per il preprocessore sfportscan sono:
Line 173 ⟶ 154:
scan_type { all } \
logfile { /var/log/snort/portscan } \
sense_level { high } </nowiki>
Dal precedente codice si deduce che saranno esaminati i pacchetti appartenenti a tutti i protocolli, saranno monitorati tutti i tipi di scansioni, il file contenente i log dei Portscan sarà /var/log/snort/portscan, e il sensore avrà una sensibilità alta.
Line 188 ⟶ 168:
suppress gen_id 1, sig_id 1852, track by_src, ip 10.1.1.54
# Suppress this event to this CIDR block
suppress gen_id 1, sig_id 1852, track by_dst, ip 10.1.1.0/24 </nowiki>
Per garantire l’effettiva disattivazione delle regole, è opportuno accertarsi che il file threshold.conf sia incluso nel file snort.conf mediante la stringa
<nowiki>
include threshold.conf </nowiki>
È anche possibile fare in modo che in un certo intervallo di tempo venga generato al massimo un allarme.
Line 202 ⟶ 180:
# Esempio
threshold gen_id 1, sig_id 1851, type limit, track by_src,
count 1, seconds 60 </nowiki>
=== I Componenti di Alerting e Logging ===
Line 245 ⟶ 222:
# output database: log, odbc, user=snort dbname=snort
# output database: log, oracle, dbname=snort user=snort
# password=test </nowiki>
In base alla riga di codice a cui viene tolto il commento si stabilisce il tipo di output. Nel caso in cui si intenda archiviare i dati in un server [[SysLog]], va specificato se tale server sia Unix o Windows. Per archiviare i dati in un file compatibile con Tcpdump, è sufficiente configurare il nome da dare a tale file. Nel caso si intenda archiviare i dati in un database, dovrà essere inserito il nome del database, l’username e la password.
Line 281 ⟶ 257:
<nowiki>
# Esempio
alert udp any 19 <> any 7 </nowiki>
Nel precente esempio viene generato un allarme, qualora venga riconosciuto un pacchetto UDP proveniente dalla porta 19 di un qualsiasi indirizzo IP sorgente, verso la porta 7 di un qualsiasi indirizzo IP di destinazione. I parametri aggiuntivi, come il testo del messaggio da scrivere nei log, saranno configurati nel body.
Line 292 ⟶ 267:
(msg:"DOS UDP echo+chargen bomb";
reference:cve,CAN-1999-0635; reference:cve,CVE-1999-0103;
classtype:attempted-dos; sid:271; rev:3;) </nowiki>
Nel precedente esempio, il messaggio scritto nei log sarà ‘DOS UDP echo + chargen bomb ’, la tipologia d’attacco è ‘attempted-dos ’ che indica il tentativo di effettuare un attacco DoS, l’identificatore della regola che ha generato l’allarme è 271 e tale regola è stata revisionata 3 volte. Vengono inoltre dati alcuni riferimenti da cui reperire informazioni aggiuntive sull’attacco: cve,CAN-1999-0635 e cve,CVE-1999-0103.
Line 307 ⟶ 281:
<nowiki>
alert ip any any -> any any
(msg:"Same Source and Destination IP Address"; sameip;) </nowiki>
Il Time To Live ‘TTL’ viene utilizzato per identificare le query via tool come Traceroute, Tracert o Netroute e supporta i simboli ‘>’,‘<’ e ‘=’, mentre l’opzione ‘seq’, permette di selezionare i pacchetti con numero di sequenza statico.
Line 331 ⟶ 304:
<nowiki>
reference:<fonte> <valore>; </nowiki>
Continuando l’analisi delle opzioni configurabili all’interno del body di una regola di intrusion detection, troviamo l’opzione ‘msg’ che permette di associare alla regola un messaggio che informerà sul tipo di attacco potenzialmente riscontrato. Questa opzione si utilizza nel seguente modo:
<nowiki>
alert tcp $EXTERNAL any -> $INTERNAL 79 (msg:"Finger";) </nowiki>
L’opzione ‘logto’ permette di archiviare i pacchetti relativi alla regola. La sintassi di questa opzione è
<nowiki>
logto: "PATH/FILE.estensione"; </nowiki>
Snort fornisce, inoltre, la possibilità di definire delle variabili da usare nelle regole. Ogni variabile deve avere una struttura di questo tipo:
<nowiki>
Var <nome variabile> <valore variabile> </nowiki>
Ogni variabile definita all’interno di regole o nei file di configurazione, può essere richiamata anteponendo al suo nome il simbolo ‘$’.
Line 393 ⟶ 362:
205.188.179.0/24,205.188.248.0/24]
# Percorso dei file contenenti le regole
var RULE_PATH /boot/etc/rules </nowiki>
Le regole sono, infine, raggruppate per categorie in alcuni file che saranno inclusi nel file di configurazione snort.conf.
Line 445 ⟶ 413:
include $RULE_PATH/multimedia.rules
include $RULE_PATH/p2p.rules
include $RULE_PATH/experimental.rules </nowiki>
Ad una tipologia di server, è usualmente associata una tipologia di regole: ad esempio il server DNS è associato al file dns.rules o il server POP3 al file pop3.rules.
Line 459 ⟶ 426:
# include $RULE_PATH/web-misc.rules
# include $RULE_PATH/web-client.rules
# include $RULE_PATH/web-php.rules </nowiki>
Terminata questa panoramica sulla configurazione delle regole di Snort, si esamineranno nel prossimo l’analisi dei log generati dalle regole.
Line 473 ⟶ 439:
ICMP TTL:45 TOS:0x0 ID:17750 IpLen:20 DgmLen:28
Type:8 Code:0 ID:31266 Seq:8282 ECHO
[Xref => http://www.whitehats.com/info/IDS162] </nowiki>
Analizzando i campi del log registrato si evince che:
Line 485 ⟶ 450:
* Le restanti informazioni riguardano le specifiche tecniche del protocollo utilizzato.
Terminata l’analisi di Snort, nel prossimo capitolo si esaminerà la sua implementazione pratica all’interno di una rete.
== Collegamenti esterni ==
Line 494 ⟶ 457:
*{{it}} {{en}} [http://www.snortattack.org/ Snortattack Snort guide, tips and tricks]
[[Categoria:Applicazioni]]
{{alfabetico|S}}
{{Avanzamento|75%|20 gennaio 2009}}
| |||