Metodologija ispitivanja

Testovi su sprovedeni na eksperimentalnom računaru sa licenciranim Windows XP sa instaliranim SP1 (testovi su sprovedeni pod idealizovanim uslovima - "operativni sistem + zaštitni zid" kako bi se isključio uticaj drugih programa na čistoću eksperimenta). Uslužni program APS korišten je kao pokazatelj uspješnog pristupa uslugama. Kao sredstva spoljnog uticaja korišćeni su:

• XSpider 6.5 i 7.0 skener
• Retina mrežni sigurnosni skener 4.9
• nekoliko skenera mog dizajna.

Osim toga, korišten je CommView 4.1 sniffer (kao sredstvo za praćenje mrežni promet i kao pomoćni program za generisanje i slanje paketa sa različitim strukturnim nepravilnostima). tzv. flooderi uobičajenih tipova, uslužni programi za imitiranje trojanaca.

Testni računar je koristio IE 6 kao sredstvo za pristup mreži i Internetu, Outlook Express 6, TheBat 1.60, MSN Messanger 6.1. Pored njih, simulatori Trojanaca i pravih Trojanaca / Backdoor programa iz moje kolekcije (posebno Backdoor.Antilam, Backdoor.AutoSpy, Backdoor.Death, Backdoor.SubSeven, Backdoor.Netbus, Backdoor.BO2K), mrežni / mail virusi ( I-Worm.Badtrans, I-Worm.NetSky, I-Worm.Sircam, I-Worm.Mydoom, I-Worm.MSBlast), TrojanDownloader Trojan preuzimači (posebno TrojanDownloader.IstBar) i komponente SpyWare. Glavni zadatak testova bio je pokušati sagledati Firewall očima korisnika, uočiti njegove snage i slabosti iz mog ugla.

Kerio Technologies WinRoute Pro v4.2.5

Instalacija i deinstalacija:
Ide bez problema.
Instalacija sa zadanim postavkama, bez pravila - radi samo NAT. Umrežavanje - nema problema, rezultati skeniranja - APS ne prikazuje status alarma, skener misli da su svi portovi zatvoreni. Winroute sama po sebi ne generiše alarme i ne identifikuje vizuelno činjenicu skeniranja.

Outpost Firewall Pro 2.1 Build 303.4009 (314)

Instalacija i deinstalacija:
Instalacija pod XP radi bez problema, mod učenja je omogućen pri pokretanju.

ZoneLabs ZoneAlarm Pro s web filtriranjem 4.5.594.000 - Personal Firewall

Instalacija i deinstalacija:
Tokom instalacije, XP je prekinuo vezu dok je pokušavao da se pokrene nakon instalacije. Nakon ponovnog pokretanja sve je radilo kako treba.

AtGuard 3.22>

Instalacija i deinstalacija:
Instalacija i deinstalacija ne izaziva nikakve posebne probleme

Prednosti:

1. Mali vatrozid, ima zanimljivo rješenje sa stanovišta sučelja - napravljen je u obliku panela koji se nalazi na vrhu ekrana

Nedostaci i karakteristike:

1. Ranjivo u režimu obuke - od trenutka kada se prikaže zahtev za kreiranje pravila do kreiranja, prosleđuje pakete u oba smera
2. Interfejs je malo pogrešan prilikom ponovnog crtanja prozora

Ukupna ocjena:
Jednostavan zaštitni zid, ali funkcionalan

Kerio Personal Firewall 4

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

Norton Internet Security 2004 (NIS)

Instalacija i deinstalacija: Instalacija ne stvara probleme, ali od svih analiziranih, instalater je najglomazniji.

Internet Connection Firewall, ICF - ugrađen windows firewall XP

Instalacija i deinstalacija: Nije potrebna instalacija, jeste redovnim sredstvima XP. Omogućavanje se vrši u postavkama mrežni adapter... Podrazumevano, ICF radi u režimu maksimalne bezbednosti i (ovo je rezultat mog zapažanja) princip njegovog rada je sledeći - zahtevi aplikacije se oslobađaju spolja, a samo paketi koji su došli kao odgovor na moje zahteve se prihvataju izvan ( korespondencija zahtjev-odgovor se jasno održava u obliku dinamičke tabele). Dakle, prilikom skeniranja portova na računaru sa uključenim ICF-om nema nijednog otvorenog porta (ovo je logično - paketi skenera portova neće biti prosleđeni, jer ih niko nije zahtevao). Slična je situacija i sa raznim vrstama "nuklearki" zasnovanih na slanju nestandardnih paketa

Zaštitni zid Internet veze, ICF - Windows XP SP2 ugrađeni zaštitni zid

Instalacija i deinstalacija: Instalacija nije potrebna, to je standardni XP alat (uključen u SP2 za XP). Omogućavanje se vrši u postavkama mrežnog adaptera. Treba napomenuti da se prilikom instaliranja SP2 ili kada instalirate XP sa integrisanim SP2, pored Firewall-a, u sistemu 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 se odvijaju bez problema, ali tokom instalacije dolazi do greške u ikernel biblioteci. Ista greška se dogodila tokom deinstalacije. Pojava ove greške ne utiče na instalaciju i uklanjanje programa. Instalater nije zahtijevao ponovno pokretanje sistema, što je neobično za zaštitni zid

Visnetic Firewall 2.2

Instalacija i deinstalacija: Instalacija programa i njegova deinstalacija se odvija bez problema. Nakon instalacije potrebno je ponovno pokretanje.

Pogledaj i zaustavi lični firewall 2.05

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

Kaspersky AntiHacker 1.5

Instalacija i deinstalacija: Instalacija programa i njegova deinstalacija se odvija bez problema. Nakon instalacije potrebno je ponovno pokretanje.

Tiny Personal Firewall Pro 6.0

Instalacija i deinstalacija:
Instalacija programa i njegova deinstalacija se odvija bez problema. Nakon instalacije potrebno je ponovno pokretanje.

McAfee Personal Firewall Plus 6.0 Build 6014

Instalacija i deinstalacija:
Instalacija programa i njegova deinstalacija se odvija bez problema. Nakon instalacije potrebno je ponovno pokretanje.

R-Firewall 1.0 Build 43

Instalacija i deinstalacija:
Instalacija programa i njegova deinstalacija se odvija bez problema. Veličina distributivnog kompleta je mala (3,8 MB), možete prilagoditi sastav proizvoda. Rad je prilično stabilan, na referentnom računaru nisu primećeni očigledni kvarovi i zamrzavanja

Opšti zaključci i zaključak

Dakle, hajde da sumiramo rezultate testova. Zapravo, testovi su potvrdili moje teorijske ideje o stanju problema:

1. Zaštitni zid treba konfigurirati... Svi testirani Firewall su dobro radili, ali tek nakon konfiguracije (obuka, kreiranje postavki ručno - nije važno). Iskorišćavanje nekonfigurisanog zaštitnog zida može učiniti više štete nego koristi (preskočiće opasne pakete i obrnuto, ometati korisne programe);
2. Poslije Postavke zaštitnog zida i IDS treba testirati- ovo je takođe prilično očigledan zaključak, ali je ipak važan. Prvi korak koji sam poduzeo u stvaranju testera bio je APS uslužni program. Ostala su još dva - simulator trojanskog programa (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 vrši se na komandu korisnika pod njegovom kontrolom), što će omogućiti praćenje reakcije Firewall-a i IDS-a) i uslužni program za ekspresno skeniranje portova i izvođenje osnovnih napada (u stvari, APS je upravo suprotno – oni mogu imati zajednička baza luka). Već se bavim razvojem ovih uslužnih programa - njihovo prisustvo u korisničkom arsenalu omogućit će neku "instrumentalnu kontrolu".
3. Personal Firewall je ranjiv na zlonamjerni softver koji je van konteksta. Zaključak - barem dolje sa raznim "lijevim" panelima i ostalim BHO-ima iz pretraživača i e-maila!! Prije instaliranja bilo kojeg dodatka, panela, uslužnog programa za proširenje, itd. morate deset puta razmisliti o njihovoj neophodnosti, tk. oni nisu zasebni procesi operativnog sistema i pokreću se iz konteksta roditeljskog programa... Trojanskog konja lako detektuje lični Firewall - on "vidi" da neki proces (recimo, bo2k.exe) pokušava da počne da sluša na portu xxxxx ili razmenjuje sa određenim hostom - izdaje se zahtev za prihvatljivost, korisnik počinje da shvatite kakva je "bo2k.exe. "i Backdoor je uhvaćen. Ali ako je trojanski konj pobjegao iz konteksta pretraživača, onda gotovo sigurno niko ne bi obraćao pažnju na pristup pretraživača Internetu. Takvi trojanci postoje, najbliži primjer je TrojanDownloader.IstBar - instaliran je tačno kao IE traka (naravno, nije u procesima, nalazi se i na popisu za autorun);
4. Mnogi lični zaštitni zidovi su vidljivi kao procesi operativnog sistema i virus ih može zaustaviti. Zaključak - rad Firewall-a se mora pratiti i njegov iznenadni prekid može poslužiti kao signal da je virus ušao u PC;
5. Neki zaštitni zidovi (kao što je Kerio) dozvoljavaju daljinsko upravljanje- funkcija daljinski upravljač mora biti ili onemogućeno ili zaštićeno lozinkom.

Postavke Windows zaštitnog zida (zaštitnog zida) su kritične za osiguranje sigurnosti vašeg računara i podataka koji se na njemu čuvaju kada radite na Internetu i lokalnim mrežama. Operacija konfiguracije firewall-a izvodi se pomoću standardnih Windows metoda i ne zahtijeva posebne kompjutersko znanje.

Instrukcije

Kliknite na dugme "Start" da biste otvorili glavni meni sistema i idite na stavku "Kontrolna tabla".

Proširite vezu Windows zaštitni zid i primenite polje za potvrdu Omogući (preporučeno) na kartici Opšte da biste pokrenuli zaštitni zid.

Potvrdite izbor u polju za potvrdu Ne dozvoli izuzetke da biste suzbili upozorenja o blokiranju i sprečili kreiranje liste izuzetaka.

Idite na karticu "Izuzeci" i primijenite potvrdne okvire u poljima aplikacija kojima želite da dozvolite dolazne veze.

Kliknite karticu Napredno da biste onemogućili zaštitni zid za određenu vezu i postavke dodatni parametri filtriranje ICMP protokola.

Kliknite na dugme "Podrazumevano" da vratite originalne postavke zaštitnog zida.

Koristite automatsko kreiranje izuzetaka aplikacije kada pokrećete program koji čeka vezu na određeni port za pristup mreži.

Kliknite na dugme Blokiraj u prozoru Windows Security Alert da u potpunosti blokirate povezivanje odabrane aplikacije na mrežu.

Kliknite na dugme Deblokiraj da kreirate pravilo koje dozvoljava odabranoj aplikaciji da se poveže na mrežu.

