Metodologjia e testimit

Testet u kryen në një PC eksperimental me Windows XP të licencuar me SP1 të instaluar (testet u kryen në kushte të idealizuara - "sistemi operativ + Firewall" për të përjashtuar ndikimin e programeve të tjera në pastërtinë e eksperimentit). Shërbimi APS u përdor si një tregues i aksesit të suksesshëm në shërbime. Si mjete të ndikimit të jashtëm u përdorën:

• Skaneri XSpider 6.5 dhe 7.0
• Skaneri i Sigurisë së Rrjetit Retina 4.9
• disa skanerë të dizajnit tim.

Për më tepër, u përdor sniffer CommView 4.1 (si një mjet monitorimi trafiku i rrjetit dhe si një mjet për gjenerimin dhe dërgimin e paketave me parregullsi të ndryshme strukturore). I ashtuquajturi. vërshues të llojeve të zakonshme, shërbime për imitimin e Trojans.

PC testues përdori IE 6 si një mjet për të hyrë në rrjet dhe internet, Outlook Express 6, TheBat 1.60, MSN Messanger 6.1. Përveç tyre, simulatorë të trojanëve dhe programeve të vërtetë trojan / Backdoor nga koleksioni im (në veçanti Backdoor.Antilam, Backdoor.AutoSpy, Backdoor.Death, Backdoor.SubSeven, Backdoor.Netbus, Backdoor.BO2K), viruset e rrjetit / postës ( I-Worm.Badtrans, I-Worm.NetSky, I-Worm.Sircam, I-Worm.Mydoom, I-Worm.MSBlast), shkarkues TrojanDownloader (në veçanti TrojanDownloader.IstBar) dhe komponentë SpyWare. Detyra kryesore e testeve ishte të përpiqeshim të shikonim Firewall-in përmes syve të një përdoruesi, të vini re pikat e forta dhe të dobëta të tij nga këndvështrimi im.

Kerio Technologies WinRoute Pro v4.2.5

Instalimi dhe çinstalimi:
Shkon pa probleme.
Instalimi me cilësimet e paracaktuara, pa rregulla - funksionon vetëm NAT. Rrjeti - nuk ka problem, rezultatet e skanimit - APS nuk tregon statusin e alarmit, skaneri mendon se të gjitha portat janë të mbyllura. Vetë Winroute nuk gjeneron alarme dhe nuk identifikon vizualisht faktin e skanimit.

Outpost Firewall Pro 2.1 Build 303.4009 (314)

Instalimi dhe çinstalimi:
Instalimi nën XP funksionon pa probleme, modaliteti i të mësuarit aktivizohet në fillim.

ZoneLabs ZoneAlarm Pro with Web Filtering 4.5.594.000 - Personal Firewall

Instalimi dhe çinstalimi:
Gjatë instalimit, XP u mbyll gjatë përpjekjes për të nisur pas instalimit. Pas rindezjes, gjithçka funksionoi mirë.

AtGuard 3.22>

Instalimi dhe çinstalimi:
Instalimi dhe çinstalimi nuk shkakton ndonjë problem të veçantë

Përparësitë:

1. Firewall i vogël në madhësi, ka një zgjidhje interesante nga pikëpamja e ndërfaqes - është bërë në formën e një paneli të vendosur në krye të ekranit

Disavantazhet dhe veçoritë:

1. I cenueshëm në modalitetin e trajnimit - që nga momenti kur shfaqet kërkesa për krijimin e një rregulli derisa të krijohet, ai kalon paketat në të dy drejtimet
2. Ndërfaqja është pak e gabuar kur rivizatoni dritaret

Vlerësimi i përgjithshëm:
Firewall i thjeshtë, por funksional

Kerio Personal Firewall 4

Instalimi dhe çinstalimi:
Instalimi vazhdon pa probleme, heqja është "e pastër" - nuk u vu re asnjë problem pas çinstalimit.

Norton Siguria e internetit 2004 (NIS)

Instalimi dhe çinstalimi: Instalimi nuk shkakton probleme, por nga të gjitha ato të analizuara, instaluesi është më i rëndë.

Firewall i lidhjes në internet, ICF - i integruar muri i zjarrit i Windows XP

Instalimi dhe çinstalimi: Nuk kërkohet instalim, është mjete të rregullta XP. Aktivizimi bëhet në cilësimet përshtatës rrjeti... Si parazgjedhje, ICF funksionon në modalitetin maksimal të sigurisë dhe (ky është rezultat i vëzhgimit tim) parimi i funksionimit të tij është si më poshtë - kërkesat e aplikacionit lëshohen jashtë, dhe vetëm paketat që kanë ardhur në përgjigje të kërkesave të mia pranohen jashtë ( korrespondenca kërkesë-përgjigje ruhet qartë në formën e një tabele dinamike). Kështu, kur skanoni portet në një kompjuter me ICF të aktivizuar, nuk ka asnjë portë të vetme të hapur (kjo është logjike - paketat e skanerit të portit nuk do të kalohen, pasi askush nuk i kërkoi ato). Situata është e ngjashme me llojet e ndryshme të "nuke" bazuar në dërgimin e paketave jo standarde

Firewall i lidhjes në internet, ICF - muri i zjarrit i integruar i Windows XP SP2

Instalimi dhe çinstalimi: Instalimi nuk kërkohet, është një mjet standard XP (i përfshirë në SP2 për XP). Aktivizimi bëhet në cilësimet e përshtatësit të rrjetit. Duhet të theksohet se kur instaloni SP2 ose kur instaloni XP me SP2 të integruar, përveç Firewall-it, në sistem shfaqet një Qendër Sigurie, e cila mund të tregojë cilësimet e ICF

Sygate Personal Firewall Pro 5.5 i ndërtuar 2525

Instalimi dhe çinstalimi:

ISS BlackIce 3.6.cci

Instalimi dhe çinstalimi: Instalimi i programit dhe çinstalimi i tij ndodh pa probleme, por gjatë instalimit ndodh një gabim në bibliotekën ikernel. I njëjti gabim ndodhi gjatë çinstalimit. Shfaqja e këtij gabimi nuk ndikon në instalimin dhe heqjen e programit. Instaluesi nuk kërkoi një rindezje të sistemit, gjë që është e pazakontë për një mur zjarri

Visnetic Firewall 2.2

Instalimi dhe çinstalimi: Instalimi i programit dhe çinstalimi i tij ndodh pa probleme. Pas instalimit kërkohet një rindezje.

Shikoni n ndaloni murin e zjarrit personal 2.05

Instalimi dhe çinstalimi: Instalimi i programit dhe çinstalimi i tij ndodh pa probleme. Pas instalimit kërkohet një rindezje. Instalon drejtuesin e vet për punë.

Kaspersky AntiHacker 1.5

Instalimi dhe çinstalimi: Instalimi i programit dhe çinstalimi i tij ndodh pa probleme. Pas instalimit kërkohet një rindezje.

Tiny Personal Firewall Pro 6.0

Instalimi dhe çinstalimi:
Instalimi i programit dhe çinstalimi i tij ndodh pa probleme. Pas instalimit kërkohet një rindezje.

McAfee Personal Firewall Plus 6.0 Build 6014

Instalimi dhe çinstalimi:
Instalimi i programit dhe çinstalimi i tij ndodh pa probleme. Pas instalimit kërkohet një rindezje.

R-Firewall 1.0 Ndërtimi 43

Instalimi dhe çinstalimi:
Instalimi i programit dhe çinstalimi i tij ndodh pa probleme. Madhësia e kompletit të shpërndarjes është e vogël (3.8 MB), ju mund të personalizoni përbërjen e produktit. Puna është mjaft e qëndrueshme, nuk u vunë re dështime dhe ngrirje të dukshme në PC-në e referencës

Përfundime dhe përfundime të përgjithshme

Pra, le të përmbledhim rezultatet e testeve. Në fakt, testet konfirmuan idetë e mia teorike për gjendjen e problemit:

1. Firewall-i duhet të konfigurohet... Të gjitha muret e zjarrit të testuar funksionuan mirë, por vetëm pas konfigurimit (trajnim, krijimi i cilësimeve me dorë - nuk ka rëndësi). Shfrytëzimi i një firewall të pakonfiguruar mund të bëjë më shumë dëm sesa dobi (do të kapërcejë paketat e rrezikshme dhe anasjelltas, do të ndërhyjë në programe të dobishme);
2. Pas Cilësimet e murit të zjarrit dhe IDS duhet të testohet- ky është gjithashtu një përfundim mjaft i qartë, por megjithatë është i rëndësishëm. Hapi i parë që bëra për të krijuar një testues ishte programi APS. Kanë mbetur edhe dy të tjera - një simulator i një programi trojan (d.m.th., një mjet që do të kryejë përpjekje të sigurta që përdoruesi të "thyejë" Firewall-in nga brenda (natyrisht, sulmet do të përshkruhen nga baza e të dhënave dhe do të jenë kryhet me komandën e përdoruesit nën kontrollin e tij), i cili do të lejojë monitorimin e reagimit Firewall dhe IDS) dhe një mjet për skanimin e shprehur të porteve dhe kryerjen e sulmeve bazë (në fakt, APS është pikërisht e kundërta - ato mund të kenë një bazë porti të përbashkët). Unë jam i angazhuar tashmë në zhvillimin e këtyre shërbimeve - prania e tyre në arsenalin e përdoruesit do të lejojë një "kontroll instrumental".
3. Firewall-i personal është i prekshëm ndaj malware që mbarojnë kontekstin. Përfundim - të paktën poshtë me panele të ndryshme "majtas" dhe BHO të tjera nga shfletuesi dhe e-mail !! Përpara se të instaloni ndonjë shtesë, panel, program shtesë, etj. ju duhet të mendoni dhjetë herë për domosdoshmërinë e tyre, tk. ato nuk janë procese të veçanta të sistemit operativ dhe ekzekutohen nga konteksti i programit prind... Kali i Trojës zbulohet lehtësisht nga Firewall-i personal - ai "sheh" që një proces (të themi, bo2k.exe) po përpiqet të fillojë të dëgjojë në portin xxxxx ose të shkëmbehet me një host të caktuar - lëshohet një kërkesë pranueshmërie, përdoruesi fillon të kuptoni se çfarë lloj "bo2k.exe është. "dhe Backdoor është kapur. Por nëse kali i Trojës do të largohej nga konteksti i shfletuesit, atëherë pothuajse me siguri askush nuk do t'i kushtonte vëmendje aksesit të shfletuesit në internet. Trojan të tillë ekzistojnë, shembulli më i afërt është TrojanDownloader.IstBar - është instaluar saktësisht si një shirit IE (natyrisht, nuk është në procese, është gjithashtu në listën autorun);
4. Shumë Firewall Personal janë të dukshëm si procese të sistemit operativ dhe mund të ndalohen nga një virus. Përfundim - puna e Firewall-it duhet të monitorohet dhe ndërprerja e papritur e tij mund të shërbejë si sinjal se një virus ka depërtuar në PC;
5. Disa mure zjarri (si Kerio) lejojnë kontrollin në distancë- funksion telekomandë duhet të jetë ose i çaktivizuar ose i mbrojtur me fjalëkalim.

Cilësimet e murit të zjarrit (firewall) të Windows janë kritike për të siguruar sigurinë e kompjuterit tuaj dhe të të dhënave të ruajtura në të kur punoni në internet dhe rrjete lokale. Operacioni i konfigurimit të murit të zjarrit kryhet duke përdorur metoda standarde të Windows dhe nuk kërkon speciale njohuri kompjuterike.

udhëzime

Klikoni butonin "Start" për të shfaqur menunë kryesore të sistemit dhe shkoni te artikulli "Paneli i Kontrollit".

Zgjeroni lidhjen e Windows Firewall dhe aplikoni kutinë e kontrollit Aktivizo (Rekomandohet) në skedën e Përgjithshme për të nisur murin e zjarrit.

Zgjidhni kutinë e kontrollit Mos lejoni përjashtime për të shtypur sinjalizimet e bllokimit dhe për të parandaluar krijimin e një liste përjashtimesh.

Shkoni te skeda "Përjashtimet" dhe aplikoni kutitë e kontrollit në fushat e aplikacioneve që dëshironi të lejoni lidhjet hyrëse.

Klikoni skedën Advanced për të çaktivizuar murin e zjarrit për një lidhje dhe cilësime specifike parametra shtesë filtrimi i protokollit ICMP.

Klikoni butonin "Default" për të rivendosur cilësimet origjinale të murit të zjarrit.

Përdorni krijimin automatik të përjashtimeve të aplikacionit kur nisni një program që pret një lidhje me një port të caktuar për të hyrë në rrjet.

Klikoni butonin Blloko në dritaren e Windows Security Alert për të bllokuar plotësisht lidhjen e aplikacionit të zgjedhur me rrjetin.

Klikoni butonin Zhblloko për të krijuar një rregull që lejon aplikacionin e zgjedhur të lidhet me rrjetin.

Klikoni butonin "Shtyre" për të refuzuar lidhjen në këtë moment.

Kthehuni te skeda Përjashtimet dhe klikoni butonin Shto program për të krijuar një rregull që lejon aplikacionin e zgjedhur të hyjë në rrjet nëse e dini paraprakisht se është e nevojshme.

Klikoni butonin Add Port për të krijuar një rregull për lidhjen nga rrjeti me shërbimin që funksionon në këtë port.

Klikoni butonin Change Scope për të vendosur gamën e adresave nga të cilat mund të krijohen lidhjet me aplikacionin ose portin e specifikuar.

Klikoni skedën Advanced dhe aplikoni kutitë e zgjedhjes në kutitë e lidhjes me rrjetin nën Cilësimet e lidhjes së rrjetit për të aktivizuar shërbimin Firewall për secilën prej tyre.

Testimi krahasues i 21 mureve të zjarrit të njohur për cilësinë e mbrojtjes kundër sulmeve që vijnë nga brenda sistemit. Në provë, mbrojtja u kontrollua duke përdorur 64 shërbime testimi të zhvilluara posaçërisht për të, të cilat kontrollojnë mbrojtjen e proceseve nga përfundimi, mbrojtjen nga sulmet standarde të brendshme, mbrojtjen nga rrjedhjet jo standarde dhe mbrojtjen kundër teknikave jo standarde për depërtimin në kernel. modaliteti.

