Metodologia de testare

Testele au fost efectuate pe un PC experimental care rulează Windows XP licențiat cu SP1 instalat (testele au fost efectuate în condiții idealizate - „sistem de operare + Firewall” pentru a exclude influența altor programe asupra purității experimentului). Utilitarul APS a fost folosit ca indicator al accesului cu succes la servicii. Ca mijloace de influență externă s-au folosit:

• Scaner XSpider 6.5 și 7.0
• Retina Network Security Scanner 4.9
• mai multe scanere ale designului meu.

În plus, a fost folosit sniffer CommView 4.1 (ca mijloc de monitorizare trafic de rețeași ca utilitate pentru generarea și trimiterea de pachete cu diverse nereguli structurale). Asa numitul. floodere de tipuri comune, utilitare pentru imitarea troienilor.

PC-ul de testare a folosit IE 6 ca mijloc de acces la rețea și la Internet, Outlook Express 6, TheBat 1.60, MSN Messanger 6.1. Pe lângă acestea, simulatoare de troieni și programe reale de troiene/Backdoor din colecția mea (în special Backdoor.Antilam, Backdoor.AutoSpy, Backdoor.Death, Backdoor.SubSeven, Backdoor.Netbus, Backdoor.BO2K), viruși de rețea/mail ( I-Worm.Badtrans, I-Worm.NetSky, I-Worm.Sircam, I-Worm.Mydoom, I-Worm.MSBlast), TrojanDownloader Trojan downloaders (în special TrojanDownloader.IstBar) și componente SpyWare. Sarcina principală a testelor a fost să încerc să privesc Firewall-ul prin ochii unui utilizator, să-i notez punctele forte și punctele slabe din punctul meu de vedere.

Kerio Technologies WinRoute Pro v4.2.5

Instalare si dezinstalare:
Merge fara probleme.
Instalare cu setări implicite, fără reguli - doar NAT funcționează. Rețea - nicio problemă, rezultatele scanării - APS nu arată starea de alarmă, scanerul crede că toate porturile sunt închise. Winroute în sine nu generează alarme și nu identifică vizual faptul scanării.

Outpost Firewall Pro 2.1 Build 303.4009 (314)

Instalare si dezinstalare:
Instalarea sub XP rulează fără probleme, modul de învățare este activat la pornire.

ZoneLabs ZoneAlarm Pro cu filtrare web 4.5.594.000 - Personal Firewall

Instalare si dezinstalare:
În timpul instalării, XP a închis în timp ce încerca să pornească după instalare. După repornire, totul a funcționat bine.

AtGuard 3.22>

Instalare si dezinstalare:
Instalarea și dezinstalarea nu cauzează probleme speciale

Avantaje:

1. Firewall de dimensiuni mici, are o soluție interesantă din punct de vedere al interfeței - este realizat sub forma unui panou situat în partea de sus a ecranului

Dezavantaje și caracteristici:

1. Vulnerabil în modul antrenament - din momentul în care se afișează cererea de creare a unei reguli și până la crearea acesteia, trece pachete în ambele direcții
2. Interfața este puțin greșită la redesenarea ferestrelor

Evaluare generală:
Firewall simplu, dar funcțional

Kerio Personal Firewall 4

Instalare si dezinstalare:
Instalarea se desfășoară fără probleme, îndepărtarea este „curată” - nu au fost observate probleme după dezinstalare.

Norton securitatea internetului 2004 (NIS)

Instalare si dezinstalare: Instalarea nu pune probleme, dar dintre toate cele analizate, instalatorul este cel mai greoi.

Internet Connection Firewall, ICF - încorporat firewall windows XP

Instalare si dezinstalare: Nu necesită instalare, este mijloace regulate XP. Activarea se face în setări adaptor de retea... Implicit, ICF operează în modul de securitate maximă și (acesta este rezultatul observației mele) principiul funcționării sale este următorul - cererile de aplicații sunt eliberate în exterior și numai pachetele care au venit ca răspuns la solicitările mele sunt acceptate în exterior ( corespondenţa cerere-răspuns este menţinută clar sub forma unui tabel dinamic). Astfel, atunci când scanați porturi pe un computer cu ICF activat, nu există un singur port deschis (acesta este logic - pachetele de scanare de porturi nu vor fi trecute, deoarece nimeni nu le-a solicitat). Situația este similară cu diferite tipuri de „nuke” bazate pe trimiterea de pachete non-standard

Internet Connection Firewall, ICF - Firewall încorporat Windows XP SP2

Instalare si dezinstalare: Instalarea nu este necesară, este un instrument standard XP (inclus în SP2 pentru XP). Activarea se face în setările adaptorului de rețea. Trebuie remarcat faptul că la instalarea SP2 sau la instalarea XP cu SP2 integrat, pe lângă Firewall, apare în sistem un Centru de securitate, care poate afișa setările ICF

Sygate Personal Firewall Pro 5.5 build 2525

Instalare si dezinstalare:

ISS BlackIce 3.6.cci

Instalare si dezinstalare: Instalarea programului și dezinstalarea acestuia au loc fără probleme, dar în timpul instalării apare o eroare în biblioteca ikernel. Aceeași eroare a apărut în timpul dezinstalării. Apariția acestei erori nu afectează instalarea și eliminarea programului. Programul de instalare nu a necesitat o repornire a sistemului, ceea ce este neobișnuit pentru un Firewall

Visnetic Firewall 2.2

Instalare si dezinstalare: Instalarea programului și dezinstalarea acestuia se fac fără probleme. Este necesară o repornire după instalare.

Priviți și opriți firewall-ul personal 2.05

Instalare si dezinstalare: Instalarea programului și dezinstalarea acestuia se fac fără probleme. Este necesară o repornire după instalare. Instalează propriul driver pentru lucru.

Kaspersky AntiHacker 1.5

Instalare si dezinstalare: Instalarea programului și dezinstalarea acestuia se fac fără probleme. Este necesară o repornire după instalare.

Tiny Personal Firewall Pro 6.0

Instalare si dezinstalare:
Instalarea programului și dezinstalarea acestuia se fac fără probleme. Este necesară o repornire după instalare.

McAfee Personal Firewall Plus 6.0 Build 6014

Instalare si dezinstalare:
Instalarea programului și dezinstalarea acestuia se fac fără probleme. Este necesară o repornire după instalare.

R-Firewall 1.0 Build 43

Instalare si dezinstalare:
Instalarea programului și dezinstalarea acestuia se fac fără probleme. Dimensiunea kit-ului de distribuție este mică (3,8 MB), puteți personaliza compoziția produsului. Lucrarea este destul de stabilă, nu au fost observate defecțiuni evidente și înghețari pe PC-ul de referință

Concluzii generale și concluzie

Deci, să rezumam rezultatele testelor. De fapt, testele mi-au confirmat ideile teoretice despre starea problemei:

1. Firewall-ul trebuie configurat... Toate firewall-urile testate au funcționat bine, dar numai după configurare (antrenament, creare manuală a setărilor - nu contează). Exploatarea unui Firewall neconfigurat poate face mai mult rău decât bine (va sări peste pachete periculoase și invers, va interfera cu programele utile);
2. După Setări firewallși IDS trebuie testat- aceasta este, de asemenea, o concluzie destul de evidentă, dar totuși este importantă. Primul pas pe care l-am făcut pentru a crea un tester a fost utilitarul APS. Au mai rămas două - un simulator al unui program troian (adică un utilitar care va efectua încercări sigure pentru ca utilizatorul să „sparge” Firewall-ul din interior (desigur, atacurile vor fi descrise de baza de date și vor fi efectuate la comanda utilizatorului sub controlul acestuia), care va permite monitorizarea reacției Firewall și IDS) și un utilitar pentru scanarea expresă a porturilor și efectuarea de atacuri de bază (de fapt, APS este exact invers - pot avea o bază de port comună). Sunt deja angajat în dezvoltarea acestor utilități - prezența lor în arsenalul utilizatorului va permite un anumit „control instrumental”.
3. Personal Firewall este vulnerabil la malware care rămâne în afara contextului. Concluzie - cel puțin în jos cu diverse panouri „stânga” și alte BHO-uri din browser și e-mail !! Înainte de a instala orice plugin, panou, utilitar de extensie etc. trebuie să te gândești de zece ori la necesitatea lor, tk. nu sunt procese separate ale sistemului de operare și rulează din contextul programului părinte... Calul troian este detectat cu ușurință de firewall-ul personal - „vede” că un proces (de exemplu, bo2k.exe) încearcă să înceapă să asculte pe portul xxxxx sau să facă schimb cu o anumită gazdă - este emisă o cerere de admisibilitate, utilizatorul începe să Aflați ce fel de „bo2k.exe este.” și Backdoor este prins. Dar dacă calul troian a fugit din contextul browserului, atunci aproape sigur nimeni nu ar fi atent la accesul browserului la Internet. Astfel de troieni există, cel mai apropiat exemplu este TrojanDownloader.IstBar - este instalat exact ca o bară IE (natural, nu este în procese, este și în lista de rulare automată);
4. Multe firewall-uri personale sunt vizibile ca procese ale sistemului de operare și pot fi oprite de un virus. Concluzie - activitatea Firewall-ului trebuie monitorizată, iar încetarea lui bruscă poate servi drept semnal că un virus a pătruns în PC;
5. Unele firewall-uri (cum ar fi Kerio) permit controlul de la distanță- functie telecomandă trebuie să fie fie dezactivat, fie protejat cu parolă.

Setările paravanului de protecție Windows (firewall) sunt esențiale pentru asigurarea securității computerului dvs. și a datelor stocate pe acesta atunci când lucrați pe Internet și rețelele locale. Operațiunea de configurare a firewall-ului se realizează folosind metode standard Windows și nu necesită special cunostinte de calculator.

Instrucțiuni

Faceți clic pe butonul „Start” pentru a afișa meniul principal al sistemului și accesați elementul „Panou de control”.

Extindeți legătura Windows Firewall și aplicați caseta de selectare Activare (recomandat) din fila General pentru a porni firewall-ul.

Bifați caseta de validare Nu permiteți excepții pentru a suprima alertele de blocare și pentru a preveni crearea unei liste de excepții.

Accesați fila „Excepții” și aplicați casetele de selectare din câmpurile aplicațiilor pentru care doriți să permiteți conexiunile de intrare.

Faceți clic pe fila Avansat pentru a dezactiva firewall-ul pentru o anumită conexiune și setări parametri suplimentari filtrarea protocolului ICMP.

Faceți clic pe butonul „Implicit” pentru a restabili setările inițiale ale paravanului de protecție.

Utilizați crearea automată a excepțiilor aplicației atunci când lansați un program care așteaptă o conexiune la un anumit port pentru a accesa rețeaua.

Faceți clic pe butonul Blocare din fereastra Windows Security Alert pentru a bloca complet conectarea la rețea a aplicației selectate.

Faceți clic pe butonul Deblocare pentru a crea o regulă care permite aplicației selectate să se conecteze la rețea.

Faceți clic pe butonul „Amânare” pentru a respinge conexiunea în acest moment.

Reveniți la fila Excepții și faceți clic pe butonul Adăugare program pentru a crea o regulă care să permită aplicației selectate să acceseze rețeaua dacă știți dinainte că este necesar.

Faceți clic pe butonul Adăugare port pentru a crea o regulă pentru conectarea de la rețea la serviciul care rulează pe acest port.

Faceți clic pe butonul Change Scope pentru a seta intervalul de adrese de la care pot fi stabilite conexiuni la aplicația sau portul specificat.

Faceți clic pe fila Avansat și aplicați casetele de selectare din casetele Conexiune la rețea din Setări conexiune la rețea pentru a activa serviciul Firewall pentru fiecare.

Testare comparativă a 21 de firewall-uri populare pentru calitatea protecției împotriva atacurilor care provin din interiorul sistemului. În cadrul testului, protecția a fost verificată folosind 64 de utilități de testare special dezvoltate pentru acesta, care verifică protecția proceselor de la terminare, protecția împotriva atacurilor interne standard, protecția împotriva scurgerilor non-standard și protecția împotriva tehnicilor nestandard de pătrundere în nucleu. modul.

Alături de antivirus, firewall-ul este una dintre componentele principale ale securității computerului. Cu toate acestea, spre deosebire de antivirusuri, testele obiective ale firewall-urilor sunt rareori efectuate. Am încercat să reducem acest decalaj prin efectuarea unui test de firewall pentru protecție împotriva atacurilor interne și a unui test de IDS/IPS personal pentru protecție împotriva atacurilor asupra aplicațiilor vulnerabile în 2011 și 2012. Anul acesta, am decis să extindem lista de metode utilizate și să repetăm ​​testul firewall-urilor de protecție împotriva atacurilor interne pentru a vedea cum s-au schimbat rezultatele produselor populare în ultimul timp conform acestui criteriu.

