On Wed, Dec 28, 2011 at 11:33 AM, Jim Wildman <jim at rossberry.com> wrote: > The 'E' in CentOS stands for Enterprise. Enterprises use change > control. Servers do not update themselves whenever they see an update. > Updates are tested (not so much), approved and scheduled, hopefully in > line with a maintenance window. In most enterprises that I've been in, > a server can't even contact the default repo servers. And remember that > for a RHEL server, it has to be registered with RHN before it can > officially receive updates. Defaulting yum-updatesd to on will be a no-op > in almost every 'enterprise' case. > > Enterprises also don't hang servers directly off the Internet. There > are many layers betwixt the wild web and the OS. > > In the decade plus that I've been running RHEL, I've seen 1 update that > was worthy of an emergency change to push it out RIGHT NOW to the > servers. And even that one didn't really need to be done. > > ---------------------------------------------------------------------- > Jim Wildman, CISSP, RHCE jim at rossberry.com http://www.rossberry.net > "Society in every state is a blessing, but Government, even in its best > state, is a necessary evil; in its worst state, an intolerable one." > Thomas Paine > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos > To be more clear, I wasn't saying that for the particular people on this list, of whom many are professional sysadmins, that it would be the best option. I'm talking about the majority of users who have leased a dedicated server or a VPS for $5-$50 per month, and cannot ever be realistically expected to change much of the defaults. In that situation, you're weighing the likelihood, and the undesirability, of two outcomes: either (1) the machine ends up going down temporarily because of a bad update, or (2) the machine ends up being hacked and attacking other networks because it wasn't receiving updates. (Side note: my friend replied to clarify that the "kernel exploit" he was talking about that was found in March of this year, was one that allowed a local user to gain root privilege, not one that allowed a remote user to get in through the webserver or sshd. So let's say it really is true that running automatic "yum" updates is not the most important thing to keep out remote users, and that the majority of webserver hacks do occur through out-of-date web apps. Then replace everything I said with "update the web apps" instead of installing the "yum update" patches.) Would it not be best for the vast majority of those users to have updates turned on by default? If not, why not? (Power users can always turn them off, after all.) Look, one may think that root access to dedicated servers (and virtual/dedicated servers, which are almost as powerful/dangerous) should never be given out to people who haven't been professionally trained. (Some people still say that about net-connected computers generally!) But that can never be rolled back now, as long as hosting companies can legally sell unmanaged dedicated/VPS machines to the public, they will. So what can be done to reduce the risks? Or look at it this way: Suppose the government or some foundation offered a $1 million prize for any proposal that permanently lowered the rate at which CentOS servers were compromised. If you actually come up with a solution that lowers the rate, you get the money, but if you say that all end users "should" do such-and-such (and they don't), then you get nothing. What would your proposal be? My suggestion would be: 1) Implement an API call on the OS for "send this message to the machine owner". When the OS is installed on the machine, the person installing it decides how the "notify" call would be implemented -- send an email to an address, send a SMS message, whatever. If a hosting company sets it up, they could implement the call so that it automatically opens a new support ticket waiting for the customer's attention. The reason for #1 is that if the OS wants to notify the machine admin that there's a problem, then -- at least in the case of a remotely hosted cheap server or VPS -- you can't rely on the admin logging in and seeing the message. You have to proactively grab their attention somehow. Then you could use this function call for lots of things, but most importantly for #2: 2) Implement some sort of scanner program (enabled by default) that would regularly scan the machine, not just for known viruses, but for *anything* that was known to be a frequent vector for attacks, that was not configured to update itself automatically. And: - If the scanner finds an app that is not configured to update itself automatically, it sends a low-priority message (using #1) saying "There are no known exploits for this thing right now, but you really ought to turn on updates for it." - If the scanner finds a web app like WordPress that *cannot* update itself automatically, say "This app can't auto-update itself, so you're taking a certain risk just by having it at all. Just sayin'." - If the scanner finds an out-of-date component for which there is a known exploit, send a high-priority message saying "This component needs to be updated or you will be hacked." (If the hosting company implements this by opening a support ticket, they can also see if the customer doesn't respond to the ticket, and threaten to disconnect them if they don't handle it.) What would your proposal be? (Remembering that you can't change human nature, so if it relies on the majority of end users devoting time that you think they "should" do, it won't happen :) ) Bennett