Heartbleed, Shellshock, POODLE, GHOST, FREAK… Even people who don’t interact with servers are aware that the past year has been terrible from a security perspective. While there’s no panacea that protects against security vulnerabilities, unattended upgrades can serve as the first line of defense.
Layers Upon Layers
When it comes to thinking about how computers work, some folks envision a clean room environment.
The reality is that a computer more closely resembles a Rube Goldberg machine.
From the bootloader to the operating system to the 3rd-party libraries upon which we all rely, it’s a series of buggy layers built on top of other buggy layers. This is one of the primary reasons security vulnerabilities exist.
If you develop software that is deployed to servers, this puts your software at risk, as well as any data your software touches. If you’ve effectively outsourced system administration to a platform-as-a-service (PaaS) providers like Heroku or OpenShift, you are implicitly trusting that your provider will stay on top of these security risks and adequately mitigate them. But what about those of us who need more control than PaaS providers offer and thus are responsible for managing this risk ourselves?
This article focuses on the first line of defense: automatic, unattended security updates.
Physical vs. Virtual Servers
Remember the days of provisioning physical servers? When you finished inserting the CPUs, RAM, and drives, the first boot usually involved an optical disc containing your preferred flavor of Linux. The resulting interactive installer would walk you through the OS installation process, which usually ended with an important question: “Do you want automatic security updates?”
For many of us, bare metal has been replaced by virtual servers provided by Linode, Amazon, and DigitalOcean. These virtual server instances deploy pre-built Linux images that are customized for each provider’s environment. These VPS images are designed with several goals in mind:
- minimize resources — particularly RAM and disk usage
- deliver an instance quickly
- follow the principle of least astonishment
Providers minimize RAM and disk usage by only including packages deemed critical for the virtualized instance to function at the most basic level. It is implicitly assumed that you, in turn, will install the software needed for your particular needs. Providers also want to deliver your instance as quickly as possible, ideally getting you from initial provisioning to a shell prompt within moments, which means they are loathe to provide an interactive installer that slows down the bootstrapping process and might frustrate folks who just want a prompt. Last but not least, providers take the operationally “safer” route of not enabling automatic updates by default, perhaps out of a desire to honor the principle of least astonishment. If they enabled automatic updates by default, which you probably wouldn’t know was active, and one of those updates caused a problem you did not anticipate… you might be upset.
The result is that you never see the above-mentioned guided installer and thus are never asked about automatic security updates. Moreover, these Linux images don’t include unattended upgrades and are thus unprotected by default… and many folks who use these virtual servers are completely unaware that their shiny new instance is vulnerable.
In short, virtual server providers leave it up to you to enable automatic security updates. We’ll cover how to do exactly that in the next section.
Unattended Upgrades for Debian
Installing unattended upgrades for Debian is easy enough:
apt-get install unattended-upgrades
So now you’re covered, right?
unattended-upgrades package is now installed, but it’s not enabled. How do you enable it? By editing a text file with superuser privileges and adding arcane configuration voodoo to it, of course. Duh!
Create a new file at
/etc/apt/apt.conf.d/20auto-upgrades with the following contents:
APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Unattended-Upgrade "1";
There are other ways to customize the upgrade behavior, but the above should ensure that security updates are retrieved and installed every 24 hours.
Unattended Upgrades for Fedora
Beginning with Fedora 22, you can enable automatic updates via:
dnf -y install dnf-automatic
All good, right?
Of course not. Have you not been paying attention? If you don’t have to muck around in a text file as root, then you aren’t doing anything of real value.
/etc/dnf/automatic.conf and move bits around until the file contains lines with these values:
upgrade_type = security apply_updates = yes
Now enable and start automatic updates via:
systemctl enable dnf-automatic.timer systemctl start dnf-automatic.timer
Unattended Upgrades for CentOS and RHEL
For CentOS, RHEL, and older versions of Fedora, the
yum-cron package is the preferred approach:
yum -y install yum-cron
So you’re all set, righ— Oh, never mind. You get the drill: you’re not done yet.
Ensure the following lines are present in
update_cmd = security download_updates = yes apply_updates = yes
Enable and start automatic updates via:
systemctl start yum-cron.service
Unattended Upgrades for Ubuntu
Ubuntu’s process is a bit easier:
apt-get install unattended-upgrades dpkg-reconfigure -plow unattended-upgrades
The latter will spawn an interactive dialog. While easier than other distros, it’s still a cumbersome, syntactically awkward way of setting up automatic security updates.
There’s an Easier Way: Monitorial
It’s remarkable that this kind of manual fumbling is required in the 21st century. You shouldn’t have to jump through hoops to get a baseline level of server security, and that is precisely why we built Monitorial, which handles all of the above for you automatically — and a whole lot more.
Monitorial ensures your servers have the latest security updates and lets you know when you need to reboot them. Enter your email address below to get early access.