locked
How to associate packets at the IPPACKET layer with a condition on the ALE_AUTH_RECV_ACCEPT or ALE_AUTH_CONNECT layers? RRS feed

  • Question

  • I need to modify packets at the network layer but the filter condition (App ID) is available only at the ALE_AUTH layers. How do I do this? If I understand correctly, a filter on the ALE layers is called only when the connection is established (or first UDP packet), so how do I find the rest of the packets for that connection? And how do I filter these packets at the IPPACKET layer?

    Freddy

    Wednesday, May 9, 2012 6:57 PM

Answers

  • Hi,

    There might not be an easy solution for this. You can use FwpsFlowAssociateContext0() on ALE layers to associate context struct containing App ID. Your context is then available at other layers. According to this MSDN document Associating Context with a Data Flow, context can be made available at IPPACKET layer. In my experiments that is not the case. So you might also take a look at Using Packet Tagging. With that approach problem is that ALE_AUTH doesn't have NBL available.

    -- Antti

    Friday, May 11, 2012 4:40 PM
  • The associated context should be available @ OUTBOUND_IPPACKET.  As for the header modification, Are you using legitimate IP Header Options?  If you are trying to stick a random header in between the IP header and the transport Header, then FwpsConstructIPHeaderForTransportPacket will strip this extra header (as indicated in the function's documentation).  You could just not call this function and calculate the checksums on your own.  this would leave the headers how you have them.

    Hope this helps,


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

    Monday, May 21, 2012 4:13 PM
    Moderator

All replies

  • Hi,

    There might not be an easy solution for this. You can use FwpsFlowAssociateContext0() on ALE layers to associate context struct containing App ID. Your context is then available at other layers. According to this MSDN document Associating Context with a Data Flow, context can be made available at IPPACKET layer. In my experiments that is not the case. So you might also take a look at Using Packet Tagging. With that approach problem is that ALE_AUTH doesn't have NBL available.

    -- Antti

    Friday, May 11, 2012 4:40 PM
  • Mostly correct. ALE_AUTH_RECV_ACCEPT & ALE_AUTH_CONNECT (non-TCP) do have NBLs available.  ALE_AUTH_LISTEN and ALE_AUTH_CONNECT (TCP) do not have NBLs.  For the flow association, INBOUND_IPPACKET classification happens before the packet is associated with the proper flow, so it'd be better to stick with TRANSPORT layers for this scenario.  Also, you could implement your own association mechanism as you are maintaining a callout anyhow.

    Hope this helps clarify.


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

    Tuesday, May 15, 2012 11:53 PM
    Moderator
  • Thanks Dusty. I was on different project for a while and now I'm back on this problem.

    Antti says above that the the flow context is not available at the IPPACKET layers, is this correct? or is it not available only on the INBOUND_IPPACKET layer?  I need it only on the outbound ippacket layer. What I'm trying to do is to identify which application has sent any packets (TCP or UDP) and modify the IP header of those packets coming from a specific application. Can I filter at some ALE layer the packets based on APPID, associate some context (effectively a tag) with the flow, and check the context at the outbound ippacket layer?

    Trying to modify the IP header in the transport layer caused me all kinds of problems (I've posted a question "Reinjecting packet in transport outbound layer seem to strip my ip header option" but didn't get any reply). The header modification worked fine with no errors but when I captured the packets with a sniffer it seems that my headers where replaced (lost changes and packets had different IDs). In the outbound ippacket layer the modification works fine.


    Freddy

    Friday, May 18, 2012 10:34 PM
  • The associated context should be available @ OUTBOUND_IPPACKET.  As for the header modification, Are you using legitimate IP Header Options?  If you are trying to stick a random header in between the IP header and the transport Header, then FwpsConstructIPHeaderForTransportPacket will strip this extra header (as indicated in the function's documentation).  You could just not call this function and calculate the checksums on your own.  this would leave the headers how you have them.

    Hope this helps,


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

    Monday, May 21, 2012 4:13 PM
    Moderator
  • I'm adding a valid timestamp option to the IP header, but at this point with a dummy time value - could this be, or become, a problem? In the IPPACKET outbound layer it works just fine, but when I tried to do it in the transport outbound layer my whole IP header was replaced (including packet ID) by the inject function (or later) - I've examined the NBL with WinDbg before calling the inject function and everything was fine.

    It seems that my best bet will be to associate a context (as a "tag") on an ALE layer and check for this context on the outbound ippacket layer to decide if I need to modify it. I'll have, it seems, to check all outgoing packets - right?.

    I think that I need to associate this context on the ALE_AUTH_RECV_ACCEPT layer and on the ALE_AUTH_CONNECT layer if I want to catch all packets sent by one application independent of who started the connection, am I right?

    Thanks!


    Freddy

    Monday, May 21, 2012 6:11 PM
  • You can use classifies @ ALE_FLOW_ESTABLISHED to call FwpsFlowAssociateContext.  This way you don't have to dinstiguish between inbound and outbound, or whether another filter at a different sublayer drops it.

    When you are injecting @ transport, are you specifying the sendArgs?  you shouldn't specify these if you already have an IP header

    Hope this helps,


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

    Monday, May 21, 2012 11:34 PM
    Moderator
  • Thanks. I'll experiment with the ALE layers.

    As for the transport injection - sendArgs was set to NULL. See my original question for this at: my transport reinjection query.


    Freddy

    Monday, May 21, 2012 11:52 PM
  • I've tried the following sequence:

    1. Register a classifyFn  on layer ALE_FLOW_ESTABLISHED filtered by APP_ID with action type FWP_ACTION_CALLOUT_INSPECTION.

    2. Register a classifyFn on layer OUTBOUND_IPPACKET with no filter and action type FWP_ACTION_CALLOUT_TERMINATING.

    3. In the ALE_FLOW_ESTABLISHED classifyFn I call FwpsFlowAssociateContext0 to associate a context to OUTBOUND_IPPACKET layer, then I set classifyOut->actionType to FWP_ACTION_CONTINUE and return.

    4. I've set breakpoints in both classify functions. I see the call to FwpsFlowAssociateContext0 (successful) but in the OUTBOUND_IPPACKET classifyFn the flowContext parameter is always 0.

    Could it be that Antti was eight and the context is never delivered in IPPACKET layer, even in the OUTBOUND direction?

    (I've tried also to use FWP_ACTION_CALLOUT_TERMINATING in the first classifyFn, and to set classifyOut->actionType to FWP_ACTION_PERMIT before returning - made no difference).


    Freddy

    Friday, June 8, 2012 6:36 PM
  • I will have to investigate why the context is not there.

    Thanks,


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

    Friday, June 8, 2012 9:15 PM
    Moderator
  • Thanks!

    Freddy

    Friday, June 8, 2012 11:39 PM
  • After code review, apparently this is by design.  Flow contexts are not indicated at the IPPACKET Layers.


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


    Friday, June 15, 2012 4:30 PM
    Moderator
  • Thanks for your efforts. It seems that I have to go back to my other thread (ReInjecting packet in transport outbound layer seem to strip my ip header option) and see why I my transport layer modifications to the IP header get lost. Hope to see you there :)

    Freddy

    Friday, June 15, 2012 4:59 PM
  • After code review, apparently this is by design.  Flow contexts are not indicated at the IPPACKET Layers.

    -------------------------------------------------------------------------------------------------------------------------

    So, is that means Call FwpsFlowAssociateContext  at FLOW_ESTABLISHED (outbound) then access the context at INBOUND_IPPACKET is impossible ?

    Monday, January 14, 2019 9:58 AM