Patching systems versus patching appliances

June 25, 2009

We have two categories of machines here; let me call them appliances and systems. Systems are machines that users have access to or that provide complex, general services to the Internet; our login and compute servers, our IMAP server, and so on. Appliances are not user accessible, are more or less hermetically sealed, and generally only expose the specific service that they're supposed to provide.

We keep systems up to date on patches. We have to; they're exposed. But we almost never patch appliances, because not only are they hermetically sealed, they're almost always vital parts of our production environment. Once they work, we want to touch them as little as possible, and applying patches is a change, and it usually doesn't fix a vulnerability that is externally accessible. Generally this means that all we care about is OpenSSH (and OpenSSL) vulnerabilities and vulnerabilities in whatever service the machine provides.

(We don't care very much if there is a way to go from a local user account to root, for example, because everyone who can log in to the machine already has root. Now, this is slightly dangerous, since it means that someone who can get access to one of our accounts can bootstrap to compromising the entire system.)

We entirely don't care about bugfix patches for our appliances, unless we happen to be running into the bug. And generally we aren't, because we do our best to make sure that the machines work before we deploy them. (Sometimes we deploy with known issues and cross our fingers, but we try to avoid that.)

Sometimes this gets annoying. For example, our iSCSI backends are appliances, so every so often Red Hat's management tools send us plaintive emails to tell us that we are very, very out of date on patches on them. Yeah, we'll get right on that.

(Note that we don't make any particular attempt to minimize the software installed on appliances, although we do minimize the running network services. But that's another topic.)

Written on 25 June 2009.
« Another source of stickyness for social web sites
An advantage for hardware RAID over software RAID »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Jun 25 02:40:36 2009
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.