Network Security
Vulnerability Management
Privileged Access Management
Endpoint Security
Threat Hunting
Unified Endpoint Management
Email & Collaboration Security
Contents:
Patch management is a big task for any IT department, and it’s even more difficult when you’re managing Linux systems, especially if we’re talking about Linux servers. 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 discuss 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 doesn’t win a lot of points in the area of accessibility. For all its popularity and history, Windows remains a closed OS (i.e., 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.
Let’s see about some Linux Patch Management challenges.
1. The lack of a centralized repository for updates
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.
2. Releasing patches can take longer
Another challenge is that some Linux distributions do not release security patches in a timely manner. This can leave systems vulnerable to attack if they are not properly patched. Also, some Linux applications are not well-supported by the vendor and may not receive security patches in a timely manner. This can also leave systems vulnerable to attacks.
3. Downtime
Yet another consideration is the amount of downtime required to apply a particular patch, especially in the case of Linux servers. If a critical Linux server needs to be rebooted, this can lead to downtime and loss in productivity, especially if it does not restart without issues. For minimum impact you should schedule the patches during off-peak hours and yet again, this means delays which can leave the unpatched servers vulnerable.
Live patching can be the solution in some cases, to eliminate the reboot process. But unfortunately, not all Linux distributions and software allow for live patching.
4. Automating the patching process on Linux is more difficult
One problem leads to another. Automating the patching process on Linux is more difficult simply because there are a lot of different types of Linux distributions and no centralized repository. Each distribution has its own package manager, which makes it hard to create a single automated patching process that would work for all of them. In addition, some distributions do not have good package management tools, making it even more difficult to automate the patching process.
There are a number of tools available to help with this, but they all have their own quirks and complexities. The first step in automating the patching process is to choose a tool that will work best for your systems. If your systems are running on Ubuntu 18.04+ you might be already in luck. Check out the Heimdal Patch & Asset Management solution for Windows & Linux
Heimdal® Patch & Asset Management Software
- Schedule updates at your convenience;
- See any software assets in inventory;
- Global deployment and LAN P2P;
- And much more than we can fit in here...
So with manual patch management out of the picture, let’s check out some technical approaches to automated patch management on Linux.
Technical Approaches to Automated Linux Patching
According to the paper “Linux Patch Management: With Security Assessment Features” by Gary Wills and Soranut Midtrapanon, there are three approaches to automated Linux patch management: agent-based, agentless, and passive network monitoring.
Agent based
What’s agent-based patch management?
In a nutshell, all things related to patching (i.e., querying local or web repos for the updates and patches, push & deployment, and testing) are handled by an agent (i.e., 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.
Agentless approach
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 do tend to max out bandwidth, leading to subpar response time when accessing network resources.
Passive network scanning
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 strength 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.
Linux Patch Management Tips
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, 3rd 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 (i.e., using CLI commands) to ensure that everything is hunky-dory.
Stay tuned for more patching topics. As always, stay safe, don’t click on odd-looking links, and subscribe to our newsletter.
If you liked this article, follow us on LinkedIn, Twitter, Facebook, Youtube, and Instagram for more cybersecurity news and topics.
