@fuznutz04 : Keep an eye out for the "hidden" hibernate that doesn't show up under "Plan settings" (only sleep and display). I've seen multiple systems that have "Hibernate after" configured under "Sleep" in the advanced settings as default.
There's also the problem where some systems become broken and once a system goes to sleep, it will continue going to sleep no matter what after something like 2 mins of non use. Rebooting fixes it, until it goes to sleep again... there is a fix somewhere in these threads too, reg fix.
Does the software establish a connection outside the managed network or do you have to vpn to the network to reach the management server?
It all runs on HTTPS connections.
I asked if I need to be on the highway to get to my destination, or if I can take surface streets and you told me to use snow tires. WTF?
I mean it's up to you how you want to design it. I would say putting it behind a VPN is the smart way to do it. Like mentioned earlier, it isn't necessary. However, it greatly reduces your attack surface.
What attack surface? The only thing you access is the web interface.
That's still a surface. Why even let attackers get to a management server to attempt a brute force or DoD?
And that is different from letting an attacker attempt to brute force or DoS a VPN?
You always have an open port to come in.
That is true, but it doesn't reveal what's behind it. Something like mesh central would be something an attacker would be interested in, but if it's behind your VPN sever they have no clue its even there.
Except VPNs are far better known and more "interesting". Nothing says "I've got something to hide that I think is valuable" like a VPN. VPNs are big advertisers that someone believes they have something worth something.
So what? Now you have to break into the VPN and mesh central. It makes it harder for an attacker.
Breaking into the VPN doesn't net you much if your traffic is encrypted internally, in fact you are in the same spot as having all your valuable assets public facing.
VPN is easy to implement with minimal hardware in an immutable fashion and gives you an extra layer of defense that is quite difficult to breach.
Allowing an SSH connection to the managementVM from the Internet
I have not tried this approach yet, and it appears more risky than the Screen Connect approach, since SSH to that VM would be open to the Internet. Unless I'm missing some benefit to this approach, I'll not be using it.
Use a strong key, lock to your IP. Very safe. Add Fail2Ban, of course.
Or add Salt and open/close based on need so it doesn't stay open.
Fail2ban doesn't work with keys.
But it would work normally with people attacking using non-keys, would it not? Or am I missing something about what it would do?
Why would you not require keys? Not making them mandatory defeats the purpose of using them.
I think he means - if a hacker is trying to use a password on a system setup to only allow keys - the fail2ban will block those users, or won't it?
No. It's dropped before fail2ban even sees it.
Oh, makes sense. There is no "attempt" like with a password, it is "already blocked."
That's a lot of investment for a system like that. If you have hundreds of customers, it can make sense. But it takes a lot of customers to recoup the lost time into that system. It can work out well for a traditional MSP, but depends on large scale standardization to justify the investment.
I don't know about hundreds of customers. The number of end points might be more relevant. For me at about 10 MSP customers I can justify the investment. When you look at the time it takes to set up something like a zabbix server and maintaining a WSUS server vs not having to that helps make it worth it. Missed revenue because you didn't have a system in place to capture every minute hurts.
It would be a blend, I'm sure. A single customer with a million end points wouldn't make sense because you'd use more traditional tools in a single customer scenario. And a hundred with only one end point each wouldn't do it either. So some combination of enough end points for volume and enough customers for complexity put together.
Thanks to @Dashrender for the assist. It looks like the problem was authentication. I authenticated to the VPN using domain\username rather than using the User Principal Name. Doing the latter allowed me to reach DFS shares.
Woops, that's crazy but definitely there is an issue with DNS
If the user cannot login with UPN there is an issue with DNS.... As you should be able to use domain.com.
User can login with UPN. They were using the old domain\username method rather than UPN, which apparently caused problems with accessing stuff via the DFS namespace.