Quanto traffico può gestire un nodo firewall? Qualche esempio reale? [chiuso]

Avendo fatto test per più clienti in cui affermano che "le scansioni non lo porteranno a termine, starai bene", quindi un'ora dopo avremo una riunione per discutere su come gestire un grave incidente di downtime , Posso tranquillamente dire alcune cose:

1. I dati di marketing che descrivono le prestazioni sono nel migliore dei casi un picco di prestazioni, prodotto in una situazione di laboratorio in cui il test case è stato completamente ottimizzato per le massime prestazioni, senza riguardo per l'effettiva usabilità o funzionalità. Nel peggiore dei casi sono una fabbricazione completa o una falsa rappresentazione dei dati. Devi ignorare tali statistiche sul rendimento.
2. I test di inondazione standard (ad esempio inondazione ICMP, alluvione SYN) sono al massimo strumenti rudimentali. La resistenza alle inondazioni ICMP è raramente una misura utile di qualsiasi cosa, dal momento che le persone hanno imparato le loro lezioni negli anni '90. SYN flooding ti dirà se il sistema è in grado di de-priorizzare le connessioni semiaperte in attesa dietro i client che hanno effettivamente inviato un ACK finale per completare la connessione, insieme all'implementazione di un sistema anti-flooding di base come i cookie TCP SYN. Queste sono cose rudimentali che puoi aspettarti da qualsiasi prodotto di rete.
3. I test di ampiezza della larghezza di banda possono essere utili per risolvere i problemi di saturazione della rete, ma ti dicono solo quale sia il limite di larghezza di banda continuo del tubo di rete. Allagando un collegamento di rete con pacchetti di grandi dimensioni (di solito i datagrammi UDP) è possibile saturare la pipe e rendere difficile la diffusione di nuovi pacchetti legittimi. Detto questo, di solito ti dice di più sulla rete stessa che sul dispositivo in prova (il firewall o IDS).
4. I sistemi IPS / IDS / Firewall hanno una velocità di trasmissione ridicolmente veloce per il traffico, ma i veri e propri colli di bottiglia si verificano sul lato della gestione. Ad esempio, se si registra ogni volta che un pacchetto viene visto da un indirizzo IP che non ha una voce ARP (ho visto questo fatto) quindi l'invio di molti pacchetti da un IP falsificato (o solo senza ARP'ing prima) sarà molto riempire rapidamente il buffer del registro in memoria e saturare l'IO del disco sull'unità che memorizza i registri, di solito facendo cadere l'intero sistema. Il dispositivo potrebbe essere in grado di trasmettere il traffico legittimo in avanti a una velocità ridicolmente alta, ma un caso a bordo singolo come questo può appiattirlo in pochi minuti.
5. Puoi eseguire tutte le suite di test DoS / DDoS che ti piacciono, verificare i risultati in produzione, aprirli al traffico del mondo reale e vedere grandi risultati, quindi scoprire che cade a faccia in giù non appena un pentester (o alcuni skript kiddie) esegue Nessus o sqlmap attraverso di esso, poiché vengono lanciati così tanti avvisi che il sistema di allerta non può tenere sotto controllo.
6. Se esegui il test di un dispositivo in un ambiente di prova, quindi spostalo in produzione, non sorprenderti quando il dispositivo non funziona più come previsto. I test devono essere eseguiti nell'impostazione del mondo reale con la stessa configurazione e la stessa topologia. Qualcosa di sottilmente diverso può cancellare completamente i risultati.

Se si desidera testare correttamente le funzionalità realistiche di uno di questi dispositivi, è necessario installarlo nell'ambiente di produzione ed eseguire una batteria completa di test attraverso di esso, nella configurazione di produzione finale. I risultati saranno diversi per ogni modello o versione del firewall / IDS / IPS, diverse opzioni di configurazione e diverse topologie di rete e sistemi di back-end raggiunti attraverso il dispositivo. Qualunque risposta tu guadagni, per esempio, un firewall pfSense, sarà completamente diversa rispetto, ad esempio, a un firewall Checkpoint.

Dato che stai parlando di ricerca, la prima cosa che dovresti fare è definire cosa intendi per firewall e IDS. Sono cose diverse; a un livello insignificante, un firewall (di stato) riguarda il livello di rete, mentre un IDS deve fare almeno l'analisi dei pacchetti e l'analisi a livello di applicazione per essere utile.

Sebbene esistano altri tipi di firewall e IDS, ciò che limita il loro throughput è in definitiva l'elemento più lento nella catena di elaborazione. Ecco un esempio di trival:

1. Il pacchetto colpisce la scheda di rete
2. A livello di kernel, lo stack di rete funziona sul frame (ad esempio deframmenta)
3. Il firewall (ad esempio, iptables) corrisponde al pacchetto ricostruito rispetto al suo set di regole
4. Il sistema di registrazione scrive un evento su /dev/log e poi si dimentica di esso
5. L'IDS esamina il pacchetto e attende l'arrivo di altri pacchetti per completare l'ispezione

In questo caso i componenti coinvolti sono:

• scheda di rete (bus PCI)
• CPU e RAM

L'elemento più lento della catena è il bus PCI, quindi questo è il fattore limitante nel caso di singoli pacchetti. Ciò significa che, a meno di non mettere una scheda da 10 GB su una CPU 486 con un clock di 100 MHz, la scheda di rete sarà sempre il collo di bottiglia. È un calcolo back-of-the-envelope ma ti dà un limite inferiore.

Una volta che hai una linea di base puoi iniziare a complicarla: ad esempio, cosa succede se il sistema è sovraccarico? Qual è il numero minimo di thread che la CPU deve essere in grado di allocare per mantenere un throughput massimo? In altre parole: isola le tue variabili e, mantenendo tutto il resto uguale, analizza i loro confini. Potresti considerare un approccio di analisi dei confini.

Devi anche chiarire la tua domanda di ricerca: parli di

the maximum packets (Internet traffic) can one instance of firewall/ IDS process

Che cosa intendi per "processo"? Il tuo IDS è attivo o passivo (ad esempio, blocca il flusso di pacchetti finché non è felice o esegue solo analisi passive)? Se sta bloccando, si ha un modello di coda produttore / consumatore in cui il limite superiore dipende dal fatto che l'IDS possa scalare su più core. Altre cose che potresti voler considerare sono l'impronta della memoria, la suscettibilità agli attacchi denial-of-service e così via. Pensa a cosa succede se un utente malintenzionato invia un pacchetto frammentato. Il firewall aspetterà per sempre di assemblarlo? Cosa succede se l'autore dell'attacco invia solo il primo blocco di una richiesta HTTP Chunked?

Per riassumere, inizia definendo esattamente cosa stai cercando di valutare; per ogni elemento, determinare i suoi limiti inferiori e (eventualmente) superiori; combina i risultati.