Re: [SAGE] auto patching

[Dan Stoner <dstoner@flmnh.ufl.edu>]

Kenton Brede wrote:
> Background:
> We have a small set of growing Linux servers, but definitely enough
> for one person to manage.  When I started working at the university I
> decided to create some patch guidelines for myself.  I divide the
> patches into remote and local exploits and treat them differently.  I
> treat bug fixes differently than security updates.  In short if it
> isn't a remotely exploitable bug, I wait two days to patch and don't
> patch on Friday.  With these guidelines I've attempted to bridge the
> gap between blindly accepting auto updated patches and not having a
> proper test environment in place, while remaining reasonably secure.
> The machines are grouped together in RHN and with a few clicks can be
> scheduled to update.
> 
> Commentary:
> I've started to think about possibly updating the machines with
> confidential information via auto update.  The idea being protection
> is worth more than availability.  Or to just go auto update for all
> the boxes, more out of the fear of having a box cracked, than having
> the box inaccessible because installing a patch breaks something.
> 
> Question:
> How would you, or do you, approach patching in a similar environment?
> 
> Thanks,
> Kent
> 

We have a similar mantra to what you described initially.  For many 
servers, only the remote exploits are worth taking the machine out of 
service.  If you allow shell access then you would need to be more 
concerned about all of the mentioned vulnerabilities (like overflow in 
libsomethingorother).


On Linux (we use CentOS), we let all updates go in automatically 
(nightly schedule) for everything except the kernel since the kernel 
updates require a reboot.   Linux has had very few severe remote kernel 
vulnerabilities in recent years.

Maybe other folks have had stuff break from patches, but I haven't seen 
this happen in the Red Hat distro in recent years.   This has allowed us 
to build-up trust to let most patches go in automatically.

Of course, none of my servers cause millions of dollars in lost revenue 
if they go down.  Our environment can tolerate a little downtime in 
exchange for less manual intervention.  I totally agree with the 
comments from others that "patches should be tested first" preferably, 
in a test environment that is identical to the production environment. 
But for those of us who do not have a budget for such things (or put 
another way, the services provided do not warrant such a high level of 
availability), I would feel fairly confident letting the patches go in.


Generally, the only time we patch the kernel is when there is a remote 
exploit situation (very rare) or some critical bug fix (again, rare).


  Dan Stoner
  Network Administrator
  Florida Museum of Natural History
  University of Florida