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-connect-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.
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-connect-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.
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
@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.
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.
>> 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
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.
> 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).
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.
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.
> 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:
- TCP
- 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?!