Packet filteri optimiseerimine

Packet filter teeb üldiselt silmajärgi hinnates süsteemile väga vähe koormust. Näiteks FreeBSDs tundub kernel tegevat rohkem tööd pakettide edastamisega kui packet filteri endaga. Üsnagi suurel tulemüüril millel koormuseks keskmiselt 20000-40000 state püsib koormus üsnagi normaalne.

Siiski järgnevalt pisut packet filteri erinevatest optimiseerimisvõimalustest.

Üks olulisemaid asju on ehk tõsta paljude ühendustega serveril statede arvu. Vaikimisi on neid lubatud vaid 10 000 mis võib hakata kiirelt piirama. Serveril veel nagu jaksu oleks aga millegipärast ei saa luua rohkem ühendusi teenustega. Seda limiiti saab tõsta reaga

set limit states 1000000

Võimalik on seadistada tcp optimiseerimist. Võimalikud valikud on normal, aggressive ja conservative. Neid saab seadistada packet filteri alguses kasutades rida

set optimization aggressive

normal - suitable for almost all networks.
aggressive - aggressively expires connections from the state table. This can greatly reduce the *memory requirements on a busy firewall at the risk of dropping idle connections early.
conservative - extremely conservative settings. This avoids dropping idle connections at the expense of greater memory utilization and slightly increased processor utilization.

high-latency - A high-latency environment (such as a satellite connection).

mis tähendab vist äärmiselt pikkasid paketiliikumise aegasid ja arvestab võimalike kadudega. "pfctl -s timeouts" peaks ära näitama mis erinevused ühel või teisel valikul on.

Nagu öeldud muudetakse set optimization abil ainult tcp timeoute. Vaikimisi timeoudid FreeBSD 8.2 opsüsteemis on

*TIMEOUTS:		   Normal	Aggressive	Conservative
tcp.first                   120s	   30s		  3600s
tcp.opening                  30s	    5s		   900s
tcp.established           86400s	18000s		432000s
tcp.closing                 900s	   60s		  3600s
tcp.finwait                  45s	   30s		   600s
tcp.closed                   90s	   30s		   180s
tcp.tsdiff                   30s	   10s		    60s

Limits püsib kõigil

LIMITS:
states        hard limit    10000
src-nodes     hard limit    10000
frags         hard limit     5000
tables        hard limit     1000
table-entries hard limit   100000

Ei muutu samuti järgnevad asjad

adaptive.start             6000 states
adaptive.end              12000 states
src.track                     0s
udp.first                    60s
udp.single                   30s
udp.multiple                 60s
icmp.first                   20s
icmp.error                   10s
other.first                  60s
other.single                 30s
other.multiple               60s
frag                         30s
interval                     10s

Muutujate seletus

set timeout tcp.first - millal handsake tehakse, kaua oodatakse
set timeout tcp.closed - kui väike sulgetakse aeglaste ühendustega kiirelt

Näide, kuidas võib valede ja teadmatute seadistustega serveri võimekust tõsiselt kahjustada. Paneme nimeserverile järgneva optimiseerimise.

set timeout udp.multiple 2

timeout.2 teeb kõvasti kahju. Kõik õnnestunud kustutakse kahe sekundiga ära ebaõnnestunuid hoitakse aga alles 60 sekundit ja kauem. Sellega läbustatakse state tabelit.

Nimeserveri spetsfiifikaks on, et kliendi poolt tehakse 1 päring ja siis ei puututa kaua. Teistel masinatel on teissugune spetsiifika. Andmebaasiserver näiteks. Seal pole vaja agresiivset optimiseerimist. Kümmekond masinat kasutavad pole vaja olekute tabelit sättida. Konservatiivsed seaded.

Järgnev seadistus on mõeldud kõrge loadi all oleva nimeserveri jaoks, palju trafficut udp peal ja tillukesed paketid. timeoudid väiksemad.

set optimization aggressive
set timeout tcp.established 7200
set timeout { udp.first 20, udp.single 5, udp.multiple 30 }
set limit states 1000000

first =üks server üheainsa paketiga, pagan teab mis nende ühendustega veel edasi saab
single =üks server mitu paketti aga vastust pole saanud. Timeout väikse, et doss attack ei tõmbaks täis
multiple = õnnestunud sessioon, mida võiks kauem hoida, väärtuslikum.

Veebiserver näiteks paljude veebidega. Peaks vaatama rohkem tcp timeoute, olekute tabel võiks olla suur.

Kas agresiivne või normal on otsustamise küsimus. Agresiivne masinale mil kliente palju laiali. Kui kliente keskmiselt mõistlik arv ja kõik mõistlike päringutega ei pea olema agresiivne.

Veel töötavad NFS/Radius udp peal, muudel serveritel tuleks seadistada rohkem TCP numbreid.

Vaja vaadata mis defauldid eri poliitikatega (agresiivne-passiivne)

Sageli ühenduste aegumisd ei paista niiasma välja. St ühendus ei pruugi katkeda vaid ühendus tuuakse üles uue paketi saabumisel kliendilt. Tehakse lihtsalt märkamatult taustal rohkem tööd näiteks state tabeliga. See paistab välja vaid siis kui suurem ddos rünnak serveri/seadme suunas.

Kui tulemüür töötab nö dioodina, et välja lubab kõiki aga sisse on filtreeritud võib samas ühendus ka puhtalt katki minna state maha viskamisega.

Igal interfacel oma tabel

set state-policy if-bound

Tasub kasutada set ruleset-optimization none st nii vast on ka vigu kergem välja sõeluda (vastasel korral ta ise järjestab reegleid võrreldes konfiga vahel ümber). PS kui labeleid kasutada iga pass-block reegliga, siis peaks ta käituma igal juhul nagu see oleks none peal.