La ce vizează acest test sau ce funcții îndeplinește firewall-ul? Conform standardului Internet [RFC3511] (2003), un firewall este un sistem care implementează funcțiile de filtrare a pachetelor de rețea în conformitate cu regulile specificate pentru a diferenția traficul între segmentele de rețea. Cu toate acestea, odată cu creșterea complexității programelor malware și atacurile hackerilor, sarcinile firewall originale au fost completate cu altele noi module functionale... Este practic imposibil să ne imaginăm un firewall cu drepturi depline fără modulul HIPS (monitorizarea evenimentelor sistemului, monitorizarea integrității sistemului etc.).

Sarcina principală a unui firewall modern este de a bloca comunicațiile neautorizate de rețea (denumite în continuare atacuri), subdivizate în interne și externe. Acestea includ:

Atacurile externe asupra unui sistem protejat cu firewall:

• inițiat de hackeri;
• inițiat de cod rău intenționat.

• inițiat de aplicații nede încredere (cod rău intenționat);
• inițiate de aplicații a căror activitate în rețea este interzisă în mod explicit de reguli.

În plus, produsele care ar putea fi clasificate drept firewall-uri personale pure în formula clasică din 2003 au dispărut practic de pe piață. Au fost înlocuite cu produse complexe pentru protejarea computerelor personale, care includ neapărat o componentă firewall.

Testul firewall pentru protecție împotriva atacurilor externe include studierea calității protecției împotriva atacurilor care provin din interiorul sistemului. Testul a fost efectuat în următoarele domenii:

1. Verificarea protecției proceselor de la terminare.
2. Protecție împotriva atacurilor interne standard.
3. Testarea protecției împotriva scurgerilor nestandard.
4. Testarea protecției împotriva tehnicilor de penetrare a modului nucleu non-standard.

Față de testul anterior, numărul de atacuri folosite s-a extins semnificativ - de la 40 la 64. S-a schimbat și sistemul de operare, care ar trebui protejat de produsele testate. La ultimul test a fost Windows XP, iar la acest test a fost Windows 7 x32. Un test similar este planificat și pentru sfârșitul anului pentru sistemul de operare Windows 7 x64.

Introducere

A participat la testarea 21 program popular protecţie cuprinzătoare(clasa Internet Security, dacă nu există un astfel de produs în linie, atunci a fost ales un firewall pur) din diferiți producători versiunile actuale ale produselor de la începutul testării (mai 2013) și care rulează mai departe Platforma Windows 7 X32 :

