Packet filteri optimiseerimine

Allikas: Kuutõrvaja

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

Pftop.png

  • 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