Filtrare l'arbitrato

L'arbitraggio dei filtri è la logica integrata nella piattaforma di filtro di Windows (WFP) usata per determinare il modo in cui i filtri interagiscono tra loro quando si effettuano decisioni di filtro del traffico di rete.

Filtrare i comportamenti di arbitrato

I comportamenti seguenti caratterizzano il sistema di arbitrato del filtro:

• Tutto il traffico può essere controllato. Nessun traffico può ignorare i filtri a un determinato livello.
• Il traffico può essere bloccato da un filtro di callout tramite un veto anche se è consentito un filtro con priorità più alta.
• Più provider possono controllare il traffico allo stesso livello. Ad esempio, il firewall seguito da filtri del sistema di rilevamento delle intrusioni (IDS) o IPsec seguito da filtri QoS (Quality of Service) può esaminare tutto il traffico allo stesso livello.

Filtro del modello

Ogni livello filtro è suddiviso in livelli secondari ordinati in base alla priorità (detto anche peso). Il traffico di rete attraversa i livelli secondari dalla priorità più alta alla priorità più bassa. I livelli secondari vengono creati e gestiti dagli sviluppatori usando l'API WFP.

All'interno di ogni livello secondario, i filtri vengono ordinati in base al peso. Il traffico di rete è indicato per associare i filtri dal peso più alto al peso più basso.

L'algoritmo di arbitrato del filtro viene applicato a tutti i livelli secondari all'interno di un livello e la decisione finale di filtro viene presa dopo la valutazione di tutti i livelli secondari. In questo modo è disponibile più funzionalità di corrispondenza.

All'interno di un sotto-livello, l'arbitrato del filtro viene eseguito come segue:

• Calcolare l'elenco dei filtri corrispondenti ordinati in base al peso dal più alto al più basso.
• Valutare i filtri corrispondenti nell'ordine fino a quando non viene restituito un "Permit" o un "Block" (i filtri possono restituire anche "Continua") o fino a quando l'elenco non viene esaurito.
• Ignorare i filtri rimanenti e restituire l'azione dall'ultimo filtro valutato.

All'interno di un livello, l'arbitrato del filtro viene eseguito come segue:

• Eseguire l'arbitraggio dei filtri a ogni livello secondario in ordine dalla priorità più alta alla priorità più bassa.
• Valutare tutti i livelli secondari anche se un livello secondario con priorità più alta ha deciso di bloccare il traffico.
• Restituisce l'azione risultante in base alle regole dei criteri descritte nella sezione seguente.

Il diagramma seguente illustra una configurazione di livello secondario di esempio. Le caselle esterne rappresentano i livelli. Le caselle interne rappresentano livelli secondari che contengono filtri. Il carattere jolly (*) in un filtro indica che tutto il traffico corrisponde al filtro.

L'unico modo per ignorare un filtro è se un filtro di peso maggiore ha consentito o bloccato il traffico all'interno dello stesso sotto layer. Al contrario, un modo per garantire che un filtro veda sempre tutto il traffico all'interno di un livello consiste nell'aggiungere un sotto layer contenente un singolo filtro che corrisponde a tutto il traffico.

Criteri di override configurabili

Le regole descritte di seguito regolano le decisioni di arbitrato all'interno di un livello. Queste regole vengono usate dal motore di filtro per decidere quale delle azioni di livello secondario viene applicata al traffico di rete.

I criteri di base sono i seguenti.

• Le azioni vengono valutate in ordine di priorità dei livelli secondari, dalla priorità più alta alla priorità più bassa.
• "Blocca" esegue l'override di "Permit".
• "Block" è finale (non può essere sottoposto a override) e arresta la valutazione. Il pacchetto viene rimosso.

I criteri di base non supportano lo scenario di un'eccezione non sottoposto a override da un firewall. Esempi tipici di questo tipo di scenario sono:

• La porta di amministrazione remota deve essere aperta anche in presenza di un firewall di terze parti.
• Componenti che richiedono l'apertura delle porte per funzionare (ad esempio, Universal Plug and Play UPnP). Se l'amministratore ha abilitato in modo esplicito il componente, il firewall non deve bloccare automaticamente il traffico.