1. Avast! Internet Security (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 Securitate inteligenta (6.0.316.0).
8. F-Secure Internet Security (1.77 build 243).
9. G DATA Internet Security (1.0.13113.239).
10. Jetico Personal Firewall (2.0).
11. Kaspersky Internet Security (13.0.1.4190 (g).
12. McAfee Internet Security (11.6.507).
13. Kingsoft Internet Security (2009.05.07.70).
14. Microsoft Security Essentials (4.2.223.0) + Windows Firewall.
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).

Înainte de începerea testului, a fost pregătit mediul de testare. Pentru a face acest lucru, pe un computer curat a fost instalat sistemul de operare Windows 7 Enterprise SP1 x86 cu toate actualizările disponibile la acel moment, precum și software-ul suplimentar necesar pentru test.

Testarea a fost efectuată pe două tipuri de setări: standard recomandat de producător (setări implicite) și maxim. În primul caz, s-au folosit setările implicite recomandate de producători și au fost efectuate toate acțiunile recomandate de program.

În al doilea caz, în plus, toate setările care au fost dezactivate în modul „implicit”, dar în același timp ar putea afecta rezultatul testului, au fost activate și/sau aduse la poziția maximă (cele mai stricte setări). Cu alte cuvinte, setarea setărilor maxime înseamnă traducerea tuturor celor disponibile din interfata grafica utilizatorul configurează toate modulele legate de detectarea fișierelor rău intenționate sau a activității în rețea la cea mai strictă opțiune.

Testul firewall a fost efectuat pe următoarele grupuri de atacuri interne, pentru claritate, defalcate pe niveluri de dificultate:

1. Nivel de bază de dificultate (56 de opțiuni de atac):

1. verificarea protecției proceselor de la terminare (41 variante de atacuri);
2. protectie impotriva atacurilor interne standard (15 tipuri de atacuri).

2. Nivel crescut de dificultate (8 opțiuni pentru atacuri):

1. testarea protecției împotriva scurgerilor non-standard (3 tipuri de atacuri);
2. testarea protecției împotriva tehnicilor de penetrare non-standard în modul kernel (5 opțiuni de atac).

Puteți găsi o descriere detaliată a tuturor metodelor de atac utilizate în test în metodologia de testare.

Verificarea firewall-urilor pentru protecție împotriva atacurilor interne

Amintiți-vă că, conform schemei de recompensare utilizată, s-a acordat 1 punct (+) dacă atacul a fost blocat automat, funcționalitatea de protecție a programului testat nu a fost încălcată. 0,5 puncte (sau +/-) - dacă atacul este blocat numai în circumstanțe speciale (de exemplu, când alegerea corecta utilizator al acțiunii dorite la solicitarea programului testat). Și, în sfârșit, dacă atacul a avut succes în totalitate sau în parte cu dezactivarea funcționalității de protecție, atunci nu s-au acordat puncte. Numărul maxim posibil de puncte obținute la acest test a fost de 64.

Tabelul 1-2 și Figura 1-2 arată rezultatele testării firewall-urilor separat pentru standard și setări maxime... Pentru claritate, rezultatele pentru fiecare firewall sunt împărțite în două grupe: protecție împotriva atacurilor de nivelul de bază de complexitate și protecție împotriva atacurilor nivel crescut dificultăți.

Tabelul 1: Rezultatele testării firewall-urilor pe stdAsetarile gurii

Produs testat							Total puncte (max. 64)	Total %
	Puncte	%	% din suma	Puncte	%	% din suma
Comodo	53	95%	82,8%	6	75%	9,4%	59	92%
Armura online	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%
Avanpost	45	80%	70,3%	2,5	31%	3,9%	47,5	74%
Trend Micro	42	75%	65,6%	3	38%	4,7%	45	70%
Kaspersky	42	75%	65,6%	2,5	31%	3,9%	44,5	70%
Dr.Web	42,5	76%	66,4%	2	25%	3,1%	44,5	70%
TrustPort	43	77%	67,2%	0,5	6%	0,8%	43,5	68%
G DATE	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%
Instrumente 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%
urs panda	30	54%	46,9%	0	0%	0,0%	30	47%
Kingsoft	27	48%	42,2%	1	13%	1,6%	28	44%

Figura 1: Rezultatele testelor firewall-urilor pe setările standard

Protecția împotriva atacurilor interne la setările recomandate de producător lasă de dorit. Doar trei firewall-uri au reușit să depășească pragul de 80% din setările standard - acestea sunt Comodo, Online Armor și Norton. Jetico (79%) și Outpost (74%) sunt destul de aproape de ei. Rezultatele celorlalte firewall-uri s-au dovedit a fi semnificativ mai rele.

În comparație cu rezultatele ultimului test, toți liderii și-au confirmat rezultate ridicate, au existat doar mici mișcări în cadrul grupului de conducere, de exemplu Outpost și Jetico și-au schimbat pozițiile. Singura surpriză a fost produs Norton, care la ultimul test a arătat un rezultat de 45% și a fost în partea inferioară a tabelului, iar la acest test cu 80% a ocupat poziția a treia.

Rezultatele obtinute se datoreaza faptului ca multi producatori stabilesc setarile implicite in asa fel incat sa reduca numarul de mesaje la care utilizatorul trebuie sa raspunda. Acest lucru este confirmat de rezultatele testelor - la setările standard, firewall-urile au adresat întrebări utilizatorilor doar în 5,4% dintre atacuri, iar la maximum - în 9,2% dintre atacuri. Totuși, acest lucru afectează calitatea protecției, care va rămâne tăcută într-o situație în care un program rău intenționat va imita / efectua acțiuni complet legitime în sistem.

De asemenea, ar trebui să acordați atenție două modele. În primul rând, procentul de prevenire a tipurilor complexe de atacuri, în general, este semnificativ mai slab decât atacurile de nivel de bază de complexitate. Mai mult de jumătate dintre aceste atacuri au fost respinse de doar patru produse - Comodo, Online Armor, Norton și Jetico. Încă patru produse au intrat în grupul de frontieră, respingând de la 25% la 38% dintre astfel de atacuri - acestea sunt Outpost, Trend Micro, Kaspersky și Dr.Web. Toate celelalte produse au respins cel mult un atac complex. În al doilea rând, indicatorii de deviere a atacurilor de bază s-au îmbunătățit. Dacă în ultimul test 11 (50%) produse au respins mai puțin de 50% din atacuri, atunci în acest test există doar 3 astfel de produse (14%).

Tabelul 2: Rezultatele testelor firewall-urilor la setările maxime

Produs testat	Atacurile de bază (max. 56 de puncte)			Atacuri avansate (max. 8 puncte)			Total puncte (max. 64)	Total %
	Puncte	%	% din suma	Puncte	%	% din suma
Comodo	56	100%	87,5%	8	100%	12,5%	64	100%
Bitdefender	56	100%	87,5%	8	100%	12,5%	64	100%
Armura online	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%
Instrumente PC	49,5	88%	77,3%	5,5	69%	8,6%	55	86%
Avanpost	49	88%	76,6%	5,5	69%	8,6%	54,5	85%
Eset	49	88%	76,6%	5,5	69%	8,6%	54,5	85%
Dr.Web	46,5	83%	72,7%	5	63%	7,8%	51,5	80%
Jetico	46	82%	71,9%	4,5	56%	7,0%	50,5	79%
Trend Micro	43	77%	67,2%	3	38%	4,7%	46	72%
TrustPort	43	77%	67,2%	2,5	31%	3,9%	45,5	71%
G DATE	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%
urs panda	30	54%	46,9%	0	0%	0,0%	30	47%
Kingsoft	27	48%	42,2%	1	13%	1,6%	28	44%

Figura 2: Rezultatele testului firewall la setările maxime

Când au fost activate setările maxime, calitatea protecției împotriva atacurilor interne pentru multe dintre firewall-urile testate s-a îmbunătățit semnificativ. Acest lucru este vizibil mai ales la țăranii mijlocii puternici. Toti liderii ultimului test din acest test au dat si ei rezultate ridicate. Dintre modificări, este de remarcat produsul Bitdefender, care, împreună cu Comodo, a dat rezultate 100% și produsul Norton, care a trecut în grupul lider.

Rezultatele pentru un număr de produse la setări standard și maxime au fost aceleași. Acest lucru se datorează faptului că aceste produse nu au setări care pot afecta rezultatele testului nostru.

Comparația calității protecției la setări standard și maxime

În conformitate cu logica acestui test, nu vom aduna sau media rezultatele aceluiași produs cu setări diferite... Dimpotrivă, dorim să le comparăm și să arătăm diferențe semnificative în calitatea protecției produselor testate, în funcție de setările folosite.

Pentru claritate, prezentăm rezultatele finale ale testului firewall cu setările standard și maxime în Tabelul 3 și Figura 3.

Tabelul 3: Rezumatul rezultatelor testelor paravanului de protecție la setările standard și maxime

Produs	Setări standard	Setări maxime
Comodo	92%	100%
Armura online	90%	95%
Norton	80%	91%
Jetico	79%	79%
Avanpost	74%	85%
Trend Micro	70%	72%
Kaspersky	70%	94%
Dr.Web	70%	80%
TrustPort	68%	71%
G DATE	67%	70%
Avast	66%	66%
Eset	66%	85%
Bitdefender	66%	100%
AVG	64%	64%
McAfee	64%	64%
Instrumente PC	64%	86%
Avira	63%	68%
Microsoft	63%	63%
F-Secure	51%	51%
urs panda	47%	47%
Kingsoft	44%	44%

Figura 3: Rezumatul rezultatelor testelor paravanului de protecție la setările standard și maxime

Figura 3 demonstrează foarte clar diferența dintre rezultatele testelor în funcție de setările selectate.

În primul rând, doar două produse - Comodo și Online Armor arată aproape performanță maximă protectie, atat la setari standard cat si la setari maxime.

În al doilea rând, la modificarea setărilor standard propuse de producător, unele dintre produse arată semnificativ cel mai bun nivel protecţie. Acest lucru se vede cel mai clar în produse precum Bitdefender, Kaspersky, Eset, F-Secure și PC Tools.

În al treilea rând, după cum sa menționat mai sus, unele dintre produsele testate nu au deloc setări care ar putea afecta în vreun fel rezultatele testului. Prin urmare, rezultatele lor pentru toate tipurile de setări din acest test sunt aceleași. Acest grup include Jetico, Avast, AVG, McAffe, F-Secure, Panda, Kingsoft și Microsoft.

Evaluarea finală nu ține cont de situațiile în care atacul a fost respins, dar au existat probleme cu interfața cu utilizatorul a produselor. În cele mai multe cazuri, problemele au constat în „crash” a interfeței pentru o perioadă scurtă de timp (de la 2 la 10 secunde) sau până la următoarea pornire a sistemului de operare. În timp ce produsele continuă să ofere securitate atunci când există probleme de interfață cu utilizatorul, prezența unor astfel de probleme este negativă din punct de vedere subiectiv și poate afecta alegerea produselor. Numărul de probleme cu interfața cu utilizatorul este prezentat în Tabelul 3 și în Figura 3. Au fost evaluate erorile care decurg din atacurile de nivelul 1, numărul total al cărora este de 41.

Tabelul 4: Numărul de probleme de UI la setările standard și maxime

Produs testat	Setări standard		Setări maxime
	Numărul de greșeli	%	Numărul de greșeli	%
McAfee	34	83%	34	83%
Microsoft	33	80%	33	80%
Kingsoft	20	49%	20	49%
F-Secure	19	46%	19	46%
urs panda	17	41%	17	41%
Jetico	16	39%	16	39%
Instrumente PC	13	32%	13	32%
Trend Micro	12	29%	12	29%
AVG	10	24%	9	22%
TrustPort	9	22%	9	22%
G DATE	9	22%	9	22%
Bitdefender	8	20%	8	20%
Norton	6	15%	6	15%
Avast	5	12%	5	12%
Avanpost	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%
Armura online	1	2%	1	2%

Figura 4: Numărul de probleme de UI la setările standard și maxime

Rezultatele arată că produsele McAfee și Microsoft au avut probleme cu interfața cu utilizatorul în majoritatea atacurilor (peste 80%). Acesta poate fi numit un nivel inacceptabil, deoarece aproape orice atac respins cu succes va duce la probleme. Kingsoft, F-Secure, Panda, Jetico și PC Tools arată rezultate destul de slabe, variind de la 30% la 50%. Când le folosiți, fiecare 2-3 atacuri va duce la probleme de interfață. O serie de alte produse prezintă rezultate de la 10% la 30%, ceea ce poate fi numit satisfăcător. Rezultate frumoase au prezentat produse Avira, Dr.Web, Kaspersky și Online Armor, care au avut probleme în intervalul de la 2% la 5% din atacuri. Singurul produs care nu a avut niciodată probleme cu interfața cu utilizatorul a fost Comodo la setări maxime, ceea ce poate fi considerat un rezultat excelent. Cu toate acestea, performanța Comodo se deteriorează la setările standard (12%), ceea ce înseamnă că utilizarea acestui produs necesită anumite cunoștințe despre modul de configurare.

Rezultatele testelor finale și premiile

La fel ca în testul anterior, nu am făcut media rezultatelor aceluiași produs cu setări diferite, ci le-am considerat independent unul de celălalt. Astfel, fiecare dintre produsele testate poate primi două premii, câte unul pentru fiecare tip de cadru.

În conformitate cu schema de recompense, cele mai bune firewall-uri primesc premii cu o indicație a setărilor utilizate, vezi tabelul 4.

Tabelul 5: Rezultatele finale ale testului paravanului de protecție la setările standard și maxime

Produs testat	Opțiune setări	Prevenirea atacurilor [%]		Total [%]	Recompensă
		Baza nivelul de dificultate	Nivel de dificultate crescut
Comodo	Max	100%	100%	100%	Firewall Platinum Outbound Premiul de protecție
Bitdefender	Max	100%	100%	100%
Armura online	Max	95%	100%	95%	Firewall de aur ieșire Premiul de protecție
Kaspersky	Max	95%	88%	94%
Comodo	Standard	95%	75%	92%
Norton	Max	90%	100%	91%
Armura online	Standard	89%	94%	90%
Instrumente PC	Max	88%	69%	86%
Avanpost	Max	88%	69%	85%
Eset	Max	88%	69%	85%
Norton	Standard	80%	75%	80%
Dr.Web	Max	83%	63%	80%
Jetico	Max	82%	56%	79%	Silver Firewall Outbound Premiul de protecție
Jetico	Standard	82%	56%	79%
Avanpost	Standard	80%	31%	74%
Trend Micro	Max	77%	38%	72%
TrustPort	Max	77%	31%	71%
Trend Micro	Standard	75%	38%	70%
Kaspersky	Standard	75%	31%	70%
Dr.Web	Standard	76%	25%	70%
G DATE	Max	75%	38%	70%
TrustPort	Standard	77%	6%	68%	Firewall Bronze Outbound Premiul de protecție
Avira	Max	74%	25%	68%
G DATE	Standard	75%	13%	67%
Avast	Max	73%	19%	66%
Avast	Standard	73%	13%	66%
Eset	Standard	73%	13%	66%
Bitdefender	Standard	73%	13%	66%
AVG	Max	73%	0%	64%
AVG	Standard	73%	0%	64%
McAfee	Max	73%	0%	64%
McAfee	Standard	73%	0%	64%
Instrumente PC	Standard	73%	0%	64%
Microsoft	Max	71%	0%	63%
Microsoft	Standard	71%	0%	63%
Avira	Standard	71%	0%	63%
F-Secure	Max	56%	13%	51%	Fără recompensă
F-Secure	Standard	56%	13%	51%
urs panda	Max	54%	0%	47%
urs panda	Standard	54%	0%	47%
Kingsoft	Max	48%	13%	44%
Kingsoft	Standard	48%	13%	44%

Cele mai bune rezultate la test au fost arătate de firewall-urile Comodo și Bitdefender, care au obținut 100% puncte la setările maxime. Aceste două produse primesc un premiu PlatinăFirewallOutboundProtecţieAdjudecare.

Online Armor, Kaspersky, Comodo, Norton, PC Tools, Outpost, Eset și firewall-urile Dr.Web, care primesc premii, au arătat și ele rezultate foarte mari la test (peste 80%). AurFirewallOutboundProtecţieAdjudecare... Este important de menționat că Comodo a primit acest premiu la setările standard, Online Armor și Norton la setările standard și maxime și toate celelalte - doar la setările maxime.

Următorul pe listă este un grup de șapte firewall-uri, ale căror rezultate se încadrează în intervalul de la 60% la 70%. Acestea sunt Outpost, Kaspersky și Dr.Web cu setări standard; TrustPort și G DATA la setări maxime, precum și Jetico și Trend Micro în același timp la setări standard și maxime. Toți primesc o recompensă

Un grup destul de mare de produse care se încadrează în intervalul 60% până la 70% va primi premiul. De menționat că produsele Eset și Bitdefender au setări standard, care la setări maxime au putut respinge un număr semnificativ mai mare de atacuri.

Puteți face cunoștință cu rezultatele detaliate ale testului și vă puteți asigura că calculele finale sunt corecte prin descărcarea rezultatelor testului în format Microsoft Excel.

Ilya Shabanov, partener director al site-ului:

„Am fost foarte mulțumit de faptul că mulți producători au îmbunătățit semnificativ protecția proactivă împotriva atacurilor interne și autoapărarea în produsele lor. A trebuit chiar să revizuim schema de premii pentru a ridica ștacheta. Un scor mai mic de 51% era acum privit ca un eșec complet.

Am fost plăcut surprinși de Bitdefender, care a respins toate atacurile 100% în modul paranoic, Eset și Dr.Web cu rezultate la setări maxime de 85% până la 80%, respectiv, precum și un nou venit la testele noastre, TrustPort. Firewall-urile de la Comodo, Norton și Online Armor au intrat în „grupul de aur” de produse conform rezultatelor acestui test, obținând mai mult de 80% la setările standard și maxime. Kaspersky, Outpost, PC Tools au dat rezultate constant ridicate la testele care implică protecție proactivă.

Cu toate acestea, în cazul unui număr de produse testate, logica prin care sunt stabilite setările standard nu este clară. Drept urmare, nivelul de protecție pentru majoritatea utilizatorilor care sunt obișnuiți să folosească protecția cu setări standard se dovedește a fi semnificativ subestimat. Acest lucru se aplică în primul rând produselor Bitdefender, Kaspersky, Eset și PC Tools.”

Kartavenko Mikhail, șeful laboratorului de testare:

„Considerând acest test ca o continuare a testului similar anterior, putem identifica câteva tendințe și probleme principale în activitatea firewall-urilor.

În primul rând, în medie, majoritatea produselor au avut performanțe mai bune decât acum 1,5 ani, dar au făcut acest lucru în principal respingând cele mai simple atacuri de Nivel 1. Atacuri mai complexe „în dinți” doar pentru o gamă limitată de produse.

În al doilea rând, chiar dacă este declanșată protecția la terminarea procesului (1 nivel de atacuri), interfața de utilizator a multor produse se blochează. Acest lucru îl pune pe utilizator într-o poziție incomodă în care nu înțelege dacă protecția funcționează sau nu.

În al treilea rând, există un decalaj destul de mare în activitatea firewall-urilor la setările standard și maxime. Ca urmare, un nivel acceptabil de protecție poate fi adesea obținut numai de utilizatori experimentați care cunosc și sunt capabili să configureze corect funcționarea firewall-urilor.

Astfel, testul a scos la iveală punctele „dureroase” ale firewall-urilor moderne, a căror soluție le poate îmbunătăți protecția.”

Secțiunea este actualizată zilnic. Întotdeauna cele mai recente versiuni ale celor mai bune programe gratuite pentru utilizarea de zi cu zi în secțiunea Programe necesare. Există practic tot ceea ce este necesar Munca zilnica... Începeți să eliminați treptat versiuni piratateîn favoarea unor omologi liberi mai comozi și funcționali. Dacă tot nu utilizați chat-ul nostru, vă recomandăm să vă familiarizați cu acesta. Îți vei găsi mulți prieteni noi acolo. Mai mult, este cel mai rapid și cale eficientă contactați administratorii de proiect. Secțiunea de actualizări antivirus continuă să funcționeze - actualizări gratuite mereu actualizate pentru Dr Web și NOD. Nu ai avut timp să citești ceva? Conținutul complet al liniei târâtoare poate fi găsit la acest link.

Gratuit firewall Comodo... Testare, concluzii

Comodo Firewall în acțiune

După instalarea și configurarea Comodo, s-a ascuns în tavă și a început să mă enerveze cu întrebările sale. În prima zi, m-am jucat cu toate firewall-urile și modurile de apărare proactivă și, în cele din urmă, l-am redus la tăcere. Nu au fost găsite frâne în sistemul lor după apariția acestuia. În general, lucrul cu firewall-ul Comodo a fost destul de ușor și convenabil. Interfața ferestrei principale este foarte simplă și informativă:

Dar a trebuit să mă obișnuiesc cu navigarea prin firewall și setările de protecție proactivă - nu este întotdeauna posibil să găsesc rapid elementul dorit. Cred că va trece în timp.

La câteva zile după instalarea Comodo Firewall, am decis să-l testez puțin.

Testul numărul 1. Testare online

Când faceți clic pe butonul „Test”, programul încearcă să stabilească o conexiune cu serverul site-ului.

Deoarece Comodo Firewall nu cunoaște încă acest utilitar, atunci când a încercat prima dată să pătrundă pe Internet, a existat o reacție imediată din partea protecției proactive și a firewall-ului:

În ambele cazuri, am făcut clic pe bloc și am primit o confirmare că testul a avut succes:

Apoi am redenumit fișierul FireWallTest.exe v opera.exeși le-am înlocuit cu fișierul Opera standard. Astfel, am încercat să păcălesc Comodo Firewall, care deja cunoaște bine acest browser și îl lansează constant și automat pe Internet. Comodo a reacționat la lansarea Operei „false” de la Total astfel:

După ce am primit permisiunea pentru o lansare unică, firewall-ul m-a avertizat despre o încercare de a accesa Opera pe Internet:

Se pare că orice aplicație pentru care există deja reguli nu va putea accesa Internetul dacă fișierul executabil este înlocuit fără știrea mea. Totul pare să fie în regulă, dar iată chestia: culoarea părții superioare a ferestrei de avertizare depinde de gravitatea situației. Dacă Comodo evaluează un eveniment ca fiind critic, atunci culoarea va fi roșie, dacă evenimentul este mai puțin periculos, va fi galben. În cazul meu, Comodo a considerat că situația simulată nu este deosebit de periculoasă și a aprins-o pe cea galbenă. Mai mult, în loc de formularea „fișier executabil opera.exe nerecunoscut „Aș prefera să văd că” a avut loc o modificare a parametrilor fișierului opera.exe”. Așa că avertizați în situatii similare combine de la Kaspersky și Eset, de exemplu. Mai mult, utilizatorul vede o fereastră de alarmă folosind roșu, ceea ce îl face imediat să fie atent la situație. Un avertisment de la Comodo poate fi pur și simplu ignorat de utilizator din cauza unui accent insuficient pe evenimentul care are loc.

Înlocuirea fișierului Opera a fost doar o parte a planului meu viclean. Următoarea victimă a fost Internet Explorer 6, care este integrat în sistemul de operare, ceea ce înseamnă iexplore.exe poate fi considerat un fișier de sistem cu drepturi depline. Imaginează-ți surpriza mea când, sub liniștea deplină a lui Comodo, am văzut o fereastră despre eșecul testului:

Aparent, a fost creată o regulă suplimentară, am decis și am intrat în firewall și politicile de protecție proactivă. După ce am săpat acolo aproximativ 15 minute, am luat singura decizie corectă - să reinstalez Comodo. Făcut repede și foarte bine. Lăsând modurile implicite de operare, am repetat experimentul cu înlocuirea iexplore.exe... La lansarea din Total, protecția proactivă a funcționat, ca și în cazul Opera:

Aici va trebui să facem o mică digresiune lirică. Faptul este că atunci când fișierul executabil IE este înlocuit, sistemul îl restabilește pe cel original în 4-8 secunde. iexplore.exe... În acest sens, rezultatele testului meu au depins de dacă fișierul înlocuit a avut timp să bată pe internet sau nu.

În cazul în care reușesc să finalizez toate manipulările înainte de a recupera explore.exe, se întâmplă următoarele. Am primit permisiunea mea pentru o lansare unică explore.exe, Total lansează utilitarul FireWallTest, apăs pe „Test”, apărarea proactivă Defens + emite un avertisment:

Dacă o permitem (ca experiment), firewall-ul funcționează:

Reușim să apăsăm „Blocați” - testul este trecut, utilitarul nu a alunecat pe internet. Dar dacă iexplore.exe restaurat înainte ca butonul de blocare să fie apăsat - nimic nu depinde de alegerea dvs. - utilitarul obține automat acces la Internet atunci când fișierul original este restaurat.

Același lucru este valabil și pentru munca de protecție proactivă: dacă nu ați avut timp să comandați să blocați înainte de restaurare explore.exe- utilitarul primește automat acces la Internet.

După ce m-am jucat suficient cu IE fals, mi-am amintit de primul eșec al testului, când Comodo a rămas tăcut și a lansat fișierul „stânga” pe Internet. După ce am reinstalat Comodo, am pus Defense + și firewall în modul antrenament și am lansat IE. După aceea, am revenit la modurile implicite și am repetat testul. Comodo a eșuat din nou în tăcere...

Testul numărul 3. Duel

Impresionat de rezultatele testului anterior, am căutat caracteristici suplimentare testați Comodo și, în sfârșit, am găsit utilitarul AWFT.

Acest program emulează comportamentul troienilor și conține o serie de șase teste care demonstrează diferite metode de acces neautorizat în rețea, ocolind protecția firewall. Aceste teste includ atât modalități vechi de a înșela firewall-urile, cât și tehnici mai moderne. Pentru fiecare test trecut cu succes, firewall-ului i se acordă un anumit număr de puncte. Dacă testul eșuează, punctele sunt acordate în favoarea AWFT. Numărul maxim de puncte este de zece.

Utilitarul este shareware, limitat la 10 lansări. În partea superioară a ferestrei programului există butoane care lansează testele corespunzătoare, mai jos este site-ul de unde va sparge AWFT și rezultatul duelului dintre firewall și utilitar. Butonul Resetare puncte este folosit pentru a reseta punctele acumulate.

Pentru orice eventualitate, am decis să schimb adresa site-ului cu adresa mea proprie.

Testarea a avut loc cu Comodo Firewall și Defense + activate, Opera rulând și monitorul Avira oprit.

În primul test, a fost folosită o tehnică cu încărcarea unei copii ascunse a browserului și corecția memoriei înainte de lansarea acesteia.

Când am făcut clic pe butonul de testare, a apărut o fereastră cu o eroare:

După ce a închis această fereastră, Comodo a reacționat la test cu o fereastră de solicitare, când a fost apăsat butonul „Block”, AWFT, după puțină gândire, a dat primul punct firewall-ului.

Potrivit dezvoltatorilor utilitarului, testul # 2 este un truc vechi și binecunoscut. Comodo răspunde din nou cu o casetă de solicitare și primește din nou un punct.

Testul # 3 folosește și un truc vechi. Comodo îl blochează în tăcere, aparent un truc cu adevărat faimos.

Testul # 4 este similar cu primul test cu lansarea unei copii ascunse a browserului și corecția memoriei înainte de lansare. Firewall-ul nu a emis niciun avertisment, dar după o scurtă pauză a mai câștigat un punct.

În timpul testelor a cincea și a șasea, trebuie să treceți la browser și să navigați puțin (tocmai am reîmprospătat pagina încărcată în browser).

În testul #5, utilitarul efectuează o căutare euristică a software-ului autorizat instalat pe computer (sau în rețea) care are acces la Internet prin portul 80, apoi lansează o copie a programului permis și corecizează memoria ocupată de acest program (adică, AWFT se lansează în memoria programului permis). Comodo a trecut în tăcere testul și a primit 3 puncte grozave pentru el.

Testul # 6 este similar cu cel de-al cincilea test anterior. Aceeași tehnică este folosită cu o căutare euristică a software-ului instalat care are dreptul de a ieși în exterior prin portul 80. Doar metoda de hacking a fost schimbată acum - este folosită o solicitare a utilizatorului. Pe parcurs, AWFT încearcă să lipească bara de instrumente ascunsă din stânga în browser. Când Opera a fost deschisă, mi-a apărut următoarea fereastră:

În momentul în care am confirmat această solicitare de utilizator, Comodo și-a emis cererea, utilitarul a fost blocat din nou, iar firewall-ul a primit 3 puncte pentru el însuși.

Rezultatul duelului este 10: 0 în favoarea lui Comodo. După ce am repetat testele cu Internet Explorer deschis, am obținut aceleași rezultate.

Concluzie

În ciuda unui gust neplăcut în dușul rămas după testarea firewall-ului, recomand în continuare Comodo Internet Security pentru uz casnic, dar doar ca firewall. Și nu ascultați de acei tipi deștepți care vă sfătuiesc să dezactivați protecția proactivă, în orice caz! Numai prin utilizarea Defense + acest firewall vă va păstra computerul în siguranță. Ceea ce nu ar trebui să utilizați este antivirusul Comodo. Nu numai că omite decent, dar vei avea probleme la actualizarea lui - are baze de date foarte greoaie. În plus, are un efect decent asupra performanței sistemului. Tocmai am lucrat grozav într-o pereche de Comodo Firewall și Avira Antivir Personal.

Nu am găsit frâne sau erori în sistem în timp ce firewall-ul rula. Îmi voi lăsa părerile mele despre rezultatele testării mele pentru moment, aș dori să ascult comentariile voastre.

În timp ce scriam partea finală a acestui articol, am dat peste rezultatele unui test recent al firewall-urilor de către laboratorul Matousec. Comodo Internet Security s-a dovedit a fi singurul firewall cu o rată de succes de 100% (vezi forumul firewall). Ei bine, eu am făcut alegerea mea... Și tu?

plusuri (explicite):
distributie gratuita,
disponibilitatea propriei baze de date de programe;
prezența protecției proactive (Apărare +);
ușurință de instalare și configurare inițială;
fereastră de rezumat foarte informativă și convenabilă;

plusuri (dubios):
prezența mai multor moduri de funcționare;

contra (explicit):
mod de instalare enervant;
înlocuirea unui fișier executabil nu este definită de protecția proactivă ca un eveniment critic;

contra (îndoielnic):
antivirus sincer nereușit.

Acest al doilea articol descrie cum să depanați o problemă de filtru de pachete. În loc de turnare masa terminata sub formă de „problemă” – „rezolvare” sunt date metode de abordare sistematică pentru rezolvarea problemelor apărute.

Acest al doilea articol (într-o serie de trei) descrie cum să depanați problemele de filtru de pachete. În loc să prezinte un tabel gata făcut sub formă de „problemă” - „soluție”, sunt oferite metode de abordare sistematică pentru rezolvarea problemelor apărute.

Introducere

Un filtru de pachete execută o politică de filtrare ocolind un set de reguli și, în consecință, blochează sau permite pachete. Capitolul explică cum să verificați dacă politica de filtrare este executată corect și cum să găsiți erori dacă nu este.

În general, pe parcursul acestui capitol, vom compara sarcina de a scrie un set de reguli de filtrare cu programarea. Dacă nu ai abilități de programare, atunci această comparație ți se va părea mai dificilă. Dar scrierea regulilor nu necesită o diplomă de informatică sau o experiență de programare în sine, nu-i așa?

Răspunsul este nu, probabil că nu aveți nevoie de asta. Limbajul folosit pentru configurarea filtrului de pachete este similar cu limbajele umane. De exemplu:

blocheaza tot

leși toate păstrează starea

treceți în proto tcp la orice port www keep state

De fapt, nu este nevoie să aveți un programator în apropiere pentru a înțelege ce face acest set sau chiar, folosind intuiția, pentru a scrie o astfel de politică de filtrare. Există chiar o șansă mare ca un set de reguli de filtrare create în această asemănare să efectueze acțiunile pe care le-a avut în minte autorul său.

Din păcate, computerele fac doar ceea ce le ceri tu, nu ceea ce vrei tu să facă. Chiar mai rau, nu vor putea distinge ceea ce se dorește de ceea ce este real, dacă există o astfel de diferență. Aceasta înseamnă că, dacă computerul nu face corect ceea ce doriți, chiar dacă credeți că ați descris instrucțiunile în mod clar, este în mâinile dumneavoastră să găsiți diferențele și să schimbați instrucțiunile. Și deoarece aceasta este o problemă comună în programare, putem vedea cum se confruntă programatorii cu ea. Se pare că abilitățile și metodele folosite pentru a testa și depana programe și regulile de filtrare sunt foarte asemănătoare. Totuși, aici nu aveți nevoie de cunoștințe despre niciun limbaj de programare pentru a înțelege implicațiile pentru testare și depanare.

Politică bună de filtrare.

O politică de filtrare este o specificație informală a ceea ce vrem să facă firewall-ul. Pe de altă parte, un set de reguli, implementarea unei specificații, este un set de instrucțiuni standard, un program executat de o mașină. În consecință, pentru a scrie un program, trebuie să definiți ce ar trebui să facă.

Astfel, primul pas în configurarea unui firewall este definirea informală a ceea ce trebuie realizat. Ce conexiuni ar trebui să fie blocate sau permise?

Un exemplu ar fi:

Există trei rețele care trebuie separate una de cealaltă printr-un firewall. Orice conexiuni de la o rețea la alta trec prin firewall. Firewall-ul are 3 interfețe, fiecare dintre ele conectată la rețeaua corespunzătoare:

$ ext_if - către rețeaua externă.

$ dmz_if - DMZ cu servere.

$ lan_if - LAN cu stații de lucru.

Gazdele de pe LAN trebuie să se conecteze liber la orice gazde din DMZ sau din rețeaua externă.

Serverele din DMZ ar trebui să poată comunica liber cu gazdele din rețeaua externă. Gazdele externe se pot conecta numai la următoarele servere din DMZ:

Server web 10.1.1.1 portul 80

Server de e-mail 10.2.2.2 portul 25

Toate celelalte conexiuni ar trebui refuzate (de exemplu, de la mașini din rețeaua externă la mașini din LAN).

Această politică este exprimată informal, astfel încât oricine o citește să o poată înțelege. Ar trebui să fie atât de specific încât cititorul să poată formula cu ușurință răspunsuri la întrebarea formularului „Ar trebui să fie transmisă conexiunea de la gazda X la gazda Y, de intrare (sau de ieșire) pe interfața Z?”. Dacă vă gândiți la cazurile în care polița dumneavoastră nu îndeplinește această cerință, atunci nu este suficient de clar.

Politicile „foggy” precum „permiteți doar ceea ce este vital” sau „blocați atacurile” trebuie clarificate, altfel nu le veți putea aplica sau testa. Ca și în dezvoltarea de software, sarcinile insuficient formalizate duc rareori la implementări justificate sau corecte. („De ce nu te duci și începi să scrii codul, în timp ce îmi voi da seama de ce are nevoie clientul”).

Un set de reguli care pun în aplicare politica

Setul de reguli este scris ca un fișier text care conține propoziții într-un limbaj formal. Precum și sursă este procesată și tradusă în instrucțiuni de cod de mașină de către compilator, „sursa” setului de reguli este procesată de pfctl, iar rezultatul este interpretat de pf în nucleu.

Când codul sursă încalcă regulile limbajului formal, analizatorul raportează o eroare de sintaxă și refuză să proceseze în continuare fișierul. Această eroare este o eroare de compilare și este de obicei remediată rapid. Când pfctl nu poate analiza fișierul setul de reguli, afișează o linie cu o eroare și un mesaj mai mult sau mai puțin informativ pe care nu l-a putut analiza. Până când întregul fișier este procesat fără singura greseala, pfctl nu va schimba setul de reguli anterior din nucleu. Și, deoarece fișierul conține una sau mai multe erori de sintaxă, nu există niciun „program” pe care pf îl poate rula.

Al doilea tip de eroare se numește „erori de rulare” deoarece apare atunci când un program corect din punct de vedere sintactic este scris și tradus și executat cu succes. V caz general, în limbajele de programare, acest lucru se poate întâmpla atunci când un program efectuează o împărțire la zero, încearcă să acceseze zone nevalide de memorie sau rămâne fără memorie. Dar, deoarece seturile de reguli seamănă doar vag cu funcționalitatea limbajelor de programare, majoritatea acestor erori nu pot apărea în timpul aplicării regulilor, de exemplu, regulile nu pot provoca așa-numitele. „Cercare de sistem”, așa cum fac programele obișnuite. Cu toate acestea, un set de reguli poate cauza erori similare, sub formă de blocare, sau invers, transmiterea de pachete care nu respectă politica. Aceasta se numește uneori o eroare booleană, o eroare care nu provoacă o excepție sau o întrerupere, ci pur și simplu produce rezultate incorecte.

Deci, înainte de a începe să verificăm cât de corect implementează firewall-ul politica noastră de securitate, trebuie să încărcăm cu succes setul de reguli.

Erori ale analizorului

Erorile parserului apar atunci când încercați să încărcați o listă de reguli folosind pfctl, de exemplu:

# pfctl -f/etc /pf.conf

/ etc /pf.conf: 3:sintaxăeroare

Acest mesaj indică faptul că există o eroare de sintaxă pe linia 3 din /etc/pf.conf și pfctl nu poate încărca regulile. Setul din nucleu nu s-a schimbat, rămâne același ca înainte de încercarea de a încărca unul nou.

Există multe varietăți de erori pfctl. Pentru a începe cu pfctl, trebuie doar să le citiți cu atenție. Poate că nu toate părțile mesajului îți vor dezvălui imediat sensul lor, dar trebuie să le citești pe toate, pentru că mai târziu, va fi mai ușor de înțeles ce a mers prost. Dacă mesajul conține o parte din formularul „nume fișier: număr: text”, se referă la linia cu numărul corespunzător din fișierul specificat.

Următorul pas este să priviți linia afișată folosind un editor de text (în vi puteți merge la linia 3 introducând 3G în modul bip), sau astfel:

# cat -n /etc/pf.conf

1 int_if = "fxp 0"

2 blochează toate

3 trece pe $ int_if inet toate păstrează starea

distribuie inet pe $ int_if toate păstrează starea

Problema ar putea fi o simplă greșeală de tipar, ca în acest caz („păstrați” în loc de „păstrați”). După reparare, încercați să reîncărcați fișierul:

# pfctl -f/etc /pf.conf

/ etc /pf.conf: 3:sintaxăeroare

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

da inet pe $ int_if all keep state

Acum toate cuvintele cheie sunt corecte, dar la o inspecție mai atentă, observăm că poziționarea cuvântului cheie „inet” înainte de „on $ int_if” este incorectă. Acest lucru ilustrează faptul că o singură linie poate conține mai multe erori. Pfctl tipărește prima eroare pe care o găsește și oprește executarea. Dacă același număr de linie a fost emis în timpul repornirii, înseamnă că există mai multe erori în el sau cele anterioare nu au fost corect eliminate.

Cuvintele cheie greșite sunt, de asemenea, o greșeală comună. Acest lucru poate fi văzut comparând regula cu sintaxa de referință BNF de la sfârșitul paginii de manual pf.conf (5), care conține:

pf-rule = acțiune [("înăuntru" | "ieșit")]

[„jurnal” | „log-all”] [„rapid”]

[„on” ifspec] [rută] [af] [protospec]

gazde [filterop-list]

ifspec = (["!"] nume-interfață) | „(” lista de interfețe „)”

af = "inet "|"inet6 "

Ceea ce înseamnă că cuvânt cheie Inet trebuie să urmeze pe $ int_if

Să o reparăm și să încercăm din nou:

# pfctl -f/etc /pf.conf

/ etc /pf.conf: 3:sintaxăeroare

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

trece pe $ int_if inet toate păstrează starea

Acum nu există greșeli evidente. Dar nu vedem toate detaliile însoțitoare! Linia depinde de definiția macro $ inf_if. Ce poate fi identificat greșit?

# pfctl -vf /etc/pf.conf

int_if = "fxp 0"

block drop all

/etc/pf.conf:3: eroare de sintaxă

După ce ați corectat greșeala de tipar „fxp 0” la „fxp0”, încercați din nou:

# pfctl -f/etc /pf.conf

Absența mesajelor indică faptul că fișierul a fost descărcat cu succes.

În unele cazuri, pfctl poate emite mesaje de eroare mai specifice decât doar „eroare de sintaxă”:

# pfctl -f /etc/pf.conf

/etc/pf.conf:3: portul se aplică numai pentru tcp / udp

/etc/pf.conf:3: sari peste regula din cauza erorilor

/etc/pf.conf:3: regula se extinde la nicio combinație validă

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

trece pe $ int_if la portul ssh păstrează starea

Prima linie a mesajului de eroare este cea mai informativă în comparație cu restul. În acest caz, problema este că regula care specifică portul nu definește protocolul - tcp sau udp.

În cazuri rare, pfctl este descurajat de prezența caracterelor neimprimabile sau a spațiilor inutile în fișier, astfel de erori nu sunt ușor de detectat fără o procesare specială a fișierului:

# pfctl -f /etc/pf.conf

/etc/pf.conf:2: spațiu după \

/etc/pf.conf:2: eroare de sintaxă

# cat -ent /etc/pf.conf

1 bloc toți $

2 trece pe gem0 de la orice la orice \ $

3 ^ Eu pastrezstare $

Problema aici este caracterul spațiu, după „backslash” dar înainte de sfârșitul celei de-a doua rânduri, indicat de semnul „$” în ieșirea cat -e.

După ce setul de reguli a fost încărcat cu succes, este o idee bună să priviți rezultatul:

$ cat /etc/pf.conf

blocheaza tot

# trece de la oricare la oricare \

trece de la 10.1.2.3 la oricare

$ pfctl -f /etc/pf.conf

$ pfctl -sr

bloccădere bruscatoate

„Bara oblică inversă” de la sfârșitul unei linii de comentariu înseamnă de fapt că linia de comentariu va continua mai jos.

Extinderea listelor cuprinse între acolade () poate produce un rezultat care vă poate surprinde și, în același timp, afișa setul de reguli procesate de parser:

$ cat /etc/pf.conf

trece de la (! 10.1.2.3,! 10.2.3.4) la oricare

$ pfctl -nvf /etc/pf.conf

trece inet din! 10.1.2.3 la oricare

trece inet din! 10.2.3.4laorice

Problema aici este că expresia „(! 10.1.2.3,! 10.2.3.4)” nu va însemna „toate adresele cu excepția 10.1.2.3 și 10.2.3.4”, expresia extinsă în sine înseamnă o potrivire cu orice adresă posibilă.

Trebuie să vă reîncărcați setul de reguli după modificări permanente pentru a vă asigura că pfctl îl poate încărca atunci când reporniți mașina. Pe OpenBSD, scriptul de pornire rc de la / etc / rc încarcă mai întâi un mic set de reguli implicite care blochează tot traficul, cu excepția celor necesare la pornire (cum ar fi dhcp sau ntp). Dacă scriptul nu reușește să încarce setul de reguli real din /etc/pf.conf din cauza erorilor de sintaxă introduse înainte de a reporni mașina fără verificare, atunci setul de reguli implicit va rămâne activ. Din fericire, acest set permite conexiuni ssh de intrare, astfel încât problema poate fi rezolvată de la distanță.

Testare

Întrucât avem o politică extrem de precis definită, și un set de reguli care trebuie să o implementeze, atunci termenul de testare va însemna, în cazul nostru, conformitatea setului rezultat cu o politică dată.

Există doar două moduri pentru ca regulile să funcționeze defectuos: blocarea conexiunilor care ar trebui să fie permise și invers, trecerea acelor conexiuni care ar trebui blocate.

Testarea implică în general o abordare sistematică a creației ordonate tipuri diferite conexiuni. Este imposibil să verificăm toate combinațiile posibile de sursă/destinație și porturile corespunzătoare pe interfețe, deoarece teoretic, firewall-ul s-ar putea ciocni cu sumă uriașă astfel de combinații. Asigurarea că un set de reguli este inițial corect poate fi asigurată doar pentru foarte mult cazuri simple... În practică, cea mai bună soluție ar fi crearea unei liste de conexiuni de testare pe baza unei politici de securitate, astfel încât fiecare punct de politică să fie afectat. Deci, pentru politica noastră de exemplu, lista de teste va fi următoarea:

Conexiune LAN la DMZ (trebuie omisă)

de la LAN la o rețea externă (trebuie să fie transmis)

de la DMZ la LAN (ar trebui blocat)

de la DMZ la rețeaua externă (ar trebui să fie transmis)

de la rețeaua externă la DMZ la 10.1.1.1 pe portul 80 (ar trebui să fie omis)

de la rețeaua externă la DMZ la 10.1.1.1 pe portul 25 (ar trebui blocat)

de la rețeaua externă la DMZ la 10.2.2.2 la portul 80 (ar trebui blocat)

de la rețeaua externă la DMZ la 10.2.2.2 la portul 25 (ar trebui să fie trecut)

de la rețeaua externă la LAN (ar trebui să fie blocată)

Rezultatul așteptat trebuie specificat în această listă înainte de testare.

Poate suna ciudat, dar scopul fiecărui test este de a găsi erori în implementarea setului de reguli pentru firewall, nu doar să afirme că acestea lipsesc. Și scopul final al procesului este de a construi un set de reguli fără erori, așa că dacă bănuiți că pot exista erori aici, este mai bine să le găsiți decât să le săriți peste. Și dacă vă asumați rolul unui tester, trebuie să rămâneți la un stil de gândire distructivă și să încercați să ocoliți limitările firewall-ului. Și doar faptul că constrângerile nu pot fi încălcate va fi o dovadă motivată că setul de reguli este lipsit de erori.

Conexiunile TCP și UDP pot fi verificate cu nc. nc poate fi folosit ca client și server (folosind opțiunea -l). Și pentru solicitările și răspunsurile ICMP, cel mai bun client se va face ping pentru a verifica.

Orice mijloc care va încerca să creeze conexiuni la server poate fi folosit pentru a verifica dacă conexiunea este blocată.

Folosind instrumente din colecția de porturi precum nmap, puteți scana cu ușurință mai multe porturi chiar și pe mai multe gazde. Dacă rezultatele nu par foarte clare, nu fi prea leneș să te uiți la pagina de manual. De exemplu, pe un port TCP, scanerul returnează „nefiltrat” atunci când nmap primește un RST de la pf. De asemenea, pf instalat pe aceeași mașină ca și scanerul poate avea efectul asupra corectitudinii nmap-ului.

Instrumentele de scanare mai sofisticate pot include instrumente pentru crearea de pachete IP fragmentate sau pentru trimiterea de pachete IP nevalide.

Pentru a verifica dacă filtrul trece conexiunile specificate în politică, cea mai bună metodă este să verificați folosind aplicațiile care vor fi ulterior utilizate de clienți. Deci, verificând trecerea conexiunilor http de la diferite mașini client ale serverului web, precum și de la browsere diferiteși prelevarea de probe continut diferit ar fi mai bine decât să recunoaștem stabilirea unei sesiuni TCP către nc care rulează ca backend. Diferiți factori, cum ar fi sistemul de operare gazdă, pot provoca, de asemenea, erori - probleme cu scalarea ferestrelor TCP sau răspunsurile TCP SACK între anumite sisteme de operare.

Când următorul punct de testare este trecut, este posibil ca rezultatele acestuia să nu fie întotdeauna aceleași. Conexiunea poate fi întreruptă în timpul procesului de stabilire a unei conexiuni dacă firewall-ul returnează RST. Stabilirea conexiunii poate pur și simplu să expire. Conexiunea poate fi pe deplin stabilită, funcționează, dar după un timp se îngheață sau se întrerupe. Conexiunea poate dura, dar lățimea de bandă sau latența pot fi diferite de cele așteptate, mai mari sau mai mici (în cazul în care utilizați AltQ pentru a limita lățimea de bandă).

Ca rezultate așteptate, pe lângă omiterea/blocarea conexiunii, se mai poate observa dacă pachetele sunt înregistrate, cum sunt difuzate, direcționate, dacă contoarele necesare sunt incrementate, dacă este necesar. Dacă aceste aspecte sunt importante pentru dvs., atunci ar trebui incluse și în metodologia de testare.

Politica dvs. poate include cerințe de performanță, răspuns la congestie și toleranță la erori. Și pot necesita teste separate. Dacă configurați un sistem tolerant la erori folosind CARP, probabil că doriți să știți ce se întâmplă atunci când apar diferite tipuri de defecțiuni.

Când vezi un rezultat care este diferit de ceea ce te-ai așteptat, marchează-ți pas cu pas în timpul testului, la ce te-ai așteptat, de ce te-ai așteptat, rezultatul obținut și cum diferă rezultatul de așteptările tale. Repetați testul pentru a vedea dacă situația este reproductibilă sau diferă din când în când. Încercați să modificați parametrii de intrare ai verificării (adresă sursă / destinație sau porturi).

Din momentul în care întâmpinați o problemă reproductibilă, trebuie să începeți depanarea pentru a vă da seama de ce lucrurile nu funcționează așa cum vă așteptați și cum să „remediați” totul. Cu această configurare, trebuie să modificați setul de reguli și să repetați toate testele, inclusiv cele care nu au cauzat erori, deoarece modificarea regulilor ar putea afecta din neatenție funcționarea părților care funcționează corect ale setului de reguli.

Același principiu se aplică și altor modificări ale setului. Această procedură formală de revizuire va contribui la ca procesul să fie mai puțin predispus la introducerea de erori. Poate să nu fie necesară repetarea întregii proceduri pentru modificări mici, dar suma mai multor modificări mici poate afecta rezultatul general al procesării setului. Puteți utiliza un sistem de control al versiunilor, cum ar fi cvs, pentru a lucra cu fișierul de configurare, deoarece acest lucru va ajuta la investigarea modificărilor care au condus la eroare. Dacă știți că eroarea nu a apărut acum o săptămână, dar acum este, revizuiți toate modificările făcute în săptămâna trecută vă va ajuta să observați problema sau cel puțin să reveniți la momentul absenței acesteia.

Seturile de reguli non-triviale pot fi considerate ca niște programe, rareori sunt perfecte în prima lor lansare și este nevoie de timp pentru a afirma cu încredere că sunt fără erori. Cu toate acestea, spre deosebire de programele obișnuite, care nu sunt niciodată considerate fără erori de către majoritatea programatorilor, seturile de reguli sunt încă suficient de simple pentru a se apropia de această definiție.

Depanare

Termenul depanare se referă de obicei la găsirea și remedierea erorilor de programare în programele de calculator. Sau, în contextul seturilor de reguli de firewall, termenul ar însemna procesul de căutare a unui motiv pentru care setul nu returnează rezultatul dorit. Există puține tipuri de erori care pot apărea în reguli, cu toate acestea, metodele de găsire a acestora sunt similare cu programarea.

Înainte de a începe să căutați cauza problemei, trebuie să înțelegeți clar natura problemei. Dacă ați observat singur o eroare în timpul testării, este foarte simplu. Dar dacă o altă persoană vă spune despre o eroare, stabilirea unui obiectiv clar dintr-un raport de eroare inexact poate fi o sarcină descurajantă. Cel mai bun loc pentru a începe este să reproduci singur bug-ul.

Problemele de rețea pot să nu fie întotdeauna cauzate de un filtru de pachete. Înainte de a vă concentra pe depanarea configurației pf, trebuie să vă asigurați că problema este cauzată de un filtru de pachete. Acest lucru este ușor de făcut și, de asemenea, vă poate economisi timp pentru depanarea în altă parte. Doar dezactivați pf cu comanda pfctl -d și verificați dacă problema reapare. Dacă da, activați pf cu pfctl -e și vedeți ce se întâmplă. Această metodă va eșua în unele cazuri, de exemplu, dacă pf nu face traducerea corectă. adresele de rețea(NAT), apoi dezactivarea pf, evident, nu vă va salva eroarea. Dar acolo unde este posibil, încercați să vă asigurați că filtrul de pachete este vinovatul.

În consecință, dacă problema este în filtrul de pachete, primul lucru de făcut este să vă asigurați că pf funcționează efectiv și că setul corect de reguli a fost încărcat cu succes:

# pfctl -si | stare grep

Stare: Activat timp de 4 zile 13: 47: 32 Depanare: Urgent

# pfctl -sr

treci repede pe lo0 toate

trece rapid pe enc0 all

Depanare prin protocoale

Următorul pas în depanare este reflectarea problemei pe anumite conexiuni de rețea. Dacă aveți o premisă: „Meseria instantă în aplicația X nu funcționează”, trebuie să aflați ce conexiuni de rețea sunt utilizate. Concluzia poate fi „gazda A nu poate stabili o conexiune cu gazda B pe portul C”. Uneori, această sarcină este cea mai dificilă, dar dacă aveți informații despre conexiunile necesare și știți că firewall-ul nu le va lăsa să treacă, trebuie doar să schimbați regulile pentru a rezolva această problemă.

Există mai multe modalități de a afla ce protocoale sau conexiuni folosește o aplicație. Tcpdump poate afișa pachete în și din interfața de rețea reală, precum și pe cele virtuale, cum ar fi pflog și pfsync. Puteți specifica o expresie de filtrare pentru a specifica pachetele de afișat și pentru a elimina zgomotul nedorit al rețelei. Încercați să instalați conexiune reteaîn aplicația dorită și uitați-vă la pachetele trimise. De exemplu:

# tcpdump -nvvvpi fxp0 tcp și nu port ssh și nu port smtp

23: 55: 59.072513 10.1.2.3.65123> 10.2.3.4.6667: S

4093655771: 4093655771 (0) câștig 5840

1039287798 0, nu, wscale 0> (DF)

Acesta este pachetul TCP SYN, primul pachet de la conexiunea TCP stabilită (strângere de mână TCP).

Expeditorul este portul 10.1.2.3 65123 (pare un port neprivilegiat aleatoriu) iar receptorul este portul 10.2.3.4 6667. Pentru o explicație detaliată a formatului de ieșire tcpdump, consultați paginile cu manualul utilitarului. Tcpdump este cel mai important instrument pentru depanarea problemelor legate de pf și este foarte important să vă familiarizați cu acesta.

O altă metodă este să folosiți funcția de înregistrare în pf. Presupunând că utilizați opțiunea „jurnal” pentru toate regulile cu „blocare”, atunci toate pachetele blocate de pf vor fi înregistrate. Puteți elimina opțiunea „jurnal” din regulile care se ocupă de protocoale cunoscute, de ex. vor fi înregistrate doar acele pachete care merg către porturi necunoscute. Încercați să utilizați o aplicație care nu poate comunica și aruncați o privire la pflog:

# ifconfig pflog0 sus

# tcpdump -nettti pflog0

26 noiembrie 00: 02: 26.723219 regula 41/0 (meci): blocați pe kue0:

195.234.187.87.34482> 62.65.145.30.6667: S 3537828346: 3537828346 (0) câștig

16384 (DF)

Dacă utilizați pflog, un demon care ascultă constant pflog0 și stochează informațiile rezultate în / var / log / pflog, puteți vedea informațiile înregistrate astfel:

# tcpdump -netttr /var /Buturuga /pflog

Când afișați pachetele stocate pf, puteți utiliza expresii de filtrare suplimentare, de exemplu, vizualizați pachetele care au fost blocate la intrarea pe interfața wi0:

# tcpdump -netttr / var / log / pflog inbound și bloc de acțiune și pe wi0

Unele protocoale, cum ar fi FTP, nu sunt ușor de urmărit, deoarece nu folosesc numere de porturi fixe sau folosesc mai multe conexiuni care coexistă. Este posibil să nu fie posibil să le treceți prin firewall fără a deschide o gamă largă de porturi. Pentru unele protocoale, există soluții similare cu ftp-proxy.

Reguli de depanare

Dacă setul dvs. de reguli blochează un anumit protocol deoarece nu ați deschis portul corect, aceasta este mai mult o problemă de proiectare decât o eroare de regulă. Dar dacă vezi că se blochează o conexiune pentru care ai o regulă care o respectă?

De exemplu, setul tău conține regula

bloc în return-rst pe $ ext_if proto tcp de la orice la $ ext_if port ssh

Dar când încerci să te conectezi la Port TCP 22, conexiunea este acceptata! Se pare că firewall-ul vă ignoră regula. La fel ca și în cazul asamblarii „puzzle-urilor”, în aceste cazuri, când te confrunți cu ele primele câteva ori, există o explicație simplă logică și de obicei banală.

În primul rând, ar trebui să verificați toți pașii menționați mai devreme. De exemplu, să presupunem că firewall-ul rulează și conține regula de mai sus. Este puțin probabil ca preocupările noastre anterioare să fie valide, dar acest lucru este ușor de verificat:

# pfctl -si | stare grep

Stare: Activat timp de 4 zile 14: 03: 13 Depanare: Urgent

# pfctl -gsr | grep "port = ssh"

@ 14 bloc return-rst in pe kue0 inet proto tcp de la oricare la 62.65.145.30 port = ssh

Următorul lucru pe care îl avem este că conexiunile TCP sunt acceptate pe portul 22 de pe kue0. S-ar putea să credeți că acest lucru este deja evident, dar nu va fi de prisos să verificați. Rulați tcpdump:

# tcpdump -nvvvi kue0 tcp și portul 22 și dst 62.65.145.30

Acum încercați din nou conexiunea SSH. Ar trebui să vedeți pachetele de la conexiunea dvs. în ieșirea tcpdump. Este posibil să nu le vedeți, iar acest lucru s-ar putea datora faptului că conexiunea nu trece de fapt prin kue0, ci trece printr-o interfață diferită, ceea ce explică de ce regula nu se declanșează. Sau este posibil să vă conectați la o altă adresă. Pe scurt, dacă nu vedeți pachetele ssh, atunci nici pf nu le va vedea, poate că nu le poate bloca folosind regula dată în sarcina noastră.

Dar dacă vedeți pachete cu tcpdump, pf le va vedea și le va filtra. Următoarea ipoteză este că regula de blocare nu ar trebui să fie prezentă doar în set (pe care am aflat deja), ci să fie ultima regulă de potrivire pentru pachetele necesare. Dacă aceasta nu este ultima regulă, evident, conform acesteia, decizia privind întârzierea pachetelor nu se ia.

Când este posibil ca o regulă să nu fie ultima regulă care se potrivește? Există trei motive posibile:

A) regula nu funcționează, deoarece vizualizarea regulilor nu ajunge la ceea ce avem nevoie.

