Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

Upcoming OSR Seminars:

Writing WDF Drivers I: Core Concepts, Nashua, NH 15-19 May, 2017
Writing WDF Drivers II: Advanced Implementation Tech., Nashua, NH 23-26 May, 2017
Kernel Debugging and Crash Analysis, Dulles, VA 26-30 June, 2017
Windows Internals & Software Driver Development, Nashua, NH 24-28 July, 2017


Go Back   OSR Online Lists > ntdev
Welcome, Guest
You must login to post to this list
  Message 1 of 11  
09 Aug 17 11:38
tope awolowo
xxxxxx@gmail.com
Join Date: 09 Aug 2017
Posts To This List: 16
developing a DNS redirection and interception project making use of Windows Filtering Platform.

Good day discussant. At present am working on a DNS redirection and interception project making use of Windows Filtering Platform. Am making use of Application Level Enforcement Using Bind or Connect Redirection from https://docs.microsoft.com/en-us/windows-hardware/drivers/network/using-bind-or-c onnect-redirection it was stated "A WFP connection redirection callout redirects an application's connection request so that the application connects to a proxy service instead of the original destination. The proxy service has two sockets: one for the redirected original connection and one for the new proxied outbound connection." " but in the ClassifyFunctions_ProxyCallouts.cpp module of the WFP driver sample it was posted "Microsoft recommends using FWPM_LAYER_STREAM_V{4/6} rather than proxying network data to a local service. Doing so will make for a better ecosystem, however if you feel you must proxy, then it is advised to use FWPM_LAYER_ALE_REDIRECT_CONNECT_V{4/6}, and have the proxy service call the REDIRECT_RECORD IOCTLs so multiple proxies can coexst without losing data on the origin of the data. " My question is this in implementing a DNS redirection and intereption, should i use proxying service or FWPM_LAYER_STREAM_V{4/6}. And if am to use FWPM_LAYER_STREAM_V{4/6}, where can i find the documentation. Am really looking forward to hearing from the discussion list on this. --
  Message 2 of 11  
09 Aug 17 14:06
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11570
developing a DNS redirection and interception project making use of Windows Filtering Platform.

tope awolowo wrote: > > At present am working on a DNS redirection and interception project > making use of Windows Filtering Platform. > Am making use of Application Level Enforcement Using Bind or Connect > Redirection from > https://docs.microsoft.com/en-us/windows-hardware/drivers/network/using-bind-or-c onnect-redirection > How would that work with DNS, which uses UDP? You don't usually use either "bind" or "connect" on UDP sockets. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 3 of 11  
10 Aug 17 03:46
Jason Stephenson
xxxxxx@live.co.uk
Join Date: 13 Jul 2015
Posts To This List: 47
developing a DNS redirection and interception project making use of Windows Filtering Platform.

You can absolutely use bind and connect redirect layers to manipulate how DNS requests are performed on your system. For UDP the CONNECT_REDIRECT layer will be indicated for the first UDP packet sent from socket a to socket b. Altering the destination address (what youd do at this wfp layer) will alter all subsequent packets that are part of this stream. When I first worked through this it became evident that although CONNECT_REDIRECT allegedly supported TCP and UDP, THE UDP path was riddled with issues. (I worked through numerous bugs with MS support engineers, including one bluescreen) If you dont need to support older windows builds then you can definately get a working solution with CONNECT_REDIRECT, but youll need to have an additional bit of complexity to workaround windows dns client rejecting redirected packets. Having said all this, if i was starting from scratch I would probably look at other layers first. STREAM / DATAGRAM_DATA. J
  Message 4 of 11  
10 Aug 17 04:13
Ishan Singh-Levett
xxxxxx@gmail.com
Join Date: 18 Jan 2016
Posts To This List: 35
developing a DNS redirection and interception project making use of Windows Filtering Platform.

@Tim: WFP considers a UDP socket to bind, then connect and notifies callout drivers when the socket first sends a datagram to a particular destination tuple. The 'connection' is then torn down after a timeout (60 seconds I believe) if no activity is seen. @Tope: We used ALE connection redirection for a recent project and found that it worked very well for TCP but wasn't reliable for UDP. This seems to be due to the inherent difficulty of imposing the concept of a connection on a connectionless protocol, as well as the fact that Microsoft didn't really test redirection of UDP properly. We found ourselves raising numerous support tickets with Microsoft in order to get quite serious WFP bugs fixed, for example a BSOD when redirecting DNS generated by the windows DNS client on Windows 8 and later. That particular problem is now fixed on recent releases of Windows 10 and there is a hotfix for it on Windows 8.1, but there are other problems which either aren't fixed or got fixed and then regressed because apparently redirection of UDP isn't supported to the extent that the WFP docs state. The Microsoft support team were very helpful but unless you can afford to wait for them to fix bugs in WFP or accept the risk that they won't fix them at all, I'd stay away from using ALE connection redirection with UDP. I think if we were to start on that project again we would have either avoided redirecting UDP traffic at all or done it at the DATAGRAM_DATA layer (I believe that the STREAM layers are only for TCP, but could be wrong) rather than using ALE redirection. Shortcomings of ALE redirection aside, there are difficulties associated with proxying UDP traffic that you should be aware of before you go down this route. For example, some UDP clients will reject inbound datagrams based on the remote address/port tuple that they were received from; if traffic is being redirected via your proxy you will fall foul of this. The Windows DNS resolver is an obvious example of a client that behaves like this and given that your requirement is all about DNS, this is a problem that you'll need to work around. In short: If you go down the route of redirecting DNS traffic you will encounter significant difficulties that will take a lot of time and effort to work around, regardless of the WFP layer you choose. Taking a step back and considering what it is you are ultimately trying to achieve and if you can achieve it without redirection is definitely the best option here.
  Message 5 of 11  