Së bashku me antivirusin, muri i zjarrit është një nga komponentët kryesorë të sigurisë së kompjuterit. Megjithatë, ndryshe nga antiviruset, testet objektive të mureve të zjarrit kryhen rrallë. Ne u përpoqëm ta mbyllim këtë boshllëk duke kryer një test të murit të zjarrit për mbrojtjen nga sulmet e brendshme dhe një test të IDS/IPS personale për mbrojtje nga sulmet ndaj aplikacioneve të cenueshme në 2011 dhe 2012. Këtë vit, ne vendosëm të zgjerojmë listën e metodave të përdorura dhe të përsërisim testin e mureve të zjarrit për mbrojtje nga sulmet e brendshme në mënyrë që të shohim se si kanë ndryshuar rezultatet e produkteve të njohura gjatë kohës së kaluar sipas këtij kriteri.

Çfarë synon ky test ose çfarë funksionesh kryen muri i zjarrit? Sipas standardit të internetit [RFC3511] (2003), një mur zjarri është një sistem që zbaton funksionet e filtrimit të paketave të rrjetit në përputhje me rregullat e specifikuara në mënyrë që të diferencojë trafikun midis segmenteve të rrjetit. Megjithatë, me kompleksitetin në rritje të malware dhe sulmet e hakerëve, detyrat origjinale të murit të zjarrit u plotësuan me të reja modulet funksionale... Është praktikisht e pamundur të imagjinohet një mur zjarri i plotë pa modulin HIPS (monitorimi i ngjarjeve të sistemit, monitorimi i integritetit të sistemit, etj.).

Detyra kryesore e një muri zjarri modern është të bllokojë komunikimet e paautorizuara të rrjetit (në tekstin e mëtejmë të referuara si sulme), të ndara në të brendshme dhe të jashtme. Kjo perfshin:

Sulmet e jashtme në një sistem të mbrojtur nga muri i zjarrit:

• iniciuar nga hakerat;
• inicuar nga kodi me qëllim të keq.

• inicuar nga aplikacione të pabesueshme (kodi me qëllim të keq);
• inicuar nga aplikacione, aktiviteti i rrjetit të të cilëve është i ndaluar në mënyrë të qartë me rregulla.

Përveç kësaj, produktet që mund të klasifikohen si mure të pastra personale të zjarrit në formulimin klasik të 2003 janë zhdukur praktikisht nga tregu. Ato u zëvendësuan nga produkte komplekse për mbrojtjen e kompjuterëve personalë, të cilët domosdoshmërisht përfshijnë një komponent të murit të zjarrit.

Testi i murit të zjarrit për mbrojtjen nga sulmet e jashtme përfshin studimin e cilësisë së mbrojtjes kundër sulmeve që vijnë nga brenda sistemit. Testi u krye në fushat e mëposhtme:

1. Kontrollimi i mbrojtjes së proceseve nga përfundimi.
2. Mbrojtje kundër sulmeve standarde të brendshme.
3. Testimi i mbrojtjes kundër rrjedhjeve jo standarde.
4. Testimi i mbrojtjes kundër teknikave jo standarde të penetrimit në modalitetin e kernelit.

Krahasuar me testin e mëparshëm, numri i sulmeve të përdorura është zgjeruar ndjeshëm - nga 40 në 64. Sistemi operativ, i cili duhet të mbrohet nga produktet në testim, ka ndryshuar gjithashtu. Në testin e fundit ishte Windows XP, dhe në këtë test ishte Windows 7 x32. Një test i ngjashëm është planifikuar edhe në fund të vitit për sistemin operativ Windows 7 x64.

Prezantimi

Mori pjesë në testimin 21 program popullor mbrojtje gjithëpërfshirëse(Klasa e Sigurisë së Internetit, nëse nuk ka një produkt të tillë në linjë, atëherë është zgjedhur një mur i pastër zjarri) nga prodhues të ndryshëm versionet aktuale të produkteve që nga fillimi i testimit (maj 2013) dhe duke vazhduar Platforma Windows 7 x32 :