O regulă prezentă anterior se declanșează și determină o întrerupere cu opțiunea „rapidă”;

B) regula este procesată, dar regula nu funcționează din cauza discrepanței dintre anumite criterii.

C) regula este procesată, regula este declanșată, dar procesarea continuă și regulile ulterioare sunt, de asemenea, declanșate pentru pachet.

Pentru a respinge aceste trei cazuri, puteți vizualiza procesarea unui pachet TCP ipotetic care ajunge pe interfața kue0 și portul 22, uitându-vă la setul de reguli încărcat.Selectați blocul de depanat. Începeți prin a parcurge prima regulă. Se potrivește? Dacă da, marcați-l. Are o opțiune „rapidă”? Dacă da, atunci încetăm să ocolim. Daca nu, continua cu urmatoarea regula... Repetați testul până când se potrivește cu opțiunea „rapidă” sau ajunge la sfârșitul setului de reguli. Care regulă a fost potrivită ultima dată? Dacă nu este regula numărul 14, ați găsit o explicație pentru problemă.

Ocolirea manuală a regulilor poate părea distractiv, totuși, dacă ai suficientă experiență, se poate face destul de repede și cu un grad ridicat de fiabilitate. Dacă setul este suficient de mare, îl puteți scurta temporar. Păstrați o copie a listei actuale de reguli și ștergeți toate intrările care credeți că nu vor afecta rezultatul. Descărcați acest kit și verificați din nou. Dacă acum conexiunea este blocată, atunci regulile care păreau să nu aibă legătură cu pachetele căutate sunt responsabile pentru cazurile A sau B. Adaugă reguli unul câte unul, repetând testul până îl găsești pe cel dorit. Dacă conexiunea este încă omisă după ștergerea regulilor care nu o afectează, repetați parcurgerea mentală a setului redus.

