Filterarguatie

Filter-arbitrage is de logica die is ingebouwd in het Windows-filterplatform (WFP) dat wordt gebruikt om te bepalen hoe filters met elkaar communiceren bij het nemen van beslissingen over het filteren van netwerkverkeer.

Arbitragegedrag filteren

Het volgende gedrag heeft betrekking op het filterargubitatiesysteem:

• Al het verkeer kan worden geïnspecteerd. Er kan geen verkeer filters op een bepaalde laag omzeilen.
• Verkeer kan worden geblokkeerd door een bijschriftfilter via een Veto-, zelfs als een filter met een hogere prioriteit dit heeft toegestaan.
• Meerdere providers kunnen verkeer op dezelfde laag inspecteren. Een firewall, gevolgd door inbraakdetectiesysteemfilters (IDS) of IPsec gevolgd door QoS-filters (Quality of Service), kan bijvoorbeeld allemaal het verkeer op dezelfde laag onderzoeken.

Filtermodel

Elke filterlaag is onderverdeeld in sublagen gerangschikt op prioriteit (ook wel gewicht genoemd). Netwerkverkeer doorkruist sublagen van de hoogste prioriteit naar de laagste prioriteit. Sublagen worden gemaakt en beheerd door de ontwikkelaars met behulp van de WFP-API.

Binnen elke sublaag worden filters geordend op gewicht. Netwerkverkeer wordt aangegeven met overeenkomende filters van het hoogste gewicht naar het laagste gewicht.

Het algoritme voor filterargubitatie wordt toegepast op alle sublagen binnen een laag en de uiteindelijke filterbeslissing wordt genomen nadat alle sublagen zijn geëvalueerd. Dit biedt meerdere overeenkomende mogelijkheden.

Binnen een sublaag wordt filterarguatie als volgt uitgevoerd:

• Bereken de lijst met overeenkomende filters gesorteerd op gewicht van hoog naar laag.
• Evalueer overeenkomende filters in volgorde totdat een 'Toestaan' of 'Blokkeren' wordt geretourneerd (filters kunnen ook Doorgaan retourneren) of totdat de lijst is uitgeput.
• Sla de resterende filters over en retourneer de actie van het laatst geëvalueerde filter.

Binnen een laag wordt filterarguatie als volgt uitgevoerd:

• Filterarguatie uitvoeren op elke sublaag, in volgorde van hoogste prioriteit tot laagste prioriteit.
• Evalueer alle sublagen, zelfs als een sublaag met een hogere prioriteit heeft besloten het verkeer te blokkeren.
• Retourneer de resulterende actie op basis van de beleidsregels die in de volgende sectie worden beschreven.

In het onderstaande diagram ziet u een voorbeeldconfiguratie van een sublaag. De buitenste vakken vertegenwoordigen lagen. De binnenste vakken vertegenwoordigen sublagen die filters bevatten. Het jokerteken (*) in een filter betekent dat al het verkeer overeenkomt met het filter.

De enige manier om een filter te omzeilen is als een filter met een hoger gewicht het verkeer binnen dezelfde sublaag heeft toegestaan of geblokkeerd. Een manier om ervoor te zorgen dat een filter altijd al het verkeer binnen een laag ziet, is door een sublaag toe te voegen die één filter bevat dat overeenkomt met al het verkeer.

Configureerbaar onderdrukkingsbeleid

De hieronder beschreven regels bepalen de arbitragebeslissingen binnen een laag. Deze regels worden door de filterengine gebruikt om te bepalen welke van de sublaagacties wordt toegepast op het netwerkverkeer.

Het basisbeleid is als volgt.

• Acties worden geëvalueerd in volgorde van prioriteit van sublagen van hoogste prioriteit naar laagste prioriteit.
• 'Blokkeren' overschrijft 'Toestaan'.
• Blokkeren is definitief (kan niet worden overschreven) en stopt de evaluatie. Het pakket wordt verwijderd.

Het basisbeleid biedt geen ondersteuning voor het scenario van een uitzondering die niet wordt overschreven door een firewall. Typische voorbeelden van dit type scenario zijn:

• Externe beheerpoort moet worden geopend, zelfs in aanwezigheid van een firewall van derden.
• Onderdelen waarvoor poorten moeten worden geopend om te kunnen functioneren (bijvoorbeeld Universal Plug en Play UPnP). Als de beheerder het onderdeel expliciet heeft ingeschakeld, mag de firewall het verkeer niet op de achtergrond blokkeren.

Om de bovenstaande scenario's te ondersteunen, moet een filterbeslissing moeilijker worden gemaakt om te overschrijven dan een andere filterbeslissing door de machtiging voor het negeren van de actie te beheren. Deze machtiging wordt geïmplementeerd als de vlag FWPS_RIGHT_ACTION_WRITE en wordt ingesteld op basis van een filter.

