Firewall test. Kontrol af firewalls for beskyttelse mod interne angreb

Bærbare computere er meget populære som hjemmecomputere i disse dage, da de fylder lidt og nemt kan flyttes fra rum til rum. Mange hjemmebrugere aktiverer fildeling for for eksempel at afspille digitalt indhold på deres multimediesystemer og fjernsyn.

Mange af disse brugere tager deres bærbare computere med til offentlige steder, såsom caféer, og opretter forbindelse til internettet ved hjælp af et trådløst Wi-Fi-netværk. Det er rimeligt at forvente, at når du anmoder om en firewall og vælger netværket som offentligt, skal computeren være beskyttet mod indtrængen fra andre deltagere i det åbne netværk.

Erhvervsbrugere, der bruger en bærbar computer som deres eneste arbejdscomputer, kan befinde sig i samme situation, hvor deres maskiner oftest er konfigureret til at blive styret via Microsoft Remote Desktop.

Formålet med denne test er at bestemme, hvordan de mest populære tredjeparts firewalls – selvstændige og som en del af Internet Security suiter – faktisk giver grundlæggende indgående adgangskontrol for bærbare brugere, der skifter mellem hjemmet/arbejdet og offentlige netværk.

Bemærk venligst, at testens omfang naturligvis er meget begrænset, og derfor betyder et godt resultat i denne test ikke, at produktet giver komplet netværkssikkerhed.

Test blev udført i januar 2014 efter ordre fra CHIP Online magazine (Tyskland). De anvendte firewallversioner var tilgængelige fra den 13. januar 2014.

Firewall test procedure

Test-pc'en er forbundet til internettet via trådløst lokalt netværk(WLAN) ved hjælp af en netværksforbindelse, der er defineret som Privat i Windows Network and Sharing Center (WNSC).

Testversionen af hvert produkt tilgængelig fra den 13. januar 2014 er installeret med standardindstillinger, og testcomputeren genstartes. Hvis selve produktet beder brugeren om at definere den aktuelle netværkstype som Privat/Trusted, vil denne mulighed blive valgt. Hvis produktet har en opdateringsfunktion, udføres den. Bekræfter, at produktet er registreret hos centret Windows support som system firewall, og selve produktet viste, at det fungerede som forventet. Brug en anden pc til at teste forbindelsen på et eksisterende privat netværk på følgende måde:

Ping værtsnavn -4
Ping værtsnavn -6
Ping IPv4-adresse
Ping IPv6-adresse
Fildeling værtsnavn
Fildelings IPv4-adresse
Remote Desktop (RDP) værtsnavn
Remote Desktop (RDP) IPv4-adresse
Remote Desktop (RDP) IPv6-adresse

Alle disse former for fjernadgang er verificeret til at virke for at sikre fuld funktionalitet af test-pc'en på det private netværk og maksimal kontrol over den. Herefter slukkes computeren og routeren, som den var tilsluttet, og pc'en starter igen. Det opretter derefter forbindelse til et andet WLAN, som er defineret som offentligt i WNSC, ved hjælp af Windows Firewall-dialogboksen.

Hvis firewallen viser sin anmodning om at bestemme netværkstypen, er den indstillet til "Public" eller "Untrusted". Der foretages ingen yderligere ændringer i produktopsætningen.

Denne procedure modellerer den typiske adfærd for en bærbar bruger, der flytter fra hjemmet/kontoret til et offentligt netværk i en café, lufthavn eller hotel. Efter at computeren er tilsluttet det nye offentlige trådløse netværk, udføres de samme tests som ved tilslutning til et privat netværk. Denne gang forventes alle forbindelsesforsøg at mislykkes, da computeren skal beskyttes mod enhver ekstern detektering og adgang på et offentligt netværk.

Testmetode

Testen blev udført på en eksperimentel pc, der kører licenseret Windows XP med SP1 installeret (testen blev udført under idealiserede forhold - "operativsystem + Firewall" for at udelukke indflydelsen fra andre programmer på forsøgets renhed). APS-værktøjet blev brugt som en indikator for vellykket adgang til tjenester. Følgende eksterne påvirkninger blev brugt:

scanner XSpider 6.5 og 7.0
Retina Network Security Scanner 4.9
flere scannere af mit design.

Derudover blev CommView 4.1 snifferen brugt (som et middel til at overvåge netværkstrafik og som et værktøj til at generere og sende pakker med forskellige uregelmæssigheder i strukturen). Den såkaldte oversvømmelser af almindelige typer, hjælpeprogrammer til simulering af trojanske programmer.

På test-pc'en blev IE 6, Outlook Express 6, TheBat 1.60, MSN Messanger 6.1 brugt til at få adgang til netværket og internettet. Ud over dem involverede testen simulatorer af trojanske programmer og rigtige trojanske/bagdørsprogrammer fra min samling (især Backdoor.Antilam, Backdoor.AutoSpy, Backdoor.Death, Backdoor.SubSeven, Backdoor.Netbus, Backdoor.BO2K), netværk / e-mail-virus (I-Worm.Badtrans, I-Worm.NetSky, I-Worm.Sircam, I-Worm.Mydoom, I-Worm.MSBlast), Trojan Downloader-downloadere (især TrojanDownloader.IstBar) og SpyWare-komponenter. Hovedopgaven for testene var at prøve at se på Firewall'en gennem brugerens øjne, for at notere dens styrker og svagheder fra mit synspunkt.

Kerio Technologies WinRoute Pro v4.2.5

Installation og afinstallation:
Det går uden problemer.
Installation med standardindstillinger, ingen regler - kun NAT er gyldig. Arbejder på netværket - ingen problemer, scanningsresultater - APS viser ikke en alarmtilstand, scanneren mener, at alle porte er lukkede. Winroute selv udsender ikke alarmer og identificerer ikke visuelt scanningen.

Outpost Firewall Pro 2.1 Build 303.4009 (314)

Installation og afinstallation:
Installation under XP forløber uden problemer; ved opstart er træningstilstanden aktiveret.

ZoneLabs ZoneAlarm Pro med webfiltrering 4.5.594.000 - Personal Firewall

Installation og afinstallation:
Under installationen gik XP ned, mens han forsøgte at starte efter installationen. Efter genstart fungerede alt fint.

AtGuard 3.22>

Installation og afinstallation:
Installation og afinstallation giver ingen særlige problemer

Fordele:

Lille i størrelsen Firewall, har interessant løsning fra et interface synspunkt - det er designet som et panel placeret øverst på skærmen

Ulemper og funktioner:

I træningstilstand er den sårbar - fra det øjeblik anmodningen om at oprette en regel udstedes, til den er oprettet, sender den pakker i begge retninger
Grænsefladen er lidt glitchy, når du gentegner vinduer

Samlet bedømmelse:
Simpel firewall, men ret funktionel

Kerio Personal Firewall 4

Installation og afinstallation:
Installationen forløber uden problemer, fjernelsen er "ren" - ingen problemer blev bemærket efter afinstallationen.

Norton Internet Security 2004 (NIS)

Installation og afinstallation: Installationen giver ikke problemer, men af alle de analyserede er installationsprogrammet det mest besværlige.

Internet Connection Firewall, ICF - indbygget Windows firewall XP

Installation og afinstallation: Ingen installation nødvendig, det er et standard XP-værktøj. Aktivering udføres i netværksadapterindstillingerne. Som standard fungerer ICF i maksimal sikkerhedstilstand, og (dette er resultatet af min observation) princippet for dets funktion er som følger: applikationsanmodninger frigives eksternt, og kun pakker, der kommer som svar på mine anmodninger, modtages eksternt (anmodningen -svarkorrespondance opretholdes tydeligt i form af en dynamisk tabel). Når der scannes porte på en computer med ICF aktiveret, er der således ikke en enkelt åben port (dette er logisk - portscannerpakker vil ikke blive savnet, da ingen anmodede om dem). Situationen er den samme med forskellige slags "atomvåben" baseret på afsendelse af ikke-standardpakker

Internet Connection Firewall, ICF - indbygget firewall til Windows XP SP2

Installation og afinstallation: Ingen installation nødvendig, det er et standard XP-værktøj (inkluderet i SP2 til XP). Aktivering udføres i netværksadapterindstillingerne. Det skal bemærkes, at ved installation af SP2 eller ved installation af XP med integreret SP2, udover Firewall, vises et sikkerhedscenter i systemet, som kan vise ICF-indstillinger

Sygate Personal Firewall Pro 5.5 build 2525

Installation og afinstallation:

ISS BlackIce 3.6.cci

Installation og afinstallation: Installation og afinstallation af programmet sker uden problemer, men under installationen opstår der en fejl i ikernel-biblioteket. Den samme fejl opstod under afinstallationen. Forekomsten af denne fejl påvirker ikke processen med at installere og afinstallere programmet. Installationsprogrammet krævede ikke en systemgenstart, hvilket er usædvanligt for Firewall

Visnetic Firewall 2.2

Installation og afinstallation: Installation og afinstallation af programmet sker uden problemer. Efter installationen er en genstart påkrævet.

Look n stop personlig firewall 2.05

Installation og afinstallation: Installation og afinstallation af programmet sker uden problemer. Efter installationen er en genstart påkrævet. Den installerer sin egen driver for at virke.

Kaspersky AntiHacker 1.5

Installation og afinstallation: Installation og afinstallation af programmet sker uden problemer. Efter installationen er en genstart påkrævet.

Tiny Personal Firewall Pro 6.0

Installation og afinstallation:
Installation og afinstallation af programmet sker uden problemer. Efter installationen er en genstart påkrævet.

McAfee Personal Firewall Plus 6.0 Build 6014

Installation og afinstallation:
Installation og afinstallation af programmet sker uden problemer. Efter installationen er en genstart påkrævet.

R-Firewall 1.0 Build 43

Installation og afinstallation:
Installation og afinstallation af programmet sker uden problemer. Størrelsen på distributionen er lille (3,8 MB), du kan tilpasse sammensætningen af produktet. Arbejdet er ret stabilt, ingen tydelige nedbrud eller frysninger blev bemærket på reference-pc'en

Generelle konklusioner og konklusion

Så lad os opsummere testresultaterne. Faktisk bekræftede testene mine teoretiske ideer om problemets tilstand:

Firewall skal konfigureres. Alle testede firewalls fungerede godt, men kun efter konfiguration (træning, oprettelse af indstillinger manuelt - det gør ikke noget). Brug af en ukonfigureret firewall kan forårsage mere skade end gavn (det vil tillade farlige pakker igennem og vil omvendt forstyrre nyttige programmer);
Efter opsætning af Firewall og IDS skal du teste- Det er også en ret indlysende konklusion, men ikke desto mindre er den vigtig. Jeg tog det første skridt mod at oprette en tester - dette er APS-værktøjet. Der er to mere tilbage - en trojansk programsimulator (dvs. et værktøj, der vil udføre sikre forsøg for brugeren på at "bryde" firewallen indefra (naturligvis vil angrebene blive beskrevet af databasen og vil blive udført hos brugeren kommando under hans kontrol), som giver dig mulighed for at observere reaktionen Firewall og IDS) og et værktøj til hurtig portscanning og udførelse af grundlæggende angreb (i det væsentlige er APS præcis det modsatte - de kan have en fælles portbase). Jeg er allerede ved at udvikle disse værktøjer - deres tilstedeværelse i brugerens arsenal vil give mulighed for en form for "instrumentel kontrol".
Personal Firewall er sårbar over for malware, der kører fra konteksten af nyttige programmer. Konklusion - i det mindste væk med de forskellige "venstre" paneler og andre BHO'er fra browseren og e-mailen!! Før du installerer et plugin, panel, udvidelsesværktøj osv. du skal tænke ti gange over deres nødvendighed, fordi... de er ikke separate processer operativ system og arbejde ud fra forældreprogrammets kontekst. Det trojanske program opdages let af en personlig firewall - det "ser", at en bestemt proces (f.eks. bo2k.exe) forsøger at begynde at lytte på port xxxxx eller kommunikere med en bestemt vært - en anmodning om tilladelse udstedes, brugeren begynder at finde ud af, hvilken slags "bo2k.exe" det er " og Backdoor er fanget. Men hvis det trojanske program fungerede fra browserens kontekst, så ville næsten helt sikkert ingen være opmærksomme på browserens adgang til internettet. Sådanne trojanske programmer findes, det nærmeste eksempel er TrojanDownloader.IstBar - det er installeret nøjagtigt som et IE-panel (naturligvis er det ikke i processer, og det er heller ikke i autorun-listen);
Mange personlige firewalls er synlige som operativsystemprocesser og kan stoppes af en virus. Konklusion - Firewall'ens arbejde skal overvåges, og dets pludselige afslutning kan tjene som et signal om, at en virus er trængt ind i pc'en;
Nogle firewalls (for eksempel Kerio) tillader fjernbetjening- fjernbetjeningsfunktionen skal enten være deaktiveret eller beskyttet med adgangskode.

