[Victor43]

As Vrtule mentioned in his post, you can use ALE with WFP and identify things such as the process information you seek. It's a layer that makes it possible to identify the application associated with the network operation(s). Refer to WDK's WFP layered samples under \src\network\trans. "inspect" sample may be helpful for instance

Thanks to Brock and Vrtule. I've got a few more questions for this old thread.

I understand that using WFP and one of the samples as you have mentioned should be sufficient for what I need. But moving forward with a few more questions:

1. Will the WFP filter driver be sufficient for Windows services that makes use of the TCP communications such as the one behind Windows update and DCOM technologies and so on ? I believe the answer would be yes but I want to be sure.

2. Now were talking about higher 7/8 layers (application) in the OSI model such as applications such as HTTP/POP/SMTP and FTP applications or other types of user mode applications that make use of likely sockets or something equivalent in order to send and receive TCP data but would there be any other interface (lower than sockets at an application layer) for TCP/IP communications that Microsoft makes readily available as you go lower in the OSI model and the TCP stack ? Would there be anyway that once you've passed the application layer that a packet could be injected into the stack even if the packet is entirely constructed without the use of formal API's Microsoft makes available ? So basically what I'm trying to say about malware is can they bypass a WFP filter driver if they choose to do so ? I cannot afford this to happen but will have to address it if this is the case.

3. Brock you said Microsoft is trying to phase out NDIS and TDI driver development in order to push WFP yes ? When will this happen ? Also does this mean the question #2 above that one cannot make use of technology a driver per se which will be able to by-pass a WFP filtering driver ? At this point I only want to monitor traffic but possibly modify it also at a layer stage.

4. What about malware that writes its own entire and complete TCP stack will they be able to by-pass a WFP filtering driver such as the one you have suggested that I take a look at ?

[Brock]

[1] Yes, as a matter of fact in Vista the Windows Firewall itself is built on WFP.

[2] Almost anything is certainly *possible* to circumvent security mechanisms, always a cat and mouse game. I focus more on probability and not so much possibility. If malware has clever tricks, locates a bug in said security or deploys a kernel driver all bets are off. All you can do is follow best security practices and address anything if it arises. Sorry for the vague answer but it's true

[3] NDIS is the lowest level, it can manipulate raw ethernet frames etc. WFP is not, however it encapsulates functionality of TDI and NDIS but it's not to be confused as one with them. Think of WFP as being built on top of them

MSDN says this about replacing NDIS, TDI and LSP as I mentioned previously:

"By providing a simpler development platform, WFP is designed to replace previous packet filtering technologies such as Transport Driver Interface (TDI) filters, Network Driver Interface Specification (NDIS) filters, and Winsock Layered Service Providers (LSP)."

[4] At the NDIS level you can create your own protocol stacks, raw kernels etc. You're basically one with the NIC at this depth at layer 2 of the OSI model aka the datalink layer so again the ability to bypass is certainly notable on its behalf

Here's some additional WFP info as well: http://www.komodia.com/wfp_hl

[Victor43]

Brock and Vrtule thanks again.

I have one more question to ask. Vrtule had said the following below: What sort of task(s) with examples would make things a little complicated then if wanting to do more than just using the WFP for monitoring ? Suppose I need to modify the packet ? At this point I am not certain which part of the packet but packet modification will likely be needed before it hits the wire or network infrastructure. Also is it possible to monitor the entire TCP stack each and every layer to see how control data gets added in each or accessible layers on a send and vice versa on a receive ?Primarily to see if anything changes as a packet of TCP data is sent out with respect to the data itself so comparing data at the highest layers (application/presentation) with the data with the lower or lowest layer (network).

If your task is just monitoring, WFP is fine and quite straightforward thing. If you wish to do more, things get quite complicated and I personally prefer using WFP sample drivers as reference since WFP documentations seems to be misleading or quite vague in some cases.

[Vrtule]

What sort of task(s) with examples would make things a little complicated then if wanting to do more than just using the WFP for monitoring

Well, your WFP callout driver is called when an event it registered for occurs. However, there are no guarantees about IRQL, except that it will be <= DISPATCH_LEVEL. This may be a problem, especially if you wish the user to interact with your driver (e.g. you report the event to her and she decides whether to allow or block the corresponding operation). Since the IRQL may be too high, you cannot perform passive waiting inside the callback. You must tell the WFP to suspend the operation smewhat, so when your callback exits, WFP does not continue with processing the operation until you resume it.

