The recent vulnerabilities in Ivanti and Fortinet VPN interfaces have got me thinking about what options are available to protect the authentication interface for firewalls. Everyone knows that having a firewall authentication interface on the open internet is stupid, but it’s a necessity when your firewall and end user VPN concentrator are all in one. I’m just thinking through what options might be available for limiting access to the VPN interface to only those people that should have it. However, our end users travel for conferences, so they could connect from anywhere.
Ideally this would go beyond basic preauth as part of the VPN service because the interface should be completely unavailable to the open internet unless some condition was met.
About a decade ago, I played with port knocking on IPTables, in front of OpenVPN, but these days I’m in an industry (and country) where I have to pick technologies that can be supported by the local MSPs. That means going with the big firewall players. In our case, we were about to cut over from Sonicwall to Fortinet when last week’s vulnerability landed.
Cloudflare tunnels offer preauth, so perhaps there’s something I could do there, but as I understand it I would end up with with a SSL VPN inside an SSL tunnel, which might cause packet storm problems.
It may be that I can set up wireguard for end users to allow access to a dedicated DMZ stub that has the VPN socket available, but I would have the same VPN inside VPN issue. I would expect the networking to be a nightmare to troubleshoot.
I could set up a basic authenticated reverse proxy that allows connections to the VPN socket after successful auth, but the end users are already unhappy about the multifactor on the Sonicwall, so extra passwords are just going to cause hassle.
The recent vulnerabilities in Ivanti and Fortinet VPN are because theses are VERY OLD and not well done VPN’s. Check out Infosec Exchange and yes, that is a fully patched Ivanti system running the following versions:
While there is a risk that a flaw could be found in OpenVPN or Wireguard which are both very popular, they have both been through modern code audits and can use certificates to help validate users prior to the user/pass section.
Does Fortinet have some kind of web authentication interface?? If so, running that on your firewall is good g-d stupid. Running anything on perimeter router/firewall is stupid, but everybody does it so why not run old versions too.
Sounds like you know the value of separating your router from your other “network services”. Most mouse clickers won’t get that but if you have to deal with MSPs, then you might be stuck with bad design.
I’m curious what other people suggest. I would run (and do run) a VPN server that uses UDP and doesn’t respond to failed attempts. That is a pretty good way to hide it. Separate it from your firewall if you can so a breach there doesn’t give them root to your router. Then, if you want to create a jump box inside that VPN subnet go for it. Otherwise, I would do basic networking blocking and tackling after that. The obvious stuff to lock down and monitor that VPN link.
I replaced a lot of fortigate firewalls. IMO I think they are total junk. I spent hours on them and had some bugs for sure. Idk how they made it to enterprise but here we are.
I replaced them netgate appliances. Netgate left a bitter taste in my mouth about the way they do business and communicate with their community. I was a huge supporter and now I have to stay with them because I have some many deployed. I get that companies can make mistakes, but I really think their true colors shined and it will take quite a bit to get me back on their side. Sorry for the side rant lol.
Thanks Tom. I understand that a valid response to “it hurts when I do this” is, “don’t do that”, when the premise of the problem is fundamentally flawed.
However, I still think it’s worth talking about possible architectures that reduce the attack surface. I’m not running Ivanti (and clearly would not consider it now) but I ran PFSense for 10 years and was the network admin through the Heartbleed and ‘signed certs can sign other certs’ situations for OpenVPN. Separately, I was burned by the time the Debian OpenSSL packagers removed sections related to the random number generator.
I agree that things are better now, with OpenSSL and OpenVPN being properly audited, but bad things happen. If there’s something simple I can do to avoid being the low hanging fruit, I’d like to do it.
I’m still weighing up our options here. It may be that a firewall passthrough to a VPN appliance is the way to go but there are cost and complexity trade-offs. I either rely on the Fortigate as a VPN appliance only (and it clearly buggy) or I deploy something I have more confidence in (like OpenVPN or Wireguard) but lose the telemetry and endpoint reporting. We rely on MSPs for 24/7 cover so our choices are few.
Sounds like a classic trade-off of simplicity vs security. Reducing your attack surface is a simple and straight forward design change, but GUI’s aren’t built for that in 2024. MSP’s have to hire close to the lowest common denominator just like corporations do. All of which support the simplicity argument. Nobody gets fired for erring toward simplicity when everybody else is doing it, even when bill comes due. Fortinet admins are safe. Hell, so is Fortinet. And if the same happened to pfsense, nobody here would change anything. 100% guarantee that.
I want to argue that the added cost isn’t as big as people think, but I know I am pissing in the wind on that one. Very few would rather grep a log file than click through a GUI wizard to get reporting stats.
Pick a system that is reputable and allows sufficient cover to protect your backside. After thinking about it, that is what I would do too.
Using OpenVPN is fine as it’s a layer of security, not my only security. The concept of Zero Trust is that no one is trusted by default from inside or outside the network, and verification is required from everyone trying to gain access to resources on the network. So if someone were to gain access to my network via VPN that would not allow them automatic access to the services I have inside my network as each of them also requires authentication.
What does the zero trust mean in this particular case? Authentication typically does not stop for LAN users.
For his argument specifically, do you put a jump box between your LAN and pfsense login? Or just ssh on pfsense?
That actually would dramatically improve security just using ssh alone. I have done that from the WAN as a back door when I am about to make a change that could break something. I should lock down the pfsense GUI to loop back on the one remote pfsense box I admin…
In this scenario, Zero Trust implies that simply gaining access to the network via VPN does not grant users unrestricted access to all resources. For example, if someone gains access to the network through VPN, they would still need to authenticate themselves to access specific services or resources within the network. This additional layer of authentication helps enforce the principle of least privilege and reduces the risk of unauthorized access or privilege escalation. As for the specific argument about implementing a jump box or using SSH for accessing pfSense, both approaches can enhance security by adding an additional layer of authentication and control. Using a jump box, also known as a bastion host, allows users to access internal resources indirectly through a single, heavily fortified gateway. This helps restrict direct access to critical systems and reduces the attack surface. Similarly, restricting access to pfSense GUI to loop back on a remote pfSense box or using SSH for administrative access can improve security by limiting access points and enforcing stricter authentication mechanisms. By implementing these measures, you can enhance control over access to critical network infrastructure components and reduce the risk of unauthorized access or exploitation.
I hear you on all that. I was just curious if Tom used something else for his zero trust buzz word reference. The obvious is just to rely on layer 7 authentication once you get past layer 4 authentication. That and the firewall rules. Nothing new there.
Just wondering if he did anything special, like use SSH and restrict the GUI to loopback. I wonder why more pro’s (MSP’s) don’t do something simple like that?? I assume they don’t b/c it is rarely mentioned.
Doing this would help with any insecure web-based authentication process. Recent screen connect issues and the like. As for the OP, this simple process would be the perfect fit IMHO.
I can’t answer your question, but I think that you will be able to find a solution here https://www.youtube.com/watch?v=-U90YePfIOk. It’s 2 years old, but I think that the information is still useful, I wasn’t able to find a newer video.
I mean, as far as I understand the recent Screenconnect issue wouldnt have been that big of an issue, if people would have used a VPN, insted of just exposing it directly to the internet.
Also it’s of course not true, that all web logins have flaws and are insecure by default. That being said, I would never expose management interfaces directly to the Internet, especially for something that provides such broad access as Screenconnect, and again, even with the flaws in Screenconnect, simply using a VPN would have been enough to prevent the attacks.
Of course, more security is generally better. But the reality is that many of the victims of these hacks that have made the news recently failed to take even minimal security precautions.
So before we start selectively adding layers, which always adds complexity and at worst can even suggest false security, let’s make sure that administrators who port forward to everything because they need remote access are using a VPN instead, that they’re not setting allow-all rules because they need access to a single server or service, or chmod 777 everything because their application doesn’t work.
If such basic best practices were consistently followed, a great deal would already have been achieved and further security measures could build on this.
Otherwise, it’s more like putting 10 locks on the front door while leaving the back door wide open.
Yes, that would have helped but keeping Screenconnect behind a VPN would mean we could not have customers go to the site and join a support session instantly as they can now.
In addition, but really it doesn’t matter. I would lock down all GUI access to loopback. Making the MSP use SSH to port forward is not a big ask, and does a lot to protect the mgmt interface. If I had a lot of of those interfaces a MSP needed to access, I would setup a jump box apart from the FW itself (container).
The OP wanted to protect the VPN server itself as well - not just the mgmt interface. I already gave my $0.02 on that - and unfortunately nobody else provided any other suggestions, which likely means everybody just ignores that particular risk.
Why not? Screenconnect should just be another website they visit that happens to be routed through a tunnel instead of their WAN. Nothing fancy here.
This works for all cases except those where the VPN is the issue. In that case there are other ways to get on the screen, or you could also say in those cases you need to come into the office. Not the end of the world. And the security improvement would be huge.
Because we have about 130 clients with many having multiple locations so setting up about 200+ VPN’s so that all of our clients can have a tunneled connection to us would be a lot of labor and therefore impractical to do.
Maybe I should do a video on how to do proper threat modeling which in short would be discussing how you balance what can be done vs what is practical to do based on the most likely threats.
If budgets were unlimited we could go all out and build VPN’s for every client and all kinds of other things to lock things down, but I live in a world where budgets are not unlimited.
Let’s assume that you did make a VPN to every customer from your support center… Would that need a MUCH more powerful firewall to handle all the connections, or would you move the VPN to a separate server? Just wondering how you would do this if you had to have 200+ VPN running all the time.
We use a Barracuda device here, and upgraded it during the pandemic, basically a web to RDP that they call a vpn.
