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
security insightslinux attackslinux monitoringLinux Security Monitoring Challenges and EDR Visibility Gaps
An attacker compromises a Linux container, launches a cryptominer, sets up a way to stay in the system through a background task, and disappears before the investigation even begins. By the time analysts start looking at the logs, the workload has shut down, and the container no longer exists. . This is the visibility problem modern Linux security teams are struggling with. Security teams depend on visibility. If they cannot see what is happening on a system, they cannot investigate attacks, understand suspicious behavior, or respond quickly when something goes wrong. That problem gets much harder in modern Linux environments. For years, endpoint detection and response tools — usually shortened to EDR — matured around Windows systems. Analysts grew used to having a clear view into processes, files, network connections, and suspicious activity. Linux never followed the same path. Why Attackers Are Targeting Linux Systems At the same time, Linux became the backbone of modern infrastructure. It now powers: Cloud platforms and production servers Containers and Kubernetes clusters Enterprise applications and databases Critical internet-facing services Attackers noticed that shift too. Linux malware, ransomware, cryptominers, and cloud-focused attacks have all grown steadily more common . The issue is not that Linux lacks security tools, or that it is “less secure.” The bigger problem is that Linux environments changed faster than most monitoring tools did. Infrastructure scales automatically in the background. In some environments, the system an analyst is investigating may no longer exist by the time the investigation even starts. That creates blind spots. Sometimes large ones. What Endpoint Detection Tools Monitor on Linux At a basic level, EDR tools collect activity data from systems so security teams can understand what happened during an attack. That data includes things like: Processes starting or stopping Files being created or modified Scripts running User logins Network connections Services being installed Scheduled tasks being created Why Linux Attacks Are Hard to Detect Most Linux attacks do not look malicious at first. Attackers often use the same tools administrators rely on every day, like Python, Bash, cron jobs, and curl, allowing malicious activity to blend into normal operations. Modern Linux environments also generate massive amounts of system activity. Containers spin up and disappear constantly, processes launch through APIs, and workloads move between hosts. Security tools may see a suspicious process running, but lack the context needed to understand what triggered it or where it started. That is the real challenge with Linux detection. The issue is rarely a lack of data. It is a lack of context. Linux Environments Don’t Behave Like Traditional Systems Traditional security tools were built for systems that stayed relatively stable. A workstation came online, ran the same software every day, and usually stayed in place for months or years. Modern Linux infrastructure rarely works like that anymore. Today, many Linux workloads run inside containers. Applications are broken into small, moving parts. New workloads appear constantly while older ones disappear just as quickly. Why Containers Create Visibility Blind Spots That speed changes everything for security teams: Evidence Disappearance: A container may only exist for a few seconds. If the tool misses activity during that window, the evidence may be gone forever. Vanishing Filesystems: Files can vanish before the tool has a chance to save the details. Complex Connections: It is harder to see which process started another because workloads are launched through automated platforms instead of direct commands. Why Linux Monitoring Is So Inconsistent Unlike Windows, Linux is highly fragmented. Organizations run different versions, different "kernels" (the core of the system), and different setups. Onemonitoring approach may work perfectly in one environment and fail completely somewhere else. That complexity forces vendors into difficult tradeoffs: Collect more data, and you risk slowing down the system or making it unstable. Collect less data, and analysts lose the ability to see important activity. Common Linux EDR Visibility Gaps Many organizations assume they have more visibility than they actually do. A dashboard may appear healthy. The tool is online. Alerts are flowing. Everything looks fine. Then the investigation starts. Suddenly, there’s no record of the background task that launched the malware. No data showing how the attacker kept their access. No record of failed logins. Researchers found major gaps in areas like: Core system (kernel) monitoring Background service tracking Scheduled task (cron) monitoring Failed login visibility Changes to running processes How Container Attacks Can Evade Investigations Consider a real-world scenario involving groups like TeamTNT, who target cloud environments. An attacker breaks into a cloud workload. They launch a cryptominer and set up a background task to keep the attack running. The malicious activity spikes the CPU, and the system automatically kills the "unhealthy" container and replaces it with a clean one. When analysts arrive, the evidence is gone. Without deep data that was captured and saved before the container vanished, analysts lose the full story. Missing data is hard to notice until you actually need it. Is your Linux visibility as strong as you think? The only way to know is to test it. If your team hasn't checked what your tools actually see during a container-based attack, now is the time to start Containers Make Endpoint Visibility Harder Containers made life easier for developers, but made security visibility harder almost immediately. At the core of the Linux system, a container is just a group of isolated processes. For securitytools, this creates challenges: Short Lifespans: A workload can do its damage and disappear before anyone looks at the logs. Isolation: A tool might see a process running, but struggle to see what the rest of the container looks like at that exact moment. Automation Layers: A command might be started by an automated script, making it hard for security teams to see who or what originally triggered it. Because production systems must stay stable, security tools often have to be very "light." Heavy tools aren't allowed on critical servers. So, vendors compromise—sometimes intentionally. Why More Security Data Is Not Always Better The solution seems obvious: just collect more data. In reality, that creates its own problems. The more data you collect, the more memory, storage, and processing power you use. Security teams also struggle with alert fatigue. Flooding analysts with endless data often slows investigations down instead of helping. What they need is useful context. That distinction matters. Process Monitoring Alone Is Not Enough Traditional tools focus on processes: a process starts, a process stops. This is useful, but incomplete. Take a "reverse shell" (a common attack tool) running through Python. On the surface, it looks normal. But the picture changes when analysts can actually see the script itself. Being able to see the details inside a script can expose: Hidden IP addresses Secret network connections Commands that are usually buried behind normal-looking activity This is why Linux detection is moving beyond just watching processes. The process itself rarely tells the whole story anymore. Attackers Already Exploit Linux Visibility Gaps Modern Linux security products use advanced hooks to capture activity. These improve visibility, but they are complex. Researchers have already shown ways to trick or bypass these monitoring methods. Attackers actively study where the "cameras" are turned off. Any blind spot eventuallybecomes useful to someone. Linux detection has to move beyond the basics because modern threats operate across: Containers and automated APIs System memory and hidden scripts Cloud infrastructure and the core kernel How Security Teams Can Improve Linux Visibility To bridge the gap, security teams should focus on these practical steps: Test Your Tools: Don't trust the dashboard. Run a test that mimics an attack and verify that your tool actually records it. Look Inside Scripts: Ensure your tools are capturing the actual commands inside a script, not just the name of the program (like "Python"). Track the Container Lifecycle: Match up cloud logs with your security tools to see what happened inside a container before it was deleted. Watch the Core System: Monitor for changes to the kernel—this is where advanced attackers hide. Check for Persistence: Test if you can see changes to background tasks and scheduled jobs that allow an attacker to stay in the system. Linux Visibility Still Matters Linux systems are no longer just sitting in the background; they run the most important parts of modern business. Attackers know how valuable these systems are. The challenge for defenders is visibility. Many assume Linux security works the same way Windows security does. In reality, it has a completely different set of challenges. The industry is improving, and new tools are closing the gaps. But one reality remains: A security tool can only protect what it can actually see. Stay Ahead of Linux Security & Infrastructure Trends Interested in more in-depth coverage of Linux security, CI/CD security, software supply chain defense, DevSecOps, and enterprise hardening strategies? Subscribe to the LinuxSecurity newsletter for weekly threat analysis, infrastructure security insights, and practical guidance covering the Linux and open-source ecosystem. Related Reading Why Container Security Monitoring Breaks Down in Ephemeral Environments How Linux Malware Evades Traditional Detection Tools Why Cloud-Native Infrastructure Creates Security Visibility Gaps The Challenges of Incident Response in Kubernetes Environments Why Traditional EDR Approaches Struggle in Modern Linux Systems . This is the visibility problem modern Linux security teams are struggling with. Security teams depen. attacker, compromises, linux, container, launches, cryptominer. . MaK Ulac
May 14, 2026
•
102
threat detectionperformanceeBPFAuditd vs eBPF: Modern Approaches to Linux System Monitoring
Most teams rely on logs to understand what’s happening on a Linux system. Think of a log like a digital paper trail; every action leaves a trace somewhere. The assumption is that if something goes wrong, you can go back and piece the story together using these records. . That approach worked well when systems were small, and attackers moved slowly. However, that logic breaks down as systems grow. Modern attacks move fast, often chaining different actions together in seconds. Logs get noisy quickly. Important signals get buried under thousands of "normal" events, and by the time a human reviews them, the damage is already done. This is where the conversation around Linux security and threat detection is changing. Auditd takes the traditional approach of recording everything it possibly can. On the other hand, eBPF focuses on filtering activity the very instant it happens. Understanding the difference between them is the key to modern system visibility. What Auditd Was Built to Do The auditd Linux tool is a part of the Linux auditing system. Its job is simple on paper: record what happens on a system so you can review it later. To understand it, you need to understand system calls. Every time a program interacts with the kernel—like opening a file, starting a process, or changing permissions—it makes a system call. Auditd hooks into those calls and logs them based on rules you define. You can see how those rules are structured in the [suspicious link removed]. If a user opens a sensitive file or fails a login attempt, Auditd can record that event. It writes everything to log files, usually on disk, where it can be sent to other systems. This is why compliance teams like it. You get a full audit trail of who did what, when, and on which system. That level of detail matters during an investigation. But there is a tradeoff. Auditd doesn’t decide what is important in the moment. It just records based on your rules. Those rules often end up being very broad because missing somethingis worse than logging too much. This generates a lot of data. Filtering usually happens later on a different system, and that delay is where things start to slip. What eBPF Does Differently eBPF changes where the thinking happens. Instead of collecting every single piece of data and deciding what matters later, it lets you run small, smart programs directly inside the Linux kernel. This sounds technical, but here is what it means in practice: these programs sit at the very heart of the system. According to the official eBPF overview , they can watch system calls, network traffic, or even specific functions as they run. Instead of logging every single time any file is opened, you can write a tiny program that says: "Only tell me if a sensitive folder is accessed by a program I don't recognize." Everything else is ignored before it ever leaves the kernel. This is the power of ebpf monitoring. You reduce the "noise" at the source. You aren't moving mountains of data; you are only moving the data that actually has meaning. From an ebpf security perspective, it’s about having better control over your visibility so you don't drown in it later. System Spotlight While Auditd acts like a security camera recording everything for later review, eBPF acts like a smart bouncer at the door, deciding in real-time who belongs and who doesn't before they even enter the room. Key Difference: Where the Work Happens Most Linux monitoring tools follow a "pipeline" model: collect everything first, and analyze it later. Auditd fits this model perfectly. It captures an event, writes it to a file, and relies on a human or another piece of software to interpret it. eBPF breaks that pattern. It processes the event inside the kernel—right where it occurs. It decides immediately if the event should be kept or thrown away. This shift matters more than it might seem. By moving less data, you save storage space, use less internet bandwidth, and spend less time parsing logs. It’s the differencebetween recording 24 hours of security footage and only having a camera that turns on when it sees someone climbing a fence. Performance and System Impact Performance is where the differences become very obvious. When you are running runtime security tools, you have to consider how much "tax" they put on the system’s CPU and memory. Auditd writes a steady stream of data to the disk. On a busy system, this creates "overhead"—basically, the computer spends more time recording what it is doing than actually doing its job. This impact has been studied in detail in performance reports from EuroBSDCon and through practical analysis by experts like Brendan Gregg . eBPF reduces this pressure. Because it filters the data early, there is less data to move around. However, it isn't "free." Since eBPF programs run in the kernel, a poorly written program can still slow things down. It’s like a filter on a faucet: if the filter is too thick, the water won't flow, no matter how clean it is. What This Means for Threat Detection Threat detection is a race against time. The gap between when an attacker does something and when a security team sees it determines who wins. With Auditd, detection usually happens later in a central log platform (often called a SIEM). This creates a delay—sometimes seconds, sometimes minutes. eBPF closes that gap. Because it makes decisions at the source, it can surface suspicious behavior the moment it happens. This leads to a much faster response. It also works better for network security monitoring, where seeing a suspicious connection immediately is much more valuable than reading about it in a report the next morning. Real-World Impact: The Detection Gap To see why this timing matters, we can look at the security challenges faced by Citibank in recent years. In recent data breach reports , it was revealed that unauthorized actors exploited web vulnerabilities to gain access to customer information. In a traditional setup using Auditd, the bank wouldhave a perfect record of the breach after the fact. Investigators could see exactly which records were touched. But for a global bank, the problem isn't just knowing you were robbed—it's stopping the theft while it's happening. As security experts often point out, banks are reluctant to admit breaches because, by the time the logs are analyzed, the "booty" is already gone. By using eBPF-based tools, teams can move from "hindsight" to "real-time." Instead of waiting for a log to be written to a disk and then sent to a server, eBPF can flag the suspicious behavior the microsecond it occurs in the kernel. It turns a "lawsuit waiting to happen" into a "threat blocked at the door." The Detection Gap: In modern breaches, the "Time to Detect" (TTD) is the only metric that matters. Auditd helps you understand the past , while eBPF helps you control the present . Where Auditd Still Makes Sense Despite the new technology, Auditd is not dead. It still makes sense in environments where "completeness" is the most important thing. If your organization is required by law to keep a record of every single action for legal reasons, Auditd is a proven, reliable tool for that job. It also works well on smaller, stable systems where there isn't a massive flood of data. Sometimes, you don't need the fastest technology; you just need a reliable record to explain what happened after the fact. Where eBPF Is Gaining Ground eBPF is becoming the standard for modern environments like the "Cloud" and "Containers." These systems are very fast and generate a lot of unpredictable activity. These setups need visibility that doesn't slow the system down. The industry is moving in this direction quickly. Even Microsoft has integrated eBPF support into its Linux security tools. The trend is clear: the world is moving away from raw, bulky logs and toward "smart" filtering. Why Many Teams Use Both In the real world, it isn’t a competition. Many teams use both tools together because they solve differentproblems. Auditd provides the long-term, historical record for the lawyers and auditors. eBPF provides real-time visibility for security responders. Using them together covers the gaps that either tool would leave open if used alone. What to Watch For: Spotting the Escape If you’re defending these systems, you can’t just wait for a summary report. You need to know what a breakout looks like while it's happening. Depending on your Linux monitoring tools, that data is going to look very different. The Auditd Trail When an attacker tries to escape, they usually need to interact with sensitive parts of the host. In Auditd Linux, you’ll see this as a flood of system calls. You might see a container suddenly trying to use mount() to grab a host directory or execve() to run a shell with root privileges. The problem? On a busy server, Auditd is recording every mount and every process. By the time you find the one "evil" line in a 50GB log file, the attacker has already moved on. It’s a great record for a post-mortem, but it’s a tough way to catch a live runner. The eBPF Signal This is where eBPF monitoring changes the game. Instead of looking at a list of everything that happened, you can set "tripwires." For example, you can use ebpf security tools to alert you only if a container process attempts to access a file outside of its own virtual environment. Because eBPF lives in the kernel, it sees the attempt in the microsecond it happens. It’s the difference between reading a police report the next day and having a silent alarm go off the moment someone touches the safe. The Visibility Gap Traditional tools often see what is inside the container, but they miss how the container is talking to the host. Real-time threat detection requires seeing that interaction as it happens, not after it's logged. A Pragmatic Path Forward If you’ve already got Auditd running, don't feel like you have to rip it out tomorrow morning. It’s a workhorse.It does exactly what it was built for—creating that rock-solid, line-by-line record that auditors and investigators live for. But here’s the harder question you have to ask yourself: Are you actually catching threats as they happen, or are you just doing a high-tech autopsy after you've already been breached? If you're managing cloud-native apps or complex container setups, raw logs usually aren't enough. They're too slow. Adding eBPF-based monitoring into the mix fills that gap. It gives you a way to filter for the high-priority events right at the source, so you aren't drowning in data later on. Most teams I talk to don't actually pick a "winner" here. They use both. Auditd handles the history; eBPF handles the "right now." At the end of the day, it just comes down to what you need more: a perfect paper trail or an immediate answer. Conclusion: It’s Not About Replacing Auditd Auditd still has a role; it provides the complete, reliable record that compliance teams require. eBPF solves a different problem by reducing noise and improving visibility in real-time. The real shift is in the approach. Older systems collect everything and figure it out later, while newer systems decide what matters immediately. Most teams end up somewhere in the middle, balancing historical compliance with modern speed. Stay Ahead of the Curve If you want to keep up with how the Linux kernel and security landscape are evolving, subscribe to our Linux Security Newsletter . We deliver the latest on eBPF, threat hunting, and system hardening directly to your inbox so you never miss a beat. . That approach worked well when systems were small, and attackers moved slowly. However, that logic b. teams, understand, what’s, happening, linux, system, think. . MaK Ulac
Apr 20, 2026
•
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