locked
FWPM_LAYER_ALE_AUTH_CONNECT_V4 ignores FWP_ACTION_BLOCK RRS feed

  • Question

  • I am trying to block access to a particular URL/IP address.

    On the user mode, I have opened a dynamic session (FWPM_SESSION_FLAG_DYNAMIC). I've added a filter on a sub layer (by calling FwpmSubLayerAdd() to ensure the callout is always called in the sublayer) in ALE FWPM_LAYER_ALE_AUTH_CONNECT_V4.

    FWPM_FILTER.action.type = FWP_ACTION_CALLOUT_TERMINATING

    FWPM_FILTER.flags = 0.

    After adding the filter (FwpmFilterAdd()), initially everything seems fine.

    In my FWPS_CALLOUT_CLASSIFY_FN, I unconditionally set

    classifyOut->actionType = FWP_ACTION_BLOCK;
    classifyOut->rights &= ~FWPS_RIGHT_ACTION_WRITE;

    I can see that initially, ie, chrome and FF are blocked when accessing the url. However, after a while,

    1. either the FWPS_CALLOUT_CLASSIFY_FN is not called (does this have something to do with the filter engine being restarted?. If I load WinDBG and reload the symbols and break into FWPS_CALLOUT_CLASSIFY_FN, I can see FWPS_CALLOUT_CLASSIFY_FN being called into again, but it has no effect. I can see ETW messages with the relevant callouts).

    2. or even if FWPS_CALLOUT_CLASSIFY_FN is called and it sets FWP_ACTION_BLOCK, the url is still accessible using the browser.

    Am I doing something wrong or is there something I've missed out?

    Here is a snippet of my user code and callout code.

    ...
    result = FwpmSubLayerAdd(engineHandle, &monitorSubLayer, NULL);
    filter.layerKey = FWPM_LAYER_ALE_AUTH_CONNECT_V4;
    filter.subLayerKey = monitorSubLayer.subLayerKey;

    filter.displayData.name = L"Blah";
    filter.displayData.description = L"Blah";

    filter.action.type = FWP_ACTION_CALLOUT_TERMINATING; // let me decide on a block decision later.
    filter.action.calloutKey = MONITOR_SAMPLE_URL_BLOCKING_CALLOUT_V4;

    filterConditions[index].fieldKey = FWPM_CONDITION_IP_REMOTE_ADDRESS;
    filterConditions[index].matchType = FWP_MATCH_EQUAL;
    filterConditions[index].conditionValue.type = FWP_UINT32;
    filterConditions[index].conditionValue.uint32 = iIPaddr;

    filter.numFilterConditions = static_cast<UINT32>(iFilterCount);
    filter.filterCondition = &filterConditions[0];

    filter.weight.type = FWP_EMPTY; // auto-weight.
    result = FwpmFilterAdd(engineHandle, &filter, NULL, NULL);
    result = FwpmTransactionCommit(engineHandle);


    FWPS_CALLOUT_CLASSIFY_FN  code

    classifyOut->actionType = FWP_ACTION_BLOCK;
    classifyOut->rights &= ~FWPS_RIGHT_ACTION_WRITE;


    I want to know

    (a) why isn't the callout being called after a while even though the IP is being accessed by a different process?

    (b) Why doesn't FWP_ACTION_BLOCK not have any effect?


    if...then...else, like everyone else!


    • Edited by SriSarma Tuesday, September 2, 2014 3:42 PM more info
    Tuesday, September 2, 2014 2:53 PM

All replies

  • A particular URL can be associated to many IPs(i.e 1 to N relationship), so I would recommend that you try to access the website using the IP that u have blocked in the CLASSIFYFN instead of the URL. Browser can do all sorts of tricky stuff to get the webpage connected. 

    Try out different browsers too


    ___________ Regards Umar Yaqoob ___________

    Tuesday, September 2, 2014 6:49 PM
  • Thanks for the reply Umar. But it still doesn't explain why returning

    classifyOut->actionType = FWP_ACTION_BLOCK;
    classifyOut->rights &= ~FWPS_RIGHT_ACTION_WRITE;

    has no effect on the IP address/url being blocked.

    And neither does it explain why the callout is not called out after a while. It looks as if the callout has been unregistered without the code actually requesting an unload.

    My questions still remain unanswered.


    if...then...else, like everyone else!

    Wednesday, September 3, 2014 7:15 AM