Denne anden artikel beskriver, hvordan du løser problemer med pakkefilteret. I stedet for at præsentere en færdig tabel i form af "problem" - "løsning", gives der metoder til en systematisk tilgang til løsning af de opståede problemer.

Denne anden artikel (i en serie på tre) beskriver, hvordan man løser pakkefilterproblemer. I stedet for at præsentere en færdig tabel i form af "problem" - "løsning", gives der metoder til en systematisk tilgang til løsning af de opståede problemer.

Introduktion

Et pakkefilter implementerer en filtreringspolitik ved at omgå et sæt regler og blokerer eller videregiver følgelig pakker. Kapitlet forklarer, hvordan man verificerer, at filtreringspolitikken implementeres korrekt, og hvordan man finder fejl, hvis den ikke er det.

Generelt vil vi i dette kapitels forløb sammenligne opgaven med at skrive et sæt filtreringsregler med programmering. Hvis du ikke har programmeringsevner, vil denne sammenligning virke ret kompliceret for dig. Men skriveregler i sig selv kræver ikke tilstedeværelsen akademisk grad i "datalogi" eller programmeringserfaring, ikke?

Svaret er nej, det behøver du nok ikke. Sproget, der bruges til at konfigurere pakkefilteret, ligner menneskelige sprog. For eksempel:

blokere alle

besvime alle holde tilstand

videregive i proto tcp til enhver port www behold tilstand

Faktisk behøver du ikke at have en programmør i nærheden for at forstå, hvad dette sæt gør, eller endda ved hjælp af intuition at skrive en lignende filtreringspolitik. Der er endda en stor chance for, at et sæt filtreringsregler, der er oprettet i denne lighed, vil udføre de handlinger, som dets forfatter havde i tankerne.

Desværre gør computere kun, hvad du beder dem om, ikke hvad du vil have dem til at gøre. Værre endnu, vil de ikke være i stand til at skelne det ønskede fra det faktiske, hvis der er en sådan forskel. Det betyder, at hvis computeren ikke gør, hvad du vil korrekt, selvom du synes, du har beskrevet instruktionerne klart, er det i dine hænder at finde forskellene og ændre instruktionerne. Og da dette er almindeligt problem i programmering kan vi se på, hvordan programmører håndterer dette. Det er her, det viser sig, at de færdigheder og metoder, der bruges til at teste og fejlfinde programmer og filtreringsregler, er meget ens. Og dog her behøver du ikke kendskab til noget programmeringssprog for at forstå implikationerne for test og fejlretning.

God filtreringspolitik.

En filtreringspolitik er en uformel specifikation af, hvad vi ønsker fra en firewall. Tværtimod er et sæt regler, en implementering af en specifikation, et sæt standardinstruktioner, et program, der udføres af en maskine. For at skrive et program skal du derfor bestemme, hvad det skal gøre.

Så det første trin i firewall-konfigurationen er uformelt at specificere, hvad du vil opnå. Hvilke forbindelser skal blokeres eller tillades igennem?

Et eksempel ville være:

Der er tre netværk, der skal adskilles fra hinanden af en firewall. Alle forbindelser fra et netværk til et andet går gennem en firewall. Firewallen har 3 grænseflader, som hver er forbundet til det tilsvarende netværk:

$ext_if - til det eksterne netværk.

$dmz_if - DMZ med servere.

$lan_if - LAN med arbejdsstationer.

Værter på LAN'et skal være frie til at oprette forbindelse til alle værter i DMZ-netværket eller det eksterne netværk.

Servere i DMZ'en skal kunne kommunikere frit med værter på det eksterne netværk. Eksterne netværksværter kan kun oprette forbindelse til følgende servere i DMZ:

Webserver 10.1.1.1 port 80

Mailserver 10.2.2.2 port 25

Alle andre forbindelser bør forbydes (f.eks. fra maskiner på det eksterne netværk til maskiner på LAN).

Denne politik er udtrykt uformelt, så alle, der læser den, kan forstå den. Den skal være så specifik, at læseren nemt kan formulere svar på et spørgsmål som 'Skal en forbindelse fra vært X til vært Y tillades indgående (eller udgående) på grænseflade Z?'. Hvis du spekulerer på, om din politik ikke opfylder dette krav, er det fordi den ikke er veldefineret.

"Vage" politikker som "tillad kun alt, hvad der er vigtigt" eller "bloker angreb" skal præciseres, ellers vil du ikke være i stand til at anvende eller verificere dem. Som i softwareudvikling fører dårligt formaliserede opgaver sjældent til berettigede eller korrekte implementeringer. ("Hvorfor går du ikke i gang med at skrive kode, mens jeg finder ud af, hvad kunden har brug for").

Et sæt regler, der implementerer en politik

Regelsættet er skrevet som en tekstfil, der indeholder sætninger på et formelt sprog. Ligesom kildekoden behandles og oversættes til maskinkodeinstruktioner af compileren, behandles regelsættets "kildetekst" af pfctl, og resultatet fortolkes af pf i kernen.

Når kildekoden bryder reglerne formelt sprog, rapporterer analysatoren en syntaksfejl og nægter at behandle filen yderligere. Denne fejl er en kompileringsfejl og kan normalt rettes hurtigt. Når pfctl ikke kan parse din regelsætfil, udskriver den en linje, der indeholder en fejl og en mere eller mindre informativ besked om, hvad den ikke kunne parse. Indtil hele filen er behandlet uden en enkelt fejl, vil pfctl ikke ændre det tidligere sæt regler i kernen. Og da filen indeholder en eller flere syntaksfejl, vil der ikke være noget "program", som pf kan udføre.

Den anden type fejl kaldes "run-time errors", fordi den opstår, når et syntaktisk korrekt skrevet program er succesfuldt oversat og eksekveret. Generelt i programmeringssprog kan dette ske, når et program dividerer med nul, forsøger at få adgang til ugyldige hukommelsesområder eller løber tør for hukommelse. Men da regelsættene kun vagt minder om funktionaliteten af programmeringssprog, kan de fleste af disse fejl ikke opstå under anvendelsen af reglerne, for eksempel kan reglerne ikke forårsage den såkaldte. "systemnedbrud", som normale programmer gør. Et sæt regler kan dog forårsage lignende fejl i form af blokering eller omvendt videregivelse af pakker, der ikke overholder politikken. Dette kaldes nogle gange en logisk fejl, en fejl, der ikke kaster en undtagelse eller stopper, men blot producerer forkerte resultater.

Så før vi kan begynde at kontrollere, om firewallen implementerer vores sikkerhedspolitik korrekt, skal vi først indlæse regelsættet.

Analysator fejl

Analysatorfejl opstår, når du forsøger at indlæse en liste over regler ved hjælp af pfctl, for eksempel:

# pfctl -f/etc/pf.konf

/ etc/pf.conf:3:syntaksfejl

Denne meddelelse indikerer, at der er en syntaksfejl på linje 3 i /etc/pf.conf, og pfctl kan ikke indlæse reglerne. Sættet i kernen er ikke ændret, det forbliver det samme som før forsøg på at indlæse en ny.

Der er mange typer fejl produceret af pfctl. For at komme i gang med pfctl skal du bare læse dem omhyggeligt. Måske vil ikke alle dele af beskeden afsløre deres betydning for dig med det samme, men du skal læse dem alle, fordi... Dette vil gøre det lettere at forstå, hvad der gik galt senere. Hvis en meddelelse indeholder en del af formen "filnavn:nummer:tekst", refererer den til linjen med det tilsvarende nummer i den angivne fil.

Det næste trin er at se på outputlinjen ved hjælp af en teksteditor (i vi kan du gå til linje 3 ved at skrive 3G i bip-tilstand), eller sådan:

# kat -n /etc/pf.conf

1 int_if = "fxp 0"

2 blokke alle

3 besvime på $int_if inet all kep tilstand

besvime inet på $int_if all kep tilstand

Problemet kan være en simpel tastefejl, som i dette tilfælde ("behold" i stedet for "behold"). Efter at have rettet, prøv at genindlæse filen:

# pfctl -f/etc/pf.konf

/ etc/pf.conf:3:syntaksfejl

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

pass out inet på $int_if all keep state

Nu er alle søgeord korrekte, men ved nærmere eftersyn bemærker vi, at placeringen af søgeordet "inet" før "on $int_if" er forkert. Dette illustrerer, at den samme linje kan indeholde mere end én fejl. Pfctl udskriver den første fejl, den finder, og stopper med at udføre. Hvis det samme linjenummer blev udstedt ved genstart, betyder det, at der stadig er fejl i det, eller at de tidligere ikke blev rettet korrekt.

Forkert placerede søgeord er også en almindelig fejl. Dette kan afsløres ved at sammenligne reglen med reference-BNF-syntaksen i slutningen af man pf.conf(5) hjælpefilen, som indeholder:

pf-rule= handling [ ("ind" | "ud") ]

["log" | "log-alle" ] [ "hurtig" ]

[ "på" ifspec ] [ rute ] [ af ] [ protospec ]

værter [filteropt-liste]

ifspec = ([ "!" ] grænsefladenavn) | "(" interface-liste ")"

af = "inet" | "inet 6"

Hvad betyder det søgeord"inet" skal følge "på $int_if"

Lad os rette det og prøve igen:

# pfctl -f/etc/pf.konf

/ etc/pf.conf:3:syntaksfejl

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

gå ud på $int_if inet all keep state

Der er ingen åbenlyse fejl tilbage nu. Men vi kan ikke se alle de medfølgende detaljer! Linjen afhænger af makrodefinitionen $inf_if. Hvad kan være forkert defineret?

# pfctl -vf /etc/pf.conf

int_if = "fxp 0"

blok drop alle

/etc/pf.conf:3: syntaksfejl

Efter at have rettet tastefejlen "fxp 0" til "fxp0", prøv igen:

# pfctl -f/etc/pf.konf

Fraværet af meddelelser indikerer, at filen blev downloadet.

I nogle tilfælde kan pfctl producere fejlmeddelelser, der er mere specifikke end blot "syntaksfejl":

# pfctl -f /etc/pf.conf

/etc/pf.conf:3: port gælder kun for tcp/udp

/etc/pf.conf:3: overspringsregel på grund af fejl

/etc/pf.conf:3: regel udvides til ingen gyldig kombination

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

gå ud på $int_if til port ssh keep state

Den første linje i fejlmeddelelsen er den mest informative sammenlignet med resten. I dette tilfælde er problemet, at reglen, når porten specificeres, ikke specificerer protokollen - tcp eller udp.

I sjældne tilfælde kan pfctl blive forvirret af tilstedeværelsen af uudskrivbare tegn eller unødvendige mellemrum i en fil, sådanne fejl opdages ikke let uden særlig behandling af filen:

# pfctl -f /etc/pf.conf

/etc/pf.conf:2: mellemrum efter \

/etc/pf.conf:2: syntaksfejl

# cat -ent /etc/pf.conf

1 blok alle $

2 besvimer på gem0 fra enhver til enhver \ $

3 ^ Jeg beholderstat$

Problemet her er mellemrumstegnet efter omvendt skråstreg, men før slutningen af anden linje, angivet med "$" tegnet i outputtet af cat -e.

Når regelsættet er blevet indlæst, ville det være rart at se på resultatet:

$ kat /etc/pf.conf

blokere alle

# pass fra enhver til enhver \

passere fra 10.1.2.3 til evt

$ pfctl -f /etc/pf.conf

$ pfctl -sr

blokdråbealle

Et "omvendt skråstreg" i slutningen af en kommentarlinje betyder faktisk, at kommentarlinjen fortsætter nedenfor.

Udvidelse af lister omsluttet af krøllede seler () kan give et resultat, der kan overraske dig, og samtidig vise det regelsæt, der behandles af analysatoren:

$ kat /etc/pf.conf

overgå fra ( !10.1.2.3, !10.2.3.4 ) til evt.

$ pfctl -nvf /etc/pf.conf

videregive internet fra ! 10.1.2.3 til evt

videregive internet fra ! 10.2.3.4tilnogen

Fangsten her er, at udtrykket "(!10.1.2.3, !10.2.3.4 )" ikke vil betyde "alle adresser undtagen 10.1.2.3 og 10.2.3.4", selve det udvidede udtryk betyder at matche enhver mulig adresse.

