În zilele noastre, laptopurile sunt foarte populare ca computere de acasă deoarece ocupă puțin spațiu și pot fi transportate cu ușurință din cameră în cameră. Mulți utilizatori casnici includ partajarea fișiere pentru, de exemplu, pentru a reda conținut digital pe acestea sisteme multimediași televizoare.

Mulți dintre acești utilizatori își duc laptopurile cu ei în locuri publice, cum ar fi cafenele, și se conectează la internet folosind o rețea Wi-Fi fără fir. Este rezonabil de așteptat ca atunci când solicitați un firewall și alegeți o rețea ca publică, computerul trebuie protejat de intruziunile altor participanți în rețeaua deschisă.

Utilizatorii de afaceri care folosesc un laptop ca singur computer de lucru se pot găsi în aceeași situație, cu mașinile lor cel mai adesea configurate pentru a fi monitorizate prin Microsoft Remote Desktop.

Scopul acestui test este de a determina modul în care cele mai populare firewall-uri terțe (firewall-uri) sunt autonome și grupate. securitatea internetului- oferă de fapt controlul de bază al accesului inbound pentru utilizatorii de laptop care comută între rețelele de acasă/serviciu și publice.

Vă rugăm să rețineți că domeniul de aplicare al testului este în mod evident foarte limitat și, prin urmare bun rezultatîn el, nu înseamnă că produsul oferă securitate completă a rețelei.

Testarea a fost efectuată în ianuarie 2014 la comanda revistei CHIP Online (Germania). Versiunile firewall-urilor utilizate erau disponibile începând cu 13 ianuarie 2014.

Procedura de testare a paravanului de protecție

PC-ul de testare este conectat la Internet printr-o rețea locală fără fir (WLAN) folosind o conexiune de rețea care este identificată ca Privată în Centrul de partajare a rețelei și acces general Windows (WNSC).

Versiunea de testare a fiecărui produs disponibilă începând cu 13 ianuarie 2014 este instalată cu setările implicite și calculator de testare repornește. Dacă produsul însuși solicită utilizatorului să definească tipul de rețea curent ca Privat / De încredere, acesta va fi selectat această opțiune... Dacă produsul are o funcție de actualizare, atunci aceasta este executată. Se verifică dacă produsul a fost înregistrat la Centru Suport Windows la fel de firewall de sistem iar produsul în sine a arătat că funcționează conform așteptărilor. Al doilea PC verifică conexiunea la rețeaua privată existentă după cum urmează:

• Ping nume de gazdă -4
• Ping nume de gazdă -6
• Ping adresa IPv4
• Ping adresa IPv6
• Nume de gazdă pentru partajarea fișierelor
• Adresă IPv4 de partajare a fișierelor
• Nume gazdă Desktop la distanță (RDP).
• Adresă IPv4 Remote Desktop (RDP).
• Adresă IPv6 Remote Desktop (RDP).

Se verifică că toate aceste forme de acces la distanță funcționează pentru a asigura funcționalitatea deplină a PC-ului de testare în rețeaua privată și controlul maxim al acestuia. După aceea, computerul și routerul la care a fost conectat se opresc, iar computerul pornește din nou. Apoi se conectează la un alt WLAN, care este definit ca Public (Public) în WNSC, utilizând caseta de dialog Windows Firewall.

Dacă firewall-ul își arată solicitarea de a determina tipul de rețea, valoarea este setată la „Public” sau „Neîncredere”. Nu se mai fac modificări la configurarea produsului.

Această procedură simulează comportamentul tipic al unui utilizator de laptop care călătorește de la domiciliu/la birou la o rețea publică într-o cafenea, aeroport sau hotel. După ce computerul este conectat la noul public retea fara fir, se fac aceleasi teste ca si pentru conectarea la o retea privata. De această dată, toate încercările de conectare sunt de așteptat să eșueze, deoarece computerul trebuie protejat de orice descoperire și acces din exterior în rețeaua publică.

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

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 conexiune specificăși configurarea parametrilor suplimentari de filtrare ICMP.

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

Utilizare creare automată excepții ale aplicației la pornirea unui 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 Modificare domeniul de aplicare pentru a seta intervalul de adrese de la care se pot face conexiuni aplicația specificată sau port.

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.

Secțiunea este actualizată zilnic. Întotdeauna versiuni proaspete ale celor mai bune software gratuit pentru utilizarea de zi cu zi Pentru mai multe informații, consultați Programele 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. Este, de asemenea, cea mai rapidă și eficientă modalitate de a contacta administratorii de proiect. Secțiunea Actualizări antivirus - mereu la zi continuă să funcționeze actualizări gratuite 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.

Firewall gratuit 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ă Instalații 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ă în 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 avertizează combinele de la Kaspersky și Eset, de exemplu, în astfel de situații. 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.

Falsificarea 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, adică iexplore.exe poate fi considerată legitimă fișier de sistem... 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 rezultate testul anterior, am căutat opțiuni suplimentare pentru a testa 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.

