Tell me they have also collared the idiots who set up a damn fool system like this as well, and I’d be happier with this story.
Eh. Let me qualify that a little before I get hoist by my own petard…
They must collar the idjits that set up the design constraints that forced the engineers to setup an obviously flawed design.
In this case there is a very likely possibility that he’s full of BS and the vulnerabilities he speaks of aren’t there.
Unfortunately, I can all too easily imagine the chain of managerial idiocy that would lead inexorably, one tiny misguided decision at a time, to such a vulnerability…
Of course, when trying to isolate whose fault it was…. you’d have a veritable mexican stand off with everyone, across several corporations and design teams, quite correctly, pointing their finger at everyone else, saying, “It’s his fault!”
But yes, BS is also definitely a possibility.
How does this compare to having a jumphost/C+C server in a normal ansible (for instance) setup? Admins have SSH key access to the single host, which handles auth & deployment for the “real” servers (and allows for arbitrary command execution across a subet of/all machines).
I’m not knocking this approach, but from reading that page it’s not obvious to me what advantage it offers.
If you just use it as a bastion host, the main difference would be you wouldn’t SSH to the jumphost. SSH could be disallowed completely to a DMZ or perimeter network and you could still manage the machines inside. And it’s physically disabling tunneling / port forwarding if you are worried about such things exposing what’s within the perimeter network.
SSH could be disallowed completely to a DMZ or perimeter network and you could still manage the machines inside.
I have SSH access on our servers restricted to the internal network only, and only allow connections from our C+C server which sits on the boundary. The C+C server has public SSH access on a high port with key-only auth. I get that KeyBox would allow me to even do away with allowing SSH on the C+C server, but it would replace it with HTTP… I’m not sure which is better to be honest — SSH running key-only on a non-standard port is pretty safe…
And it’s physically disabling tunneling / port forwarding if you are worried about such things exposing what’s within the perimeter network
That’s a good point — I believe tunnelling can be disabled in sshd_config but I admit that I find it helpful on occasion.