Du bør genindlæse dit regelsæt efter at have foretaget permanente ændringer for at sikre, at pfctl kan indlæse det, når maskinen genstartes. På OpenBSD indlæser rc-startscriptet i /etc/rc først et lille standardsæt af regler, der blokerer al trafik undtagen hvad der er nødvendigt under opstartsfasen (såsom dhcp eller ntp). Hvis scriptet ikke er i stand til at indlæse det rigtige regelsæt fra /etc/pf.conf på grund af syntaksfejl introduceret før maskinen blev genstartet uden kontrol, så forbliver standardsættet aktivt. Heldigvis tillader dette sæt indgående ssh-forbindelser, så problemet kan løses eksternt.

Afprøvning

Da vi har en ekstremt præcist defineret politik og et sæt regler, der skal implementere den, vil begrebet test i vores tilfælde betyde, at det resulterende sæt overholder den givne politik.

Der er kun to måder, hvorpå regler kan fungere forkert: blokering af forbindelser, der bør tillades, og omvendt, tilladelse af forbindelser, der bør blokeres.

Test indebærer generelt en systematisk tilgang til den velordnede skabelse af forskellige typer forbindelser. Det er umuligt at kontrollere alt mulige kombinationer kilde/modtager og tilsvarende porte på interfaces, fordi en firewall kunne teoretisk set støde på et stort antal af sådanne kombinationer. At sikre den indledende rigtighed af et sæt regler kan kun sikres for meget simple sager. I praksis er den bedste løsning at oprette en liste over testforbindelser baseret på sikkerhedspolitikken, således at hvert politikpunkt påvirkes. Så for vores eksempelpolitik vil listen over test være som følger:

Forbindelse fra LAN til DMZ (skal springes over)

fra LAN til eksternt netværk (skal springes over)

fra DMZ til LAN (skal være blokeret)

fra DMZ til eksternt netværk (skal springes over)

fra eksternt netværk til DMZ til 10.1.1.1 på port 80 (skal springes over)

fra eksternt netværk til DMZ til 10.1.1.1 på port 25 (skal være blokeret)

fra det eksterne netværk til DMZ til 10.2.2.2 på port 80 (bør være blokeret)

fra eksternt netværk til DMZ til 10.2.2.2 på port 25 (skal springes over)

fra eksternt netværk til LAN (skal være blokeret)

Det forventede resultat skal defineres i denne liste, før testen begynder.

Dette lyder måske mærkeligt, men formålet med hver test er at finde fejl i implementeringen af et sæt firewall-regler og ikke blot angive deres fravær. Og det ultimative mål med processen er at opbygge et sæt regler uden fejl, så hvis du tror, der kan være fejl, er du bedre stillet at finde dem end at gå glip af dem. Og hvis du påtager dig rollen som tester, bør du overholde en destruktiv tankegang og forsøge at omgå firewall-begrænsningerne. Og kun det faktum, at begrænsningerne ikke kan brydes, vil være en begrundet bekræftelse på, at regelsættet ikke indeholder fejl.

TCP- og UDP-forbindelser kan kontrolleres ved hjælp af nc. nc kan bruges som både en klient og en server (ved hjælp af -l-indstillingen). Og for ICMP-anmodninger og -svar er den bedste klient at tjekke ping.

For at kontrollere, om en forbindelse er blokeret, kan du bruge ethvert middel, der forsøger at oprette forbindelser til serveren.

Ved at bruge værktøjer til portindsamling som nmap kan du nemt scanne flere porte, selv på tværs af flere værter. Hvis resultaterne ikke ser helt klare ud, så tag et kig på man-siden. For en TCP-port returnerer scanneren f.eks. værdien 'ufiltreret', når nmap modtager en RST fra pf. Pf installeret på samme maskine som scanneren kan også påvirke den korrekte drift af nmap.

Mere sofistikerede scanningsværktøjer kan omfatte værktøjer til at skabe fragmenterede eller forkerte IP-pakker.

For at verificere, at filteret sender forbindelser, der er angivet i politikken, er den bedste metode at kontrollere ved hjælp af de applikationer, som efterfølgende vil blive brugt af klienter. Det vil således være bedre at kontrollere passage af http-forbindelser fra forskellige webserver-klientmaskiner, samt fra forskellige browsere, og sample forskelligt indhold end blot at bekræfte etableringen af en TCP-session til nc, der fungerer som en serverdel. Forskellige faktorer, såsom værtsoperativsystemet, kan også forårsage fejl - problemer med TCP-vindueskalering eller TCP SACK-svar mellem visse operativsystemer.

Når det næste testpunkt er bestået, er dets resultater muligvis ikke altid det samme. Forbindelsen kan blive afbrudt under, hvis firewallen returnerer RST. Forbindelsen kan simpelthen mislykkes på grund af en timeout. Forbindelsen kan være fuldt etableret og fungere, men efter et stykke tid kan den fryse eller gå i stykker. Forbindelsen kan holde, men gennemløb eller latens kan være anderledes end forventet, højere eller lavere (i tilfælde af at du bruger AltQ til at begrænse båndbredden).

Som forventede resultater kan du udover at springe/blokere forbindelsen også notere, om pakker logges, hvordan de oversættes, rutes, og om de nødvendige tællere øges, hvis det er nødvendigt. Hvis disse aspekter er vigtige for dig, så skal de også indgå i testmetoden.

Din politik kan omfatte krav relateret til ydeevne, reaktion på overbelastninger og fejltolerance. Og de kan kræve separate tests. Hvis du opsætter et fejltolerant system ved hjælp af CARP, vil du sikkert gerne vide, hvad der sker under forskellige typer fejl.

Når du observerer et resultat, der er forskelligt fra det, du forventede, skal du notere dine trin under testen trin for trin, hvad du forventede, hvorfor du forventede det, det resultat du fik, og hvordan resultatet afveg fra dine forventninger. Gentag testen for at se, om situationen er den samme eller forskellig fra gang til gang. Prøv at ændre inputparametrene for testen (kilde/destinationsadresse eller porte).

Fra det øjeblik, du har et reproducerbart problem, skal du begynde at fejlfinde for at finde ud af, hvorfor tingene ikke fungerer, som du forventede, og hvordan du "retter" tingene. Med denne opsætning skal du ændre regelsættet og gentage alle tests, inklusive dem der ikke gav fejl, fordi du ved at ændre reglerne utilsigtet kunne påvirke driften af gyldige dele af regelsættet.

Det samme princip gælder for andre ændringer foretaget på sættet. Sådan formel procedure kontrol vil hjælpe med at gøre processen mindre tilbøjelig til at introducere fejl. Små ændringer kræver muligvis ikke at gentage hele proceduren, men summen af flere små ændringer kan påvirke samlet resultat sæt behandling. Du kan bruge et versionskontrolsystem såsom cvs til at arbejde med din konfigurationsfil, fordi... dette vil hjælpe med at undersøge de ændringer, der førte til fejlen. Hvis du ved, at en fejl ikke skete for en uge siden, men det gør den nu, vil det hjælpe dig med at se problemet, eller i det mindste rulle tilbage til det punkt, hvor det skete, hvis du ser på alle de ændringer, du har foretaget i løbet af den sidste uge. eksisterer ikke.

Ikke-trivielle regelsæt kan opfattes som programmer; de er sjældent perfekte i deres første version, og det tager tid at være sikker på, at de er fri for fejl. Men i modsætning til almindelige programmer, som aldrig anses for fejlfrie af de fleste programmører, er regelsæt stadig enkle nok til at være tæt på denne definition.

Fejlretning

Udtrykket debugging refererer normalt til at finde og eliminere programmeringsfejl i computerprogrammer. Eller i forbindelse med firewall-regelsæt vil udtrykket referere til processen med at finde årsagen til, at sættet ikke returnerer det ønskede resultat. Der er få typer fejl, der kan forekomme i reglerne, men metoderne til at finde dem ligner programmering.

Før du begynder at lede efter årsagen til problemet, skal du klart forstå problemets karakter. Hvis du selv bemærker fejlen under test, er det meget enkelt. Men hvis en anden person rapporterer en fejl til dig, kan det være en udfordring at skabe et klart mål ud fra en upræcis fejlrapport. Det bedste sted at starte er ved selv at gengive fejlen.

Netværksproblemer er muligvis ikke altid forårsaget af et pakkefilter. Før du fokuserer din opmærksomhed på at fejlfinde pf-konfigurationen, skal du sikre dig, at problemet er forårsaget af pakkefilteret. Dette er nemt at gøre og vil også spare tid på at søge efter problemet andre steder. Du skal blot slå pf fra med pfctl -d og kontrollere, om problemet opstår igen. Hvis ja, aktiver pf med pfctl -e og se, hvad der sker. Denne metode vil ikke fungere i nogle tilfælde, for eksempel, hvis pf ikke udfører netværksadresseoversættelse (NAT) korrekt, så vil det naturligvis ikke slippe af med fejlen, hvis pf slås fra. Men i de tilfælde, hvor dette er muligt, så prøv at sikre dig, at det er pakkefilteret, der er skyld i.

Derfor, hvis problemet er i pakkefilteret, er den første ting, du skal gøre, at sikre dig, at pf virkelig fungerer, og at det påkrævede regelsæt er indlæst:

# pfctl -si | grep Status

Status: Aktiveret i 4 dage 13:47:32 Fejlretning: Haster

# pfctl -sr

kom hurtigt videre lo0 alle

videregive hurtigt enc0 alle

Debugging ved hjælp af protokoller

Det næste fejlfindingstrin er at lokalisere problemet til specifikke netværksforbindelser. Hvis du har meddelelsen: "Instant messaging i applikation X fungerer ikke", skal du finde ud af, hvilke netværksforbindelser der bruges. Konklusionen kan være noget i retning af "vært A kan ikke etablere en forbindelse til vært B på port C." Nogle gange er denne opgave den sværeste, men hvis du har information om de nødvendige forbindelser, og du ved, at firewallen ikke tillader dem, behøver du kun at ændre reglerne for at løse dette problem.

Der er flere måder at finde ud af, hvilke protokoller eller forbindelser et program bruger. Tcpdump kan vise pakker, der ankommer eller forlader både en rigtig netværksgrænseflade og virtuelle pakker såsom pflog og pfsync. Du kan definere et filterudtryk for at angive, hvilke pakker der skal vises, og eliminere fremmed netværksstøj. Prøv at etablere en netværksforbindelse i det ønskede program og se på de pakker, der sendes. For eksempel:

# tcpdump -nvvvpi fxp0 tcp og ikke port ssh og ikke port smtp

23:55:59.072513 10.1.2.3.65123 > 10.2.3.4.6667: S

4093655771:4093655771(0) vinde 5840

1039287798 0,nop,wscale 0> (DF)

Dette er en TCP SYN-pakke, den første pakke i et TCP-håndtryk.

Afsenderen er 10.1.2.3 port 65123 (ligner en tilfældig uprivilegeret port), og modtageren er 10.2.3.4 port 6667. En detaljeret forklaring af tcpdump outputformatet kan findes på hjælpeprogrammets manualsider. Tcpdump er det vigtigste værktøj til at fejlfinde pf-relaterede problemer, og det er meget vigtigt at blive fortrolig med det.

En anden metode er at bruge pf's logfunktion. Forudsat at du bruger 'log' muligheden i alle regler med 'blok', så vil alle pakker blokeret af pf blive afspejlet i loggen. Det er muligt at fjerne 'log' muligheden fra regler, der omhandler kendte protokoller, f.eks. Kun de pakker, der går til ukendte porte, vil blive registreret i loggen. Prøv at bruge programmet, der ikke kan oprette forbindelse og se pflog:

# ifconfig pflog0 op

# tcpdump -netti pflog0

26. nov 00:02:26.723219 regel 41/0(match): bloker ind på cue0:

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

16384 (DF)

Hvis du bruger pflog, en dæmon, der konstant lytter til pflog0 og gemmer den modtagne information i /var/log/pflog, kan du se den gemte information sådan:

# tcpdump -nettr/var/log/pflog

Når du udsender gemte pf-pakker, kan du bruge yderligere filtreringsudtryk, for eksempel se på pakker, der blev blokeret ved indgangen på wi0-grænsefladen:

# tcpdump -netttr /var/log/pflog indgående og handlingsblok og på wi0

Nogle protokoller, såsom FTP, er ikke så nemme at spore, fordi de ikke bruger faste portnumre eller bruger flere sameksisterende forbindelser. Det er muligvis ikke muligt at få dem gennem firewallen uden at åbne en lang række porte. For individuelle protokoller er der løsninger, der ligner ftp-proxy.

