Problema relativo alle prestazioni di iptables / conntrack Linux


9

Ho una configurazione di prova in laboratorio con 4 macchine:

  • 2 vecchie macchine P4 (t1, t2)
  • 1 Xeon 5420 DP 2,5 GHz 8 GB RAM (t3) Intel e1000
  • 1 Xeon 5420 DP 2,5 GHz 8 GB RAM (t4) Intel e1000

per testare le prestazioni del firewall di Linux da quando siamo stati morsi da una serie di attacchi syn-flood negli ultimi mesi. Tutte le macchine eseguono Ubuntu 12.04 a 64 bit. t1, t2, t3 sono interconnessi tramite un interruttore da 1 GB / s, t4 è collegato a t3 tramite un'interfaccia aggiuntiva. Quindi t3 simula il firewall, t4 è il bersaglio, t1, t2 gioca gli attaccanti generando un thetugh di pacchetti (192.168.4.199 è t4):

hping3 -I eth1 --rand-source --syn --flood 192.168.4.199 -p 80

t4 elimina tutti i pacchetti in arrivo per evitare confusione con gateway, problemi di prestazioni di t4 ecc. Guardo le statistiche dei pacchetti in iptraf. Ho configurato il firewall (t3) come segue:

  • stock 3.2.0-31-generico # 50-Ubuntu SMP kernel
  • rhash_entries = 33554432 come parametro del kernel
  • sysctl come segue:

    net.ipv4.ip_forward = 1
    net.ipv4.route.gc_elasticity = 2
    net.ipv4.route.gc_timeout = 1
    net.ipv4.route.gc_interval = 5
    net.ipv4.route.gc_min_interval_ms = 500
    net.ipv4.route.gc_thresh = 2000000
    net.ipv4.route.max_size = 20000000
    

(Ho ottimizzato molto per mantenere in esecuzione t3 quando t1 + t2 stanno inviando il maggior numero possibile di pacchetti).

Il risultato di questi sforzi è alquanto strano:

  • t1 + t2 riescono a inviare ciascuno circa 200k pacchetti / s. t4 nel migliore dei casi vede circa 200k in totale, quindi la metà dei pacchetti viene persa.
  • t3 è quasi inutilizzabile su console sebbene i pacchetti scorrano attraverso di essa (un numero elevato di soft-irq)
  • il garbage collector della cache di route non è affatto prevedibile e nell'impostazione predefinita è sopraffatto da pochissimi pacchetti / s (<50k pacchetti / s)
  • l'attivazione di regole iptables con stato fa sì che la velocità dei pacchetti in arrivo su t4 scenda a circa 100k pacchetti / s, perdendo efficacemente oltre il 75% dei pacchetti

E questo - ecco la mia principale preoccupazione - con due vecchie macchine P4 che inviano quanti più pacchetti possibile - il che significa che quasi tutti in rete dovrebbero essere in grado di farlo.

Quindi ecco la mia domanda: ho trascurato alcuni punti di importazione e di configurazione o nella mia configurazione di test? Esistono alternative per la creazione di un sistema firewall in particolare sui sistemi smp?


È possibile che stai solo saturando la rete? Ciò spiegherebbe parte della perdita di pacchetti.
Preston,

Non credo, dato che la rete è su 1Gb / s ciascuna connessa tramite uno switch hp 2848, il controllo del flusso è attivo e gli overflow della cache di carico e instradamento elevati su t3 indicano che t3 stesso è il punto debole.
tim

Risposte:


1

Vorrei migrare a Kernel> = 3.6 che non ha più una cache di routing. Questo dovrebbe risolvere una parte dei tuoi problemi.


0

Come è configurata la tua registrazione su T3? Se vengono registrati tutti i pacchetti rilasciati, l'I / O del disco potrebbe essere la causa.

Poiché si tratta di un ambiente di test, è possibile provare il test con la registrazione T3 disattivata.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.