10 Aug 17 14:17
ashish kohli
xxxxxx@hotmail.com
Join Date: 29 Nov 2014
Posts To This List: 40
developing a DNS redirection and interception project making use of Windows Filtering Platform.

Please see this https://msdn.microsoft.com/en-us/library/windows/desktop/bb451831(v=vs.85).aspx Clearly FWPM_LAYER_ALE_AUTH_CONNECT_V4 is a correct layer to intercept dns query. At this point remote address can be changed and dns query redirected.
  Message 6 of 11  
15 Aug 17 06:30
Jason Stephenson
xxxxxx@live.co.uk
Join Date: 13 Jul 2015
Posts To This List: 47
developing a DNS redirection and interception project making use of Windows Filtering Platform.

>> Clearly FWPM_LAYER_ALE_AUTH_CONNECT_V4 is a correct layer to intercept dns query. At this point remote address can be changed and dns query redirected. This is not correct. The auth layers are for authorization, not redirection. https://msdn.microsoft.com/en-us/library/windows/desktop/aa366492(v=vs.85).aspx
  Message 7 of 11  
15 Aug 17 09:02
ashish kohli
xxxxxx@hotmail.com
Join Date: 29 Nov 2014
Posts To This List: 40
developing a DNS redirection and interception project making use of Windows Filtering Platform.

thats just jugglery of words. Any layer in which we have netbufferlist and from which packet can be reinjected can be used for modification of network packet. Redirection is just an consequence of specific modification.
  Message 8 of 11  
15 Aug 17 10:58
Ishan Singh-Levett
xxxxxx@gmail.com
Join Date: 18 Jan 2016
Posts To This List: 35
developing a DNS redirection and interception project making use of Windows Filtering Platform.

> thats just jugglery of words. Somewhat ironically, jugglery is not a word. > Any layer in which we have netbufferlist and from which packet can be reinjected can be used for modification of network packet. Just because you *can* modify the NBL doesn't mean that's what the layer is intended for. I don't think you'll see packet modification done at the connect layer being recommended by anybody at Microsoft. Besides which, AUTH_CONNECT is only indicated for the first packet in the flow; if you modify a packet's destination at this layer it will have no effect on any subsequent packets sent from that socket. That's why you either need to do the redirection at CONNECT_REDIRECT (a layer provided by Microsoft specifically to allow redirection of the entire flow) or DATAGRAM_DATA (at which you will see all UDP packets, not just the first).
  Message 9 of 11  
15 Aug 17 14:24
ashish kohli
xxxxxx@hotmail.com
Join Date: 29 Nov 2014
Posts To This List: 40
developing a DNS redirection and interception project making use of Windows Filtering Platform.

what I said is what I observed though theoretically what you said is correct and should have happened that way.May be possible reason is the implementation of dns client by microsoft. I don't see any reason why DNS interception cannot be done at other layers as well.Its all matter that you intercept and inject correctly.
  Message 10 of 11  
15 Aug 17 14:48
ashish kohli
xxxxxx@hotmail.com
Join Date: 29 Nov 2014
Posts To This List: 40
developing a DNS redirection and interception project making use of Windows Filtering Platform.

I don't think you'll see packet modification done at the connect layer being recommended by anybody at Microsoft Also it will be really helpful for me as well as other members if you can attach the recommendation by microsoft if any for this particular case.
  Message 11 of 11  
16 Aug 17 03:10
Ishan Singh-Levett
xxxxxx@gmail.com
Join Date: 18 Jan 2016
Posts To This List: 35
developing a DNS redirection and interception project making use of Windows Filtering Platform.

> Its all matter that you intercept and inject correctly. Not exactly. You also need to choose a layer at which your callout will actually be invoked when you need it to be, as I pointed out in my previous post. You also need to be mindful of WFP's internal state and the effect your callout's presence might have on wider system behaviour and any interactions with other callouts. For example, the CONNECT_REDIRECT layer is designed to allow multiple redirecting proxies to co-exist on Windows 8+, but if you come up with your own solution using packet interception and reinjection at another layer you will almost certainly not get this benefit. It's just a pity that CONNECT_REDIRECT doesn't work as well as it should for UDP. > Also it will be really helpful for me as well as other members if you can attach the recommendation by microsoft if any for this particular case. See the link that Jason posted: "This filtering layer allows for authorizing connect requests for outgoing TCP connections, as well as authorizing outgoing non-TCP traffic based on the first packet sent." This doesn't mean that you definitely can't drop and reinject packets at this layer, but it's pretty obviously not its main purpose. I think you'll find that the layer data (NBL) pointer is null at AUTH_CONNECT for the following types of traffic: 1. TCP 2. UDP in which the socket owner called 'connect' and 'send' rather than 'sendto', e.g. DNS generated by nslookup. I don't have time to run up a debugger to check this, but I believe it's correct. This, along with what I previously said about only the first UDP packet being indicated at AUTH_CONNECT means that this layer is limited at best for packet modification and only appropriate in some very specific circumstances, of which DNS redirection is not one. Anyway, hopefully readers of this thread now have enough information to make their own mind up as to the best path to choose. Also, I should apologise for saying that jugglery was not a word. Who knew?!
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntdev list to be able to post.

All times are GMT -5. The time now is 15:37.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license