Debugging regler

Hvis dit regelsæt blokerer en bestemt protokol, fordi du ikke har åbnet den korrekte port, er det større problem designstadiet frem for en fejl i reglerne. Men hvad hvis du ser, at en forbindelse, som du har en regel, der tillader det, er blokeret?

For eksempel indeholder dit sæt reglen

bloker i return-rst på $ext_if proto tcp fra enhver til $ext_if port ssh

Men når du forsøger at oprette forbindelse til TCP-port 22, accepteres forbindelsen! Det ser ud til, at firewallen ignorerer din regel. Ligesom at lægge et puslespil, er der en simpel logisk og normalt triviel forklaring på disse ting de første par gange, du støder på dem.

Først bør du tjekke alle de trin, der er nævnt tidligere. Lad os for eksempel antage, at firewall'en kører og indeholder reglen ovenfor. Det er usandsynligt, at vores tidligere bekymringer er sande, men det er nemt at kontrollere:

# pfctl -si | grep Status

Status: Aktiveret i 4 dage 14:03:13 Fejlretning: Haster

# pfctl -gsr | grep "port=ssh"

@14 blok retur-rst ind på kue0 inet proto tcp fra enhver til 62.65.145.30 port = ssh

Den næste ting vi har er: TCP-forbindelser accepteres på port 22 på kue0. Du tror måske, at dette allerede er indlysende, men det ville være værd at tjekke. Kør tcpdump:

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

Prøv nu SSH-forbindelsen igen. Du bør se pakker fra din forbindelse i tcpdump output. Du kan muligvis ikke se dem, og det kan skyldes, at forbindelsen faktisk ikke går gennem kue0, men går gennem en anden grænseflade, hvilket forklarer, hvorfor reglen ikke udløses. Eller du opretter forbindelse til en anden adresse. Kort sagt, hvis du ikke ser ssh-pakker, så vil pf heller ikke se dem, og det kan muligvis ikke blokere dem ved at bruge reglen i vores problem.

Men hvis du ser pakker, der bruger tcpdump, vil pf også "se" dem og filtrere dem. Den næste antagelse er, at blokeringsreglen ikke kun skal være til stede i sættet (som vi allerede har etableret), men skal være den sidste matchningsregel for de ønskede pakker. Hvis dette ikke er den endelige regel, er beslutningen om at holde pakker naturligvis ikke truffet i henhold til denne.

I hvilke tilfælde er en regel muligvis ikke den sidste matchende regel? Der er tre mulige årsager:

A) reglen virker ikke, da visning af reglerne ikke når, hvad vi har brug for.

Den tidligere nuværende regel udløses også og får eksekveringen til at afslutte med muligheden 'hurtig';

B) reglen er behandlet, men reglen virker ikke på grund af uoverensstemmelse mellem individuelle kriterier.

C) reglen behandles, reglen udløses, men behandlingen fortsætter, og efterfølgende regler udløses også for pakken.

For at afvise disse tre tilfælde kan du, når du ser på det indlæste regelsæt, mentalt forestille dig at behandle en hypotetisk TCP-pakke, der ankommer til kue0-grænsefladen og port 22. Vælg den blok, der skal debugges. Begynd at kravle med den første regel. Passer det? Hvis ja, marker det. Har den en 'hurtig' mulighed? Hvis ja, så holder vi op med at gå rundt. Hvis ikke, fortsæt med næste regel. Gentag kontrollen, indtil der er fundet et match med 'hurtig'-indstillingen, eller slutningen af regelsættet er nået. Hvilken regel matchede sidst? Hvis det ikke er regel nummer 14, har du fundet forklaringen på problemet.

At omgå reglerne manuelt kan virke sjovt, men hvis du har erfaring nok, kan det gøres ret hurtigt og i høj grad pålidelighed. Hvis sættet er stort nok, kan du midlertidigt reducere det. Gem en kopi af den faktiske liste over regler og slet de poster, som du ikke tror vil påvirke resultatet. Download dette sæt og test igen. Hvis forbindelsen nu er blokeret, så er de regler, der virkede urelaterede til de pakker, du ledte efter, ansvarlige for tilfælde A eller B. Tilføj regler en efter en, gentag testen, indtil du finder den, du har brug for. Hvis forbindelsen stadig er bestået efter at have fjernet regler, der ikke påvirker den, gentag den mentale gennemgang af det reducerede sæt.

En anden metode er at bruge pf's logningsevne til at identificere tilfælde A eller C. Tilføj 'log' til alle regler med 'pass quick' før den 14. regel. Tilføj 'log' til alle regler med 'bestå' efter den 14. regel. Kør tcpdump for pflog0-grænsefladen og opret en ssh-forbindelse. Du vil se, hvilke regler udover den 14. der udløses sidst på dine pakker. Hvis der ikke er noget i loggen, opstår tilfælde B.

Sporing af forbindelser gennem en firewall

Når en forbindelse passerer gennem en firewall, ankommer pakker på den ene grænseflade og sendes ud gennem den anden. Svar kommer til den anden grænseflade og går til den første. Forbindelser kan således svigte i hvert af disse fire tilfælde.

Først skal du finde ud af, hvilket af de fire tilfælde, der er problemet. Hvis du forsøger at etablere en forbindelse, bør du se en TCP SYN-pakke på den første grænseflade ved hjælp af tcpdump. Du bør også se det samme TCP SYN-pakkeoutput fra den anden grænseflade. Hvis du ikke kan se det, konkluderer vi, at pf blokerer en indgående pakke på den første grænseflade eller en udgående pakke på den anden.

Hvis SYN-afsendelsen ikke er blokeret, bør du se SYN+ACK komme til den anden grænseflade og forlade den første. Hvis ikke, blokerer pf SYN+ACK på en eller anden grænseflade.

Tilføj "log"-indstillingen til regler, der skal tillade SYN og SYN+ACK på begge grænseflader, samt til regler, der skal blokere dem. Prøv forbindelsen igen, og tjek pflog. Det bør afklare i hvilket tilfælde blokeringen sker og efter hvilken regel.

Debugging forbindelsestilstande

Den mest almindelige årsag til, at pf-pakker blokeres, er, at der er en redundant blokeringsregel i sættet. Den tilsvarende sidste match-regel kan findes ved at tilføje 'log'-indstillingen til alle potentielt påvirkede regler og lytte til pflog-grænsefladen.

I et mindre antal tilfælde sker det, at pf lydløst dropper pakker baseret på ikke-regler, og her vil tilføjelse af 'log' til alle regler ikke medføre, at de droppede pakker ender i pflog. Ofte matches en pakke næsten, men ikke fuldstændigt, af en tilstandsindgang.

Husk, at for hver pakke, den behandler, scanner pakkefilteret tilstandstabellen. Hvis der findes en matchende post, tillades pakken med det samme uden at forårsage, at regelsættet behandles for sig selv.

En tilstandstabelpost indeholder information, der er specifik for en enkelt forbindelse.

Hver post har en unik nøgle. Denne nøgle består af flere værdier, der begrænser forbindelsens levetid til konstant hele vejen igennem. Her er de:

Adressetype (Ipv4 eller Ipv6)
Kildeadresse
Modtager adresse
Protokol (TCP UDP)
Kildeport
Modtager port

Denne nøgle bruges til alle pakker, der hører til den samme forbindelse, og pakker fra forskellige forbindelser vil altid have forskellige nøgler.

Når en tilstandstabelpost oprettes ved hjælp af 'behold tilstand'-indstillingen fra en regel, gemmes forbindelsesposten ved hjælp af forbindelsesnøglen. En vigtig begrænsning for tilstandstabellen er, at alle nøgler skal være unikke. De der. der kan ikke være to poster med de samme nøgler.

Det er måske ikke umiddelbart indlysende, at de samme to værter ikke kan etablere flere sameksisterende forbindelser ved hjælp af de samme adresser, protokoller og porte, men dette er en grundlæggende egenskab ved både TCP og UDP. Faktisk kan TCP/IP-stakke kun knytte individuelle pakker til deres sockets ved at udføre valg baseret på adresser og porte.

Selvom forbindelsen er lukket, kan det samme par adresser og porte ikke genbruges med det samme. Netværksudstyret kan senere levere gentransmitterede pakker, og hvis modtagerens TCP/IP-stak forveksler dem med pakker fra en nyoprettet forbindelse, vil dette forstyrre eller endda bryde den nye forbindelse. Af denne grund skal begge værter vente et vist tidsrum, kaldet 2MSL ("two gange den maksimale segmentlevetid"), før de kan bruge de samme adresser og porte igen til en ny forbindelse.

Du kan observere denne egenskab ved manuelt at etablere flere forbindelser til den samme vært. For eksempel at have en webserver, der kører på 10.1.1.1 og port 80, og forbinder to gange med 10.2.2.2. bruger nc:

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

Tilslutning til 10.1.1.1 80-port lykkedes!

Mens forbindelser er åbne, kan du bruge netstat på klienten eller serveren til at vise oplysninger om disse forbindelser:

$ netstat -n | grep 10.1.1.1.80

tcp 0 0 10.2.2.6.28054 10.1.1.1.80 ETABLET

tcp 0 0 10.2.2.6.43204 10.1.1.1.80 ETABLET

Som du kan se, har klienten valgt to forskellige (tilfældige) kildeporte, så dette overtræder ikke kravet om nøgleentydighed.

Du kan fortælle nc at bruge en specifik kildeport med -p-indstillingen:

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

Tilslutning til 10.1.1.1 80-port lykkedes!

nc: binding mislykkedes: Adresse er allerede i brug

Klientens TCP/IP-stak forhindrede nøgleunikhed i at blive kompromitteret. Nogle sjældne og buggy implementeringer af TCP/IP stakke fulgte ikke denne regel, og derfor, som vi snart vil se, vil pf blokere deres forbindelser, hvis nøglernes unikke karakter bliver overtrådt.

Lad os gå tilbage til hvor pf forespørger på tilstandstabellen, når pakken begynder at blive filtreret. Anmodningen består af to trin. Den første forespørgsel foretages for at finde en post i tabelindgangen med en nøgle, der svarer til pakkens protokol, adresser og port. Søgningen vil blive udført efter pakker, der går i alle retninger. Lad os antage, at følgende pakke oprettede en post i tilstandstabellen:

indgåendeTCPfra 10.2.2.2:28054til 10.1.1.1:80

En tabelforespørgsel vil finde følgende poster i tilstandstabellen:

indgående TCP fra 10.2.2.2:28054 til 10.1.1.1:80

udgående TCP fra 10.1.1.1:80 til 10.2.2.2:28054

En post i tabellen indeholder information om retningen (indgående eller udgående) af den første pakke, der skabte posten. For eksempel vil følgende poster ikke give et match:

udgåendeTCPfra 10.2.2.2:28054til 10.1.1.1:80

indgåendeTCPfra 10.1.1.1:80til 10.2.2.2:28054

Årsagen til disse begrænsninger er ikke indlysende, men er ret enkel. Forestil dig, at du kun har én grænseflade med adresse 10.1.1.1, hvor webserveren lytter på port 80. Når klient 10.2.2.2 forbinder ved hjælp af en tilfældigt valgt udgående port 28054, ankommer den første forbindelsespakke på din grænseflade og alle dine udgående svar should vil gå fra 10.1.1.1:80 til 10.2.2.2:28054. Du vil ikke tillade udgående pakker fra 10.2.2.2:28054 til 10.1.1.1:80, da sådanne pakker er meningsløse.

Hvis din firewall er konfigureret til to grænseflader, vil du ved at se pakkerne, der passerer gennem den, se, at hver pakke, der ankommer til den første grænseflade, går ud og gennem den anden. Hvis du opretter en tilstandsrecord, hvor den indledende pakke ankommer til den første grænseflade, vil denne post forhindre den samme pakke i at forlade den anden grænseflade, fordi den er forkert dirigeret.

Når et forsøg på at finde en pakke blandt posterne i tilstandstabellen mislykkes, gennemløbes listen over filterregler. Du skal specifikt tillade, at pakken passerer ud gennem den anden grænseflade med en separat regel. Du bruger sandsynligvis 'behold tilstand' i denne regel, så den anden post i tilstandstabellen dækker hele forbindelsen og på den anden grænseflade.

Du undrer dig måske over, hvordan det er muligt at oprette en anden post i en tabel, hvis vi bare forklarede, at poster skal have unikke nøgler. Forklaringen her er, at posten også indeholder information om forbindelsens retning, og kombinationen af dette med resten af data skal være unik.