For ALE layers, there are API calls you need to use. FwpsPendOperation0 for suspending the operation processing and FwpsCompleteOperation0 for resuming it. On non-ALE layers, there are no such routines available AFAIK. Well, this is still kind of easy.

Things get complicated when the operation your driver wants to suspend processing of is assocaited with a pakcet. On non-ALE layers, you just tell the WFP to silently drop the packet and if you later decide that the operation in question should proceed, you reinject the packet into the stack again. AFAIK all non_ALE layers available for drivers are associated with a packet (or an ethernet frame) which makes the world a little bit simpler. On ALE layers, some events are associated with a packet, some not and IIRC there is no need to make the drop-reinject approach even for some of "packetful" operations. I had quite hard time to extract this information from the documenation and I ended with examining the trans sample which demostrates how to suspend and resume operations on ALE and non_ALE layers. Actually, if you are writing a driver that needs to do this, trans is a good starting point.

I just want to say that writing a callout driver is not as easy as writing a registry filter driver. I actually also prefer writing file system minifilters than WFP callout drivers. I strongly recommend to start with the trans sample and to adapt it slowly to your needs.

Also is it possible to monitor the entire TCP stack each and every layer to see how control data gets added in each or accessible layers on a send and vice versa on a receive ?

Yes, it is. Just keep in mind that WFP layers are a bit different from ISO/OSI or TCP/IP layers. It is true that when an application sends a packet, the operation can be detected on multiple WFP layers (possibly connect, send, "an outgoing TCP packet", there are some layers corresponding to the ISO/OSI network layer (e.g. you can see pakcet fragmentation)). If I am not mistaken much, starting with Windows 8, WFP allows you even to monitor incoming and outgoing ethernet frames (link layer) which, until that time, I considered as one of the main reasons why to write a NDIS filter driver (WFP on Windows 7 and below is not capable of intercepting operations at link layer, which means Windows Firewall also is not).

So, you definitely can look at the packet during its "life cycle". But there are things like SSL/TLS or IPSec and fragmenation, so its content might be changed during the path through the network stack.

[Victor43]

Thank you Vrtule. The examples you have provided have been very helpful. I understand that developing even a WFP filter driver could get rather complicated as you have explained thank you. When you say "On non-ALE layers, there are no such routines available AFAIK." do you mean the Transport Layer Shim and Network Layer Shim layers respectively ? I researched these two terms from the link below. Could the Network Layer Shim as they call it be used as a complete foundation for a NDIS filter driver ? Could it be perform everything that a NDIS filter driver could perform ? So when making use of these different non-ALE layers they too have their Callout functions yes which get called by the platform ?

https://msdn.microsoft.com/en-us/librar ... s.85).aspx

You also mentioned that it is possible to monitor the entire TCP stack thank you for this answer. But would it be possible to verify if the TCP data (the payload) itself gets modified with a comparison check with the highest level or layer(s) of the TCP stack such as the application layer (OSI layer 8/7) with the lowest TCP (network/data) layers (OSI layer 3/2) ? Can all this be done via a WFP filter driver without the need for another filter driver such as an NDIS filter driver ?

Can the monitoring of the entire TCP stack be done all from within one single WFP filer driver or does one need to implement several different platform drivers such as one for each layer of the stack or multiple WFP drivers ?

Thank you again

[Vrtule]

do you mean the Transport Layer Shim and Network Layer Shim layers respectively

I just wanted to say that when you need to suspend an operation on a non_ALE layer, you just silently drop the packet associated with the operation (AFAIK there are no packetless operations on non_ALE layers available for drivers). If you later decide to resume the operation, you just reinject the packet to the stack. If you decide not to do this, the packet will not be sent (or received) which effectively blocks the operation. The receiving/sending application gets timeout error I suppose.

You also mentioned that it is possible to monitor the entire TCP stack thank you for this answer. But would it be possible to verify if the TCP data (the payload) itself gets modified with a comparison check with the highest level or layer(s) of the TCP stack such as the application layer (OSI layer 8/7) with the lowest TCP (network/data) layers (OSI layer 3/2) ? Can all this be done via a WFP filter driver without the need for another filter driver such as an NDIS filter driver ?

