Management Console Access – Obscurity by Security and vice versa
Every discussion about security sooner or later connects to the wonderful word obscurity. Mentioning security by obscurity is a guaranteed way of losing sight of the facts. It is vital to actually fix weaknesses and introduce strong separation of systems when implementing security. Furthermore, the leakage of useful information to potential adversaries should be eliminated. That’s the theory. Enter the discussions we have witnessed in real life and in the Internet.
A common tactic is to strip information from communication protocols that is not needed for transporting the message. Version numbers, host names, addresses, and other pieces of data are often removed when a server answers requests. Especially web applications send a ton of useful information to clients. You can see the structure of the web space, components used for rendering, server systems involved, and domain names taken from the URLs. Stripping version numbers is a good practice, but it only help if your frameworks and libraries are kept up-to-date. If you just remove the hints for the attackers, then there is not much gained. When in doubt, offence tools will try whatever they can and see if it works.
The same is true for management access. A lot of systems have ports or web pages for configuring options or accessing the back end of an application or infrastructure. These management ports should not be advertised or accessible for untrusted clients. Shutting off the access is easy for internal systems. If the management interface can be seen from the Internet, then you have two choices. Either you make this interface hard to find (by renaming the URL for example), or you implement additional controls to access it. The latter method usually involves multi-factor authentication, restricting the access to trusted clients, or using cryptographic methods to ensure access by valid parties. This isn’t security by obscurity. It’s basic security – provided you keep the systems up-to-date and you do not have weaknesses bypassing the access controls (think Shitrix or other kinds of remote code execution for example).
There is a third option: Design the management interface in a manner that no ones wants to use it or at least have a hard time understanding how it works. Arguably bad user interface design can be security by obscurity, too. However this is a major headache for defence. If you thought you had something covered, but the UI managed not to point this out or help you to verify your intention, then this is basically a time bomb sitting in your infrastructure. Regardless of the method, command line interfaces and web/graphical interfaces have various ways to turn your IT defence into hell. The recommendation is to use what works best for you and to banish everything that makes your life miserable. We have a blacklist of technologies and vendors that are not allowed within our infrastructure. It’s a start, but the occasional update may easily turn a useful tool into a curse.
Obscurity can be a part of the do-not-be-a-target strategy. This is a valid approach to security. Monty Python as illustrated the concept in their Flying Circus. This is not the same as security by obscurity where you just hide the vulnerabilities. Mind the difference.