Nu vil vi også være i stand til at forklare forskellen mellem en fri forbindelse og en grænsefladebundet forbindelse. Som standard opretter pf poster, der ikke er bundet til nogen grænseflade. Derfor, hvis du tillader forbindelser på én grænseflade, passerer pakker relateret til forbindelsen og matchende tabelposten (inklusive oplysninger om pakkens retning!) gennem enhver grænseflade. I simple installationer med statisk routing er der tale om mere teoretiske beregninger. I princippet bør du ikke se pakker fra den samme forbindelse ankomme til flere grænseflader og svarpakker, der også forlader på flere grænseflader. Men med dynamisk routing er dette muligt. Du kan binde tilstandsposter til en specifik grænseflade ved hjælp af den globale indstilling 'set state-policy if-bound' eller indstillingen per regel 'keep state (if-bound)'. På denne måde vil du være sikker på, at pakker kun vil blive matchet af poster fra den grænseflade, der oprettede disse poster.

Hvis der bruges tunnelgrænseflader, så passerer den samme forbindelse gennem firewallen flere gange. For eksempel kan den første pakke i en forbindelse først passere gennem grænseflade A, derefter gennem B, derefter C og til sidst forlade os gennem grænseflade D. Typisk vil pakkerne være indkapslet på grænseflader A og D og afkapslet på B og C, så pf. ser pakker med forskellige protokoller, og du kan oprette 4 forskellige poster i tilstandstabellen. Uden indkapsling vil pakken være uændret på alle fire grænseflader, og du vil ikke være i stand til at bruge nogle funktioner, såsom adresseoversættelse eller TCP-sekvensnummermodulation, fordi dette vil føre til modstridende nøgler, der vises i tilstandstabellen. Indtil du har en komplet installation, der inkluderer grænseflader med tunneling og debuggede fejl som "pf: src_tree insert failed", vil du ikke være i stand til at betragte din installation som tilstrækkelig vellykket. Lad os vende tilbage til tilstandstabelforespørgslen, der er lavet for hver pakke, før vi kontrollerer reglerne. Forespørgslen skal returnere en enkelt post med en matchende nøgle eller ikke returnere noget. Hvis forespørgslen intet returnerer, gennemgås listen over regler.

Hvis en post er fundet, er det andet trin for TCP-pakker, før de anses for at tilhøre en bestemt forbindelse og filtreres, at kontrollere sekvensnummeret.

Der er et stort antal TCP-angreb, hvor angriberen forsøger at kontrollere forbindelsen mellem to værter. I de fleste tilfælde er angriberen ikke i vejen for ruterne mellem værterne, og kan derfor ikke aflytte lovlige pakker sendt af værterne. Han kan dog sende pakker til en hvilken som helst af værterne, simulere pakker fra hans samtalepartner, ved at spoofe (“spoofing”) - forfalske afsenderens adresse. Angriberens mål kan være at forhindre forbindelser mellem værter i at blive oprettet, eller at afslutte allerede etablerede forbindelser (for at forårsage et lammelsesangreb), eller at skabe ondsindede downloads på forbindelser.

For et vellykket angreb skal angriberen korrekt "gætte" adskillige forbindelsesparametre, såsom kilden og destinationsadressen/porten. Og for udbredte protokoller er dette måske ikke så svært, som det kan se ud. Hvis angriberen kender værtsadresserne og en af portene (da vi taler om en fælles tjeneste), behøver han kun at "gætte" én port. Selvom klienten bruger en virkelig tilfældig kildeport (hvilket ikke altid er sandt), behøver angriberen kun at krydse 65536 porte på kort tid. (I de fleste tilfælde endda (65536-1024) porte, dvs. kun uprivilegerede porte - oversætterens bemærkning))

Men det, der virkelig er svært for en angriber at gætte, er det korrekte sekvensnummer (og dets bekræftelse). Hvis begge værter vælger det indledende sekvensnummer tilfældigt (eller du bruger sekvensnummermodulation til værter, der har en svag ISN (Initial Sequence Number) generator), så vil angriberen ikke være i stand til at finde den passende værdi på det rigtige tidspunkt i forbindelsen .

Under eksistensen af en gyldig TCP-forbindelse ændres sekvensnumrene (og bekræftelserne) for individuelle pakker i henhold til visse regler.

For eksempel, hvis værten sender et datasegment, og dets modtager kvitterer for modtagelsen, burde der ikke være nogen grund til, at afsenderen skulle sende segmentdataene igen. Men faktisk er et forsøg på at overskrive dele af information, der allerede er modtaget af værten, ikke en overtrædelse af TCP-protokollen, selvom det kan være en type angreb.

pf bruger regler til at bestemme det mindste interval for legitime sekvensnumre. Generelt kan pf nøjagtigt bestemme identiteten af kun 30.000 af de 4294967296 mulige sekvensnumre på ethvert givet tidspunkt i en forbindelse. Kun hvis sekvensnummeret og bekræftelsen er inkluderet i dette vindue, vil pf være overbevist om, at pakken er legitim og vil slippe den igennem.

Hvis der findes en passende post under en forespørgsel til tilstandstabellen, Næste skridt Sekvensnumrene for pakker, der er gemt i tabellen, kontrolleres for at se, om de er inden for rækkevidden af mulige værdier. Hvis sammenligningen mislykkes, vil pf generere en "DÅRLIG tilstand"-meddelelse og kassere pakken uden at evaluere regelsættet. Der er to grunde til, at en sammenligning med reglerne ikke forekommer: Det vil næsten helt sikkert være en fejl at gå glip af pakken, fordi hvis beregning af sættet vil resultere i, at reglen rammer en mulighed "keep state" og pf vil ikke være i stand til at træffe en beslutning og oprette en ny post, fordi dette vil føre til modstridende nøgler i tabellen.

For at se og logge "DÅRLIG tilstand"-meddelelser, skal du aktivere fejlfindingstilstand ved hjælp af kommandoen:

$ pfctl -xm

Fejlretningsmeddelelser sendes til konsollen som standard, og syslogd skriver dem også til /var/log/messages. Se efter beskeder, der starter med "pf":

pf:DÅRLIGstat:TCP 192.168.1.10:20 192.168.1.10:20 192.168.1.200:64828

[ lo=1185380879høj=1185380879vinde=33304modulator=0wscale=1]

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

dir=out,fwd

pf: Tilstandsfejl på: 1 |

Disse beskeder kommer altid i par. Den første meddelelse viser tilstandstabelposten på det tidspunkt, hvor pakken blev blokeret, og sekvensnummeret på den pakke, der forårsagede fejlen. Den anden post viser de betingelser, der blev overtrådt.

I slutningen af den første besked vil du se, om der blev oprettet en statuspost for en indgående (dir=in) eller udgående (dir=out) pakke, og om den blokerede pakke rejste i samme retning (dir=,fwd ) eller den modsatte retning (dir=,rev) ) retning.

Indtastningen i tabellen indeholder tre adresser: par af porte, hvoraf to altid er ens med hinanden, hvis forbindelsen ikke har gennemgået nat-, rdr- eller bnat-konvertering. For udgående forbindelser vises pakkens kilde til venstre og destinationen for pakken til højre. Hvis den udgående forbindelse involverer kildeadresseoversættelse, viser parret i midten kilden efter oversættelse. For indgående forbindelser er kilden på højre side af udgangen, og destinationsadressen er i midten. Hvis den indgående forbindelse er underlagt destinationsadresseoversættelse, viser ip/port-parret til venstre destinationen, efter at oversættelsen er udført. Dette format matcher outputtet af pfctl -ss, bortset fra at pfctl viser retningen af pakken ved hjælp af pile.

I outputtet kan du se de aktuelle værtssekvensnumre i firkantede parenteser. Så værdien "4:4" betyder, at forbindelsen er fuldt etableret (mindre værdier er mere sandsynlige på forbindelsesetableringsstadiet, større værdier er mere sandsynlige på det tidspunkt, hvor forbindelsen lukkes)."A" betyder, at den blokerede pakke havde ACK-flaget sat (som i tcpdumps flagoutput), efterfulgt af værdierne af sekvensnumrene (seq=) og (ack=) i de blokerede pakker og pakkens nyttelastlængde - datalængde (len =). askskew er en del af den interne repræsentation af data i tabellen, der kun bruges til værdier, der ikke er lig med nul.

Indgangen "pkts=930:631" betyder, at den matchede 940 pakker, der rejste i samme retning som den pakke, der forårsagede, at indgangen blev oprettet, og 631 pakker i den modsatte retning. Disse tællere vil være særligt nyttige ved fejlfinding af forbindelsesopsætningsfasen, hvis en af dem lig med nul, vil dette modsige din forventning om, at pakker, der går i begge retninger, matcher en given post.

Den følgende meddelelse vil indeholde en liste over et eller flere numre. Hvert tal repræsenterer testen, hvor fejlen opstod:

Pakkevinduesstørrelsen overstiger modtagerens maksimale størrelse (seq + len > høj)
pakken indeholder allerede transmitterede data (seq< lo - win)
acksew er mindre end minimumsværdien
ackskew er større end den maksimale værdi
samme som i (1), men med en forskel (seq + len > high + win)
samme som i (2), men (sek< lo - maximum win)

Heldigvis gælder "DÅRLIG tilstand"-meddelelser ikke for reel daglig trafik, og kontrol af pf-sekvensnummeret undgår de fleste uregelmæssigheder. Hvis du ser disse beskeder vises sporadisk og ikke bemærker et stort antal hængende forbindelser, kan du blot ignorere dem. Der er mange TCP/IP-implementeringer, der kører på internettet, og nogle af dem kan nogle gange generere fejlagtige pakker.

Denne klasse af problemer kan dog let diagnosticeres ved fremkomsten af "DÅRLIG tilstand"-meddelelser, der kun vises i sådanne tilfælde.

Oprettelse af statsregistreTCP ved initialSYN til pakken.

Ideelt set bør tilstandsposter oprettes, når den første SYN-pakke opstår.

Du kan tvinge brugen af denne regel ved at bruge princippet:

"Brug "flag S/SA"-indstillinger i alle "pass proto tcp keep state"-regler"

Kun de indledende SYN-pakker (og kun disse) har SYN-flaget sat og ACK'en indsamlet. Når "behold tilstand"-indstillingen kun anvendes på indledende SYN-pakker, vil kun disse pakker oprette poster i tilstandstabellen. Således vil enhver eksisterende indtastning i tilstandstabellen blive afledt fra den indledende SYN-pakke.

Årsagen til at oprette poster kun for de indledende pakker er en TCP-protokoludvidelse kaldet "vinduesskalering" defineret i RFC1323. TCP-headerfeltet, der bruges til at annoncere størrelsen af modtagne vinduer, er for lille til nutidens højhastighedskommunikationsforbindelser. Moderne TCP/IP-implementeringer foretrækker at bruge store værdier vinduesstørrelse end der kan passe i den eksisterende kasse. Vinduesstørrelseskalering betyder, at alle vinduesstørrelser, der kendes fra den modtagende vært, skal ganges med en bestemt værdi specificeret af modtageren, i stedet for at blive taget af sig selv. For at denne ordning skal fungere, skal begge værter understøtte udvidelsen og indikere over for hinanden deres evne til at implementere den under etableringen af forbindelsen ("håndtryk") ved hjælp af TCP-indstillinger. Disse muligheder er kun til stede i de indledende SYN- og SYN+ACK-pakker. Kun hvis hver af disse pakker indeholder en mulighed, vil den gensidige aftale lykkes, og vinduesstørrelsen for alle efterfølgende pakker vil blive ganget med en faktor.

Hvis pf "ikke var klar over" den vinduesskalering, der blev brugt, ville den tage den leverede værdi uden en faktor, og beregne vinduesstørrelser for acceptable sekvensnummerværdier ville være forkert. Typisk giver værter små vinduesstørrelser i starten af en forbindelse og øger dem, efterhånden som forbindelsen skrider frem. Uvidende om eksistensen af faktorer, der ændrer vinduesstørrelsen, vil pf på et tidspunkt begynde at blokere pakker, fordi den vil tro, at en af værterne forsøger at omgå den maksimale vinduesstørrelse, som "samtaleren" giver. Effekterne af dette kan være mere eller mindre mærkbare. Nogle gange vil værter reagere på pakketab ved at flytte til den såkaldte. "tab recovery mode" og vil annoncere en mindre vinduesstørrelse. Efter at pf genudsender pakker, der blev droppet første gang, vil vinduesstørrelserne øges yderligere, til det punkt, hvor pf vil begynde at blokere dem igen. Den eksterne manifestation kan være midlertidige forbindelsesfrysninger og lav ydeevne. Det er også muligt, at forbindelser helt fryser eller nulstilles på grund af en timeout.