In theory, yes. In practice, it might be quite complicated. The packet (and so the payload) may get fragmented because of small MTU, or a transparent encryption like IPSec (done at OSI network layer I reckon) may be applied. So simple comparison might prove ineffective.

Can the monitoring of the entire TCP stack be done all from within one single WFP filer driver or does one need to implement several different platform drivers such as one for each layer of the stack or multiple WFP drivers ?

Yes, one callback may "rule them all". You just create a filter for all the layerrs you wish to inspect and the filter action would be "call my callback". The propper way of doing this is to create your own sub-layer on these layers in order not to get in troubles with WFP arbitration. But this is not necessary for testing purposes and can always be done later.

https://msdn.microsoft.com/en-us/librar ... s.85).aspx

[Victor43]

Thank you Vrtule and Brock for the helpful responses. I'll carefully review the responses both of you have provided and return with new post (in the event this thread becomes formally closed) should I need further clarification. Thank you again to both of you.

[Victor43]

Hello some more questions to ask:

1. Could implementing a NDIS filter driver and a WFP driver (working together in tandem) determine whether there are any packets that are flowing past the WFP driver that are going undetected ? However having a NDIS filter driver will not defend against another NDIS filter driver which injects its own TCP data packets yes ?

2. What are some sort of reasons for deploying a NDIS filter driver ? A firewall I believe would be one reason but why does a firewall need access at that level to raw packets or frames ? Would it need access to some of the control data (to learn of the incoming protocol) that is made available at that layer or platform of NDIS ? Also the fact that a NDIS filter driver has access to just about all outgoing and incoming TCP data and being one of the lowest possible level or layer filter driver on the TCP stack ? Every TCP data will pass through it.

3. Is it possible for a WFP filter driver to know of or find out the existence of another WFP filter driver in the stack or filter drivers such as an NDIS filter driver below it on the TCP stack ?

4. Related to #3 but can a WPF or a NDIS filter driver determine which position it might be on the stack as a filter driver or for that filtering platform or layer ?

Thanks

[Vrtule]

1. Could implementing a NDIS filter driver and a WFP driver (working together in tandem) determine whether there are any packets that are flowing past the WFP driver that are going undetected ? However having a NDIS filter driver will not defend against another NDIS filter driver which injects its own TCP data packets yes ?

Yes, in theory, you can try to match packets seen by a WFP driver to those seen by a NDIS filter. There may be frames, however, that are created solely at link layer and fullfill some management tasks. I think you need to try this to see how well such an approach would work.

Defending against another NDIS filter driver is, in my opinion, quite pointless. If the attacker has her code already in the kernel area, she can do things to you drivers that worrying about another NDIS filter would be the least problem for you.

2. What are some sort of reasons for deploying a NDIS filter driver ? A firewall I believe would be one reason but why does a firewall need access at that level to raw packets or frames ? Would it need access to some of the control data (to learn of the incoming protocol) that is made available at that layer or platform of NDIS ? Also the fact that a NDIS filter driver has access to just about all outgoing and incoming TCP data and being one of the lowest possible level or layer filter driver on the TCP stack ? Every TCP data will pass through it.

NDIS filters were able to inspect link-layer based attack, such as ARP spoofing. Starting with Windows 8, WFP should be also able of that.

3. Is it possible for a WFP filter driver to know of or find out the existence of another WFP filter driver in the stack or filter drivers such as an NDIS filter driver below it on the TCP stack ?

AFAIR there are some APIs to enumerate installed filters, layers, sublayers etc. So, you can do this. Even if there were no such API, there would still be a possibility of parsing undocumented data structures to achieve the task.

. Related to #3 but can a WPF or a NDIS filter driver determine which position it might be on the stack as a filter driver or for that filtering platform or layer ?

WFP filters can, not sure about NDIS filters. But undocumented OS structures tell you everyting. The question is whether they are worth of researching.

[Victor43]

Vrtule thank you again.

Can you tell me is it possible for a driver to maintain a driver to driver or driver to use mode application communications that is encrypted in both directions ? Could a public/private key channel be created using only kernel mode driver ? Secondly can a WFP filter driver or NDIS filter driver communicate with a user mode application or with another kernel mode filter driver located somewhere else on the local subnet or local network ?