O altă metodă este să utilizați capacitatea de înregistrare a pf pentru a identifica cazurile A sau C. Adăugați „jurnal” la toate regulile cu „pass rapid” înainte de a 14-a regulă. Adăugați „jurnal” la toate regulile cu „trece” după regula 14. Rulați tcpdump pe interfața pflog0 și stabiliți o conexiune ssh. Veți vedea care reguli, în afară de a 14-a, sunt declanșate ultimele în pachetele dvs. Dacă nu există nimic în jurnal, atunci are loc cazul B.

Urmărirea conexiunilor printr-un firewall

Când o conexiune trece printr-un firewall, pachetele ajung pe o interfață și sunt trimise prin cealaltă. Răspunsurile vin la a doua interfață și merg la prima. Conexiunile pot fi astfel întrerupte în fiecare dintre aceste patru cazuri.

În primul rând, trebuie să vă dați seama care dintre cele patru cazuri este problema. Dacă încercați să stabiliți o conexiune, ar trebui să vedeți un pachet TCP SYN pe prima interfață folosind tcpdump. De asemenea, ar trebui să vedeți același pachet TCP SYN la ieșirea de la a doua interfață. Dacă nu îl vedeți, atunci tragem concluzia că pf se blochează pachetul primit pe prima interfață sau de ieșire pe a doua.

