I am 100% in agreement with you on that point. The most common and risky thing about building an intranet type environment is that it can lead to a false sense of complacency. What is needed is both a belt and suspenders type approach to hardening the daemons and security on individual servers and things that are within the intranet, and also security measures designed to only allow authorized endpoint clients to get into the intranet. Essentially one needs to treat the individual servers and things that are in the private IP space as if they were still facing the public internet, even if they are not.

What you absolutely never want to do is create an environment that is metaphorically like a uncooked egg, after getting through the outer shell layer, things are soft and squishy inside.

There's a principle in security called "defense in depth". Your servers shouldn't be SSHable from the public Internet, but even if that's bypassed somehow, there should still be other layers of security. Each layer of protection adds security.

There's also a principle in security that's called simplicity.

"Defense in depth" is often quoted when people want to add further complexity to a system. There are cases where adding a security mechanism that adds complexity has a benefit that is so large that it's justified (e.g. adding TLS or ASLR). But it always needs to be balanced, because complexity adds attack surface.

The system linked here seems like it's adding a whole lot of complexity and only has a very weak case to be made for what it's good for.

Not making your servers SSHable from the public Internet is absolutely worth it though, and has better simplicity than exposing them (which requires setting up firewall/NAT routes).

To be clear, we haven't been talking about the OP port-shuffling scheme for many posts now in this subthread. We're talking about not having your servers be externally SSHable, period.

That’s probably why it is described as a toy.

Is there any reference material about the culture of "if it's in the intranet it's safe"? I have had this problem with some enterprise clients, but I would like to have reference material that I can use as an authoritive source.

An obvious thing that springs to mind is that the default campus network design that is in all the standard Cisco designs let to basically everything being vulnerable when the last exchange exploit hit or the last solarwinds issue occured. But I would like to have some sources so that I can make a better case to senior management.

90s security was about protecting perimeters and network boundaries. That kind of approach, network segregation/firewalls to keep your data secure, leads to the idea that you are magically protected across impenetrable network boundaries. Which leads people to think insecure protocols are OK on the LAN, or patching policy can be slower etc. These days you would treat the LAN as untrusted and start from there. Assume already compromised. And focus on people, processes, technology, and data. Where is the corporate network boundary these days anyway in the COVID/WFH era? People's homes with all their insecure equipment? Of course you still would have your network segmentation. But as part of defence-in-depth. You just assume it's ineffective or will be circumvented, which it often trivially is: phishing, social engineering etc.

I know all of these. I also don't need a reference to Zero Trust or beyondcorp. What I'm asking for is specifically authority that can be quoted in an enterprise context to make a case for these issues.

I would however also like to hear cases against Zero Trust and Beyondcorp. The most obvious I see with the old approach is that oftentimes Engineers in those environments are not able to work and when security punches holes into the old system the whole thing becomes way more insecure than they're actually aware of.

If you just need something with the name of a low-letter-count-agency and a ".gov" in the URL, you might take a look at https://csrc.nist.gov/publications/detail/sp/800-207/final

Microsoft and Google for example have published this kind of literature.

There current reinvention of not trusting an intranet goes by "zero trust" and "beyondcorp" in the consultancy and IT management whitepaper circles, but they pile on a bunch of dynamically configured tunneling and antivirus/client pc attestation things. The previous iteration was more meme-ish, search for "there is no perimeter".

The entire concept of zero trust network.

It is, to say the least, not conventional wisdom among security engineers that simply having network segmentation is detrimental to security. The concepts you're alluding to --- "Beyond Corp" and "Zero Trust" --- are subtle, and heavily cargo culted.

Of course, if you're the one setting up the network it's always secure, it's only if someone else does it that you are vulnerable.