Per supportare gli scenari precedenti, è necessario rendere più difficile eseguire l'override di una decisione di filtro rispetto a un'altra decisione di filtro gestendo l'autorizzazione di override dell'azione. Questa autorizzazione viene implementata come flag FWPS_RIGHT_ACTION_WRITE e viene impostata in base al filtro.

L'algoritmo di valutazione gestisce l'azione corrente ("Consenti" o "Blocca") insieme al flag FWPS_RIGHT_ACTION_WRITE . Il flag controlla se un livello secondario con priorità inferiore può eseguire l'override dell'azione. Impostando o reimpostando il flag di FWPS_RIGHT_ACTION_WRITE nella struttura FWPS_CLASSIFY_OUT0 , un provider controlla come le azioni possono o non possono essere sottoposte a override. Se il flag è impostato, indica che l'azione può essere sottoposta a override. Se il flag è assente, l'azione non può essere sottoposta a override.

L'azione di filtro può essere impostata impostando il membro del tipo nella struttura FWPM_ACTION0su FWP_ACTION_BLOCK o FWP_ACTION_PERMIT. Insieme al tipo di azione, un filtro espone anche il flag FWPM_FILTER_FLAG_CLEAR_ACTION_RIGHT. Se questo flag viene cancellato, il tipo di azione è difficile e non può essere sottoposto a override tranne quando un permesso rigido viene sottoposto a override da un veto come illustrato più avanti, altrimenti è flessibile che può essere sottoposto a override da un'azione con priorità elevata.

La tabella seguente elenca il comportamento predefinito per le azioni di filtro e callout.

Un veto è un'azione "Blocca" restituita dal filtro quando il flag FWPS_RIGHT_ACTION_WRITE è stato reimpostato prima di chiamare il filtro. Un veto bloccherà il traffico consentito con un permesso rigido.

Quando viene emesso un veto , si tratta di un'indicazione di conflitto nella configurazione. Per attenuare il conflitto vengono eseguite le azioni seguenti.

• Il traffico è bloccato.

• Viene generato un evento di controllo.

• Viene generata una notifica.

  Nota

  La notifica viene ricevuta da tutte le entità che vi hanno sottoscritto. Questo includerà in genere il firewall (per rilevare configurazioni non corretta) o le applicazioni (per rilevare se il filtro specifico è sottoposto a override).

  Nota

  Non è disponibile un'istanza dell'interfaccia utente obbligatoria quando viene eseguito l'override di un filtro "Hard Permit". Le notifiche dell'override vengono inviate a qualsiasi provider registrato per riceverli, consentendo ai firewall o alle applicazioni che hanno creato i filtri "Consenti", di mostrare l'interfaccia utente che richiede l'azione dell'utente. Non esiste alcun valore in presenza di una notifica dell'interfaccia utente della piattaforma per questi eventi di override poiché gli ISV del firewall che non vogliono bloccare in modo invisibile all'utente possono farlo registrando in un luogo diverso nel WFP o (meno preferito) gestire tutta la loro logica in un driver call-out. Gli ISV che pensano che la richiesta agli utenti sia una buona idea vuole possedere l'esperienza utente e creare un'interfaccia utente personalizzata.

Il comportamento di mitigazione descritto in precedenza garantisce che un filtro "Hard Permit" non venga sottoposto a override in modo automatico da un filtro "Blocca" e copre lo scenario in cui una porta di amministrazione remota non può essere bloccata dal firewall. Per eseguire l'override in modo automatico dei filtri "Hard Permit" un firewall deve aggiungere i relativi filtri all'interno di un livello secondario con priorità superiore.

Le applicazioni utente che richiedono l'apertura di porte da aggiungere filtri sostituibili a un livello secondario con priorità bassa. Il firewall può sottoscrivere il filtro aggiungere eventi di notifica e aggiungere un filtro corrispondente dopo la convalida dell'utente (o dei criteri).

Argomenti correlati

Assegnazione di pesi dei filtri