Men pf kender til muligheden for at skalere vinduer og understøtter denne mulighed. Forudsætningen for at oprette tilstandstabelposter på de første SYN-pakker er dog, at pf kan knytte de to første pakker af forbindelsen til tabelindgangen. Og da fuld matchning af vinduesstørrelseskoefficienter kun forekommer i disse to første pakker, er der ingen pålidelig metode til at bestemme disse koefficienter, efter at forbindelsen er forhandlet.

Tidligere blev vinduesstørrelsesskalering ikke udbredt, men dette ændrer sig hurtigt. Det er først for nylig, at Linux har aktiveret denne mulighed som standard. Hvis du har problemer med at hænge forbindelser, især med visse værtskombinationer, og ser "DÅRLIG tilstand"-meddelelser relateret til disse forbindelser, skal du kontrollere, at du rent faktisk opretter tilstandstabelposter på de første pakker af forbindelsen.

Du kan bestemme, om pf bruger skaleringsindstillingen for forbindelsen fra outputtet af pfctl:

$ pfctl -vss

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

wskala 0wskala 1

Hvis der er en "wscale x"-indgang udskrevet på den anden linje (selvom x er nul), vil pf læse, at den ved, at forbindelsen bruger skalering.

En anden simpel metode til at identificere problemer forbundet med skalering er midlertidigt at deaktivere skaleringsstøtte og afspille situationen igen. På OpenBSD kan brugen af skalering styres af sysctl-indstillingen:

$ sysctlnet.inet.tcp.rfc1323

net.inet.tcp.rfc1323=1

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

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

Lignende problemer opstår, når du opretter indgange i tilstandstabellen for andre pakker end den oprindelige SYN og bruger "mulate state"-indstillingen eller broadcast. I begge tilfælde sker udsendelsen i begyndelsen af forbindelsen. Hvis den første pakke ikke er oversat, afskrækker tranchering af efterfølgende pakker normalt den modtagende ende og forårsager, at sendte svar blokeres af pf med en "DÅRLIG tilstand"-meddelelse.

Afsnittet opdateres dagligt. Altid de nyeste versioner af de bedste gratis programmer til daglig brug i afsnittet Nødvendige programmer. Der er næsten alt hvad du skal bruge til det daglige arbejde. Begynd gradvist at opgive piratkopierede versioner til fordel for mere bekvemme og funktionelle gratis analoger. Hvis du stadig ikke bruger vores chat, anbefaler vi stærkt, at du stifter bekendtskab med den. Der vil du finde mange nye venner. Derudover er dette den hurtigste og mest effektive måde at kontakte projektadministratorer på. Antivirus-opdateringssektionen fortsætter med at fungere - altid opdaterede gratis opdateringer til Dr Web og NOD. Havde du ikke tid til at læse noget? Det fulde indhold af tickeren kan findes på dette link.

Gratis firewall Comodo. Test, konklusioner

Comodo Firewall i aktion

Efter installation og konfiguration gemte Comodo sig i bakken og begyndte at plage mig med sine spørgsmål. På den første dag legede jeg med alle firewall'erne og proaktive beskyttelsestilstande og fik det til sidst stille. Der blev ikke fundet bremser i vores system efter dets fremkomst. Generelt var det ret nemt og bekvemt at arbejde med firewallen fra Comodo. Grænsefladen til hovedvinduet er meget enkel og informativ:

Men jeg skulle vænne mig til at navigere gennem firewall'en og proaktive beskyttelsesindstillinger - det er ikke altid muligt hurtigt at finde det rigtige element. Jeg tror, det vil gå væk med tiden.

Et par dage efter installationen af Comodo Firewall besluttede jeg at teste det lidt.

Test nr. 1. Online test

Når du klikker på knappen "Test", forsøger programmet at etablere en forbindelse til webstedets server.

Da Comodo Firewall endnu ikke kender dette værktøj, første gang den forsøgte at få adgang til internettet, var der en øjeblikkelig reaktion fra proaktiv beskyttelse og firewallen:

I begge tilfælde klikkede jeg på blok og modtog bekræftelse på, at testen var vellykket:

Så omdøbte jeg filen FireWallTest.exe V opera.exe og erstattede standard Opera-filen med den. Således forsøgte jeg at snyde Comodo Firewall, som allerede kender denne browser godt og konstant og automatisk frigiver den til internettet. Comodo reagerede på lanceringen af den "falske" Opera fra Total som følger:

Efter at have modtaget min tilladelse til en engangslancering advarede firewallen mig om, at Opera forsøgte at få adgang til internettet:

Det viser sig, at enhver applikation, som der allerede er regler for, hvis den eksekverbare fil erstattes uden min viden, ikke vil være i stand til at få adgang til internettet. Alt ser ud til at være i orden, men her er sagen: Farven på den øverste del af advarselsvinduet afhænger af situationens alvor. Hvis Comodo vurderer en begivenhed som kritisk, vil farven være rød, hvis begivenheden er mindre farlig, vil den være gul. I mit tilfælde anså Comodo den simulerede situation for ikke at være særlig farlig og tændte det "gule" lys. Desuden i stedet for ordlyden "eksekverbar fil opera.exe ikke genkendt" Jeg ville foretrække at se, at "der var en ændring i filparametre opera.exe" Sådan advarer høstmaskiner fra for eksempel Kaspersky og Eset i sådanne situationer. Desuden ser brugeren et alarmvindue med den røde farve, som straks tvinger dem til at være opmærksomme på situationen. Og en advarsel fra Comodo kan simpelthen ignoreres af brugeren på grund af utilstrækkelig vægt på begivenheden.

At erstatte Opera-filen var kun en del af min lumsk plan. Det næste offer var Internet Explorer 6, som er integreret i operativsystemet, og derfor iexplore.exe kan betragtes som en fuldgyldig systemfil. Forestil dig min overraskelse, da jeg under Comodos fuldstændige tavshed så et vindue om testfejl:

Tilsyneladende var der oprettet en ekstra regel, besluttede jeg og gik ind i firewallen og proaktive beskyttelsespolitikker. Efter at have rodet rundt der i omkring 15 minutter, tog jeg den eneste rigtige beslutning - at geninstallere Comodo. Ikke før sagt end gjort. Da jeg forlod standarddriftstilstandene, gentog jeg eksperimentet med substitution iexplore.exe. Da den blev lanceret fra Total, virkede proaktiv beskyttelse, som i tilfældet med Opera:

Her skal du gøre lidt lyrisk digression. Faktum er, at når en IE eksekverbar fil udskiftes, gendanner systemet den originale inden for 4-8 sekunder iexplore.exe. I denne forbindelse afhang resultaterne af min test af, om den forfalskede fil formåede at nå internettet eller ej.

I det tilfælde, hvor det lykkes mig at fuldføre alle manipulationerne, før jeg genopretter explore.exe, sker følgende. Efter at have modtaget min tilladelse til en engangslancering explore.exe, Total starter FireWallTest-værktøjet, tryk på "Test", Defens+ proaktiv beskyttelse udsender en advarsel:

Hvis vi tillader det (som et eksperiment), fungerer firewallen:

Vi formår at klikke på "Bloker" - testen er bestået, værktøjet kommer ikke igennem til internettet. Men hvis iexplore.exe gendannet før du trykkede på blokeringsknappen - intet afhænger af dit valg - værktøjet får automatisk internetadgang i det øjeblik, den originale fil gendannes.

Det samme gælder arbejdet med proaktiv beskyttelse: hvis du ikke havde tid til at kommandere blokering før genopretning explore.exe- værktøjet får automatisk adgang til internettet.

Efter at have spillet nok med den falske IE, huskede jeg den allerførste fiasko i testen, da Comodo forblev tavs og frigav den "forkerte" fil på internettet. Efter at have geninstalleret Comodo, satte jeg Defence+ og firewallen i træningstilstand og lancerede IE. Derefter returnerede jeg standardtilstandene og gentog testen. Comodo fejlede det stille og roligt igen...

Test nr. 3. Duel

Imponeret over resultaterne af den forrige test, ledte jeg efter yderligere muligheder for at teste Comodo og fandt endelig AWFT-værktøjet.

Dette program emulerer trojanske hestes opførsel og indeholder en serie på seks tests, der demonstrerer forskellige teknikker uautoriseret adgang til netværket, omgåelse af firewallbeskyttelse. Blandt disse tests er der både gamle måder at bedrage firewalls på og mere moderne teknikker. For hver bestået test tildeles firewallen et vist antal point. Hvis prøven ikke er bestået, vil der blive tildelt point til AWFT. Det maksimale antal point er ti.

Hjælpeprogrammet er shareware, begrænset til 10 lanceringer. Øverst i programvinduet er der knapper, der starter de tilsvarende tests; nederst er stedet, hvor AWFT vil bryde igennem, og resultatet af duellen mellem firewallen og værktøjet. Knappen Nulstil punkter bruges til at nulstille de akkumulerede punkter.

For en sikkerheds skyld besluttede jeg at ændre webstedsadressen til min egen.

Testen fandt sted med Comodo Firewall og Defence+ slået til, Opera kører og Avira-skærm slukket.

Den første test brugte teknikken med at indlæse en skjult kopi af browseren og lappe hukommelsen, før den blev startet.

Da jeg klikkede på testknappen, dukkede et vindue op med en fejl:

Efter at have lukket dette vindue, svarede Comodo på testen med et anmodningsvindue; da du klikkede på knappen "Bloker", gav AWFT, efter at have tænkt lidt, det første punkt til firewallen.

Ifølge udviklerne af hjælpeprogrammet er test nr. 2 et gammelt og velkendt trick. Comodo svarer igen med et anmodningsvindue og scorer igen et point.

Test #3 bruger også et gammelt trick. Comodo blokerer det simpelthen lydløst, tilsyneladende er tricket virkelig velkendt.

Test nr. 4 ligner den første test med lancering af en skjult kopi af browseren og patchning af hukommelsen, før den startes. Firewallen gav ingen advarsler, men efter en kort pause fik den endnu et point.

Under den femte og sjette test skal du skifte til browseren og surfe lidt (jeg har lige opdateret siden, der er indlæst i browseren).

I test nr. 5 udfører hjælpeprogrammet en heuristisk søgning efter autoriseret software installeret på en computer (eller netværk), der har adgang til internettet via port 80, starter derefter en kopi af det autoriserede program og patcher hukommelsen lige før start. optaget af dette program (dvs. AWFT starter sig selv i hukommelsen af det tilladte program). Comodo gennemførte prøven stille og roligt og modtog hele 3 point for den.

Test nr. 6 ligner den forrige femte test. Samme teknik bruges med en heuristisk søgning efter installeret software, der har ret til at afslutte gennem port 80. Kun hackingmetoden er nu ændret - en brugeranmodning anvendes. Samtidig forsøger AWFT at vedhæfte en skjult venstre værktøjslinje til browseren. Da jeg åbnede Opera, dukkede følgende vindue op:

I det øjeblik, jeg bekræftede denne brugeranmodning, udstedte Comodo sin anmodning, værktøjet blev blokeret igen, og firewallen modtog 3 point i sin kredit.

Resultatet af duellen er 10:0 til fordel for Comodo. Ved at gentage testene med Internet Explorer åben, fik jeg de samme resultater.

Konklusion

På trods af nogle dårlig eftersmag i mit hjerte, tilbage efter at have testet firewallen, anbefaler jeg stadig Comodo Internet Security til hjemmebrug, men kun som en firewall. Og lyt ikke til de smarte fyre, der råder dig til at slå proaktiv beskyttelse fra, under ingen omstændigheder! Kun med brugen af Defence+ sikrer denne firewall virkelig din computers sikkerhed. Men hvad du egentlig ikke bør bruge er Comodos antivirus. Ikke alene springer den en del over, men du vil få problemer med at opdatere den - dens databaser er meget besværlige. Derudover påvirker det systemets ydeevne betydeligt. Comodo Firewall og Avira Antivir Personal fungerede fint for mig.

Jeg fandt ingen bremser eller fejl i systemet, mens firewallen kørte. Jeg vil holde mine tanker om resultaterne af min test for mig selv indtil videre; jeg vil gerne høre dine kommentarer.

Mens jeg skrev den sidste del af denne artikel, stødte jeg på resultaterne af nylige firewall-tests fra Matousec-laboratoriet. Comodo Internet Security var den eneste firewall med en score på 100 % (se firewall-forum). Nå, jeg tog mit valg... Og dig?

fordele (indlysende):
gratis distribution,
tilgængelighed af sin egen programdatabase;
tilgængelighed af proaktiv beskyttelse (Defense+);
nem installation og indledende opsætning;
meget informativt og praktisk vindue med et resumé;

