1. 1

    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.

    1. 2

      In this case there is a very likely possibility that he’s full of BS and the vulnerabilities he speaks of aren’t there.

      1. 3

        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.

    1. 1

      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.

      1. 1

        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.

        1. 1

          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.