Dacă trimiterea SYN nu este blocată, ar trebui să vedeți SYN + ACK care intră pe a doua interfață și iese pe prima. Dacă nu, pf blochează SYN + ACK pe o anumită interfață.

Adăugați opțiunea „jurnal” la regulile care trebuie să permită SYN și SYN + ACK pe ambele interfețe și regulile care trebuie să le blocheze. Încercați să vă conectați din nou și verificați pflog. Ar trebui să clarifice în ce caz are loc blocarea și după ce regulă.

Depanarea stărilor de conexiune

Cel mai frecvent motiv pentru care pf blochează pachetele este că există o regulă de blocare redundantă în set. O regulă de potrivire care se declanșează la ultima potrivire poate fi găsită prin adăugarea opțiunii „jurnal” la toate regulile care pot afecta și ascultând interfața pflog.

În mai puține cazuri, se întâmplă ca pf să renunțe la pachete bazate pe non-reguli, iar aici adăugarea unui „jurnal” la toate regulile nu va face ca pachetele abandonate să treacă la pflog. Adesea, un pachet se potrivește aproape, dar nu în totalitate, cu o intrare de stat.

Rețineți că pentru fiecare pachet pe care îl procesează, filtrul de pachete efectuează o scanare a tabelului de stări. Dacă se găsește o intrare care se potrivește, pachetul este omis imediat, fără ca el însuși să proceseze setul de reguli.

