Zero Trust Network Architecture and Untangle

[ianv]

I'm just starting to get my head around Zero Trust networking or more accurately how to achieve it in a small business (15 employees).

I watched a 2020 Brighttalk webinar on Zero Trust where Untangle was represented by Heather Paunton. While the purchase of Untangle by Astera might be leading to a Zero Trust offering for SME's I'm not sure that Untangle really gets it, yet.

For example, Untangle makes the assumption that if a connection comes in on a VPN then it can be trusted so, by default, that traffic is not scanned. It seems to me that Zero Trust would mean that VPN traffic should also be scanned since the device making the connection could be compromised. Of course we can all do this ourselves but it probably shouldn't be the default.

One of the objectives of Zero Trust seems to be to limit each user's access to the network so as to limit the damage which can be done by an infected client. This usually means confining each user's access to specific business applications rather than allow them to roam across the whole network. The obvious tools to do this are Policy Manager and Captive Portal although I am not sure that they would be sufficient to control access to specific business applications as distinct from Untangles own Apps.

More than anything else, I would like to see some informed discussion on this as I am sure many members of this forum have considerable experience with Zero Trust implementations involving Untangle.
Ian

[sky-knight]

Untangle cannot, and never has had the ability to scan traffic impacting on the Untangle itself.

And honestly, before we dig into all of the realities around the traffic types that can bypass most of Untangle filtration... we have to reconcile the reality that none of that matters because Untangle lacks 2FA on the admin portal. Without 2FA on the local admin... the rest is pointless.

There has been focused discussion on this by the way, so much so it's a dead horse. We're all just waiting to see what Astera's purchase really means for the product. Because presumably they're going to have to address the myriad of issues that remove Untangle from the zero trust playing field.

Or perhaps they'll continue doubling down on MFA for VPN connections as if that actually matters.

[ianv]

Thanks Rob,
I've wondered about the 2FA. It is weird for a Security product!

I've no doubt Untangle was a next generation firewall when it came out but now it's starting to look a bit like a LastGen firewall.

I suppose the only way to deal with this would be to put it behind another Router which acts as a VPN end point.

Ian

[sky-knight]

Perhaps? But the focus on VPN itself is already off target. Zero Trust methods replace VPN with mTLS because it is basically VPN with far more access control. Not to mention that it's part of the TCP/IP stack itself, and therefore some of the most tested software on the planet. So you're looking at more cloud access models for information.

Untangle can be part of the monitoring stack to ensure the cloud controls are working correctly, but it shouldn't be the ACL itself. Though there are circumstances where it's still quite potent, but most places are reverting to software on the endpoints to do that work. For my part, I think this is a terrible idea. The industry has learned many times through history that trusting software on an endpoint is objectively stupid.

So we're back to using software on the endpoint to achieve our goals, and building networks in trusted locations to enforce an audit of the software in question. Untangle is REALLY good at that part. Threat Prevention as the youngest module is certainly a huge help in this space.

But again without 2FA on the local admin UI, AND an admin UI that doesn't run as root on the box this discussion is moot. These two things override all other concerns in the Zero Trust space. After all, what good is an alarm that could possibly be disabled via a simple web request against a local web service that has God level control of the audit logs?

All of this didn't used to be a big deal, but when you're looking into process and privilege isolation required to actually achieve Zero Trust... it's an insurmountable mountain.

Want to know the dumb part? Untangle NGFW as broken as it seems? Is STILL the BEST OPTION WE HAVE. Because the other options are worse for many... many reasons. Not the least of which is the inability to do your own code audit if you require it. Zero Trust means you trust nothing, not yourself, and certainly not your vendors!

So many would construe my comments here as negative, they aren't. But they are harsh criticism of the product, and something I expect to be corrected over time. And at the same time, I should have cast a fair bit of doubt on "Zero Trust" potential in the marketplace. It's a solid methodology, but the market simply hasn't adapted to it, and I'm dubious as to if it ever will.

[ianv]

Thanks Rob,
I hadn't heard of mTLS so have now researched it a bit.

Our network setup consists of an on-premises MS AD and Exchange server connecting to the internet via an Untangle NGFW. Our production workload and data are in AWS using Microsoft Terminal services with a separate data server. Both those machines have OpenVPN clients and are on the Domain. We have a separate Web Server (Windows) in AWS which is not on the Domain, to service client requests.

I am using OpenVPN clients because I have never been successful at getting NGFW to service a private subnet in AWS despite following all the instructions. I might say several years ago I offered to pay Untangle support to set it up for me and they gave up without charge after several months!

While AWS does not officially support mTLS apparently it can be done by using AWS NLB which would pass the mTLS requests straight through to the Servers via the private network.

Microsoft seems to support mTLS via its Identity Server which starts to get messy and expensive.
Perhaps a Linux Instance as an end point could provide mTLS verification of client requests and pass the authenticated requests on to the appropriate servers?

Right now, we are converting all our internal systems to run on a Web Server when we will no longer need the Terminal Services Server.

A question, there is a lot of browser requests and server responses being sent when using data intensive apps. Would each of those requests require mTLS authentication which would presumably introduce some lag?

Rob, I realize I'm asking your advice for free and wouldn't blame you if you tell me to get lost. However, I do think this is a subject which would be of increasing interest and importance to Untangle Users as they consider the significance of Zero Trust to their own and their client's systems and I'd be grateful for any information you might like to give.
Ian

[sky-knight]

mTLS is not a VPN, it's simply mutually secured TLS. For example, when you visit a web site, that's TLS protected it has a certificate and that allows you to know that server is who it claims to be. mTLS does this too, but then also uses another certificate to validate the client. Please note, I'm using the proper protocol name TLS here, instead of the commonly referred to SSL. We do not have "SSL Certificates", we have X509 certificates used to perform SSL authentication, which is no longer used because SSL sucks and TLS has replaced it. So when you see mTLS referenced, that's the world we're talking about. This is a protocol living on layer 4!

This isn't something you build into "networks", it's something you build into applications. And it's not something you deploy for yourself, you purchase services from people that are providing it as a part of what they do. VPN is a poor alternative, but what we're stuck with in many circumstances. But it is something I expect more application vendors to use over time as all workloads migrate away from VPSs and into microservices and are appropriately secured as such.

As for what you could be doing... I'd migrate off that on premise Exchange into M365, using M365 Business Premium you have AAD, inTune, and Advanced Defender built in. All of that utterly replaces the on premise AD, you flat don't need it anymore. And if you want it, just spin up a B2S instance to run it in Azure, alongside another B2S you have Untangle so you can VPN to the Azure network easily.

If cost is a factor, there are other things that can be done to reduce your subscription load to M365 Business Standard and Basic, which also simplifies things greatly but still allows you to shed AD. But you do have that terminal server, so having AD around is rather required. So you're stuck building a VPN tunnel between AWS and Azure to get that to work, unless you just put the AD instance in AWS itself.

None of this is terribly hard, but your security reality amplifies greatly when you move servers off premise, since most on premise investments fail to properly isolate the systems. In the cloud all systems trusted or not have the same access pathway, which is easier to secure and audit.