Skip to main content

Minimal Installations & the Consultants who Have no Clue

I've got a simple mantra that I sometimes express as the 'Least Bit Principle'. It's not complicated. In any system, install and configure the least number of services, packages, configurable entities, permissions or privileges necessary for system functionality. This goes way back to the days when one needed to disable defaults services while hardening a new server (chargen anyone?) and it applies to any complex system, such as operating systems, databases, routers, firewalls, etc. It's not new, it's not radical.

The fundamentals of this principle are self evident.
  • What is the minimum software needed to support the application functionality? (Hint: It's not 'Entire Distribution')
  • What are the minimum file system privileges necessary for application functionality? (Hint: It's not 'Everyone/Full Control')
  • What are the minimum database privileges necessary for application functionality? (Hint: It's not 'DBA' or 'DBO')
  • What are the minimum services that need to be running to support the application functionality? (Hint: You don't need chargen, rsh, rcmd or IPX)
For software installation, general expression of this principle is that if a package or feature is not installed, it does not have to be maintained, patched or upgraded, and more importantly, if the package or feature is not installed it cannot be accidentally enabled in an unconfigured or partially configured insecure state. When code red and slammer hit, how many of the victims  knew they were running SQL server or IIS? Many of them didn't know that the vulnerable software was even installed and running, much less that they had to patch it or they'd be screwed.

This is extremely valuable for Solaris and Oracle. For both of those, we are able to minimize the installations and defer a significant number of patch cycles simply because the vulnerable feature or package is not installed.  If the vulnerable software is not installed, we do not have to consider the vulnerability. It's even on Microsoft's radar. With server 2008, it is finally possible to install a minimized version of the operating system. I dream of the day when my IIS server will not have a GUI browser, and I'll be able to ignore vulnerabilities and patches that infect the pathetically insecure userland software that infests my servers.

So a vendor (Sun) offers to help out with a proof of concept. They delegate the actual install to a VAR. The consultant paid by the VAR (or Sun) shows up and starts to build an 'Entire Installation' server. We insist that 'Entire Installation', which includes software that we will never, ever use on that server, is not appropriate and does not meet our standards. We declare to the consultant that what we need is 'Reduced Networking Core System Support'. The vendor (Sun) provides and supports minimized installation options for the software (Solaris) and we expect the consultant to perform a minimal installation plus the specific packages necessary for supporting the intended application. What's so hard about figuring out a dependency tree and installing the minimum software necessary to resolve the dependencies? The consultant balked.

In this case, fatigued from having to deal with clueless consultants, we said screw it. We'll end up running the proof of concept with an 'Entire Installation', throwing it away and doing the minimal installation later when & if it moves to production. It shouldn't have to be that way though. It's 2009 and I expect consultants to think and act like it's the 21st century.

Why are all my 'vendor' posts also tagged as 'annoying'?

Comments

  1. If it isn't on there, it can't go wrong.

    It's one reason I get peeved at finding stuff like ALSA being installed as default on Ubuntu Server Edition, along with a few other random packages. A LAMP stack, DB server, DNS server or whatever does not need sound. In theory I don't ever want to see a monitor and keyboard hooked up to the thing after iLO (or equivalent) has been set up.

    I was at a computing conference several years ago, not long after code red was released. The Microsoft guy there claimed Microsoft didn't want to release a fully clogged up operating system, but felt their hands were tied by the great "unwashed masses" (his words) that "couldn't install their way out of a paper bag". He also stated they were going to be doing things radically differently with Windows 2003 (ha, ha) and have nothing extraneous installed.

    My view? Anyone that can't manage to install IIS shouldn't be allowed to have servers connected to the internet. If you can't even install IIS, you sure as hell aren't going to be capable of securing it.

    Viruses, trojans, and zombies are a big issue and costing a significant amount of money, and it's really not helped by clueless server admins.

    ReplyDelete
  2. @garp - I'd actually argue that anyone who INSTALLS IIS and uses it as a web server shouldn't be allowed to connect servers to the Internet. :P

    ReplyDelete
  3. Theoretically, installing a min install should be pretty easy, but I doubt in practice it is because most software doesn't have well documented dependencies... so you'd be stuck with an endless test/installation loop.

    ReplyDelete
  4. To build a pair of minimal Solaris golden images took a person-week. The image without Java support is about 600MB, and the image that has enough bits to support java is about 1GB.

    We have those images deployed on dozens of app and database servers. They work.

    ReplyDelete

Post a Comment

Popular posts from this blog

Cargo Cult System Administration

“imitate the superficial exterior of a process or system without having any understanding of the underlying substance” --Wikipedia During and after WWII, some native south pacific islanders erroneously associated the presence of war related technology with the delivery of highly desirable cargo. When the war ended and the cargo stopped showing up, they built crude facsimiles of runways, control towers, and airplanes in the belief that the presence of war technology caused the delivery of desirable cargo. From our point of view, it looks pretty amusing to see people build fake airplanes, runways and control towers  and wait for cargo to fall from the sky.The question is, how amusing are we?We have cargo cult science[1], cargo cult management[2], cargo cult programming[3], how about cargo cult system management?Here’s some common system administration failures that might be ‘cargo cult’:Failing to understand the difference between necessary and sufficient. A daily backup is necessary, b…

Ad-Hoc Verses Structured System Management

Structured system management is a concept that covers the fundamentals of building, securing, deploying, monitoring, logging, alerting, and documenting networks, servers and applications. Structured system management implies that you have those fundamentals in place, you execute them consistently, and you know all cases where you are inconsistent. The converse of structured system management is what I call ad hoc system management, where every system has it own plan, undocumented and inconsistent, and you don't know how inconsistent they are, because you've never looked.

In previous posts (here and here) I implied that structured system management was an integral part of improving system availability. Having inherited several platforms that had, at best, ad hoc system management, and having moved the platforms to something resembling structured system management, I've concluded that implementing basic structure around system management will be the best and fastest path to …

The Cloud – Provider Failure Modes

In The Cloud - Outsourcing Moved up the Stack[1] I compared the outsourcing that we do routinely (wide area networks) with the outsourcing of the higher layers of the application stack (processor, memory, storage). Conceptually they are similar:
In both cases you’ve entrusted your bits to someone else, you’ve shared physical and logical resources with others, you’ve disassociated physical devices (circuits or servers) from logical devices (virtual circuits, virtual severs), and in exchange for what is hopefully better, faster, cheaper service, you give up visibility, manageability and control to a provider. There are differences though. In the case of networking, your cloud provider is only entrusted with your bits for the time it takes for those bits to cross the providers network, and the loss of a few bits is not catastrophic. For providers of higher layer services, the bits are entrusted to the provider for the life of the bits, and the loss of a few bits is a major problem. The…