1. Avast! Siguria në Internet (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 Siguria e zgjuar (6.0.316.0).
8. F-Secure Internet Security (1.77 build 243).
9. G DATA Internet Security (1.0.13113.239).
10. Firewall personal Jetico (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) + Firewall i Windows.
15. Norton Internet Security (20.3.0.36).
16. Firewall Online Armor Premium (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).

Para fillimit të testit, u përgatit mjedisi i testimit. Për ta bërë këtë, sistemi operativ Windows 7 Enterprise SP1 x86 me të gjitha përditësimet e disponueshme në atë kohë, si dhe softuerin shtesë të kërkuar për testin, u instalua në një kompjuter të pastër.

Testimi u krye në dy lloje cilësimesh: standarde të rekomanduara nga prodhuesi (cilësimet e parazgjedhura) dhe maksimale. Në rastin e parë, janë përdorur cilësimet e paracaktuara të rekomanduara nga prodhuesit dhe janë kryer të gjitha veprimet e rekomanduara nga programi.

Në rastin e dytë, përveç kësaj, të gjitha cilësimet që ishin çaktivizuar në modalitetin "default", por në të njëjtën kohë mund të ndikonin në rezultatin e testit, u aktivizuan dhe / ose u sollën në pozicionin maksimal (cilësimet më të rrepta). Me fjalë të tjera, vendosja e cilësimeve maksimale nënkupton përkthimin e të gjithave të disponueshme nga ndërfaqe grafike përdoruesi konfiguron të gjitha modulet që lidhen me zbulimin e skedarëve me qëllim të keq ose aktivitetit të rrjetit në opsionin më të rreptë.

Testi i murit të zjarrit u krye në grupet e mëposhtme të sulmeve të brendshme, për qartësi, të ndara në nivele vështirësish:

1. Niveli bazë i vështirësisë (56 opsione sulmi):

1. kontrollimi i mbrojtjes së proceseve nga përfundimi (41 variante sulmesh);
2. mbrojtje kundër sulmeve standarde të brendshme (15 lloje sulmesh).

2. Niveli i rritur i vështirësisë (8 opsione për sulme):

1. testimi i mbrojtjes kundër rrjedhjeve jo standarde (3 lloje sulmesh);
2. testimi i mbrojtjes kundër teknikave jo standarde të depërtimit në modalitetin e kernelit (5 opsione sulmi).

Ju mund të gjeni një përshkrim të hollësishëm të të gjitha metodave të sulmit të përdorura në test në metodologjinë e testimit.

Kontrollimi i mureve të zjarrit për mbrojtje kundër sulmeve të brendshme

Kujtojmë se sipas skemës së shpërblimit të përdorur, 1 pikë (+) është dhënë nëse sulmi bllokohet automatikisht, funksionaliteti mbrojtës i programit të testuar nuk është shkelur. 0.5 pikë (ose +/-) - nëse sulmi bllokohet vetëm në rrethana të veçanta (për shembull, kur zgjedhja e duhur përdoruesi i veprimit të dëshiruar me kërkesë të programit në provë). Dhe, së fundi, nëse sulmi ishte i suksesshëm tërësisht ose pjesërisht me çaktivizimin e funksionit të mbrojtjes, atëherë nuk jepeshin pikë. Numri maksimal i mundshëm i pikëve të fituara në këtë test ishte 64.

Tabela 1-2 dhe Figura 1-2 tregojnë rezultatet e testimit të mureve të zjarrit veçmas për standarde dhe cilësimet maksimale... Për qartësi, rezultatet për çdo mur zjarri ndahen në dy grupe: mbrojtje kundër sulmeve të nivelit bazë të kompleksitetit dhe mbrojtje kundër sulmeve. nivel i rritur vështirësitë.

Tabela 1: Rezultatet e testimit të mureve të zjarrit në stdacilësimet e gojës

Produkt i testuar							Totali i pikëve (maksimumi 64)	Total %
	Pikat	%	% nga shuma	Pikat	%	% nga shuma
Comodo	53	95%	82,8%	6	75%	9,4%	59	92%
Forca të blinduara në internet	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%
Postë	45	80%	70,3%	2,5	31%	3,9%	47,5	74%
Trendi 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 TË DHËNAT	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%
Mjete PC	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%

Figura 1: Rezultatet e testimit të mureve të zjarrit në cilësimet standarde

Mbrojtja kundër sulmeve të brendshme në cilësimet e rekomanduara nga prodhuesi lë shumë për të dëshiruar. Vetëm tre mure zjarri ishin në gjendje të kapërcenin pragun prej 80% në cilësimet standarde - këto janë Comodo, Online Armor dhe Norton. Jetico (79%) dhe Outpost (74%) janë mjaft afër tyre. Rezultatet e pjesës tjetër të mureve të zjarrit doli të ishin dukshëm më të këqija.

Krahasuar me rezultatet e testit të fundit, të gjithë drejtuesit e konfirmuan atë rezultate të larta, kishte vetëm lëvizje të vogla brenda grupit drejtues, për shembull Outpost dhe Jetico ndryshuan pozicione. E vetmja surprizë ishte Produkt Norton, e cila në testin e fundit rezultoi me rezultat 45% dhe ishte në pjesën e poshtme të tabelës dhe në këtë test me 80% zuri pozitën e tretë.

Rezultatet e marra janë për shkak të faktit se shumë prodhues vendosin cilësimet e paracaktuara në atë mënyrë që të zvogëlojnë numrin e mesazheve të cilave përdoruesi duhet t'u përgjigjet. Kjo konfirmohet nga rezultatet e testimit - në cilësimet standarde, muret e zjarrit u bënë pyetje përdoruesve vetëm në 5.4% të sulmeve, dhe në maksimum - në 9.2% të sulmeve. Megjithatë, kjo ndikon në cilësinë e mbrojtjes, e cila do të qëndrojë e heshtur në një situatë kur një program me qëllim të keq do të imitojë / kryejë veprime plotësisht të ligjshme në sistem.

Ju gjithashtu duhet t'i kushtoni vëmendje dy modeleve. Së pari, përqindja e parandalimit të llojeve komplekse të sulmeve në përgjithësi është dukshëm më e keqe se sulmet e nivelit bazë të kompleksitetit. Më shumë se gjysma e këtyre sulmeve u refuzuan nga vetëm katër produkte - Comodo, Online Armor, Norton dhe Jetico. Katër produkte të tjera hynë në grupin kufitar, duke refuzuar nga 25% në 38% të sulmeve të tilla - këto janë Outpost, Trend Micro, Kaspersky dhe Dr.Web. Të gjitha produktet e tjera kanë refuzuar më së shumti një sulm kompleks. Së dyti, treguesit e devijimit të sulmeve bazë janë përmirësuar. Nëse në testin e fundit 11 (50%) produkte refuzuan më pak se 50% të sulmeve, atëherë në këtë test ka vetëm 3 produkte të tilla (14%).

Tabela 2: Rezultatet e testimit të mureve të zjarrit në cilësimet maksimale

Produkt i testuar	Sulmet bazë (maksimumi 56 pikë)			Sulmet e avancuara (maksimumi 8 pikë)			Totali i pikëve (maksimumi 64)	Total %
	Pikat	%	% nga shuma	Pikat	%	% nga shuma
Comodo	56	100%	87,5%	8	100%	12,5%	64	100%
Bitdefender	56	100%	87,5%	8	100%	12,5%	64	100%
Forca të blinduara në internet	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%
Mjete PC	49,5	88%	77,3%	5,5	69%	8,6%	55	86%
Postë	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%
Trendi 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 TË DHËNAT	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%

Figura 2: Rezultatet e testit të murit të zjarrit në cilësimet maksimale

Kur u aktivizuan cilësimet maksimale, cilësia e mbrojtjes kundër sulmeve të brendshme për shumë prej mureve të zjarrit të testuar u përmirësua ndjeshëm. Kjo është veçanërisht e dukshme në fshatarët e mesëm të fortë. Të gjithë drejtuesit e testit të fundit në këtë test kanë treguar edhe rezultate të larta. Nga ndryshimet, vlen të përmendet produkti Bitdefender, i cili, së bashku me Comodo, tregoi rezultate 100% dhe produkti Norton, i cili kaloi në grupin kryesor.

Rezultatet për një numër produktesh në cilësimet standarde dhe maksimale ishin të njëjta. Kjo për faktin se këto produkte nuk kanë cilësime që mund të ndikojnë në rezultatet e testit tonë.

Krahasimi i cilësisë së mbrojtjes në cilësimet standarde dhe maksimale

Në përputhje me logjikën e këtij testi, ne nuk do të përmbledhim ose mesatarizojmë rezultatet e të njëjtit produkt me cilësime të ndryshme... Përkundrazi, ne duam t'i krahasojmë ato dhe të tregojmë dallime domethënëse në cilësinë e mbrojtjes së produkteve të testuara, në varësi të cilësimeve të përdorura.

Për qartësi, ne paraqesim rezultatet përfundimtare të testit të murit të zjarrit me cilësimet standarde dhe maksimale në Tabelën 3 dhe Figurën 3.

Tabela 3: Përmbledhja e rezultateve të testit të murit të zjarrit në cilësimet standarde dhe maksimale

Produkt	Cilësimet standarde	Cilësimet maksimale
Comodo	92%	100%
Forca të blinduara në internet	90%	95%
Norton	80%	91%
Jetico	79%	79%
Postë	74%	85%
Trendi Micro	70%	72%
Kaspersky	70%	94%
Dr.Web	70%	80%
TrustPort	68%	71%
G TË DHËNAT	67%	70%
Avast	66%	66%
Eset	66%	85%
Bitdefender	66%	100%
AVG	64%	64%
McAfee	64%	64%
Mjete PC	64%	86%
Avira	63%	68%
Microsoft	63%	63%
F-Secure	51%	51%
Panda	47%	47%
Kingsoft	44%	44%

Figura 3: Përmbledhja e rezultateve të testit të murit të zjarrit në cilësimet standarde dhe maksimale

Figura 3 tregon shumë qartë ndryshimin në rezultatet e testit në varësi të cilësimeve të zgjedhura.

Së pari, vetëm dy produkte - Comodo dhe Online Armor shfaqen afër performanca maksimale mbrojtje, si në cilësimet standarde ashtu edhe në ato maksimale.

Së dyti, kur ndryshoni cilësimet standarde të propozuara nga prodhuesi, disa nga produktet shfaqen ndjeshëm niveli më i mirë mbrojtjes. Kjo shihet më qartë në produkte të tilla si Bitdefender, Kaspersky, Eset, F-Secure dhe PC Tools.

Së treti, siç u përmend më lart, disa nga produktet e testuara nuk kanë fare cilësime që mund të ndikojnë në ndonjë mënyrë në rezultatet e testimit. Prandaj, rezultatet e tyre në të gjitha llojet e cilësimeve në këtë test janë të njëjta. Ky grup përfshin Jetico, Avast, AVG, McAffe, F-Secure, Panda, Kingsoft dhe Microsoft.

Vlerësimi përfundimtar nuk merr parasysh situatat kur sulmi u zmbraps, por kishte probleme me ndërfaqen e përdoruesit të produkteve. Në shumicën e rasteve, problemet konsistonin në "përplasjen" e ndërfaqes për një kohë të shkurtër (nga 2 deri në 10 sekonda) ose deri në nisjen tjetër të sistemit operativ. Ndërsa produktet vazhdojnë të ofrojnë siguri kur ka probleme me ndërfaqen e përdoruesit, prania e këtyre çështjeve është subjektivisht negative dhe mund të ndikojë në zgjedhjet e produktit. Numri i problemeve me ndërfaqen e përdoruesit është paraqitur në tabelën 3 dhe në figurën 3. Janë vlerësuar gabimet që vijnë nga sulmet e nivelit të parë, numri i përgjithshëm i të cilave është 41.

Tabela 4: Numri i problemeve të ndërfaqes së përdoruesit në cilësimet standarde dhe maksimale

Produkt i testuar	Cilësimet standarde		Cilësimet maksimale
	Numri i gabimeve	%	Numri i gabimeve	%
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%
Mjete PC	13	32%	13	32%
Trendi Micro	12	29%	12	29%
AVG	10	24%	9	22%
TrustPort	9	22%	9	22%
G TË DHËNAT	9	22%	9	22%
Bitdefender	8	20%	8	20%
Norton	6	15%	6	15%
Avast	5	12%	5	12%
Postë	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%
Forca të blinduara në internet	1	2%	1	2%

Figura 4: Numri i çështjeve të ndërfaqes së përdoruesit në cilësimet standarde dhe maksimale

Rezultatet tregojnë se produktet McAfee dhe Microsoft përjetuan probleme të ndërfaqes së përdoruesit në shumicën e sulmeve (mbi 80%). Ky mund të quhet një nivel i papranueshëm, sepse pothuajse çdo sulm i zmbrapsur me sukses do të çojë në probleme. Kingsoft, F-Secure, Panda, Jetico dhe PC Tools tregojnë rezultate mjaft të dobëta, duke filluar nga 30% në 50%. Kur i përdorni, çdo 2-3 sulme do të çojnë në probleme të ndërfaqes. Një numër produktesh të tjera tregojnë rezultate nga 10% në 30%, të cilat mund të quhen të kënaqshme. Rezultate të bukura treguan produktet Avira, Dr.Web, Kaspersky dhe Online Armor, të cilat kishin probleme në rangun nga 2% deri në 5% të sulmeve. I vetmi produkt që nuk pati kurrë ndonjë problem me ndërfaqen e përdoruesit ishte Comodo në cilësimet maksimale, gjë që mund të konsiderohet një rezultat i shkëlqyer. Megjithatë, performanca e Comodo përkeqësohet në cilësimet standarde (12%), që do të thotë se përdorimi i këtij produkti kërkon disa njohuri se si ta konfiguroni atë.

Rezultatet përfundimtare të testit dhe çmimet

Ashtu si në testin e mëparshëm, ne nuk i vlerësuam rezultatet e të njëjtit produkt me cilësime të ndryshme, por i konsideruam ato në mënyrë të pavarur nga njëri-tjetri. Kështu, secili prej produkteve të testuara mund të marrë dy çmime, një për çdo lloj vendosjeje.

Në përputhje me skemën e shpërblimit, muret e zjarrit më të mirë marrin çmime me një tregues të cilësimeve të përdorura, shih tabelën 4.

Tabela 5: Rezultatet përfundimtare të testit të murit të zjarrit në cilësimet standarde dhe maksimale

Produkt i testuar	Opsioni cilësimet	Parandalimi i sulmeve [%]		Total [%]	Shperblim
		Baza niveli i veshtiresise	Niveli i rritur i vështirësisë
Comodo	Maks	100%	100%	100%	Platinum Firewall Outbound Çmimi i Mbrojtjes
Bitdefender	Maks	100%	100%	100%
Forca të blinduara në internet	Maks	95%	100%	95%	Firewall ari jashtë Çmimi i Mbrojtjes
Kaspersky	Maks	95%	88%	94%
Comodo	Standard	95%	75%	92%
Norton	Maks	90%	100%	91%
Forca të blinduara në internet	Standard	89%	94%	90%
Mjete PC	Maks	88%	69%	86%
Postë	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%	Firewall i argjendtë në dalje Çmimi i Mbrojtjes
Jetico	Standard	82%	56%	79%
Postë	Standard	80%	31%	74%
Trendi Micro	Maks	77%	38%	72%
TrustPort	Maks	77%	31%	71%
Trendi Micro	Standard	75%	38%	70%
Kaspersky	Standard	75%	31%	70%
Dr.Web	Standard	76%	25%	70%
G TË DHËNAT	Maks	75%	38%	70%
TrustPort	Standard	77%	6%	68%	Firewall bronzi në dalje Çmimi i Mbrojtjes
Avira	Maks	74%	25%	68%
G TË DHËNAT	Standard	75%	13%	67%
Avast	Maks	73%	19%	66%
Avast	Standard	73%	13%	66%
Eset	Standard	73%	13%	66%
Bitdefender	Standard	73%	13%	66%
AVG	Maks	73%	0%	64%
AVG	Standard	73%	0%	64%
McAfee	Maks	73%	0%	64%
McAfee	Standard	73%	0%	64%
Mjete PC	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%	Asnjë shpërblim
F-Secure	Standard	56%	13%	51%
Panda	Maks	54%	0%	47%
Panda	Standard	54%	0%	47%
Kingsoft	Maks	48%	13%	44%
Kingsoft	Standard	48%	13%	44%

Rezultatet më të mira në test u treguan nga muret e zjarrit Comodo dhe Bitdefender, të cilët shënuan 100% pikë në cilësimet maksimale. Këto dy produkte marrin një çmim PlatinumFirewallJashtëMbrojtjaÇmimi.

Firewallët Online Armor, Kaspersky, Comodo, Norton, PC Tools, Outpost, Eset dhe Dr.Web, të cilët marrin çmime, treguan gjithashtu rezultate shumë të larta në test (mbi 80%). AriFirewallJashtëMbrojtjaÇmimi... Është e rëndësishme të theksohet se Comodo mori këtë çmim në cilësimet standarde, Online Armor dhe Norton në cilësimet standarde dhe maksimale, dhe të gjitha të tjerat - vetëm në cilësimet maksimale.

Tjetra në listë është një grup prej shtatë muresh zjarri, rezultatet e të cilëve bien në rangun nga 60% në 70%. Këto janë Outpost, Kaspersky dhe Dr.Web me cilësime standarde; TrustPort dhe G DATA në cilësimet maksimale, si dhe Jetico dhe Trend Micro në të njëjtën kohë në cilësimet standarde dhe maksimale. Ata të gjithë marrin një shpërblim

Një grup mjaft i madh produktesh që bien në intervalin 60% deri në 70% do të marrin çmimin. Duhet të theksohet se produktet Eset dhe Bitdefender në cilësimet standarde, të cilat në cilësimet maksimale ishin në gjendje të zmbrapsnin një numër dukshëm më të madh sulmesh.

Ju mund të njiheni me rezultatet e detajuara të testit dhe të siguroheni që llogaritjet përfundimtare të jenë të sakta duke shkarkuar rezultatet e testit në formatin Microsoft Excel.

Ilya Shabanov, partneri menaxhues i faqes:

“Isha shumë i kënaqur me faktin që shumë prodhues kanë përmirësuar ndjeshëm mbrojtjen proaktive kundër sulmeve të brendshme dhe vetëmbrojtjen në produktet e tyre. Madje na u desh të rishikonim skemën e çmimeve për të ngritur shiritin. Një rezultat prej më pak se 51% tani shihej si një dështim i plotë.

Ne u befasuam këndshëm nga Bitdefender, i cili zmbrapsi të gjitha 100% të sulmeve në modalitetin paranojak, Eset dhe Dr.Web me rezultate në cilësimet maksimale prej 85% deri në 80%, respektivisht, si dhe një i sapoardhur në testet tona, TrustPort. Firewalls nga Comodo, Norton dhe Online Armor u përfshinë në "grupin e artë" të produkteve sipas rezultateve të këtij testi, duke shënuar më shumë se 80% në cilësimet standarde dhe maksimale. Kaspersky, Outpost, PC Tools kanë treguar rezultate vazhdimisht të larta në testet që përfshijnë mbrojtje proaktive.

Megjithatë, në rastin e një numri produktesh të testuara, logjika me të cilën vendosen cilësimet standarde nuk është e qartë. Si rezultat, niveli i mbrojtjes për shumicën e përdoruesve që janë mësuar të përdorin mbrojtjen me cilësimet standarde rezulton të jetë dukshëm i nënvlerësuar. Kjo vlen kryesisht për produktet Bitdefender, Kaspersky, Eset dhe PC Tools.

Kartavenko Mikhail, kreu i vendit të laboratorit të testimit:

“Duke e konsideruar këtë test si vazhdimësi të testit të mëparshëm të ngjashëm, mund të identifikojmë disa tendenca dhe probleme kryesore në punën e mureve të zjarrit.

Së pari, mesatarisht, shumica e produkteve performuan më mirë se 1.5 vjet më parë, por ata e bënë këtë kryesisht duke zmbrapsur sulmet më të thjeshta të Nivelit 1. Sulme më komplekse "në dhëmbë" vetëm për një gamë të kufizuar produktesh.

Së dyti, edhe nëse aktivizohet mbrojtja e përfundimit të procesit (1 nivel sulmesh), ndërfaqja e përdoruesit e shumë produkteve prishet. Kjo e vendos përdoruesin në një pozitë të pakëndshme në të cilën ai nuk e kupton nëse mbrojtja funksionon apo jo.

Së treti, ekziston një hendek mjaft i madh në punën e mureve të zjarrit në cilësimet standarde dhe maksimale. Si rezultat, një nivel i pranueshëm mbrojtjeje shpesh mund të merret vetëm nga përdoruesit me përvojë që dinë dhe janë në gjendje të konfigurojnë siç duhet punën e mureve të zjarrit.

Kështu, testi zbuloi pikat "e dhimbshme" të mureve moderne të zjarrit, zgjidhja e të cilave mund të përmirësojë mbrojtjen e tyre."

Seksioni përditësohet çdo ditë. Gjithmonë versionet më të fundit të programeve më të mira falas për përdorim të përditshëm në seksionin "Programet e nevojshme". Praktikisht ka gjithçka që kërkohet puna e përditshme... Filloni të hiqni dorë versione pirate në favor të homologëve të lirë më të përshtatshëm dhe funksionalë. Nëse ende nuk e përdorni bisedën tonë, ju rekomandojmë shumë të njiheni me të. Aty do të gjeni shumë miq të rinj. Për më tepër, është më i shpejti dhe mënyrë efikase kontaktoni administratorët e projektit. Seksioni i Përditësimeve të Antivirusit vazhdon të funksionojë - përditësime gjithmonë të përditësuara falas për Dr Web dhe NOD. Nuk kishit kohë për të lexuar diçka? Përmbajtja e plotë e linjës zvarritëse mund të gjendet në këtë lidhje.

Falas firewall Comodo... Testimi, përfundimet

Comodo Firewall në veprim

Pas instalimit dhe konfigurimit të Comodo, ai u fsheh në tabaka dhe filloi të më bezdiste me pyetjet e tij. Ditën e parë, luajta me të gjithë murin e zjarrit dhe mënyrat e mbrojtjes proaktive dhe përfundimisht e mbylla në heshtje. Në sistemin e tyre nuk u gjetën frena pas shfaqjes së tij. Në përgjithësi, puna me murin e zjarrit Comodo ishte mjaft e lehtë dhe e përshtatshme. Ndërfaqja e dritares kryesore është shumë e thjeshtë dhe informuese:

Por më duhej të mësohesha me lundrimin nëpër murin e zjarrit dhe cilësimet e mbrojtjes proaktive - nuk është gjithmonë e mundur të gjesh shpejt artikullin e dëshiruar. Unë mendoj se do të kalojë me kalimin e kohës.

Disa ditë pas instalimit të Comodo Firewall, vendosa ta testoj pak.

Testi numër 1. Testimi në internet

Kur klikoni në butonin "Test", programi përpiqet të krijojë një lidhje me serverin e faqes.

Meqenëse Comodo Firewall nuk e njeh ende këtë mjet, kur u përpoq për herë të parë të depërtonte në internet, pati një reagim të menjëhershëm nga mbrojtja proaktive dhe muri i zjarrit:

Në të dyja rastet, klikova bllokimin dhe mora një konfirmim që testi ishte i suksesshëm:

Pastaj e riemërova skedarin FireWallTest.exe v opera.exe dhe i zëvendësoi ato me skedarin standard Opera. Kështu, u përpoqa të mashtroj Comodo Firewall, i cili tashmë e njeh mirë dhe vazhdimisht këtë shfletues dhe e lëshon automatikisht në internet. Comodo reagoi ndaj lançimit të Operas "të rreme" nga Total si më poshtë:

Pasi mori lejen time për një nisje një herë, muri i zjarrit më paralajmëroi për një përpjekje për të hyrë në Opera në internet:

Rezulton se çdo aplikacion për të cilin tashmë ka rregulla nuk do të jetë në gjendje të hyjë në internet nëse skedari i ekzekutueshëm zëvendësohet pa dijeninë time. Gjithçka duket se është në rregull, por ja ku është gjëja: ngjyra e pjesës së sipërme të dritares paralajmëruese varet nga ashpërsia e situatës. Nëse Comodo vlerëson një ngjarje si kritike, atëherë ngjyra do të jetë e kuqe, nëse ngjarja është më pak e rrezikshme, do të jetë e verdhë. Në rastin tim, Comodo e konsideroi situatën e simuluar jo veçanërisht të rrezikshme dhe ndezi atë të verdhë. Për më tepër, në vend të formulimit "skedar i ekzekutueshëm opera.exe nuk njihet "Unë do të preferoja të shihja se" pati një ndryshim në parametrat e skedarit opera.exe“. Pra, paralajmëroni situata të ngjashme kombinon nga Kaspersky dhe Eset, për shembull. Për më tepër, përdoruesi sheh një dritare alarmi duke përdorur të kuqe, gjë që e bën menjëherë t'i kushtojë vëmendje situatës. Një paralajmërim nga Comodo thjesht mund të injorohet nga përdoruesi për shkak të theksit të pamjaftueshëm në ngjarjen që po ndodh.

Mashtrimi i skedarit Opera ishte vetëm një pjesë e planit tim dinake. Viktima e radhës ishte Internet Explorer 6, e cila është e integruar në sistemin operativ, që do të thotë iexplore.exe mund të konsiderohet një skedar i plotë i sistemit. Imagjinoni habinë time kur, nën heshtjen e plotë të Comodo, pashë një dritare për dështimin e testit:

Me sa duket, është krijuar një rregull shtesë, vendosa dhe hyra në murin e zjarrit dhe politikat e mbrojtjes proaktive. Pasi gërmova atje për rreth 15 minuta, mora vendimin e vetëm të saktë - të riinstaloja Comodo. E thënë më shpejt se sa bëhet. Duke lënë mënyrat e paracaktuara të funksionimit, unë përsërita eksperimentin me zëvendësimin iexplore.exe... Në fillimin nga Total, funksionoi mbrojtja proaktive, si në rastin e Opera:

Këtu do të na duhet të bëjmë një digresion të vogël lirik. Fakti është se kur skedari i ekzekutueshëm IE zëvendësohet, sistemi rikthen atë origjinal brenda 4-8 sekondave. iexplore.exe... Në këtë drejtim, rezultatet e testit tim vareshin nga fakti nëse skedari i zëvendësuar kishte kohë për të trokitur në internet apo jo.

Në rastin kur arrij të kryej të gjitha manipulimet përpara se të rikuperoj explore.exe, ndodh si më poshtë. Pasi kam marrë lejen time për një lëshim një herë explore.exe, Total lëshon programin FireWallTest, shtyp "Test", mbrojtja proaktive Defens + lëshon një paralajmërim:

Nëse e lejojmë (si eksperiment), muri i zjarrit funksionon:

Ne arrijmë të shtypim "Blloko" - testi kaloi, programi nuk u fut në internet. Por nëse iexplore.exe restauruar përpara se të shtypej butoni i kyçjes - asgjë nuk varet nga zgjedhja juaj - programi automatikisht fiton akses në internet kur skedari origjinal restaurohet.

E njëjta gjë vlen edhe për punën e mbrojtjes proaktive: nëse nuk keni pasur kohë të urdhëroni bllokimin përpara restaurimit explore.exe- programi automatikisht merr akses në internet.

Pasi luajta mjaftueshëm me IE të rreme, m'u kujtua dështimi i parë i testit, kur Comodo heshti dhe lëshoi ​​skedarin "majtë" në internet. Pas riinstalimit të Comodo, vendosa Defence + dhe murin e zjarrit në modalitetin e trajnimit dhe nisa IE. Pas kësaj, ktheva mënyrat e paracaktuara dhe përsërita testin. Comodo dështoi përsëri në heshtje ...

Testi numër 3. Duel

I impresionuar nga rezultatet e testit të mëparshëm, kërkova veçori shtesë testo Comodo dhe më në fund gjeti mjetin AWFT.

Ky program emulon sjelljen e Trojans dhe përmban një seri prej gjashtë testesh që demonstrojnë metoda të ndryshme të aksesit të paautorizuar në rrjet, duke anashkaluar mbrojtjen e murit të zjarrit. Këto teste përfshijnë mënyra të vjetra për të mashtruar muret e zjarrit dhe teknika më moderne. Për çdo test të kaluar me sukses, muri i zjarrit i jepet një numër i caktuar pikësh. Nëse testi dështon, pikët jepen në favor të AWFT. Numri maksimal i pikëve është dhjetë.

Shërbimi është shareware, i kufizuar në 10 lëshime. Në pjesën e sipërme të dritares së programit ka butona që nisin testet përkatëse, më poshtë është faqja ku do të depërtojë AWFT dhe rezultati i duelit midis murit të zjarrit dhe programit. Butoni Reset Points përdoret për të rivendosur pikat e grumbulluara.

Për çdo rast, vendosa të ndryshoj adresën e faqes në adresën time.

Testimi u krye me Comodo Firewall dhe Defence + të ndezur, Opera funksionon dhe monitori i Avira-s i fikur.

Në testin e parë, u përdor një teknikë me ngarkimin e një kopjeje të fshehur të shfletuesit dhe korrigjimin e kujtesës përpara se ta niste atë.

Kur klikova butonin e testimit, doli një dritare me një gabim:

Pas mbylljes së kësaj dritareje, Comodo reagoi ndaj provës me një dritare kërkese, kur u shtyp butoni "Blloko", AWFT, pas një mendimi të vogël, i dha pikën e parë firewall-it.

Sipas zhvilluesve të programit, testi # 2 është një mashtrim i vjetër dhe i njohur. Comodo përsëri përgjigjet me një kuti kërkese dhe përsëri merr një pikë.

Testi # 3 përdor gjithashtu një truk të vjetër. Comodo thjesht e bllokon atë në heshtje, me sa duket një truk vërtet i famshëm.

Testi # 4 është i ngjashëm me testin e parë me lëshimin e një kopjeje të fshehur të shfletuesit dhe korrigjimin e kujtesës përpara se ta nisni atë. Firewall-i nuk lëshoi ​​asnjë paralajmërim, por pas një pauze të shkurtër ai fitoi një pikë tjetër.

Gjatë testit të pestë dhe të gjashtë, duhet të kaloni në shfletues dhe të shfletoni pak (sapo rifreskova faqen e ngarkuar në shfletues).

Në testin # 5, programi kryen një kërkim heuristik për softuerin e autorizuar të instaluar në kompjuter (ose në rrjet) që ka akses në internet përmes portës 80, më pas lëshon një kopje të programit të lejuar dhe rregullon memorien e zënë nga ky program (dmth. AWFT lëshohet vetë në kujtesën e programit të lejuar). Comodo e kaloi në heshtje provën dhe mori 3 pikë për të.

Testi # 6 është i ngjashëm me testin e pestë të mëparshëm. E njëjta teknikë përdoret me një kërkim heuristik për softuerin e instaluar që ka të drejtë të dalë jashtë përmes portit 80. Vetëm metoda e hakimit është ndryshuar tani - përdoret një kërkesë e përdoruesit. Gjatë rrugës, AWFT po përpiqet të ngjitë shiritin e majtë të fshehur të veglave në shfletues. Kur Opera ishte e hapur, dritarja e mëposhtme doli për mua:

Në momentin që konfirmova këtë kërkesë të përdoruesit, Comodo lëshoi ​​kërkesën e saj, shërbimi u bllokua përsëri dhe muri i zjarrit mori 3 pikë për vete.

Rezultati i duelit është 10:0 në favor të Comodo. Pasi përsërita testet me Internet Explorer të hapur, mora të njëjtat rezultate.

konkluzioni

Pavarësisht nga një shije e pakëndshme në dush, e mbetur pas testimit të murit të zjarrit, unë ende rekomandoj Comodo Internet Security për përdorim në shtëpi, por vetëm si mur zjarri. Dhe mos dëgjoni ata djem të zgjuar që këshillojnë çaktivizimin e mbrojtjes proaktive, në asnjë rast! Vetëm duke përdorur Defence + ky mur mbrojtës do ta mbajë vërtet kompjuterin tuaj të sigurt. Ajo që në të vërtetë nuk duhet të përdorni është antivirusi i Comodo. Jo vetëm që kapërcehet mirë, por do të keni probleme me përditësimin e tij - ai ka baza të dhënash shumë të rënda. Përveç kësaj, ajo ka një efekt të mirë në performancën e sistemit. Sapo punova shkëlqyeshëm në një palë Comodo Firewall dhe Avira Antivir Personal.

Nuk gjeta asnjë frenim ose defekt në sistem ndërsa muri i zjarrit ishte në punë. Mendimet e mia për rezultatet e testimit do t'i lë për vete tani për tani, do të doja të dëgjoja komentet tuaja.

Ndërsa shkruaja pjesën e fundit të këtij artikulli, hasa në rezultatet e një testi të fundit të mureve të zjarrit nga laboratori Matousec. Comodo Internet Security doli të ishte i vetmi mur zjarri me një shkallë suksesi 100% (shih forumin e murit të zjarrit). Epo, unë bëra zgjedhjen time ... Dhe ju?

pluse (të qarta):
shpërndarja falas,
disponueshmëria e bazës së të dhënave të saj të programeve;
prania e mbrojtjes proaktive (Mbrojtje +);
lehtësia e instalimit dhe konfigurimi fillestar;
dritare përmbledhëse shumë informuese dhe e përshtatshme;

pluse (të dyshimta):
prania e disa mënyrave të funksionimit;

kundër (e qartë):
mënyra e bezdisshme e instalimit;
zëvendësimi i një skedari të ekzekutueshëm nuk përcaktohet nga mbrojtja proaktive si një ngjarje kritike;

kundër (e diskutueshme):
sinqerisht antivirus i pasuksesshëm.

Ky artikull i dytë përshkruan se si të zgjidhni problemin e filtrit të paketave. Në vend të hedhjes tryezë e përfunduar në formën e "problemit" - "zgjidhjes" jepen metoda të një qasjeje sistematike për zgjidhjen e problemeve që kanë lindur.

Ky artikull i dytë (në një seri prej tresh) përshkruan se si të zgjidhni problemet e filtrit të paketave. Në vend të paraqitjes së një tabele të gatshme në formën e "problemit" - "zgjidhjes", jepen metoda të një qasjeje sistematike për zgjidhjen e problemeve që janë shfaqur.

Prezantimi

Një filtër paketash ekzekuton një politikë filtrimi duke anashkaluar një sërë rregullash dhe, në përputhje me rrethanat, bllokon ose lejon paketat. Kapitulli shpjegon se si të kontrolloni nëse politika e filtrimit po ekzekutohet saktë dhe si të gjeni gabime nëse nuk është.

Në përgjithësi, përgjatë këtij kapitulli, do të krahasojmë detyrën e shkrimit të një grupi rregullash filtrimi me programimin. Nëse nuk keni aftësi programimi, atëherë ky krahasim do t'ju duket më i vështirë. Por shkrimi i rregullave nuk kërkon një diplomë të shkencave kompjuterike ose përvojë programimi në vetvete, apo jo?

Përgjigja është jo, ju ndoshta nuk keni nevojë për këtë. Gjuha e përdorur për të konfiguruar filtrin e paketave është bërë e ngjashme me gjuhët njerëzore. Për shembull:

bllokojnë të gjitha

kaloj të gjithë mbaj shtet

kaloni në proto tcp në çdo port www keep state

Në fakt, nuk keni nevojë të keni një programues afër për të kuptuar se çfarë bën ky grup, apo edhe, duke përdorur intuitën, për të shkruar një politikë të tillë filtrimi. Ekziston madje një shans i madh që një grup rregullash filtrimi të krijuara në këtë ngjashmëri të kryejnë veprimet që autori i tij kishte në mendje.

Fatkeqësisht, kompjuterët bëjnë vetëm atë që ju kërkoni të bëjnë, jo atë që dëshironi që ata të bëjnë. Edhe më keq, ata nuk do të jenë në gjendje të dallojnë atë që dëshirohet nga ajo që është reale, nëse ka një ndryshim të tillë. Kjo do të thotë që nëse kompjuteri nuk bën siç duhet atë që dëshironi, edhe nëse mendoni se i keni përshkruar qartë udhëzimet, është në dorën tuaj të gjeni dallimet dhe të ndryshoni udhëzimet. Dhe meqenëse ky është një problem i zakonshëm në programim, ne mund të shohim se si e trajtojnë programuesit. Rezulton se aftësitë dhe metodat e përdorura për të testuar dhe korrigjuar programet dhe rregullat e filtrimit janë shumë të ngjashme. Megjithatë këtu nuk keni nevojë për njohuri të ndonjë gjuhe programimi për të kuptuar implikimet për testimin dhe korrigjimin e gabimeve.

Politika e mirë e filtrimit.

Një politikë filtrimi është një specifikim jozyrtar i asaj që duam të bëjë muri i zjarrit. Nga ana tjetër, një grup rregullash, zbatimi i një specifikimi, është një grup udhëzimesh standarde, një program i ekzekutuar nga një makinë. Prandaj, për të shkruar një program, duhet të përcaktoni se çfarë duhet të bëjë.

Kështu, hapi i parë në konfigurimin e një muri zjarri është përcaktimi joformal i asaj që duhet të arrihet. Cilat lidhje duhet të bllokohen ose lejohen?

Një shembull do të ishte:

Janë tre rrjete që duhet të ndahen nga njëri-tjetri nga një mur zjarri. Çdo lidhje nga një rrjet në tjetrin kalon përmes murit të zjarrit. Firewall ka 3 ndërfaqe, secila prej të cilave është e lidhur me rrjetin përkatës:

$ ext_if - në rrjetin e jashtëm.

$ dmz_if - DMZ me serverë.

$ lan_if - LAN me stacione pune.

Hostët në LAN duhet të lidhen lirshëm me çdo host në DMZ ose në rrjetin e jashtëm.

Serverët në DMZ duhet të jenë në gjendje të komunikojnë lirshëm me hostet në rrjetin e jashtëm. Pritësit e jashtëm mund të lidhen vetëm me serverët e mëposhtëm në DMZ:

Ueb serveri 10.1.1.1 porti 80

Serveri i postës 10.2.2.2 porti 25

Të gjitha lidhjet e tjera duhet të mohohen (për shembull, nga makinat në rrjetin e jashtëm te makinat në LAN).

Kjo politikë shprehet në mënyrë joformale në mënyrë që kushdo që e lexon ta kuptojë atë. Duhet të jetë aq specifik sa që lexuesi të mund të formulojë lehtësisht përgjigjet për pyetjen e formularit "A duhet të kalohet lidhja nga hosti X me hostin Y, në hyrje (ose në dalje) në ndërfaqen Z?". Nëse po mendoni për rastet kur politika juaj nuk e plotëson këtë kërkesë, atëherë nuk është mjaft e qartë.

Politikat "me mjegull" si "lejoni vetëm atë që është jetike" ose "sulmet e bllokimit" duhet të sqarohen, ose nuk do të jeni në gjendje t'i aplikoni ose testoni ato. Ashtu si në zhvillimin e softuerit, detyrat e formalizuara në mënyrë të pamjaftueshme rrallë çojnë në zbatime të justifikuara ose korrekte. ("Pse nuk shkoni dhe filloni të shkruani kodin, ndërsa unë do të kuptoj se çfarë ka nevojë klienti").

Një grup rregullash që zbatojnë politikën

Grupi i rregullave është shkruar si një skedar teksti që përmban fjali në një gjuhë zyrtare. Si dhe burimi përpunohet dhe përkthehet në udhëzimet e kodit të makinës nga përpiluesi, "burimi" i grupit të rregullave përpunohet nga pfctl dhe rezultati interpretohet nga pf në kernel.

Kur kodi burim shkel rregullat e gjuhës zyrtare, analizuesi raporton një gabim sintaksor dhe refuzon të përpunojë më tej skedarin. Ky gabim është një gabim në kohën e përpilimit dhe zakonisht rregullohet shpejt. Kur pfctl nuk mund të analizojë skedarin tuaj të grupit të rregullave, ai printon një rresht me një gabim dhe një mesazh pak a shumë informues që nuk mund ta analizonte. Derisa i gjithë skedari të përpunohet pa gabim i vetëm, pfctl nuk do të ndryshojë grupin e mëparshëm të rregullave në kernel. Dhe meqenëse skedari përmban një ose më shumë gabime sintaksore, nuk ka asnjë "program" që mund të ekzekutojë pf.

Lloji i dytë i gabimit quhet "gabimet në kohën e ekzekutimit" sepse ndodh kur një program sintaksorisht i saktë shkruhet dhe përkthehet dhe ekzekutohet me sukses. V rast i përgjithshëm, në gjuhët e programimit, kjo mund të ndodhë kur një program kryen një pjesëtim me zero, përpiqet të hyjë në zona të pavlefshme të memories ose kur i mbaron memoria. Por meqenëse grupet e rregullave ngjajnë vetëm në mënyrë të paqartë me funksionalitetin e gjuhëve programuese, shumica e këtyre gabimeve nuk mund të ndodhin gjatë zbatimit të rregullave, për shembull, rregullat nuk mund të shkaktojnë të ashtuquajturat. "Dështimi i sistemit", siç bëjnë zakonisht programet. Megjithatë, një sërë rregullash mund të shkaktojë gabime të ngjashme, në formën e bllokimit, ose anasjelltas, kalimit të paketave që nuk përputhen me politikën. Ky nganjëherë quhet një gabim boolean, një gabim që nuk shkakton përjashtim ose prishje, por thjesht prodhon rezultate të pasakta.

Pra, përpara se të fillojmë të kontrollojmë se sa saktë firewall-i po zbaton politikën tonë të sigurisë, duhet të ngarkojmë me sukses grupin e rregullave së pari.

Gabimet e analizuesit

Gabimet e analizuesit ndodhin kur përpiqeni të ngarkoni një listë rregullash duke përdorur pfctl, për shembull:

# pfctl -f /etj /pf.konf

/ etj /pf.konf: 3:sintaksëgabim

Ky mesazh tregon se ka një gabim sintaksor në rreshtin 3 të /etc/pf.conf dhe pfctl nuk mund të ngarkojë rregullat. Seti në kernel nuk ka ndryshuar, ai mbetet i njëjtë si përpara përpjekjes për të ngarkuar një të re.

Ka shumë lloje të gabimeve pfctl. Për të filluar me pfctl, ju vetëm duhet t'i lexoni ato me kujdes. Ndoshta jo të gjitha pjesët e mesazhit do t'ju zbulojnë menjëherë kuptimin e tyre, por ju duhet t'i lexoni të gjitha, sepse më vonë do ta bëjë më të lehtë të kuptosh se çfarë shkoi keq. Nëse mesazhi përmban një pjesë të formularit "emri i skedarit: numri: teksti", ai i referohet rreshtit me numrin përkatës në skedarin e specifikuar.

Hapi tjetër është të shikoni rreshtin e shfaqur duke përdorur një redaktues teksti (në vi mund të shkoni në rreshtin 3 duke futur 3G në modalitetin e sinjalit), ose si kjo:

# cat -n /etc/pf.conf

1 int_if = "fxp 0"

2 bllok të gjitha

3 kalojnë në $ int_if inet të gjitha të mbajtura gjendje

kaloj inet në $ int_if të gjitha mbahen në gjendje

Problemi mund të jetë një gabim i thjeshtë shtypi, si në këtë rast ("mbaj" në vend të "mbaj"). Pas rregullimit, provoni të ringarkoni skedarin:

# pfctl -f /etj /pf.konf

/ etj /pf.konf: 3:sintaksëgabim

# head -n 3 /etc/pf.conf | bisht -n 1

kaloni inet në $ int_if të gjithë mbajnë gjendjen

Tani të gjitha fjalët kyçe janë të sakta, por pas një kontrolli më të afërt, vërejmë se pozicionimi i fjalës kyçe "inet" përpara "on $ int_if" është i gabuar. Kjo ilustron që një rresht i vetëm mund të përmbajë më shumë se një gabim. Pfctl printon gabimin e parë që gjen dhe ndalon ekzekutimin. Nëse i njëjti numër i linjës është lëshuar gjatë rinisjes, do të thotë se ka më shumë gabime në të, ose ato të mëparshmet nuk janë eliminuar saktë.

Fjalë kyçe të gabuara janë gjithashtu një gabim i zakonshëm. Kjo mund të shihet duke krahasuar rregullin kundër sintaksës së referencës BNF në fund të faqes pf.conf (5), e cila përmban:

pf-rule = veprim [("në" | "jashtë")]

["log" | "log-all"] ["i shpejtë"]

["në" ifspec] [rrugë] [af] [protospec]

hostet [filteropt-list]

ifspec = (["!"] emri i ndërfaqes) | "(" lista e ndërfaqes ")"

af = "inet "|"inet6"

Që do të thotë se fjalë kyçe Inet duhet të ndjekë $ int_if

Le ta rregullojmë dhe të provojmë përsëri:

# pfctl -f /etj /pf.konf

/ etj /pf.konf: 3:sintaksëgabim

# head -n 3 /etc/pf.conf | bisht -n 1

kalojnë në $ int_if inet të gjithë mbajnë gjendjen

Tani nuk ka gabime të dukshme. Por nuk i shohim të gjitha detajet shoqëruese! Linja varet nga përkufizimi i makro $ inf_if. Çfarë mund të identifikohet gabimisht?

# pfctl -vf /etc/pf.conf

int_if = "fxp 0"

blloko të gjitha

/etc/pf.conf:3: gabim sintaksor

Pasi të korrigjoni gabimin e shtypit "fxp 0" në "fxp0", provoni përsëri:

# pfctl -f /etj /pf.konf

Mungesa e mesazheve tregon që skedari është shkarkuar me sukses.

Në disa raste, pfctl mund të lëshojë mesazhe gabimi më specifike sesa thjesht "gabim sintaksor":

# pfctl -f /etc/pf.conf

/etc/pf.conf:3: porti zbatohet vetëm për tcp / udp

/etc/pf.conf:3: rregulli i kapërcimit për shkak të gabimeve

/etc/pf.conf:3: rregulli zgjerohet në asnjë kombinim të vlefshëm

# head -n 3 /etc/pf.conf | bisht -n 1

kalojnë në $ int_if në port ssh mbaj gjendjen

Rreshti i parë i mesazhit të gabimit është më informues në krahasim me pjesën tjetër. Në këtë rast, problemi është se rregulli që specifikon portin nuk përcakton protokollin - tcp ose udp.

Në raste të rralla, pfctl dekurajohet nga prania e karaktereve të pashtypshme ose hapësirave të panevojshme në skedar, gabime të tilla nuk janë të lehta për t'u zbuluar pa përpunim të veçantë të skedarit:

# pfctl -f /etc/pf.conf

/etc/pf.conf:2: hapësira e bardhë pas \

/etc/pf.conf:2: gabim sintaksor

# cat -ent /etc/pf.conf

1 bllok të gjitha $

2 kalojnë në gem0 nga çdo në çdo \ $

3 ^ Mbajshtet $

Problemi këtu është karakteri i hapësirës, ​​pas "backslash" por para fundit të rreshtit të dytë, i treguar nga shenja "$" në daljen e cat -e.

Pasi grupi i rregullave të jetë ngarkuar me sukses, është mirë të shikoni rezultatin:

$ cat /etc/pf.conf

bllokojnë të gjitha

# kalim nga cilido në cilindo \

kalojnë nga 10.1.2.3 në ndonjë

$ pfctl -f /etc/pf.conf

$ pfctl -sr

bllokojrënietë gjitha

"Prapa" në fund të një linje komenti në fakt do të thotë se linja e komenteve do të vazhdojë më poshtë.

Zgjerimi i listave të mbyllura në kllapa kaçurrelë () mund të prodhojë një rezultat që mund t'ju befasojë, dhe në të njëjtën kohë të tregojë grupin e rregullave të përpunuara nga analizuesi:

$ cat /etc/pf.conf

kalojnë nga (! 10.1.2.3,! 10.2.3.4) në ndonjë

$ pfctl -nvf /etc/pf.conf

kaloj inet nga! 10.1.2.3 për cilindo

kaloj inet nga! 10.2.3.4tendonjë

Kapja këtu është se shprehja "(! 10.1.2.3,! 10.2.3.4)" nuk do të thotë "të gjitha adresat përveç 10.1.2.3 dhe 10.2.3.4", shprehja e zgjeruar në vetvete do të thotë një përputhje me çdo adresë të mundshme.

Ju duhet të rifreskoni grupin e rregullave pas ndryshimeve të përhershme për t'u siguruar që pfctl mund ta ngarkojë atë kur rinisni makinën. Në OpenBSD, skripti i nisjes rc nga / etc / rc fillimisht ngarkon një grup të vogël rregullash të paracaktuar që bllokojnë të gjithë trafikun, përveç atyre që nevojiten në kohën e nisjes (të tilla si dhcp ose ntp). Nëse skripti dështon të ngarkojë grupin e vërtetë të rregullave nga /etc/pf.conf për shkak të gabimeve sintaksore të paraqitura përpara rinisjes së makinës pa kontrolluar, atëherë grupi i rregullave të paracaktuar do të mbetet aktiv. Për fat të mirë, ky grup lejon lidhjet hyrëse ssh, kështu që problemi mund të zgjidhet nga distanca.

Duke testuar

Meqenëse kemi një politikë jashtëzakonisht të përcaktuar saktësisht dhe një grup rregullash që duhet ta zbatojnë atë, atëherë termi testim do të nënkuptojë, në rastin tonë, përputhshmërinë e grupit që rezulton me një politikë të caktuar.

Ekzistojnë vetëm dy mënyra që rregullat të mos funksionojnë: bllokimi i lidhjeve që duhet të lejohen dhe anasjelltas, kalimi i atyre lidhjeve që duhet të bllokohen.

Testimi në përgjithësi nënkupton një qasje sistematike ndaj krijimit të rregullt tipe te ndryshme lidhjet. Është e pamundur të kontrollohen të gjitha kombinimet e mundshme të burimit / destinacionit dhe porteve përkatëse në ndërfaqet, sepse muri i zjarrit teorikisht mund të përplaset me të sasi e madhe kombinime të tilla. Sigurimi që një grup rregullash është fillimisht i saktë mund të sigurohet vetëm për shumë kohë raste të thjeshta... Në praktikë, zgjidhja më e mirë do të ishte krijimi i një liste të lidhjeve testuese të bazuara në një politikë sigurie të tillë që çdo pikë e politikës të preket. Pra, për politikën tonë të shembullit, lista e testeve do të jetë si më poshtë:

Lidhja LAN me DMZ (duhet anashkaluar)

nga LAN në rrjetin e jashtëm (duhet të kalohet)

nga DMZ në LAN (duhet të bllokohet)

nga DMZ në rrjetin e jashtëm (duhet të kalohet)

nga rrjeti i jashtëm në DMZ në 10.1.1.1 në portin 80 (duhet anashkaluar)

nga rrjeti i jashtëm në DMZ në 10.1.1.1 në portin 25 (duhet të bllokohet)

nga rrjeti i jashtëm në DMZ në 10.2.2.2 në portin 80 (duhet të bllokohet)

nga rrjeti i jashtëm në DMZ në 10.2.2.2 në portin 25 (duhet të kalohet)

nga rrjeti i jashtëm në LAN (duhet të bllokohet)

Rezultati i pritur duhet të specifikohet në këtë listë përpara testimit.

Mund të tingëllojë e çuditshme, por qëllimi i çdo testi është të gjejë gabime në zbatimin e grupit të rregullave të murit të zjarrit, jo vetëm të deklarojë se ato mungojnë. Dhe qëllimi përfundimtar i procesit është të ndërtojë një sërë rregullash pa gabime, kështu që nëse dyshoni se mund të ketë gabime këtu, është më mirë t'i gjeni ato sesa t'i anashkaloni. Dhe nëse merrni përsipër rolin e një testuesi, duhet t'i përmbaheni një stili të të menduarit shkatërrues dhe të përpiqeni të anashkaloni kufizimet e murit të zjarrit. Dhe vetëm fakti që kufizimet nuk mund të thyhen do të jetë një provë e arsyetuar se grupi i rregullave është pa gabime.

Lidhjet TCP dhe UDP mund të kontrollohen me nc. nc mund të përdoret si klient dhe server (duke përdorur opsionin -l). Dhe për kërkesat dhe përgjigjet e ICMP-së, klienti më i mirë do të bëhet ping për të kontrolluar.

Çdo mjet që do të përpiqet të krijojë lidhje me serverin mund të përdoret për të verifikuar që lidhja është duke u bllokuar.

Duke përdorur mjete nga koleksioni i porteve si nmap, mund të skanoni me lehtësi porta të shumta edhe në hoste të shumtë. Nëse rezultatet nuk duken shumë të qarta, mos u bëni shumë dembel për të parë faqen e njeriut. Për shembull, në një port TCP, skaneri kthehet 'i pafiltruar' kur nmap merr një RST nga pf. Gjithashtu, pf e instaluar në të njëjtën makinë si skaner mund të ndikojë në korrektësinë e nmap.

Mjetet më të sofistikuara të skanimit mund të përfshijnë mjete për krijimin e paketave IP të fragmentuara ose të pavlefshme.

Për të verifikuar që filtri kalon lidhjet e specifikuara në politikë, metoda më e mirë është të kontrolloni duke përdorur aplikacionet që do të përdoren më pas nga klientët. Pra, kontrolloni kalimin e lidhjeve http nga makina të ndryshme klientësh të serverit në internet, si dhe nga shfletues të ndryshëm dhe marrjen e mostrave përmbajtje të ndryshme do të ishte më mirë sesa thjesht të pranosh krijimin e një sesioni TCP në nc që funksionon si prapavijë. Faktorë të ndryshëm si sistemi operativ pritës mund të shkaktojnë gjithashtu gabime - probleme me shkallëzimin e dritares TCP ose përgjigjet TCP SACK midis sistemeve të caktuara operative.

Kur kalon pikën tjetër të testimit, rezultatet e saj mund të mos jenë gjithmonë të njëjta. Lidhja mund të ndërpritet gjatë procesit të krijimit të një lidhjeje nëse muri i zjarrit kthen RST. Vendosja e lidhjes thjesht mund të përfundojë. Lidhja mund të vendoset plotësisht, të funksionojë, por pas një kohe të ngrijë ose të prishet. Lidhja mund të qëndrojë, por gjerësia e brezit ose vonesa mund të jetë e ndryshme nga ajo e pritura, më e lartë ose më e ulët (në rast se po përdorni AltQ për të kufizuar gjerësinë e brezit).

Si rezultat i pritshëm, përveç kapërcimit/bllokimit të lidhjes, mund të vërehet edhe nëse paketat janë regjistruar, si transmetohen, drejtohen, nëse numëruesit e nevojshëm janë shtuar, nëse është e nevojshme. Nëse këto aspekte janë të rëndësishme për ju, atëherë ato duhet të përfshihen edhe në metodologjinë e testimit.

Politika juaj mund të përfshijë kërkesat e performancës, reagimin e mbingarkesës dhe tolerancën ndaj gabimeve. Dhe ata mund të kërkojnë teste të veçanta. Nëse po konfiguroni një sistem tolerant ndaj gabimeve duke përdorur CARP, ndoshta dëshironi të dini se çfarë ndodh kur ndodhin lloje të ndryshme dështimesh.

Kur shihni një rezultat që është i ndryshëm nga ai që prisnit, shënoni hap pas hapi hapat tuaj gjatë testit, çfarë prisnit, pse e prisnit, rezultatin e marrë dhe si ndryshon rezultati nga pritshmëritë tuaja. Përsëriteni testin për të parë nëse situata është e riprodhueshme apo ndryshon herë pas here. Provoni të ndryshoni parametrat e hyrjes së kontrollit (adresa e burimit / destinacionit ose portet).

Që nga momenti që keni një problem të riprodhueshëm, duhet të filloni korrigjimin për të kuptuar pse gjërat nuk po funksionojnë siç prisnit dhe si të "rregulloni" gjithçka. Me këtë konfigurim, duhet të ndryshoni grupin e rregullave dhe të përsërisni të gjitha testet, duke përfshirë ato që nuk shkaktuan gabime, sepse ndryshimi i rregullave mund të ndikojë pa dashje në funksionimin e pjesëve që funksionojnë siç duhet të grupit të rregullave.

I njëjti parim vlen edhe për ndryshimet e tjera të kompletit. Kjo procedurë zyrtare e rishikimit do të ndihmojë që procesi të jetë më pak i prirur për të paraqitur gabime. Mund të mos jetë e nevojshme të përsëritet e gjithë procedura për ndryshime të vogla, por shuma e disa ndryshimeve të vogla mund të ndikojë në rezultatin e përgjithshëm të përpunimit të grupit. Ju mund të përdorni një sistem kontrolli versioni si cvs për të punuar me skedarin tuaj të konfigurimit, meqë kjo do të ndihmojë në hetimin e ndryshimeve që çuan në gabim. Nëse e dini se gabimi nuk ka ndodhur një javë më parë, por tani është, rishikoni të gjitha ndryshimet e bëra në javen e shkuar do t'ju ndihmojë të vini re problemin, ose të paktën të ktheheni në momentin e mungesës së tij.

Rregulloret jo të parëndësishme mund të mendohen si programe, ato rrallë janë të përsosura në lëshimin e tyre të parë dhe duhet kohë për të deklaruar me besim se janë pa gabime. Megjithatë, ndryshe nga programet e rregullta, të cilat nuk konsiderohen kurrë pa gabime nga shumica e programuesve, grupet e rregullave janë ende mjaft të thjeshta për t'iu afruar këtij përkufizimi.

Korrigjimi

Termi debugging zakonisht i referohet gjetjes dhe rregullimit të gabimeve të programimit në programet kompjuterike. Ose, në kontekstin e grupeve të rregullave të murit të zjarrit, termi do të nënkuptonte procesin e kërkimit të një arsyeje pse grupi nuk kthen rezultatin e dëshiruar. Ka pak lloje gabimesh që mund të shfaqen në rregulla, megjithatë, metodat për gjetjen e tyre janë të ngjashme me programimin.

Para se të filloni të kërkoni për shkakun e problemit, duhet të kuptoni qartë natyrën e problemit. Nëse keni vërejtur vetë një gabim gjatë testimit, është shumë e thjeshtë. Por nëse një person tjetër ju tregon për një defekt, vendosja e një objektivi të qartë nga një raport i pasaktë i gabimeve mund të jetë një detyrë e frikshme. Vendi më i mirë për të filluar është të riprodhoni vetë defektin.

Problemet e rrjetit mund të mos shkaktohen gjithmonë nga një filtër paketash. Përpara se të përqendroheni në korrigjimin e konfigurimit pf, duhet të siguroheni që problemi është shkaktuar nga një filtër pakete. Kjo është e lehtë për t'u bërë dhe gjithashtu mund t'ju kursejë kohë për zgjidhjen e problemeve diku tjetër. Thjesht fikni pf me komandën pfctl -d dhe kontrolloni nëse problemi rishfaqet. Nëse po, aktivizoni pf me pfctl -e dhe shikoni se çfarë ndodh. Kjo metodë do të dështojë në disa raste, për shembull, nëse pf nuk bën përkthimin e saktë. adresat e rrjetit(NAT) pastaj fikja e pf padyshim që nuk do t'ju kursejë gabimin. Por aty ku është e mundur, përpiquni të siguroheni që filtri i paketës është fajtori.

Prandaj, nëse problemi është në filtrin e paketës, gjëja e parë që duhet të bëni është të siguroheni që pf po funksionon me të vërtetë dhe se grupi i saktë i rregullave është ngarkuar me sukses:

# pfctl -si | Statusi grep

Statusi: Aktivizuar për 4 ditë 13: 47: 32 Korrigjimi: Urgjent

# pfctl -sr

kaloni shpejt lo0 të gjitha

kaloni shpejt në enc0 të gjitha

Korrigjimi sipas protokolleve

Hapi tjetër në korrigjimin e gabimeve është pasqyrimi i problemit në lidhjet specifike të rrjetit. Nëse keni një premisë: "Mesazhet e çastit në aplikacionin X nuk funksionojnë", duhet të zbuloni se cilat lidhje rrjeti janë në përdorim. Përfundimi mund të jetë "hosti A nuk mund të krijojë një lidhje me hostin B në portin C." Ndonjëherë kjo detyrë është më e vështira, por nëse keni informacion për lidhjet e nevojshme dhe e dini që muri i zjarrit nuk do t'i lejojë ato, thjesht duhet të ndryshoni rregullat për të zgjidhur këtë problem.

Ka disa mënyra për të zbuluar se cilat protokolle ose lidhje po përdor një aplikacion. Tcpdump mund të shfaqë paketat brenda dhe jashtë ndërfaqes reale të rrjetit, si dhe ato virtuale si pflog dhe pfsync. Ju mund të specifikoni një shprehje filtruese për të specifikuar se cilat paketa të shfaqen dhe të eliminoni zhurmën e padëshiruar të rrjetit. Provoni të instaloni lidhje rrjeti në aplikacionin e dëshiruar dhe shikoni paketat që dërgohen. Për shembull:

# tcpdump -nvvvpi fxp0 tcp dhe jo port ssh dhe jo port smtp

23: 55: 59.072513 10.1.2.3.65123> 10.2.3.4.6667: S

4093655771: 4093655771 (0) fiton 5840

1039287798 0, nop, wscale 0> (DF)

Kjo është paketa TCP SYN, paketa e parë nga lidhja e krijuar TCP (shtrëngim duarsh TCP).

Dërguesi është porti 10.1.2.3 65123 (duket si një port i rastësishëm i paprivilegjuar) dhe marrësi është porta 10.2.3.4 6667. Për një shpjegim të detajuar të formatit të daljes tcpdump, shihni faqet manuale të programit. Tcpdump është mjeti më i rëndësishëm për korrigjimin e problemeve të lidhura me pf, dhe është shumë e rëndësishme të njiheni me të.

Një metodë tjetër është përdorimi i funksionit të logging në pf. Duke supozuar se përdorni opsionin 'log' në të gjitha rregullat me 'block', atëherë të gjitha paketat e bllokuara nga pf do të regjistrohen. Mund të hiqni opsionin 'log' nga rregullat që kanë të bëjnë me protokollet e njohura, d.m.th. do të regjistrohen vetëm ato paketa që shkojnë në porte të panjohura. Provoni të përdorni një aplikacion që nuk mund të komunikojë dhe hidhini një sy pflog:

# ifconfig pflog0 lart

# tcpdump -nettti pflog0

26 nëntor 00: 02: 26.723219 rregulli 41/0 (ndeshja): blloko në kue0:

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

16384 (DF)

Nëse jeni duke përdorur pflog, një demon që vazhdimisht dëgjon pflog0 dhe ruan informacionin që rezulton në / var / log / pflog, mund të shihni informacionin e regjistruar si ky:

# tcpdump -netttr /var /log /pflog

Kur shfaqni paketa të ruajtura në pf, mund të përdorni shprehje shtesë filtruese, për shembull, shikoni paketat që u bllokuan në hyrje të ndërfaqes wi0:

# tcpdump -netttr / var / log / pflog blloku hyrës dhe i veprimit dhe në wi0

Disa protokolle, si FTP, nuk janë të lehta për t'u gjurmuar sepse nuk përdorin numra portash fiks, ose përdorin lidhje të shumta që bashkëjetojnë. Mund të mos jetë e mundur kalimi i tyre përmes murit të zjarrit pa hapur një gamë të gjerë portash. Për disa protokolle, ka zgjidhje të ngjashme me ftp-proxy.

Rregullat e korrigjimit

Nëse grupi juaj i rregullave bllokon një protokoll të veçantë sepse nuk keni hapur portin e duhur, ky është më shumë një problem dizajni sesa një gabim rregullash. Por, çka nëse shihni se po bllokohet një lidhje për të cilën keni një rregull që e kalon atë?

Për shembull, grupi juaj përmban rregullin

blloko në return-rst në $ ext_if proto tcp nga cilido në portin $ ext_if ssh

Por kur përpiqeni të lidheni me Porta TCP 22, lidhja pranohet! Duket sikur muri i zjarrit po injoron rregullin tuaj. Ashtu si me montimin e "puzzles me bashkim pjesësh figure", në këto raste, kur përballemi me to herët e para, ka një shpjegim të thjeshtë logjik dhe zakonisht të parëndësishëm.

Së pari, duhet të kontrolloni të gjitha hapat e përmendur më parë. Për shembull, supozoni se muri i zjarrit po funksionon dhe përmban rregullin e mësipërm. Nuk ka gjasa që shqetësimet tona të mëparshme të jenë të vlefshme, por kjo është e lehtë për t'u verifikuar:

# pfctl -si | Statusi grep

Statusi: Aktivizuar për 4 ditë 14: 03: 13 Korrigjimi: Urgjent

# pfctl -gsr | grep "port = ssh"

@ 14 blloko kthimin-rst në në kue0 inet proto tcp nga çdo në 62.65.145.30 port = ssh

Gjëja tjetër që kemi është që lidhjet TCP pranohen në portin 22 në kue0. Ju mund të mendoni se kjo tashmë është e qartë, por nuk do të jetë e tepërt të kontrollohet. Ekzekutoni tcpdump:

# tcpdump -nvvvi kue0 tcp dhe porta 22 dhe dst 62.65.145.30

Tani provoni përsëri lidhjen SSH. Ju duhet të shihni paketat nga lidhja juaj në daljen tcpdump. Ju mund të mos i shihni ato, dhe kjo mund të jetë për shkak se lidhja në të vërtetë nuk kalon përmes kue0, por kalon përmes një ndërfaqeje tjetër, gjë që shpjegon pse rregulli nuk funksionon. Ose mund të jeni duke u lidhur me një adresë tjetër. Me pak fjalë, nëse nuk i shihni paketat ssh, atëherë as pf nuk do t'i shohë ato, ndoshta nuk mund t'i bllokojë ato duke përdorur rregullin e dhënë në detyrën tonë.

Por nëse shihni paketa me tcpdump, pf do t'i shohë edhe ato dhe do t'i filtrojë. Supozimi tjetër është se rregulli i bllokimit nuk duhet të jetë vetëm i pranishëm në grup (të cilin e kemi zbuluar tashmë), por të jetë rregulli i fundit i përputhjes për paketat e kërkuara. Nëse ky nuk është rregulli i fundit, padyshim, sipas kësaj, vendimi për vonesën e paketave nuk merret.

Kur një rregull mund të mos jetë rregulli i fundit që përputhet? Ka tre arsye të mundshme:

A) rregulli nuk funksionon, pasi shikimi i rregullave nuk arrin atë që na nevojitet.

