Kako postaviti pametne telefone i računala. Informativni portal

Kako mogu saznati koji firewall imam. Vanjski napadi na sustav zaštićen vatrozidom

Metodologija ispitivanja

Testiranje je provedeno na eksperimentalnom računalu s licenciranim sustavom Windows XP s instaliranim SP1 (testiranje je provedeno pod idealiziranim uvjetima - "operacijski sustav + vatrozid" kako bi se isključio utjecaj drugih programa na čistoću eksperimenta). Uslužni program APS korišten je kao pokazatelj uspješnog pristupa uslugama. Kao sredstva vanjskog utjecaja korištena su:
  • skener XSpider 6.5 i 7.0
  • Retina mrežni sigurnosni skener 4.9
  • nekoliko skenera mog dizajna.
Osim toga, korišten je CommView 4.1 njuškalo (kao alat za praćenje mrežni promet te kao pomoćni program za generiranje i slanje paketa s raznim kršenjima u strukturi). Takozvani. flooderi uobičajenih tipova, uslužni programi za simulaciju trojanaca.

Na testnom računalu IE 6 je korišten kao sredstvo za pristup mreži i Internetu, Outlook Express 6, TheBat 1.60, MSN Messenger 6.1. Osim njih, u testu su sudjelovali i simulatori trojanaca i pravih trojanaca / Backdoorsa iz moje kolekcije (posebno Backdoor.Antilam, Backdoor.AutoSpy, Backdoor.Death, Backdoor.SubSeven, Backdoor.Netbus, Backdoor.BO2K), mreža / mail virusi (I-Worm.Badtrans, I-Worm.NetSky, I-Worm.Sircam, I-Worm.Mydoom, I-Worm.MSBlast), programi za preuzimanje TrojanDownloader (osobito TrojanDownloader.IstBar) i špijunske komponente SpyWare. Glavni zadatak testova bio je pokušaj sagledavanja Firewall-a očima korisnika, uočavanje njegovih snaga i slabosti s moje točke gledišta.

Kerio Technologies WinRoute Pro v4.2.5

Instalacija i deinstalacija:
Prolazi bez problema.
Instalacija sa "default" postavkama, bez pravila - radi samo NAT. Umrežavanje - nema problema, rezultati skeniranja - APS ne pokazuje status alarma, skener misli da su svi portovi zatvoreni. Winroute sam po sebi ne izdaje alarme i vizualno ne identificira činjenicu skeniranja.

Outpost Firewall Pro 2.1 Build 303.4009 (314)

Instalacija i deinstalacija:
Instalacija pod XP ide bez problema, pri pokretanju je uključen način učenja.

ZoneLabs ZoneAlarm Pro s web filtriranjem 4.5.594.000 – osobni vatrozid

Instalacija i deinstalacija:
Tijekom instalacije, XP je prekinuo vezu tijekom pokušaja pokretanja nakon instalacije. Nakon ponovnog pokretanja sve je radilo dobro.

AtGuard 3.22>

Instalacija i deinstalacija:
Instalacija i deinstalacija ne stvara nikakve probleme

prednosti:

  1. Vatrozid je male veličine, ima zanimljivo rješenje u pogledu sučelja - izrađen je u obliku panela smještenog na vrhu ekrana

Nedostaci i značajke:

  1. Ranjivo u načinu učenja - od trenutka kada se izda zahtjev za kreiranje pravila do kreiranja, ono prosljeđuje pakete u oba smjera
  2. Sučelje je malo problematično pri ponovnom crtanju prozora

Cjelokupna ocjena:
Jednostavan vatrozid, ali prilično funkcionalan

Kerio osobni vatrozid 4

Instalacija i deinstalacija:
Instalacija ide bez problema, uklanjanje je "čisto" - nisu uočeni nikakvi problemi nakon deinstalacije.

Norton sigurnost na internetu 2004. (NIS)

Instalacija i deinstalacija: Instalacija ne stvara probleme, ali je od svih analiziranih instalatera najteža.

Vatrozid internetske veze, ICF - ugrađen Windows vatrozid XP

Instalacija i deinstalacija: Instalacija nije potrebna, jest redovnim sredstvima xp Omogućeno u postavkama mrežni adapter. Prema zadanim postavkama, ICF radi u maksimalnom sigurnosnom načinu rada i (ovo je rezultat mog zapažanja) princip njegovog rada je sljedeći - zahtjevi aplikacije se puštaju prema van, a izvan primaju se samo paketi koji su došli kao odgovor na moje zahtjeve ( korespondencija zahtjev-odgovor jasno se održava u obliku dinamičke tablice). Dakle, prilikom skeniranja portova na računalu s uključenim ICF-om nema niti jednog otvorenog porta (to je logično - paketi skenera portova neće biti preskočeni, jer ih nitko nije tražio). Slična je situacija i s raznim vrstama "nuklearki" koje se temelje na slanju nestandardnih paketa.

Vatrozid internetske veze, ICF - ugrađeni vatrozid u Windows XP SP2

Instalacija i deinstalacija: Instalacija nije potrebna, to je običan XP alat (uključen u paket ažuriranja SP2 za XP). Omogućavanje se vrši u postavkama mrežnog adaptera. Treba napomenuti da se prilikom instaliranja SP2 ili kada instalirate XP s integriranim SP2, osim vatrozida, u sustavu pojavljuje i sigurnosni centar koji može prikazati ICF postavke

Sygate Personal Firewall Pro 5.5 verzija 2525

Instalacija i deinstalacija:

ISS BlackIce 3.6.cci

Instalacija i deinstalacija: Instalacija programa i njegova deinstalacija odvijaju se bez problema, ali tijekom instalacije dolazi do pogreške u ikernel biblioteci. Ista se pogreška dogodila tijekom deinstalacije. Pojava ove pogreške ne utječe na proces instaliranja i deinstaliranja programa. Instalacijski program nije zahtijevao ponovno pokretanje sustava, što je neobično za Firewall

Visnetic Firewall 2.2

Instalacija i deinstalacija: Instalacija programa i njegova deinstalacija odvijaju se bez problema. Nakon instalacije potrebno je ponovno podizanje sustava.

Pogledajte i zaustavite osobni vatrozid 2.05

Instalacija i deinstalacija: Instalacija programa i njegova deinstalacija odvijaju se bez problema. Nakon instalacije potrebno je ponovno podizanje sustava. Instalira vlastiti drajver za rad.

Kaspersky AntiHacker 1.5

Instalacija i deinstalacija: Instalacija programa i njegova deinstalacija odvijaju se bez problema. Nakon instalacije potrebno je ponovno podizanje sustava.

Tiny Personal Firewall Pro 6.0

Instalacija i deinstalacija:
Instalacija programa i njegova deinstalacija odvijaju se bez problema. Nakon instalacije potrebno je ponovno podizanje sustava.

McAfee Personal Firewall Plus 6.0 Build 6014

Instalacija i deinstalacija:
Instalacija programa i njegova deinstalacija odvijaju se bez problema. Nakon instalacije potrebno je ponovno podizanje sustava.

R-Firewall 1.0 Build 43

Instalacija i deinstalacija:
Instalacija programa i njegova deinstalacija odvijaju se bez problema. Veličina distribucijskog kompleta je mala (3,8 MB), možete prilagoditi sastav proizvoda. Rad je prilično stabilan, na referentnom PC-u nisu uočeni očiti kvarovi i zamrzavanja

Opći zaključci i zaključak

Dakle, zbrojimo rezultate testova. Zapravo, testovi su potvrdili moje teorijske ideje o stanju problema:
  1. Vatrozid je potrebno konfigurirati. Svi testirani vatrozidovi su dobro radili, ali tek nakon konfiguracije (trening, ručno kreiranje postavki - nije važno). Korištenje nekonfiguriranog vatrozida može učiniti više štete nego koristi (propuštat će opasne pakete i, obrnuto, ometati korisne programe);
  2. Nakon postavke vatrozida a IDS treba testirati- Ovo je također prilično očigledan zaključak, ali je ipak važan. Prvi korak koji sam poduzeo za stvaranje testera bio je APS uslužni program. Postoje još dva - trojanski simulator (tj. uslužni program koji će izvoditi sigurne pokušaje da korisnik "razbije" Firewall iznutra (naravno, napadi će biti opisani u bazi podataka i bit će izvedeni na naredbu korisnik pod njegovom kontrolom), što će vam omogućiti da promatrate reakciju Firewall i IDS) i uslužni program za ekspresno skeniranje portova i osnovne napade (u stvari, APS je upravo suprotan - mogu imati zajedničku bazu portova). Već razvijam ove uslužne programe - njihova prisutnost u korisničkom arsenalu omogućit će neku vrstu "instrumentalne kontrole".
  3. Osobni vatrozid osjetljiv je na zlonamjerne programe koji se pokreću iz konteksta korisnih. Zaključak - barem dolje s različitim "lijevim" panelima i ostalim BHO iz preglednika i e-maila!! Prije instaliranja bilo kojeg dodatka, ploče, uslužnog programa za proširenje itd. treba deset puta razmisliti o njihovoj nužnosti, jer. oni nisu zasebni procesi operacijskog sustava i pokreću se iz konteksta roditeljskog programa. Trojanac lako detektuje osobni Firewall - "vidi" da neki proces (recimo, bo2k.exe) pokušava početi slušati na portu xxxxx ili komunicirati s određenim hostom - izdaje se zahtjev za valjanost, korisnik počinje shvatiti kakav je "bo2k.exe" i Backdoor je uhvaćen. Ali ako je trojanski program radio iz konteksta preglednika, tada gotovo sigurno nitko ne bi obraćao pažnju na pristup preglednika Internetu. Takvi trojanci postoje, najbliži primjer je TrojanDownloader.IstBar - instaliran je točno kao IE traka (naravno, nije u procesima, niti na popisu za automatsko pokretanje);
  4. Mnogi osobni vatrozidovi vidljivi su kao procesi operativnog sustava i virus ih može zaustaviti. Zaključak - rad Firewall-a mora se pratiti i njegov iznenadni prekid može poslužiti kao signal da je virus prodro u PC;
  5. Neki vatrozidovi (kao što je Kerio) dopuštaju daljinsko upravljanje- funkcija daljinski upravljač mora biti ili onemogućeno ili zaštićeno lozinkom.

Vatrozid (vatrozid) Postavke sustava Windows ključne su za osiguranje sigurnosti računala i podataka pohranjenih na njemu pri radu na Internetu i lokalnim mrežama. Operacija konfiguracije vatrozida provodi se standardnim Windows metodama i ne zahtijeva posebne kompjutersko znanje.

