IPtables - schlechte Performance durch schlechte Regeln?

[lynix]

Hi, zusammen!

Weiß jemand, ob es durch "umständliche" Regelkonstruktionen zu spürbaren Performanceverlusten bei iptables kommen kann?

Mit "umständlich" meine ich z.B. das Erstellen von zusätzlichen Chains, anstatt die Regeln direkt in INPUT zu klatschen. Das fördert nämlich die Übersicht dramatisch - aber da ich die genaue Implementierung nicht kenne würde ich gerne wissen, ob ich dadurch Performance einbüße.


Gruß

lynix

[Roger Wilco]

Langsamer ja, aber vermutlich unmerklich, so lange die Anzahl deiner Regeln nicht hoch 4- bzw. 5-stellig sind.

[Thorashh]

Moin

Das läßt sich so pauschal nicht sagen.
Wenn Du die Chains geschickt definierst, lässt sich damit viel Rechenzeit einsparen. Wenn Du sie schlecht wählst, verbrauchst Du unnötig Rechenzeit.

[asi_dkn]

Also bis du wirklich etwas merkst, gerade auf aktuellen Rechnern, brauchst du einige zehntausend Regel sowie ne Menge Pakete die gefiltert werden. Zudem kann es durchaus auch Unterschiede geben ob du stateful oder stateless filterst.

Die Reihenfolge der Regeln ist sicherlich relevant. Wenn du als Destination DROP oder ACCEPT hast, als Beispiel, und ein Paket matcht, dann werden keine weiteren Regeln angewendet.

Wenn du also am meisten HTTP Traffic hast, filterst du mit Vorteil als erstes danach, damit die meisten Pakete zügig verarbeitet werden können.

[403]

Hm, haette vermutet dass iptables logging Optionen aufgrund von IO Belastungen schlechte Performance nach sich ziehen. Vielleicht kann Harry nochmal was dazu sagen?!

[lynix]

Okay, vielen Dank für die zahlreichen Antworten :)

Ich werde dann mal etwas konkreter:

Ich verwende eine stateful firewall mit folgender Konfiguration:


Chain INPUT (policy DROP 60 packets, 2160 bytes)
pkts bytes target prot opt in out source destination
6802 4467K preventions all -- any any anywhere anywhere
6802 4467K blacklist all -- any any anywhere anywhere
6802 4467K whitelist all -- any any anywhere anywhere
310 30663 services all -- any any anywhere anywhere
1 204 REJECT tcp -- any any anywhere anywhere reject-with tcp-reset
249 28299 REJECT udp -- any any anywhere anywhere reject-with icmp-port-unreachable

Ich jage hier meine Pakete erst durch eine chain namens preventions, wo ich gängige Attacken (Xmas-Pakete, flooding, etc.) herausfiltere. Danach kommt eine mac-blacklist, gefolgt von einer whitelist, welche related, established und pings durchlässt. Danach kommen die eigentlichen Freigaben für die Services auf der Box (ssh, samba, etc.) und schließlich die Imitation des Standardverhaltens bei geschlossenen Ports.

Meine Frage bezog sich nun darauf, dass die meisten Pakete ja unter related fallen und somit erst in der whitelist matchen. Ich frage mich also, ob es erheblich ist, die den Umweg durch die separate chain nehmen zu lassen, statt die entsprechende Regel direkt in INPUT zu klatschen.

Die Box ist eine umgebaute Streamingbox mit einem 700MHz mobile Pentium, hat also nicht soo viel Rechenpower. Sie dient auch als Torrentbox (seeden meiner Lieblingsdistribution ;) ).


Gruß

lynix

[asi_dkn]

Beitrag gemeldet

[lynix]

Beitrag gemeldet

Gemeldet?? Darf ich fragen warum??

[Roger Wilco]

Weil davor ein reiner Spameintrag von einem Bot stand. Vielleicht könnten die Mods die Folgeeinträge darauf ebenfalls löschen?