39360.zip
Il scalabile ed efficiente Snort Network Intrusion Detection System (NIDS) open-source usa una serie di regole ben definite per rilevare pacchetti anomali sulla vostra rete. Mantenere queste serie di regole migliora notevolmente l’efficacia del sistema. Alcune tecniche di gestione delle regole possono aiutarvi a mantenere il vostro IDS Snort. In primo luogo, è possibile prevenire un sovraccarico di avvisi stringendo le definizioni delle variabili e curando le regole di Snort. È anche possibile persistere le regole personalizzate attraverso gli aggiornamenti dei set di regole. Infine, è possibile decostruire una regola per capire come personalizzare le regole per il proprio ambiente.
Per impostazione predefinita, Snort contiene più di 1900 regole in una serie di quasi 50 file di testo organizzati per tipo, come mostra la Figura 1. Queste regole definiscono i trigger di risposta a molti exploit di vulnerabilità noti relativi a Windows, UNIX e applicazioni ampiamente utilizzate come Microsoft IIS, Apache, Microsoft SQL Server e Oracle SQL. Le regole aiutano anche Snort a fornire dati di ricognizione e possibili avvisi di configurazione per avvertire di scansioni di rete o di una macchina che sta trasmettendo una stringa di comunità predefinita SNMP, per esempio. Come si può immaginare, Snort può generare un numero enorme di avvisi. Per ridurre il rumore delle regole di stock, la configurazione predefinita di Snort abilita solo circa 1300 delle regole per default e disabilita interi tipi di regole, come policy, chat e virus, per default. (Un tipo di regola è tipicamente contenuto in un proprio file di testo, quindi le regole di tipo virus sono contenute nel file virus.rules). Esaminate tutti i gruppi di regole disabilitate e abilitate quelle che potrebbero essere applicabili al vostro ambiente.
Prune Your Rules
Anche con le molte regole che Snort disabilita di default, il vostro sistema IDS Snort probabilmente genererà molti avvisi. Faticare per tutti questi avvisi potrebbe rendere i vostri sensi insensibili al traffico veramente sospetto. Dopo aver installato Snort nel vostro ambiente, potate le regole per rimuovere quelle che non riguardano il vostro ambiente o che non vi riguardano. Per esempio, se non avete il linguaggio di scripting HTML incorporato PHP: Hypertext Preprocessor (PHP) installato nel tuo ambiente, puoi disabilitare il file di regole web-php.rules. Quando si decide quali regole disabilitare, tuttavia, considerare gli utenti che potrebbero avere vari software sulle loro macchine. Per esempio, uno dei vostri sensori Snort potrebbe raccogliere pacchetti sospetti da una macchina domestica compromessa su una connessione VPN. Quindi, continuando l’esempio precedente, anche se non avete installato PHP su nessuno dei vostri computer aziendali, uno dei vostri utenti finali potrebbe averlo installato a casa. Se il computer di casa fosse compromesso da una vulnerabilità di PHP, l’aggressore potrebbe essere in grado di accedere alla rete aziendale mentre il computer compromesso è collegato in remoto alla rete aziendale (ad esempio tramite una VPN).
La maggior parte dei sistemi di avviso e di reporting visualizza il nome e il SID per ogni regola per un facile riferimento. Per ridurre ulteriormente l’elenco delle regole abilitate, monitorate i vostri sistemi, annotate i nomi delle regole estranee o i SID, quindi disabilitate tali regole. Per disabilitare manualmente una regola di Snort, aprire il file delle regole e inserire un segno cancelletto (#) davanti alla regola. Per disabilitare un’intera classe di regole, aggiungere un segno cancelletto davanti al nome del file della regola nel file di configurazione di Snort. È necessario riavviare Snort per caricare le regole modificate.
Rivedere regolarmente le vostre regole e continuare a eliminare quelle che non si applicano alla vostra rete diminuirà drasticamente il numero di avvisi che Snort genera, rendendo così più facile individuare e identificare i pacchetti veramente sospetti. E ricordati di riabilitare le regole quando introduci una nuova tecnologia che le regole attualmente disabilitate potrebbero proteggere.
Mantieni le regole aggiornate
Snort.org ospita due versioni delle regole di Snort: snortrules-stable e snortrules-current, che funzionano rispettivamente con Snort 2.0x e Snort 1.9x. Le regole più recenti contengono firme aggiuntive e aggiornamenti alle regole esistenti per fare uso di variabili estese. Ad esempio, le regole della versione 2.0.0 definiscono variabili che descrivono specificamente alcune funzioni della macchina (ad esempio, le variabili HTTP_SERVERS e HTTP_PORTS caratterizzano i computer che eseguono servizi Web e potrebbero essere soggetti ad attacchi di servizi Web). Queste nuove variabili lavorano nelle nuove regole per schermare ulteriormente gli attacchi in arrivo. Una vecchia regola potrebbe avvisarvi di una richiesta HTTP sospetta destinata a qualsiasi computer della vostra rete, ma la nuova regola cerca lo stesso attacco solo quando è destinato a un server Web che la variabile HTTP_SERVERS definisce. Questo processo di classificazione aiuta a ridurre i falsi allarmi.
Snort.org aggiorna frequentemente i set di regole per rimanere al passo con le nuove scoperte di exploit. Per rimanere aggiornati, controllate regolarmente, scaricate e applicate nuove regole che potrebbero essere utili nel vostro ambiente. Tuttavia, notate che ogni volta che scaricate un set di nuove regole, i file di testo che contengono le nuove regole sovrascrivono quelli che contengono le vecchie regole. Scoprirete rapidamente che commentare tutte le vostre regole inutilizzate ogni volta che aggiornate i vostri file di regole è gravoso.
Oinkmaster al salvataggio
Fortunatamente, diversi strumenti open-source possono aiutarvi a superare questo problema. Un programma di script Perl chiamato Oinkmaster, che potete scaricare da http://www.algonet.se/~nitzer/oinkmaster, automatizza il download di nuove regole e gestisce le regole disabilitate o modificate. Adattato ai sistemi UNIX, lo script Perl usa gli strumenti wget, tar e gzip per recuperare ed espandere nuove regole ogni volta che lo script viene eseguito. La maggior parte di questi strumenti sono installati su sistemi UNIX, ma è possibile scaricare gli strumenti per Windows. Ricordate che le soluzioni open-source hanno un supporto dedicato limitato (se esiste), quindi cercate online le soluzioni a qualsiasi problema o domanda che potreste avere. La comunità del software open-source (OSS) abbonda di informazioni utili. Un buon punto di partenza è l’iscrizione a una delle mailing list di Snort, a cui potete iscrivervi all’indirizzo http://www.snort.org/lists.html.
Assicuratevi di consultare il file README per istruzioni dettagliate sull’installazione della vostra piattaforma. La procedura di base per l’installazione di Oinkmaster consiste nell’espandere i file oinkmaster.pl e oinkmaster.conf nella vostra directory di Snort (o in una directory da voi specificata), quindi utilizzare oinkmaster.conf per configurare Oinkmaster.
Aprire oinkmaster.conf e seguire i commenti in linea per configurare lo strumento. Per prima cosa, confermate la posizione delle regole aggiornate come indirizzo web (ad esempio, http://www.snort.org/dl/signatures/snortrules.tar.gz). Assicurati di puntare Oinkmaster a un sito affidabile e rispettabile, specialmente se scegli di scaricare e installare le regole automaticamente. Altrimenti, corri il rischio di scaricare regole corrotte (o peggio, manomesse) che potrebbero compromettere il tuo IDS.
Prossimo, specifica i file da saltare, modificare e disabilitare. Per impostazione predefinita, Oinkmaster non elabora (cioè, salta) local.rules e snort.conf.
La funzione modifysid dello script ti permette di modificare le regole appena scaricate; pensa a modifysid come a una funzione Cerca e sostituisci per una regola specifica che identifichi tramite SID. Con questo comando, puoi modificare il testo di una regola specifica. Per esempio, puoi usare modifysid per abilitare una regola che è disabilitata di default. Per fare questo, aggiungi un nuovo comando modifysid identificando la regola che vuoi abilitare e istruiscilo a rimuovere il carattere di commento (#). Ogni volta che viene scaricato un nuovo set di regole, questo carattere di commento verrà rimosso quando Oinkmaster analizzerà quella regola. Puoi anche usare modifysid per elevare il tipo di azione di una regola. Per esempio, il comando
modifysid 2003 "alert" | "sev1"
eleva l’avviso con un SID di 2003 a un tipo di azione personalizzata di sev1. Oinkmaster lo fa cercando “alert” e sostituendolo con “sev1”. E sì, farà sostituzioni multiple, quindi usalo con attenzione.
L’ultima e più popolare caratteristica di Oinkmaster, disablesid, ti permette di disabilitare regole selezionate. Specifica i SID di tutte le regole che vuoi mantenere disabilitate. Per esempio, per disabilitare gli avvisi sulle scansioni di rete, potresti iniziare con una voce simile a
disablesid 469, 615, 618, 620
Dopo aver scaricato e analizzato un nuovo set di regole, Oinkmaster cerca i SID specificati e commenta le regole. Finché Oinkmaster gestisce le tue regole, le regole rimarranno disabilitate, anche attraverso gli aggiornamenti del set di regole.
Esegui manualmente lo script ogni volta che vuoi aggiornare le tue regole. Se ti senti audace, programma lo script per eseguire e aggiornare le regole su base ricorrente. Oinkmaster recupererà le regole, le espanderà e le copierà nella directory delle regole del tuo sensore. Come con la maggior parte degli OSS, usate Oinkmaster con discrezione e imparate prima cosa fa e come influenzerà il vostro ambiente. Per esempio, testate un nuovo set di regole eseguendo Snort in modalità auto-test (usando snort -T più gli altri parametri) prima di distribuire le regole nel vostro ambiente di produzione.
Oinkmaster vi permette di evitare i rischi di scaricare aggiornamenti dubbi, dandovi la possibilità di fare il backup delle vecchie regole e fornendo un log delle sue azioni alla console. Esamina questo output, che mostra le regole rimosse, le regole attive modificate, le revisioni delle non regole e i nuovi file, per confermare che Oinkmaster ha completato con successo i suoi compiti e per confermare le regole che Oinkmaster ha modificato. Se scegli di programmare l’esecuzione automatica di Oinkmaster, considera la possibilità di inviare i risultati via email per facilitare la revisione, come mostra la Figura 2. L’esempio seguente mostra come programmare l’esecuzione di Oinkmaster ogni giorno alle 6:15 usando il comando crontab di Linux (crontab ti permette di programmare i lavori in Linux):
15 6 * * * /home/snort/oinkmaster.pl -o /home/snort/rules -b /home/snort/backup 2>&1 | mail -s "Oinkmaster"
I parametri di Oinkmaster specificano la directory delle regole (-o), la directory delle regole di backup (-b), e un comando per inviare i risultati al proprietario. Il comando 2>&1 invia l’output StdErr a StdOut (la console) prima di inviarlo all’applicazione di posta elettronica.
Guardare una regola di Snort
Oltre a disabilitare o apportare modifiche di base alle regole standard, è possibile creare le proprie regole e personalizzare ulteriormente le regole di Snort direttamente al proprio ambiente. Ad esempio, si consideri l’implementazione di un sensore che monitorizza il traffico all’interno e all’esterno del firewall. Anche se sapere quanti attacchi di worm il vostro firewall respinge potrebbe interessarvi, sapere se qualcuno di questi attacchi ha avuto origine all’interno della vostra rete probabilmente vi interesserà ancora di più. Recentemente, le regole di Snort hanno incluso regole “sintonizzate” come l’esempio precedente, ma ne rimangono molte altre che potreste voler personalizzare in modo simile. Il listato 1 mostra una regola standard che vi avvisa quando rileva il worm SQL Slammer (aka Sapphire). Decostruiamo rapidamente questa regola. (Per informazioni dettagliate su tutti i parametri disponibili che definiscono le regole, fare riferimento alla documentazione completa sulle regole di Snort all’indirizzo http://www.snort.org/docs/writing_rules/chap2.html#tth_sec2.3.26.)
Tutte le regole devono risiedere su una linea e iniziare con una regola azione, che in questo caso è
alert
La regola azione definisce come Snort risponde alla regola se attivata. È possibile modificare il tipo di regola (ad esempio, in una stringa come ‘sev1’) per fornire una gestione personalizzata, ad esempio, per intensificare l’azione in caso di corrispondenza. Questo passo è diverso dall’esempio precedente, in cui abbiamo usato Oinkmaster per cambiare il tipo di avviso di una regola esistente; in questo esempio, stiamo creando una nuova regola usando una regola esistente come modello.
Il set di parametri
udp $EXTERNAL_NET any -> $HOME_NET 1434
fornisce il protocollo, l’indirizzo IP, le informazioni sulla porta e la direzione del traffico della regola. Questa regola dice a Snort di trovare qualsiasi pacchetto UDP da una fonte di rete (che la variabile $EXTERNAL_NET definisce) che tenta di andare alla variabile $HOME_NET sulla porta 1434. La maggior parte delle regole predefinite utilizza principalmente le variabili $EXTERNAL_NET e $HOME_NET. Tuttavia, alcune regole usano variabili più specifiche. Ad esempio, le regole che riguardano i server DNS (nel file dns.rules) utilizzano la variabile $DNS_SERVERS. Definire queste variabili nel file di configurazione di Snort (tipicamente snort.conf). Facoltativamente, create le vostre variabili per riflettere la vostra topologia (ad esempio, $MAIL_SERVERS) e per l’uso in regole personalizzate. Definisci una variabile usando il suo nome (ad esempio, var MAIL_SERVERS= 192.168.0.20/30), poi fai riferimento alla variabile con il prefisso del dollaro ($-e.g., $MAIL_SERVERS). L’azione della regola e questi parametri costituiscono l’intestazione della regola.
Le opzioni della regola raffinano ulteriormente la regola in modo che un pacchetto sospetto (e solo un pacchetto sospetto) faccia scattare una risposta. Come si può intuire, queste firme possono diventare piuttosto dettagliate ed estendersi ben oltre la semplice corrispondenza delle porte. Per esempio, immagina i falsi positivi che risulterebbero se questa regola Slammer ti avvisasse semplicemente di qualsiasi traffico della porta UDP 1434.
L’opzione msg
msg:"MS-SQL Worm propagation attempt"
fornisce una semplice descrizione dell’avviso da usare nelle attività di avviso e segnalazione. L’opzione content
content:"|04|"; depth:1; content:"|81 F1 03 01 04 9B 81 F1 01|";content:"sock"; content:"send";
contiene la stringa di corrispondenza del payload sensibile alle maiuscole e alle minuscole, in valori ASCII o esadecimali (racchiudi i valori esadecimali con il carattere pipe-|). È possibile specificare più opzioni di contenuto. L’opzione di profondità segue ogni opzione di contenuto e specifica quanti byte nel carico utile vuoi cercare il contenuto specificato. In questo esempio, un pacchetto attiverà una risposta se contiene il valore esadecimale 04 nel primo byte o il contenuto rimanente in qualsiasi punto del payload.
Le regole scaricate spesso contengono riferimenti a informazioni dettagliate sull’exploit sospetto o sul motivo alla base della creazione della regola. Alcuni sistemi di segnalazione supportano l’opzione di riferimento fornendo collegamenti diretti a queste informazioni:
reference:bugtraq,5310; reference:bugtraq,5311;reference:url,vil.nai.com/vil/content/v_99992.htm;
Snort assegna le regole alle classi e assegna a queste classi una priorità alta, media o bassa. Attualmente, esistono più di 30 classificazioni, tra cui attempted-admin, trojan-activity, attempted denial of service e network-scan. Nel nostro esempio, la classificazione è
classtype:misc-attack
Snort registra la priorità di risposta per le intrusioni rilevate. È possibile utilizzare uno strumento esterno o uno script per analizzare ulteriormente questa priorità e agire con la propria applicazione di reporting.
Nel segmento finale
sid:2003; rev:2;
sid rappresenta una regola unica di Snort e rev indica il numero di revisione. Queste proprietà identificano in modo univoco la regola.
Tailoring the Rule
Esaminiamo come modificare questa regola per fornire un allarme escalation quando rileva host interni infetti. Poiché abbiamo a che fare con lo stesso exploit della regola originale, la definizione del contenuto della regola rimane la stessa. Dobbiamo modificare solo gli indirizzi IP e la direzione del traffico. Cambiamo l’indirizzo IP sorgente a $HOME_NET, come segue:
udp $HOME_NET any -> $EXTERNAL_NET 1434
Snort.conf definisce $EXTERNAL_NET come “any”, quindi questa regola catturerà ancora i pacchetti corrotti che mirano agli host interni (come la regola originale). Tuttavia, ora che abbiamo una regola dedicata che tiene traccia solo degli indirizzi IP interni, possiamo cambiare il tipo di azione in un tipo di azione personalizzata che innesca un allarme escalation.
Le attuali regole di Snort includono questa regola di rilevamento del worm Slammer in uscita nel set di regole di default. Tuttavia, quando un nuovo worm, un virus o un altro exploit inizia a diffondersi, considerate la possibilità di creare nuove regole che evidenzino specifiche intrusioni.
Creare le vostre regole
Oltre alle regole esistenti o personalizzate che potete modificare o creare, potreste voler includere regole che ottenete da altre fonti. Per esempio, quando la notizia di un nuovo worm si diffonde su Internet, i siti di sicurezza e i newsgroup sono pronti a pubblicare regole di Snort una tantum che possono rilevare il nuovo worm. Incollare queste nuove regole nel file local.rules, quindi riavviare Snort affinché le nuove regole abbiano effetto.
Snort fornisce la struttura per un IDS economico e personalizzabile. Sostenuto da una serie di regole supportate dalla comunità, Snort rimane un sistema flessibile ed efficace. Mantenere le regole aggiornate aumenterà la vostra vigilanza e ridurrà il rumore che risulta da avvisi inefficaci. Come con qualsiasi progetto open-source, prendersi il tempo per capire come funziona e familiarizzare con i suoi componenti aggiuntivi sviluppati dalla comunità migliorerà notevolmente il vostro comfort con il sistema e aumenterà la sua efficacia nel vostro ambiente.