O intrare de tabel de stare conține informații specifice unei singure conexiuni.

Fiecare intrare are o cheie unică. Această cheie constă din mai multe valori care sunt constante pe toată durata de viață a conexiunii. Aici sunt ei:

• Tip de adresă (Ipv4 sau Ipv6)
• Sursa adresei
• Adresa destinatarului
• Protocol (TCP UDP)
• Port sursă
• Port receptor

Această cheie este utilizată pentru toate pachetele legate de aceeași conexiune și pachete conexiuni diferite va avea întotdeauna chei diferite.

Când se utilizează opțiunea „păstrare stare” pentru a crea o intrare în tabelul de stări, înregistrarea conexiunii este păstrată folosind cheia conexiunii respective. O limitare importantă pentru tabelul de stări este că toate cheile trebuie să fie unice. Acestea. nu pot exista două înregistrări cu aceleași chei.

Este posibil să nu fie imediat evident că aceleași două gazde nu pot stabili mai multe conexiuni coexistente folosind aceleași adrese, protocoale și porturi, dar acest lucru este proprietate fundamentală atât TCP, cât și UDP. De fapt, stivele TCP / IP pot asocia pachete individuale cu socket-urile lor doar prin preluarea pe baza adreselor și a portului.

Chiar dacă conexiunea este închisă, aceeași pereche de adrese și porturi nu poate fi reutilizată imediat. Pachetele retransmise pot fi ulterior livrate de echipamentul de rețea, iar dacă stiva TCP/IP a destinatarului le-a confundat cu pachetele conexiunii nou create, acest lucru ar împiedica sau chiar ar termina noua conexiune. Din acest motiv, ambele gazde trebuie să aștepte o anumită perioadă de timp numită 2MSL (de două ori durata maximă de viață a segmentului) înainte de a putea utiliza din nou aceleași adrese și porturi pentru o nouă conexiune.

Puteți observa această proprietate stabilind manual mai multe conexiuni la aceeași gazdă. De exemplu, având un server web care rulează pe 10.1.1.1 și portul 80 și conectarea de două ori cu 10.2.2.2. folosind nc:

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

Conexiunea la portul 10.1.1.1 80 a reușit!

În timp ce conexiunile sunt deschise, puteți utiliza netstat pe client sau server pentru a afișa informații despre aceste conexiuni:

$ netstat -n | grep 10.1.1.1.80

tcp 0 0 10.2.2.6.28054 10.1.1.1.80 INFIINTAT

tcp 0 0 10.2.2.6.43204 10.1.1.1.80 INFIINTAT

După cum puteți vedea, clientul a ales două porturi sursă diferite (aleatorie), astfel încât acest lucru nu încalcă cerința de unicitate a cheii.

Puteți spune nc să folosească un anumit port sursă cu opțiunea -p:

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

Conexiunea la portul 10.1.1.1 80 a reușit!

nc: bind failed: Adresă deja utilizată

Stiva TCP/IP client a prevenit încălcarea unicității cheii. Unele implementări rare și greșite ale stivelor TCP/IP nu au respectat această regulă și, așa cum vom vedea în curând, pf își va bloca conexiunile dacă este încălcată unicitatea cheii.

Să ne întoarcem la locul în care pf interogează tabelul de stare în momentul în care pachetul începe să se filtreze. Solicitarea constă în doi pași. Prima solicitare este de a găsi o intrare în tabelul de înregistrare cu o cheie corespunzătoare protocolului, adreselor și portului pachetului. Căutarea va fi efectuată pentru pachetele care merg în orice direcție. Să presupunem că pachetul de mai jos a creat o intrare în tabelul de stări:

sositTCPdin 10.2.2.2:28054până la 10.1.1.1:80

O interogare pe tabel va găsi următoarele intrări în tabelul de stare:

TCP de intrare de la 10.2.2.2:28054 la 10.1.1.1:80

TCP de ieșire de la 10.1.1.1:80 la 10.2.2.2:28054

Înregistrarea din tabel include informații despre direcția (inbound sau outbound) a primului pachet care a creat înregistrarea. De exemplu, următoarele înregistrări nu se vor potrivi:

de ieșireTCPdin 10.2.2.2:28054până la 10.1.1.1:80

sositTCPdin 10.1.1.1:80până la 10.2.2.2:28054

Motivul acestor limitări nu este evident, ci mai degrabă simplu. Imaginați-vă că aveți o singură interfață la 10.1.1.1 unde serverul web ascultă pe portul 80. Când un client 10.2.2.2 se conectează folosind un port de ieșire aleatoriu 28054, primul pachet de conexiune ajunge pe interfața dvs. și toate răspunsurile dvs. de ieșire ar trebui să fie de la 10.1.1.1:80 până la 10.2.2.2:28054. Nu veți permite pachete de ieșire de la 10.2.2.2:28054 la 10.1.1.1:80, deoarece astfel de pachete sunt lipsite de sens.

Dacă firewall-ul tău este configurat pentru două interfețe, atunci observând pachetele care trec prin el, vei vedea că fiecare pachet care ajunge pe prima interfață se stinge și prin a doua. Dacă creați o înregistrare de stare în care pachetul inițial ajunge pe prima interfață, atunci acea înregistrare va împiedica același pachet să părăsească a doua interfață deoarece este în direcția greșită.

Când o încercare de a găsi un pachet printre intrările din tabelul de stări eșuează, lista regulilor de filtrare este parcursă. Trebuie să permiteți în mod specific pachetului să iasă prin a doua interfață cu o regulă separată. Cel mai probabil utilizați „păstrați starea” în această regulă, astfel încât a doua intrare din tabelul de stare să acopere întreaga conexiune de pe a doua interfață.

S-ar putea să vă întrebați cum este posibil să creați oa doua înregistrare într-un tabel când tocmai am explicat că înregistrările trebuie să aibă chei unice. Explicația aici este că înregistrarea conține și informații despre direcția conexiunii, iar combinarea acestora cu restul datelor trebuie să fie unică.

Acum vom putea explica și diferența dintre o conexiune liberă și o conexiune legată de interfață. În mod implicit, pf creează intrări care nu sunt legate la nicio interfață. Prin urmare, dacă permiteți conexiuni pe o singură interfață, pachetele legate de conexiune și care se încadrează sub intrarea tabelului (inclusiv informații despre direcția pachetului!) Treceți prin orice interfață. În instalațiile simple cu rutare statică, acestea sunt calcule mai teoretice. Practic, nu ar trebui să vedeți pachete dintr-o conexiune care sosesc prin mai multe interfețe și pachete de răspuns care părăsesc și mai multe interfețe. Cu toate acestea, cu rutarea dinamică, acest lucru este posibil. Puteți lega înregistrările de stare la o interfață specifică utilizând setarea globală „set state-policy if-bound” sau opțiunea „keep state (if-bound)” pentru fiecare regulă. Acest lucru va asigura că pachetele vor fi corelate numai cu intrările din interfața care a creat intrările.

Dacă utilizați interfețe pentru tuneluri, atunci aceeași conexiune trece prin firewall de mai multe ori. De exemplu, primul pachet de conexiune poate trece mai întâi prin interfața A, apoi prin B, apoi C și în final să ne părăsească prin interfața D. De obicei, pachetele vor fi încapsulate pe interfețele A și D și decapsulate pe B și C, așa că pf vede pachete de protocoale diferite și puteți crea 4 intrări diferite în tabelul de stare. Fără încapsulare, pachetul va rămâne neschimbat pe toate cele patru interfețe și nu veți putea folosi unele caracteristici, cum ar fi traducerea adresei sau modularea numărului de secvență tcp, deoarece acest lucru va duce la chei conflictuale în tabelul de stări. Până când nu veți avea o instalare completă care include interfețe cu tunel și erori depanate precum „pf: src_tree insert failed”, nu veți putea considera că integrarea dvs. este suficient de reușită. Să revenim la interogarea tabelului de stare pentru fiecare pachet înainte de a verifica regulile. Solicitarea ar trebui să returneze o singură înregistrare cu cheie potrivită, sau nu returnați nimic. Dacă interogarea nu returnează nimic, se parcurge lista de reguli.

Dacă se găsește o intrare, al doilea pas pentru pachetele TCP este verificarea numărului de secvență înainte ca acestea să fie considerate ca aparținând unei anumite conexiuni și să fie filtrate.

