☰

Linux iptables / conntrack Leistungsproblem

tag-icon • tag-icon linux firewall
Linux iptables / conntrack Leistungsproblem

Ich habe im Labor einen Test-Aufbau mit 4 Maschinen:

  • 2 alte P4-Maschinen (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

um die Leistung der Linux-Firewall zu testen, da wir in den letzten Monaten von einer Reihe von Syn-Flood-Angriffen betroffen waren. Alle Maschinen laufen unter Ubuntu 12.04 64bit. t1, t2, t3 sind über einen 1GB/s-Switch miteinander verbunden, t4 ist über eine zusätzliche Schnittstelle mit t3 verbunden. t3 simuliert also die Firewall, t4 ist das Ziel, t1, t2 spielen die Angreifer, die einen Paketsturm erzeugen (192.168.4.199 ist t4):

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

t4 verwirft alle eingehenden Pakete, um Verwechslungen mit Gateways, Leistungsprobleme von t4 usw. zu vermeiden. Ich beobachte die Paketstatistiken in iptraf. Ich habe die Firewall (t3) wie folgt konfiguriert:

  • Stock 3.2.0-31-generischer #50-Ubuntu SMP-Kernel
  • rhash_entries=33554432 als Kernel-Parameter

  • sysctl wie folgt:

    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

(Ich habe viele Optimierungen vorgenommen, um t3 am Laufen zu halten, wenn t1+t2 so viele Pakete wie möglich senden).

Das Ergebnis dieser Bemühungen ist etwas merkwürdig:

  • t1+t2 schaffen es, jeweils etwa 200.000 Pakete/s zu senden. t4 schafft es im besten Fall insgesamt etwa 200.000, sodass die Hälfte der Pakete verloren geht.
  • t3 ist auf der Konsole nahezu unbrauchbar, obwohl Pakete hindurchfließen (hohe Anzahl von Soft-IRQs)
  • der Route Cache Garbage Collector ist alles andere als vorhersehbar und wird in der Standardeinstellung von sehr wenigen Paketen/s (<50k Pakete/s) überfordert
  • Durch die Aktivierung von Stateful-IPtables-Regeln sinkt die Paketrate, die bei T4 ankommt, auf etwa 100.000 Pakete/s, wodurch effektiv mehr als 75 % der Pakete verloren gehen

Und dies – und das ist meine Hauptsorge – mit zwei alten P4-Maschinen, die so viele Pakete senden wie sie können – was bedeutet, dass fast jeder im Netz dazu in der Lage sein sollte.

Hier also meine Frage: Habe ich einen wichtigen Punkt in der Konfiguration oder in meinem Testaufbau übersehen? Gibt es Alternativen zum Aufbau eines Firewall-Systems, insbesondere auf SMP-Systemen?

Antwort1

Ich würde auf Kernel >= 3.6 migrieren, der keinen Routing-Cache mehr hat. Das sollte einen Teil Ihrer Probleme lösen.

Antwort2

Wie ist Ihre Protokollierung auf T3 eingerichtet? Wenn alle verlorenen Pakete protokolliert werden, liegt die Ursache möglicherweise am Festplatten-E/A.

Da dies eine Testumgebung ist, können Sie den Test mit deaktivierter T3-Protokollierung durchführen.

verwandte Informationen