fordele (tvivlsomt):
tilstedeværelsen af flere driftstilstande;

ulemper (indlysende):
irriterende installationstilstand;
substitution af en eksekverbar fil identificeres ikke af proaktiv beskyttelse som en kritisk hændelse;

ulemper (tvivlsomt):
ærlig talt mislykket antivirus.

Sammenlignende test af 21 populære firewalls for kvaliteten af beskyttelse mod angreb, der kommer inde fra systemet. Testen testede beskyttelse ved hjælp af 64 specialudviklede testværktøjer, der kontrollerede beskyttelse af processer mod afslutning, beskyttelse mod interne standardangreb, beskyttelse mod ikke-standardlækager og beskyttelse mod ikke-standardiserede teknikker til at penetrere kernetilstand.

Sammen med antivirus er en firewall en af hovedkomponenterne i computersikkerhed. Men i modsætning til antivirus, udføres objektive test af firewall-ydeevne sjældent. Vi forsøgte at lukke dette hul ved at udføre en test af firewalls til beskyttelse mod interne angreb i 2011 og 2012 og en test af personlig IDS/IPS til beskyttelse mod angreb på sårbare applikationer. I år besluttede vi at udvide listen over anvendte metoder og gentage firewall-testen for beskyttelse mod interne angreb for at se, hvordan resultaterne af populære produkter i henhold til dette kriterium har ændret sig over tid.

Hvad er denne test rettet mod, eller hvilke funktioner udfører firewallen? Ifølge definitionen af internetstandarden [RFC3511] (2003) er en firewall et system, der implementerer funktionerne til at filtrere netværkspakker i overensstemmelse med specificerede regler for at differentiere trafik mellem netværkssegmenter. Men med den voksende kompleksitet af malware og hackerangreb er de oprindelige firewall-opgaver blevet suppleret med nye funktionelle moduler. Det er praktisk talt umuligt at forestille sig en fuldgyldig firewall uden et HIPS-modul (overvågning af systemhændelser, overvågning af systemintegritet osv.).

Hovedopgaven for en moderne firewall er at blokere uautoriseret netværkskommunikation (herefter benævnt angreb), opdelt i intern og ekstern. Disse omfatter:

Eksterne angreb på et firewall-beskyttet system:

initieret af hackere;
initieret af ondsindet kode.

initieret af applikationer, der ikke er tillid til (ondsindet kode);
initieret af applikationer, hvis netværksaktivitet er udtrykkeligt forbudt i henhold til reglerne.

Derudover er produkter, der kunne klassificeres som rene personlige firewalls i den klassiske formulering fra 2003, stort set forsvundet fra markedet. De er blevet erstattet af omfattende beskyttelsesprodukter personlige computere, som nødvendigvis inkluderer en firewall-komponent.

En firewall-test til beskyttelse mod eksterne angreb involverer at undersøge kvaliteten af beskyttelsen mod angreb, der kommer inde fra systemet. Testen blev udført på følgende områder:

Kontrol af beskyttelse af processer mod opsigelse.
Beskyttelse mod standard interne angreb.
Test af beskyttelse mod ikke-standard lækager.
Test af beskyttelse mod ikke-standard teknikker til at penetrere kernetilstand.

I forhold til den tidligere test er antallet af brugte angreb steget markant – fra 40 til 64. Det styresystem, som de testede produkter skal beskytte, har også ændret sig. I den forrige test var det Windows XP, og i denne test var det Windows 7 x32. En lignende test er også planlagt i slutningen af året for Windows 7 x64-operativsystemet.

Introduktion

Testen involverede 21 populære omfattende beskyttelsesprogrammer (Internet Security-klasse; hvis der ikke er et sådant produkt i rækken, blev der valgt en ren firewall) fra forskellige producenter Produktversioner, der er aktuelle fra startdatoen for test (maj 2013) og kører på Windows-platformen 7 x32 :

