IPtables: pořadí pravidel a výkon

[monolog]

Zalezi vykon iptables od poradia pravidiel? Je napriklad vhodne vlozit conntrack az za jednoduchsie pravidla (match na interface, port atd)? Drzi sa vobec kernel povodneho poradia alebo si ho sam za behu optimalizuje?

[Reklama]

[Sten]

Záleží a hodně. Kernel se drží zadaného pořadí, žádné optimalizace nedělá, to má dělat buď uživatel nebo nějaký obslužný program, kernel může těžko rozhodovat, jestli to přeskládáním pravidel nerozbije.

[Rhinox]

Zalezi vykon iptables od poradia pravidiel? Je napriklad vhodne vlozit conntrack az za jednoduchsie pravidla (match na interface, port atd)? Drzi sa vobec kernel povodneho poradia alebo si ho sam za behu optimalizuje?

Nejen ze zalezit na poradi pravidel, ale taky na tom kam ty pravidla umistis (chain, table). Kdyz uz spominas conntrack, z hlediska vykonu je rozdil jestli nevalidni packety blokujes pres:

iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

nebo:

iptables -t mangle -A PREROUTING -m conntrack --ctstate INVALID -j DROP

V tom druhem pripade je takovej packet odchycen jiz v prerouting-chain, a do input-chain ani neprijde (prerouting-chain ovsem nema filter-table, tak se to musi resit pres mangle-table)...

[SB]

No jo, ale když budu mít v INPUT/FORWARD pravidlo pro invalid až za established (což je asi nejpoužívanější pravidlo), tak to bude rychlejší, než když v PREROUTING budu vždy ověřovat invalid. Je tomu tak?

[Rhinox]

No jo, ale když budu mít v INPUT/FORWARD pravidlo pro invalid až za established (což je asi nejpoužívanější pravidlo), tak to bude rychlejší, než když v PREROUTING budu vždy ověřovat invalid. Je tomu tak?

Nebude to rychlejsi, protoze nez to vubec projde pres INPUT, jiz to musi projit pres PREROUTING (i kdybys tam zadne pravidla nemel). Tak proc to nefiltrovat jiz v PREROUTING?

Jestli se nemylim, povolit new/established/related muzes taky v PREROUTING/mangle (opravte mne jestli se pletu), to je uz za conntrack, coz je vse co k tomu potrebujes. K tomu jeste nastavit policy na deny (opet si nejsem jistej, ale domnivam se ze -P jde nastavit pro vsechny zabudovane chains), a filtrovani nevalidniho trafficu mas pak vyresen jiz na PREROUTING. Do INPUT-chain se ani nedostane...

[Reklama]

[SB]

Když v PREROUTING bude nic, tak to taky bude nic trvat. Když se potom použije nejčastější pravidlo ve FORWARD established před pravidlem invalid, ke kontrole vůbec nedojde. Když ale dám do PREROUTING test na invalid, bude se KAŽDÝ paket ověřovat na invalid, což stojí zdroje, a to v situaci, kdy výskyt paketů invalid je zcela okrajový (u mě na routeru asi 0,0005).

Kde je v mé úvaze chyba?

[Rhinox]

Tvoje chyba je v predpokladu, ze na to aby packet prosel pres PREROUTING-chain nepotrebujes zadne cpu/ram, protoze tam nemas zadne pravidlo...

Kdyz nechces overovat invalid, nemusis (to byl ostatne jenom priklad, protoze tazatel spomenul conntrack). Jenze vetsina pravidel se muze presunout z INPUT do PREROUTING. U packetu ktere projdou je to temer jedno, jesti jsou podrobeny pravidlu v PREROUTING nebo INPUT. Kdyz jsou povoleny, stejne prejdou obe. Jenze u malignich paketu se vyplati zahazovat je co nejdriv. A stejne tak kazde filtrovani nezadouciho trafficu (bogus, blacklist, atd).

[SB]

Tak ještě pomaleji:

1. Zpracovává-li firewall v PREROUTING 1 pravidlo, je to vždy náročnější (na něco, to není podstatné), než když je tam 0 pravidel.
2. Je-li vadný jeden z 2000 packetů, je rychlejší, když při jednom z 2000 packetů zpracuju navíc 5 pravidel, než když 1999krát zpracuju zbytečně jedno pravidlo.

Už je jasné, co mám na mysli? Pravidla, která se používají vyjímečně a nejsou fatální, nemá smysl strkat dopředu.