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. Võib tekkida olukord, kus serveril veel nagu jaksu oleks aga millegipärast ei saa luua rohkem ühendusi seal lösutavate 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 muuta packet filteri alguses kasutades rida
set optimization <mingi poliitika>
- 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. Oletame, et meie nimeserveris on seadistatud
set timeout udp.multiple 2
Mis tähendab, et kõik õnnestunud udp ühendused kustutakse kahe sekundiga ära, ebaõnnestunuid hoitakse aga alles 60 sekundit ja kauem. Sellega läbustatakse põhjalikult state tabelit.
Nimeserveri spetsfiifikaks on, et kliendi poolt tehakse 1 päring ja siis ei puututa kaua. Teistel teenustel kipub sageli olema teissugune spetsiifika. Andmebaasiserver näiteks ei vaja agresiivset optimiseerimist. Seal tavaliselt kümmekond masinat kasutavad pole vaja olekute tabelit sättida.
Järgnev seadistus on mõeldud kõrge loadi all oleva nimeserveri jaoks, kus palju liiklust udp protokolli peal ja tillukesed paketid. timeoudid aga 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.
Veebiserveril 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.
Abiks utiliidid statistika vaatamisel
Pftop
# pftop -v rules
- netstat: show network status
- vmstat: report virtual memory statistics
- iostat: report I/O statistics
Statistika jälgimiseks vahendeid
# netstat -w 1 -I igb0
input (igb0) output
packets errs idrops bytes packets errs bytes colls
3000 0 0 1086897 8134 0 8775357 0
2620 0 0 396348 6891 0 7189021 0
1899 0 0 295243 5412 0 5856201 0
1901 0 0 298604 5175 0 5464099 0
1658 0 0 297696 4982 0 5265117 0
1817 0 0 316836 5453 0 5968408 0
2091 0 0 377244 5253 0 5494482 0
2133 0 0 381662 6582 0 7420491 0
1964 0 0 313340 6520 0 7840469 0
2697 0 0 860869 7669 0 8651722 0
2554 0 0 357516 6459 0 7297391 0
1943 0 0 312796 4987 0 5225931 0
2211 0 0 397048 6176 0 6464275 0
1759 0 0 291412 4692 0 4938879 0
1810 0 0 289110 5183 0 5833218 0
2270 0 0 351328 6374 0 7031752 0
1862 0 0 412506 5559 0 6363501 0
2301 0 0 499698 6740 0 7712993 0
2408 0 0 446374 7401 0 8451935 0
/0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10
Load Average |
Interface Traffic Peak Total
lo0 in 0.000 KB/s 0.000 KB/s 1.564 MB
out 0.000 KB/s 0.000 KB/s 1.564 MB
igb3 in 4.552 MB/s 4.553 MB/s 17.493 TB
out 76.708 KB/s 79.002 KB/s 3.859 TB
igb2 in 2.027 MB/s 2.788 MB/s 4.091 TB
out 195.864 KB/s 195.864 KB/s 6.895 TB
bge1 in 0.069 KB/s 0.081 KB/s 943.625 MB
out 0.000 KB/s 0.000 KB/s 0.359 KB
igb1 in 1.853 MB/s 3.429 MB/s 30.322 TB
out 2.152 MB/s 3.266 MB/s 7.158 TB
igb0 in 370.152 KB/s 370.152 KB/s 11.772 TB
out 7.763 MB/s 9.346 MB/s 57.659 TB
Lugemist
- http://www.freebsd.org/doc/handbook/configtuning-kernel-limits.html Mitte seotud otseselt paketi filtreerimisega end ka vajalik.