Filtrera skiljeförfarande

Filter skiljeförfarande är den logik som är inbyggd i Windows Filtering Platform (WFP) som används för att avgöra hur filter interagerar med varandra när du fattar beslut om filtrering av nätverkstrafik.

Filtrera skiljedomsbeteenden

Följande beteenden kännetecknar filtrets skiljedomssystem:

• All trafik kan inspekteras. Ingen trafik kan kringgå filter på ett visst lager.
• Trafik kan blockeras av ett pratbubblans filter via ett Veto även om ett filter med högre prioritet har tillåtit det.
• Flera leverantörer kan inspektera trafik på samma lager. Till exempel kan brandvägg följt av IDS-filter (intrångsidentifieringssystem) eller IPsec följt av QoS-filter (Quality of Service) undersöka trafiken på samma nivå.

Filtreringsmodell

Varje filterskikt är indelat i underlager ordnade efter prioritet (kallas även vikt). Nätverkstrafik passerar underlager från högsta prioritet till lägsta prioritet. Underlager skapas och hanteras av utvecklarna med hjälp av WFP-API:et.

I varje underlager sorteras filter efter vikt. Nätverkstrafik anges för matchande filter från högsta vikt till lägsta vikt.

Algoritmen för filtermedling tillämpas på alla underlager i ett lager och det slutliga filtreringsbeslutet fattas när alla underlager har utvärderats. Detta ger flera matchande funktioner.

I ett underlager utförs filter skiljeförfarande på följande sätt:

• Beräkna listan med matchande filter ordnade efter vikt från högsta till lägsta.
• Utvärdera matchande filter i ordning tills ett "Tillstånd" eller ett "Block" returneras (filter kan också returnera "Fortsätt") eller tills listan är slut.
• Hoppa över de återstående filtren och returnera åtgärden från det senast utvärderade filtret.

I ett lager utförs filter skiljeförfarande på följande sätt:

• Utför filter skiljeförfarande i varje underlager i ordning från högsta prioritet till lägsta prioritet.
• Utvärdera alla underlager även om ett underlager med högre prioritet har beslutat att blockera trafiken.
• Returnera den resulterande åtgärden baserat på de principregler som beskrivs i följande avsnitt.

Diagrammet nedan illustrerar ett exempel på en delnivåkonfiguration. De yttre rutorna representerar lager. De inre rutorna representerar underlager som innehåller filter. Jokertecknet (*) i ett filter innebär att all trafik matchar filtret.

Det enda sättet för ett filter att kringgås är om ett filter med högre vikt har tillåtit eller blockerat trafiken inom samma underskikt. Omvänt är ett sätt att se till att ett filter alltid ser all trafik inom ett lager att lägga till ett underlager som innehåller ett enda filter som matchar all trafik.

Konfigurerad åsidosättningsprincip

Reglerna som beskrivs nedan styr skiljedomsbesluten inom ett lager. Dessa regler används av filtermotorn för att avgöra vilken av åtgärderna på undernivå som tillämpas på nätverkstrafiken.

Den grundläggande principen är följande.

• Åtgärder utvärderas i prioritetsordning för underlager från högsta prioritet till lägsta prioritet.
• "Blockera" åsidosätter "Tillåt".
• "Block" är slutgiltigt (kan inte åsidosättas) och stoppar utvärderingen. Paketet ignoreras.

Den grundläggande principen stöder inte scenariot med ett undantag som inte åsidosättas av en brandvägg. Vanliga exempel på den här typen av scenario är:

• Fjärradministrationsporten måste öppnas även i närvaro av en brandvägg från tredje part.
• Komponenter som kräver att portar öppnas för att fungera (till exempel Universal Plug och Play UPnP). Om administratören uttryckligen har aktiverat komponenten bör brandväggen inte blockera trafiken tyst.

För att stödja ovanstående scenarier måste ett filtreringsbeslut göras svårare att åsidosätta än ett annat filtreringsbeslut genom att hantera behörigheten åsidosättning av åtgärden. Den här behörigheten implementeras som flaggan FWPS_RIGHT_ACTION_WRITE och den anges per filter.