Există un numar mare de Atacuri TCP în care un atacator încearcă să controleze o conexiune între două gazde. În cele mai multe cazuri, atacatorul nu se află pe calea rutelor dintre gazde, așa că nu poate asculta pachetele legitime trimise de gazde. Cu toate acestea, poate trimite pachete către oricare dintre gazde, imitând pachetele interlocutorului său, prin intermediul spoofing-ului - falsificarea adresei expeditorului. Scopul unui atacator ar putea fi acela de a preveni crearea de conexiuni între gazde sau de a întrerupe conexiunile existente (pentru a provoca o refuz de serviciu) sau de a crea o sarcină rău intenționată asupra conexiunilor.

Pentru un atac de succes, un atacator trebuie să „ghicească” corect mai mulți parametri de conexiune, cum ar fi adresa/portul sursei și destinației. Și pentru protocoalele utilizate pe scară largă, s-ar putea să nu fie atât de dificil pe cât ar părea. Dacă atacatorul știe adresele gazdei și unul dintre porturi (întrucât vorbim de un serviciu comun), va trebui să „ghicească” doar un port. Chiar dacă clientul folosește un port sursă cu adevărat aleatoriu (ceea ce de fapt nu este întotdeauna adevărat), atacatorul trebuie doar să încerce 65536 porturi într-un timp scurt. (În majoritatea cazurilor, chiar și porturile (65536-1024), adică numai porturi neprivilegiate - nota traducătorului))

Dar ceea ce este cu adevărat greu de ghicit pentru un atacator este numărul de secvență corect (și confirmarea acestuia). Dacă ambele gazde aleg numărul de început secvențe aleatoriu (sau utilizați modularea numărului de secvență pentru gazdele care au un generator ISN (Initial Sequence Number) „slab”), atunci atacatorul nu va putea alege valoarea corespunzătoare la momentul potrivit al conexiunii.

Pe durata de viață a unei conexiuni TCP valide, numerele de secvență (și confirmările) pentru pachetele individuale sunt modificate în conformitate cu anumite reguli.

De exemplu, dacă o gazdă trimite un anumit segment de date și receptorul ei confirmă primirea, nu ar trebui să existe niciun motiv pentru care expeditorul ar trebui să trimită din nou datele segmentului. Dar, de fapt, încercarea de a suprascrie informațiile deja primite de gazdă nu este o încălcare. Protocolul TCP, deși poate fi o formă de atac.

pf folosește reguli pentru a determina cel mai mic interval pentru numerele de secvență legitime. În general, pf poate identifica cu exactitate doar autenticitatea de 30.000 din 4294967296 numere posibile secvența în orice moment a conexiunii. Numai dacă numărul de secvență și confirmarea intră în această fereastră se va asigura că pachetul este legitim și îl va lăsa să treacă.

Dacă în timpul unei interogări la tabelul de stări se găsește intrare potrivită, pe urmatorul pas numerele de secvență ale pachetelor stocate în tabel sunt verificate în funcție de interval valori posibile... Dacă comparația nu reușește, pf va genera un mesaj de „stare proastă” și va arunca pachetul fără a evalua setul de reguli. Există două motive pentru care s-ar putea să nu se întâmple comparația cu regulile: este aproape sigur o eroare să sari peste pachet, deoarece dacă calculul setului va duce la atingerea unei opțiuni din regulă „păstrați starea” și pf nu vor putea judeca și crea intrare nouă deoarece acest lucru va duce la chei conflictuale în tabel.

Pentru a vedea și a scrie în jurnal mesajele „stare proastă”, trebuie să activați modul de depanare folosind comanda:

$ pfctl -xm

Mesajele de depanare sunt trimise implicit către consolă, iar syslogd le scrie și în / var / log / mesaje. Căutați mesaje care încep cu „pf”:

pf:RĂUstat:TCP 192.168.1.10:20 192.168.1.10:20 192.168.1.200:64828

[ lo = 1185380879mare = 1185380879câștig = 33304modulator = 0wscale = 1]

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

dir = out, fwd

pf: Eșecul de stare pe: 1 |

Aceste mesaje vin întotdeauna în perechi. Primul mesaj arată intrarea din tabelul de stare la momentul blocării pachetului și numărul de secvență al pachetului care a cauzat eroarea. A doua intrare afișează condițiile care au fost încălcate.

La sfârșitul primului mesaj, veți vedea dacă a fost creată o înregistrare de stare pentru un pachet de intrare (dir = in) sau de ieșire (dir = out) și dacă pachetul blocat a mers în aceeași direcție (dir =, fwd) sau în sens opus (dir =, rev ).

Intrarea din tabel conține trei adrese: perechi de porturi, dintre care două sunt întotdeauna egale între ele, dacă conexiunea nu a suferit conversie nat, rdr sau bnat. Pentru conexiunile de ieșire, sursa este afișată în stânga, iar destinația pachetului este în dreapta. Dacă conexiune de ieșire permite conversia adresei sursă, perechea din mijloc indică sursa după conversie. Pentru conexiunile de intrare, sursa este în dreapta în pin și destinația este în mijloc. Dacă conexiunea de intrare suferă o traducere a adresei de destinație, perechea ip/port din stânga arată destinația după ce traducerea a fost făcută. Acest format se potrivește cu rezultatul pfctl -ss, cu singura diferență că pfctl indică direcția pachetului folosind săgeți.

În ieșire, puteți vedea numerele curente ale secvenței gazdei între paranteze drepte. Deci valoarea „4: 4” înseamnă că conexiunea este pe deplin stabilită (valorile mai mici sunt mai probabile în stadiul stabilirii unei conexiuni, valori mai mari - până la momentul în care conexiunea este închisă).„A” înseamnă că pachetul blocat avea setat steag-ul ACK (ca în ieșirea steagului tcpdump), urmat de valorile numerelor de secvență (seq =) și (ack =) din pachetele blocate și lungimea încărcăturii utile a pachetului - lungimea datelor (len =). askskew este o parte a reprezentării interne a datelor într-un tabel, care este utilizat numai atunci când valorile nu sunt egale cu zero.

Înregistrarea „pkts = 930: 631” înseamnă că a potrivit 940 de pachete în aceeași direcție cu cel care a provocat această înregistrare și 631 de pachete în direcția opusă. Aceste contoare vor fi deosebit de utile atunci când se caută probleme în stadiul stabilirii unei conexiuni, dacă una dintre ele este zero, acest lucru ar contrazice așteptările dvs. că înregistrarea dată se va potrivi cu pachetele care merg în ambele direcții.

Următorul mesaj va conține o listă cu una sau mai multe cifre. Fiecare cifră reprezintă verificarea la care a apărut eroarea:

1. dimensiunea ferestrei pachetului depășește dimensiunea maximă a destinatarului (seq + len> high)
2. pachetul conține date deja transmise (seq< lo - win)
3. ackskew este mai mică decât valoarea minimă
4. ackskew este mai mare decât valoarea maximă
5. la fel ca în (1), dar cu diferența (seq + len> high + win)
6. la fel ca în (2), dar (sev< lo - maximum win)

Din fericire, mesajele de „stare proastă” nu au legătură cu traficul real de zi cu zi, iar verificarea numărului de secvență evită majoritatea anomaliilor. Dacă vedeți că aceste mesaje apar neregulat și nu observați un număr mare de conexiuni suspendate, puteți pur și simplu să le ignorați. Există multe implementări TCP/IP pe Internet, iar unele dintre ele pot genera uneori pachete eronate.

Cu toate acestea, această clasă de probleme poate fi diagnosticată cu ușurință prin apariția mesajelor de „stare RAU”, care apar doar în astfel de cazuri.

Crearea înregistrărilor de statTCP pe initialPachetul SYN.

În mod ideal, înregistrările de stare ar trebui să fie generate când sosește primul pachet SYN.

Puteți impune utilizarea acestei reguli folosind principiul:

„Utilizați” steaguri S/SA „opțiuni în toate” trece proto tcp păstrează starea „reguli”

Doar (și numai) pachetele inițiale SYN au marcajul SYN setat și un ACK colectat. Când se utilizează opțiunea „păstrare stare” se leagă numai pachetele SYN inițiale, numai acele pachete vor crea o intrare în tabelul de stare. Astfel, orice intrare existentă în tabelul de stări va fi făcută din pachetul SYN inițial.

Motivul creării înregistrărilor numai pentru pachetele inițiale este o extensie TCP numită „scalare fereastră”, definită în RFC1323. Câmpul antet TCP folosit pentru a face publicitate dimensiunii ferestrelor primite este prea mic pentru legăturile de mare viteză actuale. Implementările moderne TCP / IP preferă să utilizeze ferestre de dimensiuni mai mari decât se pot încadra în câmpul existent. Scalarea ferestrelor înseamnă că toate dimensiunile ferestrelor care sunt cunoscute de la gazda destinatarului ar trebui înmulțite cu o valoare specifică dată de destinatar, mai degrabă decât luate de ele însele. Pentru ca această schemă să funcționeze, ambele gazde trebuie să accepte extensia și să-și indice reciproc capacitatea de a o implementa în etapa de strângere de mână folosind opțiunile TCP. Aceste opțiuni sunt prezente doar în pachetele inițiale SYN și SYN + ACK. Și numai dacă fiecare dintre aceste pachete conține o opțiune, negocierea va avea succes și dimensiunea ferestrei tuturor pachetelor ulterioare va fi înmulțită cu un factor.

Dacă pf nu „știe” despre scalarea ferestrei utilizată, valoarea furnizată fără coeficient ar fi luată, iar calculul dimensiunilor ferestrelor pentru valorile acceptabile ale numerelor de secvență ar fi efectuat incorect. De obicei, gazdele oferă ferestre de dimensiuni mici la începutul unei conexiuni și le măresc în timpul conexiunii. Neconștient de existența unor factori care modifică dimensiunea ferestrei, pf va începe la un moment dat să blocheze pachetele, deoarece se va gândi că una dintre gazde încearcă să ocolească dimensiunea maximă a ferestrei oferită de „interlocutor”. Efectele acestui lucru pot fi mai mult sau mai puțin vizibile. Uneori, gazdele vor reacționa la pierderea pachetelor mergând la așa-numitul. „Modul de recuperare pierdere” și va face publicitate unei ferestre de dimensiune mai mică. După ce pf retransmite pachetele care au fost aruncate prima dată, dimensiunile ferestrelor vor crește și mai mult până la punctul în care pf începe să le blocheze din nou. O manifestare externă poate fi înghețarea temporară a conexiunilor și performanta slaba... Posibil si blocare completă sau resetați conexiunile până la expirare.

Dar pf știe despre capacitatea de a scala ferestre și o acceptă. Totuși, condiția prealabilă pentru crearea intrărilor din tabelul de stări pentru primele pachete SYN este ca pf să poată asocia primele două pachete ale unei conexiuni cu o înregistrare din tabel. Și deoarece potrivirea completă a coeficienților dimensiunii ferestrei are loc numai în aceste primele două pachete, nu există o metodă sigură pentru a determina acești coeficienți după negocierea conexiunii.

În trecut, scalarea ferestrelor nu era utilizată pe scară largă, dar aceasta se schimbă rapid. Doar recent această opțiune a fost activată implicit în Linux. Dacă întâmpinați probleme cu suspendarea conexiunilor, în special cu unele combinații de gazdă, și vedeți mesaje de „stare proastă” legate de acele conexiuni, asigurați-vă că creați intrări în tabelul de stări pentru primele pachete de conexiune.

Puteți spune dacă pf folosește opțiunea de scalare pentru unire din rezultatul pfctl:

$ pfctl -vss

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

wscale 0wscale 1

Dacă intrarea „wscale x” tipărită pe a doua linie este prezentă (chiar dacă x este zero), pf reads știe că îmbinarea folosește scalarea.

O altă metodă simplă pentru identificarea problemelor de scalare este dezactivarea temporară a suportului de scalare și reluarea situației. Pe OpenBSD, utilizarea scalării poate fi controlată cu opțiunea sysctl:

$ sysctlnet.inet.tcp.rfc1323

net.inet.tcp.rfc1323 = 1

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

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

Probleme similare apar atunci când creați intrări în tabelul de stare pentru alte pachete decât SYN-urile inițiale și utilizați opțiunea de stare moulate sau difuzare. În ambele cazuri, difuzarea are loc la începutul conexiunii. Dacă primul pachet nu este difuzat, difuzarea celor ulterioare descurajează, de obicei, partea de recepție și face ca răspunsurile trimise să fie blocate de pf cu mesajul „stare REA”.