WFP: Layer and filter conditions to capture all packets?

Question

Please, can you tell me, which layer and which filter conditions should I use in order to capture all IP packets, like in promiscuous mode? I try to use

FWPM_LAYER_ALE_RESOURCE_ASSIGNMENT_V4 layer and

FWPM_CONDITION_ALE_PROMISCUOUS_MODE condition,

but

FwpmFilterAdd0 returns error "An FWP_VALUE or FWPM_CONDITION_VALUE is of the wrong type".

Code follows:
...

filter.layerKey = FWPM_LAYER_ALE_RESOURCE_ASSIGNMENT_V4;

//FWPM_LAYER_ALE_FLOW_ESTABLISHED_V4

filter.action.type = FWP_ACTION_CALLOUT_INSPECTION;

// We're only doing inspection.

filter.weight.type = FWP_EMPTY;

// auto-weight.

...

filterConditions[0].fieldKey = FWPM_CONDITION_ALE_PROMISCUOUS_MODE;

filterConditions[0].conditionValue.type = FWP_UINT8;

filterConditions[0].conditionValue.uint8 = SIO_RCVALL;

 

Answer 1

You are wanting to see all packets coming into, or leaving the machine correct?

You can accomplish this placing by filters at the FWPM_LAYER_INBOUND_IPPACKET_Vx, FWPM_LAYER_OUTBOUND_IPPACKET_Vx, and FWPM_LAYER_IPFORWARD_Vx.

The code above would add a filter that would only get triggered when a resource (socket) was allocated and placed in Promiscuous Mode.

To capture all packets, you can specify 0 as the numFilterConditions, and the filter will match all packets.

To correct the above code, you would have this:

filterConditions[0].fieldKey              = FWPM_CONDITION_ALE_PROMISCUOUS_MODE;
filterConditions[0].conditionValue.type   = FWP_UINT32;
filterConditions[0].conditionValue.uint32 = SIO_RCVALL;

 

 

(On msdn documentation review, it appears the wrong data type was disclosed for FWPM_CONDITION_ALE_PROMISCUOUS_MODE, I will follow up to get that remedied).




 

---

Dusty Harper [MSFT]
Microsoft Corporation
------------------------------------------------------------
This posting is provided "AS IS", with NO warranties and confers NO rights
------------------------------------------------------------

Answer 2

Thank you very much for helpfull information. Yes, I want to inspect each packet coming into, or leaving the machine. I add callouts to  FWPM_LAYER_INBOUND_IPPACKET_V4, FWPM_LAYER_OUTBOUND_IPPACKET_V4 and FWPM_LAYER_IPFORWARD_V4 layers. Now, inbound and outbound callouts at inbound and outbound layers are called for each packet. Thank you for your helping! But I faced with the following problem: the inMetaValues doesn't contain process_path value at inbound and outbound layers. The FWPS_IN_METADATA_FIELD_PRESENT(inMetaValues, FWPS_METADATA_FIELD_PROCESS_PATH) returns FALSE. I know, I can use another layer, for example, STREAM layer, at STREAM layer I can get process_path value, but at STREAM layer I can't capture all packets. May be it is possible to capture all packets of the machine on another layer, but with ability to get process_path value?

Answer 3

You can get the PROCESS_PATH at FWPM_LAYER_ALE_*.  in this case, you would register at FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V* (for incoming packets) and FWPM_LAYER_ALE_AUTH_CONNECT_V* (for the outgoing packets).  THe issue with solely sitting at these layers is you may miss a few packets inbound (scenario where a packet comes in and is dropped by the stack before you're callout is invoked) or classify packets that do not actually leave the machine (scenario where a packet invokes your callout, and gets dropped at a higher layer or by the stack).

If you add these layers to the layers previously mentioned, your needs should be met.

---

Dusty Harper [MSFT]
Microsoft Corporation
------------------------------------------------------------
This posting is provided "AS IS", with NO warranties and confers NO rights
------------------------------------------------------------

Answer 4

Registering at FWPM_LAYER_ALE_AUTH_CONNECT_V* layer will work for all (TCP and non-TCP) outgoing packets, but registering at FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V* will work for TCP-only incoming packets, right?

Answer 5

Both of these layers  (CONNECT and RECV_ACCEPT) are for any protocol.

---

Dusty Harper [MSFT]
Microsoft Corporation
------------------------------------------------------------
This posting is provided "AS IS", with NO warranties and confers NO rights
------------------------------------------------------------

Answer 6

 May be it is possible to capture all packets of the machine on another layer, but with ability to get process_path value?

As Dusty pointed out, application path is only available from ALE layers. However any ALE layer fields can be "tagged" to a flow and be made available to STREAM (TCP data segment), STREAM_PACKET (Win7+, TCP data/control packets), DATAGRAM_DATA(UDP and ICMP), and TRANSPORT layers (Win7+, all non- forwarded packets).

A driver-defined context can be made associated with a flow via FwpsFlowAssociateContext0. It can be invoked from ALE_FLOW_ESTABLISHED layer in Vista/WS08; and in Win7 it can be invoked from ALE_AUTH_CONNECT and ALE_AUTH_RECV_ACCEPT as well. For example, in Win7, you could associate context during ALE_AUTH_RECV_ACCEPT and all TCP packets belonging to the same flow (including 3-way handshake) will be indicated to the STREAM_PACKET layer along with your context. If the context association is done within ALE_FLOW_ESTABLISHED, then the 3-way handshake will be classified w/o the context. Similarly, UDP/ICMP packets will be classified to DATAGRAM_DATA layers with a context, if one is associated with the flow. Lastly, in Win7 the context will also be classified at TRANSPORT layers for all protocol, if associated.

Hope this helps,
Biao.W.

P.S. Below are some example WFP invocation sequences showing ordering of TRANSPORT, ALE, DATAGRAM_DATA/STREAM_PACKET, and STREAM layers.

Example classify sequence for inbound TCP Flow

1)   INBOUND_TRANSPORT (SYN)
2)   STREAM_PACKET(FWP_DIRECTION_INBOUND, SYN)
3)   ALE_AUTH_RECV_ACCEPT (SYN)

---  Assuming flow is authorized by firewall  ---

4)   STREAM_PACKET(FWP_DIRECTION_OUTBOUND, SYN-ACK)
5)   OUTBOUND_TRANSPORT(SYN-ACK)
6)   INBOUND_TRANSPORT (ACK)
7)   STREAM_PACKET(FWP_DIRECTION_INBOUND, ACK)
8)   ALE_FLOW_ESTABLISHED

9)   INBOUND_TRANSPORT (data packet)
10) STREAM_PACKET(FWP_DIRECTION_INBOUND, data packet)
11) STREAM (_RECV_, data segment)
...

Example classify sequence for outbound TCP Flow

1) ALE_AUTH_CONNECT

---  Assuming flow is authorized by firewall  ---

2)   STREAM_PACKET(FWP_DIRECTION_OUTBOUND, SYN)
3)   OUTBOUND_TRANSPORT(SYN)
4)   INBOUND_TRANSPORT (SYN-ACK)
5)   STREAM_PACKET(FWP_DIRECTION_INBOUND, SYN-ACK)
6)   STREAM_PACKET(FWP_DIRECTION_OUTBOUND, ACK)
7)   OUTBOUND_TRANSPORT(ACK)
8)   ALE_FLOW_ESTABLISHED ()

9)   STREAM (_SEND_, data segment)
10) STREAM_PACKET(FWP_DIRECTION_OUTBOUND, data packet)
11) OUTBOUND_TRANSPORT (data packet)
...

Example classify sequence for inbound UDP/ICMP Flow

1)   INBOUND_TRANSPORT (first packet)
2)   ALE_AUTH_RECV_ACCEPT (first packet)

---  Assuming flow is authorized by firewall  ---

3)   ALE_FLOW_ESTABLISHED ()
4)   DATAGRAM_DATA(FWP_DIRECTION_INBOUND, first packet)
5)   DATAGRAM_DATA(FWP_DIRECTION_OUTBOUND, response packet)
6)   OUTBOUND_TRANSPORT(response packet)
...

Example classify sequence for outbound UDP/ICMP Flow

1)   ALE_AUTH_CONNECT (first packet)

---  Assuming flow is authorized by firewall  ---

2)   ALE_FLOW_ESTABLISHED
3)   DATAGRAM_DATA(FWP_DIRECTION_OUTBOUND, first packet)
4)   OUTBOUND_TRANSPORT(first packet)
5)   INBOUND_TRANSPORT(response packet)
6)   DATAGRAM_DATA(FWP_DIRECTION_INBOUND, response packet)
...

Answer 7

Thank you very much for detailed information! I realize, that I need to use FwpsFlowAssociateContext0 in order to tag process_path to flow and access tagged value process_path from STREAM and DATAGRAM_DATA callouts. I use msnmntr sample as an example for implementing such functionality. In msnmntr sample in FLOW_ESTABLISHED callout the FwpsFlowAssociateContext0 function is called, and in STREAM callout this associated context is accessible. It works fine! But, in msnmntr only TCP packets are captured. 

I try to do the same for UDP packets and faced with the following problem: the CoCreateFlowEstablishedCalloutV4 is called for UDP, but FwpsAssociateFlowContext0 returns "invalid parameter":

Log file:

-Log- MonitorCoFlowEstablishedCalloutV4.

-Log- MonitorCoCreateFlowContext: process path '\device\harddiskvolume1\windows\system32\nslookup.exe'.

-Log- MonitorCoFlowEstablishedCalloutV4. Flow context can't be associated with DATAGRAM_DATA layer,status=0xC000000D, calloutId=287, flowcontextLocal=18446744071631366296, flowHandle=352.

-Log- MonitorCoDatagramDataCalloutV4. FlowContext=0

-Log- MonitorCoOutboundIPPacketCalloutV4. FlowContext=0

I use nslookup utility to generate UDP traffic. All parameters are valid, but flowcontext is not associated with UDP flow.

Code follows:

status = FwpsFlowAssociateContext0(flowHandle, FWPS_LAYER_DATAGRAM_DATA_V4, DatagramData, flowContextLocal);

if (!NT_SUCCESS(status))

{

      #if DBG

      DbgPrint("-Log- MonitorCoFlowEstablishedCalloutV4. Flow context can't be associated with DATAGRAM_DATA layer,"\

                            "status=0x%X, calloutId=%u, flowcontextLocal=%I64u, flowHandle=%I64u.\n", 

                            status, DatagramData, flowContextLocal, flowHandle);

      #endif

      classifyOut->actionType = FWP_ACTION_CONTINUE;

      goto cleanup;

}

System is Vista sp2 (x86). 

May be the special actions are required in order to successfully accosiate flow context with UDP flow?

Answer 8

You may want to review the "DD Proxy" sample to see the logic to associate context w/ UDP flows.

Thanks,
Biao.W.