locked
having the same filter applied twice results in a circular behabiour RRS feed

  • Question

  • hello,

    I am playing with filters at FWPM_LAYER_ALE_CONNECT_REDIRECT_V4 layer, my sublayer:

     

    filter.weight.type  = FWP_UINT8;
    filter.weight.uint8 = 0xe;
    filter.subLayerKey = TCP_REDIRECTOR_SUBLAYER;
    filterConditions[0].fieldKey = FWPM_CONDITION_IP_REMOTE_ADDRESS;
    filterConditions[0].matchType = FWP_MATCH_EQUAL;
    
    RtlZeroMemory(&remoteAddrAndMask, sizeof(FWP_V4_ADDR_AND_MASK));
    remoteAddrAndMask.addr = remoteAddr;
    remoteAddrAndMask.mask = 0xFFFFFF00;
    
    filterConditions[0].conditionValue.type = FWP_V4_ADDR_MASK;
    filterConditions[0].conditionValue.v4AddrMask = &remoteAddrAndMask;
    
    
    If I apply such filter twice, I get (in debugger output) endless attempts to redirect the traffic (from local host back into local host, my port). Is that expected? While this is an artificial example, the same happens if I specify filters for two overlapping IP ranges. Should I always monitor user input on app level and prevent overlapping IP ranges before such filters reach WFP or is there any 'internal' mechanism to ignore the overlapping (i.e. count it just once)?

     


    Alex
    Thursday, December 9, 2010 4:42 PM

Answers

  • This one is sorted out now. Had to add another filter with a higher weight, action type = permit and the following condition:

    	filterConditions[0].fieldKey =  FWPM_CONDITION_FLAGS;
    	filterConditions[0].matchType = FWP_MATCH_FLAGS_ANY_SET;
    	filterConditions[0].conditionValue.type = FWP_UINT32;
    	filterConditions[0].conditionValue.uint32 = FWP_CONDITION_FLAG_IS_REAUTHORIZE;
    

    Alternatively, this condition can be added to the inspecting filter:

    	filterConditions[1].fieldKey =  FWPM_CONDITION_FLAGS;
    	filterConditions[1].matchType = FWP_MATCH_FLAGS_NONE_SET;
    	filterConditions[1].conditionValue.type = FWP_UINT32;
    	filterConditions[1].conditionValue.uint32 = FWP_CONDITION_FLAG_IS_REAUTHORIZE;

    When REAUTHORIZE flag check is added to the conditions, the localRedirectTargetPID should be set to the actual PID of the local proxy, otherwise socket exception will happen.

    Still not sure why I can see my ClassifyFn called twice - the second time it's called I see that remoteAddressAndPort from the FWPS_CONNECT_REQUEST0 is already modified, so, the condition for my filter is not true and I expect ClassifyFn not to be triggered.


     


    Alex
    • Marked as answer by Doolav Tuesday, January 4, 2011 10:51 AM
    Tuesday, January 4, 2011 10:49 AM

All replies

  • No one faced this issue?
    Alex
    Monday, December 13, 2010 11:03 AM
  • Are you skipping packets that have already been inspected? If the return of FwpsQueryPacketInjectionState0 FWPS_PACKET_INJECTED_BY_SELF or FWPS_PACKET_PREVIOUSLY_INJECTED_BY_SELF, you shouldn't reinspect and just permit the packet (this is for inbound packets).

    Thursday, December 16, 2010 10:43 AM
  • Hello MattCpp,

    thank you for your reply, but I am doing redirection on ALE level (hence  FWPM_LAYER_ALE_CONNECT_REDIRECT_V4 filtering layer), so no per packet inspection/reinjection.

    I know such a mechanism [to prevent packet handling if it already was handled] does exist, but only in case of a per packet redirection. It was noticed in some forum that this was not implemented for ALE layers, but that info is very dated (2007 I think), so I wonder if things have changed since then in this sense? Can any developer from WFP team shed some light on it?

    Thanks again


    Alex
    Friday, December 17, 2010 11:54 AM
  • I have seen almost similar behavior. Same callout is called twice for the one connect() call.

    FWPS_BIND_REQUEST0 and FWPS_CONNECT_REQUEST0 structures have previousVersion and modifierFilterId fields. By traversing previousVersion list and calling FwpmFilterGetById0(... modifierFilterId) to get filter.action.calloutKey, you should be able to check if the same callout is already called. Maybe this could also be used for preventing circular behavior.

    It would be nice, if there is some flag to check this more easily??

    -- Antti

    Monday, December 20, 2010 6:34 PM
  • Hi Antti,

    yes, I tried the previousVersion field, it tells me that it was me who made the previous modification, and it returns me the previously modified src/dst port[ip address], so I have nothing to do at the present step. But then my classifyFn triggers again with the same effect. And so endlessly. I need some flag outside of classifyFn, so it would not be called at all after it gets called for the first time (as it happens when only one filter per IP address is applied).

    Thanks


    Alex
    Monday, December 20, 2010 10:01 PM
  • Just some observation - after checking

    UINT32 flags = inFixedValues->incomingValue[FWPS_FIELD_ALE_CONNECT_REDIRECT_V4_FLAGS].value.uint32;
    
    inside my classifyFn, I noticed that after it's called for the first two times, the value of this flag is 0x0, and ever after it's 0x4


    Alex
    Monday, December 20, 2010 10:36 PM
  • This one is sorted out now. Had to add another filter with a higher weight, action type = permit and the following condition:

    	filterConditions[0].fieldKey =  FWPM_CONDITION_FLAGS;
    	filterConditions[0].matchType = FWP_MATCH_FLAGS_ANY_SET;
    	filterConditions[0].conditionValue.type = FWP_UINT32;
    	filterConditions[0].conditionValue.uint32 = FWP_CONDITION_FLAG_IS_REAUTHORIZE;
    

    Alternatively, this condition can be added to the inspecting filter:

    	filterConditions[1].fieldKey =  FWPM_CONDITION_FLAGS;
    	filterConditions[1].matchType = FWP_MATCH_FLAGS_NONE_SET;
    	filterConditions[1].conditionValue.type = FWP_UINT32;
    	filterConditions[1].conditionValue.uint32 = FWP_CONDITION_FLAG_IS_REAUTHORIZE;

    When REAUTHORIZE flag check is added to the conditions, the localRedirectTargetPID should be set to the actual PID of the local proxy, otherwise socket exception will happen.

    Still not sure why I can see my ClassifyFn called twice - the second time it's called I see that remoteAddressAndPort from the FWPS_CONNECT_REQUEST0 is already modified, so, the condition for my filter is not true and I expect ClassifyFn not to be triggered.


     


    Alex
    • Marked as answer by Doolav Tuesday, January 4, 2011 10:51 AM
    Tuesday, January 4, 2011 10:49 AM