Një rregull i mëparshëm i pranishëm gjithashtu ndez dhe shkakton një abort me opsionin "i shpejtë";

B) rregulli përpunohet, por rregulli nuk funksionon për shkak të mospërputhjes midis disa kritereve.

C) rregulli përpunohet, rregulli aktivizohet, por përpunimi vazhdon dhe rregullat pasuese aktivizohen gjithashtu për paketën.

Për të refuzuar këto tre raste, mund të vizualizoni përpunimin e një pakete hipotetike TCP që arrin në ndërfaqen kue0 dhe portin 22 duke parë grupin e rregullave të ngarkuar. Zgjidhni bllokun që do të korrigjohet. Filloni duke kaluar rregullin e parë. A përputhet? Nëse po, shënojeni. A ka një opsion 'të shpejtë'? Nëse po, atëherë ne ndalojmë së anashkaluari. Nëse jo, vazhdoni me duke ndjekur rregullin... Përsëriteni testin derisa të përputhet me opsionin "i shpejtë" ose të arrijë në fund të grupit të rregullave. Cili rregull u përputh për herë të fundit? Nëse nuk është rregulli numër 14, ju keni gjetur një shpjegim për problemin.

Anashkalimi i rregullave me dorë mund të duket argëtues, megjithatë, nëse keni përvojë të mjaftueshme, mund të bëhet mjaft shpejt dhe me një shkallë të lartë besueshmërie. Nëse grupi është mjaft i madh, mund ta shkurtoni përkohësisht. Mbani një kopje të listës aktuale të rregullave dhe fshini çdo hyrje që mendoni se nuk do të ndikojë në rezultatin. Shkarkoni këtë komplet dhe kontrolloni përsëri. Nëse lidhja tani është e bllokuar, atëherë rregullat që dukej se nuk kishin lidhje me paketat e kërkuara janë përgjegjëse për rastet A ose B. Shtoni rregullat një nga një, duke përsëritur testin derisa të gjeni atë që dëshironi. Nëse lidhja është anashkaluar ende pas fshirjes së rregullave që nuk ndikojnë në të, përsëritni kalimin mendor të grupit të reduktuar.

