12

Following the recent heartbleed vulnerability of OpenSSL, I would like to keep my EC2 machines updated on a regular basis. The naive approach would be setting an hourly cron job for security updates (sudo apt-get update && sudo unattended-upgrade).

Are there any risks of doing that? Is there a recommended update mechanism for EC2 machines?

2 Answers 2

14

The unattended-upgrades package is the standard way to automatically apply important bug fixes and security patches in Ubuntu.

I recommend installing this on every Ubuntu system:

sudo apt-get update &&
sudo apt-get install unattended-upgrades

You don't need to create your own cron job. The package installs one for you.

You can edit the default configuration if you'd like to alter its behavior: https://help.ubuntu.com/lts/serverguide/automatic-updates.html

3
  • Any thoughts on the advisability of doing this on a production server? It makes me nervous to have changes quietly applied and risk the possibility of the update failing or introducing problems.
    – ianjs
    Apr 14, 2014 at 2:19
  • 3
    By "every" I meant production systems, too. I've been auto applying Ubuntu security patches for many years and can't remember any serious issues. It makes me nervous to have a production server sitting there without patches to known security issues and risk the possibility of having them exploited. That said each situation has different needs, so you may be better off going through a rigorous testing phase for each patch. Be aware, though, that they are released all the time, so you'll be busy. Apr 19, 2014 at 18:48
  • 1
    I do not advise this unless you have a redundant / cluster setup. Ubuntu's update procedures are not up to snuff, I've had stopped services multiple times and most recently even a broken boot sector... And we don't to anything special -- just Apache as reverse proxy and Tomcat applications.
    – dualed
    Feb 6, 2018 at 15:58
1

We have been using unattended-upgrades from 2015 to 2020 with no issues. We have a small setup (on DigitalOcean) with:

  • nginx
  • mysql-server
  • php5-fpm php5-curl php5-mysql

Based on good past performance, doing updates this way feels safer than not doing it. But that's not necessarily a guarantee for the future!

This might not be such a good idea for apache, based on the reports of other users, and my past experience of apache updates. [See above, and here]

With unattended-upgrades, manual intervention will still be required when the release approaches EOL.


(Aside from the question: In my experience with TWiki, WordPress and Jenkins, keeping these apps up-to-date is actually a greater concern than the OS itself, although of course we should really do both. For peace-of-mind, you could sandbox Internet-facing apps as non-root processes running inside a Docker container.)


But since you asked about best practice, the primary approach recommended in AWS documentation is:

  • Create and start new instances to replace your current online instances. Then delete the current instances.

    The new instances will have the latest set of security patches installed during setup.

(February 2020)

This can be done as part of a blue-green deployment strategy. The advantage here is that you can run tests against your new server before switching traffic over. If your tests are thorough, then in theory your updates can be fully-automated, verified before going live, and with no downtime.

Other advantages:

  • The tests can give you advanced warning if human attention is required (as opposed to unattended-upgrades, when the warnings only come from your users once the problem is live!)

  • If your system does get compromised, or you decide to switch providers, this approach should make it easy to roll out a fresh deployment. Your deployment strategy is scripted, rather than ancient memory.

But of course there is more setup required for this approach than simply installing unattended-upgrades, and more complexity, so there is still room for error.


AWS does also mention performing the "Update Dependencies stack command", which seems to be their official way of doing something similar to unattended-upgrades. It seems that can be triggered from their Instances interface, but I'm not sure if it can be automated.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .