Arbitraggio filtro

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 arbitraggio

I comportamenti seguenti caratterizzano il sistema di arbitraggio dei filtri:

• Tutto il traffico può essere controllato. Nessun traffico può ignorare i filtri a un determinato livello.
• Il traffico può essere bloccato da un filtro callout tramite un Veto anche se un filtro con priorità più alta lo ha consentito.
• 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 per 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 la corrispondenza dei filtri dal peso più alto al peso più basso.

L'algoritmo di arbitraggio 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 layer, l'arbitraggio 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 in 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'arbitraggio 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 sotto layer 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.

di configurazione di livello secondario di esempio

L'unico modo per ignorare un filtro è se un filtro di peso maggiore ha consentito o bloccato il traffico all'interno dello stesso livello secondario. Viceversa, un modo per garantire che un filtro visualizzi sempre tutto il traffico all'interno di un livello consiste nell'aggiungere un sotto layer che contiene 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.

La politica di base è la seguente.

• 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 il funzionamento (ad esempio, UPnP UPnP di Plug and Play universale). Se l'amministratore ha abilitato in modo esplicito il componente, il firewall non deve bloccare automaticamente il traffico.

Per supportare gli scenari precedenti, è necessario prendere una decisione di filtro più difficile 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 mantiene l'azione corrente ("Consenti" o "Blocca") insieme al flag FWPS_RIGHT_ACTION_WRITE. Il flag controlla se un livello secondario con priorità inferiore è autorizzato a eseguire l'override dell'azione. Impostando o reimpostando il flag di FWPS_RIGHT_ACTION_WRITE nella struttura FWPS_CLASSIFY_OUT0, un provider regola come eseguire l'override delle azioni o non può essere sottoposto 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 tipo di membro nella struttura FWPM_ACTION0 su 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 è soft che può essere sostituito 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 include in genere il firewall (per rilevare configurazioni non corretta) o le applicazioni (per rilevare se il filtro specifico è sottoposto a override).

  Nota

  Non viene creata alcuna 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, che consente 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 nella presenza di una notifica dell'interfaccia utente della piattaforma per questi eventi di override perché gli ISV del firewall che non vogliono bloccare in modo invisibile all'utente possono farlo registrandosi in un luogo diverso nel WFP o (meno preferito) gestire tutta la logica in un driver di call-out. Gli ISV che pensano di richiedere agli utenti è una buona idea che voglia possedere l'esperienza utente e creare la propria interfaccia utente.

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

Le applicazioni utente che richiedono l'apertura delle porte aggiungono 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 peso filtro