Një metodë tjetër është përdorimi i aftësisë së regjistrimit të pf për të identifikuar rastet A ose C. Shtoni 'log' në të gjitha rregullat me 'kalim shpejt' përpara rregullit të 14-të. Shtoni "log" në të gjitha rregullat me "kalim" pas rregullit 14. Ekzekutoni tcpdump në ndërfaqen pflog0 dhe krijoni një lidhje ssh. Do të shihni se cilat rregulla, përveç datës 14, janë aktivizuar të fundit në paketat tuaja. Nëse nuk ka asgjë në regjistër, atëherë rasti B po zhvillohet.

Ndjekja e lidhjeve përmes një muri zjarri

Kur një lidhje kalon përmes një muri zjarri, paketat arrijnë në njërën ndërfaqe dhe dërgohen përmes tjetrës. Përgjigjet vijnë në ndërfaqen e dytë dhe shkojnë te e para. Kështu, lidhjet mund të hiqen në secilin prej këtyre katër rasteve.

Së pari, duhet të kuptoni se cili nga katër rastet është problemi. Nëse përpiqeni të krijoni një lidhje, duhet të shihni një paketë TCP SYN në ndërfaqen e parë duke përdorur tcpdump. Ju gjithashtu duhet të shihni të njëjtën paketë TCP SYN në daljen nga ndërfaqja e dytë. Nëse nuk e shihni, atëherë konkludojmë se pf po bllokon paketa hyrëse në ndërfaqen e parë, ose në dalje në të dytën.

