Ad esempio, in che modo il team VRT di Snort o qualcuno che ci dà le firme, li ha determinati?
Sarei più interessato a sapere, come vengono analizzati i modelli di traffico rispetto ad alcuni modelli teorici noti (eventuali modelli statistici / probablistici?) per determinare le firme?
Sashank, questa è una buona domanda.
Scrivere regole è un lavoro di ricerca divertente. Spesso ci vuole molta ricerca e analisi, e qualche volta per alcune minacce è molto facile scrivere una firma.
Questa è una rapida panoramica ad alto livello delle firme di scrittura. Le cose che dovresti sapere prima di eseguire l'analisi e iniziare a scrivere regole -
Molto buona comprensione dei protocolli in base alle loro RFC - Questo include tutti i protocolli (IP, ICMP, DHCP, TCP, UDP, SMTP, FTP, POP3, ssh, telnet ecc) nei livelli OSI (datalink, rete, trasporto, sessione ecc.). La RFC è la linea guida su come viene progettato un protocollo, come dovrebbe comportarsi. Questo è un riferimento molto importante nelle regole di scrittura. RFC definisce la struttura dei protocolli, le loro intestazioni, stato, flag / attributi. Sulla rete, qualsiasi deviazione osservata da questi standard RFC è la chiave per scrivere le regole.
Comprensione dettagliata della vulnerabilità - What do you want to write a signature for? Do you understand how the vulnerability works? Do you know what are you looking for in the network traffic? Where shall you concentrate on in the application/service? Tentare di rispondere a queste domande ti darà un percorso per comprendere la vulnerabilità. Esempio: se si sta scrivendo una regola per l'overflow del buffer remoto sulla porta 80 / http su IIS, è necessario comprendere l'architettura del server Web, il modo in cui i dati vengono gestiti internamente nel server Web, in che modo il server Web gestisce le richieste e genera le risposte . Questo chiarirà la vulnerabilità. Se capisci questo, allora ti condurrà a cosa esattamente dovresti cercare. Questo è applicabile per qualsiasi servizio / processo / software remoto o locale a cui si desidera applicare una regola di vulnerabilità.
Lotto di lavoro di laboratorio - Esegui gli exploit più e più volte in diversi scenari, ottieni molte acquisizioni di pacchetti o dump di memoria. Analizza la timeline, analizza le intestazioni dei pacchetti e confrontala con gli standard RFC, analizza i payloads . Se esegui un exploit 10 volte, le acquisizioni di pacchetti ti forniranno la timeline, la dimensione del carico utile / dati, la sequenza di bit (dati) nel payload e, soprattutto, chiariranno le condizioni in base alle quali lo sfruttamento ha più probabilità di avere successo. Mettere tutto insieme porterà una buona precisione per la firma, quindi saprai esattamente il bit patter da cercare e quando cercare e dove cercare.
Sostituire "firma" con "regola".
A volte è un compito semplice, altre volte no.
Le regole vengono generalmente create (afaik) esaminando le acquisizioni di pacchetti di attacchi / exploit e quindi creando regole che corrispondono a tale modello di traffico. L'abilità consiste nel creare una regola il più precisa possibile al fine di limitare i falsi positivi ma abbastanza generica da garantire di catturare tutto. Le regole integrate sono create nello stesso modo in cui molte persone creano le proprie regole, analizzando le acquisizioni di pacchetti, esaminando i bit e i byte per creare uno schema appropriato. Il bit facile ovviamente sta facendo corrispondere le porte e il protocollo (vale a dire la RULE HEADER).
il flusso di traffico (cioè da / verso server) ma poi diventa più complesso con gli operatori (contenuto, offset, profondità, interno, distanza ecc.) o invoca Pcre. L'altro elemento delicato è quello di garantire che una regola non solo rilevi il traffico ma non influenzi negativamente le prestazioni.
Snort ora è una bestia complicata (in senso buono) e c'è molto di più rispetto alle semplici regole alla ricerca di schemi di traffico. Il vero lavoro avviene con i pre-processori e il più recente modulo DAQ .
Ecco un vecchio post che parla di come le firme IDS / le regole sono state create.
Una brava persona con cui chattare sarebbe Joel Esler (@joelesler), un veterano di Sourcefire e membro del team di VRT. Non sono sicuro di quello che può dirti se è un esempio da lui . I membri del team VRT sono vere scimmie a pacchetto, grandi sviluppatori e eseguono test approfonditi sulle loro regole prima del rilascio. Molto spesso questo test viene eseguito con il venditore o la società che ha scoperto o è stato colpito dall'attacco.
C'è letteralmente un sacco di documenti in rete su come vengono scritte le regole snort, molte delle quali sono scritte da Dipendenti di Sourcefire e il manuale .