Primul test folosește tehnica de încărcare copie oarbă browser și corecția memoriei înainte de a-l lansa.

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ă atenție, 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ă pentru un permis software care are acces la Internet prin portul 80, apoi lansează o copie a programului permis și, chiar înainte de a începe, corecizează memoria ocupată de acest program (adică AWFT se lansează și î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 unor sedimente neplăcute din duș rămase după testarea firewall-ului, recomand în continuare Comodo Internet Securitate pentru uz casnic, dar numai 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 să prezinte un tabel gata făcut sub formă de „problemă” - „soluție”, sunt oferite 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. Limba folosită pentru configurarea filtrului de pachete este similară cu limbi 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 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. Și setul de reguli este opusul, implementarea specificației este un set instrucțiuni standard, un program executat de 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. Așa cum codul sursă este procesat și tradus în instrucțiuni de cod mașină de către compilator, " text original»Setul 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 nu a fost procesat fără o singură eroare, pfctl nu va schimba setul anterior de reguli din nucleu. Și deoarece fișierul conține unul sau mai multe erori de sintaxă, nu va exista niciun „program” pe care pf îl poate executa.

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. În 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ântul cheie „inet” trebuie să urmeze „on $ 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ă tratament special fişier:

# 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 de prizonieri în bretele() poate produce un rezultat care vă poate surprinde și, în același timp, va afișa setul de reguli procesate de analizor:

$ 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 creării ordonate a diferitelor tipuri de 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. A telul suprem proces, construiește 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 omiteți. Ș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 partea de 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, pentru porturi TCP scannerul revine „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 buna metoda se va face verificare folosind acele aplicatii care ulterior vor fi folosite de clienti. 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 programe regulate 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 programe 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 pachetele care sosesc sau pleacă ca fiind reale interfata retea precum și cele virtuale precum 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 l-ați deschis portul dorit, aceasta mai multa problema etape de proiectare mai degrabă decât un bug în reguli. 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 încercați să vă conectați la portul TCP 22, conexiunea este acceptată! 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 presupunere este că regula de blocare nu ar trebui să fie prezentă doar în set (pe care am aflat deja), ci ar trebui 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. Adăugați reguli unul câte unul, repetând testul până îl găsiți 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ă adăugând opțiunea „jurnal” la toate regulile care pot afecta și ascultând pe 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 opțiunea „păstrare stare” din regulă creează o intrare în tabelul de stări, intrarea conexiunii este salvată folosind cheia acest compus... 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. Echipamente de rețea pachetele retransmise pot fi livrate mai târziu, iar dacă sunt confundate cu pachete din conexiunea nou creată de către stiva TCP/IP a destinatarului, aceasta va împiedica sau va termina complet 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, dar destul de 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 la interfața dvs. și toate răspunsurile dvs. de ieșire ar trebui să meargă 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ță iese ș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ță. V instalatii 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 anumită interfață folosind instalare globală„Setați politica de stat dacă este legat” sau o opțiune pentru fiecare regulă „păstrați starea (dacă este legat)”. 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 diverse înregistrăriîn tabelul de stat. 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ă nu veți avea o instalare completă care include interfețe cu tunelare și erori depanate, cum ar fi „pf: src_tree insert failed”, nu veți putea considera integrarea dvs. ca fiind suficient de reușită. Să revenim la interogarea tabelului de stare pentru fiecare pachet înainte de a verifica regulile. Solicitarea trebuie să returneze o singură înregistrare cu o cheie corespunzătoare sau 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ă multe atacuri TCP în care un atacator încearcă să controleze conexiunea dintre 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 atacatorului poate fi acela de a preveni posibilitatea de a crea conexiuni între gazde sau de a întrerupe deja legături stabilite(pentru a provoca o refuz de serviciu) sau pentru 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 potrivită 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ții deja primite de gazdă nu este o încălcare a protocolului 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 autentifica cu exactitate doar 30.000 din cele 4294967296 de numere de secvență posibile la un moment dat. 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ă, la pasul următor, numerele de secvență ale pachetelor stocate în tabel sunt verificate pentru introducerea intervalului de 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ă conexiunea de ieșire implică traducerea adresei sursă, perechea din mijloc indică sursa după traducere. 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 etapa de stabilire a conexiunii, valorile mai mari - până în momentul în care conexiunea este închisă).„A” înseamnă că pachetul blocat avea setat steag-ul ACK (ca în ieșirea steagurilor pentru tcpdump), urmat de valorile numerelor de secvență (seq =) și (ack =) din pachetele blocate și încărcarea utilă. lungimea 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 cea care a determinat crearea acestei înregistrări și 631 de pachete în direcția opusă. Aceste contoare vor fi deosebit de utile atunci când căutați probleme în stadiul stabilirii unei conexiuni, dacă unul dintre ele este egal cu zero, acest lucru vă va contrazice așteptarea că pachetele care vin în ambele direcții se potrivesc cu această înregistrare.

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 mai mult valoare 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 trebuie înmulțite cu o anumită valoare dată de destinatar și nu luate de la sine. Pentru a această schemă funcționând, 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... De asemenea, este posibil să închideți complet sau să resetați conexiunile prin 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 stare 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”.

Metodologia de testare

Testarea a fost efectuată pe un PC experimental care rulează Windows cu licență XP 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ă Testele au fost o încercare de a privi Firewall-ul prin ochii unui utilizator, de a-i marca 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:
Instalare și dezinstalare probleme speciale nu provoacă

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 Internet Security 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: Instalarea nu este necesară, este un instrument standard XP. Activarea se face în setări adaptor de retea... Implicit, ICF funcționează î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ă port deschis(acest lucru este logic - pachetele de scanare de porturi nu vor fi transmise, 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 pachetele periculoase și invers, va interfera cu programele utile);
2. După configurarea Firewall și IDS, trebuie să testați- 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 sunt lipsite de context programul 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 - funcționarea Firewall-ului trebuie monitorizată și î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ță- funcția de telecomandă trebuie să fie fie dezactivată, fie protejată cu parolă.