Nëse dërgimi SYN nuk është i bllokuar, duhet të shihni SYN + ACK që hyn në ndërfaqen e dytë dhe del në të parën. Nëse jo, pf bllokon SYN + ACK në një ndërfaqe.

Shtoni opsionin "log" tek rregullat që duhet të lejojnë SYN dhe SYN + ACK në të dy ndërfaqet, dhe rregullat që duhet t'i bllokojnë ato. Provoni të lidheni përsëri dhe kontrolloni pflog. Ai duhet të sqarojë se në cilin rast ndodh bllokimi dhe me çfarë rregulli.

Rregullimi i gjendjeve të lidhjes

Arsyeja më e zakonshme që pf bllokon paketat është sepse ekziston një rregull bllokimi i tepërt në grup. Një rregull i përputhjes që aktivizohet në ndeshjen e fundit mund të gjendet duke shtuar opsionin 'log' për të gjitha rregullat që mund të ndikojnë dhe duke dëgjuar ndërfaqen pflog.

Në më pak raste, ndodh që pf hedh në heshtje paketat bazuar në jo-rregulla, dhe këtu shtimi i një 'log' në të gjitha rregullat nuk do të bëjë që paketat e hedhura të shkojnë në pflog. Shpesh, një paketë pothuajse, por jo plotësisht, përputhet me një hyrje në gjendje.

