They MIGHT have an internal team for this, but since we have our own IT department, my management has decide to take the costs internal versus paying the new vendor to set up remote access for themselves.
That doesn't really make sense as this is all questions about THEIR IT. All your team can do is get in the way 😉
Right, I have no idea WTF you think you are doing here @Dashrender.
The most you should do is setup a VLAN or actual separate LAN with no access to your network. The other company can deal with putting something on this shit old device that reaches to their support infrastructure.
No one on there side has even breathed a word about something like that.
As I previously mentioned - the old HVAC vendor did all of their own management - I only provided them an internet connection, they managed everything else.
I can see the advantages of that - time to toss this at the new vendor similarly.
Just use ZT to lower (all but remove) the attack surface.
That would get them up to 3FA (which isn't a bad thing) assuming ZT isn't somehow tied to some other authentication mechanism.
As it's been AGES since I've used ZT - can you make the user have to log into it each time they launch it? If yes - and it's logon isn't associated with AD (as you mentioned) then OK - I see how you consider ZT and RDP MFA.
The user can be forced to start or stop the process. The fact that it uses a key (something you have) owned by the user makes it MFA regardless of if they automate the login or force it to be manual.
Don't try to compare it to Duo or something like that which uses "something you have" to generate "something you know." Compare it to a security USB stick like YubiKey. It's a direct "something you have" 2FA in that sense.
@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.
@scottalanmiller - Just curious are you still using Tactical or just Mesh these days? I've been playing around with Tactical internally and definitely a great solution. I know you mentioned a while back you were using that and Mesh separate from each other.
We use both. Tactical has been pretty good. Definitely use Mesh 90% of the time and Tactical just 10%. But it has been a good tool and we like it.
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."