[technion]

- Plenty of services that can't adequately be secured any other way are often mitigated by restricting access to VPN users coming in over a network device. I appreciate that "just secure the service" is supposed to be the best practice, but when you're talking about things like IPMI interfaces or SCADA devices the alternatives approache zero

- Controlling the networking equipment can open you up to things like sslstrip

[rsync]

"things like IPMI interfaces or SCADA devices the alternatives approache zero"

My strategy with IPMI has been to assign IPMI non-routable, private IP addresses, then block that address space at the interior of the network (which is sort of redundant) and then require folks to SSH onto an interior host and connect to IPMI that way.

I would be very interested in, and receptive to, criticisms of this model ...

[lmm]

The argument there would be that it's very hard to secure all access to a network - anyone compromising any network device, or e.g. physical access to the cable runs in the building, then had access to IPMI.

In a high security situation I'd keep the IPMI network physically segregated, with a small number of machines acting as access to it. Or maybe connect IPMI only within each (locked) rack, and require using something like ansible if you want to perform an operation across more than one rack. Whether the cost/benefit fits for your circumstances is another question of course.

[technion]

If you consider "ssh jump host" and "vpn" somewhat similar implementations of the same general strategy (forcing users to jump through something secure) we have a similar recommendation.

[nathwhal]

In my experience, IPMI is generally considered a part of the control plane, and not accessed via the same network as apps/data, but through a separate, more restricted/audited privatenetwork.