Kliknite na dugme "Odloži" da odbijete vezu u ovom trenutku.

Vratite se na karticu Izuzeci i kliknite na dugme Dodaj program da kreirate pravilo koje dozvoljava odabranoj aplikaciji da pristupi mreži ako unapred znate da je to neophodno.

Kliknite na dugme Dodaj port da kreirate pravilo za povezivanje sa mreže na uslugu koja radi na ovom portu.

Kliknite na dugme Promeni opseg da postavite opseg adresa sa kojih se mogu uspostaviti veze sa navedenom aplikacijom ili portom.

Kliknite karticu Napredno i primijenite potvrdne okvire u okvirima Mrežna veza pod Postavke mrežne veze da biste omogućili uslugu zaštitnog zida za svaku od njih.

Uporedno testiranje 21 popularnog firewall-a za kvalitet zaštite od napada koji dolaze iz sistema. U testu je zaštita provjerena korištenjem 64 test uslužna programa posebno razvijena za to, koji provjeravaju zaštitu procesa od prekida, zaštitu od standardnih internih napada, zaštitu od nestandardnih curenja i zaštitu od nestandardnih tehnika prodiranja u kernel način rada.

Uz antivirus, zaštitni zid je jedna od glavnih komponenti računarske sigurnosti. Međutim, za razliku od antivirusnih programa, objektivni testovi firewall-a se rijetko izvode. Ovu prazninu pokušali smo da popravimo provodeći firewall test za zaštitu od internih napada i test personalnog IDS/IPS za zaštitu od napada na ranjive aplikacije 2011. i 2012. godine. Ove godine smo odlučili da proširimo listu korištenih metoda i ponovimo test firewall-a za zaštitu od internih napada kako bismo vidjeli kako su se rezultati popularnih proizvoda mijenjali u proteklom vremenu po ovom kriteriju.

Čemu je cilj ovog testa ili koje funkcije firewall obavlja? Prema Internet standardu [RFC3511] (2003), firewall je sistem koji implementira funkcije filtriranja mrežnih paketa u skladu sa određenim pravilima kako bi se razlikovao promet između segmenata mreže. Međutim, sa sve većom složenošću zlonamjernog softvera i hakerski napadi, originalni zadaci firewall-a su dopunjeni novim funkcionalni moduli... Praktično je nemoguće zamisliti punopravni zaštitni zid bez HIPS modula (nadgledanje sistemskih događaja, praćenje integriteta sistema, itd.).

Glavni zadatak modernog firewall-a je blokiranje neovlaštenih mrežnih komunikacija (u daljem tekstu napadi), podijeljenih na interne i eksterne. To uključuje:

Vanjski napadi na sistem zaštićen vatrozidom:

• iniciran od strane hakera;
• pokrenut zlonamjernim kodom.

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

Pored toga, proizvodi koji bi se mogli klasifikovati kao čisti lični firewall u klasičnoj formulaciji iz 2003. praktično su nestali sa tržišta. Zamijenjeni su složenim proizvodima za zaštitu osobnih računala, koji nužno uključuju komponentu firewall-a.

Test zaštitnog zida za zaštitu od eksternih napada uključuje proučavanje kvaliteta zaštite od napada koji dolaze iz sistema. Test je sproveden u sledećim oblastima:

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

U odnosu na prethodni test, broj korišćenih napada je značajno povećan - sa 40 na 64. Promenjen je i operativni sistem koji bi trebalo da bude zaštićen proizvodima koji se testiraju. U prošlom testu to je bio Windows XP, au ovom testu Windows 7 x32. Sličan test je takođe planiran za kraj godine za Windows 7 x64 operativni sistem.

Uvod