Het evaluatie-algoritme onderhoudt de huidige actie ('Toestaan' of 'Blokkeren') samen met de vlag FWPS_RIGHT_ACTION_WRITE. De vlag bepaalt of een sublaag met een lagere prioriteit de actie mag overschrijven. Door de vlag FWPS_RIGHT_ACTION_WRITE in de FWPS_CLASSIFY_OUT0-structuur in te stellen of opnieuw in te stellen, bepaalt een provider hoe acties wel of niet kunnen worden overschreven. Als de vlag is ingesteld, geeft deze aan dat de actie kan worden overschreven. Als de vlag ontbreekt, kan de actie niet worden overschreven.

Actie	Onderdrukking toestaan (FWPS_RIGHT_ACTION_WRITE is ingesteld)	Beschrijving
Toestaan	Ja	Het verkeer kan worden geblokkeerd op een andere sublaag. Dit wordt een zachte vergunning genoemd.
Toestaan	Nee	Het verkeer kan alleen op een andere sublaag worden geblokkeerd door een bijschrift Veto-. Dit wordt een harde vergunning genoemd.
Blokkeren	Ja	Het verkeer kan worden toegestaan op een andere sublaag. Dit wordt een zacht blok genoemd.
Blokkeren	Nee	Het verkeer kan niet worden toegestaan op een andere sublaag. Dit wordt een hard blok genoemd.

De filteractie kan worden ingesteld door het type lid in de structuur in te stellen FWPM_ACTION0 op FWP_ACTION_BLOCK of FWP_ACTION_PERMIT. Naast het actietype wordt met een filter ook de vlag FWPM_FILTER_FLAG_CLEAR_ACTION_RIGHTweergegeven. Als deze vlag is gewist, is het actietype moeilijk en kan het niet worden overschreven, behalve wanneer een harde vergunning wordt overschreven door een Veto- zoals later uitgelegd, anders is het zacht dat kan worden overschreven door actie met hoge prioriteit.

De volgende tabel bevat het standaardgedrag voor filter- en bijschriftacties.

Actie	Standaardgedrag
Filtervergunning	Zachte vergunning
Bijschrift toestaan	Zachte vergunning
Filterblok	Hard blok
Bijschriftblok	Zacht blok

Een Veto- is een actie Blokkeren die door het filter wordt geretourneerd wanneer de FWPS_RIGHT_ACTION_WRITE vlag opnieuw is ingesteld voordat het filter werd aangeroepen. Een Veto- blokkeert verkeer dat met een harde vergunning is toegestaan.

Wanneer een Veto- wordt uitgegeven, is het een indicatie van een conflict in de configuratie. De volgende acties worden uitgevoerd om het conflict te verhelpen.

• Het verkeer wordt geblokkeerd.

• Er wordt een controlegebeurtenis gegenereerd.

• Er wordt een melding gegenereerd.

  Notitie

  De melding wordt ontvangen door alle entiteiten die zich hierop hebben geabonneerd. Dit omvat doorgaans de firewall (om onjuiste configuraties te detecteren) of toepassingen (om te detecteren of hun specifieke filter wordt overschreven).

  Notitie

  Er is geen verplichte gebruikersinterface (UI) geïnstantieerd wanneer een filter 'Harde vergunning' wordt overschreven. De meldingen van de onderdrukking worden verzonden naar elke provider die is geregistreerd om ze te ontvangen, waardoor firewalls, of de toepassingen die de filters 'Toestaan' hebben gemaakt, worden weergegeven om de gebruikersinterface weer te geven die vraagt om gebruikersactie. Er is geen waarde in het hebben van een platform-UI-melding voor deze onderdrukkingsgebeurtenissen, omdat firewall-ISV's die dit niet op de achtergrond willen blokkeren, dit kunnen doen door zich te registreren op een andere locatie in WFP of (minder voorkeur) al hun logica in een call-outstuurprogramma af te handelen. ISV's die denken dat het vragen aan gebruikers een goed idee is, willen eigenaar zijn van de gebruikerservaring en hun eigen gebruikersinterface maken.

Het hierboven beschreven beperkingsgedrag zorgt ervoor dat een filter 'Harde vergunning' niet op de achtergrond wordt overschreven door een blokfilter en behandelt het scenario waarin een poort voor extern beheer niet door de firewall mag worden geblokkeerd. Om de filters 'Harde vergunning' op de achtergrond te overschrijven, moet een firewall de filters toevoegen binnen een sublaag met een hogere prioriteit.

Notitie

Omdat er geen arbitrage tussen lagen is, kan verkeer dat is toegestaan met 'Harde vergunning' nog steeds worden geblokkeerd op een andere laag. Het is de verantwoordelijkheid van de beleidsauteur om ervoor te zorgen dat verkeer zo nodig op elke laag wordt toegestaan.

Gebruikerstoepassingen die poorten aanvragen om te worden geopend, voegen overschrijfbare filters toe aan een sublaag met lage prioriteit. De firewall kan zich abonneren op het filter meldingsevenementen toevoegen en een overeenkomend filter toevoegen na validatie van de gebruiker (of het beleid).

Verwante onderwerpen

toewijzing van filtergewicht