Sto studiando i dispositivi IPS e le loro firme sia statiche che stateless. La rete di test che sto cercando di implementare l'IPS ha un traffico asimmetrico, quindi un'ispezione statica sarebbe quasi impossibile. Quale percentuale di minacce può essere mitigata solo dall'ispezione di stato?
Se dovessi disattivare l'ispezione stateful su IPS a quali minacce sto lasciando la rete di test aperta?
Il rilevamento delle intrusioni di rete con stato, e ancor più la prevenzione, è un compito difficile di fronte a più collegamenti upstream. Quando il traffico può fluire in un collegamento e uscire da un altro, un singolo monitor non può ricostruire efficacemente lo stato dell'host di fine. Puoi accettare questa situazione con tutte le sue implicazioni (ad es., Una protezione mediocre nella migliore delle ipotesi) o ricorrere a una soluzione distribuita che propaga lo stato tra i nodi.
Idealmente dovresti spingere i monitor verso il bordo della rete [1], ma sembra che tu non abbia alcun controllo sul bordo. Senza una comprensione dettagliata della topologia della rete, questa è una domanda difficile a cui rispondere. Per il resto di questa risposta, presumo che tu abbia almeno la possibilità di distribuire diversi monitor nella tua rete per approssimare l'ideale di ispezionare tutto il traffico upstream.
Il monitoraggio della sicurezza della rete Bro ha un modalità di esclusione , in cui un nodo può propagare lo stato ad altri nodi. Ad esempio, quando il nodo A vede una connessione di controllo FTP, può propagare questa informazione al nodo B , in modo che sappia come interpretare la seguente connessione dati ad alta porta. Un altro scenario in cui questo è utile è il rilevamento della scansione distribuita. Se nella rete è presente una macchina infetta che esegue scansioni in uscita tramite più collegamenti, ciascun nodo può conservare un contatore locale e scambiarlo regolarmente con altri nodi. Per un'analisi più dettagliata dello scambio di stato, dai un'occhiata al documento del cluster NIDS .
Questo approccio cluster si adatta bene alle seguenti informazioni:
La granularità dell'analisi e del clustering è un'intera connessione. Finché è possibile garantire che i pacchetti appartenenti alla stessa connessione finiscano nello stesso nodo del cluster, si ottiene una buona scalabilità. Negli ambienti single-upstream, un frontend taglia in genere il traffico di input per raggiungere questo vincolo. Nelle reti di medie dimensioni, un router Click che riscrive l'indirizzo MAC è spesso sufficiente, ma gli ambienti più grandi spesso devono utilizzare dispositivi dedicati ad alte prestazioni. Il nostro gruppo di ricerca ha ottime esperienze con i sottotitoli cPacket CVU , che possono bilanciare il carico di link multi-10-Gbps a velocità di linea senza perdere pacchetti.
La dimensione dello stato scambiato è in genere di ordini di grandezza inferiore al traffico osservato da un nodo. Ad esempio, se un nodo osserva un grande download di immagini ISO, non propagherà l'immagine ISO ad altri nodi, ma ad esempio solo il nome dell'immagine ISO. Inoltre, l'analisi intra -connessione è già stateful, ad esempio, Bro segue la macchina a stati TCP e espone la pipeline di messaggi HTTP all'utente.
Applicare questo al tuo scenario è un po 'più complicato, perché non hai un singolo link upstream. Per scalare bene, è necessario assicurarsi che il traffico proveniente dalla stessa connessione venga ispezionato dallo stesso nodo. In altre parole, la nozione di un frontend è un po 'sfocata perché devi instradare manualmente i pacchetti sul nodo del cluster corrispondente. L'esatto sovraccarico di questo approccio dipende dalla tua topologia concreta.
[1] Questo non preclude la