Mos harroni se për çdo paketë që përpunon, filtri i paketave kryen një skanim të tabelës së gjendjes. Nëse gjendet një hyrje që përputhet, paketa anashkalohet menjëherë pa shkaktuar vetë përpunimin e grupit të rregullave.

Një hyrje në tabelën e gjendjes përmban informacion specifik për një lidhje të vetme.

Çdo hyrje ka një çelës unik. Ky çelës përbëhet nga disa vlera që janë konstante gjatë gjithë jetës së lidhjes. Këtu ata janë:

• Lloji i adresës (Ipv4 ose Ipv6)
• Adresa e burimit
• Adresa e marrësit
• Protokolli (TCP UDP)
• Porta e burimit
• Porta e marrësit

Ky çelës përdoret për të gjitha paketat që lidhen me të njëjtën lidhje dhe paketa lidhje të ndryshme do të ketë gjithmonë çelësa të ndryshëm.

Kur një opsion "mbaj gjendjen" përdoret për të krijuar një hyrje në tabelën e gjendjes, regjistrimi i lidhjes mbahet duke përdorur çelësin e asaj lidhjeje. Një kufizim i rëndësishëm për tabelën e gjendjes është se të gjithë çelësat duhet të jenë unikë. ato. nuk mund të ketë dy regjistrime me çelësa të njëjtë.

Mund të mos jetë menjëherë e qartë se të dy hostet e njëjtë nuk mund të krijojnë lidhje të shumta bashkëekzistuese duke përdorur të njëjtat adresa, protokolle dhe porte, por kjo është pronë themelore si TCP ashtu edhe UDP. Në fakt, pirgjet TCP/IP mund të lidhin vetëm paketa individuale me bazat e tyre duke marrë në bazë të adresave dhe porteve.

Edhe nëse lidhja mbyllet, e njëjta palë adresash dhe portash nuk mund të ripërdoren menjëherë. Paketat e ritransmetuara mund të dorëzohen më vonë nga pajisja e rrjetit dhe nëse rafti TCP/IP i marrësit i ngatërronte ato me paketat e lidhjes së krijuar rishtazi, kjo do të parandalonte ose madje do të përfundonte lidhjen e re. Për këtë arsye, të dy hostet duhet të presin një kohë të caktuar të quajtur 2MSL (dyfishi i jetëgjatësisë maksimale të segmentit) përpara se të jenë në gjendje të përdorin të njëjtat adresa dhe porte përsëri për një lidhje të re.

Ju mund ta vëzhgoni këtë veçori duke krijuar manualisht lidhje të shumta me të njëjtin host. Për shembull, të kesh një server në internet që funksionon në 10.1.1.1 dhe portin 80, dhe të lidhesh dy herë me 10.2.2.2. duke përdorur nc:

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

Lidhja me portën 10.1.1.1 80 pati sukses!

Ndërsa lidhjet janë të hapura, mund të përdorni netstat në klientin ose serverin për të shfaqur informacione rreth këtyre lidhjeve:

$ netstat -n | grep 10.1.1.1.80

tcp 0 0 10.2.2.6.28054 10.1.1.1.80 E THEMELUAR

tcp 0 0 10.2.2.6.43204 10.1.1.1.80 E THEMELUAR

Siç mund ta shihni, klienti ka zgjedhur dy porte burimi të ndryshme (të rastësishme), kështu që kjo nuk cenon kërkesën për unike të çelësit.

Mund t'i thuash nc-së të përdorë një port specifik burimi me opsionin -p:

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

Lidhja me portën 10.1.1.1 80 pati sukses!

nc: lidhja dështoi: Adresa tashmë është në përdorim

Klienti TCP/IP parandaloi shkeljen e veçantisë së çelësit. Disa zbatime të rralla dhe me të meta të pirgjeve TCP / IP nuk e ndoqën këtë rregull, dhe kështu, siç do të shohim së shpejti, pf do të bllokojë lidhjet e tyre nëse shkelet unike e çelësit.

Le të kthehemi atje ku pf po kërkon tabelën e gjendjes në kohën kur paketa fillon të filtrohet. Kërkesa përbëhet nga dy hapa. Kërkesa e parë është të gjesh një hyrje në tabelën e regjistrimit me një çelës që korrespondon me protokollin, adresat dhe portin e paketës. Kërkimi do të kryhet për pako që shkojnë në çdo drejtim. Supozoni se paketa më poshtë ka krijuar një hyrje në tabelën e gjendjes:

hyrëseTCPnga 10.2.2.2: 28054deri në 10.1.1.1:80

Një pyetje në tabelë do të gjejë hyrjet e mëposhtme në tabelën e gjendjes:

TCP hyrëse nga 10.2.2.2:28054 në 10.1.1.1:80

TCP dalëse nga 10.1.1.1:80 në 10.2.2.2: 28054

Regjistrimi në tabelë përfshin informacion në lidhje me drejtimin (në hyrje ose në dalje) të paketës së parë që krijoi rekordin. Për shembull, të dhënat e mëposhtme nuk do të përputhen:

dalëseTCPnga 10.2.2.2: 28054deri në 10.1.1.1:80

hyrëseTCPnga 10.1.1.1:80në 10.2.2.2: 28054

Arsyeja për këto kufizime nuk është e qartë, por mjaft e thjeshtë. Imagjinoni që keni vetëm një ndërfaqe në 10.1.1.1 ku serveri në internet dëgjon në portin 80. Kur një klient 10.2.2.2 lidhet duke përdorur një port të rastësishëm dalës 28054, paketa e parë e lidhjes arrin në ndërfaqen tuaj dhe të gjitha përgjigjet tuaja dalëse do të shkojnë nga 10.1.1.1:80 deri në 10.2.2.2: 28054. Ju nuk do të lejoni paketat dalëse nga 10.2.2.2:28054 deri në 10.1.1.1:80, pasi paketa të tilla janë të pakuptimta.

Nëse muri juaj i zjarrit është i konfiguruar për dy ndërfaqe, atëherë duke vëzhguar paketat që kalojnë nëpër të, do të shihni se çdo paketë që arrin në ndërfaqen e parë del jashtë dhe përmes së dytës. Nëse krijoni një rekord të gjendjes në të cilën paketa fillestare arrin në ndërfaqen e parë, atëherë ai rekord do të parandalojë që e njëjta paketë të largohet nga ndërfaqja e dytë sepse është në drejtimin e gabuar.

Kur një përpjekje për të gjetur një paketë midis hyrjeve në tabelën e gjendjes dështon, lista e rregullave të filtrit kalon. Në mënyrë specifike duhet të lejoni që paketa të dalë përmes ndërfaqes së dytë me një rregull të veçantë. Me shumë mundësi, në këtë rregull po përdorni "gjendjen e mbajtjes" në mënyrë që hyrja e dytë në tabelën e gjendjes të mbulojë të gjithë lidhjen në ndërfaqen e dytë gjithashtu.

Ju mund të pyesni veten se si është e mundur të krijohet një rekord i dytë në një tabelë kur sapo shpjeguam se regjistrimet duhet të kenë çelësa unikë. Shpjegimi këtu është se rekordi gjithashtu përmban informacion për drejtimin e lidhjes dhe kombinimi i kësaj me të dhënat e tjera duhet të jetë unik.

Tani do të jemi gjithashtu në gjendje të shpjegojmë ndryshimin midis një lidhjeje të lirë dhe një lidhjeje të lidhur me ndërfaqe. Si parazgjedhje, pf krijon hyrje që nuk janë të lidhura me asnjë ndërfaqe. Prandaj, nëse lejoni lidhjet në një ndërfaqe, paketat që lidhen me lidhjen dhe që bien nën hyrjen e tabelës (përfshirë informacionin e drejtimit të paketës!) Kaloni nëpër çdo ndërfaqe. Në instalime të thjeshta me rrugëzim statik, kjo është më shumë llogaritje teorike. Në thelb, ju nuk duhet të shihni paketat e një lidhjeje që vijnë përmes disa ndërfaqeve dhe paketave të përgjigjes duke lënë gjithashtu disa ndërfaqe. Megjithatë, me rrugë dinamike, kjo është e mundur. Ju mund t'i lidhni të dhënat e gjendjes me një ndërfaqe specifike duke përdorur cilësimin global "vendosni politikën e shtetit nëse-bound" ose opsionin "mbaj gjendjen (nëse-bound)" për secilin rregull. Kjo do të sigurojë që paketat do të përputhen vetëm me hyrjet nga ndërfaqja që krijoi hyrjet.

Nëse jeni duke përdorur ndërfaqe për tunele, atëherë e njëjta lidhje kalon nëpër murin e zjarrit disa herë. Për shembull, paketa e parë e lidhjes mund të kalojë fillimisht përmes ndërfaqes A, pastaj përmes B, pastaj C dhe në fund të na lërë përmes ndërfaqes D. Zakonisht, paketat do të inkapsulohen në ndërfaqet A dhe D dhe do të dekapsulohen në B dhe C, kështu që pf sheh pako të protokolleve të ndryshme dhe mund të krijoni 4 hyrje të ndryshme në tabelën e gjendjes. Pa enkapsulim, paketa do të jetë e pandryshuar në të katër ndërfaqet dhe nuk do të mund të përdorni disa veçori, të tilla si përkthimi i adresës ose modulimi i numrit të sekuencës tcp, sepse kjo do të çojë në konflikte të çelësave në tabelën e gjendjes. Derisa të keni një instalim të plotë që përfshin ndërfaqe me tunele dhe gabime të korrigjuara si "pf: futja e src_tree dështoi", nuk do të mund ta konsideroni instalimin tuaj si mjaft të suksesshëm. Le të kthehemi në kërkimin e tabelës së gjendjes për secilën paketë përpara se të kontrollojmë rregullat. Kërkesa duhet të kthejë një regjistrim të vetëm me çelësi i përshtatshëm, ose nuk ktheni asgjë. Nëse pyetja nuk kthen asgjë, lista e rregullave kalohet.

Nëse gjendet një hyrje, hapi i dytë për paketat TCP është kontrollimi i numrit të sekuencës përpara se ato të konsiderohen se i përkasin një lidhjeje specifike dhe të filtrohen.

