Architettura per l'ispezione dei pacchetti distribuiti

Question

Architettura per l'ispezione dei pacchetti distribuiti

#1 da (1 voti)

0

Attualmente sto lavorando a un nuovo progetto open-source per un'ispezione dei pacchetti. Non ho quasi nessuna esperienza con la progettazione di un'architettura. Vorrei quindi chiedere la tua opinione sulla mia attuale architettura e su quali problemi potrei affrontare durante il ridimensionamento.

Ho un set di file di acquisizione di pacchetti di grandi dimensioni con traffico di rete. Questi file di acquisizione sono tutti catturati sulla stessa macchina e si susseguono nel tempo. Il mio compito principale è ricostruire tutti i flussi di rete che stavano accadendo in questi file. I flussi possono estendersi su più file.

Ecco quello che ho finora: Non voglio trasferire file su una rete perché sono relativamente grandi, quindi ho scritto un piccolo servizio web che riceve query con i seguenti parametri: numero di file, offset e quantità di byte. Questo servizio di invio risponde con byte da questa posizione.

Un'altra parte è un separatore. Inizia da un semplice offset di pacchetto e fa iterativamente i seguenti passaggi:

Ottieni byte per la prossima intestazione del protocollo in questo pacchetto
Analizza l'intestazione
Invia informazioni per aggiornare le informazioni sul flusso di rete a un terzo componente
Analizza qual è il protocollo successivo nello stack del protocollo nel pacchetto

Infine, la terza parte: re-constructor del flusso: È un insieme di oggetti che contiene alcune meta informazioni su un flusso (ad esempio indirizzi IP, porte TCP) e un elenco di file con offset e dimensioni per descrivere il carico utile del flusso.

Le mie domande:

Penso che implementare "send service" e "re-constructor" da solo non sia una buona idea. Quale può essere una soluzione più ottimale in termini di prestazioni.
Attualmente sto usando rabbitMQ per comunicare tra i componenti. Esiste una soluzione più produttiva?
Stavo pensando di creare più istanze di separatori (magari su macchine separate) quindi ho bisogno di alcuni meccanismi per orchestrare la consegna dei byte.
"Separatore" sprecano molto tempo solo in attesa di una consegna di byte. Come posso migliorarlo?

Inoltre, apprezzo molto qualsiasi suggerimento o commento sull'architettura attuale. Per favore aiutate l'architetto principiante e il collaboratore open-source:)

architecture networking

posta Rhaegar 06.09.2016 - 15:12

fonte

1 risposta

Leggi altre domande sui tag architecture networking

Come lavorare con i kit di avvio e i loro aggiornamenti? Loop Invariant in funzione ricorsiva

score 1 · Answer 1

Quello che stai proponendo per il tuo "servizio di invio" sembra molto quello che fa un file system in rete.
Ciò rivela anche un grosso difetto nell'architettura: separando "servizio di invio" e "separatore", è necessario trasferire quasi l'intero file di acquisizione sulla rete. Questo perché il separatore non sarà in grado di saltare grandi parti del traffico catturato.

Per evitare di dover trasferire grandi quantità di dati sulla rete, è necessario eseguire almeno un controllo iniziale dei pacchetti e un filtro sulla macchina in cui risiedono i file di acquisizione. Questo filtro iniziale può già eliminare tutti i pacchetti che non sono interessanti, perché ad esempio il computer del tuo amico non è coinvolto nel pacchetto.

Inoltre, dato che i file di acquisizione formano una sequenza temporale, utilizzerei questa proprietà e presenterò i dati in essa contenuti alla logica che ricostruisce frame e pacchetti come se esistesse un solo file di acquisizione veramente grande. L'elaborazione è molto più semplice se solo il lettore di file sa che ci sono più file e ogni cosa dopo di essa vede solo un lungo flusso di fotogrammi / byte catturati.

Con questo in mente, vorrei ottenere i seguenti servizi

Un servizio di pacchetti che può fornire uno stream / sequenza di pacchetti che soddisfano determinati criteri. Ad esempio, l'indirizzo A (e possibilmente la porta P) è coinvolto nella conversazione; la conversazione usa il protocollo X; ecc.

Questo servizio contiene componenti
- legge i file di acquisizione e li presenta come un lungo flusso di dati di acquisizione
- estrai i pacchetti dai dati di acquisizione
- filtro i pacchetti in base ai criteri del filtro
Un servizio di ricostruzione della conversazione in grado di ricostruire una conversazione (HTTP) con più pacchetti
Un analizzatore di conversazioni che esamina le conversazioni ricostruite e cerca conversazioni sospette (in base a ciò che classifichi come sospetto).

Come nota finale, se i file di acquisizione sono in un formato ragionevolmente noto, allora è molto probabile che possano essere elaborati individualmente da strumenti come Wireshark . Se la lettura dei file di acquisizione sulla rete non è un grosso problema, potrebbe anche essere la possibilità di applicare patch a uno strumento che può leggere da più file consecutivi.