"Problem with that, though, is that it wants to log in as root. All the documentation says to have it log in as root. But on my hosts nobody logs in as root, unless there’s some big crisis happening."This wasn't a crisis.
This seems to be a common problem. We've had a fair number of situations where a vendor assumed that remote login as root was possible, that there were no firewalls anywhere, that all systems of the same platform had the same credentials, and that unsafe practices are generally followed.
Examples:
- Really expensive enterprise backup software that assumed that there were no firewalls anywhere. The vendor advised us that technical support couldn't help us if the customer was firewalled. (This was a while ago, but the product still requires the worlds ugliest firewall rules).
- An 'appliance' (really a linux box) that because it used the brilliantly designed random port-hopping Java RMI protocol for its management interface, couldn't be firewalled separately from its console (really a Windows server).
- A financial reporting tool that required that the group 'Everyone' have 'Full Control' over the MS SQL server data directories. No kidding - I have the vendor docs and the f*ugly audit finding.
- A really expensive load testing product that assumes that netstat, rsh and other archaic, deprecated, unencrypted and unsecure protocols are enabled and available across the network.
Here's a couple of hypothesis.
- Bob and I are the only ones in the world with segmented networks, who have remote root login disabled and who have rational security practices. To the vendors, we are outliers who don't matter.
- The vendors’ developers, who insist that the only way that they can be productive is if they get a sandbox/dev environment where they are root and they don't have any security restrictions, actually get what they ask for. The code they write then works fine (in their unrestricted environment) so they ship it. Customers don't object, so the practice continues.
(OK - maybe there are other possibilities, but they aren't as amusing as picking on developers...)
It doesn't have to be this way. A couple decades ago I installed a product that had specific, detailed instructions on the minimum file system permissions required for application functionality for each directory in the application tree, including things like write-only directories, directories with read, but not file scan privs, etc. (an early version of what's now called GroupWise)
Today? I still see vendors that assume they have 'Full Control', remote root, unrestricted networks, etc.
My solution?
- Escalate brain deadedness through the vendors’ help desk, through tiers 1-2-3 to the duty manager and don't let them close the ticket until you've annoyed them so badly that the product manager calls you and apologizes.
- In meetings with the vendors’ sales team, emphasize the problem. Make it clear that future purchasing decisions are affected by their poor design. ‘You’ve got a great product, but unfortunately it’s not deployable in our environment’. The sales channel likely has more influence over the product than the support channel.
- Ask for a written statement of indemnification on future security incidents that are shown to have exploited the vendors poor design. You obviously will not get it, but the vendors’ product support will have to interface with their own legal, which is painful enough that they'll likely not forget your problem at their next 'product roadmap' meeting.
- Do it nicely though. Things like "...man, I've got an audit finding here that makes your product look really bad, that's going to hurt us both..." are more effective than anything resembling hostility.