ka nje numer i madh i Sulmet TCP në të cilat një sulmues përpiqet të kontrollojë një lidhje midis dy hosteve. Në shumicën e rasteve, sulmuesi nuk është në rrugën e rrugëve midis hosteve, kështu që ai nuk mund të dëgjojë paketat legjitime të dërguara nga hostet. Megjithatë, ai mund t'i dërgojë pako cilitdo nga hostet, duke imituar paketat e bashkëbiseduesit të tij, me anë të mashtrimit - falsifikimit të adresës së dërguesit. Qëllimi i një sulmuesi mund të jetë të parandalojë krijimin e lidhjeve midis hosteve, ose të prishë lidhjet ekzistuese (për të shkaktuar një mohim të shërbimit), ose të krijojë një ngarkesë me qëllim të keq në lidhje.

Për një sulm të suksesshëm, një sulmues duhet të "mendojë" saktë disa parametra lidhjeje, të tilla si adresa / porta e burimit dhe destinacionit. Dhe për protokollet e përdorur gjerësisht, mund të mos jetë aq e vështirë sa mund të duket. Nëse sulmuesi njeh adresat e hostit dhe një nga portet (meqë po flasim për një shërbim të përbashkët), ai do të duhet vetëm të "mendojë" një port. Edhe nëse klienti përdor një port me burim të vërtetë të rastësishëm (që në fakt nuk është gjithmonë e vërtetë), sulmuesi duhet vetëm të provojë 65536 porte në një kohë të shkurtër. (Në shumicën e rasteve, edhe porte (65536-1024), d.m.th. vetëm porte të paprivilegjuara - shënimi i përkthyesit))

Por ajo që është vërtet e vështirë për një sulmues të hamendësohet është numri i saktë i sekuencës (dhe konfirmimi i tij). Nëse zgjedhin të dy pritësit numri i fillimit sekuencat në mënyrë të rastësishme (ose përdorni modulimin e numrit të sekuencës për hostet që kanë një gjenerator "të dobët" ISN (Numri i Sekuencës Fillestare)), atëherë sulmuesi nuk do të jetë në gjendje të zgjedhë vlerën e duhur në kohën e duhur të lidhjes.

Gjatë jetës së një lidhjeje të vlefshme TCP, numrat e sekuencës (dhe njohjet) për paketat individuale ndryshohen sipas rregullave të caktuara.

Për shembull, nëse një host dërgon një segment të caktuar të të dhënave dhe marrësi i tij e pranon marrjen, nuk duhet të ketë arsye pse dërguesi duhet të dërgojë përsëri të dhënat e segmentit. Por, në fakt, përpjekja për të mbishkruar pjesët e informacionit të marrë tashmë nga hosti nuk është shkelje. Protokolli TCP, megjithëse mund të jetë një formë sulmi.

pf përdor rregulla për të përcaktuar diapazonin më të vogël për numrat legjitim të sekuencës. Në përgjithësi, pf mund të identifikojë me saktësi vërtetësinë e 30,000 nga 4294967296 numrat e mundshëm sekuencë në çdo kohë të lidhjes. Vetëm nëse numri i sekuencës dhe konfirmimi hyn në këtë dritare, do të sigurohet që paketa të jetë legjitime dhe ta lërë të kalojë.

Nëse gjatë një pyetësori në tabelën e gjendjes gjendet hyrje e përshtatshme, në hapi tjeter numrat e sekuencës së paketave të ruajtura në tabelë kontrollohen kundrejt diapazonit vlerat e mundshme... Nëse krahasimi dështon, pf do të gjenerojë një mesazh "gjendje e keqe" dhe do ta heqë paketën pa e vlerësuar grupin e rregullave. Ka dy arsye pse krahasimi me rregullat mund të mos ndodhë: është pothuajse me siguri një gabim të kapërcesh paketën, pasi nëse llogaritja e grupit do të rezultojë në goditjen e një opsioni në rregull "mbaj shtet" dhe pf nuk do te mund te gjykoje e te krijoje hyrje e re sepse kjo do të çojë në konflikte të çelësave në tabelë.

Për të parë dhe shkruar mesazhet "gjendja e keqe" në regjistër, duhet të aktivizoni modalitetin e korrigjimit duke përdorur komandën:

$ pfctl -xm

Mesazhet e korrigjimit dërgohen në tastierë si parazgjedhje, dhe syslogd gjithashtu i shkruan ato në / var / log / mesazhe. Kërkoni mesazhe që fillojnë me "pf":

pf:KEQshtet:TCP 192.168.1.10:20 192.168.1.10:20 192.168.1.200:64828

[ ja = 1185380879lartë = 1185380879fitim = 33304modulator = 0wscale = 1]

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

dir = jashtë, fwd

pf: Dështimi shtetëror më: 1 |

Këto mesazhe vijnë gjithmonë në çifte. Mesazhi i parë tregon hyrjen në tabelën e gjendjes në kohën kur paketa u bllokua dhe numrin e sekuencës së paketës që shkaktoi gabimin. Hyrja e dytë tregon kushtet që janë shkelur.

Në fund të mesazhit të parë, do të shihni nëse një rekord statusi është krijuar për një paketë hyrëse (dir = brenda) ose dalëse (dir = dalë) dhe nëse paketa e bllokuar shkoi në të njëjtin drejtim (dir =, fwd) ose drejtim të kundërt (dir =, rev ).

Hyrja në tabelë përmban tre adresa: çifte portash, dy prej të cilave janë gjithmonë të barabarta me njëra-tjetrën, nëse lidhja nuk ka pësuar konvertim nat, rdr ose bnat. Për lidhjet dalëse, burimi shfaqet në të majtë dhe destinacioni i paketës është në të djathtë. Nëse lidhje dalëse mundëson konvertimin e adresës së burimit, çifti në mes tregon burimin pas konvertimit. Për lidhjet hyrëse, burimi është në të djathtë në pin dhe destinacioni është në mes. Nëse lidhja në hyrje i nënshtrohet një përkthimi të adresës së destinacionit, çifti ip/port në të majtë tregon destinacionin pasi të jetë kryer përkthimi. Ky format përputhet me daljen e pfctl -ss, me ndryshimin e vetëm që pfctl tregon drejtimin e paketës duke përdorur shigjetat.

Në dalje, mund të shihni numrat e sekuencës aktuale të hostit në kllapa katrore. Pra, vlera "4: 4" do të thotë që lidhja është krijuar plotësisht (vlerat më të ulëta kanë më shumë gjasa në fazën e vendosjes së një lidhjeje, vlera më të larta - deri në kohën kur lidhja mbyllet)."A" do të thotë që paketa e bllokuar kishte vendosur flamurin ACK (si në daljen e flamujve për tcpdump), e ndjekur nga vlerat e numrave të sekuencës (seq =) dhe (ack =) në paketat e bllokuara dhe ngarkesën gjatësia e paketës - gjatësia e të dhënave (len =). askskew është një pjesë e paraqitjes së brendshme të të dhënave në një tabelë, e cila përdoret vetëm kur vlerat nuk janë të barabarta me zero.

Rekordi "pkts = 930: 631" do të thotë se ka përputhur 940 pako në të njëjtin drejtim si ai që shkaktoi krijimin e këtij regjistrimi dhe 631 pako në drejtim të kundërt. Këto sportele do të jenë veçanërisht të dobishme kur kërkoni probleme në fazën e vendosjes së një lidhjeje, nëse një prej tyre është zero, kjo do të kundërshtonte pritshmërinë tuaj që rekordi i dhënë do të përputhet me paketat që shkojnë në të dy drejtimet.

Mesazhi i mëposhtëm do të përmbajë një listë me një ose më shumë shifra. Çdo shifër përfaqëson kontrollin në të cilin ndodhi gabimi:

1. madhësia e dritares së paketës tejkalon madhësinë maksimale të marrësit (seq + len> lartë)
2. paketa përmban të dhëna tashmë të transmetuara (seq< lo - win)
3. ackskew është më e vogël se vlera minimale
4. ackskew është më e madhe se vlera maksimale
5. njëjtë si në (1), por me diferencën (seq + len> lartë + fitim)
6. njëjtë si në (2), por (seq< lo - maximum win)

Për fat të mirë, mesazhet "gjendja e keqe" nuk lidhen me trafikun real të përditshëm dhe pf kontrollimi i numrit të sekuencës shmang shumicën e anomalive. Nëse i shihni këto mesazhe që shfaqen në mënyrë të parregullt dhe nuk vini re një numër të madh lidhjesh të varura, thjesht mund t'i shpërfillni ato. Ka shumë implementime TCP/IP në internet, dhe disa prej tyre ndonjëherë mund të gjenerojnë pako të gabuara.

Megjithatë, kjo klasë problemesh mund të diagnostikohet lehtësisht nga shfaqja e mesazheve "BAD State", të cilat shfaqen vetëm në raste të tilla.

Krijimi i të dhënave shtetëroreTCP në fillimPaketa SYN.

Në mënyrë ideale, të dhënat e gjendjes duhet të gjenerohen kur të arrijë paketa e parë SYN.

Ju mund të zbatoni përdorimin e këtij rregulli duke përdorur parimin:

"Përdorni" flamujt S / SA "opsionet në të gjitha" kaloni protokollin tcp mbani gjendjen "rregullat"

Vetëm (dhe vetëm) paketat fillestare SYN kanë flamurin SYN të vendosur dhe një ACK të mbledhur. Kur përdorni opsionin "keep state" lidh vetëm paketat fillestare SYN, vetëm ato paketa do të krijojnë një hyrje në tabelën e gjendjes. Kështu, çdo hyrje ekzistuese në tabelën e gjendjes do të bëhet nga paketa fillestare SYN.

Arsyeja për krijimin e regjistrimeve vetëm për paketat fillestare është një zgjatje TCP e quajtur "shkallëzimi i dritares", i përcaktuar në RFC1323. Fusha e kokës TCP e përdorur për të reklamuar madhësinë e dritareve të marra është shumë e vogël për lidhjet e sotme me shpejtësi të lartë. Implementimet moderne TCP/IP preferojnë të përdorin madhësi më të mëdha të dritareve sesa mund të përshtaten në fushën ekzistuese. Shkallëzimi i dritares do të thotë që të gjitha madhësitë e dritareve që njihen nga hosti marrës duhet të shumëzohen me një vlerë specifike të dhënë nga marrësi dhe jo të merren vetë. Në mënyrë që kjo skemë të funksionojë, të dy hostet duhet të mbështesin zgjerimin dhe t'i tregojnë njëri-tjetrit aftësinë e tyre për ta zbatuar atë në fazën e shtrëngimit të duarve duke përdorur opsionet TCP. Këto opsione janë të pranishme vetëm në paketat fillestare SYN dhe SYN + ACK. Dhe vetëm nëse secila prej këtyre paketave përmban një opsion, negocimi do të jetë i suksesshëm dhe madhësia e dritares së të gjitha paketave pasuese do të shumëzohet me një faktor.

Nëse pf nuk do të "dinte" për shkallëzimin e dritares së përdorur, do të merrej vlera e dhënë pa koeficientin dhe llogaritja e madhësive të dritareve për vlerat e pranueshme të numrave të sekuencës do të kryhej gabim. Në mënyrë tipike, hostet ofrojnë madhësi të vogla dritaresh në fillim të një lidhjeje dhe i rrisin ato gjatë lidhjes. I pavetëdijshëm për ekzistencën e faktorëve që ndryshojnë madhësinë e dritares, pf do të fillojë të bllokojë paketat në një moment, sepse do të mendojë se një nga hostet po përpiqet të anashkalojë madhësinë maksimale të dritares të ofruar nga "bashkëbiseduesi". Efektet e kësaj mund të jenë pak a shumë të dukshme. Ndonjëherë, hostet do të reagojnë ndaj humbjes së paketave duke shkuar te të ashtuquajturat. "Modaliteti i rikuperimit të humbjes" dhe do të reklamojë një madhësi më të vogël të dritares. Pasi pf ritransmeton paketat që u hodhën herën e parë, madhësitë e dritareve do të rriten më tej deri në pikën në të cilën pf fillon t'i bllokojë përsëri. Një manifestim i jashtëm mund të jetë ngrirja e përkohshme e lidhjeve dhe performance e dobet... Mundësisht gjithashtu varje e plotë ose rivendosni lidhjet me skadimin e kohës.

Por pf di për aftësinë për të shkallëzuar dritaret dhe e mbështet atë. Megjithatë, parakushti për krijimin e hyrjeve në tabelën e gjendjes për paketat e para SYN është që pf të mund të lidh dy paketat e para të një lidhjeje me një rekord në tabelë. Dhe meqenëse përputhja e plotë e koeficientëve të madhësisë së dritares ndodh vetëm në këto dy paketat e para, nuk ka asnjë metodë të besueshme për të përcaktuar këta koeficientë pas negociatave të lidhjes.

Në të kaluarën, shkallëzimi i dritareve nuk përdorej gjerësisht, por kjo po ndryshon me shpejtësi. Vetëm kohët e fundit ky opsion është aktivizuar si parazgjedhje në Linux. Nëse keni probleme me varjen e lidhjeve, veçanërisht me disa kombinime pritëse, dhe shihni mesazhe "gjendje e keqe" që lidhen me ato lidhje, sigurohuni që në të vërtetë po krijoni hyrje në tabelën e gjendjes për paketat e para të lidhjes.

Mund të dalloni nëse pf përdor opsionin e shkallëzimit për bashkimin nga dalja pfctl:

$ pfctl -vss

kue0 tcp 10.1.2.3:10604 -> 10.2.3.4:80 I THEMELIKUAR: I THEMELUAR

wshkalla 0wshkalla 1

Nëse hyrja "wscale x" e printuar në rreshtin e dytë është e pranishme (edhe nëse x është zero), pf reads e di se bashkimi po përdor shkallëzim.

Një metodë tjetër e thjeshtë për identifikimin e problemeve të shkallëzimit është çaktivizimi i përkohshëm i mbështetjes së shkallëzimit dhe rishikimi i situatës. Në OpenBSD, përdorimi i shkallëzimit mund të kontrollohet me opsionin sysctl:

$ sysctlneto.inet.tcp.rfc1323

neto.inet.tcp.rfc1323 = 1

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

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

Probleme të ngjashme shfaqen kur krijoni hyrje në tabelën e gjendjes për paketa të ndryshme nga SYN-të fillestare dhe përdorni opsionin ose transmetimin e modulimit të gjendjes. Në të dyja rastet, transmetimi ndodh në fillim të lidhjes. Nëse paketa e parë nuk transmetohet, transmetimi i atyre të mëvonshme zakonisht dekurajon anën marrëse dhe bën që përgjigjet e dërguara të bllokohen nga pf me mesazhin "gjendje e keqe".