Uputa

  • Pritisnite gumb "Start" za pozivanje glavnog izbornika sustava i idite na stavku "Upravljačka ploča".
  • Otvorite vezu "Windows Firewall" i označite okvir "Omogući (preporučeno)" na kartici "Općenito" da biste pokrenuli vatrozid.
  • Označite okvir "Ne dopuštaj iznimke" kako biste onemogućili blokiranje upozorenja i spriječili stvaranje popisa izuzetaka.
  • Idite na karticu "Iznimke" i primijenite potvrdne okvire u poljima aplikacija kojima želite dopustiti dolazne veze.
  • Kliknite karticu "Napredno" da biste onemogućili vatrozid za određenu vezu i postavke dodatne opcije Filtriranje ICMP protokola.
  • Kliknite gumb "Zadano" da biste vratili izvorne postavke vatrozida.
  • Koristite automatsko kreiranje iznimaka aplikacije kada pokrenete program koji čeka vezu na određeni port za pristup mreži.
  • Kliknite gumb "Blokiraj" u prozoru "Windows Security Alert" kako biste u potpunosti spriječili povezivanje odabrane aplikacije s mrežom.
  • Kliknite gumb "Deblokiraj" da biste stvorili pravilo koje omogućuje da se odabrana aplikacija poveže s mrežom.
  • Kliknite gumb Obustavi kako biste u ovom trenutku odbili vezu.
  • Vratite se na karticu "Iznimke" i kliknite gumb "Dodaj program" kako biste stvorili pravilo koje odabranoj aplikaciji dopušta pristup mreži, ako je unaprijed poznato da je to potrebno.
  • Kliknite gumb "Dodaj priključak" da biste stvorili pravilo povezivanja s mreže s uslugom koja se izvodi na ovom portu.
  • Kliknite gumb Promjena područja da biste postavili raspon adresa s kojih se mogu uspostaviti veze s navedenom aplikacijom ili portom.
  • Kliknite karticu Napredno i primijenite potvrdne okvire na poljima mrežnih veza u odjeljku Postavke mrežnih veza kako biste omogućili uslugu vatrozida za svaku od njih.
  • Usporedno testiranje 21 popularnog vatrozida za kvalitetu zaštite od napada koji dolaze iz sustava. U testu je zaštita testirana na 64 testna uslužna programa posebno razvijena za nju, koji su provjeravali zaštitu procesa od prekida, zaštitu od standardnih internih napada, zaštitu od nestandardnih curenja i zaštitu od nestandardnih tehnika prodora u kernel mode.

    Uz antivirus, vatrozid je jedna od glavnih komponenti računalne sigurnosti. Međutim, za razliku od antivirusnih programa, objektivni testovi učinkovitosti vatrozida rijetko se provode. Taj smo jaz pokušali zatvoriti provodeći test vatrozida za zaštitu od internih napada i osobni IDS/IPS test za zaštitu od napada na ranjive aplikacije 2011. i 2012. godine. Ove godine odlučili smo proširiti popis korištenih metoda i ponoviti test vatrozida za zaštitu od internih napada kako bismo vidjeli kako su se rezultati popularnih proizvoda mijenjali tijekom proteklog vremena po ovom kriteriju.

    Čemu je ovaj test namijenjen ili koje funkcije vatrozid obavlja? Prema definiciji internetskog standarda [RFC3511] (2003.), vatrozid je sustav koji implementira funkcije filtriranja mrežnih paketa u skladu s određenim pravilima kako bi se razlikovao promet između mrežnih segmenata. Međutim, sa sve većom složenošću zlonamjernog softvera i hakerski napadi, izvorni zadaci vatrozida dopunjeni su novima funkcionalni moduli. Gotovo je nemoguće zamisliti punopravni vatrozid bez HIPS modula (praćenje događaja sustava, kontrola integriteta sustava itd.).

    Glavni zadatak modernog vatrozida je blokiranje neovlaštenih mrežnih komunikacija (u daljnjem tekstu napadi), koji se dijele na unutarnje i vanjske. To uključuje:

    Vanjski napadi na sustav zaštićen vatrozidom:

    • pokrenuli hakeri;
    • pokrenut zlonamjernim kodom.
    • pokrenut od strane nepouzdanih aplikacija (zlonamjerni kod);
    • pokrenute od strane aplikacija čija je mrežna aktivnost izričito zabranjena pravilima.

    Osim toga, proizvodi koji bi se mogli klasificirati kao čisti osobni vatrozidovi u klasičnoj formulaciji iz 2003. praktički su nestali s tržišta. Zamijenjeni su složenim proizvodima za zaštitu osobnih računala, koji nužno uključuju komponentu vatrozida.

    Test vatrozida za zaštitu od vanjskih napada uključuje proučavanje kvalitete zaštite od napada koji dolaze iz sustava. Ispitivanje je provedeno u sljedećim područjima:

    1. Provjera zaštite procesa od prekida.
    2. Zaštita od standardnih internih napada.
    3. Ispitivanje zaštite od nestandardnih propuštanja.
    4. Testiranje zaštite od nestandardnih tehnika penetracije u kernel modu.

    U odnosu na prethodni test, broj korištenih napada značajno je porastao – s 40 na 64. Promijenio se i operativni sustav koji testirani proizvodi moraju štititi. U prethodnom testu to je bio Windows XP, a u ovom testu Windows 7 x32. Sličan test za Windows 7 x64 operativni sustav također je planiran za kraj godine.

    Uvod

    U testiranju je sudjelovao 21 popularan program sveobuhvatna zaštita(klase Internet Security, ako u liniji nema takvog proizvoda, odabran je isključivo vatrozid) od raznih proizvođača ažurirano od datuma početka testiranja proizvoda (svibanj 2013.) i radi na Windows platforma 7 x32 :

    1. Avast! Internet sigurnost (8.0.1488).
    2. AVG Internet Security (2013.0.3272).
    3. Avira Internet Security (13.0.0.3499).
    4. Bitdefender Internet Security (16.29.0.1830).
    5. Comodo Internet Security (6.1.276867.2813).
    6. Dr.Web sigurnosni prostor (8.0).
    7. Eset pametna sigurnost (6.0.316.0).
    8. F-Secure Internet Security (1.77 build 243).
    9. G DATA Internet Security (1.0.13113.239).
    10. Jetico osobni vatrozid (2.0).
    11. Kaspersky Internet Security (13.0.1.4190(g).
    12. McAfee Internet Security (11.6.507).
    13. Kingsoft Internet Security (2009.05.07.70).
    14. Microsoft Security Essentials (4.2.223.0) + Windows vatrozid.
    15. Norton Internet Security (20.3.0.36).
    16. Online Armor Premium vatrozid (6.0.0.1736).
    17. Outpost Security Suite Pro (8.0 (4164.639.1856).
    18. Panda Internet Security (18.01.01).
    19. Računalni alati Internet Security (9.1.0.2900).
    20. Trend Micro Titanium Internet Security (6.0.1215).
    21. TrustPort Internet Security (2013. (13.0.9.5102).

    Prije početka ispitivanja pripremljeno je testno okruženje. Da biste to učinili, Windows 7 Enterprise SP1 x86 instaliran je na čisto računalo sa svim ažuriranjima dostupnim u tom trenutku, kao i dodatnim softverom potrebnim za testiranje.

    Testiranje je provedeno na dvije vrste postavki: standardno preporučeno od strane proizvođača (zadane postavke) i maksimalno. U prvom slučaju korištene su zadane postavke koje su preporučili proizvođači i izvršene su sve radnje koje je program preporučio.

    U drugom slučaju, osim toga, omogućene su i/ili dovedene sve postavke koje su bile onemogućene u "zadanom" načinu rada, ali su u isto vrijeme mogle utjecati na ishod testiranja i/ili dovedene na maksimalnu poziciju (najstrože postavke). Drugim riječima, postavljanje maksimalnih postavki znači prijenos svih dostupnih s GUI korisničke postavke za sve module vezane za otkrivanje zlonamjerne datoteke ili mrežne aktivnosti na najstrožu opciju.

    Test vatrozida proveden je na sljedećim grupama internih napada, raščlanjenih na razine težine radi jasnoće:

    1. Osnovna razina težine (56 opcija napada):

    1. provjera zaštite procesa od prekida (41 vrsta napada);
    2. zaštita od standardnih internih napada (15 vrsta napada).

    2. Povećana razina težine (8 opcija napada):

    1. ispitivanje zaštite od nestandardnih propuštanja (3 vrste napada);
    2. testiranje zaštite od nestandardnih tehnika za prodor u kernel mod (5 vrsta napada).

    Detaljan opis svih metoda napada korištenih u testu možete pronaći u metodologiji testiranja.

    Provjera zaštite vatrozida od internih napada

    Podsjetimo da se prema korištenoj shemi nagrađivanja dodjeljuje 1 bod (+) ako je napad automatski blokiran, zaštitna funkcionalnost testiranog programa nije narušena. 0,5 bodova (ili +/-) - ako je napad blokiran samo u posebnim okolnostima (npr pravi izbor korisnik željene radnje na zahtjev programa koji se testira). I, konačno, ako je napad bio uspješan u cijelosti ili djelomično s neuspjehom zaštitne funkcionalnosti, tada se nisu dodijelili bodovi. Maksimalni mogući broj bodova postignut u ovom testu bio je 64.

    Tablica 1-2 i Slika 1-2 prikazuju rezultate testiranja vatrozida odvojeno na standardnim i maksimalne postavke. Radi jasnoće, rezultati za svaki vatrozid podijeljeni su u dvije skupine: zaštita od napada osnovne razine složenosti i zaštita od napada Napredna razina teškoće.

    Tablica 1: Rezultati ispitivanja vatrozida za stdapostavke po želji korisnika

    Testirani proizvod Ukupno bodova (maks. 64) Ukupno
    %
    Bodovi % % od zbroja Bodovi % % od zbroja
    Comodo 53 95% 82,8% 6 75% 9,4% 59 92%
    Online oklop 50 89% 78,1% 7,5 94% 11,7% 57,5 90%
    Norton 45 80% 70,3% 6 75% 9,4% 51 80%
    Jetico 46 82% 71,9% 4,5 56% 7,0% 50,5 79%
    Ispostava 45 80% 70,3% 2,5 31% 3,9% 47,5 74%
    Trend Micro 42 75% 65,6% 3 38% 4,7% 45 70%
    Kaspersky 42 75% 65,6% 2,5 31% 3,9% 44,5 70%
    dr. Web 42,5 76% 66,4% 2 25% 3,1% 44,5 70%
    Port povjerenja 43 77% 67,2% 0,5 6% 0,8% 43,5 68%
    G PODACI 42 75% 65,6% 1 13% 1,6% 43 67%
    Avast 41 73% 64,1% 1 13% 1,6% 42 66%
    Eset 41 73% 64,1% 1 13% 1,6% 42 66%
    Bitdefender 41 73% 64,1% 1 13% 1,6% 42 66%
    PROSJEČAN 41 73% 64,1% 0 0% 0,0% 41 64%
    McAfee 41 73% 64,1% 0 0% 0,0% 41 64%
    PC alati 41 73% 64,1% 0 0% 0,0% 41 64%
    Avira 40 71% 62,5% 0 0% 0,0% 40 63%
    Microsoft 40 71% 62,5% 0 0% 0,0% 40 63%
    F-Secure 31,5 56% 49,2% 1 13% 1,6% 32,5 51%
    Panda 30 54% 46,9% 0 0% 0,0% 30 47%
    kralj mekan 27 48% 42,2% 1 13% 1,6% 28 44%

    Slika 1: Rezultati testiranja vatrozida na standardnim postavkama

    Zaštita od unutarnjih napada na postavkama koje preporučuje proizvođač ostavlja mnogo poželjeti. Samo su tri vatrozida uspjela prevladati prag od 80% na standardnim postavkama - to su Comodo, Online Armor i Norton. Sasvim blizu su im Jetico (79%) i Outpost (74%). Rezultati ostalih vatrozida bili su znatno lošiji.

    U odnosu na rezultate prethodnog testa, svi su voditelji potvrdili svoje visoke rezultate, bilo je samo malih pomaka unutar vodeće skupine, na primjer, Outpost i Jetico su zamijenili položaje. Jedino iznenađenje je bilo Nortonov proizvod, koja je u prošlom testu pokazala rezultat od 45% i bila na dnu tablice, a u ovom testu s 80% zauzela je treću poziciju.

    Dobiveni rezultati su rezultat činjenice da su mnogi proizvođači postavili zadane postavke na način da se smanji broj poruka na koje korisnik mora odgovoriti. To potvrđuju i rezultati testa - na standardnim postavkama vatrozidi su postavljali pitanja korisnicima samo u 5,4% napada, a na maksimalnim postavkama - u 9,2% napada. No, to utječe na kvalitetu zaštite, koja će prešutjeti u situaciji kada zlonamjerni program oponaša/izvodi potpuno legitimne radnje u sustavu.

    Također treba obratiti pažnju na dvije pravilnosti. Prvo, postotak prevencije složenih vrsta napada općenito je osjetno lošiji od napada osnovne razine složenosti. Više od polovice ovih napada odbila su samo četiri proizvoda – Comodo, Online Armor, Norton i Jetico. Još četiri proizvoda ušla su u graničnu skupinu, odbacivši od 25% do 38% takvih napada - to su Outpost, Trend Micro, Kaspersky i Dr.Web. Svi ostali proizvodi nisu odbili više od jednog složenog napada. Drugo, poboljšani su pokazatelji odbijanja osnovnih napada. Ako je u prethodnom testu 11 (50%) proizvoda odbilo manje od 50% napada, u ovom testu postoje samo 3 (14%) takva proizvoda.

    Tablica 2: Rezultati testiranja vatrozida pri maksimalnim postavkama

    Testirani proizvod Napadi osnovne razine složenosti (maks. 56 bodova) Napredni napadi (maks. 8 poena) Ukupno bodova (maks. 64) Ukupno
    %
    Bodovi % % od zbroja Bodovi % % od zbroja
    Comodo 56 100% 87,5% 8 100% 12,5% 64 100%
    Bitdefender 56 100% 87,5% 8 100% 12,5% 64 100%
    Online oklop 53 95% 82,8% 8 100% 12,5% 61 95%
    Kaspersky 53 95% 82,8% 7 88% 10,9% 60 94%
    Norton 50,5 90% 78,9% 8 100% 12,5% 58,5 91%
    PC alati 49,5 88% 77,3% 5,5 69% 8,6% 55 86%
    Ispostava 49 88% 76,6% 5,5 69% 8,6% 54,5 85%
    Eset 49 88% 76,6% 5,5 69% 8,6% 54,5 85%
    dr. Web 46,5 83% 72,7% 5 63% 7,8% 51,5 80%
    Jetico 46 82% 71,9% 4,5 56% 7,0% 50,5 79%
    Trend Micro 43 77% 67,2% 3 38% 4,7% 46 72%
    Port povjerenja 43 77% 67,2% 2,5 31% 3,9% 45,5 71%
    G PODACI 42 75% 65,6% 3 38% 4,7% 45 70%
    Avira 41,5 74% 64,8% 2 25% 3,1% 43,5 68%
    Avast 41 73% 64,1% 1,5 19% 2,3% 42,5 66%
    PROSJEČAN 41 73% 64,1% 0 0% 0,0% 41 64%
    McAfee 41 73% 64,1% 0 0% 0,0% 41 64%
    Microsoft 40 71% 62,5% 0 0% 0,0% 40 63%
    F-Secure 31,5 56% 49,2% 1 13% 1,6% 32,5 51%
    Panda 30 54% 46,9% 0 0% 0,0% 30 47%
    kralj mekan 27 48% 42,2% 1 13% 1,6% 28 44%

    Slika 2: Rezultati testiranja vatrozida na maksimalnim postavkama

    S uključenim maksimalnim postavkama, kvaliteta zaštite od internih napada u mnogim testiranim vatrozidima značajno se poboljšala. To je osobito uočljivo kod jakih srednjih seljaka. Svi lideri prethodnog testa i na ovom su testu pokazali visoke rezultate. Od promjena vrijedi istaknuti proizvod Bitdefender koji je uz Comodo pokazao stopostotni rezultat te Norton proizvod koji je prešao u vodeću skupinu.

    Rezultati brojnih proizvoda na standardnim i maksimalnim postavkama pokazali su se istim. To je zbog činjenice da ovi proizvodi nemaju postavke koje mogu utjecati na rezultate našeg testa.

    Usporedba kvalitete zaštite pri standardnim i maksimalnim postavkama

    U skladu s logikom ovog testa, nećemo zbrajati niti usrednjavati rezultate istog proizvoda s razne postavke. Naprotiv, želimo ih usporediti i pokazati značajne razlike u kvaliteti zaštite testiranih proizvoda, ovisno o korištenim postavkama.

    Radi jasnoće predstavljamo konačne rezultate testa vatrozida sa standardnim i maksimalnim postavkama u tablici 3 i slici 3.

    Tablica 3: Sažetak rezultata ispitivanja vatrozida pri standardnim i maksimalnim postavkama

    Proizvod

    Standardne postavke Maksimalne postavke
    Comodo 92% 100%
    Online oklop 90% 95%
    Norton 80% 91%
    Jetico 79% 79%
    Ispostava 74% 85%
    Trend Micro 70% 72%
    Kaspersky 70% 94%
    dr. Web 70% 80%
    Port povjerenja 68% 71%
    G PODACI 67% 70%
    Avast 66% 66%
    Eset 66% 85%
    Bitdefender 66% 100%
    PROSJEČAN 64% 64%
    McAfee 64% 64%
    PC alati 64% 86%
    Avira 63% 68%
    Microsoft 63% 63%
    F-Secure 51% 51%
    Panda 47% 47%
    kralj mekan 44% 44%

    Slika 3: Sažetak rezultata testiranja vatrozida pri standardnim i maksimalnim postavkama

    Slika 3 vrlo jasno pokazuje razliku u rezultatima ispitivanja ovisno o odabranim postavkama.

    Prvo, samo dva proizvoda - Comodo i Online Armor pokazuju blizu maksimalne performanse zaštita, kako na standardnim tako i na maksimalnim postavkama.

    Drugo, prilikom promjene standardnih postavki koje je predložio proizvođač, neki proizvodi se značajno pokazuju najbolja razina zaštita. To se najjasnije vidi u proizvodima kao što su Bitdefender, Kaspersky, Eset, F-Secure i PC Tools.

    Treće, kao što je gore navedeno, neki od testiranih proizvoda uopće nemaju postavke koje bi na bilo koji način mogle utjecati na rezultate testiranja. Stoga su njihovi rezultati na svim vrstama postavki u ovom testu isti. Ova grupa uključuje Jetico, Avast, AVG, McAffe, F-Secure, Panda, Kingsoft i Microsoft.

    Konačna ocjena ne uzima u obzir situacije u kojima je napad odbijen, ali je bilo problema s korisničkim sučeljem proizvoda. U većini slučajeva problemi su se sastojali u „izlijetanju“ sučelja na kratko (od 2 do 10 sekundi) ili do sljedećeg pokretanja operativnog sustava. Iako su proizvodi i dalje pružali zaštitu u slučaju problema s korisničkim sučeljem, prisutnost takvih problema subjektivno se doživljava negativno i može utjecati na preferencije proizvoda. Broj problema s korisničkim sučeljem prikazan je u tablici 3 i slici 3. Procijenjene su pogreške koje su se dogodile tijekom napada razine 1, čiji je ukupan broj 41.

    Tablica 4: Broj problema s korisničkim sučeljem pri standardnim i maksimalnim postavkama

    Testirani proizvod Standardne postavke Maksimalne postavke
    Broj pogrešaka % Broj pogrešaka %
    McAfee 34 83% 34 83%
    Microsoft 33 80% 33 80%
    kralj mekan 20 49% 20 49%
    F-Secure 19 46% 19 46%
    Panda 17 41% 17 41%
    Jetico 16 39% 16 39%
    PC alati 13 32% 13 32%
    Trend Micro 12 29% 12 29%
    PROSJEČAN 10 24% 9 22%
    Port povjerenja 9 22% 9 22%
    G PODACI 9 22% 9 22%
    Bitdefender 8 20% 8 20%
    Norton 6 15% 6 15%
    Avast 5 12% 5 12%
    Ispostava 5 12% 5 12%
    Eset 5 12% 4 10%
    Comodo 5 12% 0 0%
    Avira 2 5% 2 5%
    dr. Web 2 5% 2 5%
    Kaspersky 1 2% 1 2%
    Online oklop 1 2% 1 2%

    Slika 4: Broj problema s korisničkim sučeljem pri standardnim i maksimalnim postavkama

    Rezultati pokazuju da su McAfee i Microsoftovi proizvodi imali problema s korisničkim sučeljem u većini napada (više od 80%). To se može nazvati neprihvatljivom razinom, jer. gotovo svaki uspješno odbijen napad dovest će do problema. Prilično loše rezultate, u rasponu od 30% do 50%, pokazuju Kingsoft, F-Secure, Panda, Jetico i PC Tools. Kada ih koristite, svaka 2-3 napada dovest će do problema sa sučeljem. Brojni proizvodi pokazuju rezultate od 10% do 30%, što se može nazvati zadovoljavajućim. Lijepi rezultati prikazani su proizvodi Avira, Dr.Web, Kaspersky i Online Armor, koji su imali problema u rasponu od 2% do 5% napada. Jedini proizvod koji nikada nije imao problema s korisničkim sučeljem bio je Comodo na maksimalnim postavkama, što je odličan rezultat. Međutim, sa standardnim postavkama Comodoov rezultat se pogoršava (12%), što ukazuje da korištenje ovog proizvoda zahtijeva određeno poznavanje njegove konfiguracije.

    Konačni rezultati testiranja i nagrade

    Kao i u prethodnom testu, nismo usrednjavali rezultate istog proizvoda s različitim postavkama, već smo ih razmatrali neovisno. Tako svaki od testiranih proizvoda može dobiti dvije nagrade, po jednu za svaku vrstu postavke.

    U skladu s nagradnom shemom, najbolji vatrozidovi dobivaju nagrade s naznakom korištenih postavki, vidi tablicu 4.

    Tablica 5: Konačni rezultati testa vatrozida pri standardnim i maksimalnim postavkama

    Testirani proizvod Opcija
    postavke
    Prevencija napada [%] Ukupno
    [%]
    Nagrada
    Baza
    razina težine
    Povećana razina težine
    Comodo Maks 100% 100% 100%
    Platinum Firewall Outbound
    nagradu za zaštitu
    Bitdefender Maks 100% 100% 100%
    Online oklop Maks 95% 100% 95%
    Odlazni zlatni vatrozid
    nagradu za zaštitu
    Kaspersky Maks 95% 88% 94%
    Comodo standard 95% 75% 92%
    Norton Maks 90% 100% 91%
    Online oklop standard 89% 94% 90%
    PC alati Maks 88% 69% 86%
    Ispostava Maks 88% 69% 85%
    Eset Maks 88% 69% 85%
    Norton standard 80% 75% 80%
    dr. Web Maks 83% 63% 80%
    Jetico Maks 82% 56% 79%
    Odlazni srebrni vatrozid
    nagradu za zaštitu
    Jetico standard 82% 56% 79%
    Ispostava standard 80% 31% 74%
    Trend Micro Maks 77% 38% 72%
    Port povjerenja Maks 77% 31% 71%
    Trend Micro standard 75% 38% 70%
    Kaspersky standard 75% 31% 70%
    dr. Web standard 76% 25% 70%
    G PODACI Maks 75% 38% 70%
    Port povjerenja standard 77% 6% 68%
    Odlazni brončani vatrozid
    nagradu za zaštitu
    Avira Maks 74% 25% 68%
    G PODACI standard 75% 13% 67%
    Avast Maks 73% 19% 66%
    Avast standard 73% 13% 66%
    Eset standard 73% 13% 66%
    Bitdefender standard 73% 13% 66%
    PROSJEČAN Maks 73% 0% 64%
    PROSJEČAN standard 73% 0% 64%
    McAfee Maks 73% 0% 64%
    McAfee standard 73% 0% 64%
    PC alati standard 73% 0% 64%
    Microsoft Maks 71% 0% 63%
    Microsoft standard 71% 0% 63%
    Avira standard 71% 0% 63%
    F-Secure Maks 56% 13% 51% Bez nagrade
    F-Secure standard 56% 13% 51%
    Panda Maks 54% 0% 47%
    Panda standard 54% 0% 47%
    kralj mekan Maks 48% 13% 44%
    kralj mekan standard 48% 13% 44%

    Comodo i Bitdefender firewall pokazali su najbolje rezultate na testu, osvojivši 100% bodova na maksimalnim postavkama. Ova dva proizvoda dobivaju nagradu PlatinavatrozidaInostranstvoZaštitaDodijeliti.

    Nagrađivani vatrozidi Online Armor, Kaspersky, Comodo, Norton, PC Tools, Outpost, Eset i Dr.Web također su pokazali vrlo visoke rezultate u testu (preko 80%) ZlatovatrozidaInostranstvoZaštitaDodijeliti. Važno je napomenuti da je Comodo primio ovu nagradu na standardnim postavkama, Online Armor i Norton na standardnim i maksimalnim postavkama, a sve ostalo - samo na maksimalnim postavkama.

    Sljedeća na popisu je skupina od sedam vatrozida čiji rezultati padaju između 60% i 70%. To su Outpost, Kaspersky i Dr.Web na standardnim postavkama; TrustPort i G DATA na maksimalnim postavkama, kao i Jetico i Trend Micro istovremeno na standardnim i maksimalnim postavkama. Svi su oni nagrađeni

    Dovoljno velika skupina proizvoda koji spadaju u raspon od 60% do 70% dobiva nagradu. Valja istaknuti proizvode Eset i Bitdefender na standardnim postavkama, koji su na maksimalnim postavkama uspjeli odbiti znatno veći broj napada.

    Možete se upoznati s detaljnim rezultatima testiranja i uvjeriti se u točnost konačnih izračuna preuzimanjem rezultata testa u Microsoft Excel formatu.

    Shabanov Ilya, stranica za upravljanje partnerom:

    “Bio sam jako zadovoljan činjenicom da je toliko proizvođača značajno poboljšalo proaktivnu zaštitu od unutarnjih napada i samoobrane u svojim proizvodima. Čak smo morali revidirati shemu dodjele kako bismo podigli ljestvicu zahtjeva. Rezultat manji od 51% sada se smatra potpunim neuspjehom.

    Ugodno me iznenadio Bitdefender koji je paranoično odbio svih 100% napada, Eset i Dr.Web s rezultatima na maksimalnim postavkama od 85% do 80%, kao i novajlija naših TrustPort testova. U "zlatnu skupinu" proizvoda prema rezultatima ovog testa bili su Comodo, Norton i Online Armor firewall koji su postigli više od 80% na standardnim i maksimalnim postavkama. Dosljedno visoke rezultate u testovima koji uključuju proaktivnu obranu pokazali su Kaspersky, Outpost, PC Tools.

    Međutim, u slučaju brojnih testiranih proizvoda, logika po kojoj se postavljaju standardne postavke nije jasna. Kao rezultat toga, razina zaštite za većinu korisnika koji su navikli koristiti zaštitu sa standardnim postavkama pokazuje se značajno podcijenjenom. To se prvenstveno odnosi na proizvode Bitdefender, Kaspersky, Eset i PC Tools.”

    Kartavenko Mikhail, voditelj laboratorija za ispitivanje:

    “Smatrajući ovaj test kao nastavak prethodnog sličnog testa, možemo identificirati nekoliko glavnih trendova i problema u radu vatrozida.

    Prvo, većina proizvoda je u prosjeku pokazala bolje rezultate nego prije 1,5 godine, ali to su uglavnom činili odbijanjem najjednostavnijih napada razine 1. Složeniji napadi "preteški" samo za ograničeni raspon proizvoda.

    Drugo, čak i ako je zaštita procesa od prekida (1 razina napada) funkcionirala, korisničko sučelje se ruši u mnogim proizvodima. To korisnika dovodi u neugodan položaj u kojem ne razumije radi li zaštita ili ne.

    Treće, postoji prilično velika praznina u radu vatrozida na standardnim i maksimalnim postavkama. Kao rezultat toga, prihvatljivu razinu zaštite često mogu postići samo iskusni korisnici koji znaju i mogu pravilno konfigurirati vatrozide.

    Tako je test otkrio “bolne” točke modernih vatrozida čije rješenje može poboljšati njihovu zaštitu.”

    Odjeljak se ažurira svakodnevno. Uvijek ažurne verzije najboljih besplatnih programa za svakodnevnu upotrebu u odjeljku Osnovni programi. Gotovo sve što trebate je tu svakodnevni rad. Počnite se ukidati piratske verzije u korist prikladnijih i funkcionalnijih besplatnih analoga. Ako još uvijek ne koristite naš chat, toplo vam savjetujemo da se s njime upoznate. Tamo ćete naći mnogo novih prijatelja. Štoviše, najbrži je i učinkovit način kontaktirajte administratore projekta. Odjeljak Antivirusna ažuriranja nastavlja s radom - uvijek ažurna besplatna ažuriranja za Dr Web i NOD. Niste imali vremena nešto pročitati? Cijeli sadržaj tickera možete pronaći na ovoj poveznici.

    Besplatno Comodo vatrozid. Testiranje, zaključci

    Comodo Firewall u akciji

    Nakon instaliranja i konfiguriranja Comodo se sakrio u tray i počeo me živcirati svojim pitanjima. Prvi dan sam se poigrao sa svim firewall i načinima proaktivne obrane i na kraju sam to utišao. Nakon pojave u njegovom sustavu nisu pronađene kočnice. Općenito, rad s Comodoovim vatrozidom bio je prilično jednostavan i praktičan. Sučelje glavnog prozora je vrlo jednostavno i informativno:


    Ali morao sam se naviknuti na kretanje kroz postavke vatrozida i proaktivnu zaštitu - nije uvijek moguće brzo pronaći pravu stavku. Mislim da će to proći s vremenom.






    Nekoliko dana nakon što sam instalirao Comodo Firewall, odlučio sam ga malo testirati.

    Test broj 1. Online testiranje

    Kada kliknete na gumb "Test", program pokušava uspostaviti vezu s poslužiteljem stranice.

    Budući da Comodo Firewall još ne poznaje ovaj uslužni program, prvi put kada je pokušao provaliti na Internet, uslijedila je neposredna reakcija proaktivne obrane i vatrozida:

    U oba sam slučaja kliknuo na blok i dobio potvrdu da je test prošao:

    Zatim sam preimenovao datoteku FireWallTest.exe u opera.exe i njome zamijenio standardnu ​​datoteku Opera. Tako sam pokušao prevariti Comodo Firewall, koji ovaj preglednik već dobro i stalno poznaje i automatski ga pušta na Internet. Comodo je na lansiranje "lažne" Opere iz Totala reagirao na sljedeći način:

    Nakon što sam dobio moje dopuštenje za jednokratno pokretanje, vatrozid me upozorio na pokušaj pristupa Operi na Internetu:

    Ispada da bilo koja aplikacija za koju već postoje pravila, ako se izvršna datoteka zamijeni, neće moći pristupiti internetu bez mog znanja. Čini se da je sve u redu, ali evo u čemu je stvar: boja gornjeg dijela prozorčića upozorenja ovisi o ozbiljnosti situacije. Ako Comodo ocijeni događaj kao kritičan, tada će boja biti crvena, ako je događaj manje opasan - žuta. U mom slučaju, Comodo je simuliranu situaciju smatrao ne osobito opasnom i zasvijetlio je “žuto”. Osim toga, umjesto teksta "izvršna datoteka opera.exe nije prepoznato" radije bih vidio da je "došlo do promjene u parametrima datoteke opera.exe". Stoga upozoravaju slične situacije kombajni iz Kasperskyja i Eseta, na primjer. Štoviše, korisnik vidi prozor alarma koji koristi crvenu boju, što vas odmah tjera da obratite pozornost na situaciju. A upozorenje iz Comodoa korisnik jednostavno može zanemariti zbog nedovoljnog naglaska na događaju koji je u tijeku.

    Zamjena datoteke Opera bila je samo dio mog lukavog plana. Sljedeća žrtva je bila Internet Explorer 6, koji je integriran u operativni sustav, te stoga iexplore.exe može se smatrati cjelovitom datotekom sustava. Kakvo je bilo moje iznenađenje kada sam u potpunoj tišini Comoda ugledao prozor o neuspjehu testa:

    Očito je stvoreno dodatno pravilo, odlučio sam i ušao u vatrozid i proaktivnu obrambenu politiku. Nakon što sam kopao oko 15 minuta, donio sam jedinu ispravnu odluku - ponovno instalirati Comodo. Tek što je rečeno nego učinjeno. Ostavivši zadane načine rada, ponovio sam eksperiment sa zamjenom iexplore.exe. Kada se pokrenula iz Total-a, proaktivna zaštita je radila, kao u slučaju Opere:

    Ovdje moramo napraviti malu lirsku digresiju. Činjenica je da prilikom zamjene IE izvršne datoteke, sustav vraća izvornu u roku od 4-8 sekundi. iexplore.exe. S tim u vezi, rezultati mog testa ovisili su o tome je li zamijenjena datoteka imala vremena zakucati na Internet ili ne.

    U slučaju kada uspijem dovršiti sve manipulacije prije vraćanja explore.exe, događa se sljedeće. Uz moje dopuštenje za jednokratno trčanje explore.exe, Total pokreće uslužni program FireWallTest, pritisnem "Test", Defens + proaktivna zaštita izdaje upozorenje:

    Ako dopustimo (kao eksperiment) - vatrozid radi:

    Imamo vremena kliknuti "Blokiraj" - test je prošao, uslužni program nije skliznuo na Internet. Ali ako iexplore.exe vraćen prije nego što je pritisnut gumb za zaključavanje - ništa ne ovisi o vašem izboru - uslužni program automatski pristupa Internetu u trenutku kada se izvorna datoteka vrati.

    Isto vrijedi i za rad proaktivne obrane: ako nemate vremena zapovjediti blokiranje prije obnove explore.exe- uslužni program automatski dobiva pristup internetu.

    Nakon što sam se dovoljno igrao s lažnim IE-om, sjetio sam se prvog neuspjeha testa, kada je Comodo šutio i pustio "lijevu" datoteku na Internet. Nakon ponovne instalacije Comodoa, stavio sam Defense+ i vatrozid u način učenja i pokrenuo IE. Nakon toga sam vratio zadane modove i ponovio test. Comodo opet šutke nije uspio...

    Test broj 3. Dvoboj

    Impresioniran rezultatima prethodnog testa, tražio sam dodatne mogućnosti testirati Comodo i konačno pronašao uslužni program AWFT.

    Ovaj program oponaša ponašanje trojanaca i sadrži niz od šest testova koji demonstriraju različite metode neovlaštenog pristupa mreži, zaobilazeći zaštitu vatrozida. Među tim testovima postoje i stare metode varanja vatrozida i modernije metode. Za svaki uspješno položen test vatrozidu se dodjeljuje određeni broj bodova. Ako test nije položen, bodovi se dodjeljuju AWFT-u. Maksimalan broj bodova je deset.

    Uslužni je program shareware, ograničen na 10 pokretanja. Na vrhu prozora programa nalaze se gumbi koji pokreću odgovarajuće testove, na dnu je mjesto gdje će se AWFT probiti i rezultat dvoboja između vatrozida i uslužnog programa. Gumb Reset Points koristi se za resetiranje akumuliranih bodova.


    Za svaki slučaj odlučio sam promijeniti adresu stranice u svoju.

    Testiranje se odvijalo uz uključeni Comodo Firewall i Defense+, Opera je pokrenuta i Avirin monitor isključen.

    U prvom testu korišten je trik s učitavanjem skrivene kopije preglednika i krpanjem memorije prije pokretanja.

    Kada sam kliknuo gumb za testiranje, pojavio se prozor s greškom:

    Nakon zatvaranja ovog prozora, Somodo je na test reagirao prozorom sa zahtjevom, kada je pritisnut gumb “Blokiraj”, AWFT je nakon malo razmišljanja dao prvu točku vatrozidu.

    Prema programerima uslužnog programa, test #2 je stari i dobro poznati trik. Comodo ponovno odgovara s prozorom zahtjeva i ponovno dobiva bod.

    Test #3 također koristi stari trik. Comodo ga samo tiho blokira, očito, trik je stvarno poznat.

    Test #4 sličan je prvom testu, pokreće skrivenu kopiju preglednika i krpi memoriju prije pokretanja. Vatrozid nije izdao nikakva upozorenja, ali je nakon kratke pauze zaradio još jedan bod.

    Tijekom petog i šestog testa treba se prebaciti na preglednik i malo surfati (upravo sam osvježio stranicu učitanu u pregledniku).

    U testu br. 5, uslužni program izvodi heurističku pretragu ovlaštenog softvera instaliranog na računalu (ili na mreži) koje ima pristup Internetu preko porta 80, zatim pokreće kopiju ovlaštenog programa i neposredno prije pokretanja krpa memoriju zauzima ovaj program (tj. AWFT se sam pokreće u memoriji dopuštenog programa). Comodo je tiho prošao test i za to dobio nevjerovatna 3 boda.

    Test #6 sličan je prethodnom petom testu. Ista tehnika se koristi i za heurističko traženje instaliranog softvera koji ima pravo izaći van preko porta 80. Sada je promijenjena samo metoda hakiranja - koristi se korisnički zahtjev. Uz to, AWFT pokušava staviti lijevu skrivenu alatnu traku u preglednik. Kada je Opera otvorena, pojavio se ovaj prozor:


    U trenutku kada sam potvrdio ovaj korisnički zahtjev, Comodo je izdao svoj zahtjev, uslužni program je ponovno blokiran, a vatrozid je dobio 3 boda kredita.

    Rezultat dvoboja je 10:0 u korist Comoda. Ponavljajući testove s otvorenim Internet Explorerom, dobio sam iste rezultate.


    Zaključak

    Unatoč nekom neugodnom okusu u duši nakon testiranja firewall-a, Comodo Internet Security ipak preporučujem za kućnu upotrebu, ali samo kao vatrozid. I ne slušajte one pametne ljude koji savjetuju onemogućavanje proaktivne obrane, ni u kojem slučaju! Samo uz korištenje Defense+ ovaj vatrozid zaista štiti vaše računalo. Ono što stvarno ne biste trebali koristiti je Comodoov antivirus. Ne samo da pristojno preskače, već ćete imati problema s ažuriranjem - ima vrlo glomazne baze podataka. Osim toga, pristojno utječe na performanse sustava. Upravo mi je odlično funkcionirao u paru Comodo Firewall i Avira Antivir Personal.

    Nisam pronašao nikakve kočnice i kvarove u sustavu tijekom rada vatrozida. Svoje mišljenje o rezultatima testiranja za sada ću zadržati za sebe, voljela bih poslušati vaše komentare.

    Dok sam pisao završni dio ovog članka, naišao sam na rezultate nedavnog testa vatrozida u laboratoriju Matousec. Comodo Internet Security bio je jedini vatrozid sa 100% ocjenom (pogledajte forum vatrozida). Pa, ja sam se odlučila... A ti?

    profesionalci (eksplicitno):
    besplatna distribucija,
    prisutnost vlastite baze podataka programa;
    prisutnost proaktivne zaštite (Obrana +);
    jednostavnost instalacije i početne konfiguracije;
    vrlo informativan i zgodan prozor sa sažetkom;

    profesionalci (sumnjivo):
    prisutnost nekoliko načina rada;

    kontra (očito):
    dosadan način instalacije;
    zamjena izvršne datoteke nije definirana proaktivnom obranom kao kritični događaj;

    kontra (sumnjivo):
    iskreno neuspješan antivirus.

    Ovaj drugi članak opisuje kako riješiti probleme vezane uz filtar paketa. Umjesto lijevanja gotov stol u obliku "problema" - "rješenja" daju se metode sustavnog pristupa za rješavanje nastalih problema.

    Ovaj drugi članak (u nizu od tri) opisuje kako riješiti probleme s filtrom paketa. Umjesto da se gotova tablica dovede u obliku "problema" - "rješenja", daju se metode sustavnog pristupa rješavanju nastalih problema.

    Uvod

    Filter paketa izvršava politiku filtriranja zaobilazeći skup pravila i, u skladu s tim, ili blokira ili prosljeđuje pakete. Poglavlje objašnjava kako provjeriti je li politika filtriranja ispravno implementirana i kako pronaći pogreške ako nije.

    Općenito, tijekom ovog poglavlja usporedit ćemo zadatak pisanja skupa pravila filtriranja s programiranjem. Ako nemate vještine programiranja, tada će vam se ova usporedba činiti prilično kompliciranom. Ali pisanje pravila samo po sebi ne zahtijeva diplomu informatike ili iskustvo u programiranju, zar ne?

    Odgovor je ne, vjerojatno vam to ne treba. Jezik koji se koristi za konfiguraciju filtera paketa napravljen je tako da izgleda kao ljudski jezici. Na primjer:

    blokirati sve

    onesvijestiti sve zadržati stanje

    proslijediti proto tcp na bilo koji port www keep state

    Zapravo, ne morate imati programera u blizini da biste razumjeli što ovaj skup radi ili čak, koristeći intuiciju, napisali sličnu politiku filtriranja. Čak postoji velika šansa da će skup pravila filtriranja kreiranih u ovom prividu izvesti radnje koje je njegov autor imao na umu.

    Nažalost, računala rade samo ono što od njih tražite, a ne ono što želite. Gore od toga, neće moći razlikovati željeno od stvarnog, ako postoji takva razlika. Dakle, ako računalo ne radi ispravno ono što želite, čak i ako mislite da ste jasno opisali upute, na vama je da pronađete razlike i promijenite upute. A budući da je to čest problem u programiranju, možemo vidjeti kako se programeri s njim nose. Ovdje se ispostavilo da su vještine i metode koje se koriste za testiranje i otklanjanje pogrešaka programa i pravila filtriranja vrlo slične. Pa ipak, ovdje vam nije potrebno poznavanje bilo kojeg programskog jezika da biste razumjeli implikacije za testiranje i otklanjanje pogrešaka.

    Dobra politika filtriranja.

    Politika filtera je neformalna specifikacija onoga što želimo od vatrozida. Naprotiv, skup pravila, implementacija specifikacije, je skup standardnih instrukcija, program koji izvršava stroj. U skladu s tim, da biste napisali program, morate odrediti što bi trebao raditi.

    Stoga je prvi korak u konfiguraciji vatrozida neformalno specificirati što treba postići. Koje veze treba blokirati ili dopustiti?

    Primjer bi bio:

    Postoje tri mreže koje moraju biti odvojene jedna od druge vatrozidom. Sve veze s jedne mreže na drugu prolaze kroz vatrozid. Vatrozid ima 3 sučelja, od kojih je svako povezano na odgovarajuću mrežu:

    $ext_if - na vanjsku mrežu.

    $dmz_if - DMZ s poslužiteljima.

    $lan_if - LAN s radnim stanicama.

    Hostovi na LAN-u moraju se slobodno povezati s bilo kojim hostom u DMZ-u ili vanjskoj mreži.

    Poslužitelji u DMZ-u moraju se slobodno povezati s hostovima na vanjskoj mreži. Vanjski mrežni domaćini mogu se povezati samo sa sljedećim poslužiteljima u DMZ-u:

    Web poslužitelj 10.1.1.1 port 80

    Poslužitelj pošte 10.2.2.2 port 25

    Sve ostale veze trebale bi biti zabranjene (na primjer, od strojeva na vanjskoj mreži do strojeva na LAN-u).

    Ova se politika izražava neformalno kako bi je svaki čitatelj mogao razumjeti. Trebao bi biti toliko specifičan da čitatelj može lako formulirati odgovore na pitanje poput 'Treba li se veza s hosta X na host Y proslijediti dolaznom (ili odlaznom) na sučelju Z?'. Ako razmišljate o slučajevima u kojima vaša polica ne ispunjava ovaj uvjet, onda on nije jasno definiran.

    "Maglovita" pravila poput "dopusti samo osnovne stvari" ili "blokirajte napade" moraju se pojasniti ili ih nećete moći provoditi ili testirati. Kao iu razvoju softvera, loše formalizirani zadaci rijetko dovode do opravdanih ili ispravnih implementacija. (“Zašto ne odeš i ne počneš pisati kod dok ja skužim što klijentu treba”).

    Skup pravila koji provodi politiku

    Skup pravila je napisan kao tekstualna datoteka koja sadrži rečenice na formalnom jeziku. Kao i izvor se obrađuje i prevodi u instrukcije strojnog koda od strane prevoditelja, skup pravila "izvor" obrađuje pfctl, a rezultat interpretira pf u kernelu.

    Kada izvorni kod krši pravila formalnog jezika, parser prijavljuje sintaksičku pogrešku i odbija daljnju obradu datoteke. Ova pogreška je pogreška u vremenu prevođenja i obično se brzo popravlja. Kada pfctl ne može raščlaniti vašu datoteku skupa pravila, ispisat će redak u kojem je pronašao grešku i više ili manje informativnu poruku koja kaže da nije mogla raščlaniti. Sve dok se cijela datoteka ne obradi bez jedna greška, pfctl neće promijeniti prethodni skup pravila u kernelu. A budući da datoteka sadrži jednu ili više sintaktičkih pogrešaka, neće postojati "program" koji pf može izvršiti.

    Druga vrsta pogreške naziva se "run-time errors" jer se javlja kada se sintaktički ispravan program uspješno prevede i izvrši. NA opći slučaj, u programskim jezicima, to se može dogoditi kada program izvrši dijeljenje s nulom, pokuša pristupiti nevažećim područjima memorije ili ponestane memorije. No, budući da skupovi pravila tek nejasno podsjećaju na funkcionalnost programskih jezika, većina ovih pogrešaka ne može se dogoditi tijekom primjene pravila, npr. pravila ne mogu uzrokovati tzv. "rušenje sustava", kao što to čine obični programi. Međutim, skup pravila može uzrokovati slične pogreške, u obliku blokiranja ili obrnuto, prosljeđivanje paketa koji ne odgovaraju politici. To se ponekad naziva i logička pogreška, pogreška koja ne uzrokuje iznimku i zaustavljanje, već jednostavno daje netočne rezultate.

    Dakle, prije nego što počnemo provjeravati koliko dobro vatrozid provodi našu sigurnosnu politiku, prvo moramo uspješno učitati skup pravila.

    Greške analizatora

    Pogreške parsera javljaju se kada pokušavate učitati popis pravila pomoću pfctl-a, na primjer:

    # pfctl-f/itd/pf.konf

    / itd/pf.conf:3:sintaksapogreška

    Ova poruka pokazuje da postoji sintaktička pogreška u retku 3 datoteke /etc/pf.conf i pfctl ne može učitati pravila. Set u kernelu se nije promijenio, ostaje isti kao prije pokušaja učitavanja novog.

    Postoji mnogo vrsta pogrešaka koje stvara pfctl. Da biste započeli s pfctl-om, samo ih trebate pažljivo pročitati. Moguće je da vam svi dijelovi poruke neće odmah otkriti svoje značenje, no potrebno ih je sve pročitati, jer. kasnije će biti lakše razumjeti što je pošlo po zlu. Ako poruka sadrži dio obrasca "ime datoteke:broj:tekst", ona se odnosi na redak s odgovarajućim brojem u navedenoj datoteci.

    Sljedeći korak je pogledati izlazni redak pomoću uređivača teksta (u vi možete skočiti na redak 3 upisivanjem 3G u načinu zvučnog signala), ili ovako:

    # mačka -n /etc/pf.conf

    1 int_if = "fxp 0"

    2 bloka sve

    3 se onesvijestiti na $int_if inet all kep state

    proslijediti inet na $int_if sve kep stanje

    Problem bi mogao biti obična tipkarska pogreška, kao u ovom slučaju ("čuvati" umjesto "čuvati"). Nakon popravka, pokušajte ponovno učitati datoteku:

    # pfctl-f/itd/pf.konf

    / itd/pf.conf:3:sintaksapogreška

    # glava -n 3 /etc/pf.conf | rep -n 1

    proslijediti inet na $int_if sve zadrži stanje

    Sada su sve ključne riječi točne, ali nakon detaljnijeg pregleda, primjećujemo da je položaj ključne riječi "inet" prije "on $int_if" pogrešan. Ovo ilustrira da isti redak može sadržavati više od jedne pogreške. Pfctl ispisuje poruku o prvoj pogrešci koju pronađe i prestaje raditi. Ako je isti broj retka generiran tijekom drugog pokretanja, onda u njemu još uvijek postoje pogreške ili prethodne nisu bile ispravno eliminirane.

    Netočno postavljene ključne riječi također su česta pogreška. To se može vidjeti usporedbom pravila s referentnom BNF sintaksom na kraju datoteke pomoći man pf.conf(5), koja sadrži:

    pf-rule= akcija [("in" | "out") ]

    [ "dnevnik" | "log-sve" ] [ "brzo" ]

    ["on" ifspec] [ruta] [af] [protospec]

    domaćini [filteropt-list]

    ifspec = ([ "!" ] naziv-sučelja) | "("popis sučelja")"

    af="inet" | "inet6"

    Što to znači ključna riječ"inet" mora slijediti "on $int_if"

    Popravimo to i pokušajmo ponovo:

    # pfctl-f/itd/pf.konf

    / itd/pf.conf:3:sintaksapogreška

    # glava -n 3 /etc/pf.conf | rep -n 1

    onesvijestiti se na $int_if inet sve zadržati stanje

    Sada nema očitih grešaka. Ali ne možemo vidjeti sve povezane detalje! Niz ovisi o makronaredbi $inf_if. Što se može pogrešno shvatiti?

    # pfctl -vf /etc/pf.conf

    int_if = "fxp 0"

    blok ispusti sve

    /etc/pf.conf:3: sintaksička pogreška

    Nakon što ispravite tipografsku pogrešku "fxp 0" u "fxp0", pokušajte ponovo:

    # pfctl-f/itd/pf.konf

    Nepostojanje poruka znači da je datoteka uspješno učitana.

    U nekim slučajevima, pfctl može proizvesti specifičnije poruke o pogrešci od samo "sintaktičke pogreške":

    # pfctl -f /etc/pf.conf

    /etc/pf.conf:3: port se odnosi samo na tcp/udp

    /etc/pf.conf:3: pravilo preskakanja zbog grešaka

    /etc/pf.conf:3: pravilo se proširuje bez valjane kombinacije

    # glava -n 3 /etc/pf.conf | rep -n 1

    onesvijestiti se na $int_if na port ssh zadržati stanje

    Prvi red poruke o pogrešci je najinformativniji od ostalih. U ovom slučaju, problem je u tome što pravilo, navodeći port, ne navodi protokol - tcp ili udp.

    U rijetkim slučajevima, pfctl se obeshrabruje zbog prisutnosti znakova koji se ne ispisuju ili nepotrebnih razmaka u datoteci, takve pogreške nije lako otkriti bez posebne obrade datoteke:

    # pfctl -f /etc/pf.conf

    /etc/pf.conf:2: razmak iza \

    /etc/pf.conf:2: sintaksička pogreška

    # cat -ent /etc/pf.conf

    1 blok sve$

    2 se onesvijestiti na gem0 od bilo kojeg do bilo kojeg \ $

    3 ^ Držimstanje$

    Problem je ovdje znak za razmak, nakon "obrnute kose crte", ali prije kraja drugog retka, označen znakom "$" u izlazu cat -e.

    Nakon što je skup pravila uspješno učitan, dobro je pogledati rezultat:

    $ cat /etc/pf.conf

    blokirati sve

    # prijelaz s bilo kojeg na bilo koji \

    prijeći s 10.1.2.3 na bilo koji

    $ pfctl -f /etc/pf.conf

    $ pfctl-sr

    blokpadsvi

    "Obrnuta kosa crta" na kraju retka komentara zapravo znači da će se red komentara nastaviti ispod.

    Proširivanje popisa zatvorenih u vitičaste zagrade () može proizvesti rezultat koji bi vas mogao iznenaditi, a ujedno pokazati skup pravila koje obrađuje analizator:

    $ cat /etc/pf.conf

    prijeđi s ( !10.1.2.3, !10.2.3.4 ) na bilo koji

    $ pfctl -nvf /etc/pf.conf

    pass inet from ! 10.1.2.3 na bilo koji

    pass inet from ! 10.2.3.4dobilo koji

    Kvaka je u tome što izraz "( !10.1.2.3, !10.2.3.4 )" neće značiti "sve adrese osim 10.1.2.3 i 10.2.3.4", a sam prošireni izraz znači podudaranje s bilo kojom mogućom adresom.

    Morate ponovno učitati svoj skup pravila nakon trajnih izmjena kako biste osigurali da ga pfctl može učitati i kada se stroj ponovno pokrene. Na OpenBSD-u, startup rc skripta u /etc/rc prvo učitava mali skup zadanih pravila koja blokira sav promet osim onoga što je potrebno tijekom faze pokretanja (kao što je dhcp ili ntp). Ako skripta ne uspije učitati pravi skup pravila iz /etc/pf.conf zbog sintaksičkih pogrešaka uvedenih prije ponovnog pokretanja stroja bez provjere, tada će zadani skup ostati aktivan. Srećom, u ovom skupu su dopuštene dolazne ssh veze, tako da se problem može riješiti na daljinu.

    Testiranje

    Budući da imamo iznimno precizno definiranu politiku, i skup pravila koja je moraju implementirati, tada će pojam testiranje u našem slučaju značiti usklađenost rezultirajućeg skupa s zadanom politikom.

    Postoje samo dva načina za pogrešnu primjenu pravila: blokiranje veza koje bi trebale biti dopuštene i obrnuto, prosljeđivanje onih veza koje bi trebale biti blokirane.

    Testiranje u općem slučaju podrazumijeva sustavni pristup uređenoj kreaciji razne vrste veze. Nije moguće testirati sve moguće kombinacije izvor/odredište i odgovarajuće portove na sučeljima, kao firewall se teoretski može sudariti veliki iznos takve kombinacije. Osiguravanje početne ispravnosti skupa pravila može se osigurati samo za vrlo jednostavnim slučajevima. U praksi, najbolje rješenje je kreirati popis testnih veza na temelju sigurnosne politike, tako da se utječe na svaku stavku politike. Dakle, za našu politiku primjera, popis testova bi bio:

    Veza s LAN-a na DMZ (treba preskočiti)

    s LAN-a na vanjsku mrežu (treba preskočiti)

    od DMZ-a do LAN-a (treba biti blokiran)

    s DMZ-a na vanjsku mrežu (treba preskočiti)

    s vanjske mreže u DMZ-u na 10.1.1.1 na portu 80 (treba preskočiti)

    s vanjske mreže na DMZ do 10.1.1.1 na portu 25 (treba biti blokiran)

    s vanjske mreže na DMZ do 10.2.2.2 na portu 80 (treba biti blokiran)

    s vanjske mreže u DMZ-u na 10.2.2.2 na portu 25 (treba preskočiti)

    s vanjske mreže na LAN (treba biti blokiran)

    Očekivani rezultat mora biti definiran u ovom popisu prije testiranja.

    Možda zvuči čudno, ali svrha svakog testa je pronaći greške u implementaciji skupa pravila vatrozida, a ne samo navesti njihovu odsutnost. A krajnji cilj procesa je izgraditi skup pravila bez grešaka, pa ako mislite da će vjerojatno postojati pogreške, bilo bi vam bolje da ih pronađete nego propustite. A ako preuzmete ulogu testera, morate usvojiti destruktivni stil razmišljanja i pokušati zaobići ograničenja vatrozida. I samo činjenica da se ograničenja ne mogu prekršiti postat će obrazložena potvrda da skup pravila ne sadrži pogreške.

    TCP i UDP veze mogu se provjeriti pomoću nc. nc se može koristiti i kao klijent i kao poslužitelj (koristeći opciju -l). A za ICMP zahtjeve i odgovore, najbolji klijent za provjeru će ping.

    Da biste provjerili je li veza blokirana, možete koristiti bilo koje sredstvo koje će pokušati stvoriti veze s poslužiteljem.

    Koristeći alate iz zbirke Ports, kao što je nmap, možete jednostavno skenirati mnoge portove, čak i na više hostova. Ako rezultati nisu sasvim jasni, slobodno bacite pogled na man stranicu. Na primjer, za TCP port, skener vraća 'nefiltriran' kada nmap primi RST od pf-a. Također, pf instaliran na istom stroju kao i skener može utjecati na ispravan rad nmapa.

    Sofisticiraniji alati za skeniranje mogu uključivati ​​objekte za generiranje fragmentiranih ili nevažećih IP paketa.

    Da biste provjerili da filtar prosljeđuje veze navedene u politici, najbolja metoda je provjera pomoću onih aplikacija koje će kasnije koristiti klijenti. Dakle, provjera prolaska http veza s različitih klijentskih računala web poslužitelja, kao i iz različitim preglednicima i uzorak razni sadržaji bilo bi bolje nego samo potvrditi uspostavu TCP sesije da nc djeluje kao backend. Različiti čimbenici, kao što je operativni sustav glavnog računala, također mogu uzrokovati pogreške - probleme sa skaliranjem TCP prozora ili TCP SACK odgovorima između određenih operacijskih sustava.

    Kada se položi sljedeća ispitna jedinica, njeni rezultati možda neće biti uvijek isti. Veza može biti prekinuta tijekom uspostavljanja veze, u slučaju da vatrozid vrati RST. Uspostavljanje veze može jednostavno isteći. Veza se može u potpunosti uspostaviti, raditi, ali nakon nekog vremena visi ili prekida. Veza se može održati, ali propusnost ili kašnjenje mogu biti drugačiji od očekivanog, veći ili manji (u slučaju da koristite AltQ za ograničavanje propusnosti).

    Kao očekivani rezultati, osim preskakanja/blokiranja veze, može se primijetiti i jesu li paketi evidentirani, kako se emitiraju, usmjeravaju, povećavaju li se potrebni brojači, ako je potrebno. Ako su vam ovi aspekti važni, onda ih također treba uključiti u metodologiju testiranja.

    Vaša politika može uključivati ​​zahtjeve u pogledu izvedbe, odgovora na preopterećenje, tolerancije grešaka. I mogu zahtijevati odvojene testove. Ako postavljate sustav otporan na greške pomoću CARP-a, vjerojatno ćete htjeti znati što se događa s raznim vrstama kvarova.

    Kada vidite da se rezultat razlikuje od onoga što ste očekivali, korak po korak zabilježite svoje korake tijekom testa, što ste očekivali, zašto ste to očekivali, dobiveni rezultat i kako se rezultat razlikuje od vaših očekivanja. Ponovite test da vidite je li situacija ponovljiva ili drugačija s vremena na vrijeme. Pokušajte promijeniti ulazne parametre testa (izvorna/odredišna adresa ili portovi).

    Od trenutka kada dobijete ponovljiv problem, morate početi s otklanjanjem pogrešaka kako biste saznali zašto stvari ne rade kako ste očekivali i kako sve "popraviti". S ovom postavkom morate promijeniti skup pravila i ponovno pokušati sve testove, uključujući i one koji nisu uzrokovali pogreške, jer biste promjenom pravila mogli nenamjerno utjecati na rad ispravno radnih dijelova skupa pravila.

    Isti princip vrijedi i za ostale promjene skupa. Ovaj formalni postupak provjere pomoći će da proces bude manje sklon uvođenju pogrešaka. Možda neće biti potrebno ponavljati cijeli postupak za male promjene, ali zbroj nekoliko malih promjena može utjecati na ukupni rezultat obrade skupa. Za upravljanje konfiguracijskom datotekom možete koristiti sustav kontrole verzija kao što je cvs. to će pomoći u istraživanju promjena koje su dovele do pogreške. Ako znate da se pogreška nije dogodila prije tjedan dana, ali se dogodila sada, pregledavajući sve napravljene promjene prošli tjedan pomoći će uočiti problem ili se barem vratiti na trenutak njegovog izostanka.

    Netrivijalni skupovi pravila mogu se smatrati programima, rijetko su savršeni u svojoj prvoj verziji i potrebno je vrijeme da se uvjerimo da nema grešaka. Međutim, za razliku od konvencionalnih programa, koje većina programera nikada ne smatra da nemaju bugove, skupovi pravila su još uvijek dovoljno jednostavni da budu bliski ovoj definiciji.

    Otklanjanje pogrešaka

    Pojam otklanjanje pogrešaka obično se odnosi na pronalaženje i popravljanje programskih pogrešaka u računalnim programima. Ili, u kontekstu skupova pravila vatrozida, pojam bi značio proces pronalaženja razloga zašto skup ne vraća željeni rezultat. Postoji nekoliko vrsta pogrešaka koje se mogu pojaviti u pravilima, međutim, metode za njihovo pronalaženje su slične programiranju.

    Prije nego počnete tražiti uzrok problema, morate jasno razumjeti bit ovog problema. Ako ste sami primijetili grešku tijekom testiranja, vrlo je jednostavno. Ali ako vam druga osoba prijavi bug, postavljanje jasnog cilja iz netočnog izvješća o grešci može biti teško. Najbolje mjesto za početak je da sami reproducirate pogrešku.

    Ne uvijek problemi s mrežom mogu biti uzrokovani filterom paketa. Prije nego što se usredotočite na otklanjanje pogrešaka u pf konfiguraciji, morate biti sigurni da je problem uzrokovan filterom paketa. To je lako učiniti, a također će vam uštedjeti vrijeme za rješavanje problema na nekom drugom mjestu. Samo isključite pf pomoću pfctl -d i provjerite hoće li se problem ponovno pojaviti. Ako je tako, omogućite pf pomoću pfctl -e i pogledajte što će se dogoditi. Ova metoda neće uspjeti u nekim slučajevima, na primjer ako se pf ne prevodi ispravno mrežne adrese(NAT), tada isključivanje pf-a očito se neće riješiti pogreške. Ali kad god je moguće, pokušajte se uvjeriti da je filtar paketa krivac.

    U skladu s tim, ako je problem u filteru paketa, prvo što trebate učiniti je provjeriti da li pf stvarno radi i da je ispravan skup pravila uspješno učitan:

    # pfctl -si | grep Status

    Status: Omogućeno 4 dana 13:47:32 Otklanjanje pogrešaka: Hitno

    # pfctl -sr

    brzo proći na lo0 sve

    brzo proći na enc0 all

    Otklanjanje pogrešaka po protokolima

    Sljedeći korak otklanjanja pogrešaka je odraz problema na određenim mrežnim vezama. Ako imate poruku: "trenutna razmjena poruka u aplikaciji X ne radi", morate saznati koje se mrežne veze koriste. Zaključak može biti u obliku "host A ne može uspostaviti vezu s hostom B na portu C". Ponekad je ovaj zadatak najteži, ali ako imate informacije o potrebnim vezama i znate da ih vatrozid neće propustiti, sve što trebate učiniti je promijeniti pravila kako biste riješili ovaj problem.

    Postoji nekoliko načina da saznate koje protokole ili veze aplikacija koristi. Tcpdump može prikazati pakete koji pristižu ili napuštaju i stvarno mrežno sučelje i virtualno sučelje kao što su pflog i pfsync. Možete odrediti izraz za filtriranje kako biste odredili koje će pakete prikazati i isključiti "šum" na strani mreže. Pokušajte instalirati Mrežna veza u željenoj aplikaciji i pogledajte pakete koji se šalju. Na primjer:

    # tcpdump -nvvvpi fxp0 tcp a ne port ssh i ne port smtp

    23:55:59.072513 10.1.2.3.65123 > 10.2.3.4.6667:S

    4093655771:4093655771(0) win 5840

    1039287798 0,nop,wscale 0> (DF)

    Ovo je TCP SYN paket, prvi paket TCP veze (TCP rukovanje) koji se uspostavlja.

    Pošiljatelj je 10.1.2.3 port 65123 (izgleda kao nasumični neprivilegirani port), a odredište je 10.2.3.4 port 6667. Detaljno objašnjenje izlaznog formata tcpdump možete pronaći na stranicama priručnika uslužnog programa. Tcpdump je najvažniji alat za otklanjanje pogrešaka povezanih s pf-om i vrlo je važno upoznati se s njim.

    Druga metoda je korištenje pf-ove funkcionalnosti zapisivanja. Pod pretpostavkom da koristite opciju 'log' na svim pravilima s 'blokiranjem', tada će se svi paketi blokirani od strane pf-a zabilježiti. Moguće je ukloniti opciju 'log' iz pravila koja se bave poznatim protokolima, t.j. samo oni paketi koji idu na nepoznate portove bit će zapisani. Pokušajte upotrijebiti aplikaciju koja ne može komunicirati i pogledajte pflog:

    # ifconfig pflog0 gore

    # tcpdump -nettti pflog0

    26. studenog 00:02:26.723219 pravilo 41/0 (utakmica): blokiraj na kue0:

    195.234.187.87.34482 > 62.65.145.30.6667: S 3537828346:3537828346(0) pobjeda

    16384 (DF)

    Ako koristite pflog, demon koji stalno sluša pflog0 i sprema informacije koje prima u /var/log/pflog, spremljene informacije mogu se vidjeti ovako:

    # tcpdump-nettr /var/log/pflog

    Kada prikazujete pakete pohranjene u pf-u, možete koristiti dodatne izraze za filtriranje, kao što je pregled paketa kojima je blokiran ulazak na wi0 sučelju:

    # tcpdump -netttr /var/log/pflog ulazni i akcijski blok i na wi0

    Neke protokole, kao što je FTP, nije lako pronaći jer ne koriste fiksne brojeve portova ili koriste više koegzistirajućih veza. Možda ih neće biti moguće proći kroz vatrozid bez otvaranja širokog raspona portova. Postoje rješenja slična ftp-proxy za pojedinačne protokole.

    Pravila za otklanjanje pogrešaka

    Ako vaš skup pravila blokira određeni protokol jer niste otvorili ispravan port, to je više problem u vremenu dizajna nego greška u pravilima. Ali što ako vidite da je veza blokirana za koju imate pravilo koje joj dopušta da prođe?

    Na primjer, vaš skup sadrži pravilo

    blokiraj u return-rst na $ext_if proto tcp s bilo kojeg na $ext_if port ssh

    Ali kada se pokušate povezati s TCP port 22, veza je prihvaćena! Čini se da vatrozid ignorira vaše pravilo. Kao i za slagalice, postoji jednostavno logično i obično trivijalno objašnjenje za ove slučajeve prvih nekoliko puta kada ih sretnete.

    Prvo, trebali biste provjeriti sve prethodno spomenute korake. Na primjer, recimo da je vatrozid pokrenut i da sadrži gornje pravilo. Malo je vjerojatno da su naše prethodne zabrinutosti istinite, ali je lako provjeriti:

    # pfctl -si | grep Status

    Status: Omogućeno 4 dana 14:03:13 Otklanjanje pogrešaka: Hitno

    # pfctl -gsr | grep "port=ssh"

    @14 blok return-rst in na kue0 inet proto tcp s bilo kojeg na 62.65.145.30 port = ssh

    Sljedeće što imamo je da se TCP veze prihvaćaju na portu 22 na kue0. Možda mislite da je to već očito, ali bilo bi korisno provjeriti. Pokrenite tcpdump:

    # tcpdump -nvvvi kue0 tcp i port 22 i dst 62.65.145.30

    Sada ponovno pokušajte SSH vezu. Trebali biste vidjeti pakete iz vaše veze u tcpdump izlazu. Možda ih nećete moći vidjeti, što bi moglo biti zato što veza zapravo ne prolazi kroz kue0, već kroz drugo sučelje, što bi objasnilo zašto se pravilo ne aktivira. Ili se možda povezujete na drugu adresu. Ukratko, ako ne vidite ssh pakete, onda ih ni pf neće vidjeti i vjerojatno ih ne može blokirati pomoću pravila danog u našem problemu.

    Ali ako vidite pakete s tcpdumpom, pf će i njih "vidjeti" i filtrirati. Sljedeća pretpostavka je da pravilo blokiranja ne bi trebalo biti samo prisutno u skupu (što smo već shvatili), već bi trebalo biti posljednje podudarno pravilo za tražene pakete. Ako ovo nije posljednje pravilo, očito se prema ovome ne donosi odluka o kašnjenju paketa.

    U kojim slučajevima pravilo možda nije posljednje podudarno pravilo? Postoje tri moguća razloga:

    A) pravilo ne funkcionira, jer pregled pravila ne doseže željeno.

    Prethodno prisutno pravilo također pokreće i uzrokuje da se izvršenje prekine s 'brzo' opcijom;

    B) pravilo je obrađeno, ali pravilo ne funkcionira zbog nepodudaranja pojedinačnih kriterija.

    C) izvršava se obrada pravila, pravilo se pokreće, ali se obrada nastavlja i naknadna pravila također se aktiviraju za paket.

    Da biste isključili ova tri slučaja, možete vizualizirati obradu hipotetičkog TCP paketa koji stiže na sučelje kue0 i port 22 gledajući učitani skup pravila. Odaberite blok za otklanjanje pogrešaka. Počnite zaobilaziti s prvim pravilom. Poklapa li se? Ako da, označite. Ima li 'brzo' opciju? Ako je tako, onda zaustavljamo rundu. Ako ne, nastavite s sljedeće pravilo. Ponavljajte test dok se ne pronađe podudaranje s opcijom 'brzo' ili dok se ne postigne kraj skupa pravila. Koje se pravilo posljednje podudaralo? Ako nije pravilo broj 14, pronašli ste objašnjenje za problem.

    Ručno zaobilaženje pravila može se činiti smiješnim, međutim, s dovoljno iskustva, to se može učiniti prilično brzo i s visokim stupnjem pouzdanosti. Ako je skup dovoljno velik, možete ga privremeno smanjiti. Spremite kopiju pravog popisa pravila i izbrišite one unose za koje mislite da neće utjecati na rezultat. Preuzmite ovaj set i ponovno testirajte. Ako je veza sada blokirana, tada su pravila koja su se činila nepovezana s paketima koje tražite odgovorna za slučajeve A ili B. Dodajte pravila jedno po jedno, ponavljajući test dok ne pronađete ono pravo. Ako je veza i dalje dopuštena nakon uklanjanja pravila koja ne utječu na nju, ponovite smanjeni skup mentalnog obilaska.

    Druga metoda je korištenje pf-ove sposobnosti zapisivanja za identifikaciju slučajeva A ili C. Dodajte 'log' svim pravilima s 'prođi brzo' prije 14. pravila. Dodajte "log" svim pravilima s "pass" nakon 14. pravila. Pokrenite tcpdump na sučelju pflog0 i uspostavite ssh vezu. Vidjet ćete koja pravila, osim 14., posljednja rade na vašim paketima. Ako u dnevniku nema ništa, javlja se slučaj B.

    Praćenje veze vatrozida

    Kada veza prođe kroz vatrozid, paketi stižu na jedno sučelje i prenose se kroz drugo. Odgovori dolaze na drugo sučelje, a idu na prvo. Veze stoga mogu propasti u svakom od ova četiri slučaja.

    Prvo morate shvatiti koji je od četiri slučaja problem. Ako pokušate uspostaviti vezu, trebali biste vidjeti TCP SYN paket na prvom sučelju koristeći tcpdump. Također biste trebali vidjeti isti TCP SYN paket koji izlazi iz drugog sučelja. Ako ga ne vidite, onda zaključujemo da se pf blokira dolazni paket na prvom sučelju ili odlazni na drugom.

    Ako SYN nije blokiran, trebali biste vidjeti SYN+ACK koji dolazi na drugom sučelju i izlazi na prvom. Ako nije, pf blokira SYN+ACK na nekom sučelju.

    Dodajte opciju 'log' pravilima koja bi trebala dopustiti SYN i SYN+ACK na oba sučelja, kao i pravilima koja bi ih trebala blokirati. Pokušajte ponovo povezati i provjeriti pflog. Trebalo bi pojasniti u kojem slučaju dolazi do blokiranja i po kojem pravilu.

    Otklanjanje pogrešaka stanja veze

    Najčešći razlog za blokiranje pf paketa je taj što u skupu postoji prekomjerno pravilo blokiranja. Odgovarajuće pravilo koje se pokreće na posljednjoj utakmici može se pronaći dodavanjem opcije 'log' svim potencijalno utječućim pravilima i slušanjem pflog sučelja.

    U manjem broju slučajeva događa se da pf "tiho" ispušta pakete na temelju nepravila, a ovdje dodavanje 'log' svim pravilima neće rezultirati da ispušteni paketi uđu u pflog. Često je paket gotovo, ali ne u potpunosti, državni unos.

    Zapamtite da za svaki paket koji obrađuje, filtar paketa skenira tablicu stanja. Ako se pronađe odgovarajući unos, paket se odmah prosljeđuje bez da se skup pravila obradi na samom sebi.

    Unos u tablici stanja sadrži informacije vezane za jednu vezu.

    Svaki unos ima jedinstveni ključ. Ovaj ključ se sastoji od nekoliko vrijednosti koje ograničavaju konstantu tijekom cijelog životnog vijeka veze. Evo ih:

    • Vrsta adrese (Ipv4 ili Ipv6)
    • Izvorna adresa
    • Adresa primatelja
    • Protokol (TCP/UDP)
    • Izvorni port
    • Prijamnik

    Ovaj ključ se koristi za sve pakete koji se odnose na istu vezu i pakete različitih spojeva uvijek će imati različite ključeve.

    Kada opcija 'zadrži stanje' iz pravila stvori unos u tablici stanja, unos veze se pohranjuje pomoću ključa te veze. Važno ograničenje za tablicu stanja je da svi ključevi moraju biti jedinstveni. Oni. ne mogu postojati dva zapisa s istim ključevima.

    Možda nije odmah očito da ista dva hosta ne mogu uspostaviti više koegzistirajućih veza koristeći iste adrese, protokole i portove, ali je temeljno svojstvo i TCP i UDP. Zapravo, TCP/IP stogovi mogu samo povezati pojedinačne pakete sa svojim utičnicama vršeći odabir na temelju adresa i portova.

    Čak i ako je veza zatvorena, isti par adresa i portova ne može se odmah ponovno koristiti. Mrežna oprema može kasnije dostaviti ponovno poslane pakete, a ako ih TCP/IP stog prijamnika zamijeni s paketima novostvorene veze, to će ometati ili čak prekinuti novu vezu. Iz tog razloga, oba domaćina moraju čekati određeno vrijeme zvano 2MSL ("dvostruko maksimalno trajanje segmenta") prije nego što mogu ponovno koristiti iste adrese i portove za novu vezu.

    Ovo svojstvo možete promatrati ručnim uspostavljanjem više veza s istim hostom. Na primjer, imati web-poslužitelj koji radi na 10.1.1.1 i portu 80, te se dvaput povezati od 10.2.2.2. koristeći nc:

    $ nc -v 10.1.1.1 80 & nc -v 10.1.1.1 80

    Povezivanje s 10.1.1.1 80 portom uspjelo!

    Dok su veze otvorene, možete prikazati informacije o tim vezama koristeći netstat na klijentu ili poslužitelju:

    $ netstat -n | grep 10.1.1.1.80

    tcp 0 0 10.2.2.6.28054 10.1.1.1.80 OSNOVAN

    tcp 0 0 10.2.2.6.43204 10.1.1.1.80 OSNOVAN

    Kao što možete vidjeti, klijent je odabrao dva različita (slučajna) izvorna porta, tako da to ne krši ključne zahtjeve jedinstvenosti.

    Možete reći nc da koristi određeni izvorni port s opcijom -p:

    $ nc -v -p 31234 10.1.1.1 80 & nc -v -p 31234 10.1.1.1 80

    Povezivanje s 10.1.1.1 80 portom uspjelo!

    nc: vezanje nije uspjelo: adresa se već koristi

    Klijentov TCP/IP stog spriječio je kršenja jedinstvenosti ključa. Neke rijetke i pogrešne implementacije TCP/IP stogova nisu slijedile ovo pravilo, pa će stoga, kao što ćemo uskoro vidjeti, pf blokirati njihove veze ako se naruši jedinstvenost ključeva.

    Vratimo se na točku gdje pf postavlja upit tablici stanja, u vrijeme kada se paket počinje filtrirati. Zahtjev ima dva koraka. Prvi je upit napravljen kako bi se tražio unos u tablici unosa s ključem koji odgovara protokolu, adresama i portu paketa. Tražit će se paketi koji idu u bilo kojem smjeru. Pretpostavimo da je paket ispod stvorio unos u tablici stanja:

    dolazakTCPod 10.2.2.2:28054do 10.1.1.1:80

    Upit tablice će pronaći sljedeće unose u tablici stanja:

    dolazni TCP od 10.2.2.2:28054 do 10.1.1.1:80

    odlazni TCP od 10.1.1.1:80 do 10.2.2.2:28054

    Unos u tablici uključuje informacije o smjeru (ulazni ili odlazni) prvog paketa koji je stvorio unos. Na primjer, sljedeći unosi neće uzrokovati podudaranje:

    odlazniTCPod 10.2.2.2:28054do 10.1.1.1:80

    dolazakTCPod 10.1.1.1:80do 10.2.2.2:28054

    Razlog za ova ograničenja nije očit, ali je prilično jednostavan. Zamislite da imate samo jedno sučelje na 10.1.1.1, gdje web poslužitelj sluša port 80. Kada se klijent na 10.2.2.2 poveže pomoću nasumično odabranog odlaznog porta 28054, prvi paket veze stiže na vaše sučelje i sve Vaši odlazni odgovori moraju ići s 10.1.1.1:80 na 10.2.2.2:28054. Nećete proslijediti odlazne pakete s 10.2.2.2:28054 na 10.1.1.1:80, jer takvi paketi nemaju smisla.

    Ako je vaš vatrozid konfiguriran za dva sučelja, onda gledajući pakete koji prolaze kroz njega, vidjet ćete da svaki paket koji stigne na prvo sučelje izlazi i prolazi kroz drugo. Ako kreirate unos stanja u kojem početni paket stiže na prvo sučelje, taj će unos spriječiti da isti paket napusti drugo sučelje jer je u krivom smjeru.

    Kada pokušaj pronalaženja paketa među unosima u tablici stanja ne uspije, prelazi se na popis pravila filtriranja. Morate posebno dopustiti da paket prođe kroz drugo sučelje s posebnim pravilom. Vjerojatno koristite 'zadrži stanje' u ovom pravilu tako da drugi unos u tablici stanja također pokriva cijelu vezu na drugom sučelju.

    Možda se pitate kako je moguće stvoriti drugi zapis u tablici kada smo upravo objasnili da zapisi moraju imati jedinstvene ključeve. Ovdje je objašnjenje da zapis također sadrži informaciju o smjeru veze, a kombinacija toga s ostatkom podataka mora biti jedinstvena.

    Sada također možemo objasniti razliku između labave veze i veze vezane za sučelje. Prema zadanim postavkama, pf stvara unose koji nisu vezani ni za jedno sučelje. Dakle, ako dopustite veze na jednom sučelju, paketi koji se odnose na vezu i koji odgovaraju unosu u tablici (uključujući informacije o smjeru paketa!) prolaze kroz bilo koje sučelje. U jednostavnim instalacijama sa statičkim usmjeravanjem, ovo su više teoretski izračuni. U principu, ne biste trebali vidjeti pakete iz iste veze kako stižu na više sučelja i pakete odgovora koji također odlaze na više sučelja. Međutim, s dinamičkim usmjeravanjem to je moguće. Unose stanja možete povezati s određenim sučeljem koristeći globalnu postavku 'set state-policy if-bound' ili opciju po pravilu 'zadrži stanje (ako je vezano)'. To osigurava da će se paketi podudarati samo s unosima iz sučelja koje je stvorilo te unose.

    Ako se koriste sučelja za tunele, tada ista veza prolazi kroz vatrozid nekoliko puta. Na primjer, prvi paket veze može prvo proći kroz sučelje A, zatim kroz B, zatim C i konačno nas ostaviti kroz sučelje D. Obično će paketi biti kapsulirani na sučeljima A i D i dekapsulirani na B i C, tako da pf vidi pakete različitih protokola i možete stvoriti 4 različita unosa u tablici stanja. Bez enkapsulacije, paket će biti nepromijenjen na sva četiri sučelja i nećete moći koristiti neke značajke poput prijevoda adrese ili modulacije tcp sekvencijalnog broja, jer će to rezultirati pojavljivanjem sukobljenih ključeva u tablici stanja. Sve dok ne budete imali potpunu instalaciju koja uključuje sučelja s tuneliranjem i otklonjenim pogreškama poput "pf: src_tree insert failed", nećete moći smatrati svoju instalaciju dovoljno uspješnom. Vratimo se zahtjevu na tablicu stanja koja se pravi za svaki paket prije provjere pravila. Upit mora vratiti jedan zapis s odgovarajući ključ ili ne vratiti ništa. Ako upit ne vrati ništa, popis pravila se zaobilazi.

    Ako je unos pronađen, drugi korak za TCP pakete je provjera broja sekvence prije nego što se tretiraju kao da pripadaju određenoj vezi i podvrgnu filtriranju.

    Tamo je veliki broj TCP napadi u kojima napadač pokušava kontrolirati vezu između dva hosta. U većini slučajeva, napadač nije na putu ruta između hostova, pa stoga ne može slušati legitimne pakete koje prosljeđuju hostovi. Međutim, može slati pakete bilo kojem od hosta koji oponašaju pakete njegovog sugovornika, lažiranjem („spoofing“) – krivotvorenjem adrese pošiljatelja. Cilj napadača može biti spriječiti mogućnost uspostavljanja veze između hostova ili prekinuti već uspostavljene veze (prouzročiti uskraćivanje usluge) ili stvoriti zlonamjerno preuzimanje na vezama.

    Za uspješan napad, napadač mora ispravno "pogoditi" nekoliko parametara veze, kao što su adresa/port izvora i odredišta. A za široko korištene protokole to možda i nije tako teško kao što se čini. Ako napadač zna adrese domaćina i jedan od portova (budući da je riječ o uobičajenom servisu), trebat će samo "pogoditi" jedan port. Čak i ako klijent koristi istinski nasumični izvorni port (što nije uvijek točno), napadač treba samo isprobati 65536 portova u kratkom vremenu. (U većini slučajeva, čak (65536-1024) portovi, tj. samo neprivilegirani portovi - napomena prevoditelja))

    Ali ono što je napadaču doista teško pogoditi je točan redni broj (i njegova potvrda). Ako oba domaćina izaberu početni broj redni broj nasumično (ili koristite modulaciju slijednog broja za hostove koji imaju "slabi" generator ISN (početni broj sekvence)), tada napadač neće moći pokupiti odgovarajuću vrijednost u pravom trenutku veze.

    Tijekom postojanja valjane TCP veze, redni brojevi (i potvrde) za pojedinačne pakete mijenjaju se prema određenim pravilima.

    Na primjer, ako domaćin pošalje neki segment podataka, a njegov primatelj potvrdi primitak, ne bi trebao postojati razlog zašto bi pošiljatelj trebao ponovno poslati podatke segmenta. Ali, zapravo, pokušaj prepisivanja dijelova informacija koje je domaćin već primio nije kršenje TCP protokol, iako može biti oblik napada.

    pf koristi pravila za određivanje najmanjeg raspona za legitimne brojeve sekvence. Općenito, pf može točno odrediti autentičnost samo 30.000 od 4294967296 mogući brojevi slijed u bilo kojem trenutku tijekom veze. Samo ako se redni broj i potvrda nalaze u ovom prozoru, uvjerit će se da je paket legitiman i pustiti ga da prođe.

    Ako se tijekom upita prema tablici stanja pronađe prikladan ulaz, na sljedeći korak redni brojevi paketa pohranjenih u tablici provjeravaju se za raspon moguće vrijednosti. Ako usporedba ne uspije, pf će generirati poruku "LOŠE stanje" i odbaciti paket bez procjene skupa pravila. Dva su razloga zašto se podudaranje pravila možda neće dogoditi: gotovo sigurno će biti pogreška preskakanje paketa, jer ako će izračun skupa dovesti do pogađanja opcije u pravilu "čuvati stanje" i pf neće moći odlučivati ​​i stvarati novi rekord jer će uzrokovati pojavljivanje sukobljenih ključeva u tablici.

    Da biste vidjeli i zabilježili poruke "BAD state", morate omogućiti način otklanjanja pogrešaka pomoću naredbe:

    $ pfctl-xm

    Poruke za otklanjanje pogrešaka se prema zadanim postavkama zapisuju na konzolu, a syslogd ih također zapisuje u /var/log/messages. Potražite postove koji počinju s "pf":

    pf:lošedržava:TCP 192.168.1.10:20 192.168.1.10:20 192.168.1.200:64828

    [ lo=1185380879visoka=1185380879pobjeda=33304modulator=0wscale=1]

    4:4 A seq=1185380879 ack=1046638749 len=1448 ackskew=0 pkts=940:631

    dir=out,fwd

    pf: Neuspjeh stanja na: 1 |

    Ove poruke uvijek dolaze u paru. Prva poruka prikazuje unos u tablici stanja u trenutku kada je paket blokiran i redni broj paketa koji je rezultirao pogreškom. Drugi unos prikazuje uvjete koji su prekršeni.

    Na kraju prve poruke vidjet ćete je li kreiran unos statusa za dolazni (dir=in) ili odlazni (dir=out) paket i je li blokirani paket otišao u istom smjeru (dir=,fwd) ili suprotnog smjera (dir=,rev ) smjera.

    Unos u tablici sadrži tri adrese: parove portova, od kojih su dva uvijek međusobno jednaka, ako veza nije prošla nat, rdr ili bnat prijevod. Za odlazne veze izvor se prikazuje s lijeve strane, a odredište paketa s desne strane. Ako je a odlazna veza omogućuje prijevod izvorne adrese, par u sredini prikazuje izvor nakon prijevoda. Za dolazne veze izvor je na desnoj strani izlaza, a adresa odredišta je u sredini. Ako dolazna veza prolazi kroz prijevod odredišne ​​adrese, par ip/port s lijeve strane prikazuje odredište nakon prijevoda. Ovaj format odgovara izlazu pfctl -ss, s jedinom razlikom što pfctl pokazuje smjer paketa pomoću strelica.

    U izlazu možete vidjeti trenutne sekvence hostova u uglastim zagradama. Dakle, vrijednost "4:4" znači da je veza uspostavljena u potpunosti (manje vrijednosti vjerojatnije su u fazi uspostavljanja veze, veće - do zatvaranja veze)."A" znači da je blokirani paket imao postavljenu ACK zastavicu (isto kao u izlazu zastavice tcpdump), nakon čega slijede vrijednosti brojeva sekvence (seq=) i (ack=) u blokiranim paketima i duljina korisnog opterećenja paketa - duljina podataka (len =). askskew je dio internog prikaza podataka u tablici i koristi se samo za vrijednosti različite od nule.

    Unos "pkts=930:631" znači da je upario 940 paketa koji idu u istom smjeru kao i onaj koji je uzrokovao stvaranje ovog unosa i 631 paket u suprotnom smjeru. Ovi brojači će biti posebno korisni pri rješavanju problema tijekom faze uspostavljanja veze, ako je jedan od njih nula, to bi bilo suprotno vašim očekivanjima da se navedeni unos podudara s paketima koji putuju u oba smjera.

    Sljedeća poruka će sadržavati popis od jedne ili više znamenki. Svaka znamenka predstavlja provjeru na kojoj je došlo do pogreške:

    1. veličina prozora paketa premašuje maksimalnu veličinu primatelja (seq + len > high)
    2. paket sadrži već prenesene podatke (sl< lo - win)
    3. ackskew je manji od minimalne vrijednosti
    4. ackskew je veći od maksimalne vrijednosti
    5. isto kao (1) ali s razlikom (seq + len > high + win)
    6. isto kao u (2), ali (sl< lo - maximum win)

    Na sreću, poruke "LOŠE stanje" ne odnose se na stvarni svakodnevni promet, a provjerom pf rednog broja izbjegava se većina anomalija. Ako vidite da se ove poruke povremeno pojavljuju i ne primijetite veliki broj veza koje vise, možete ih jednostavno zanemariti. Na Internetu se izvodi mnogo implementacija TCP/IP-a, a neke od njih ponekad mogu generirati pogrešne pakete.

    Međutim, ova se klasa problema može lako dijagnosticirati pojavom poruka "BAD state" koje se pojavljuju samo u takvim slučajevima.

    Stvorite državne zapiseTCP iznad početnogSYN na paket.

    U idealnom slučaju, zapisi o stanju trebali bi se kreirati kada se pojavi prvi SYN paket.

    Možete prisiliti korištenje ovog pravila koristeći načelo:

    "Koristite opcije "zastavice S/SA" u svim pravilima "pass proto tcp keep state""

    Samo (i jedini) početni SYN paketi imaju postavljenu SYN zastavicu i prikupljen ACK. Kada je primjena opcije "čuvaj stanje" vezana samo za početne SYN pakete, samo će ti paketi stvoriti unose u tablici stanja. Stoga će svaki postojeći unos u tablici stanja biti izveden iz početnog SYN paketa.

    Razlog za stvaranje unosa samo za početne pakete je TCP proširenje koje se naziva "skaliranje prozora" definirano u RFC1323. Polje TCP zaglavlja koje se koristi za najavu veličine primljenih prozora premalo je za današnje veze velike brzine. Moderne implementacije TCP/IP radije koriste veće veličine prozora nego što mogu stati u postojeće polje. Skaliranje veličine prozora znači da se sve veličine prozora poznate s odredišnog hosta moraju pomnožiti s određenom vrijednošću koju odredi odredište, a ne uzeti same. Kako bi ova shema funkcionirala, oba domaćina moraju podržavati proširenje i međusobno ukazati na svoju sposobnost da ga implementiraju tijekom uspostavljanja veze (“rukovanje”) koristeći TCP opcije. Ove su opcije prisutne samo u početnim SYN i SYN+ACK paketima. I samo ako svaki od ovih paketa sadrži opciju, nexus će biti uspješan i veličina prozora svih sljedećih paketa bit će pomnožena s faktorom.

    Ako pf nije bio "svjestan" skaliranja prozora koji se koristi, dostavljena vrijednost bila bi uzeta bez faktora, a izračun veličina prozora za prihvatljive vrijednosti rednog broja bio bi netočan. Obično domaćini pružaju male veličine prozora na početku veze i povećavaju ih tijekom veze. Nesvjestan postojanja faktora promjene veličine prozora, pf će u nekom trenutku početi blokirati pakete, jer će pretpostaviti da jedan od hostova pokušava zaobići maksimalnu veličinu prozora koju daje "peer". Učinci ovoga mogu biti manje ili više vidljivi. Ponekad će domaćini na gubitak paketa odgovoriti prelaskom na tzv. "način oporavka od gubitka" i oglašavat će manju veličinu prozora. Nakon što pf ponovno odašilje pakete ispuštene prvi put, veličine prozora će se nastaviti povećavati, sve do točke u kojoj ih pf ponovno počne blokirati. Vanjska manifestacija može biti privremeni prekid veza i loša izvedba. Moguće također potpuno zamrzavanje ili resetiranje veze do isteka vremena.

    Ali pf zna za skaliranje prozora i podržava ga. Međutim, preduvjet za kreiranje unosa u tablici stanja za prve SYN pakete je da pf može pridružiti prva dva paketa veze s unosom u tablici. A budući da se podudaranje faktora pune veličine prozora događa samo u ova prva dva paketa, ne postoji pouzdan način za određivanje tih faktora nakon pregovaranja veze.

    U prošlosti, skaliranje prozora nije bilo široko korišteno, ali to se brzo mijenja. Tek nedavno je Linux ovu opciju omogućio prema zadanim postavkama. Ako imate problema s visećim vezama, osobito s nekim kombinacijama hostova, i vidite poruke "LOŠE stanje" koje se odnose na te veze, provjerite stvarate li unose tablice stanja na prvim paketima veze.

    Možete odrediti koristi li pf opciju skaliranja za vezu iz pfctl izlaza:

    $ pfctl -vss

    kue0 tcp 10.1.2.3:10604 -> 10.2.3.4:80 UTVRĐEN: UTVRĐEN

    wscale 0wscale 1

    Ako je u drugom retku ispisan unos "wscale x" (čak i ako je x nula), pf zna da veza koristi skaliranje.

    Još jedna jednostavna metoda za rješavanje problema sa skaliranjem je privremeno isključiti podršku za skaliranje i ponoviti situaciju. U OpenBSD-u, korištenje skaliranja može se kontrolirati opcijom sysctl:

    $ sysctlneto.inet.tcp.rfc1323

    neto.inet.tcp.rfc1323=1

    $ sysctl-wsysctlneto.inet.tcp.rfc1323=0

    neto.inet.tcp.rfc1323: 1 -> 0

    Slični problemi se pojavljuju kada kreirate unose u tablici stanja za pakete koji nisu početni SYN i koristite opciju ili prijevod "moulate state". U oba slučaja prijevod se vrši na početku veze. Ako prvi paket nije preveden, prosljeđivanje sljedećih paketa obično obeshrabruje primatelja i uzrokuje blokiranje poslanih odgovora od strane pf s porukom "LOŠE stanje".

    Vrhunski povezani članci