Stay Ahead With Linux Security Features
threat detection scalability Building a SIEM is easier than scaling one. Most open-source deployments start as a simple "all-in-one" server. It is easy to set up, but that design rarely survives the transition from a lab to a production workload. . A SIEM watching 20 endpoints is not doing the same job as one watching 500. More endpoints mean more logs; more logs require more storage; more storage makes search heavier. Eventually, the very architecture that made your lab easy to deploy becomes the reason your production...
Jun 04, 2026
security advisory apache A newly disclosed attack technique called HTTP/2 Bomb is drawing attention because it targets the software that sits at the front of much of the Linux internet. Apache HTTP Server, NGINX, Envoy, and the ingress layers that many Kubernetes environments depend on can be forced into consuming disproportionate amounts of memory using relatively small amounts of attacker traffic. . For Linux administrators, the concern is not the HTTP/2 protocol itself. It is the possibility that a single...
Jun 04, 2026
security advisory important The compromise of Nx Console shows how much infrastructure now sits behind a single developer account. GitHub repositories, CI/CD pipelines, container build systems, Terraform projects, Kubernetes deployments. None of those systems was the initial target. The workstation was. . Attackers did not need a Linux privilege escalation bug or a remote code execution chain. They needed developers to trust a tool they were already using. For many organizations, that was enough. What Happened? Federal...
Jun 03, 2026
security advisory open-source You remove the malware. You rotate the compromised credentials. You patch the original vulnerability and close the ticket. Two weeks later, the attacker is back. . What happened? You didn't lose the battle at the exploit; you lost it at the cleanup. In many modern Linux intrusions, the malware you found wasn't the main problem—it was the fallback mechanisms left behind. These hooks quietly restore attacker access the moment you look away. If you clean a host but miss these persistence layers,...
Jun 02, 2026
security advisory Red Hat Researchers investigating a campaign now tracked as Miasma found that more than 30 packages in Red Hat's @redhat-cloud-services npm namespace had been altered to deliver credential-stealing malware. . The packages weren't being used to deploy ransomware or sabotage systems. From what has been reported so far, the objective appears to have been much simpler: collect credentials from developer environments and use that access elsewhere. GitHub tokens, cloud credentials, SSH keys, and other...
Jun 02, 2026
Refine features
X Clear Filters
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Loading...
Explore Latest Linux Security features
We found -2 articles for you...
102
encryptionkey managementpackage managementWhat Is GNU Privacy Guard (GPG)? A Practical Guide for Linux Security
You’ve probably used GPG already. Maybe indirectly through package updates, maybe signing a Git commit because the repo required it, maybe encrypting a backup before pushing it offsite. It tends to show up quietly, and once it’s working, nobody touches it again. . That’s usually where the risk starts. GNU Privacy Guard sits underneath a lot of Linux security controls that people assume are handled. Repository trust. Software integrity. Encrypted file exchange. Signed releases. The mechanics are solid, but the operational ownership is often vague. Keys get created during a project kickoff, copied to a server, added to a CI job, and then slowly fade into the background. GPG is not just a file encryption tool. It is a trust system. Every time you verify a package, sign a commit, or decrypt a backup, you are making a decision about which keys you trust and how well they are protected. If you have not defined how keys are generated, stored, rotated, revoked, and monitored, then your Linux security model has a quiet dependency you are not actively managing. This guide is not about cryptography theory. It is about what changes in your environment once GPG is in play. We’ll walk through how it actually works on Linux systems, where it shows up in daily operations, how it shifts your threat model, what tends to break in the real world, what you can realistically monitor, and what needs to be written into policy so you are not guessing during an incident. If you are responsible for systems, backups, CI pipelines, or package repositories, this touches you whether you planned for it or not. What GPG Is and How It Actually Works on Linux GNU Privacy Guard is the GNU implementation of the OpenPGP standard. In practical terms, GPG gives you two core capabilities on a Linux system. It encrypts data so only the intended recipient can read it, and it creates digital signatures so others can verify that something really came from you and has not been altered. Under the hood, it uses public andprivate key cryptography. The public key is shared and used to encrypt data or verify a signature. The private key stays with the owner and is used to decrypt data or create signatures. That sounds simple enough, but the moment you generate a keypair, you have introduced something that must be protected, backed up, possibly rotated, and eventually revoked. It is not just a file sitting on disk. On most Linux systems, key material lives under ~/.gnupg/. That directory holds your keyrings, trust database, and configuration files. Private keys are stored there unless you offload them to hardware such as a smart card or HSM. The gpg-agent process handles private key operations and passphrase caching, which means decrypted private keys may exist in memory longer than you expect if cache settings are permissive. Trust is handled through a web-of-trust model by default. There is no central certificate authority unless you build one around it. You decide which keys you trust and to what degree. That decision directly affects whether a signature is treated as valid. On a multi-user Linux system, two users can import the same public key and assign it different trust levels, which leads to very different verification outcomes. In day-to-day use, the commands are straightforward. gpg --encrypt to protect a file. gpg --decrypt to recover it. gpg --sign to create a signature. gpg --verify to check one. The complexity is not in the commands. It is in what those commands imply about key custody and trust relationships. Once GPG is installed on a server, you are not just encrypting data. You are taking on key lifecycle risk. That affects how you harden home directories, how you manage service accounts, how you configure gpg-agent, and how you think about backups of private keys. If you do not treat keys as sensitive assets with defined ownership, the encryption itself becomes the least interesting part of the system. Where Does GPG Show Up in Real Linux Environments? Most teams do not deploy GPG as a formalproject. It just accumulates. You enable signed packages because the distribution defaults to it. A developer turns on commit signing. A backup script pipes a tar archive through gpg --encrypt before pushing it to object storage. Now it is part of your Linux security posture whether you documented it or not. Package management is usually the first place it matters. APT, DNF, and RPM repositories rely on GPG keys to verify that packages have not been tampered with. When a repository key expires or is replaced, updates start failing. You see errors about missing or untrusted signatures, and suddenly, patching stalls across systems. It looks like a routine package issue, but it is really a trust chain problem. Then there is source control. Git commit signing and tag verification are increasingly required in regulated environments. A signed tag is treated as proof that a release came from a specific developer key. If that key is shared, poorly protected, or never rotated, the assurance is weaker than it appears. Backups are another common entry point. I have seen environments where nightly archives are encrypted with GPG and shipped offsite, but the only copy of the private key lived in one admin’s home directory. The encryption was strong. The operational planning was not. You only notice that mismatch during a restore test, or worse, during an incident. You will also see GPG in automation and CI pipelines. For example: Encrypting configuration files before committing them to a private repository Signing release artifacts during a build job Importing a repository public key as part of a provisioning script Encrypting secrets before storing them in artifact storage Each of those steps assumes something about key availability and trust. If a CI runner has access to a private signing key, that runner becomes a high-value target. If a provisioning script imports a public key over HTTP without verification, you have created a supply chain risk in the name of convenience. Beforeyou can assess risk, you need visibility. Inventory where GPG is already used. Look at your package manager configs, CI definitions, backup scripts, and developer guidelines. Once you map those touchpoints, you can start evaluating whether the keys involved are owned, documented, and monitored. Until then, you are operating on assumptions. What GPG Changes in Your Threat Model Once GPG is in use, your threat model shifts in ways that are easy to overlook. The cryptography itself is rarely the weak point. The weak point is almost always how keys are handled and how trust decisions are made. Confidentiality now depends entirely on private key protection . If someone gains access to a private decryption key, encrypted backups or files are readable. It does not matter how strong the algorithm is. I have seen environments with encrypted archives sitting in cloud storage, fully exposed, because the corresponding private key was copied to multiple servers for convenience. Integrity works the same way. A digital signature is only meaningful if the verifying system actually trusts the correct public key. If a malicious key is imported and marked as trusted, GPG will happily validate a forged package or release artifact. The tool is doing what it was told to do. The mistake is in the trust assignment. Revocation adds another layer. If a signing key is compromised, you need a revocation certificate and a way to distribute that information. On a single laptop, that is straightforward. Across dozens of servers and CI runners, it becomes coordination work. Some systems may continue trusting a key long after it should have been retired. Key loss is the other side of the problem. If the only private key capable of decrypting critical backups is lost, the data is effectively gone. There is no password reset. No recovery ticket. The math is unforgiving. From a Linux security perspective, GPG introduces a new class of high-impact events. A private key compromise is closer to credential theft than a typicalmisconfiguration. An incorrect trust setting can undermine package verification across a fleet. You need defined response steps for both scenarios, not just an assumption that encryption equals safety. The shift is subtle. You are no longer just protecting data at rest or verifying downloads. You are protecting and validating trust anchors. Once you see it that way, the priority of key custody, revocation planning, and verification workflows changes. Key Management Realities Most Teams Underestimate This is where most GPG deployments start to fray. Not because the crypto is weak, but because key management quietly turns into an afterthought. I have walked into environments where private keys were sitting unencrypted on production servers under /root/.gnupg/, protected only by filesystem permissions. Technically restricted. Practically exposed to anyone with root access, backup access, or a snapshot of the disk. Once that key is copied, you will not know it happened. Passphrase practices are another weak point. A strong passphrase does not help much if gpg-agent is configured with a long cache timeout and the key stays unlocked for hours on a shared system. It feels convenient during operations. It also widens the window for misuse. Shared service account keys are common in CI pipelines and automation. One keypair, used to sign artifacts or decrypt secrets across multiple jobs. No named owner. No documented rotation schedule. When someone leaves the team, nobody knows whether the key should be replaced. It just keeps working, so it stays. Revocation certificates are often skipped entirely. During key creation, GPG offers to generate one. Many people decline or never store it somewhere safe. The result is predictable. When a key is suspected to be compromised, there is no clean way to signal that to every system that trusts it. Rotation is usually informal. Keys expire because someone set a default validity period years ago, and suddenly, package installs fail or signing jobs break. Theresponse is reactive. A new key is generated under pressure, distributed manually, and the old one lingers in trust stores longer than it should. If you look at this through a GPG key management lens, the pattern is consistent. Keys are treated like configuration files instead of security assets. That mindset is what needs to change. You need named ownership, documented storage locations, defined backup procedures for private keys, scheduled rotation, and a tested revocation process. Until that is written down and periodically reviewed, you are relying on memory and goodwill. That works right up until it doesn’t. Monitoring and Auditing GPG Activity Monitoring GPG is not as straightforward as monitoring SSH logins or sudo use. The tool itself is relatively quiet. If you are not deliberately collecting the right signals, most encryption and signing activity blends into the background. By default, GPG does not produce rich, centralized logs. gpg-agent handles private key operations in user space, and unless you have configured additional logging, there is no obvious trail that says, “this key decrypted this file at this time.” That surprises people the first time they try to reconstruct an incident timeline. So you monitor around it. Start with filesystem visibility. The directories ~/.gnupg/ and /root/.gnupg/ are sensitive. File integrity monitoring or auditd rules that watch for reads, writes, and permission changes on private key files give you at least some signal. If a private key file is accessed by a process that normally never touches it, that is worth a look. Then look at the systems that depend on signature verification. Package managers log signature failures. If APT or DNF starts reporting invalid or untrusted signatures, that is not just a patching issue. It can indicate expired keys, replaced repository keys, or in worst cases, tampering. In a mature Linux security monitoring setup, those errors should be collected and reviewed, not ignored as noise. Decryptionpatterns can also be a clue. If a service account normally decrypts one backup archive per night and suddenly decrypts dozens of files outside its usual schedule, that deviation matters. You will not see “GPG misuse” in a log line. You will see unusual process execution, file access spikes, or unexpected key imports. Key import activity is another blind spot. A user running gpg --import to add a new public key changes the trust landscape on that host. On shared or critical systems, that action should be auditable. Shell history is not enough. Centralized audit logs give you a way to answer who introduced a new trust anchor and when. The reality is that GPG operations are mostly invisible unless you design monitoring around the edges. Without file integrity checks, audit rules, and log aggregation that captures signature failures and key changes, you are trusting that no one misuses or replaces keys. That is not a monitoring strategy. It is an assumption. Policy Decisions You Need to Make About GPG At some point, GPG stops being a technical detail and becomes a governance question. If you are responsible for systems, you need clear answers to a few uncomfortable things. First, who is allowed to generate keys on production systems? If every admin or developer can create long-lived signing keys wherever they want, you will eventually lose track of which keys matter. I have seen environments where three different keys were used to sign internal packages, and nobody could say which one was authoritative. That confusion turns into risk during audits or incident response. Storage location is another decision that cannot stay informal. Are private keys allowed to live on disk under ~/.gnupg/, or do you require hardware tokens or a dedicated signing service for sensitive operations? For high-impact signing keys, especially those tied to release artifacts or repository metadata, hardware-backed storage reduces exposure. It is not mandatory everywhere, but the decision should be deliberate. Youalso need standards around key strength and lifetime. GPG supports modern algorithms and configurable expiration dates. If you do not define minimum key sizes and maximum validity periods, you will end up with a mix of legacy and current keys across your fleet. That makes reviews messy and compliance reporting harder than it needs to be. Passphrase and agent configuration should be written down as well. Long cache timeouts in gpg-agent might be acceptable on a developer laptop. On a shared server, they may not be. Decide what is allowed and align it with how the system is actually used. Revocation and incident response deserve explicit treatment. If a signing key is suspected to be compromised, what happens next? Who generates or publishes the revocation certificate? How are dependent systems updated? In many organizations, this workflow does not exist until the first scare. That is late. Finally, decide how trust is established internally. The default web-of-trust model in GNU Privacy Guard is flexible, but it assumes individuals validate and sign each other’s keys. In structured environments, you may prefer controlled key distribution and centralized trust configuration instead of ad hoc trust assignments on each host. When these decisions are documented, GPG becomes part of your defined Linux security architecture. Without them, it remains a powerful tool running on convention and habit. That gap is what auditors tend to notice. Common Failure Scenarios and What They Look Like Most GPG problems do not start as security incidents. They start as operational annoyances. A failed update. A broken pipeline. A restore that will not complete. If you have seen enough of them, you begin to recognize the pattern underneath. Package management is a common trigger. An expired or replaced repository key causes APT or DNF to reject updates. The error mentions an invalid or missing signature, and patching stops across multiple systems. What looks like a routine maintenance issue is actually a trustanchor problem that was not tracked. CI and release pipelines fail in similar ways. A build job cannot sign artifacts because the expected private key is missing, locked, or expired. Sometimes the key was rotated on one runner but not another. Sometimes the trust database was never updated. The symptom is a red pipeline. The root cause is unmanaged key lifecycle. Backups surface a harsher version of the same issue. Encryption works for years. No one tests full restore with key recovery. Then, during an incident or hardware failure, you discover the only copy of the private key lived on a retired admin’s laptop. At that point, the data is intact but inaccessible. The math does not care about intent. There are also quieter failures that do not break loudly: A signing key is shared across multiple users, so accountability is blurred A public key is imported and marked as trusted without proper verification A compromised signing key continues to validate artifacts because revocation was never distributed A user encrypts sensitive data to the wrong public key and only notices after deletion of the original These scenarios are not theoretical. They show up in audit findings and post-incident reviews with uncomfortable regularity. When you use GPG, you need documented recovery procedures for key loss and key compromise. That means tested backup of private keys, stored revocation certificates, clear rotation steps, and a way to update trust stores across affected systems. If those steps are not written and rehearsed, the first real failure will double as your design review. Final Takeaways for Linux Admins Using GPG By the time GPG is woven into package verification, Git signing, backups, and automation, it is no longer just a utility. It is part of how your environment decides what to trust and what to protect. That makes it infrastructure, even if it started as a single command in a script. The main shift is ownership. If no one explicitly owns key generation, storage,rotation, and revocation, then those responsibilities are scattered across individuals and habits. The encryption may be strong, but the process around it is fragile. Over time, you start to see expired keys blocking updates, shared keys masking accountability, or private keys copied between systems without record. Most real failures are operational. Lost keys. Forgotten passphrases. Revocation certificates that were never created. Trust settings applied locally and never reviewed. The cryptography rarely breaks. The surrounding discipline does. GPG also does not replace other controls. Encrypted files still rely on correct filesystem permissions. Signed packages still depend on secure key distribution. Private keys on disk still depend on system hardening and access control. In a broader Linux security model, GPG strengthens confidentiality and integrity, but only if the underlying system is treated as hostile by default. Treat a private key compromise the way you would treat credential theft. Assume anything signed or decrypted with that key could be suspect. Have documented steps for revocation, redistribution, and trust updates. Test those steps before you need them. When you move GPG from “it works” to “it is defined, monitored, and owned,” the risk profile changes. You are no longer hoping your trust anchors remain intact. You are managing them deliberately. That difference is subtle on a calm day. It matters a great deal when something goes wrong. . Explore how GNU Privacy Guard enhances Linux security and impacts key management practices in your environment.. GPG Linux security, trust management, key lifecycle, encryption process. . Brittany Day
Feb 21, 2026
•
102
intrusion preventionsecurity toolopen sourceCrowdSec v1.1.x Release: Exciting Features and Installation Steps
On July 8, 2021, the CrowdSec team released CrowdSec v1.1.x - the latest version of their free and open-source cybersecurity solution designed to protect Linux servers, services, containers, or virtual machines exposed on the Internet with a server-side agent - with new packages and repositories, as well as improvements to to the CrowdSec agent itself. LinuxSecurity spoke with the CrowdSec team to provide readers with insight into what they can expect from this exciting release, and how they can get started with CrowdSec v1.1.x. . A Brief Introduction to CrowdSec CrowdSec is a modernized, collaborative version of the Fail2Ban intrusion-preventio n tool that is designed to run on complex modern architectures including clouds, containers and lambdas. It leverages a behavior analysis system based on logs to determine whether someone is trying to hack you. If your agent detects such aggression, the offending IP is then sent for curation. If it passes the curation process, the IP is then redistributed to all users sharing a similar technological profile to “immunize” them against this IP. Philippe Humeau, CEO and co-founder of the company explains, “The goal is to leverage the power of the crowd to create a real-time IP reputation database. Ultimately, CrowdSec harnesses the power of the community to create an extremely accurate IP reputation system that benefits all its users. With its collaborative, transparent roots, Open Source has provided and continues to provide our team with the optimal framework to accomplish this mission”. Enhancing Package Support with Package Cloud As part of the CrowdSec v1.1.x release, CrowdSec has moved its services to Package Cloud , a fast, reliable and secure cloud-hosted package distribution. This move has enabled CrowdSec to distribute more packages to their customers . Thibault Koechlin, CTO, elaborates, “Alongside existing packages for Debian and Ubuntu including Bionic, Bullseye, Buster, Focal, Stretch, Focal for x86-64 and arm, we now provide packagesfor Red Hat Enterprise Linux (RHEL), CentOS and Amazon Linux. We encourage users to update repositories’ URLs as soon as they can. The “old” repository (S3 bucket used as a repository) will no longer be updated and will be decommissioned shortly.” As part of this landmark release, CrowdSec has also added RPM and Debian package support to its firewall bouncer , which fetches new and old decisions from a CrowdSec API and adds them to a blocklist used by supported firewalls, and its custom bouncer , which fetches new and expired or removed decisions from a CrowdSec Local API and passes them as arguments to a custom user script. Various improvements have also been made to CrowdSec itself, one of the most notable being a revamp of the data acquisition process to add support for CloudWatch sources. Their CTO states, “We are excited to announce that CrowdSec can also now act as a syslog server, which should allow for the addition of many more data sources in future releases!” Getting Started with CrowdSec v1.1.x With the release of v1.1.x, getting started with CrowdSec is now easier than ever! To install CrowdSec on Ubuntu or Debian, add the repositories: curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash Then install: sudo apt-get install crowdsec -y On a CentOS or Red Hat Enterprise Linux (RHEL) system, add the repositories: curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.rpm.sh | sudo bash Then install: sudo dnf install crowdsec If you install new services after this, you can update CrowdSec to install the required collections using: /usr/share/crowdsec/wizard.sh -c Repel Attacks with Bouncers CrowdSec’s detection capabilities provide visibility into the threats targeting your system; however, deterring attacks requires an intelligent, proactive security strategy, which is where bouncers come into play! Bouncers work by querying CrowdSec’s API to know when to block anIP. They can be downloaded directly from the CrowdSec Hub . To install the Cs-firewall-bouncer in an Ubuntu or Debian repository, use: sudo apt install crowdsec-firewall-bouncer-nftables crowdsec-firewall-bouncer If you are an CentOS or RHEL user, use: sudo dnf install crowdsec-firewall-bouncer-nftables The CrowdSec Console: CrowdSec Values Your Feedback! The brand-new CrowdSec Console, which is now in private beta, provides an easy-to-use web interface to inspect multiple CrowdSec agents spread across different networks. You can create a Console account and find instructions to enroll the CrowdSec agent app . Philippe, CEO, concludes, “The CrowSec team encourages testing and feedback! To get in touch with us, visit our Gitter channel . We look forward to continuing to provide our users with versatile, reliable and user-friendly intrusion-prevention services.” . Explore the latest enhancements in CrowdSec v1.1.x for bolstered protection and learn straightforward installation methods across different operating systems.. CrowdSec Installation,Linux Security Tools,Intrusion Detection,Cloud Package Management. . Brittany Day
Aug 01, 2021
•
102
security advisorydebiansystem updateInstalling Updates For Ubuntu 22.04 LTS And Debian 10: Security Steps
Whether you are a DevSecOps engineer responsible for managing your organization’s application infrastructure or you have your own personal Linux server that you use at home, the importance of keeping your systems safe and secure against malicious attacks by bad actors cannot be over emphasized. . While there are many aspects with regards to securing systems, one fundamental best practice is to continuously patch your systems and applications as soon as they are made available. The infamous WannaCry ransomware attack from the summer of 2017, that caused much grief to millions of users is a case in point. While the patch was made available much ahead of the actual attack, it was due to a sheer lack of security discipline that the attack was successful. “While Microsoft had released patches previously to close the exploit, much of WannaCry's spread was from organizations that had not applied these or were using older Windows systems that were past their end-of-life. These patches are imperative to an organization's cyber-security, but many were not applied because of needing 24/7 operation, risking having applications that used to work break, inconvenience, or other reasons.” (Source: WannaCry ransomware attack - Wikipedia ) This article will walk you through specific steps you need to patch your Ubuntu and Debian based systems for operating system packages. We shall cover the basics of commands you need to execute through the CLI and through the GUI. We shall also cover some additional tips and techniques for automation, package conflict resolution, kernel patches and how to manage docker/container-based security updates. How Can I Update Ubuntu via the Command-Line? Most programmers prefer the command line or programmatic execution of commands. This method is quicker, you have better control, and the commands can be easily incorporated into scripts that can be setup for regular execution through automation. If you are new to the topic, the Ubuntu command manuals is a goodplace to get started. The commands we shall cover pertaining to this topic are: apt update: This command only fetches the information on latest packages that can be upgraded. Note that it does not actually upgrade any packages on the system, only refreshes the index local to the system. This package information is obtained from standard official sources and then stored locally on the system. If ever you need to check from which sources the package information gets picked, you will see it in under /etc/apt/sources.list on the system. apt list –upgradable: This command will then display the packages that have updates available and therefore can be upgraded on the system. This information is based on the information fetched previously from the update command apt upgrade: This is the actual command that does the upgrade of the packages in the system. Once executed, the OS will be successfully upgraded. Note that this command can install new packages if the dependencies require it, but it will never remove packages. apt full-upgrade: This command does a little more than what the upgrade command does. In addition to upgrading new packages and installing new packages as required, it also removes existing installed packages if it determines that the dependencies are no longer required. Use this option with caution as it can cause unexpected system behavior if your application is dependent on a specific version of the package. apt autoremove: This command is used to remove unused packages which are no longer needed by the dependent packages. This can be executed after apt upgrade Note that all of this discussion is with respect to packages that are already on the system. If you need new packages that are not already there, you need to use the apt install command. As you research and look for commands on upgrading, you will come across apt-get commands with similar options of upgrade/update etc. So, what should you use and what is the difference? Bothare package management command line tools and there is a bit of history as to how the command evolved over the years. The apt CLI is the more recent (made available since Ubuntu 18.04 and Debian 10), preferred and the officially recommended tool. It is clearer in explaining what exactly it is doing, the options that come with apt are considered to be more user friendly and covers the range of frequently used options for the average user. The apt-get CLI, on the other hand, is more low level and contains a lot more options that are for the advanced user. So how does one typically sequence these commands? Once you are comfortable with what each of these does, you can combine them together into a single command that can be set up for automated regular execution. More about that in later sections. Here are a couple of screen captures to illustrate what you would see for some of the above commands. apt update: Here you can see the various ubuntu sources that it is fetching the package information from. apt list –upgradable: Here you can see, that from that list of package information fetched from earlier step, the packages that are having new versions and can be upgraded: apt upgrade -y: This command upgrades all the packages from the previous step and shows a neat progress bar as it proceeds. The -y option installs it silently without you having to prompt again. (Side Note: This is one example of how the apt is more user- friendly than the apt-get . You would not see the progress bar in the apt-get ). How Can I Update Ubuntu via the GUI? Some users may prefer the UI way of upgrading packages as it gives neat visual steps that tells you details of the packages that makes easy reading and unlike the CLI, prompts you that a restart of the system is required after install (if needed). The GUI way of upgrading is easy to do if you have only one or two systems to manage, personal installations and only on systems which have gnome or alternative desktopavailable. In the above section, we had installed Ubuntu Desktop and connected to the system using a VNC Server/VNC viewer. Depending on your system - there are many different ways to get to the GUI. To upgrade via GUI, open the Ubuntu “Activities” folder and search for the “Software Updater” Click on Details twisty to check the listing and description of the packages that will get upgraded. A dialogue box will appear to ask you for permission to install the updates right now or later. You can also use the checkbox selector to check/uncheck the packages that you want to install. (The equivalent of this in the CLI is to upgrade only the required package instead of a general upgrade on all packages). Click “Install Now” to begin the installation. Once the updated version of Ubuntu and the updated packages are installed on your system, a window may appear asking you to restart your system in order for the changes to take effect. And after restart, you get confirmation that the computer is up to date! Update Debian via the CLI Updating Debian via CLI uses the exact same set of commands as already demonstrated in the Ubuntu section. Ubuntu is the newer operating system based on the older Debian. They are very similar in many aspects and in the context of this article, the same commands for upgrade can be used. Update Debian via the GUI In this section, we used the GNOME Desktop that came with the default installation of Debian 10. Depending on your system setup, there may be several ways of getting to the GUI. So, to get started for upgrades, press the “Super key” on your keyboard. (It is a key with Windows logo if you are on a Windows machine. If it is an Apple keyboard it is the Command key.) Type "gnome-software" and click on the software icon. Click on the Updates tab on the popup as shown in the image. If there are updates available, it will show here. Click on Download . Next, it will prompt you forupdate and restart. Once updated and rebooted you will see a confirmation as below. Extras & Tips How to block upgrades on specific packages Sometimes, there is a need to block specific packages from getting upgraded as your application may have some dependencies on the specific version and upgrading it may have a detrimental effect on the application behaviour. You still want to upgrade all other packages in the system except those specific packages. This is where the apt mark hold and apt mark unhold commands will come in handy. In the example below, we do not want to upgrade the Jenkins package as it will break the Jenkins jobs running, so we hold back its upgrade. apt-mark hold jenkins apt update -y apt upgrade -y Later when you are ready to upgrade the package, you can execute the following: apt-mark unhold jenkins apt update -y apt upgrade -y How to perform a dry run to test the configuration As the name suggests, this parameter that can be combined with (most of) the apt commands, is very useful when you want to check what would happen if you executed an upgrade, without actually running it. So, from the following output, it lays out what would happen: that one new package will be installed, one package will not be upgraded, and a few packages will be upgraded. This lets you do a quick sanity check to see if this is what you really want. apt full-upgrade --dry-run Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following NEW packages will be installed: libzstd1 The following packages have been kept back: logdna-agent The following packages will be upgraded: apt dpkg libapt-pkg5.0 3 upgraded, 1 newly installed, 0 to remove and 1 not upgraded. Managing kernels that build up in the system over a period of time A special note should be mentioned regarding kernel upgrades. Every time youupgrade a kernel, a new version of the kernel gets installed. Over a period of time, these kernels can accumulate on the system and consume significant disk space. Whenever a new kernel gets installed as part of the upgrade, you can clean up the old ones. As a best practice you can keep three kernels, the current active one plus two old ones – so that you can fall back to the old one if needed. The Debian package “byobu” has a script “purge-old-kernels” that can be used for this purpose. apt install byobu purge-old-kernels --keep 3 You can learn more purge old kernels . To see all the kernels installed on the system, check using: dpkg --list | grep linux-image To see the list of currently active kernel uname -mrs In the system below there are three kernels and the active one is the latest version Managing automatic upgrades in GUI Search for the “Software & Updates” application in the GUI Click on the Updates tab and in the option for “When there are security updates:” , from the drop down, click on the “Download and Install automatically” option. The corresponding steps in Debian are very similar: Click on Update Preferences : And set it up for automatic upgrade using these options: Managing automatic upgrades through scripts Using the "unattended-upgrades" package you can set up the system for automatic upgrades including optional reboot, email notification etc. You can check for details AutomaticSecuri . Again, the above works when you have a few systems to manage. When you are talking about hundreds of systems with live running applications that cannot be afforded to be disrupted, you have to come up with a more organized custom approach with regression testing and scheduled downtimes built into your automation scripts. Managing upgrades in the containerized world As more organizations move towards microservices and containerization of their applications, the adoption of Ubuntubased base images for running the microservices and other containers can become a common practice. Here too, updating the OS vulnerabilities periodically becomes imperative. The easiest way to handle this is to have a line of code, that does the upgrades, in the Dockerfile of your service. This way every time your Docker image gets built; it is automatically up to date with the latest OS packages. # full-upgrade' -> the function of upgrade is to install the newest versions of all packages, also intelligently handles changing dependencies with new versions of packages # 'autoremove' -> Remove packages that were automatically installed to satisfy dependencies for some packages that are no longer needed. # 'autoclean' -> Clears out the local repository of retrieved package files RUN apt update && apt full-upgrade -y && apt autoremove -y && apt autoclean -y This same combination command can be used for automation on server systems. Managing vulnerabilities that cannot be remediated through upgrade Sometimes, you can run into situations when the packages do not get upgraded through any of these usual methods and yet your system is left vulnerable. (This can only get caught when you run vulnerability scans against the system). One such example would be when there are no more new versions available on the package, when the OS version has reached EOS/EOL. In such a case, you have to upgrade to the latest OS version and if you need to buy time, another option would be to manually remove that package and install an alternative, if required. Conclusion A typical application environment, whether a cloud or on-prem model, contains 100s or even 1000s of systems that need to be kept up to date with respect to operating system patches. Self-aware organizations should ensure that their security policies mandate timely application ofpatches that get released periodically from vendors. Keeping OS packages upgraded not only improves your security posture but will also improve the stability and performance of the system. This will take you one step closer to staying compliant to various regulatory certifications like HIPAA, GDPR, SOC2, ISO and so on. And finally, that makes your customers happy! About the Authors Mrudula Madiraju Mrudula Madiraju's technical career spans across multiple technologies, domains, customers, services and products. In her current role, she manages the Security Controls and Compliance of the Spark based Analytics Engine service on IBM Cloud. Whenever time permits, she loves to learn and share tidbits of epiphanies through sessions and writings. Connect with her on LinkedIn . Chetan Bhatia Chetan Bhatia is a seasoned DevSecurityOps consultant. He is an avid problem solver, and is skilled in Python, Unix scripting, Jenkins andTekton. Chetan is great at handling crisis situations, and never has to repeat a job more than once. “Automation Automation Automation” is his mantra. He currently leads the DevOps CI/CD pipeline development for the Spark based Analytics Engine service on IBM Cloud. Connect with Chetan on LinkedIn . . Ensure strong defense for your Debian and Ubuntu systems by following these steps for effective patch management and security upkeeping. Debian Updates, Ubuntu Security, Package Management, System Patching, Security Automation. . Brittany Day
Jul 12, 2021
•
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Search Topics
Powered By
Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases
QUICK LINKS
subscribe to newsletters!
Like staying secure? So do we.
Sign up for updates, tips, and alerts!
Discover faster search, smarter navigation, and deeper Linux security insights. Read More