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
web applicationLinux securitysecurity architectureWhat Is a WAF? A Linux Security Admin’s Practical Guide
If you manage Linux systems in production, you already operate with multiple layers in place. Network firewalls, SELinux or AppArmor, IDS and IPS, and regular patching. From the operating system’s perspective, the environment is controlled. Still, web applications running on top of that stack continue to be the source of incidents, audit findings, and late-night investigations. Not because the OS failed, but because most modern attacks never need to touch it. . This is the gap a web application firewall (WAF) addresses. Linux security tools are designed to protect the system and the processes it runs. They are not designed to interpret the intent of an HTTP request or notice when a parameter is shaped just slightly wrong. Application-layer attacks tend to look like ordinary traffic until you examine structure, behavior, and repetition over time. Once you start reviewing real request logs, the limitation becomes obvious. In this guide, we’ll focus on what a WAF actually does in that space and what it changes for you as an administrator. Where it fits in a Linux security stack, what visibility it adds, and what tradeoffs come with running one in production. The goal is not to convince you to deploy a WAF, but to give you a clear framework for deciding when it makes sense and what deploying it really involves. What Is a WAF (Web Application Firewall)? At its core, a WAF is a control that sits close to your application and pays attention to the parts of a request that Linux itself never interprets. It inspects HTTP and HTTPS traffic at the application layer, looking at URLs, headers, cookies, request bodies, and sometimes responses. Instead of asking whether a packet is allowed onto the system, it asks whether a request makes sense in the context of how the application is supposed to behave. This is what separates a WAF from the firewalls you already run . iptables and nftables work at the network and transport layers. They decide which connections are allowed to exist. A WAF operates atLayer 7, where requests are already accepted and being handled by a web server or reverse proxy. That distinction matters in linux security because most application attacks arrive over ports and protocols you cannot reasonably block. Port 443 has to stay open. The difference between a normal request and a malicious one is often buried inside the payload. The Core Definition A WAF focuses on the semantics of web traffic rather than its transport characteristics. In practical terms, it evaluates things like: Request structure and parameter format Known attack patterns such as SQL injection or cross-site scripting Behavioral signals like request rate, repetition, and sequencing Protocol compliance issues that indicate fuzzing or probing Because it understands HTTP, a WAF can block or flag traffic that would otherwise look legitimate to a network firewall. This is why it is often described as an application-layer firewall rather than a system firewall. It does not protect the Linux host directly. It protects the application’s attack surface. Where a WAF Sits in a Linux Security Architecture In Linux environments, a WAF usually lives in one of a few places. It might run as a module inside a web server like Apache or NGINX, operate as a reverse proxy in front of your application, or sit at an edge layer managed outside the host entirely. Each placement changes what the WAF can see and how tightly it integrates with your existing controls. What matters is how traffic flows. A request typically passes through network filtering, reaches the WAF for inspection, and only then is handed to the application running on Linux. At no point does the WAF replace iptables, fail2ban, or SELinux . It complements them by narrowing the set of requests that ever reach application code. Once you visualize that flow, the role of a WAF in a broader linux security strategy becomes easier to reason about. Why WAFs Exist (and Why Linux Security Alone Isn’t Enough) Linux systems can be hardened to a high standard and still be exposed in ways that have nothing to do with the operating system. A fully patched kernel does not prevent a malformed query from reaching application code. Mandatory access controls do not notice when input is reused across requests in a way that leaks data. From the system’s point of view, the process is behaving exactly as expected. The problem lives higher up. This is where many teams get stuck conceptually. Linux security is very good at protecting resources. Web attacks are often about manipulating logic. An attacker is not trying to break out of a process or escalate privileges. They are trying to convince the application to do something unintended while staying entirely within allowed execution paths. When you review incident timelines, you start to see the pattern. The OS logs stay quiet while application logs slowly fill with strange but technically valid requests. The Gap Between OS Security and Application Attacks Most application-layer attacks succeed because they exploit assumptions, not vulnerabilities the kernel can see. A SQL injection attempt is just text inside a parameter. Cross-site scripting payloads are delivered as user input that passes every system-level check. Request smuggling relies on edge-case behavior in HTTP parsing, not on breaking Linux isolation. If you have spent time digging through web server logs, you have likely seen this already. Repeated requests with slightly altered parameters. Odd header combinations. Long query strings that never quite trigger an error. These are not things SELinux is meant to evaluate. They are signals that only appear once you inspect traffic in the context of the application. Common Web Attacks a WAF Is Designed to Mitigate A WAF exists to recognize and respond to these patterns before they reach application logic. In practice, this usually includes: Injection attacks, such as SQL injection and command injection Cross-site scripting that targets users rather than the server Fileinclusion and path traversal attempts that abuse routing or templating Automated abuse like credential stuffing and scraping Attack classes documented in the OWASP Top 10 None of these are stopped by traditional Linux security controls alone, and that is not a failure of those controls. It is a boundary issue. A WAF sits at that boundary, where requests are still just data and decisions can be made without modifying application code. How Does a WAF Impact You as a Linux Security Admin? Once a WAF is in place, your relationship with web traffic changes. Requests that used to flow straight from the network into the application now stop, get evaluated, and sometimes get rejected. That evaluation produces data, and that data becomes part of your operational reality. Some of it is genuinely useful. Some of it is noise you now have to understand well enough to ignore safely. The impact shows up less in architecture diagrams and more in day-to-day work. You gain another policy surface to manage and another source of truth during incidents. Over time, you also start to notice that problems blamed on “the app” or “the network” often live in the space between them, where the WAF operates. What a WAF Changes in Your Daily Workflow A WAF introduces its own stream of logs, alerts, and decisions that you are expected to interpret. This changes how investigations unfold. You review blocked requests alongside web server and application logs You tune rules to reduce false positives without opening obvious gaps You correlate WAF events with IDS alerts and authentication failures You answer questions from developers and auditors about why traffic was blocked Rule management also feels different from managing Linux policies. Instead of defining what a process may access, you are defining what a request is allowed to look like. That mental shift takes time, especially when legitimate traffic gets caught by generic rules. Performance, Latency, and AvailabilityConsiderations Every request a WAF inspects adds work to the request path. In low-traffic environments, this is rarely noticeable. At scale, it becomes part of capacity planning. Inline inspection can introduce latency, and TLS termination at the WAF changes where encryption starts and ends. Misconfiguration is where most pain comes from. An overly strict rule can break a login flow or block an API endpoint without obvious errors. From the outside, the service looks up. From the user’s perspective, it is not. When that happens, you are often the one tracing the failure across layers to find the rule responsible. Visibility and Control You Gain (or Lose) A well-integrated WAF gives you visibility into request behavior that Linux tools do not provide. You can see which endpoints are being probed, how bots behave over time, and which inputs attract the most abuse. That context can be valuable during risk assessments and post-incident reviews. At the same time, not all WAFs are equally transparent. Managed or black-box deployments may block traffic without exposing the exact reasoning. That complicates troubleshooting and raises questions during audits. In linux security work, control and observability tend to matter as much as protection. A WAF shifts that balance, and understanding how much insight you retain is part of owning the decision. WAF Deployment Models in Linux Environments How a WAF is deployed matters as much as whether you deploy one at all. The same ruleset behaves very differently depending on where inspection happens and how tightly it is coupled to your Linux systems. This is usually where theoretical discussions turn practical, because deployment choices affect performance, visibility, and who gets paged when something breaks. Most Linux environments end up with one of a few common models. None are universally better. Each trades control for convenience in a slightly different way. Host-Based WAFs on Linux A host-based WAF runs directly on the Linux system thatserves the application, often as a module inside the web server. ModSecurity paired with Apache or NGINX is a common example. In this model, inspection happens very close to the application. The advantages are mostly about control and transparency. Full access to rules, logs, and request context Easier correlation with local web server and system logs Fine-grained tuning for specific applications The drawbacks show up over time. Inspection consumes CPU and memory on the host. Rulesets require ongoing maintenance. Updates and exceptions become part of your configuration management process. In busy environments, the operational overhead can be nontrivial. Reverse Proxy and Edge WAFs In proxy-based models, the WAF sits in front of the application, either as a dedicated reverse proxy or as part of an edge service. NGINX configured as a reverse proxy, Apache in front of application servers, or CDN-based WAFs fall into this category. This changes trust boundaries. The application servers see traffic that has already been filtered, but they no longer see everything. Operationally, this can simplify hosts and centralize control. It can also make debugging harder when blocked requests never reach the Linux system at all. The main differences compared to host-based deployment are: Reduced load on application hosts Centralized rule management across multiple services Less direct visibility from the Linux system itself Managed vs. Self-Managed WAFs Managed WAFs offload rule updates and tuning to a third party. Self-managed WAFs keep that responsibility in-house. The technical difference is often smaller than the operational one. With managed services, you trade some control for speed and coverage. False positives still happen, but you may not fully understand why. In regulated Linux environments, this raises questions about auditability and incident reconstruction. With self-managed WAFs, you own the rules, the mistakes, and the learning curve. The right choice usuallydepends less on traffic volume and more on how much visibility and accountability your linux security posture requires. WAFs and Defense-in-Depth for Linux Security A WAF only makes sense when you place it correctly in your mental model of defense in depth. It is not a perimeter replacement and it is not a safety net for weak system hardening. It is a layer that operates in a very specific slice of the stack, one that Linux security controls intentionally do not cover. Once you view it that way, the role of a WAF becomes clearer. It reduces exposure at the application boundary while the operating system continues to enforce isolation, least privilege , and integrity underneath. How WAFs Complement Linux Security Controls Linux security controls focus on what processes can do once they are running. A WAF focuses on which requests are allowed to reach those processes in the first place. Used together, they narrow both the attack surface and the blast radius. Common pairings tend to look like this: A WAF filtering malformed or abusive requests before they hit application code SELinux or AppArmor constraining what that application can access if something slips through IDS or IPS systems watching for broader patterns across hosts SIEM platforms correlating WAF events with system and authentication logs In mature environments, the WAF often becomes an early warning signal. Spikes in blocked requests or unusual patterns show up there first, long before anything triggers a system-level alert. That visibility is often its quietest contribution to linux security. What a WAF Will Never Do for You There are limits that are worth stating plainly. A WAF does not fix vulnerable code. It does not understand business logic beyond generic patterns. It cannot patch dependencies or rewrite unsafe queries. At best, it buys time and reduces exposure. Over-reliance is the common failure mode. Teams deploy a WAF and gradually relax other practices, assuming coverage they do notactually have. When a bypass happens, the impact is worse because assumptions have shifted. A WAF works best when it is treated as a compensating control, not a substitute for secure development and disciplined system administration. When a WAF Makes Sense—and When It Doesn’t Whether a WAF belongs in your environment is usually less noticeable at design time and more obvious after you have lived with real traffic for a while. The question is not whether WAFs work in general, but whether they meaningfully reduce risk in your specific Linux environment without introducing more instability than they prevent. Patterns tend to repeat across teams and industries. Once you have seen a few deployments succeed and a few struggle, the dividing line becomes clearer. Scenarios Where a WAF Is Worth the Operational Cost A WAF tends to justify itself when exposure and constraints leave you with few other options. Public-facing Linux web applications are the most common case. Anything accessible from the internet will eventually attract automated scanning, credential stuffing, and low-effort exploitation attempts. Even well-written applications accumulate edge cases over time. Legacy applications are another strong candidate. When code cannot be easily refactored, a WAF becomes a practical way to reduce risk without touching the application itself. This is especially common in environments where uptime matters more than architectural purity. Compliance-driven environments also push teams toward WAFs. Standards like PCI DSS and certain government frameworks explicitly reference application-layer protections. In those cases, a WAF provides a concrete control that auditors can evaluate, even if it is not the primary security mechanism. Scenarios Where a WAF Adds More Pain Than Value Not every service benefits from application-layer inspection. Internal-only applications with strong network segmentation and limited user bases often see little real-world abuse. In those environments, the noiseintroduced by a WAF can outweigh its protective value. Static sites and low-risk services are another common mismatch. If an application does not process user input in meaningful ways, most WAF rules will never trigger. What remains is overhead, both in performance and in operational attention. The final limiting factor is people. WAFs require tuning, monitoring, and ownership. Teams without the bandwidth to review logs, investigate false positives, and adjust rules tend to end up with either overly permissive configurations or broken workflows. In linux security work, an unused or poorly understood control is often worse than none at all. Our Final Thoughts on the Role of a WAF in Your Linux Security Strategy A WAF protects a part of the stack that Linux security tools do not see. It inspects requests after they are allowed onto the network but before they reach application logic, where many modern attacks actually live. That alone explains why WAFs continue to exist alongside mature operating system controls rather than replacing them. At the same time, a WAF is not a passive addition. It introduces another policy layer, another source of logs, and another place where mistakes can surface as outages. Performance considerations, rule tuning, and ownership all become part of your operational workload. These costs are manageable, but only if they are acknowledged upfront. The real value of a WAF depends on visibility and accountability. When you can see why traffic was blocked, adjust behavior safely, and correlate events with the rest of your Linux environment, the WAF becomes a useful boundary control. When it is opaque or ignored, it becomes noise. Treated correctly, a WAF is neither a safety net nor a silver bullet. It is a focused layer in a broader linux security strategy, doing one job well and leaving the rest to the controls that were designed for it. . Explore the role and effectiveness of Web Application Firewalls in enhancing Linux security for web applications.. Web ApplicationFirewall, Linux Security Tools, Application Layer Protection, Security Strategy, Incident Response. . Brittany Day
Jan 10, 2026 •
102
network securityrisk managementsecurity toolsReview of Network Security Monitoring by Richard Bejtlich
The Tao of Network Security Monitoring is one of the most comprehensive and up-to-date sources available on the subject. It gives an excellent introduction to information security and the importance of network security monitoring, offers hands-on examples of almost 30 open source network security tools, and includes information relevant to security managers through case studies, best practices, and recommendations on how to establish training programs for network security staff. . Book Review Author: Richard Bejtlich Publisher: Addison Wesley Pages: 798 Opinion To be honest, this was one of the best books that I've read on network security. Others books often dive too deeply into technical discussions and fail to provide any relevance to network engineers/administrators working in a corporate environment. Budgets, deadlines, and flexibility are issues that we must all address. The Tao of Network Security Monitoring is presented in such a way that all of these are still relevant. One of the greatest virtues of this book is that is offers real-life technical examples, while backing them up with relevant case studies. Network security engineers, system administrations, and security management will find value in this book. It is a must-read for anyone interested in getting into the field, but would still be useful as a reference for the experienced expert. The book is written in an easy to follow manner and is filled with diagrams, tables, screen shots, and relevant examples. Richard Bejtlich attempts to help network engineers go beyond what is offered by today's intrusion detection systems. He provides a basis for developing an entire network security monitoring architecture, which gives administrators a much clearer view of network activity. I highly recommend this book to anyone involved in network security on a day-to-day basis. Inside the Book The Tao of Network Security Monitoring is written in 6 parts with 18 chapters and several appendixes. Part I gives an introduction tonetwork security monitoring, part II introduces available network security tools with examples of usage as well as how the tool can be acquired. Part III and IV outline the network security monitoring process through best practices and case studies while explaining role of those individuals involved. Part V describes what tools and tactics attackers use to evade network security monitoring systems. Part VI, the appendixes, offer a protocol header reference, an intellectual history of network security monitoring, and an introduction to protocol anomaly detection. Chapter 1 offers a decent introduction to information security, but it focuses specifically on background material that is relevant to network security monitoring. Rather than viewing security in a traditional light, Richard Bejtlich offers an explanation that puts threats and vulnerabilities into the concept of risk management. The characteristics of an intruder are given as well as the phases of a typical network compromise. (Reconnaissance, Exploitation, etc.) One of the more interesting parts of this chapter is the author's description of the phrase 'defensible network.' Defensible networks can be monitored, limit an intruder's maneuverability, keep services to a minimum, and can be managed more easily. Chapter 2 goes more deeply into network security. This chapter is slightly more technical, but still offers a high-level explanation of the principles and concepts necessary when developing a network security plan. Chapter 3 continues to prepare the reader to understand the entire network security environment. This chapter offers an introduction to the security perimeter, demilitarized zone, wireless networks, and intranets. It discusses the use of hubs, span ports, taps, inline devices, monitoring architecture, and monitoring administration considerations. After the first three chapters, readers should have a firm understanding of the role the network security plays in an organization. The next seven chapters offer detailed information aboutmany of the network security monitoring tools available to administrators. The author chose to include only software that is presently available for his FreeBSD 4.9 test platform. However, this should not be a discouraging factor for Linux readers. The sources and binaries for nearly all of the software examined is also available for Linux. Chapter 5 focuses on 'full content' software such as Tcpdump, Tethereal, and Snort as a packet logger. For each tool examined, a basic introduction and usage examples are given as well as extended examples which show how each tool can be used in specific scenarios. Chapter 6 discusses 'additional data analysis' tools such as tcpslice, tcpreplay, ngrep, etherape, etc. Chapter 7 gives examples and usage suggestions for tools that deal with session data and chapter 8 does the same for statistical based tools. Chapters 11 and 12 are probably much more interesting to seasoned information security professionals. Network security best practices are discussed as well as case studies that offer interesting examples of network security incidents. Chapter 13 is an excellent piece of writing that lays out the parts necessary to create a network security analyst training program. This chapters does a good job of outlining the skills necessary to help a security manager determine who should be doing what, how tools are established and used within an organization, how policies are created, and the tasks associated with each area of network security monitoring. It includes weapons and tactics, telecommunications, system administration, scripting and programming, management policy, and examples of training in action. The last two chapters, 17 and 18 will probably be two of the most interesting chapters to the casual reader. Rather than focusing solely on the security engineer, these two chapters consider the perspective of the intruder. Tools used to disrupt the integrity of network security monitoring systems are discussed as well as tactics to promote anonymity, evade detection,and affect the integrity of data collection tools. These chapters show the importance of thinking like the enemy. About the Author Richard Bejtlich is a security engineer in the Computer Forensic and Intrusion Analysis division of ManTech International. He has also worked as a consultant for Foundstone, and managed network security operations for Ball Aerospace & Technologies Corporation. He served in the Air Force Computer Emergency Response Team (AFCERT) as well as support law enforcement investigations. He is well known in the wider security community for writing papers and giving technical lectures at SANS, FIRST, Infragard, ISSA, and SHADOW conferences. He has a Bachelor of Science degree from the United States Air Force Academy, a Master's from Harvard, CISSP, and Certified Information Forensics Investigator certification. . Richard Bejtlich, a cybersecurity expert, shares deep insights on network security monitoring, highlighting continuous threat detection and the importance of logging.. Network Security Monitoring, Open Source Tools, Best Practices, Security Management. . Benjamin D. Thomas
Jan 28, 2005 • 
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