locked
Bypass the smb traffic RRS feed

  • Question

  • Hi All,

    I have a callout driver which has two layers AUTH_CONNECT and STREAM_LAYER, basically filtering the TCP/IP streams. But, I want to exclude SMB traffic from the filtering logic ie. I don't want my classify functions to be called when SMB traffic occures.

    Could you please tell me whether I can do this by setting some filters?

    Thanks,

    Krishnanand

    Tuesday, December 13, 2011 4:17 PM

Answers

  • SMB uses TCP 137/139/445, UDP 137/138

    You can create filters off of these protocol / port combinations to achieve your goal.  Alternatively, you could also add validation within your classifyFn to return FWP_ACTION_PERMIT for any of these ports.

     

    Hope this helps,

     


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------
    Tuesday, January 3, 2012 6:36 PM
    Moderator

All replies

  • Hi All,

    Could you please provide me an idea on how to perform this?

    Thanks,

    Krishnanand

    Tuesday, January 3, 2012 11:12 AM
  • SMB uses TCP 137/139/445, UDP 137/138

    You can create filters off of these protocol / port combinations to achieve your goal.  Alternatively, you could also add validation within your classifyFn to return FWP_ACTION_PERMIT for any of these ports.

     

    Hope this helps,

     


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------
    Tuesday, January 3, 2012 6:36 PM
    Moderator
  • Hi Dusty,

    Thank you so much for the reply.

    I have a filter set to classify only on TCP traffic. I will add a couple of more filters to exclude the ports 137/139/445.

    Hope the following works.

    tcp filter + filters to avoid ports 137/139/445.

    Filter to avoid port -

    filterConditions[0].fieldKey =  FWPM_CONDITION_IP_REMOTE_PORT ; 

    filterConditions[0].matchType = FWP_MATCH_NOT_EQUAL;

    filterConditions[0].conditionValue.type = FWP_UINT16;

    filterConditions[0].conditionValue.uint8 = 137;

    Thanks,

    Krishnanand

    Wednesday, January 4, 2012 9:58 AM
  • Hi Dusty,

    I don't want my callouts to be classified for the SMB ports 137/139/445. Also the driver need to be classifed for TCP traffic only. So I have added the following filter conditions.

     
    sCallout.classifyFn = ClassifyFunction;

    sCallout.notifyFn = NotifyFunction;

    sCallout.flags = 0;

    displayData.name = AUTH_CONNECT_CALLOUT_NAME;

    displayData.description = AUTH_CONNECT_CALLOUT_DESCRIPTION;


    // Filter conditions

    RtlZeroMemory(&filter, sizeof(FWPM_FILTER));

    filter.layerKey = FWPM_LAYER_ALE_AUTH_CONNECT_V4;

    filter.displayData.name = L"ALE Auth Connect filter.";

    filter.displayData.description = L"Connection requests.";

    filter.action.type = FWP_ACTION_CALLOUT_INSPECTION;

    filter.action.calloutKey = TEST_AUTH_CONNECT_CALLOUT_V4;

    filter.filterCondition = filterConditions;

    filter.subLayerKey = FWPM_SUBLAYER_UNIVERSAL;

    filter.weight.type = FWP_EMPTY;

    filter.numFilterConditions = 4;

    RtlZeroMemory(filterConditions, sizeof(filterConditions));


    filterConditions[0].fieldKey = FWPM_CONDITION_IP_PROTOCOL;

    filterConditions[0].matchType = FWP_MATCH_EQUAL;

    filterConditions[0].conditionValue.type = FWP_UINT8;

    filterConditions[0].conditionValue.uint8 = IPPROTO_TCP;


    filterConditions[1].fieldKey = FWPM_CONDITION_IP_REMOTE_PORT ;

    filterConditions[1].matchType = FWP_MATCH_NOT_EQUAL;

    filterConditions[1].conditionValue.type = FWP_UINT16;

    filterConditions[1].conditionValue.uint8 = 137;


    filterConditions[2].fieldKey = FWPM_CONDITION_IP_REMOTE_PORT ;

    filterConditions[2].matchType = FWP_MATCH_NOT_EQUAL;

    filterConditions[2].conditionValue.type = FWP_UINT16;

    filterConditions[2].conditionValue.uint8 = 139;


    filterConditions[3].fieldKey = FWPM_CONDITION_IP_REMOTE_PORT ;

    filterConditions[3].matchType = FWP_MATCH_NOT_EQUAL;

    filterConditions[3].conditionValue.type = FWP_UINT16;

    filterConditions[3].conditionValue.uint8 = 445;


    But it seems like these conditions don't exclude my callouts from classifying.
    Could you please tell me whether these conditions are right or not?

    Thanks,
    Krishnanand

    Thursday, February 23, 2012 12:02 PM
  • Hi,

    Multiple conditions with same fieldKey are OR'ed. With your conditions, e.g. port 137 doesn't match filterConditions[1], but it matches filterConditions[1] and the callout will be called.

    This should work better:

    filterConditions[1].fieldKey = FWPM_CONDITION_IP_REMOTE_PORT;
    filterConditions[1].matchType = FWP_MATCH_LESS;
    filterConditions[1].conditionValue.type = FWP_UINT16;
    filterConditions[1].conditionValue.uint8 = 137;
    
    filterConditions[2].fieldKey = FWPM_CONDITION_IP_REMOTE_PORT;
    filterConditions[2].matchType = FWP_MATCH_EQUAL;
    filterConditions[2].conditionValue.type = FWP_UINT16;
    filterConditions[2].conditionValue.uint8 = 138;
    
    filterConditions[3].fieldKey = FWPM_CONDITION_IP_REMOTE_PORT;
    filterConditions[3].matchType = FWP_MATCH_GREATER;
    filterConditions[3].conditionValue.type = FWP_UINT16;
    filterConditions[3].conditionValue.uint8 = 445;
    

    -- Antti

    Thursday, February 23, 2012 3:10 PM
  • Remember that multiple conditions are OR'd together.  essentially you've said filter if remote port is !137 || !139 || !445.  When a packet with remote port of 139 comes through, you will classify because it is !137.

    Hope this helps,


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

    Thursday, February 23, 2012 4:36 PM
    Moderator
  • Hi Both,

    Thank you for your reply.

    Does that mean, we cannot exclude these ports by setting the filters alone ?

    I will try what Antti suggested.

    Antti - I guess the port number is 139 in the following condition, please correct me if I am wrong.

    filterConditions[2].fieldKey = FWPM_CONDITION_IP_REMOTE_PORT;
    filterConditions
    [2].matchType = FWP_MATCH_EQUAL;
    filterConditions
    [2].conditionValue.type = FWP_UINT16;
    filterConditions
    [2].conditionValue.uint8 = 138;

    Thanks,

    Krishnanand

    Friday, February 24, 2012 5:14 AM
  • Antti - I guess the port number is 139 in the following condition, please correct me if I am wrong.

    filterConditions[2].fieldKey = FWPM_CONDITION_IP_REMOTE_PORT;
    filterConditions
    [2].matchType = FWP_MATCH_EQUAL;
    filterConditions
    [2].conditionValue.type = FWP_UINT16;
    filterConditions
    [2].conditionValue.uint8 = 138;

    138 is correct. However, my code is otherwise flawed, it missed range 140-444. And conditionValue.uint8 should be conditionValue.uint16. 

    So you want to exclude ports 137,139 and 445. This is !(137 || 139 || 445). But with WFP, you can't do this kind of filter. Instead of using negation, specify the ports that you would like to be filtered and you get this this <137 || 138 || (140 - 444) || >445.

    For the port range 140-444, you can use the following code:

    FWP_RANGE0 portRange
    portRange.valueLow.type = FWP_UINT16;
    portRange.valueLow.uint16 = 140;
    portRange.valueHigh.type = FWP_UINT16;
    portRange.valueHigh.uint16 = 444;
    
    filterConditions[4].fieldKey = FWPM_CONDITION_IP_REMOTE_PORT;
    filterConditions[4].matchType = FWP_MATCH_RANGE;
    filterConditions[4].conditionValue.type = FWP_RANGE_TYPE;
    filterConditions[4].conditionValue.rangeValue = &portRange;
    

    -- Antti

    Friday, February 24, 2012 9:08 AM
  • Hi Antti,

    Thank you so much for the help.

    I will try these changes.

    Regards,

    Krishnanand

    Saturday, February 25, 2012 6:07 AM