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 -3 articles for you...
102
malwarerootkitsecurity techniquesLinux Rootkits: Detecting, Preventing, and Surviving an Attack
Let’s talk about a threat that’s smart, sneaky, and dangerous to your Linux systems: rootkits. If you’ve ever heard the term tossed around and wondered what a rootkit is and why it’s such a headache, you’re in the right place. These are not your usual malware nuisances —they’re tools that let attackers dig into a system, stay hidden for the long game, and potentially wreak havoc without leaving many breadcrumbs. For Linux admins and infosec pros, rootkits aren’t just pests; they’re an adversary that requires awareness, vigilance, and a specific approach to deal with. . Rootkits have been tools of choice for attackers because they allow stealthy access, often with elevated privileges, while hiding malicious activity. That’s bad enough, but detecting and cleaning them up can feel like walking through a minefield, especially if the attacker knows their craft. Whether you’re a sysadmin managing production servers or you simply want to level up your defenses, understanding what rootkits are, how they get in, and how to neutralize them is essential. What Is A Rootkit? So, what are rootkits? At its core, a rootkit is a set of software tools designed to give an attacker unauthorized access while remaining undetected. Usually, this involves privileged (or "root") access. Once installed, rootkits can do anything from stealing data to monitoring activity or even transforming a system into a "zombie" to carry out further attacks, like Distributed Denial of Service (DDoS) . Sound bad? It gets worse: attackers often use rootkits to conceal other malware, such as trojans or cryptominers. Rootkits don’t just appear out of thin air. They get in when an attacker finds a way to escalate privileges—maybe through a vulnerability, a misconfiguration, or even phishing to steal credentials. Once in, the rootkit installs itself deeply enough to outwit most traditional monitoring tools. Some rootkits even find their way onto systems through legitimate-looking software. Remember the SonyBMG rootkit debacle from 2005 ? It wasn’t about Linux, but it’s still relevant. Their DRM software secretly installed a rootkit on users’ PCs to enforce copy restrictions, which not only caused outrage but opened up gaping security holes that attackers could exploit. What Types of Linux Rootkits Exist? Rootkits aren’t one-size-fits-all. Different types are crafted to operate in different layers of a Linux system, each with its own level of complexity and threat. User-Mode Rootkits These are the simplest type and work at the application or user level. They might replace standard user applications like ls, ps , or netstat with malicious versions that lie about running processes or files. For example, you could run ps -aux and not see anything suspicious because the output is being tampered with. User-mode rootkits are relatively easier to detect since the kernel (hopefully) remains trustworthy in these scenarios. Kernel-Mode Rootkits Kernel-mode rootkits are a lot nastier. They operate at the kernel level, giving the attacker full control over the underlying foundation of the OS. These rootkits often come disguised as Linux Kernel Modules (LKMs), and once they’re loaded, they can mess with system calls, wipe out logs, or make themselves practically invisible. That makes detection challenging because, at this point, you can’t even fully trust the kernel’s output anymore. An example of this? A rootkit modifies the syscall table to redirect file operations or process listings, effectively cloaking itself and its activities. These are a major headache to detect, and removing one often feels like uninstalling your OS piece by piece. What Are Common Rootkit Techniques? Rootkits don’t just sit around once installed. They actively work to hide themselves and their payloads. Two of the most common strategies include: Hooking System Calls: A rootkit will hijack system calls like open , read , or write to manipulate outputs. For instance, if you check the /proc directory for running processes, the malicious rootkit simply omits its own. Tampering with Logs: Some rootkits will quietly delete or modify log entries to erase evidence of intrusions. Checked /var/log/auth.log and found nothing? That doesn’t mean no one was there—it may just mean the attacker erased their tracks. Think about that for a second. These tactics allow attackers to maintain near-total stealth. It’s like letting someone live in your house without ever noticing—messing with your thermostat, peeking into your files—and you have no clue they’re there. How Can I Detect Rootkits? Here’s the challenge: rootkits are specifically designed to avoid detection. Your regular security tooling, no matter how good, probably won’t catch a kernel-mode rootkit. Using tools like a rootkit scanner can help, but don’t rely on it completely. Tools such as chkrootkit or rkhunter can identify known rootkits, but that’s the key phrase: known rootkits. Sophisticated ones, including custom-written attackers, might fly under the radar. A solid detection approach includes: Booting from live media (USB, DVD, etc.) to a clean environment and inspecting your system’s integrity. Deploying tools like Lynis for effective security auditing. Using network packet sniffers, like Wireshark , to analyze your traffic. Suspicious outgoing connections could be a major giveaway. The sad truth: by the time a rootkit is detected, the system may already be compromised beyond repair. In many cases, the best option becomes a complete reinstall. How Can I Prevent Rootkit Infections? Preventing rootkits comes down to minimizing attack vectors. Keep your systems hardened, patched , and thoroughly investigated. Always follow these basics: Use SELinux or AppArmor to enforce security policies. Lockdown permissions: the principle of least privilege should apply everywhere. Regularly audit your systems with tools like rkhunter or chkrootkit. Consider deploying arootkit scanner regularly as part of your workflow. Segment networks to limit the damage of a compromised machine. And yeah, don’t trust just anyone with the key (i.e., credentials). You’d think this is obvious, but weak password policies—or worse, unpatched vulnerabilities—continue to be a playground for attackers. Is Trojan Virus Removal Enough? Some admins think clearing out an infection—like a Trojan virus—restores their system to normal. Here’s the hard truth: if the Trojan came bundled with a rootkit, Trojan virus removal simply won’t cut it. Rootkits are, by design, stealth operators, and removing the obvious infection doesn’t necessarily pull the hidden strings. Reinstall from trusted media when you’re in doubt. Better to go scorched earth than gamble on a compromised system. Our Final Thoughts on Combating Linux Rootkits Rootkits are scary, yes, but they’re not undefeatable. Understanding what rootkits are and how they work is half the battle—the other half is keeping a disciplined approach to monitoring and patching your systems, and sticking to best practices in securing your Linux environment. They’re not new, but what’s old isn’t always easy to see. As Linux admins and infosec pros, it’s on us to stay proactive. Take the time to set up a rootkit scanner, leverage network monitoring, and instill a culture of layered security. After all, nothing is worse than realizing an attacker has been lurking in your systems for weeks—or even months. Stay sharp. Stay protected. Stay rootkit-free. . Rootkits have been tools of choice for attackers because they allow stealthy access, often with elev. let’s, about, threat, that’s, smart, sneaky, dangerous, linux, systems, rootkits. . Brittany Day
Sep 01, 2025
•
102
network securityincident responsecase studyFTP Attack Case Study Part II: Insights on Network Security and Response
This article presents part II of a case study related to a company network server compromise. Lessons on designing and implementing security are drawn from the case. . Computer forensics investigation was undertaken and results are presented. The article provides an opportunity to follow the trail of incident response for a real case. We will organize the case study based on the prevention-detection-response metaphor. For example, how to prevent future incidents of that kind? What technological means do we need to detect them? How to effectively respond to them? I. Prevention What could the company have done to prevent it? Their network DMZ architecture was robust (see description in the previous paper ), and that actually prevented the spread of damage. As was discovered from the netForensics software network traces, the attacker had attempted to connect to several internal machines, all without success. In addition, an effective DMZ setup prevented the attacker's attempt to connect to his site and to other sites. Overall, it shows that disallowing DMZ machines all access to the outside is very important. It serves to prevent potential liability claims against your company if it is used to launch denial-of-service attacks or to commit other network abuse against third parties. Many security experts predict the rise of lawsuits against companies whose networks were used for attacks. It is much more likely that a DMZ machine will be compromised by outside attackers than a machine on the internal network. Due to this fact, DMZ machines should only be allowed to "do their job" by access rules (principle of least privilege). Namely, the web server should only be allowed to serve pages, while email servers - accept and forward mail, etc, but no more. As for the prevention of an actual accident, it is entirely clear that steps should have been taken. The system administrator should have patched the WU-FTPD using Red Hat updatepage (https://www.redhat.com/en/services/support). Updated FTPD is supposedly safe from this particular attack (see previous part for details). However, the issue is more complicated than just timely patching. Many people are saying that companies should patch immediately upon seeing the patch on the vendor site, or right after testing it, etc. But talk is cheap and security talk is no exception. It was calculated and reported that large companies (especially those that are Microsoft-only), will not have enough time to complete the previous round of patching before the next patch is released using their system and network staff. And prioritizing patches is another hard challenge ( ). The situation is dramatically better in the UNIX/Linux world, but one still has to check vendor announcements often enough to stay secure. And judging by the number of FTP scans on our honeynet, the vulnerable FTP server might be exploited within days (we see hundreds of attempted FTP accesses per day). Still, patching is good security, but it is also a losing battle. It might not seem to be, if you have just a few UNIX servers and use an automated update (or notification) system, but for a large environment it likely is. As Bruce Schneier writes in his "Secrets and Lies", information systems are becoming more complex and thus more vulnerable. His concept of "window of exposure" shows that there always will be an interval of time where attackers have an advantage. What is the prevention method that will always work? Good network design only goes so far. Hardened hosts and firewalls will not stop application-level attacks, since something will always have to be allowed to pass through. Patching will work, if you have time to do it and watch for new patches for all mission-critical software every day. Avoiding network daemons with a bad security history might help, but programs change and new bugs get introduced every day. For example, old SunOS security guidesactually recommended replacing the stock Sun ftp daemon with a "secure" WU-FTPD. And now WU-FTPD is the guilty party. One proposed solution is the emerging category of "intrusion prevention", loosely defined as operating systems or special software that puts bounds on the applications behavior. And while the precise definition is still missing (see some discussion at Security Information, News and Tips from TechTarget ), these products can sometimes prevent incidents like this - without any need to patch or update. For example, in the Linux world, EnGarde Linux and some other vendors provide solutions that can mitigate application attacks by limiting the applications behavior and stopping attacks on an unpatched systems. For example, if the FTP server was unable to spawn a shell, the attack would not have been successful. II. Detection In this case study detection was not an issue. Empty server disks served as a reliable indicator that something was amiss. However, our hypothesis is that the attacker decided to delete the disk contents only after he or she understood that the environment was not conducive for his or her purposes (no outgoing connections, nothing to hack inside). The rootkit installation presupposed the intention to keep the box for future purposes. Now imagine that the DMZ was not very robust and the attacker got away with deploying the rootkit and preserving the ability to come back. In this case, only a good network IDS (such as Snort https://www.snort.org/ ) with up-to-date attack signatures would have helped. Not surprisingly, intrusion detection attack signatures were proven to be an effective detection mechanism. But an IDS is only as effective as the person watching the screen and analyzing and correlating the log files. Products such as netForensics are also effective in detecting violations by providing a full picture of the incident and notiying the security professional. However, it remains important that somebodyactually looks at the data and acts on it. III. Response Part 1 of the paper outlined an effective investigation involving computer and network forensics. Several lessons can be drawn from it. First, having network security devices helped a lot - but only after the intrusion had occurred. The absence of a person monitoring the network in real-time made all the deployed IDS an effective forensics tool - and no more. In addition, network forensics using the data aggregation and correlation software helped to restore the picture of intruder's actions within the DMZ. In fact, if it were decided to only investigate the cause of an incident and not to go for the recovery of hacker tools, doing network forensics would have been sufficient. Second, disk forensics is not a hard science - its a game of chance. Guaranteed recovery of deleted files on UNIX file systems is simply not possible, especially in case where a long time has passed since the incident. Recovered forensic evidence helped restore the picture of the attack and gave us some hacker tools to study. However, disk forensics procedures can be very time consuming. Third, detailed analysis of hacker attacks and tools is better left for the research honeypot environment. Production systems and the people running them (i.e. system and network administrators) are not well suited for this battle, since many of the business requirements will run counter to the needs of security researchers. For example, letting hacker keep access to the box for some period of time is unthinkable for a production system. However, it should be allowed in the honeynet, since it may provide valuable feedback on hacker operations. As an overall conclusion, the case study highlights the risks of running exploitable servers, the benefits of good DMZ and some investigative techniques. Anton Chuvakin , Ph.D. is a Senior Security Analyst with netForensics ( ), a security information management company thatprovides real-time network security monitoring solutions.. This case study highlights vital lessons from a corporate network server compromise, emphasizing security measure and incident response improvements needed. Network Security, Incident Response, Forensics Techniques, Security Management. . Anthony Pell
Mar 01, 2010
•
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