Utvärderingsalgoritmen underhåller den aktuella åtgärden ("Tillåt" eller "Blockera") tillsammans med flaggan FWPS_RIGHT_ACTION_WRITE. Flaggan styr om ett underlager med lägre prioritet tillåts åsidosätta åtgärden. Genom att ange eller återställa flaggan FWPS_RIGHT_ACTION_WRITE i FWPS_CLASSIFY_OUT0-strukturen styr en provider hur åtgärder kan eller inte kan åsidosättas. Om flaggan har angetts anger den att åtgärden kan åsidosättas. Om flaggan saknas kan åtgärden inte åsidosättas.

Handling	Tillåt åsidosättning (FWPS_RIGHT_ACTION_WRITE har angetts)	Beskrivning
Tillåta	Ja	Trafiken kan blockeras på ett annat underlager. Detta kallas för ett mjukt tillstånd.
Tillåta	Nej	Trafiken kan endast blockeras på ett annat underlager av en pratbubblan Veto. Detta kallas för ett hårt tillstånd.
Block	Ja	Trafiken kan tillåtas på ett annat underlager. Detta kallas för ett mjukt block.
Block	Nej	Trafiken kan inte tillåtas på ett annat underlager. Detta kallas för ett hårt block.

Filteråtgärden kan anges genom att ange typ medlem i strukturen FWPM_ACTION0 till antingen FWP_ACTION_BLOCK eller FWP_ACTION_PERMIT. Tillsammans med åtgärdstypen exponerar ett filter även flaggan FWPM_FILTER_FLAG_CLEAR_ACTION_RIGHT. Om den här flaggan avmarkeras är åtgärdstypen hård och kan inte åsidosättas förutom när ett hårt tillstånd åsidosätts av en Veto som beskrivs senare, annars är den mjuk som kan åsidosättas av högprioriterade åtgärder.

I följande tabell visas standardbeteendet för filter- och pratbubblan.

Handling	Standardbeteendet
Filtertillstånd	Mjukt tillstånd
Pratbubblans tillstånd	Mjukt tillstånd
Filterblock	Hårt block
Pratbubblans block	Mjukt block

En Veto- är en "Blockera"-åtgärd som returnerades av filtret när flaggan FWPS_RIGHT_ACTION_WRITE återställdes innan filtret anropades. Ett Veto kommer att blockera trafik som tilläts med ett hårt tillstånd.

När ett Veto utfärdas är det en indikation på konflikt i konfigurationen. Följande åtgärder vidtas för att minska konflikten.

• Trafiken blockeras.

• En granskningshändelse genereras.

• Ett meddelande genereras.

  Not

  Meddelandet tas emot av alla entiteter som prenumererar på det. Detta inkluderar vanligtvis brandväggen (för att identifiera felkonfigurationer) eller program (för att identifiera om deras specifika filter är åsidosatt).

  Not

  Det finns inget obligatoriskt användargränssnitt (UI) som instansieras när ett "Hard Permit"-filter åsidosättas. Meddelandena om åsidosättningen skickas till alla leverantörer som registrerat sig för att ta emot dem, vilket gör det möjligt för brandväggar eller program som skapade filter för "Tillåt" att visa användargränssnittet som ber om användaråtgärder. Det finns inget värde i att ha ett plattformsgränssnittsmeddelande för dessa åsidosättningshändelser eftersom brandväggs-ISV:er som inte vill blockera tyst kan göra det genom att registrera sig på en annan plats i WFP, eller (mindre föredragna) hantera all logik i en pratbubblande drivrutin. ISV:er som tror att fråga användare är en bra idé som vill äga användarupplevelsen och skapa ett eget användargränssnitt.

Det åtgärdsbeteende som beskrivs ovan säkerställer att ett "hard permit"-filter inte tyst åsidosätts av ett "Blockera"-filter och omfattar scenariot där en fjärradministrationsport inte tillåts blockeras av brandväggen. För att tyst åsidosätta "Hard Permit"-filter måste en brandvägg lägga till sina filter i ett underlager med högre prioritet.

Not

Eftersom det inte finns något skiljeförfarande mellan lager kan trafik som tillåts med "hard permit" fortfarande blockeras på ett annat lager. Det är principförfattarens ansvar att se till att trafik tillåts på varje lager om det behövs.

Användarprogram som begär att portar ska öppnas lägger till åsidosättbara filter i ett underlager med låg prioritet. Brandväggen kan prenumerera på filtret lägga till meddelandehändelser och lägga till ett matchande filter efter verifiering av användare (eller princip).

Relaterade ämnen

Filtrera vikttilldelning