Linux Patch Management Primer - Challenges, Pros, and Cons

With Linux inherently different from Windows in areas such as operationality, features, ease-of-use, and flexibility, it’s only natural to assume that there will be major differences in terms of patching and patch management between the two operating systems. This guide will cover the various facets of Linux patch management – from necessity to complexity, structural difference, challenges, limitations, advantages, versus disadvantages. Enjoy!

Challenges in Linux Patch Management

Obviously, no self-respecting IT administrator would go about applying Windows patch management principles on devices and ecosystems running Linux. To start with, Linux, which is regarded as the embodiment of open-source software, allows the user to dimension and re-dimension each and every component, including the kernel – great for security, but does not win a lot of points in the area of accessibility. For all its popularity and history, Windows remains a closed OS (ie, only some members have access to the source code) and, unfortunately, more prone to security issues than Linux.

Now, in terms of patch management, Windows has so graciously accustomed us with patching flows such as WSUS- or SCCM-based. For Linux, it’s all about repositories – think big bookstores stuffed to the brim with all manner of neat resources. Even more enticing (for everybody) is that these repositories are free for all and anyone – with enough coding experience – can contribute. Mind you that not all Linux software repositories are open-source.

For instance, as far as Ubuntu repositories go, the main or canonical are free for use. Same goes for the so-called Universe or Universal repositories are also on the house and, as an added bonus, community-maintained. On the other hand, Restricted and Multiverse repositories, which contain proprietary drivers or software with copyright issues, are not open to the public.

Anyway, as you’ve probably guessed, the first challenge in Linux Patch Management is matching the patch or update to the right repositories. There are literally thousands of Linux repos out there and any attempt to manually retrieve and deploy patches would be a waste of time, not to mention madness, especially when your business’s ecosystem has hundreds of devices running different Linux versions or distros. So with manual patch management out of the picture, let’s check out automatic patch management.

According to the paper “Linux Patch Management: With Security Assessment Features”By Gary Wills and Soranut Midtrapanon, there are three approaches to automatic patch management: agent-based, agentless, and passive network monitoring. What’s agent-based patch management?

In a nutshell, all things related to patching (ie, querying local or web repos for the updates and patches, push & deployment, and testing) are handled by an agent (ie, application) installed on the machine – great for accessibility and ease. -of-use, but bad for security, since the agent requires local admin rights to fetch and deploy the patches or updates. To tie any loose ends, the agentless approach was created; Bye-bye to local admin rights, caching, and storage.

Of course, this type of approach can greatly reduce patching speed and reduce downtime associated with this type of operation. In addition, agentless patch management can accommodate a greater number of devices compared to the agent-based approach. Seems like a match made in Heaven except for one tiny caveat – bandwidth burnout. Agentless solutions tend to max out bandwidth, leading to subpar response time when accessing network resources.

Last, but not least, we have passive network scanning – a nifty little approach that allows you to quickly figure out which endpoints are unpatched and to list all outdated applications. The approach, in itself, is sound but not very functional; Passive network scanning only allows you to discover unpatched apps and machines but has no patching functionality. More than that, passive network scanning only works on unencrypted networks and on specific applications.

To sum up, we have three functional patch management methods: agent-based, agentless, and passive, each with its own strengths and chinks. Which one is best? On their own, these approaches cannot cover an entire patch management cycle. So, obviously, the key would be a solution that combines all three approaches in order to cover all bases. We’ll talk about that in the last section of this article.

Let’s see about some other Linux Patch Management challenges.

Asset and software inventory

The first step to successful patch management has to be asset and software inventory. After all, why bother deploying patches if you don’t know what needs patching in the first place? Automated patch management, the asset inventory bit will help you secure vital info about your endpoints and, of course, provide you with better insight on your entire ecosystem.

Do keep in mind that Linux is compatible with many kinds of devices (eg, desktop computers, laptops, servers, routers, smartphones, tablets, SBCs, firewalls, and more). The solution should provide you with info such as system configuration (eg, CPU, RAM memory, SCSI drives, motherboard optical drives), machine status, Linux distribution, external, and internal IPs.

Pre- and post-deployment testing. Troubleshooting.

Another vital phase in patch management is testing. Regardless of the target OS, patches, especially those carrying security fixes, must be tested before and after deployment. Security-wise, most fixes released by 3^rd party developers are checked and double-checked prior to release.

However, in most cases, IT admins along with the SOC team would perform additional tests on the patches and updates before they are distributed throughout the network (ie, administrators will usually perform operational tests on the patches, later comparing the results against a benchmark, while the SOC conducts on the security / vulnerability-specific testing).

Of great significance in the pre-deployment testing process is the kernel assessment phase. As a rule of thumb, you should refrain from changing kernels or, more specifically, don’t go about changing kernels for apps or drivers or hotfixes that aren’t in use. For instance, if an obsolete network card driver requires a kernel change in order to receive an update, it’s best to just stop using that piece of equipment instead of making the switch.

Patch Management Tips, Tricks, and Hacks. Parting Thoughts.

Constructing a functional and flawless Linux patch management flow can be a very daunting task considering all the reasons stated above. However, there are some things you could try out in order to iron out the process, cut back on time and manpower.

All-encompassing patch management solution. As I might have mentioned, the key to successful patching is getting yourself a tool that checks out all the items on the list: agent, agentless features, and passive network scanning. Heimdal ™ Security’s Patch & Asset Management can aid you in patching existing Linux applications, identifying historical vulnerabilities, inventory hardware, and software assets. The solution accommodates OS-specific, 3^rd party, and proprietary patches, updates, and hotfixes.
Documentation. Be sure to document every step of the way: downloading, pre-deployment testing, post-deployment testing, troubleshooting. Keep the documents neat and up to date. They may be of use if you plan on conducting an audit.
Manual patching. Yes, I know it kind of sounds counterintuitive considering that I made quite a case for automatic patching, but there are some cases where you need to take the bull by the horns. For instance, if the solution fails to automatically patch an app several times, you may need to apply this patch by hand (ie, using CLI commands) to ensure that everything is hunky-dory.

Well, that wraps it up for Linux patch management. Stay tuned for more patching topics. As always, stay safe, don’t click on odd-looking links, and subscribe to our newsletter. Ciao!