locked
How to wait for decision from wok item ? RRS feed

  • Question

  • Hi All,

    I want to call the method RtlEqualSid from my callout driver (STREAM_LAYER) and allow/deny the connecton based on that. But the documentation says that RtlEqualSid can be called at only when IRQL < DISPATCH_LEVEL . As the classify callouts may be called at IRQL <= DISPATCH_LEVEL, sometime this is causing issue for me. I have been advised to create a work item for solving this issue. I tried to do that, but i think it is not working since the work item works in an asynchronous way. I have to wait for the decision of RtlEqualSid (or workitem) to allow/deny the connection.

    1. Could you please tell me whether this is possible with workitem ?

    2. Also couuld you please tell me whether there is an alternative way to achieve this?

    Thanks,

    Krishnanand

    Tuesday, December 6, 2011 3:26 PM

Answers

  • Hi Krishnanand,

    In that layer pending is implemented by first cloning the indicated data (take a look at FwpsAllocateCloneNetBufferList0), followed by returning FWP_ACTION_BLOCK from the classfyFn function that has the FWPS_CLASSIFY_OUT_FLAG_ABSORB bit set.

    After data is 'analyzed' you should reinject it by calling FwpsInjectTransportReceiveAsync0/FwpsInjectTransportSendAsync0 or discard it as you desire.

     

    Hope this helps

    Wednesday, December 7, 2011 2:36 PM

All replies

  • You will need to pend the connection (FwpsPendOperation0) return FWP_ACTION_BLOCK and set FWPS_CLASSIFY_OUT_FLAG_ABSORB, execute the workitem, then unpend (FwpsCompleteOperation) connection when you know what action you want to return.

     

    http://msdn.microsoft.com/en-us/library/windows/hardware/ff551199(v=vs.85).aspx

    http://msdn.microsoft.com/en-us/library/windows/hardware/ff551152(v=vs.85).aspx

     

    Hope this helps,

     

     


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------
    Tuesday, December 6, 2011 4:25 PM
    Moderator
  • Hi Dusty,

    Thank you for the reply.

    But, I am calling this from the STREAM layer. I think pending is not possible at this layer.

    Thanks,

    Krishnanand

    Wednesday, December 7, 2011 1:33 PM
  • Hi Krishnanand,

    In that layer pending is implemented by first cloning the indicated data (take a look at FwpsAllocateCloneNetBufferList0), followed by returning FWP_ACTION_BLOCK from the classfyFn function that has the FWPS_CLASSIFY_OUT_FLAG_ABSORB bit set.

    After data is 'analyzed' you should reinject it by calling FwpsInjectTransportReceiveAsync0/FwpsInjectTransportSendAsync0 or discard it as you desire.

     

    Hope this helps

    Wednesday, December 7, 2011 2:36 PM
  • Sorry, I skipped over the STREAM layer detail.  Alvaro is correct, you would clone the data, block and absorb it.  When you know the decision you wish to make, you'd either inject the data back, or discard it.

    Hope this helps,

     


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------
    Wednesday, December 7, 2011 8:07 PM
    Moderator
  • Hi Both,

    Thank you for the reply.

    Currently, the action type of my stream filter is FWP_ACTION_CALLOUT_UNKNOWN. This is made to be like that to drop the connection if the connection should be blocked after the stream analysis . 'FWPS_STREAM_ACTION_DROP_CONNECTION' is supported only if the action type of filter is FWP_ACTION_CALLOUT_UNKNOWN.

    1. Will there be any issues if we do like this ? (Or the action type of filter should be FWP_ACTION_CALLOUT_TERMINATING)?

    2. What I am planning to do is

    (a) Clone the data at STREAM LAYER.

    (b) calling FWP_ACTION_BLOCK from the classfyFn function that has the FWPS_CLASSIFY_OUT_FLAG_ABSORB bit set.

    (c) Queue the work item for processing (ie processing the connection information to check whether the connection is allowed or not)?

    (d) Get a decision(to drop the connection or not)  from the processing and store it some where (not sure on which place would be good for this to store)

    (e) Discard the connection by calling streamPacket->streamAction = FWPS_STREAM_ACTION_DROP_CONNECTION if the connection is not allowed. (I am planning to do this from classify fucntion rather than in Worker queue)

    (f) Reinject the packet if the connection is allowed.

     

    Could you please tell me whether this aapproach is righ or not?


    Thanks,

    Krishnanand

     

     


    Wednesday, December 21, 2011 11:09 AM
  • Could you please tell me whether this approach is right or not?

    Thanks,

    Krishnanand

    Tuesday, January 3, 2012 11:10 AM
  • Wouldn't it make more sense to drop the connection at ALE_AUTH_CONNECT?  If you require data inspection to make your decision, then the above mostly works.  I'd expect you to not wait around in the initial classify for your workerThread to finish.  you'd perform (b), and then in the worker thread set something to indicate whether the connection should be dropped.  on the next classify, you'd check your setting and either drop it, or continue on.

    The following may help with your endeavors:
    http://msdn.microsoft.com/en-us/library/windows/hardware/ff570891(v=vs.85).aspx 

    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:53 PM
    Moderator
  • Hi Dusty,

    Thank you so much for the reply.

    If I want to check the setting on next classify, how can I distingush the one after reinjection. Is it possible to use 'FwpsQueryPacketInjectionState' at STREAM_LAYER?

    Regarding dropping a connection at ALE_AUTH_CONNECT, I need to find out the site information (eg: www.google.com, www.sitename.com etc..) from the classify functions before dropping the connection. I think it is not possible to identify this information from the ALE_AUTH_CONNECT layer. Please correct me if my assumption is wrong.

    So I chose two layers ,

    1. I am using ALE_AUTH_CONNECT layer to identify the connection information (user SID, group SID etc. - which are not possible to identify from STREAM_LAYER) and associated the flow context to retrieve this information in the STREAM_LAYER.

    2. STREAM_LAYER which is used to identify the site information etc. and allow or deny the traffic based on the user configuration.

    For implementing the STREAM inspection in worker queue (only inspection not editing the STREAM),I guess, I need to pass the flow context(which is associated from ALE_AUTH_CONNECT) as well as the STREAM data to the worker queue.

    Thanks,

    Krishnanand


    Wednesday, January 4, 2012 9:42 AM