Avast! Internetsikkerhed (8.0.1488).
AVG Internet Security (2013.0.3272).
Avira Internet Security (13.0.0.3499).
Bitdefender Internet Security (16.29.0.1830).
Comodo Internet Security (6.1.276867.2813).
Dr.Web Security Space (8.0).
Eset Smart Security (6.0.316.0).
F-Secure Internet Security (1.77 build 243).
G DATA Internetsikkerhed (1.0.13113.239).
Jetico Personal Firewall (2.0).
Kaspersky Internet Security (13.0.1.4190(g).
McAfee Internet Security (11.6.507).
Kingsoft Internet Security (2009.05.07.70).
Microsoft Security Essentials (4.2.223.0) + Windows Firewall.
Norton Internet Security (20.3.0.36).
Online Armor Premium Firewall (6.0.0.1736).
Outpost Security Suite Pro (8.0 (4164.639.1856).
Panda Internet Security (18/01/01).
PC Tools Internet Security (9.1.0.2900).
Trend Micro Titanium Internet Security (6.0.1215).
TrustPort Internet Security (2013 (13.0.9.5102).

Før testen startede, blev testmiljøet forberedt. For at gøre dette blev Windows 7 Enterprise SP1 x86-operativsystemet med alle tilgængelige opdateringer på det tidspunkt, samt yderligere software, der kræves til testen, installeret på en ren computer.

Test blev udført på to typer indstillinger: standard anbefalet af producenten (standardindstillinger) og maksimum. I det første tilfælde blev standardindstillingerne anbefalet af fabrikanterne brugt, og alle handlinger anbefalet af programmet blev udført.

I det andet tilfælde blev alle indstillinger, der var deaktiveret i "standard"-tilstand, men stadig kunne påvirke resultatet af testen, desuden slået til og/eller bragt til deres maksimale position (de mest stringente indstillinger). Med andre ord betyder indstilling af de maksimale indstillinger at overføre alle tilgængelige indstillinger fra den grafiske brugergrænseflade for alle moduler, der er relateret til detektering af ondsindet fil- eller netværksaktivitet til den mest strenge mulighed.

Firewalltesten blev udført vha til følgende grupper interne angreb, opdelt i sværhedsgrader for klarhedens skyld:

1. Grundlæggende sværhedsgrad (56 angrebsmuligheder):

1. kontrol af beskyttelsen af processer mod afslutning (41 angrebsmuligheder);
2. beskyttelse mod standard interne angreb (15 angrebsmuligheder).

2. Øget sværhedsgrad (8 angrebsmuligheder):

1. test af beskyttelse mod ikke-standard lækager (3 angrebsmuligheder);
2. afprøvning af beskyttelse mod ikke-standardiserede teknikker til at penetrere kernetilstand (5 angrebsmuligheder).

En detaljeret beskrivelse af alle angrebsmetoder brugt i testen kan findes i testmetodikken.

Kontrol af firewalls for beskyttelse mod interne angreb

Lad os minde dig om, at i henhold til den anvendte prisordning blev der tildelt 1 point (+), hvis angrebet blev blokeret automatisk, og den beskyttende funktionalitet af det testede program ikke var brudt. 0,5 point (eller +/-) - hvis angrebet kun blokeres under særlige omstændigheder (f.eks. når brugeren vælger korrekt påkrævet handling efter anmodning fra det program, der testes). Og endelig, hvis angrebet var vellykket helt eller delvist og deaktiverede beskyttelsesfunktionaliteten, blev der ikke givet point. Det maksimalt mulige antal point opnået i denne test var 64.

Tabel 1-2 og figur 1-2 viser resultaterne af at teste firewalls separat på standard- og maksimumindstillinger. For klarhedens skyld er resultaterne for hver firewall opdelt i to grupper: beskyttelse mod angreb basis niveau kompleksitet og beskyttelse mod angreb af et øget kompleksitetsniveau.

Tabel 1: Firewall-testresultater for standardENrt indstillinger

Testet produkt							Samlet antal point (maks. 64)	Total %
Testet produkt	Points	%	% fra summen	Points	%	% fra summen	Samlet antal point (maks. 64)	Total %
Comodo	53	95%	82,8%	6	75%	9,4%	59	92%
Online rustning	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%
Forpost	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 DATA	42	75%	65,6%	1	13%	1,6%	43	67%
Avast	41	73%	64,1%	1	13%	1,6%	42	66%
Eset	41	73%	64,1%	1	13%	1,6%	42	66%
Bitdefender	41	73%	64,1%	1	13%	1,6%	42	66%
AVG	41	73%	64,1%	0	0%	0,0%	41	64%
McAfee	41	73%	64,1%	0	0%	0,0%	41	64%
PC-værktøjer	41	73%	64,1%	0	0%	0,0%	41	64%
Avira	40	71%	62,5%	0	0%	0,0%	40	63%
Microsoft	40	71%	62,5%	0	0%	0,0%	40	63%
F-Secure	31,5	56%	49,2%	1	13%	1,6%	32,5	51%
Panda	30	54%	46,9%	0	0%	0,0%	30	47%
Kingsoft	27	48%	42,2%	1	13%	1,6%	28	44%

Figur 1: Firewall-testresultater på standardindstillinger

Beskyttelse mod interne angreb ved de af producenten anbefalede indstillinger lader meget tilbage at ønske. Kun tre firewalls var i stand til at overvinde tærsklen på 80 % på standardindstillinger - Comodo, Online Armor og Norton. Produkterne Jetico (79%) og Outpost (74%) er ret tæt på dem. Resultaterne af andre firewalls var væsentligt dårligere.

Sammenlignet med resultaterne af den sidste test bekræftede alle ledere deres høje resultater; der var kun små bevægelser inden for den førende gruppe, for eksempel byttede Outpost og Jetico positioner. Den eneste overraskelse var Norton-produktet, som i den forrige test viste et resultat på 45% og lå i bunden af tabellen, og i denne test med 80% indtog det tredjepladsen.

De opnåede resultater skyldes, at mange producenter sætter standardindstillingerne på en sådan måde, at de reducerer antallet af beskeder, som brugeren skal svare på. Dette bekræftes af testresultaterne - ved standardindstillinger stillede firewalls kun spørgsmål til brugere i 5,4 % af angrebene, og ved maksimale indstillinger - i 9,2 % af angrebene. Dette påvirker dog kvaliteten af beskyttelsen, som vil forblive tavs i en situation, hvor det ondsindede program efterligner/udfører helt legitime handlinger i systemet.

Du bør også være opmærksom på to mønstre. For det første er procentdelen af forebyggelse af komplekse typer af angreb generelt mærkbart værre end angreb af et grundlæggende kompleksitetsniveau. Mere end halvdelen af disse angreb blev afvist af kun fire produkter - Comodo, Online Armor, Norton og Jetico. Yderligere fire produkter blev inkluderet i grænsegruppen, der afviste fra 25 % til 38 % af sådanne angreb: Outpost, Trend Micro, Kaspersky og Dr.Web. Alle andre produkter afviste ikke mere end ét komplekst angreb. For det andet er ydeevnen til at afvise grundlæggende angreb forbedret. Hvis 11 (50%) produkter i den foregående test afviste mindre end 50% af angrebene, så var der i denne test kun 3 (14%) sådanne produkter.

Tabel 2: Firewall-testresultater ved maksimale indstillinger

Testet produkt	Grundlæggende sværhedsgrad angreb (maks. 56 point)			Angreb af en højere sværhedsgrad (maks. 8 point)			Samlet point (maks. 64)	Total %
Testet produkt	Points	%	% fra summen	Points	%	% fra summen	Samlet point (maks. 64)	Total %
Comodo	56	100%	87,5%	8	100%	12,5%	64	100%
Bitdefender	56	100%	87,5%	8	100%	12,5%	64	100%
Online rustning	53	95%	82,8%	8	100%	12,5%	61	95%
Kaspersky	53	95%	82,8%	7	88%	10,9%	60	94%
Norton	50,5	90%	78,9%	8	100%	12,5%	58,5	91%
PC-værktøjer	49,5	88%	77,3%	5,5	69%	8,6%	55	86%
Forpost	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 DATA	42	75%	65,6%	3	38%	4,7%	45	70%
Avira	41,5	74%	64,8%	2	25%	3,1%	43,5	68%
Avast	41	73%	64,1%	1,5	19%	2,3%	42,5	66%
AVG	41	73%	64,1%	0	0%	0,0%	41	64%
McAfee	41	73%	64,1%	0	0%	0,0%	41	64%
Microsoft	40	71%	62,5%	0	0%	0,0%	40	63%
F-Secure	31,5	56%	49,2%	1	13%	1,6%	32,5	51%
Panda	30	54%	46,9%	0	0%	0,0%	30	47%
Kingsoft	27	48%	42,2%	1	13%	1,6%	28	44%

Figur 2: Firewall-testresultater ved maksimale indstillinger

Da de maksimale indstillinger blev aktiveret, blev kvaliteten af beskyttelsen mod interne angreb i mange testede firewalls væsentligt forbedret. Dette er især mærkbart blandt stærke mellembønder. Alle lederne af den tidligere test viste også høje resultater i denne test. Blandt ændringerne er det værd at bemærke Bitdefender-produktet, som sammen med Comodo viste 100% resultater, og Norton-produktet, der flyttede til den førende gruppe.

Resultaterne af en række produkter på standard- og maksimumindstillinger var de samme. Dette skyldes, at disse produkter ikke har indstillinger, der kan påvirke resultaterne af vores test.

Sammenligning af beskyttelseskvalitet ved standard- og maksimumindstillinger

På grund af logikken i denne test vil vi ikke summere eller gennemsnit af resultaterne af det samme produkt med forskellige indstillinger. Tværtimod ønsker vi at sammenligne dem og vise betydelige forskelle i kvaliteten af beskyttelsen af de testede produkter afhængigt af de anvendte indstillinger.

For klarhedens skyld præsenterer vi de endelige resultater af firewalltesten med standard- og maksimumindstillinger i tabel 3 og figur 3.

Tabel 3: Oversigtsresultater af firewalltesten på standard- og maksimumindstillinger

Produkt	Standardindstillinger	Maksimale indstillinger
Comodo	92%	100%
Online rustning	90%	95%
Norton	80%	91%
Jetico	79%	79%
Forpost	74%	85%
Trend Micro	70%	72%
Kaspersky	70%	94%
Dr.Web	70%	80%
TrustPort	68%	71%
G DATA	67%	70%
Avast	66%	66%
Eset	66%	85%
Bitdefender	66%	100%
AVG	64%	64%
McAfee	64%	64%
PC-værktøjer	64%	86%
Avira	63%	68%
Microsoft	63%	63%
F-Secure	51%	51%
Panda	47%	47%
Kingsoft	44%	44%

Figur 3: Sammenfatningsresultater af firewalltesten på standard- og maksimumindstillinger

Figur 3 viser meget tydeligt forskellen i testresultater afhængigt af de valgte indstillinger.

For det første viser kun to produkter - Comodo og Online Armor - beskyttelsesindikatorer tæt på maksimum, både ved standard- og ved maksimale indstillinger.

For det andet, når du ændrer standardindstillingerne foreslået af producenten, viser nogle produkter et væsentligt bedre beskyttelsesniveau. Dette er tydeligst synligt i produkter som Bitdefender, Kaspersky, Eset, F-Secure og PC Tools.

For det tredje, som nævnt ovenfor, har nogle af de testede produkter slet ikke indstillinger, der på nogen måde kan påvirke testresultaterne. Derfor er deres resultater for alle typer indstillinger i denne test de samme. Denne gruppe omfatter Jetico, Avast, AVG, McAffe, F-Secure, Panda, Kingsoft og Microsoft.

Slutresultatet tager ikke højde for situationer, hvor angrebet blev afvist, men der var problemer med produkternes brugerflade. I de fleste tilfælde bestod problemerne i, at grænsefladen gik ned i kort tid (fra 2 til 10 sekunder) eller indtil næste opstart af operativsystemet. Selvom produkter fortsatte med at yde beskyttelse af problemer med brugergrænsefladen, opfattes tilstedeværelsen af sådanne problemer subjektivt som negative og kan påvirke produktvalgspræferencer. Antallet af problemer med brugergrænsefladen er vist i tabel 3 og figur 3. Der blev vurderet fejl, der stammede fra niveau 1-angreb, hvoraf det samlede antal var 41.

Tabel 4: Antal brugergrænsefladeproblemer på standard- og maksimumindstillinger

Testet produkt	Standardindstillinger		Maksimale indstillinger
Testet produkt	Antal fejl	%	Antal fejl	%
McAfee	34	83%	34	83%
Microsoft	33	80%	33	80%
Kingsoft	20	49%	20	49%
F-Secure	19	46%	19	46%
Panda	17	41%	17	41%
Jetico	16	39%	16	39%
PC-værktøjer	13	32%	13	32%
Trend Micro	12	29%	12	29%
AVG	10	24%	9	22%
TrustPort	9	22%	9	22%
G DATA	9	22%	9	22%
Bitdefender	8	20%	8	20%
Norton	6	15%	6	15%
Avast	5	12%	5	12%
Forpost	5	12%	5	12%
Eset	5	12%	4	10%
Comodo	5	12%	0	0%
Avira	2	5%	2	5%
Dr.Web	2	5%	2	5%
Kaspersky	1	2%	1	2%
Online rustning	1	2%	1	2%

Figur 4: Antal UI-problemer på standard- og maksimumindstillinger

Resultaterne viser, at McAfee- og Microsoft-produkter oplevede problemer med brugergrænsefladen i de fleste angreb (mere end 80%). Dette kan kaldes et uacceptabelt niveau, fordi... Næsten ethvert med succes afvist angreb vil føre til problemer. Ganske dårlige resultater, der spænder fra 30 % til 50 %, vises af produkter fra Kingsoft, F-Secure, Panda, Jetico og PC Tools. Når du bruger dem, vil hvert 2-3 angreb føre til problemer med grænsefladen. En række andre produkter viser resultater fra 10 % til 30 %, hvilket kan kaldes tilfredsstillende. Gode resultater viste produkterne Avira, Dr.Web, Kaspersky og Online Armor, hvor problemer opstod i området fra 2 % til 5 % af angrebene. Det eneste produkt, der aldrig har haft problemer med brugergrænsefladen, var Comodo med maksimale indstillinger, hvilket kan tillades fremragende resultat. Men med standardindstillinger forringes Comodo-resultatet (12%), hvilket tyder på, at brugen af dette produkt kræver en vis viden om, hvordan det konfigureres.

Endelige testresultater og præmier

Ligesom i den forrige test tog vi ikke gennemsnittet af resultaterne af det samme produkt med forskellige indstillinger, men betragtede dem uafhængigt af hinanden. Således kan hvert af de testede produkter modtage to priser, en for hver type indstilling.

I overensstemmelse med præmieordningen modtager de bedste firewalls priser, der angiver de anvendte indstillinger, se tabel 4.

Tabel 5: Endelige resultater af firewalltesten på standard- og maksimumindstillinger

Produktet bliver testet	Mulighed indstillinger	Angrebsforebyggelse [%]		Total [%]	Belønning
Produktet bliver testet	Mulighed indstillinger	Grundlag sværhedsgrad	Øget sværhedsgrad	Total [%]	Belønning
Comodo	Maks	100%	100%	100%	Platinum Firewall udgående Beskyttelsespris
Bitdefender	Maks	100%	100%	100%	Platinum Firewall udgående Beskyttelsespris
Online rustning	Maks	95%	100%	95%	Gold Firewall udgående Beskyttelsespris
Kaspersky	Maks	95%	88%	94%
Comodo	Standard	95%	75%	92%
Norton	Maks	90%	100%	91%
Online rustning	Standard	89%	94%	90%
PC-værktøjer	Maks	88%	69%	86%
Forpost	Maks	88%	69%	85%
Eset	Maks	88%	69%	85%
Norton	Standard	80%	75%	80%
Dr.Web	Maks	83%	63%	80%
Jetico	Maks	82%	56%	79%	Sølv Firewall udgående Beskyttelsespris
Jetico	Standard	82%	56%	79%
Forpost	Standard	80%	31%	74%
Trend Micro	Maks	77%	38%	72%
TrustPort	Maks	77%	31%	71%
Trend Micro	Standard	75%	38%	70%
Kaspersky	Standard	75%	31%	70%
Dr.Web	Standard	76%	25%	70%
G DATA	Maks	75%	38%	70%
TrustPort	Standard	77%	6%	68%	Bronze Firewall udgående Beskyttelsespris
Avira	Maks	74%	25%	68%
G DATA	Standard	75%	13%	67%
Avast	Maks	73%	19%	66%
Avast	Standard	73%	13%	66%
Eset	Standard	73%	13%	66%
Bitdefender	Standard	73%	13%	66%
AVG	Maks	73%	0%	64%
AVG	Standard	73%	0%	64%
McAfee	Maks	73%	0%	64%
McAfee	Standard	73%	0%	64%
PC-værktøjer	Standard	73%	0%	64%
Microsoft	Maks	71%	0%	63%
Microsoft	Standard	71%	0%	63%
Avira	Standard	71%	0%	63%
F-Secure	Maks	56%	13%	51%	Ingen belønning
F-Secure	Standard	56%	13%	51%
Panda	Maks	54%	0%	47%
Panda	Standard	54%	0%	47%
Kingsoft	Maks	48%	13%	44%
Kingsoft	Standard	48%	13%	44%

De bedste resultater i testen blev vist af Comodo og Bitdefender firewalls, som scorede 100 % på maksimale indstillinger. Disse to produkter vinder en pris PlatinFirewallUdgåendeBeskyttelsePris.

Meget høje resultater i testen (over 80%) blev også vist af Firewalls Online Armor, Kaspersky, Comodo, Norton, PC Tools, Outpost, Eset og Dr.Web, som modtog priser GuldFirewallUdgåendeBeskyttelsePris. Det er vigtigt at bemærke, at Comodo modtog denne pris for standardindstillinger, Online Armor og Norton for standard- og maksimumindstillinger, og alle andre kun for maksimale indstillinger.

Næste på listen er en gruppe på syv firewalls, hvis resultater falder i intervallet 60% til 70%. Disse er Outpost, Kaspersky og Dr.Web med standardindstillinger; TrustPort og G DATA ved maksimale indstillinger, samt Jetico og Trend Micro ved både standard- og maksimumindstillinger. De får alle en belønning

Nok stor gruppe Produkter, der falder i intervallet 60% til 70% modtager en pris. Det skal bemærkes, at Eset- og Bitdefender-produkter ved standardindstillinger var i stand til at afvise et betydeligt større antal angreb ved maksimale indstillinger.

Du kan se de detaljerede testresultater og sikre dig, at de endelige beregninger er korrekte ved at downloade testresultaterne i Microsoft Excel-format.

Shabanov Ilya, administrerende partner for webstedet:

”Jeg var meget tilfreds med, at mange producenter har forbedret proaktiv beskyttelse mod interne angreb og selvforsvar i deres produkter markant. Vi var endda nødt til at revidere tildelingsordningen for at højne kravene. En score på mindre end 51 % blev nu betragtet som en fuldstændig fiasko.

Jeg var glædeligt overrasket over, at Bitdefender afviste alle 100 % af angrebene i paranoid tilstand, Eset og Dr.Web med resultater ved maksimale indstillinger på henholdsvis 85 % til 80 %, såvel som nykommeren til vores test, TrustPort. IN " guld gruppe Ifølge resultaterne af denne test inkluderede produkterne firewalls Comodo, Norton og Online Armor, som scorede mere end 80% på standard- og maksimumindstillinger. Konsekvent høje resultater i test, der involverer proaktiv beskyttelse, blev demonstreret af Kaspersky, Outpost og PC Tools.

I tilfælde af en række testede produkter er logikken for standardindstillingerne dog uklar. Som følge heraf viser beskyttelsesniveauet for de fleste brugere, der er vant til at bruge beskyttelse med standardindstillinger, sig at være væsentligt lavere. Dette gælder primært produkter fra Bitdefender, Kaspersky, Eset og PC Tools.”

Mikhail Kartavenko, leder af testlaboratoriets hjemmeside:

“I betragtning af denne test som en fortsættelse af den tidligere lignende test, kan vi identificere flere hovedtendenser og problemer i driften af firewalls.

For det første viste de fleste produkter i gennemsnit bedre resultater end for 1,5 år siden, men de gjorde dette hovedsageligt ved at afvise de enkleste niveau 1-angreb. Mere komplekse angreb er kun hårde på et begrænset udvalg af produkter.

For det andet, selvom beskyttelsen af processer mod afslutning (1. angrebsniveau) virkede, går brugergrænsefladen på mange produkter ned. Dette sætter brugeren i en akavet stilling, hvor han ikke forstår, om beskyttelsen virker eller ej.

For det tredje er der et ret stort hul i firewalls ydeevne på standard- og maksimalindstillinger. Som følge heraf kan et acceptabelt beskyttelsesniveau ofte kun opnås af erfarne brugere, der kender og kan konfigurere firewalls korrekt.

Således identificerede testen smertepunkterne i moderne firewalls, hvis løsning kan forbedre deres beskyttelse."