Microsoft DirectAccess and WAF

WAF only handles http or https over one specific port.  It also has trouble with Citrix ICA which is nonHTML data in an https session.  My guess is that this Microsoft product uses an odd protocol or a primary and a secondary session on different ports.  If that gues is correct, WAF will not be your answer.

DouglasFoster said:

WAF only handles http or https over one specific port.  It also has trouble with Citrix ICA which is nonHTML data in an https session.  My guess is that this Microsoft product uses an odd protocol or a primary and a secondary session on different ports.  If that gues is correct, WAF will not be your answer.

 

Well that sucks. Thanks for the response. I think you may be right in that it may be using nonHTML data in an https session. DirectAccess is a 'always-on' VPN solution that only connects on port 443. That may be why browsing to the domain through a browser works but using DirectAccess fails at the SSL handshake. Looking through https://docs.microsoft.com/en-us/windows-server/remote/remote-access/directaccess/tlg-cluster-nlb/step-6-test-directaccess-client-connectivity-from-behind-a-nat-device it states IP-HTTPS connection will fail if the proxy requires authentication or if the web proxy performs outbound SSL inspection. AFAIK I dont have these options enabled.

Since I'm only allowing 443 traffic to this server, other hardening techniques on the host itself should still be applied correct? Any other traffic directed at the host is dropped.

Suggest you move back from the technology and look for the business function.

1) All remote access should use two-factor authentication.   PCI DSS requires it, and abundant evidence confirms it.   UTM provides that capability.  Does Microsoft have a two-factor solution baked into their technology, or do you have to add it in.

2) UTM SSL VPN requires (a) a download to a chosen PC, and supports 2-factor authentication.   So it is really a form of three-factor, especially if you keep the download awy from the user portal and require that it be installed by I/T from the WebAdmin screen.   (Alternatively, only enabled it for a short window while the user does self-install.   Then you can control available IP addresses with VPN profiles, and tune them further using firewall rules based on user ID.   You also have automatic break-in evasion.   Can you assemble all of these pieces at no-extra-cost with any other remote client VPN technology?

2) If at all possible, avoid VPN completely.  HTML5 VPN to RDPO is a great alternative to Go-to-my-pc, but with 2-factor authentication and without dependence on a third-party server in the cloud.

Thank you for your assistance. We have decided to use the Full NAT configuration and adjust security as needed for now.

I had a brief look at DirectAccess after this thread was started. Seems it uses a dual tunnel approach.

The first tunnel is always connected and serves for it admin purposes only eg updates, gpo etc so that when the client is turned on, now matter where it is, it is updated.

The second tunnel only comes up when the user authenticates and is used for all the other stuff eg file transfer etc.

The advantage this has is that it is not reliant upon the user bringing/or not bringing a vpn up as the minute it is turned on its looking for GPO's, updates etc

I suppose if you couple it with bitlocker, locked down policies etc, it may be a fairly secure way of doing things and may alleviate vpn client overheads.

That being said, there is always the fear of exposing an M$ product directly to the internet

Great suggestions, Doug.  The caveat with the HTML5 method is that it is very compute-intensive for the UTM and should only be used for a few individuals to have occasional access.  Having several active sessions at once will bring most "correctly-sized" UTMs to their knees.

Cheers - Bob

Great warning about Html5 Rdp. Any reason to hope that CPU load is improved in v9.5?

I bet not, Doug.  I've seen more than one Sophos person say that it's meant primarily for use by a few occasional accesses.  Say a Windows server specialist or an Apache guru.  For regular, broad use, I prefer SSL VPN configured to use UDP.  As you point out, it's possible to use triple-factor auth with that - a belt and two suspenders.[:D]

Cheers - Bob

We are looking to implement DirectAccess due to the lack of user involvement. I've had a good read of it and it's a fairly secure system using certificates and entries in AD.

It can also use OTP, Radius for authentication.

Coupled with WAF, it would be fairly secure I think.

So our plan is:
WAF > Outside DMZ > Direct Access Server > Inside DMZ > Corporate Network

You only need to expose TCP 443 so it's basically like the Microsoft RDS Gateway and fairly secure.

After the earlier exchange, I looked at the product a little more, and it seems intriguing.   We look forward to a report on your deployment.

After the earlier exchange, I looked at the product a little more, and it seems intriguing.   We look forward to a report on your deployment.