Description

The FwpmFilterAdd0 function adds a new filter object to the system.

Parameters

engineHandle [in]

Handle for an open session to the filter engine. Call FwpmEngineOpen0 to open a session to the filter engine.

filter [in]

The filter object to be added.

sd [in, optional]

Security information about the filter object.

id [out, optional]

The runtime identifier for this filter.

Return value

Remarks

FwpmFilterAdd0 adds the filter to the specified sub-layer at every filtering layer in the system.

Some fields in the FWPM_FILTER0 structure are assigned by the system, not the caller, and are ignored in the call to FwpmFilterAdd0.

If the caller supplies a NULL security descriptor, the system will assign a default security descriptor.

To block connections to particular locations, add a FWP_ACTION_BLOCK filter specifying the local address at the FWPM_LAYER_ALE_AUTH_CONNECT_V* layer, or add a FWP_ACTION_BLOCK filter without specifying the local address at the FWPM_LAYER_ALE_RESOURCE_ASSIGNMENT_V* layer.

If a local address is specified at the resource assignment layer, an implicit bind would succeed because address, address type, and port may come back as FWP_EMPTY.

The FWPM_FILTER0 structure can label a filter as a boot-time or persistent filter. Boot-time filters are added to the Base Filtering Engine (BFE) when the TCP/IP driver starts, and are removed once the BFE finishes initialization. Persistent objects are added when the BFE starts.

This function cannot be called from within a read-only transaction, it fails with FWP_E_INCOMPATIBLE_TXN. See Object Management for more information about transactions.

The caller needs the following access rights:

• FWPM_ACTRL_ADD access to the filter's container
• FWPM_ACTRL_ADD_LINK access to the provider (if any)
• FWPM_ACTRL_ADD_LINK access to the applicable layer
• FWPM_ACTRL_ADD_LINK access to the applicable sub-layer
• FWPM_ACTRL_ADD_LINK access to the callout (if any)
• FWPM_ACTRL_ADD_LINK access to the provider context (if any). See Access Control for more information.

To add a filter that references a callout, invoke the functions in the following order.

• Call FwpsCalloutRegister0 (documented in the Windows Driver Kit (WDK)), to register the callout with the filter engine.
• Call FwpmCalloutAdd0 to add the callout to the system.
• Call FwpmFilterAdd0 to add the filter that references the callout to the system.

By default filters that reference callouts that have been added but have not yet registered with the filter engine are treated as Block filters.

FwpmFilterAdd0 is a specific implementation of FwpmFilterAdd. See WFP Version-Independent Names and Targeting Specific Versions of Windows for more information.

Examples

The following C++ example shows how to initialize and add a filter using FwpmFilterAdd0 that specifically blocks traffic on IP V4 for all applications.

// Add filter to block traffic on IP V4 for all applications.
//
FWPM_FILTER0      fwpFilter;
FWPM_SUBLAYER0    fwpFilterSubLayer;

RtlZeroMemory(&fwpFilter, sizeof(FWPM_FILTER0));

fwpFilter.layerKey = FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4;
fwpFilter.action.type = FWP_ACTION_BLOCK;

if (&fwpFilterSubLayer.subLayerKey != NULL)
    fwpFilter.subLayerKey = fwpFilterSubLayer.subLayerKey;

fwpFilter.weight.type = FWP_EMPTY; // auto-weight.
fwpFilter.numFilterConditions = 0; // this applies to all application traffic
fwpFilter.displayData.name = L"Receive/Accept Layer Block";
fwpFilter.displayData.description = L"Filter to block all inbound connections.";

printf("Adding filter to block all inbound connections.\n");
result = FwpmFilterAdd0(engineHandle, &fwpFilter, NULL, NULL);

if (result != ERROR_SUCCESS)
    printf("FwpmFilterAdd0 failed. Return value: %d.\n", result);
else
    printf("Filter added successfully.\n");

See also

• FwpsCalloutRegister0
• FwpmCalloutAdd0
• FWPM_FILTER0
• Management Functions
• WFP Functions
• WFP Version-Independent Names and Targeting Specific Versions of Windows