Učestvovao u testiranju 21 popularan program sveobuhvatna zaštita(Internet Security klasa, ako nema takvog proizvoda u liniji, onda je odabran čisto firewall) od različitih proizvođača trenutne verzije proizvoda od početka testiranja (maj 2013.) i dalje 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 Security Space (8.0).
7. Eset Smart Security (6.0.316.0).
8. F-Secure Internet Security (1.77 build 243).
9. G DATA Internet Security (1.0.13113.239).
10. Jetico Personal Firewall (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 zaštitni zid.
15. Norton Internet Security (20.3.0.36).
16. Online Armor Premium Firewall (6.0.0.1736).
17. Outpost Security Suite Pro (8.0 (4164.639.1856).
18. Panda Internet Security (18.01.01).
19. PC Tools 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 testiranja pripremljeno je okruženje za testiranje. Da bi se to postiglo, na čist računar je instaliran operativni sistem Windows 7 Enterprise SP1 x86 sa svim tada dostupnim ažuriranjima, kao i dodatnim softverom potrebnim za testiranje.

Testiranje je obavljeno na dvije vrste podešavanja: standardno preporučeno od strane proizvođača (podrazumevane 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, sve postavke koje su bile onemogućene u "podrazumevanom" načinu rada, ali su u isto vrijeme mogle utjecati na ishod testiranja, bile su omogućene i/ili dovedene na maksimalnu poziciju (najstrože postavke). Drugim riječima, postavljanje maksimalnih postavki znači prijevod svih dostupnih sa grafički interfejs korisnik konfigurira sve module koji se odnose na otkrivanje zlonamjerne datoteke ili mrežne aktivnosti na najstrožu opciju.

Test firewall-a je proveden na sljedećim grupama internih napada, radi jasnoće, raščlanjenih na nivoe težine:

1. Osnovni nivo težine (56 opcija napada):

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

2. Povećani nivo težine (8 opcija za napade):

1. testiranje zaštite od nestandardnih curenja (3 vrste napada);
2. testiranje zaštite od nestandardnih tehnika prodora u kernel mod (5 opcija napada).

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

Provjeravanje zaštitnih zidova za zaštitu od unutrašnjih napada

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

Tabela 1-2 i Slika 1-2 prikazuju rezultate testiranja zaštitnih zidova odvojeno za standardne i maksimalne postavke... Radi jasnoće, rezultati za svaki firewall su podijeljeni u dvije grupe: zaštita od napada osnovnog nivoa složenosti i zaštita od napada povećan nivo teškoće.

Tabela 1: Rezultati testiranja firewall-a na stdapostavke usta

Testirani proizvod							Ukupno bodova (maks. 64)	Ukupno %
	Poeni	%	% od sume	Poeni	%	% od sume
Comodo	53	95%	82,8%	6	75%	9,4%	59	92%
Online Armor	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%
Outpost	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%
TrustPort	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%
AVG	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%
Kingsoft	27	48%	42,2%	1	13%	1,6%	28	44%

Slika 1: Rezultati testiranja zaštitnih zidova na standardnim postavkama

Zaštita od unutrašnjih napada na postavkama koje preporučuje proizvođač ostavlja mnogo da se poželi. Samo tri firewall-a su bila u stanju da prevaziđu prag od 80% na standardnim postavkama - to su Comodo, Online Armor i Norton. Jetico (79%) i Outpost (74%) su im sasvim blizu. Ispostavilo se da su rezultati ostalih zaštitnih zidova znatno lošiji.

U odnosu na rezultate posljednjeg testa, svi lideri su potvrdili svoje visoke rezultate, bilo je samo malih pokreta unutar vodeće grupe, na primjer Outpost i Jetico su promijenili položaje. Jedino iznenađenje je bilo Norton proizvod, koja je u prošlom testu pokazala rezultat od 45% i bila u donjem dijelu tabele, a u ovom testu sa 80% zauzela je treću poziciju.

Dobiveni rezultati su rezultat činjenice da mnogi proizvođači postavljaju zadane postavke na način da se smanji broj poruka na koje korisnik mora odgovoriti. To potvrđuju i rezultati testiranja – na standardnim postavkama firewall su postavljali pitanja korisnicima samo u 5,4% napada, a maksimalno u 9,2% napada. Međutim, to utiče na kvalitet zaštite, koja će ostati tiha u situaciji kada će zlonamjerni program imitirati/izvršiti potpuno legitimne radnje u sistemu.

Također treba obratiti pažnju na dva uzorka. Prvo, procenat prevencije složenih tipova napada generalno je primetno gori od napada osnovnog nivoa složenosti. Više od polovine ovih napada odbacila su samo četiri proizvoda - Comodo, Online Armor, Norton i Jetico. Još četiri proizvoda ušla su u graničnu grupu, odbacivši od 25% do 38% takvih napada - to su Outpost, Trend Micro, Kaspersky i Dr.Web. Svi ostali proizvodi su odbili najviše jedan složeni napad. Drugo, poboljšani su pokazatelji odbijanja osnovnih napada. Ako je u prošlom testu 11 (50%) proizvoda odbilo manje od 50% napada, onda su u ovom testu samo 3 takva proizvoda (14%).

Tabela 2: Rezultati testiranja zaštitnih zidova na maksimalnim postavkama

Testirani proizvod	Osnovni napadi (maks. 56 poena)			Napredni napadi (maks. 8 poena)			Ukupno bodova (maks. 64)	Ukupno %
	Poeni	%	% od sume	Poeni	%	% od sume
Comodo	56	100%	87,5%	8	100%	12,5%	64	100%
Bitdefender	56	100%	87,5%	8	100%	12,5%	64	100%
Online Armor	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%
Outpost	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%
TrustPort	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%
AVG	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%
Kingsoft	27	48%	42,2%	1	13%	1,6%	28	44%

Slika 2: Rezultati testa zaštitnog zida pri maksimalnim postavkama

Kada su omogućene maksimalne postavke, kvalitet zaštite od internih napada za mnoge od testiranih firewall-a je značajno poboljšan. To je posebno uočljivo kod jakih srednjih seljaka. Svi lideri posljednjeg testa na ovom testu također su pokazali visoke rezultate. Od promjena vrijedi istaknuti Bitdefender proizvod koji je uz Comodo pokazao stopostotne rezultate i Norton proizvod koji je prešao u vodeću grupu.

Rezultati za niz proizvoda pri standardnim i maksimalnim postavkama bili su isti. To je zbog činjenice da ovi proizvodi nemaju postavke koje mogu utjecati na rezultate našeg testa.

Poređenje kvaliteta zaštite na standardnim i maksimalnim postavkama

U skladu sa logikom ovog testa, nećemo zbrajati ili usrednjavati rezultate istog proizvoda sa različite postavke... Naprotiv, želimo da ih uporedimo i pokažemo značajne razlike u kvaliteti zaštite testiranih proizvoda, u zavisnosti od podešavanja koja se koriste.

Radi jasnoće, predstavljamo konačne rezultate testa zaštitnog zida sa standardnim i maksimalnim postavkama u tabeli 3 i na slici 3.

Tabela 3: Sažetak rezultata testiranja zaštitnog zida pri standardnim i maksimalnim postavkama

Proizvod	Standardne postavke	Maksimalne postavke
Comodo	92%	100%
Online Armor	90%	95%
Norton	80%	91%
Jetico	79%	79%
Outpost	74%	85%
Trend Micro	70%	72%
Kaspersky	70%	94%
Dr.Web	70%	80%
TrustPort	68%	71%
G PODACI	67%	70%
Avast	66%	66%
Eset	66%	85%
Bitdefender	66%	100%
AVG	64%	64%
McAfee	64%	64%
PC alati	64%	86%
Avira	63%	68%
Microsoft	63%	63%
F-Secure	51%	51%
Panda	47%	47%
Kingsoft	44%	44%

Slika 3: Sažetak rezultata testiranja zaštitnog zida pri standardnim i maksimalnim postavkama

Slika 3 vrlo jasno pokazuje razliku u rezultatima testa u zavisnosti od odabranih postavki.

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 od proizvoda se značajno pokazuju najbolji nivo 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 nemaju uopće podešavanja koja bi na bilo koji način mogla utjecati na rezultate testa. 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 procjena ne uzima u obzir situacije u kojima je napad odbijen, ali je bilo problema sa korisničkim interfejsom proizvoda. U većini slučajeva, problemi su se sastojali u „rušenju“ interfejsa na kratko (od 2 do 10 sekundi) ili do sledećeg pokretanja operativnog sistema. Dok proizvodi nastavljaju da pružaju sigurnost kada postoje problemi sa korisničkim interfejsom, prisustvo takvih problema je subjektivno negativno i može uticati na izbor proizvoda. Broj problema sa korisničkim interfejsom prikazan je u tabeli 3 i na slici 3. Procenjene su greške nastale napadima 1. nivoa, čiji je ukupan broj 41.

Tabela 4: Broj problema korisničkog sučelja pri standardnim i maksimalnim postavkama

Testirani proizvod	Standardne postavke		Maksimalne postavke
	Broj grešaka	%	Broj grešaka	%
McAfee	34	83%	34	83%
Microsoft	33	80%	33	80%
Kingsoft	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%
AVG	10	24%	9	22%
TrustPort	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%
Outpost	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 Armor	1	2%	1	2%

Slika 4: Broj problema korisničkog interfejsa pri standardnim i maksimalnim postavkama

Rezultati pokazuju da su McAfee i Microsoft proizvodi imali probleme sa korisničkim interfejsom u većini napada (preko 80%). Ovo se može nazvati neprihvatljivim nivoom, jer praktično svaki uspješno odbijen napad će dovesti do problema. Kingsoft, F-Secure, Panda, Jetico i PC Tools pokazuju prilično loše rezultate, u rasponu od 30% do 50%. Kada ih koristite, svaka 2-3 napada će dovesti do problema sa interfejsom. Brojni drugi proizvodi pokazuju rezultate od 10% do 30%, što se može nazvati zadovoljavajućim. Dobri 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 sa korisničkim interfejsom je Comodo na maksimalnim postavkama, što se može smatrati odličnim rezultatom. Međutim, Comodo performanse se pogoršavaju pri standardnim postavkama (12%), što znači da korištenje ovog proizvoda zahtijeva određeno znanje o tome kako ga postaviti.

Konačni rezultati testova i nagrade

Kao iu prethodnom testu, nismo usrednjavali rezultate istog proizvoda sa različitim postavkama, već smo ih razmatrali nezavisno jedan od drugog. Tako svaki od testiranih proizvoda može dobiti dvije nagrade, po jednu za svaku vrstu postavke.

U skladu sa nagradnom šemom, najbolji firewall dobijaju nagrade sa naznakom korišćenih postavki, vidi tabelu 4.

Tabela 5: Konačni rezultati testa zaštitnog zida na standardnim i maksimalnim postavkama

Testirani proizvod	Opcija postavke	Sprečavanje napada [%]		Ukupno [%]	Nagrada
		Baza nivo težine	Povećani nivo težine
Comodo	Max	100%	100%	100%	Platinum Firewall Outbound Zaštitna nagrada
Bitdefender	Max	100%	100%	100%
Online Armor	Max	95%	100%	95%	Zlatni firewall odlazni Zaštitna nagrada
Kaspersky	Max	95%	88%	94%
Comodo	Standard	95%	75%	92%
Norton	Max	90%	100%	91%
Online Armor	Standard	89%	94%	90%
PC alati	Max	88%	69%	86%
Outpost	Max	88%	69%	85%
Eset	Max	88%	69%	85%
Norton	Standard	80%	75%	80%
Dr.Web	Max	83%	63%	80%
Jetico	Max	82%	56%	79%	Silver Firewall Outbound Zaštitna nagrada
Jetico	Standard	82%	56%	79%
Outpost	Standard	80%	31%	74%
Trend Micro	Max	77%	38%	72%
TrustPort	Max	77%	31%	71%
Trend Micro	Standard	75%	38%	70%
Kaspersky	Standard	75%	31%	70%
Dr.Web	Standard	76%	25%	70%
G PODACI	Max	75%	38%	70%
TrustPort	Standard	77%	6%	68%	Bronze Firewall Outbound Zaštitna nagrada
Avira	Max	74%	25%	68%
G PODACI	Standard	75%	13%	67%
Avast	Max	73%	19%	66%
Avast	Standard	73%	13%	66%
Eset	Standard	73%	13%	66%
Bitdefender	Standard	73%	13%	66%
AVG	Max	73%	0%	64%
AVG	Standard	73%	0%	64%
McAfee	Max	73%	0%	64%
McAfee	Standard	73%	0%	64%
PC alati	Standard	73%	0%	64%
Microsoft	Max	71%	0%	63%
Microsoft	Standard	71%	0%	63%
Avira	Standard	71%	0%	63%
F-Secure	Max	56%	13%	51%	Nema nagrade
F-Secure	Standard	56%	13%	51%
Panda	Max	54%	0%	47%
Panda	Standard	54%	0%	47%
Kingsoft	Max	48%	13%	44%
Kingsoft	Standard	48%	13%	44%

Najbolje rezultate na testu pokazali su Comodo i Bitdefender firewall koji su na maksimalnim postavkama postigli 100% bodova. Ova dva proizvoda dobijaju nagradu PlatinumFirewallOutboundZaštitaNagrada.

Online Armor, Kaspersky, Comodo, Norton, PC Tools, Outpost, Eset i Dr.Web firewall, koji dobijaju nagrade, takođe su pokazali veoma visoke rezultate na testu (preko 80%). ZlatoFirewallOutboundZaštitaNagrada... Važno je napomenuti da je Comodo primio ovu nagradu na standardnim postavkama, Online Armor i Norton na standardnim i maksimalnim postavkama, a svi ostali - samo na maksimalnim postavkama.

Sljedeća na listi je grupa od sedam zaštitnih zidova, čiji rezultati padaju u rasponu od 60% do 70%. To su Outpost, Kaspersky i Dr.Web sa standardnim postavkama; TrustPort i G DATA na maksimalnim postavkama, kao i Jetico i Trend Micro u isto vrijeme na standardnim i maksimalnim postavkama. Svi dobijaju nagradu

Prilično velika grupa proizvoda koji spadaju u raspon od 60% do 70% dobit će nagradu. Treba napomenuti da su proizvodi Eset i Bitdefender na standardnim postavkama, koji su na maksimalnim postavkama uspjeli odbiti znatno veći broj napada.

Možete se upoznati sa detaljnim rezultatima testiranja i uvjeriti se da su konačni proračuni tačni preuzimanjem rezultata testa u Microsoft Excel formatu.

Ilya Shabanov, izvršni partner stranice:

“Veoma sam zadovoljan činjenicom da su mnogi proizvođači značajno poboljšali proaktivnu zaštitu od internih napada i samoodbrane u svojim proizvodima. Čak smo morali da revidiramo šemu nagrada da bismo podigli letvicu. Rezultat manji od 51% se sada smatra potpunim neuspjehom.

Ugodno su nas iznenadili Bitdefender, koji je odbio svih 100% napada u paranoidnom modu, Eset i Dr.Web s rezultatima na maksimalnim postavkama od 85% do 80%, respektivno, kao i novajlija na našim testovima, TrustPort. Firewall kompanija Comodo, Norton i Online Armor uvršteni su u "zlatnu grupu" proizvoda prema rezultatima ovog testa, sa više od 80% bodova na standardnim i maksimalnim postavkama. Kaspersky, Outpost, PC Tools su pokazali konstantno visoke rezultate u testovima koji uključuju proaktivnu zaštitu.

Međutim, u slučaju većeg broja 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 ispada značajno podcijenjena. Ovo se prvenstveno odnosi na Bitdefender, Kaspersky, Eset i PC Tools proizvode."

Kartavenko Mihail, šef laboratorije za ispitivanje:

“Smatrajući ovaj test kao nastavak prethodnog sličnog testa, možemo identifikovati nekoliko glavnih tendencija i problema u radu firewall-a.

Prvo, većina proizvoda je u prosjeku imala bolje rezultate nego prije 1,5 godine, ali to su uglavnom činili odbijanjem najjednostavnijih napada Nivoa 1. Složeniji napadi "u zube" samo za ograničeni asortiman proizvoda.

Drugo, čak i ako se aktivira zaštita od prekida procesa (1 nivo napada), korisničko sučelje mnogih proizvoda ruši. Ovo dovodi korisnika u neugodan položaj u kojem ne razumije da li zaštita radi ili ne.

Treće, postoji prilično velika praznina u radu zaštitnih zidova na standardnim i maksimalnim postavkama. Kao rezultat toga, prihvatljiv nivo zaštite često mogu dobiti samo iskusni korisnici koji znaju i mogu pravilno konfigurirati rad firewall-a.

Tako je test otkrio "bolne" tačke modernih firewall-a, čije rješenje može poboljšati njihovu zaštitu."

Odjeljak se ažurira svakodnevno. Uvijek najnovije verzije najboljih besplatnih programa za svakodnevnu upotrebu u odjeljku Neophodni programi. Praktično postoji sve što je potrebno svakodnevni rad... Počnite da se ukidate piratske verzije u korist praktičnijih i funkcionalnijih besplatnih kolega. Ako još uvijek ne koristite naš chat, toplo vam preporučujemo da se s njim upoznate. Tamo ćete naći mnogo novih prijatelja. Štaviše, najbrži je i efikasan 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 da nešto pročitate? Kompletan sadržaj puzajuće linije možete pronaći na ovom linku.

Besplatno firewall Comodo... Testiranje, zaključci

Comodo Firewall u akciji

Nakon instaliranja i konfigurisanja Comodoa, sakrio se u tray i počeo me nervirati svojim pitanjima. Prvog dana sam se poigrao sa svim zaštitnim zidom i proaktivnim odbrambenim modovima i na kraju ga ućutkao. U njihovom sistemu nakon pojave nisu pronađene kočnice. Općenito, rad sa Comodo firewall-om bio je prilično lak i zgodan. Interfejs glavnog prozora je vrlo jednostavan i informativan:

Ali morao sam se naviknuti na navigaciju kroz firewall i postavke proaktivne zaštite - nije uvijek moguće brzo pronaći željenu stavku. Mislim da će to vremenom proći.

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

Test broj 1. Online testiranje

Kada kliknete na dugme "Test", program pokušava da uspostavi vezu sa serverom sajta.

Pošto Comodo Firewall još ne poznaje ovaj uslužni program, kada je prvi put pokušao provaliti na Internet, odmah je uslijedila reakcija proaktivne zaštite i zaštitnog zida:

U oba slučaja, kliknuo sam na blok i dobio sam potvrdu da je test bio uspješan:

Zatim sam preimenovao fajl FireWallTest.exe v opera.exe i zamenio ih standardnim Opera fajlom. Tako sam pokušao da prevarim Comodo Firewall, koji ovaj pretraživač već dobro poznaje i stalno i automatski ga pušta na Internet. Comodo je reagovao na lansiranje "lažne" Opere iz Totala na sljedeći način:

Pošto sam dobio moju dozvolu za jednokratno pokretanje, firewall me upozorio na pokušaj pristupa Operi na Internetu:

Ispostavilo se da bilo koja aplikacija za koju već postoje pravila neće moći pristupiti Internetu ako se izvršna datoteka zamijeni bez mog znanja. Čini se da je sve u redu, ali evo u čemu je stvar: boja gornjeg dijela prozora upozorenja ovisi o ozbiljnosti situacije. Ako Comodo ocijeni događaj kao kritičan, tada će boja biti crvena, ako je događaj manje opasan, bit će žuta. U mom slučaju, Comodo je smatrao da simulirana situacija nije naročito opasna i upalio je žutu. Štaviše, umjesto teksta „izvršni fajl opera.exe nije prepoznato "radije bih to vidio" došlo je do promjene u parametrima datoteke opera.exe”. Zato upozorite slične situacije kombinate od Kasperskyja i Eseta, na primjer. Štaviše, korisnik vidi prozor alarma koji koristi crvenu boju, što ga odmah tjera da obrati pažnju na situaciju. Upozorenje od Comodoa korisnik jednostavno može zanemariti zbog nedovoljnog naglaska na događaju koji se odvija.

Lažnjavanje Opera fajla bilo je samo deo mog lukavog plana. Sledeća žrtva je bila Internet Explorer 6, koji je integrisan u operativni sistem, što znači iexplore.exe može se smatrati punopravnim sistemskim fajlom. Zamislite moje iznenađenje kada sam u potpunoj tišini Comodo-a ugledao prozor o neuspjehu testa:

Očigledno je stvoreno dodatno pravilo, odlučio sam i ušao u firewall i politike proaktivne zaštite. Nakon 15-tak minuta kopanja, donio sam jedinu ispravnu odluku - da ponovo instaliram Comodo. Ne pre rečeno nego učinjeno. Ostavljajući zadane načine rada, ponovio sam eksperiment sa zamjenom iexplore.exe... Prilikom pokretanja iz Total-a, proaktivna zaštita je radila, kao u slučaju Opere:

Ovdje ćemo morati napraviti malu lirsku digresiju. Činjenica je da kada se IE izvršna datoteka zamijeni, sistem vraća originalnu u roku od 4-8 sekundi. iexplore.exe... S tim u vezi, rezultati mog testa ovisili su o tome da li je zamijenjena datoteka imala vremena da se pojavi na Internetu ili ne.

U slučaju kada uspem da završim sve manipulacije pre oporavka explore.exe, dešava se sledeće. Pošto sam dobio moju dozvolu za jednokratno lansiranje explore.exe, Total pokreće uslužni program FireWallTest, pritisnem "Test", proaktivna odbrana Defens + izdaje upozorenje:

Ako to dopustimo (kao eksperiment), firewall radi:

Uspijemo pritisnuti "Blokiraj" - test je prošao, uslužni program nije skliznuo na Internet. Ali ako iexplore.exe vraćeno pre nego što je pritisnuto dugme za zaključavanje - ništa ne zavisi od vašeg izbora - uslužni program automatski dobija pristup Internetu kada se originalna datoteka vrati.

Isto se odnosi i na rad proaktivne zaštite: ako niste imali vremena za naredbu za blokiranje prije restauracije explore.exe- uslužni program automatski dobija pristup internetu.

Pošto sam se dovoljno igrao sa lažnim IE, prisjetio sam se prvog neuspjeha testa, kada je Comodo šutio i pustio "lijevu" datoteku na Internet. Nakon ponovne instalacije Comodoa, stavio sam Defense + i firewall u režim obuke i pokrenuo IE. Nakon toga sam vratio zadane modove i ponovio test. Comodo opet tiho nije uspio...

Test broj 3. Duel

Impresioniran rezultatima prethodnog testa, tražio sam dodatne funkcije testirali Comodo i konačno pronašli uslužni program AWFT.

Ovaj program emulira ponašanje trojanaca i sadrži seriju od šest testova koji demonstriraju različite metode neovlaštenog pristupa mreži, zaobilazeći zaštitu firewall-a. Ovi testovi uključuju i stare načine varanja zaštitnih zidova i modernije tehnike. Za svaki uspješno položen test firewall-u se dodjeljuje određeni broj bodova. Ako test ne uspije, bodovi se dodjeljuju u korist AWFT. Maksimalan broj bodova je deset.

Uslužni program je shareware, ograničen na 10 pokretanja. U gornjem dijelu prozora programa nalaze se dugmad koja pokreću odgovarajuće testove, ispod je mjesto gdje će se AWFT probiti i rezultat duela između firewall-a i uslužnog programa. Dugme Reset Points se koristi za resetovanje akumuliranih bodova.

Za svaki slučaj, odlučio sam da promijenim adresu stranice u svoju.

Testiranje je obavljeno uz uključeni Comodo Firewall i Defense +, Opera radi i Avirin monitor isključen.

U prvom testu korišćena je tehnika sa učitavanjem skrivene kopije pretraživača i krpljenjem memorije pre pokretanja.

Kada sam kliknuo na dugme za testiranje, pojavio se prozor sa greškom:

Nakon zatvaranja ovog prozora, Comodo je reagovao na test prozorom sa zahtjevom, kada je pritisnuto dugme "Blokiraj", AWFT je, nakon malo razmišljanja, dao prvu tačku firewall-u.

Prema programerima uslužnog programa, test #2 je stari i dobro poznati trik. Comodo ponovo odgovara poljem sa zahtevom i ponovo dobija poen.

Test broj 3 također koristi stari trik. Comodo ga samo nečujno blokira, očigledno stvarno poznat trik.

Test br. 4 je sličan prvom testu sa pokretanjem skrivene kopije pretraživača i krpljenjem memorije prije pokretanja. Firewall nije izdao nikakva upozorenja, ali je nakon kratke pauze zaradio još jedan poen.

Tokom petog i šestog testa potrebno je prebaciti se na pretraživač i malo surfovati (upravo sam osvježio stranicu učitanu u pretraživač).

U testu #5, uslužni program izvodi heurističku pretragu za ovlaštenim softverom instaliranim na računalu (ili u mreži) koji ima pristup Internetu preko porta 80, zatim pokreće kopiju dozvoljenog programa i krpi memoriju koju ovaj program zauzima (tj. AWFT se sam pokreće u memoriji dozvoljenog programa). Comodo je tiho prošao test i za to dobio ogromna 3 boda.

Test #6 je sličan prethodnom petom testu. Ista tehnika se koristi sa heurističkom pretragom instaliranog softvera koji ima pravo da izađe napolje preko porta 80. Promenjen je samo metod hakovanja - koristi se korisnički zahtev. Usput, AWFT pokušava da zalijepi lijevu skrivenu traku sa alatkama u pretraživač. Kada je Opera bila otvorena, pojavio mi se sledeći prozor:

U trenutku kada sam potvrdio ovaj korisnički zahtjev, Comodo je izdao svoj zahtjev, uslužni program je ponovo blokiran, a firewall je dobio 3 boda za sebe.

Rezultat duela je 10:0 u korist Comoda. Nakon ponavljanja testova sa otvorenim Internet Explorerom, dobio sam iste rezultate.

Zaključak

Uprkos neprijatnom ukusu u tušu koji je ostao nakon testiranja firewall-a, i dalje preporučujem Comodo Internet Security za kućnu upotrebu, ali samo kao zaštitni zid. I ne slušajte one pametne tipove koji savjetuju onemogućavanje proaktivne zaštite, u svakom slučaju! Samo korištenjem Defense + ovaj zaštitni zid će zaista zaštititi vaš računar. Ono što zaista ne biste trebali koristiti je Comodo antivirus. Ne samo da pristojno preskače, već ćete imati problema s ažuriranjem - ima vrlo glomazne baze podataka. Osim toga, ima pristojan učinak na performanse sistema. Upravo sam odlično radio u paru Comodo Firewall-a i Avira Antivir Personal.

Nisam pronašao nikakve kočnice ili kvarove u sistemu dok je firewall radio. Svoje mišljenje o rezultatima testiranja za sada ću ostaviti za sebe, voljela bih saslušati vaše komentare.

Dok sam pisao završni dio ovog članka, naišao sam na rezultate nedavnog testiranja firewall-a u laboratoriji Matousec. Ispostavilo se da je Comodo Internet Security jedini zaštitni zid sa stopom uspješnosti od 100% (pogledajte forum zaštitnog zida). Pa, ja sam izabrao... A ti?

plusevi (eksplicitno):
besplatna distribucija,
dostupnost sopstvene baze programa;
prisustvo proaktivne zaštite (Odbrana +);
jednostavnost instalacije i početnog podešavanja;
vrlo informativan i zgodan prozor sa sažetkom;

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

kontra (eksplicitno):
dosadan način instalacije;
zamena izvršne datoteke nije definisana proaktivnom zaštitom kao kritični događaj;

nedostaci (upitno):
iskreno neuspješan antivirus.

Ovaj drugi članak opisuje kako riješiti problem s filterom paketa. Umjesto kastinga gotov sto u obliku "problema" - "rešenja" date su metode sistematskog pristupa za rešavanje nastalih problema.

Ovaj drugi članak (u nizu od tri) opisuje kako riješiti probleme s filterom paketa. Umjesto prezentovanja gotove tabele u obliku "problema" - "rješenja", daju se metode sistematskog pristupa za rješavanje nastalih problema.

Uvod

Filter paketa izvršava politiku filtriranja zaobilazeći skup pravila i, shodno tome, blokira ili dozvoljava pakete. Poglavlje objašnjava kako provjeriti da li se politika filtriranja izvršava ispravno i kako pronaći greške ako nije.

Uopšteno govoreći, kroz ovo poglavlje upoređivaćemo zadatak pisanja skupa pravila filtriranja sa programiranjem. Ako nemate vještine programiranja, onda će vam se ovo poređenje učiniti težim. Ali pisanje pravila ne zahtijeva diplomu informatike ili iskustvo u programiranju samo po sebi, zar ne?

Odgovor je ne, vjerovatno vam to ne treba. Jezik koji se koristi za konfigurisanje filtera paketa je sličan ljudskim jezicima. Na primjer:

blokirati sve

proslijediti sve zadržati stanje

proslijediti proto tcp na bilo koji port www keep state

Zapravo, ne morate imati programera u blizini da biste razumjeli šta ovaj set radi, ili čak, koristeći intuiciju, da biste napisali takvu politiku filtriranja. Postoji čak i velika šansa da će skup pravila filtriranja kreiranih na ovaj način izvršiti radnje koje je njegov autor imao na umu.

Nažalost, računari rade samo ono što od njih tražite, a ne ono što želite da urade. Još gore, neće moći razlikovati ono što se želi od onoga što je stvarno, ako postoji takva razlika. To znači da ako računar ne radi ispravno ono što želite, čak i ako mislite da ste jasno opisali uputstva, u vašim je rukama da pronađete razlike i promenite uputstva. A pošto je ovo uobičajen problem u programiranju, možemo vidjeti kako se programeri nose s njim. Ispostavilo se da su vještine i metode koje se koriste za testiranje i otklanjanje grešaka u programima i pravila filtriranja vrlo slične. Ipak, ovdje vam nije potrebno poznavanje bilo kojeg programskog jezika da biste razumjeli implikacije za testiranje i otklanjanje grešaka.

Dobra politika filtriranja.

Politika filtriranja je neformalna specifikacija onoga što želimo da zaštitni zid radi. S druge strane, skup pravila, implementacija specifikacije, je skup standardnih instrukcija, program koji izvršava mašina. Shodno tome, da biste napisali program, morate definisati šta on treba da radi.

Dakle, prvi korak u konfiguraciji firewall-a je neformalno definiranje onoga što treba postići. Koje veze treba blokirati ili dozvoliti?

Primjer bi bio:

Postoje tri mreže koje moraju biti odvojene jedna od druge zaštitnim zidom. Sve veze s jedne mreže na drugu prolaze kroz zaštitni zid. Firewall ima 3 interfejsa, od kojih je svaki povezan na odgovarajuću mrežu:

$ ext_if - na vanjsku mrežu.

$ dmz_if - DMZ sa serverima.

$ lan_if - LAN sa radnim stanicama.

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

Serveri u DMZ-u bi trebali biti u mogućnosti da slobodno komuniciraju sa domaćinima na vanjskoj mreži. Vanjski domaćini se mogu povezati samo sa sljedećim serverima u DMZ-u:

Web server 10.1.1.1 port 80

Mail server 10.2.2.2 port 25

Sve ostale veze treba zabraniti (na primjer, od strojeva na vanjskoj mreži do strojeva na LAN-u).

Ova politika je izražena neformalno tako da je svako čita može razumjeti. Trebao bi biti toliko specifičan da čitatelj može lako formulirati odgovore na pitanje oblika „Treba li se veza od hosta X do hosta Y proći kroz, dolaznu (ili odlaznu) na Z sučelju?“. Ako razmišljate o slučajevima kada vaša polisa ne ispunjava ovaj uslov, onda to nije dovoljno jasno.

"Maglovita" pravila poput "dozvoliti samo ono što je vitalno" ili "blokirati napade" moraju biti razjašnjena, inače ih nećete moći primijeniti ili testirati. Kao iu razvoju softvera, nedovoljno formalizirani zadaci rijetko dovode do opravdanih ili ispravnih implementacija. (“Zašto ne odeš i ne počneš pisati kod, a ja ću shvatiti šta klijentu treba”).

Skup pravila koja provode 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 mašinskog koda od strane kompajlera, "izvor" skupa pravila obrađuje pfctl, a rezultat interpretira pf u kernelu.

Kada izvorni kod krši pravila formalnog jezika, analizator prijavljuje sintaksičku grešku i odbija dalju obradu datoteke. Ova greška je greška u vremenu kompajliranja i obično se brzo popravlja. Kada pfctl ne može raščlaniti vašu datoteku skupa pravila, ispisuje red s greškom i više ili manje informativnom porukom koju nije mogao raščlaniti. Dok se cijeli fajl ne obradi bez pojedinacna greska, pfctl neće promijeniti prethodni skup pravila u kernelu. A pošto datoteka sadrži jednu ili više sintaksičkih grešaka, ne postoji "program" koji pf može pokrenuti.

Druga vrsta greške naziva se "greške u toku izvođenja" jer se javlja kada je sintaktički ispravan program napisan i uspješno preveden i izvršen. V opšti slučaj, u programskim jezicima, ovo se može dogoditi kada program izvrši dijeljenje nulom, pokuša pristupiti nevažećim područjima memorije ili ostane bez memorije. Ali pošto skupovi pravila samo nejasno podsjećaju na funkcionalnost programskih jezika, većina ovih grešaka se ne može pojaviti tokom primjene pravila, na primjer, pravila ne mogu uzrokovati tzv. "System crash", kao i uobičajeni programi. Međutim, skup pravila može uzrokovati slične greške, u obliku blokiranja, ili obrnuto, prosljeđivanja paketa koji nisu u skladu sa politikom. Ovo se ponekad naziva booleova greška, greška koja ne uzrokuje izuzetak ili prekid, već jednostavno daje netačne rezultate.

Dakle, prije nego što počnemo provjeravati koliko ispravno firewall implementira našu sigurnosnu politiku, moramo prvo uspješno učitati skup pravila.

Greške analizatora

Greške parsera se javljaju kada pokušavate učitati listu pravila koristeći pfctl, na primjer:

# pfctl -f /itd /pf.konf

/ itd /pf.konf: 3:sintaksagreška

Ova poruka ukazuje da postoji sintaksička greška u redu 3 /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 varijanti pfctl grešaka. Da biste započeli sa pfctl-om, samo ih trebate pažljivo pročitati. Možda vam svi dijelovi poruke neće odmah otkriti svoje značenje, ali morate ih sve pročitati, jer kasnije će biti lakše razumjeti šta je pošlo po zlu. Ako poruka sadrži dio forme "ime datoteke: broj: tekst", ona se odnosi na red s odgovarajućim brojem u navedenoj datoteci.

Sljedeći korak je da pogledate prikazanu liniju pomoću uređivača teksta (u vi možete ići na red 3 unosom 3G u bip modu), ili ovako:

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

1 int_if = "fxp 0"

2 blokiraju sve

3 se onesvijestiti na $ int_if inet all kep stanje

proslijediti inet na $ int_if sve kep stanje

Problem bi mogao biti obična greška u kucanju, kao u ovom slučaju („kep“ umjesto „keep“). Nakon popravljanja, pokušajte ponovo učitati fajl:

# pfctl -f /itd /pf.konf

/ itd /pf.konf: 3:sintaksagreška

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

proslijediti inet na $ int_if svi zadržavaju stanje

Sada su sve ključne riječi tačne, ali nakon detaljnijeg pregleda, primjećujemo da je pozicioniranje ključne riječi “inet” prije “on $ int_if” pogrešno. Ovo ilustrira da jedan red može sadržavati više od jedne greške. Pfctl ispisuje prvu grešku koju pronađe i prestaje da se izvršava. Ako je isti broj linije izdat prilikom ponovnog pokretanja, to znači da u njemu ima više grešaka ili prethodne nisu ispravno otklonjene.

Pogrešno postavljene ključne riječi su također česta greška. Ovo se može vidjeti upoređivanjem pravila sa BNF referentnom sintaksom na kraju pf.conf (5) man stranice, koja sadrži:

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

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

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

hostovi [filteropt-list]

ifspec = (["!"] ime interfejsa) | "(" lista-interfejsa ")"

af = "inet "|"inet6 "

Što znači da ključna riječ Inet mora pratiti $ int_if

Popravimo to i pokušajmo ponovo:

# pfctl -f /itd /pf.konf

/ itd /pf.konf: 3:sintaksagreška

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

onesvijestiti se na $ int_if inet svi zadržavaju stanje

Sada nema očiglednih grešaka. Ali ne vidimo sve prateće detalje! Linija zavisi od definicije makroa $ inf_if. Šta se može pogrešno identificirati?

# pfctl -vf /etc/pf.conf

int_if = "fxp 0"

blok ispusti sve

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

Nakon što ispravite grešku u kucanju "fxp 0" u "fxp0", pokušajte ponovo:

# pfctl -f /itd /pf.konf

Odsustvo poruka znači da je datoteka uspješno preuzeta.

U nekim slučajevima, pfctl može izdati specifičnije poruke o grešci od samo "greške u sintaksi":

# 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 na nevažeću kombinaciju

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

proslijediti na $ int_if na port ssh zadržati stanje

Prvi red poruke o grešci je najinformativniji u odnosu na ostale. U ovom slučaju, problem je što pravilo koje navodi port ne definiše protokol - tcp ili udp.

U rijetkim slučajevima, pfctl obeshrabruje prisustvo znakova koji se ne mogu ispisati ili nepotrebnih razmaka u datoteci, takve greš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 greška

# cat -ent /etc/pf.conf

1 blok svih $

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

3 ^ Ikeepstanje $

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

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

$ cat /etc/pf.conf

blokirati sve

# prelaz sa bilo kojeg na bilo koji \

prijeći sa 10.1.2.3 na bilo koji

$ pfctl -f /etc/pf.conf

$ pfctl -sr

blokdropsve

"Obratna kosa crta" na kraju reda komentara zapravo znači da će se red za komentare nastaviti ispod.

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

$ cat /etc/pf.conf

prijeći sa (! 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.4tobilo 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 sa bilo kojom mogućom adresom.

Morate ponovo učitati svoj skup pravila nakon trajnih promjena kako biste osigurali da ga pfctl može učitati kada ponovo pokrenete stroj. Na OpenBSD-u, skripta za pokretanje rc iz / etc / rc prvo učitava mali skup zadanih pravila koja blokiraju sav promet osim onih potrebnih u vrijeme pokretanja (kao što su dhcp ili ntp). Ako skripta ne uspije učitati pravi skup pravila iz /etc/pf.conf zbog sintaksičkih grešaka uvedenih prije ponovnog pokretanja stroja bez provjere, tada će zadani skup pravila ostati aktivan. Na sreću, ovaj set omogućava dolazne ssh konekcije, tako da se problem može riješiti na daljinu.

Testiranje

Pošto imamo izuzetno precizno definisanu politiku, i skup pravila koja je moraju implementirati, onda će pojam testiranje u našem slučaju značiti usklađenost rezultujućeg skupa sa datom politikom.

Postoje samo dva načina da pravila ne funkcionišu: blokiranje veza koje treba dozvoliti i obrnuto, propuštanje onih veza koje bi trebale biti blokirane.

Testiranje općenito podrazumijeva sistematski pristup uređenom kreiranju različite vrste veze. Nemoguće je provjeriti sve moguće kombinacije izvora/destinacije i odgovarajućih portova na sučeljima, jer zaštitni zid bi se teoretski mogao sudariti veliki iznos takve kombinacije. Osiguravanje da je skup pravila u početku ispravan može se osigurati samo za vrlo jednostavnim slučajevima... U praksi, najbolje rješenje bi bilo kreiranje liste testnih veza zasnovanih na sigurnosnoj politici tako da se utiče na svaku tačku politike. Dakle, za našu politiku primjera, lista testova će biti sljedeća:

LAN na DMZ vezu (mora se preskočiti)

sa LAN-a na vanjsku mrežu (mora biti proslijeđen)

sa DMZ na LAN (treba biti blokiran)

sa DMZ-a na vanjsku mrežu (treba proslijediti)

sa vanjske mreže na DMZ do 10.1.1.1 na portu 80 (treba preskočiti)

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

sa vanjske mreže na DMZ na 10.2.2.2 na port 80 (treba biti blokiran)

sa vanjske mreže na DMZ na 10.2.2.2 na port 25 (treba proslijediti)

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

Očekivani rezultat mora biti naveden u ovoj listi prije testiranja.

Možda zvuči čudno, ali cilj svakog testa je pronaći greške u implementaciji skupa pravila zaštitnog zida, a ne samo navesti da nedostaju. A krajnji cilj procesa je da se izgradi skup pravila bez grešaka, pa ako sumnjate da ovdje može biti grešaka, bolje ih je pronaći nego preskočiti. A ako ipak preuzmete ulogu testera, morate se držati destruktivnog stila razmišljanja i pokušati zaobići ograničenja firewall-a. I sama činjenica da se ograničenja ne mogu prekinuti bit će obrazloženi dokaz da je skup pravila bez grešaka.

TCP i UDP veze se mogu provjeriti pomoću nc. nc se može koristiti kao klijent i server (koristeći opciju -l). I za ICMP zahtjeve i odgovore, najbolji klijent ping će se obaviti radi provjere.

Bilo koja sredstva koja će pokušati stvoriti veze sa serverom mogu se koristiti za provjeru da je veza blokirana.

Koristeći alate iz kolekcije portova kao što je nmap, možete lako skenirati više portova čak i na više hostova. Ako rezultati ne izgledaju baš jasni, nemojte biti lijeni da pogledate man stranicu. Na primjer, na TCP portu, skener vraća 'nefiltriran' kada nmap primi RST od pf-a. Takođe, pf instaliran na istoj mašini kao i skener može uticati na ispravnost nmap-a.

Sofisticiraniji alati za skeniranje mogu uključivati ​​alate za kreiranje fragmentiranih ili slanje nevažećih IP paketa.

Da biste provjerili da li filter propušta veze navedene u politici, najbolji način je provjeriti korištenjem aplikacija koje će klijenti kasnije koristiti. Dakle, provjerava prolaznost http konekcija sa različitih klijentskih mašina web servera, kao i sa različitim pretraživačima i uzorkovanje različit sadržaj bilo bi bolje nego samo potvrditi uspostavljanje TCP sesije nc-u koji radi kao pozadina. Različiti faktori kao što je operativni sistem domaćina takođe mogu uzrokovati greške – probleme sa skaliranjem TCP prozora ili TCP SACK odgovorima između određenih operativnih sistema.

Kada se prođe sljedeća tačka testiranja, njeni rezultati možda neće uvijek biti isti. Veza može biti prekinuta tokom procesa uspostavljanja veze ako firewall vrati RST. Uspostavljanje veze može jednostavno isteći. Veza se može u potpunosti uspostaviti, raditi, ali nakon nekog vremena zamrznuti ili prekinuti. Veza se može održati, ali propusnost ili kašnjenje mogu biti različiti od očekivanih, viši ili niži (u slučaju da koristite AltQ za ograničavanje propusnosti).

Kao očekivani rezultati, pored preskakanja/blokiranja konekcije, može se uočiti i da li su paketi evidentirani, kako se emituju, rutiraju, da li su potrebni brojači povećani, 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 za performanse, odgovor na zagušenje i toleranciju grešaka. I mogu zahtijevati odvojene testove. Ako konfigurišete sistem otporan na greške koristeći CARP, verovatno želite da znate šta se dešava kada se dogode različite vrste kvarova.

Kada vidite rezultat koji se razlikuje od onoga što ste očekivali, korak po korak označite svoje korake tokom testa, šta ste očekivali, zašto ste to očekivali, dobijeni rezultat i koliko se rezultat razlikuje od vaših očekivanja. Ponovite test da vidite da li je situacija ponovljiva ili se s vremena na vrijeme razlikuje. Pokušajte promijeniti ulazne parametre provjere (izvorna / odredišna adresa ili portovi).

Od trenutka kada dobijete ponovljiv problem, morate započeti otklanjanje grešaka kako biste shvatili zašto stvari ne rade kako ste očekivali i kako sve "popraviti". Sa ovim podešavanjem morate promijeniti skup pravila i ponoviti sve testove, uključujući i one koji nisu uzrokovali greške, jer bi promjena pravila mogla nenamjerno utjecati na funkcionisanje ispravno radnih dijelova skupa pravila.

Isti princip vrijedi i za ostale promjene u kompletu. Ova formalna procedura pregleda će pomoći da proces bude manje podložan uvođenju grešaka. Možda neće biti potrebno ponavljati cijeli postupak za male promjene, ali zbir nekoliko malih promjena može utjecati na ukupni rezultat obrade skupa. Možete koristiti sistem kontrole verzija kao što je cvs za rad sa vašim konfiguracionim fajlom, pošto ovo će pomoći u istraživanju promjena koje su dovele do greške. Ako znate da se greška nije dogodila prije nedelju dana, ali sada jeste, pregledajte sve promjene koje ste napravili prošle sedmiceće vam pomoći da uočite problem ili se barem vratite na trenutak njegovog odsustva.

Netrivijalni skupovi pravila mogu se smatrati programima, rijetko su savršeni u svom prvom izdanju i potrebno je vrijeme da se sa sigurnošću izjavi da su bez grešaka. Međutim, za razliku od običnih programa, koje većina programera nikada ne smatra bez grešaka, skupovi pravila su i dalje dovoljno jednostavni da se približe ovoj definiciji.

Otklanjanje grešaka

Termin otklanjanje grešaka obično se odnosi na pronalaženje i popravljanje programskih grešaka u kompjuterskim programima. Ili, u kontekstu skupova pravila zaštitnog zida, termin bi značio proces traženja razloga zašto skup ne daje željeni rezultat. Postoji nekoliko vrsta greš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 prirodu problema. Ako ste sami uočili grešku tokom testiranja, vrlo je jednostavno. Ali ako vam druga osoba kaže za grešku, postavljanje jasnog cilja iz netačnog izvještaja o grešci može biti zastrašujući zadatak. Najbolje mjesto za početak je da sami reprodukujete grešku.

Mrežni problemi ne moraju uvijek biti uzrokovani filterom paketa. Prije nego što se fokusirate na otklanjanje grešaka u pf konfiguraciji, morate se uvjeriti da je problem uzrokovan filterom paketa. Ovo je lako učiniti, a može vam uštedjeti i vrijeme za rješavanje problema na drugim mjestima. Samo isključite pf komandom pfctl -d i provjerite da li se problem ponovo pojavljuje. Ako je tako, omogućite pf sa pfctl -e i pogledajte šta će se dogoditi. Ova metoda neće uspjeti u nekim slučajevima, na primjer, ako pf ne izvrši ispravan prijevod. mrežne adrese(NAT) onda isključivanje pf-a očito vas neće spasiti od greške. Ali gdje je moguće, pokušajte se uvjeriti da je filter paketa krivac.

Prema tome, ako je problem u filteru paketa, prva stvar koju treba učiniti je osigurati da 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 grešaka: Hitno

# pfctl -sr

brzo proći na lo0 all

brzo proći na enc0 all

Otklanjanje grešaka po protokolima

Sljedeći korak u otklanjanju grešaka je odraz problema na određenim mrežnim vezama. Ako imate premisu: "Instant poruka u aplikaciji X ne radi", morate saznati koje mrežne veze se koriste. Zaključak može biti "host A ne može uspostaviti vezu sa hostom B na portu C." Ponekad je ovaj zadatak najteži, ali ako imate informacije o potrebnim konekcijama i znate da ih firewall neće propustiti, samo trebate 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 u i izvan stvarnog mrežnog interfejsa, kao i virtuelne, kao što su pflog i pfsync. Možete odrediti izraz za filtriranje da odredite koje pakete želite prikazati i eliminirati neželjenu mrežnu buku. 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 iz uspostavljene TCP veze (TCP rukovanje).

Pošiljalac je 10.1.2.3 port 65123 (izgleda kao nasumični neprivilegirani port), a primalac je 10.2.3.4 port 6667. Za detaljno objašnjenje tcpdump izlaznog formata, pogledajte stranice priručnika za uslužni program. Tcpdump je najvažniji alat za otklanjanje grešaka u pf-u i veoma je važno da se upoznate sa njim.

Druga metoda je korištenje funkcije evidentiranja u pf. Pod pretpostavkom da koristite opciju 'log' na svim pravilima sa 'blokiranjem', tada će svi paketi blokirani od strane pf-a biti evidentirani. Možete ukloniti opciju ‘log’ iz pravila koja se bave poznatim protokolima, tj. samo oni paketi koji idu na nepoznate portove će biti evidentirani. Pokušajte koristiti aplikaciju koja ne može komunicirati i pogledajte pflog:

# ifconfig pflog0 up

# tcpdump -nettti pflog0

Nov 26 00: 02: 26.723219 pravilo 41/0 (utakmica): blok 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 pohranjuje rezultirajuće informacije u / var / log / pflog, možete vidjeti zabilježene informacije ovako:

# tcpdump -netttr /var /log /pflog

Kada prikazujete pakete pohranjene u pf-u, možete koristiti dodatne izraze za filtriranje, na primjer, pogledati pakete koji su blokirani na ulazu na wi0 sučelju:

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

Nekim protokolima, kao što je FTP, nije lako ući u trag jer ne koriste fiksne brojeve portova ili koriste više veza koje koegzistiraju. Možda ih neće biti moguće proći kroz zaštitni zid bez otvaranja širokog spektra portova. Za neke protokole postoje rješenja slična ftp-proxy-u.

Pravila za otklanjanje grešaka

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

Na primjer, vaš skup sadrži pravilo

blok u return-rst na $ ext_if proto tcp od bilo kojeg do $ ext_if porta ssh

Ali kada pokušate da se povežete na TCP port 22, veza je prihvaćena! Izgleda da zaštitni zid ignorira vaše pravilo. Kao i kod sastavljanja "slagalice", u ovim slučajevima, kada se s njima suočite prvih nekoliko puta, postoji jednostavno logično i obično trivijalno objašnjenje.

Prvo, trebali biste provjeriti sve ranije navedene korake. Na primjer, pretpostavimo da je zaštitni zid pokrenut i da sadrži pravilo iznad. Malo je vjerovatno da su naše prethodne zabrinutosti valjane, ali ovo je lako provjeriti:

# pfctl -si | grep Status

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

# pfctl -gsr | grep "port = ssh"

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

Sljedeća stvar koju imamo je da se TCP veze prihvataju na portu 22 na kue0. Možda mislite da je to već očigledno, ali neće biti suvišno provjeriti. Pokreni tcpdump:

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

Sada pokušajte ponovo sa SSH konekciju. Trebali biste vidjeti pakete iz vaše veze u tcpdump izlazu. Možda ih nećete vidjeti, a to može biti zato što veza zapravo ne prolazi kroz kue0, već ide kroz drugačiji interfejs, što objašnjava zašto se pravilo ne pokreće. Ili se možda povezujete na drugu adresu. Ukratko, ako ne vidite ssh pakete, onda ih ni pf neće vidjeti, možda ih ne može blokirati koristeći pravilo dato u našem zadatku.

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

Kada pravilo možda nije posljednje pravilo koje se podudara? Postoje tri moguća razloga:

A) pravilo ne funkcioniše, pošto gledanje pravila ne dostiže ono što nam je potrebno.

Prethodno prisutno pravilo također se pokreće i uzrokuje prekid s opcijom 'brzo';

B) pravilo je obrađeno, ali pravilo ne radi zbog neslaganja između određenih kriterijuma.

C) pravilo se obrađuje, pravilo se pokreće, ali se obrada nastavlja i naredna pravila se također pokreću za paket.

Da biste odbili 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 grešaka. Počnite prelaskom prvog pravila. Da li se poklapa? Ako da, označite. Ima li 'brzo' opciju? Ako je tako, onda prestajemo zaobilaziti. Ako ne, nastavite sa slijedeće pravilo... Ponavljajte test sve dok se ne poklopi s opcijom „brzo“ ili do kraja skupa pravila. Koje je pravilo posljednje usklađeno? Ako to nije pravilo broj 14, pronašli ste objašnjenje za problem.

Ručno zaobilaženje pravila može izgledati zabavno, međutim, ako imate dovoljno iskustva, to se može učiniti dovoljno brzo i sa visokim stupnjem pouzdanosti. Ako je set dovoljno velik, možete ga privremeno skratiti. Sačuvajte kopiju stvarne liste pravila i izbrišite sve unose za koje mislite da neće uticati na rezultat. Preuzmite ovaj komplet i provjerite ponovo. Ako je veza sada blokirana, onda su pravila koja su izgledala nepovezana sa traženim paketima odgovorna za slučajeve A ili B. Dodajte pravila jedno po jedno, ponavljajući test dok ne pronađete ono koje želite. Ako je veza i dalje preskočena nakon brisanja pravila koja ne utječu na nju, ponovite mentalni obilazak smanjenog skupa.

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

Praćenje veza kroz zaštitni zid

Kada veza prolazi kroz zaštitni zid, paketi stižu na jedan interfejs i šalju se preko drugog. Odgovori dolaze do drugog interfejsa i idu na prvi. Tako se veze mogu prekinuti u svakom od ova četiri slučaja.

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

Ako SYN slanje nije blokirano, trebali biste vidjeti SYN + ACK kako ulaze na drugom interfejsu i izlaze na prvom. Ako nije, pf blokira SYN + ACK na nekom interfejsu.

Dodajte opciju ‘log’ pravilima koja moraju dozvoliti SYN i SYN + ACK na oba sučelja i pravilima koja ih moraju blokirati. Pokušajte se ponovo povezati i provjerite pflog. On treba da razjasni u kom slučaju dolazi do blokiranja i po kom pravilu.

Otklanjanje grešaka u stanju veze

Najčešći razlog zašto pf blokira pakete je taj što u skupu postoji redundantno pravilo blokiranja. Pravilo podudaranja koje se pokreće pri posljednjem podudaranju 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, dešava se da pf tiho ispušta pakete na osnovu nepravila, a ovdje dodavanje 'log-a' svim pravilima neće uzrokovati da ispušteni paketi odu u pflog. Često se paket skoro, ali ne u potpunosti, podudara sa unosom stanja.

Zapamtite da za svaki paket koji obrađuje, filter paketa vrši skeniranje tablice stanja. Ako se pronađe odgovarajući unos, paket se odmah preskače, a da ne uzrokuje da sam obradi skup pravila.

Unos tablice stanja sadrži informacije specifične za jednu vezu.

Svaki unos ima jedinstveni ključ. Ovaj ključ se sastoji od nekoliko vrijednosti koje su konstantne tokom cijelog vijeka trajanja veze. Evo ih:

• Vrsta adrese (Ipv4 ili Ipv6)
• Izvorna adresa
• Adresa primaoca
• Protokol (TCP UDP)
• Izvorni port
• Port za prijemnik

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

Kada se za kreiranje unosa u tabeli stanja koristi opcija 'čuvaj stanje', zapis veze se čuva pomoću ključa te veze. Važno ograničenje za tabelu stanja je da svi ključevi moraju biti jedinstveni. One. ne mogu postojati dva zapisa sa istim ključevima.

Možda nije odmah očigledno da ista dva hosta ne mogu uspostaviti više koegzistirajućih veza koristeći iste adrese, protokole i portove, ali ovo je fundamentalno svojstvo i TCP i UDP. U stvari, TCP/IP stekovi mogu povezati samo pojedinačne pakete sa svojim utičnicama dohvaćanjem na osnovu adresa i portova.

Čak i ako je veza zatvorena, isti par adresa i portova se ne može odmah ponovo koristiti. Ponovo poslani paketi mogu kasnije biti isporučeni od strane mrežne opreme, a ako ih je primateljev TCP/IP stog pomiješao sa paketima novostvorene veze, to bi spriječilo ili čak prekinulo novu vezu. Iz tog razloga, oba hosta moraju čekati određeno vrijeme koje se zove 2MSL (dvostruko duži životni vijek segmenta) prije nego što mogu ponovo koristiti iste adrese i portove za novu vezu.

Ovo svojstvo možete promatrati ručnim uspostavljanjem više konekcija na isti host. Na primjer, imati web server koji radi na 10.1.1.1 i portu 80 i dvaput se povezati sa 10.2.2.2. koristeći nc:

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

Povezivanje sa 10.1.1.1 80 portom je uspjelo!

Dok su veze otvorene, možete koristiti netstat na klijentu ili serveru za prikaz informacija o ovim vezama:

$ 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 vidite, klijent je izabrao dva različita (slučajna) izvorna porta, tako da ovo ne krši zahtjev za jedinstvenost ključa.

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

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

Povezivanje sa 10.1.1.1 80 portom je uspjelo!

nc: vezanje nije uspjelo: Adresa se već koristi

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

Vratimo se na mjesto gdje pf ispituje tabelu stanja u trenutku kada paket počinje filtrirati. Zahtjev se sastoji iz dva koraka. Prvi zahtjev je pronaći unos u tablici zapisa sa ključem koji odgovara protokolu, adresama i portu paketa. Potraga će se vršiti za pakete koji idu u bilo kojem smjeru. Pretpostavimo da je paket ispod kreirao unos tabele stanja:

dolazniTCPod 10.2.2.2:28054do 10.1.1.1:80

Upit u tabeli će pronaći sljedeće unose u tabeli 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

Zapis u tabeli uključuje informacije o smjeru (ulazni ili odlazni) prvog paketa koji je kreirao zapis. Na primjer, sljedeći zapisi se neće podudarati:

odlazniTCPod 10.2.2.2:28054do 10.1.1.1:80

dolazniTCPod 10.1.1.1:80do 10.2.2.2:28054

Razlog za ova ograničenja nije očigledan, ali prilično jednostavan. Zamislite da imate samo jedno sučelje na 10.1.1.1 gdje web server sluša na portu 80. Kada se 10.2.2.2 klijent poveže koristeći nasumični odlazni port 28054, prvi paket veze stiže na vaš interfejs i svi vaši odlazni odgovori bi trebali otići sa 10.1.1.1:80 do 10.2.2.2:28054. Nećete dozvoliti odlazne pakete od 10.2.2.2:28054 do 10.1.1.1:80, pošto su takvi paketi besmisleni.

Ako je vaš firewall konfigurisan za dva interfejsa, onda posmatrajući pakete koji prolaze kroz njega, videćete da svaki paket koji stigne na prvi interfejs izlazi i kroz drugi. Ako kreirate zapis stanja u kojem početni paket stiže na prvo sučelje, tada će taj zapis spriječiti da isti paket napusti drugo sučelje jer je u pogrešnom smjeru.

Kada pokušaj pronalaženja paketa među unosima u tabeli stanja ne uspije, prelazi se na listu pravila filtera. Morate izričito dozvoliti da paket izađe kroz drugi interfejs sa posebnim pravilom. U ovom pravilu najvjerovatnije koristite 'zadrži stanje' tako da drugi unos u tabeli stanja pokriva i cijelu vezu na drugom sučelju.

Možda se pitate kako je moguće kreirati drugi zapis u tabeli kada smo upravo objasnili da zapisi moraju imati jedinstvene ključeve. Objašnjenje ovdje je da zapis sadrži i informacije o smjeru veze, a kombinacija toga sa ostalim podacima mora biti jedinstvena.

Sada ćemo također moći objasniti razliku između labave veze i veze vezane za interfejs. Po defaultu, pf kreira unose koji nisu vezani ni za jedan interfejs. Stoga, ako dozvolite veze na jednom interfejsu, paketi koji se odnose na vezu i koji potpadaju pod unos u tabeli (uključujući informacije o pravcu paketa!) prolaze kroz bilo koji interfejs. U jednostavnim instalacijama sa statičkim usmjeravanjem, ovo su više teoretski proračuni. U osnovi, ne biste trebali vidjeti pakete jedne veze koji stižu kroz nekoliko interfejsa i pakete odgovora koji takođe napuštaju nekoliko interfejsa. Međutim, s dinamičkim usmjeravanjem, to je moguće. Zapise stanja možete vezati za određeno sučelje koristeći globalnu postavku 'set state-policy if-bound' ili opciju 'zadrži stanje (ako je vezano)' za svako pravilo. Ovo će osigurati da se paketi podudaraju samo sa unosima iz interfejsa koji je kreirao unose.

Ako koristite interfejse za tunele, tada ista veza prolazi kroz zaštitni zid 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 inkapsulirani na sučeljima A i D i dekapsulirani na B i C, tako da pf vidi pakete različitih protokola i možete kreirati 4 različita unosa u tabeli stanja. Bez enkapsulacije, paket će biti nepromijenjen na sva četiri interfejsa i nećete moći koristiti neke karakteristike, kao što je translacija adrese ili modulacija tcp rednog broja, jer će to dovesti do konfliktnih ključeva u tabeli stanja. Osim ako nemate kompletno podešavanje koje uključuje tunelirana sučelja i otklonjene greške poput "pf: src_tree insert failed", nećete moći smatrati da je vaša instalacija dovoljno uspješna. Vratimo se na ispitivanje tabele stanja za svaki paket prije provjere pravila. Zahtjev treba vratiti jedan zapis sa odgovarajući ključ, ili ne vratite ništa. Ako upit ne vrati ništa, prelazi se na listu pravila.

Ako se pronađe unos, drugi korak za TCP pakete je provjera rednog broja prije nego što se smatra da pripadaju određenoj vezi i filtriraju.

Tu 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, tako da ne može slušati legitimne pakete koje šalju hostovi. Međutim, on može slati pakete bilo kom od domaćina, imitirajući pakete svog sagovornika, pomoću lažiranja – krivotvorenja adrese pošiljaoca. Cilj napadača može biti da spriječi stvaranje veza između hostova, ili da prekine postojeće veze (da izazove uskraćivanje usluge), ili da stvori zlonamjerno opterećenje veza.

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

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

Tokom životnog vijeka važeće TCP veze, redni brojevi (i potvrde) za pojedinačne pakete se mijenjaju prema određenim pravilima.

Na primjer, ako domaćin pošalje određeni segment podataka, a njegov primalac potvrdi prijem, ne bi trebalo postojati razlog zašto bi pošiljatelj trebao ponovo poslati podatke segmenta. Ali, u stvari, pokušaj prepisivanja informacija koje je domaćin već primio nije kršenje. TCP protokol, iako to može biti oblik napada.

pf koristi pravila da odredi najmanji raspon za legitimne brojeve sekvence. Općenito, pf može precizno identificirati autentičnost samo 30.000 od 4294967296 mogući brojevi redosled u bilo kom trenutku veze. Samo ako redni broj i potvrda uđu u ovaj prozor će se uvjeriti da je paket legitiman i pustiti ga da prođe.

Ako se tokom upita prema tabeli stanja pronađe odgovarajući ulaz, na sljedeći korak redni brojevi paketa pohranjenih u tabeli se provjeravaju u odnosu na raspon moguće vrijednosti... Ako poređenje ne uspije, pf će generirati poruku "LOŠE stanje" i odbaciti paket bez procjene skupa pravila. Dva su razloga zašto se poređenje s pravilima možda neće dogoditi: gotovo je sigurno greška preskočiti paket, jer ako će izračunavanje skupa rezultirati pogađanjem opcije u pravilu "održavanje stanja" i pf neće moći suditi i stvarati novi ulaz jer će to dovesti do konfliktnih ključeva u tabeli.

Da biste vidjeli i napisali poruke "LOŠE stanje" u dnevnik, morate omogućiti način otklanjanja grešaka pomoću naredbe:

$ pfctl -xm

Poruke za otklanjanje grešaka se podrazumevano šalju na konzolu, a syslogd ih takođe zapisuje u / var / log / poruke. Potražite poruke koje počinju sa "pf":

pf:LOŠEstanje: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 tabeli stanja u trenutku kada je paket blokiran i redni broj paketa koji je izazvao grešku. Drugi unos prikazuje uslove koji su prekršeni.

Na kraju prve poruke vidjet ćete da li je kreiran statusni zapis za dolazni (dir = ulaz) ili odlazni (dir = izlaz) paket i da li je blokirani paket otišao u istom smjeru (dir =, fwd) ili suprotnom (dir =, rev ) smjeru.

Unos u tabeli sadrži tri adrese: parove portova, od kojih su dva uvek jednaka jedna drugoj, ako veza nije prošla nat, rdr ili bnat konverziju. Za odlazne veze izvor je prikazan na lijevoj strani, a odredište paketa na desnoj strani. Ako odlazna veza omogućava konverziju izvorne adrese, par u sredini označava izvor nakon konverzije. Za dolazne veze, izvor je desno u pinu, a odredište u sredini. Ako dolazna veza prolazi kroz prijevod odredišne ​​adrese, par ip / port na lijevoj strani pokazuje odredište nakon što je prijevod obavljen. Ovaj format odgovara izlazu pfctl -ss, sa jedinom razlikom što pfctl pokazuje smjer paketa pomoću strelica.

U izlazu možete vidjeti trenutne sekvence hosta u uglastim zagradama. Dakle, vrijednost "4:4" znači da je veza u potpunosti uspostavljena (niže vrijednosti su vjerovatnije u fazi uspostavljanja veze, veće vrijednosti - do trenutka zatvaranja veze)."A" znači da je blokirani paket imao postavljenu ACK zastavicu (kao u izlazu zastavica za tcpdump), praćenu vrijednostima brojeva sekvence (seq =) i (ack =) u blokiranim paketima i korisnim opterećenjem dužina paketa - dužina podataka (len =). askskew je dio internog prikaza podataka u tabeli, koji se koristi samo kada vrijednosti nisu jednake nuli.

Zapis "pkts = 930:631" znači da je upario 940 paketa u istom smjeru kao i onaj koji je izazvao ovaj zapis i 631 paket u suprotnom smjeru. Ovi brojači će biti posebno korisni kada se traže problemi u fazi uspostavljanja veze, ako je jedan od njih je nula, ovo bi bilo u suprotnosti sa vašim očekivanjima da će dati zapis odgovarati paketima koji idu u oba smjera.

Sljedeća poruka će sadržavati listu od jedne ili više cifara. Svaka cifra predstavlja provjeru na kojoj je došlo do greške:

1. veličina prozora paketa premašuje maksimalnu veličinu primaoca (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 u (1), ali sa razlikom (seq + len> high + win)
6. isto kao u (2), ali (sl< lo - maximum win)

Na sreću, poruke "LOŠE stanje" nisu povezane sa stvarnim svakodnevnim saobraćajem, a provjera rednog broja izbjegava većinu anomalija. Ako vidite da se ove poruke pojavljuju nepravilno i ne primijetite veliki broj visećih veza, možete ih jednostavno zanemariti. Postoji mnogo TCP/IP implementacija na Internetu, a neke od njih ponekad mogu generirati pogrešne pakete.

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

Kreiranje državnih zapisaTCP na početnomSYN paket.

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

Možete nametnuti upotrebu ovog pravila koristeći princip:

"Koristi" zastavice S/SA "opcije u svim" pass proto tcp zadržati stanje "pravila"

Samo (i jedini) početni SYN paketi imaju postavljenu SYN zastavicu i prikupljeni ACK. Kada se korištenjem opcije "čuvaj stanje" vezuju samo početni SYN paketi, samo ti paketi će kreirati unos u tabeli stanja. Stoga će svaki postojeći unos u tabeli stanja biti napravljen iz početnog SYN paketa.

Razlog za kreiranje zapisa samo za početne pakete je TCP ekstenzija nazvana "skaliranje prozora", definirana u RFC1323. Polje TCP zaglavlja koje se koristi za oglašavanje veličine primljenih prozora premalo je za današnje veze velike brzine. Moderne TCP/IP implementacije radije koriste veće veličine prozora nego što se mogu uklopiti u postojeće polje. Skaliranje prozora znači da sve veličine prozora koje su poznate od hosta primaoca treba pomnožiti sa određenom vrijednošću koju je dao primalac, a ne uzeti same. Da bi ova šema funkcionirala, oba hosta moraju podržavati proširenje i ukazati jedan drugome na svoju sposobnost da ga implementiraju u fazi rukovanja koristeći TCP opcije. Ove opcije su prisutne samo u početnim SYN i SYN + ACK paketima. I samo ako svaki od ovih paketa sadrži opciju, pregovaranje će biti uspješno i veličina prozora svih sljedećih paketa će biti pomnožena faktorom.

Ako pf ne bi "znao" o korištenom skaliranju prozora, uzeta bi se dostavljena vrijednost bez koeficijenta, a izračunavanje veličina prozora za prihvatljive vrijednosti rednih brojeva bi se izvršilo pogrešno. Obično domaćini pružaju male veličine prozora na početku veze i povećavaju ih tokom veze. Nesvjestan postojanja faktora koji mijenjaju veličinu prozora, pf će u jednom trenutku početi blokirati pakete, jer će pomisliti da jedan od hostova pokušava zaobići maksimalnu veličinu prozora koju daje "sagovornik". Efekti ovoga mogu biti manje ili više uočljivi. Ponekad će domaćini reagirati na gubitak paketa odlaskom na tzv. „Režim oporavka od gubitka“ i reklamiraće manju veličinu prozora. Nakon što pf ponovo odašilje pakete koji su odbačeni prvi put, veličine prozora će dalje rasti do tačke u kojoj ih pf ponovo počne blokirati. Vanjska manifestacija može biti privremeno zamrzavanje veza i loše performanse... Moguće također full hang ili resetirajte veze do isteka vremena.

Ali pf zna za mogućnost skaliranja prozora i podržava je. Međutim, preduvjet za kreiranje unosa u tablici stanja za prve SYN pakete je da pf može povezati prva dva paketa veze sa zapisom u tablici. A pošto se potpuno podudaranje koeficijenata veličine prozora dešava samo u ova prva dva paketa, ne postoji pouzdana metoda za određivanje ovih koeficijenata nakon pregovaranja veze.

U prošlosti, skaliranje prozora nije bilo široko korišteno, ali to se brzo mijenja. Tek nedavno je ova opcija omogućena po defaultu u Linuxu. Ako imate problema sa prekinutim vezama, posebno s nekim kombinacijama hosta, i vidite poruke "LOŠE stanje" koje se odnose na te veze, uvjerite se da zapravo kreirate unose u tablici stanja za prve pakete veze.

Možete reći da li pf koristi opciju skaliranja za spajanje iz pfctl izlaza:

$ pfctl -vss

kue0 tcp 10.1.2.3:10604 -> 10.2.3.4:80 USTANOVLJENO: USTANOVLJENO

wscale 0wscale 1

Ako je unos "wscale x" odštampan u drugom redu prisutan (čak i ako je x nula), pf reads zna da spajanje koristi skaliranje.

Još jedna jednostavna metoda za identifikaciju problema sa skaliranjem je privremeno onemogućiti podršku za skaliranje i ponoviti situaciju. Na OpenBSD-u, korištenje skaliranja može se kontrolirati sysctl opcijom:

$ sysctlnet.inet.tcp.rfc1323

net.inet.tcp.rfc1323 = 1

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

net.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 moulate state ili emitiranje. U oba slučaja, emitiranje se događa na početku veze. Ako se prvi paket ne emituje, emitovanje narednih obično obeshrabruje stranu koja prima i uzrokuje da pf blokira poslane odgovore sa porukom "LOŠE stanje".