Stay Ahead With Linux Security Features
security advisory attack A Linux server gets cleaned up after an intrusion. The suspicious process is terminated, credentials are rotated, and the system is rebooted during maintenance. Everything seems secure. A few hours later, the same outbound connection appears again. . Situations like that point to persistence . The attacker no longer needs the original exploit because something on the host continues restoring access behind the scenes. Finding that mechanism is often more important than understanding how the...
Jun 08, 2026
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
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 -3 articles for you...
102
security advisorysoftware updatesecurity enhancementsOpenwall: LKRG 0.9.0 Release: Major Changes And Security Fixes
Openwall recently announced the release of LKRG (Linux Kernel Runtime Guard) 0.9.0, featuring a host of major changes and improvements, as well as fixes for multiple security bugs. LKRG is a kernel module that performs runtime integrity checking of the Linux kernel and detection of security vulnerability exploits against the kernel. . In an email sent to the LKRG Users List announcing the release of LKRG 0.9.0, Openwall Founder Alexander Peslyak (known by many as “Solar Designer” ) outlines the major changes that have been made between LKRG 0.8.1 and 0.9.0, and explains the significance of these updates: *) Support new mainline kernel versions 5.8 to 5.12 (inclusive) and new stable kernels 5.4.87+ (which include some back-ports from 5.8+) *) Support new RHEL kernels up to RHEL 8.4's (inclusive) *) Support building LKRG in the kernel tree (not only as a standalone module), as a module or linking into the kernel image (see scripts/copy-builtin.sh) *) Support CONFIG_FUNCTION_TRACER with or without CONFIG_DYNAMIC_FTRACE *) Support various CONFIG_OPTPROBES configurations *) Support loading overlayfs[2] after LKRG (e.g., by Docker; previously, the overlayfs[2] module had to be loaded before LKRG for Docker to work) *) "Support" CONFIG_GCC_PLUGIN_RANDSTRUCT (don't monitor SELinux if enabled) *) Explicitly do not support RT kernels *) Fix support for 32-bit x86 (was unintentionally broken in LKRG for ages, but could mostly work on many pre-5.7 kernel and LKRG builds by "luck") *) Fix detection of process user/group ID corruption to cover any unexpected changes (previously, only numerically lower new IDs, as exploits normally use, would be detected - a limitation left over from early LKRG testing) *) Fix logging of WP/SMEP/SMAP violations on systems with SMAP in the "log and accept" mode (previously, one such violation could mute logging of others) *) Add detection of ADDR_LIMIT corruption attacks *) Remove validation of waking-up tasks (drop pint_validate=2) *) Replace execve(2) hooks (instead hook security_bprm_committing_creds and security_bprm_committed_creds, which shortens the race window for exploits) *) Replace ptrace(2) hooks (instead hook security_ptrace_access) *) Simplify UMH blocking and make it compatible with CPA-protected pages *) Simplify and speed up do_exit hook (no need to validate a dying process) *) Many other changes under the hood to make LKRG easier to maintain and debug *) Integrate LKRG with out-of-tree (a tool to assist kernel module testing) *) Integrate LKRG with mkosi (systemd's tool for generating a test boot image) *) Continuous Integration setup: boot tests on GitHub Actions using mkosi (with Ubuntu's release kernels and their daily builds of mainline kernels) As you can see, we had to make changes to support Linux kernels newer than those available at the time of previous release. Almost every major kernel release, and some back-ports too, broke compatibility with LKRG. Since we did not make new LKRG releases, people with those newer kernels were advised (on the LKRG homepage and otherwise) to use our latest code off GitHub, which we tried to keep in a stable state (lately in part through use of Continuous Integration). We also preserved support for all of the old kernels we supported previously (RHEL7, etc.) LKRG 0.8.1 was already smaller than 0.8, and with 0.9 the LKRG source code became a bit smaller again (at least in terms of line count) due to the simplifications we made, despite of significant additions: $ git diff --shortstat v0.8.1..v0.9.0 126 files changed, 3919 insertions(+), 4375 deletions(-) Also, perhaps in part due to our move to GitHub, we started to receive more direct contributions to LKRG development (GitHub pull requests). The fulllist of direct contributors to this release is: $ git shortlog -sn v0.8.1..v0.9.0 67 Adam 'pi3' Zabrocki 15 Solar Designer 12 Mariusz Zaborski 7 Vladimir D. Seleznev 5 0xC0ncord 5 RageLtMan 5 Vitaly Chikunov 2 F0x1fy 1 William 1 disrupttheflow I'd like to specifically highlight the contribution of support for building LKRG in-tree (scripts/copy-builtin.sh and related testing) by RageLtMan and the contribution of mkosi integration and Continuous Integration setup by Vitaly Chikunov. I'd also like to highlight Mikhail Klementev's offer to use his out-of-tree framework, which Adam eventually added the integration for. The announcement also mentions various Linux kernel issues that LKRG principal developer Adam 'pi3' Zabrocki discovered in the development and testing of LKRG: During LKRG development and testing I've found 7 Linux kernel bugs, 4 of them have CVE numbers (however, 1 CVE number covers 2 bugs): CVE-2021-3411 - Linux kernel: broken KRETPROBES and OPTIMIZER CVE-2020-27825 - Linux kernel: Use-After-Free in the ftrace ring buffer resizing logic due to a race condition CVE-2020-25220 - Linux kernel Use-After-Free in backported patch for CVE-2020-14356 (affected kernels: 4.9.x before 4.9.233, 4.14.x before 4.14.194, and 4.19.x before 4.19.140) CVE-2020-14356 - Linux kernel Use-After-Free in cgroup BPF component (affected kernels: since 4.5+ up to 5.7.10) I've also found 2 other issues related to the ftrace UAF bug (CVE-2020-27825): - Deadlock issue which was not really addressed and devs said they will take a look and there are not many updates on that. - Problem with the code related to hwlatdkernel thread - it is incorrectly synchronizing with launcher / killer of it. You can have WARN in kernels all the time. CVE-2021-3411 refers to 2 different type of bugs: - Broken KRETPROBE (recently reported) - Incompatibility of KPROBE optimizer with the latest changes in the linker. Additionally, I've also found a bug with the kernel signal handling in dying process: CVE-2020-12826 - Linux kernel prior to 5.6.5 does not sufficiently restrict exit signals However, I don't remember if I found it during my work related to LKRG so I'm not counting it here (otherwise it would be total 8 bugs while 5 of them would have CVE). That's pretty bad stats... However, it might be an interesting story to say during LKRG announcement of the new version. It could be also interesting talk for a conference. The kretprobes and ftrace issues here are of questionable security relevance (this functionality is not exposed for attack under most reasonable threat models), but all of these are interesting bugs. Peslyak welcomes any feedback on this release. In a recent email exchange with LinuxSecurity.com security researchers, Peslyak summarizes the main benefits that LKRG offers users, “LKRG offers best-effort protection against kernel vulnerability exploits with little effort on behalf of the user - no need to configure a policy, etc. - making it especially beneficial for systems that are not expected to be consistently kept up-to-date.” You can download LKRG 0.9.0 lkrg . Are you using LKRG to help secure your Linux system? Have you downloaded LKRG 0.9.0? What are your thoughts? We want to hear! Connect with us on social media: Twitter | Facebook . Openwall unveils LKRG 0.9.0, featuring major updates and essential security patches aimed at bolstering kernel security and overall integrity.. LKRG, Runtime Integrity Guard, Openwall, Linux Kernel, SecurityImprovements. . Brittany Day
Apr 19, 2021
•
102
kernel securitysecurity toolssecurity improvementEnhancing Linux Kernel Defense: Open-Source Tools and Strategies
Kernel security is a key determinant of overall system security. After all, the Linux kernel is the foundation of the OS and the core interface between a computer’s hardware and its processes. Luckily, Linux now supports a range of effective open-source extensions and external tools engineered to boost kernel security. From the threats you should be aware of to the initiatives and technologies designed to reinforce and enhance the security of the Linux kernel, here's what you need to know. . The Open-Source Security Advantage Enterprise IT environments are becoming increasingly reliant on open-source technologies, but companies too often fail to approach those technologies with the same attention to security as they do with commercial and closed-source alternatives. Of course, open-source technologies are traditionally more secure than IT products that have been commercially developed. The Linux OS, for example, is known for its high level of security and has been exposed to far fewer bugs than its closed-source counterparts. This can largely be attributed to the nature of open-source development - higher levels of transparency and user scrutiny than proprietary development results in the rapid identification and elimination of potential security vulnerabilities in open-source code. The Impact of OpenSFF Launched in August 2020, the Open Source Security Foundation (OpenSSF) was created with the sole intention of improving the security of open-source software (OSS). A combination of The Linux Foundation’s Core Infrastructure Initiative, Github’s Open-Source Security Coalition and the Joint Open-Source Software Initiative, OpenSSF is a cross-industry collaboration that intends to continuously work to improve OSS security. OpenSSF has lofty goals and is already producing real-world results. Along with the accessible courses open to software developers (the Secure Software Development Fundamentals), they have also launched scoring systems that auto-generate reports into security andcriticality. The launch of a security metrics dashboard is still in its early stages but seems to be a very promising addition that should help boost kernel security. Overall, OpenSSF is one of the most significant steps forward in terms of improving OSS security. What Are Some Common Linux Kernel Attacks? From kernel data attacks that change the way that an OS functions to malware attacks that remain a serious, persistent threat, Linux kernel attacks are as dangerous and disruptive as ever. Let’s take a closer look at some of the main threats to the Linux kernel. Rootkits & Kernel Data Attacks Threat actors wishing to breach open-source security systems will commonly alter the in-memory kernel data so they can manipulate and change the way that the OS behaves. Doing this means that they don't have to worry about inputting any form of malicious code. This type of exploit is known as a kernel data attack and, although somewhat rare, these attacks could quickly become as disruptive as more traditional kernel rootkits - a particularly damaging type of malware that is able to hide from both antivirus software and the human eye. Rootkits work by modifying files (and in some cases replacing them entirely). While other OSes suffer from rootkit insertion to a much greater extent than Linux, Linux users can be just as susceptible to data theft, the intrusion of remote access, or even recruitment into a botnet. The transparency of open-source kernel security technologies is becoming less of a determining factor of security as those systems grow. For example, just a few years ago Linux kernel code consisted of only two million lines. Now, that number is closer to 28 million Malware and Open-Source Technologies In the early days of the Internet, malware was used primarily as a form of digital vandalism. The purposes of malware have evolved and expanded as cybercriminals have become increasingly sophisticated in both their motives and their tactics. Now, their goals and methods of attack vary greatly and,as a result, open-source kernel security technologies have to work harder to detect malware and rootkits and to avoid exposure to different types of DDoS attacks , as well as the myriad of other ways that threat actors can breach modern digital environments. For the most part, cyber criminals' main goal is now financial gain, although there are still those with ideological reasons for attacking organizations. Implementing Linux Kernel Security with Open-Source Technologies The most common method of enhancing kernel security is the use of a software layer that sits within the OS itself. With hardware at the heart of the technology, the kernel is the next layer, and regulates all authentication instructions and governs access control. The kernel cannot then be tampered with or changed, and by using open-source kernel security technologies, transparency becomes a key aspect of improving security. As the world grows increasingly reliance on digital technologies, open-source kernel security technologies must be built with this transparency at their heart. The growing number of automation tools that can monitor Linux systems and identify errors is only making open-source kernels safer and easier to use, while exponentially improving digital security. The LSM framework allows for various security checks via the use of newly introduced kernel extensions. These extensions are not loadable kernel modules, however. Instead, they are selected during the build-time process but can be overridden when it comes to boot-time. Mandatory Access Control (MAC) extensions are one of the more comprehensive security policies for Linux, and there is a range of options to look at more closely throughout build-time. Some of the most well-known examples, such as SELinux and AppArmor , do have limited functionality, though. For more in-depth layering and protection, extensions can be built directly from the LSM framework. This gives users the opportunity to make specific changes that they may not have access to with larger MACextensions. You can find out more about LSMs and how to extend their capabilities on the Linux man-pages project. These protection systems must be enabled at all times to ensure a safe Linux environment. Introducing Linux Kernel Lockdown Lockdown is a relatively new security feature designed specifically for the Linux kernel. Part of the Linux kernel 5.4 branch, it is a feature that must be activated. Its default mode is off, simply because it can negatively affect existing systems. However, the primary function of lockdown is to prevent root account interactions with kernel code. By strengthening this divide, Lockdown counters potentially dangerous interactions that have been possible since the launch of the Linux OS. Once lockdown has been activated, there will be limitations on kernel functionality, but these will make it significantly more difficult for root accounts that have been compromised to affect the rest of the OS. This will even affect root users, so it's not a small step. Two lockdown modes are supported: Integrity: This mode disables the kernel features that will allow userland modifications to kernel code. Confidentiality: This mode disables the ability to use the kernel features that allow for the extraction of confidential information. Additional external patches can also be added to the lockdown LSM. Additional Security Features It is highly advisable that organizations allow for the enabling of UEFI Secure Boot in either 'full' or 'boot' mode - especially on x86-64 systems. This will require cryptographically signed kernels and firmware, but it means that unsigned drivers cannot be loaded for hardware. This can dramatically reduce an attack surface by making it much more challenging for threat actors to insert malicious kernel modules into a system. It can also reduce the risk of unsigned rootkits remaining in place after a reboot. It's worth noting that not all Linux distros will have Secure Boot integration and that manual intervention may be necessary at times,particularly during upgrades. Introducing the Linux Auditing System (AuditD) Developed and maintained by RedHat, AuditD is designed for Linux access monitoring and accounting. It's an excellent and robust tool that integrates very tightly with the kernel, monitoring for particular system calls. By operating at the kernel level, this allows admins to access any of the system operations that they need to. Everything can be monitored, including files and network traffic. By operating at such a granular level, the detail that AuditD offers is outstanding, and it is as useful a tool as they come. However, it does suffer from a lack of Syslog. So while it doesn't have to rely on any externals, this does mean that you have to manage all of the audit logging using only the tools available on the AuditD dashboard itself. As a result, log collection, archiving and remote logging can become a lot more challenging. Malware/Rootkit Scanners Finding rootkits is always a challenge, but there is now a wide range of rootkit scanners that make it much easier to detect and then remove rootkits. There are plenty of options available, too, with some of the biggest tech names, such as Intel (McAfee) and Norton, offering their own rootkit scanners. Smaller names are also delivering a rapid output of rootkit scanning products, making rootkit discovery and removal significantly faster and easier. If you are planning to implement a malware/rootkit scanner, it's worth bearing in mind that they are often designed with a different end-user in mind. Many are tailored to more experienced users, while others will offer more basic functionality for non-technical users. Make sure to have a clear idea of the types of features you need, and do your research on each of the existing options. The following are all highly regarded: rkhunter chkrootkit OSSEC Automated Source Code Analysis Automated source code analysis (SCA) software is more informative than traditional vulnerability scanning software, as it checks forlicense and policy compliance and security threats, as well as any version updates. If the goal is a higher quality end product, automated source code analysis software is a worthwhile investment. It is very helpful in detecting flaws and even highlighting specific solutions for application code errors. Without the need for test cases and dramatically cutting down on test time, SCA software is the common-sense alternative to manually evaluating every single line of code. These solutions are dependable and cost-effective and are particularly valuable for organizations facing repeated cases of reduced quality, compliance issues, or overlooked flaws. Although not definitive, the advent of an automated technology that reads and analyses source codes line by line is the next stage in the evolution in open-source kernel security technologies. These technologies can quickly and easily identify and then repair potential vulnerabilities across a range of open-source systems and technologies. Hackers looking to attack an open-source technology will often target buffer overflows , memory allocation bugs - or any vulnerability they are able to find. Coding issues are all too easy to miss when in-house teams are the only option, making automation key to enhanced security measures across the digital space. In Summary By utilizing the very best open-source kernel security technologies, Linux admins can ensure that their systems are secure from attacks and branches. With the rapid innovation occurring in the realm of open-source security combined with responsible administration, admins, users and data can be kept safer than ever. . Open-source kernel security technologies enhance Linux security by strengthening defenses against threats, allowing rapid vulnerability identification and patching. Kernel Security, Open Source Technologies, Rootkit Detection, Linux Protection, Malware Prevention. . Brittany Day
Feb 15, 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