Network Security
system security Linux network
system security Linux network The romanticized image of the digital nomad – a laptop on a sun-drenched balcony – rarely accounts for the actual friction of maintaining a professional development environment on the move. . The friction is amplified with Linux. We are looking for a setup that respects our kernel configurations, handles volatile network handovers, and maintains a strict security posture without the hand-holding of a consumer-grade OS – so, put simply, more than just a laptop and a sunny deck. The hardware is...
May 26, 2026
Server Securityopen-source Linux administration
open-source Linux administration Cron has existed in Unix and Linux environments for decades, handling backups, cleanup scripts, patching jobs, log rotation, monitoring tasks, and other maintenance work that administrators do not want to run manually. Most Linux servers rely on it constantly, which is exactly why attackers continue abusing it for persistence after a system has already been compromised. . Persistence through cron is not complicated. Attackers do not need a rootkit or advanced malware framework to maintain...
May 25, 2026
Vendors/Productssecurity breach linux
security breach linux A major internal repository breach at GitHub has exposed a critical and overlooked blind spot in Linux supply chain security. Kernel exploits, exposed SSH services, weak firewall rules, and vulnerable daemons dominated the Linux threat model for years, and in many environments, they still matter. But recent supply-chain incidents involving GitHub ecosystems, npm packages, and malicious developer tooling point somewhere else entirely: the developer workstation. . The breach matters because...
May 21, 2026
Security Trends access control multi-tenant
access control multi-tenant Linux administrators often face an ugly choice in the cloud: prioritize convenience and cost-efficiency by sharing infrastructure, or sacrifice those benefits for the sake of total isolation. Most modern Linux workloads don't live on their own private servers anymore. They live in shared environments like Kubernetes clusters, where multiple teams and services run side-by-side. It sounds efficient, and it usually is. . But cloud isolation isn't as ironclad as it looks on the diagram. If you...
May 21, 2026
Vendors/Productsincident response cloud security
incident response cloud security Managed Extended Detection and Response (MXDR) has become one of the most sought-after security services in the enterprise market — and with good reason. It promises the holy grail: broad visibility across endpoints, network, cloud, email, and identity, combined with the 24/7 human expertise most organizations simply cannot build in-house. . However, the rapid growth of the market has produced a wide range of providers whose capabilities vary considerably beneath the surface. Choosing the...
May 19, 2026
Refine news
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 news
We found 2 articles for you...
210
security advisoryimportantCiscoWhen Security Tools Become a Risk: Cisco Snort 3 Flaws & Network Security Threats
Snort 3 flaws don’t matter because they are unusual. They matter because they are predictable. . Recent disclosures showed that crafted network traffic can crash the Snort 3 inspection engine, force restarts, or degrade analysis without always raising clear alarms. In some cases, memory data can be exposed. None of this requires authentication. For Linux admins running Snort sensors, this means inspection can fail under exactly the conditions it is meant to handle: hostile input at scale. That failure mode is the real issue. Network inspection tools are still widely treated as passive observers, not as software that can be targeted and destabilized. When inspection breaks quietly, visibility disappears first, not connectivity. Traffic looks clean. Alerts dry up. Monitoring dashboards stay green. This is a broader trend Linux admins rarely plan for. As inspection engines grow more complex, they also become part of the attack surface. If you assume detection is working because the service is running, you are already behind. These recently discovered Snort 3 flaws are a reminder that inspection itself needs monitoring, policy, and explicit risk ownership, or it quietly becomes the weakest link in the network. What Do the Cisco Snort 3 Security Flaws Actually Change in Network Inspection? This is not about one bad bug or an exotic edge case. It’s about how the inspection engine behaves when traffic is intentionally shaped to stress it. How the Snort 3 Engine Fails Under Crafted Traffic Snort 3 inspects packets by parsing them deeply, protocol by protocol, field by field. That parsing happens on untrusted input, and some of the recent flaws sit directly in that path. Crafted packets can trigger crashes or force the engine to restart. In some cases, inspection does not stop cleanly. It degrades, skipping analysis while the process recovers. The important detail is how little access is required. These failures can be triggered remotely and without authentication. An attacker doesnot need a foothold inside the network. They only need to reach the sensor with traffic that exercises the vulnerable code paths. From the outside, this looks like normal network noise. From the inside, inspection may already be compromised. Data Exposure and Inspection Blind Spots Not all of the issues are about availability. Some flaws allow limited memory disclosure, leaking data from the inspection process itself. That exposure is subtle, but it matters because it confirms something defenders often overlook. The inspection engine is handling a sensitive state while processing traffic, and bugs there can spill more than just alerts. More damaging, though, are the blind spots. Inspection gaps are not always logged or escalated. A sensor can miss traffic while still appearing healthy in dashboards that only track uptime or alert counts. Quiet failure is the core risk here. The system does not always tell you it has stopped seeing clearly. Affected Products and Linux Deployments These issues are not confined to a single appliance or niche setup. Open-source Snort 3 deployments are affected, as are Cisco Secure Firewall products that embed the Snort engine. Many of those sensors run on Linux, either as dedicated hosts or as part of a larger security stack. That matters for teams relying on network intrusion detection as a control. The same engine, the same failure modes, and often the same monitoring assumptions apply across environments. When Network Intrusion Detection Tools Become Part of the Attack Surface It helps to stop thinking of an IDS as a passive observer. The engine is not just watching traffic. It is actively parsing it, normalizing it, and making decisions based on structures an attacker fully controls. That makes the detection layer a place where mistakes can be triggered on purpose, not just stumbled into. IDS engines process untrusted input continuously, often at line rate. Parsing bugs get easier to hit as traffic volume increases. Attackers can probedetection logic the same way defenders test rules. A crashed or degraded sensor does not raise alarms. It just goes quiet. This is why the risk is easy to underestimate. When an application server crashes, users complain. When an inspection engine fails, the network can look clean. For admins, that means responsibility shifts. Threat models have to include inspection engines as attackable components, not trusted referees standing outside the game. Linux Admin Reality Check: Why Snort 3 Failures Are Easy to Miss Most Snort failures don’t announce themselves as failures. They show up as normal-looking systems doing less work than you think. Why “Service Running” Is Not a Security Signal On a Linux host, the first check is usually simple. Is the service running? systemd says yes, so everyone moves on. That works for many daemons. It breaks down for inspection engines. Snort can crash and restart on its own. It can enter short crash loops and recover without ever tripping a pager. During those windows, packet inspection may stop or partially resume, and nothing in basic service monitoring tells you that coverage slipped. Where IDS Visibility Usually Stops Most IDS monitoring is built around detections. Alerts fired. Signatures matched. Packets dropped. What often goes untracked are decode errors and parser exceptions, the signals that tell you the engine is struggling to make sense of what it is seeing. Those events may be logged locally, if at all. They rarely escalate. Dashboards stay quiet because they are watching outcomes, not engine health. The result is a blind spot that only shows up after you need the data that never got inspected. Early Indicators Admins Tend to Ignore There are usually hints, but they look like noise. A slight drop in inspected traffic. CPU spikes that line up with bursts of malformed packets. A sensor that feels “off” but not broken enough to justify digging. You start to see the trend once you’ve chased it a few times. Inspectiondegrades before it fails, and that degradation is easy to rationalize away as load or background churn. Policy and Monitoring Changes That Reduce Network Inspection Risk Once you accept that inspection can fail quietly, policy has to follow. Network intrusion detection cannot be treated as a static control that is either on or off. It becomes a system whose health needs to be measured, reviewed, and explained, especially in environments where detection is cited as a compensating control. That starts with watching the engine itself, not just the alerts it produces. Signal What It Indicates Why It Matters Snort restarts Engine instability Inspection may drop without notice Decode failures Parsing stress Early sign of hostile or malformed traffic Rule reload errors Broken detection logic Coverage exists on paper, not in practice These signals are not exotic. Most of them already exist in logs or metrics streams. They are just rarely elevated to the level of security monitoring. A few minimum changes usually make the difference: Treat IDS health events as security-relevant, not operational noise. Alert on restarts, crash loops, and repeated decode errors, even if detections stay low. Correlate inspection errors with traffic spikes instead of looking at them in isolation. None of this requires rewriting your entire monitoring stack . It does require changing what you consider evidence that detection is working. Patch, Compensate, or Re-Architect: Security Decisions After Snort 3 Flaws Once the flaws are understood, the hard part starts. This is where teams tend to stall, because patching feels obvious and everything else feels optional. In reality, each choice changes risk in a different way, and pretending there is only one answer is how blind spots stick around. Option What It Fixes What ItDoesn’t Patch Snort Known flaws in current versions Future parser bugs and unknown failure modes Add redundancy Single-sensor failure Operational complexity and tuning drift External monitoring Visibility gaps Alert fatigue and correlation work Patching is necessary. It closes the specific holes that have been documented. It does not change the fact that inspection engines will keep parsing hostile input tomorrow and next year. That is where compensating controls come in. Redundant sensors limit how much visibility you lose when one engine stumbles. External monitoring helps you notice when inspection quality drops instead of assuming clean traffic. The last option is the one people rarely name. Doing nothing. That is still a decision, and it carries risk just like the others. The difference is that it is usually undocumented and therefore hard to defend later. Why Network Security Threats Now Include the Tools You Rely On Network security threats are no longer limited to the traffic crossing the wire. They also live inside the tools built to inspect that traffic. As detection engines grow more complex, they accumulate their own failure modes, many of them subtle. Inspection logic ages. Parsers expand. Edge cases multiply. Over time, the attack surface grows even if the network itself does not. What makes this harder to manage is how these failures present. Inspection engines tend to fail quietly. Alerts stop. Coverage thins. Everything looks calm unless you are watching the right signals. Long-term security strategies have to assume these gaps will happen and plan for how to detect and explain them. FAQ: Cisco Snort 3 and Network Intrusion Detection Risks Can Snort 3 fail without generating alerts? Yes. Snort can crash, restart, or partially degrade while producing few or no alerts. If monitoring is focused on detections rather than engine health, inspection gaps can gounnoticed. How do I detect inspection failure on Linux sensors? You have to look past service status. Track restarts, decode errors, parser exceptions, and sudden drops in inspected traffic, then correlate those signals with traffic patterns and system load. Are passive IDS deployments safer than inline ones? They reduce the risk of blocking traffic, but they do not remove inspection risk. A passive sensor that fails quietly still creates a visibility gap, which can be just as damaging during an investigation. Does patching eliminate inspection risk? No. Patching fixes known flaws, not the underlying reality that inspection engines parse hostile input. New bugs and new failure modes will appear over time, even in well-maintained systems. What metrics indicate IDS health issues? Repeated restarts, rising decode failures, rule reload errors, and unexplained CPU spikes are common indicators. None of them is definitive alone, but together they show when inspection quality is slipping. . Explore recent Cisco Snort 3 flaws affecting network inspection, highlighting the risk of silent failures and data leaks.. Cisco Snort 3, network security tools, Linux intrusion detection, security monitoring, network inspection flaws. . Brittany Day
Jan 19, 2026
•
Security Vulnerabilities
74
network securityintrusion detectionsecurity toolsDeploying Snort IDS For Enhanced Network Security On Linux
The past few weeks have been frustrating and rewarding all at the same time. I had set a goal to configure an intrusion-detection system (IDS) using the de facto standard, Snort on Linux. In our environment, we have very little in the way of security tools and devices, and little or no budget to procure such items. This project was the first step in being able to detect potentially malicious network traffic as inexpensively as possible. security manage This article discuses a security managers experience with deploying a Linux intrusion-detection system. Have you implemented a IDS on your network? If so what was your experience? . The link for this article located at ComputerWorld is no longer available. . Implementing an Intrusion Detection System (IDS) using Snort on Linux significantly improves network security while offering a hands-on experience in threat monitoring. Intrusion Detection, Snort IDS, Linux Network Protection. . Bill Locke
Aug 22, 2008
•
Network Security
78
network securityintrusion detectionopen sourceSnort's Evolution: Insights From Martin Roesch on Development Progress
Last week we met with Martin Roesch, the creator of Snort, the de facto standard for intrusion detection/prevention. Presented here is the entire story of Snort in his words that covers seven years of development that made this tool one of the most important security software titles ever developed. . During his talk you'll get all the details on how Snort was initially conceived as well as how it is expected to develop further now after Check Point acquired Sourcefire. You'll discover many technical details related to the development of Snort since its inception in 1998 up to today as well as some details of upcoming features. Among other things Martin talks about all the major Snort releases, the founding of Sourcefire, the enhancements added to the last versions of Snort, new technology that presents a self-tuning engine, and much more. The link for this article located at Net-security.org is no longer available. . During his talk you'll get all the details on how Snort was initially conceived as well as how it is. martin, roesch, creator, snort, facto, standard, intrusion, detec. . LinuxSecurity.com Team
Oct 25, 2005
•
Vendors/Products
74
web applicationsql injectiondetectionTechniques For SQL Injection And XSS Detection With Snort IDS
In this article, we've presented different types of regular expression signatures that can be used to detect SQL Injection and Cross Site Scripting attacks. Some of the signatures are simple yet paranoid, in that they will raise an alert even if there is a hint of an attack. But there is also the possibility that these paranoid signatures may result in false positives. To take care of this, we've then modified the simple signatures with additional pattern checks so that they are more accurate. We recommend that these signatures be taken as a starting point for tuning your IDS or log analysis methods, in the detection of these Web application layer attacks. After a few modifications, and after taking into account the non-malicious traffic that occurs as part of your normal Web transactions, you should be able to accurately detect these attacks. . . .. 1. Introduction In the last couple of years, attacks against the Web application layer have required increased attention from security professionals. This is because no matter how strong your firewall rulesets are or how diligent your patching mechanism may be, if your Web application developers haven't followed secure coding practices, attackers will walk right into your systems through port 80. The two main attack techniques that have been used widely are SQL Injection [ref 1] and Cross Site Scripting [ref 2] attacks. SQL Injection refers to the technique of inserting SQL meta-characters and commands into Web-based input fields in order to manipulate the execution of the back-end SQL queries. These are attacks directed primarily against another organization's Web server. Cross Site Scripting attacks work by embedding script tags in URLs and enticing unsuspecting users to click on them, ensuring that the malicious Javascript gets executed on the victim's machine. These attacks leverage the trust between the user and the server and the fact that there is no input/output validation on the server to reject Javascript characters. This article discusses techniques todetect SQL Injection and Cross Site Scripting (CSS) attacks against your networks. There has been a lot of discussion on these two categories of Web-based attacks about how to carry them out, their impact, and how to prevent these attacks using better coding and design practices. However, there is not enough discussion on how these attacks can be detected. We take the popular open-source IDS Snort [ref 3], and compose regular-expression based rules for detecting these attacks. Incidentally, the default ruleset in Snort does contain signatures for detecting cross-site scripting, but these can be evaded easily. Most of them can be evaded by using the hex-encoded values of strings such as %3C%73%63%72%69%70%74%3E instead of . We have written multiple rules for detecting the same attack depending upon the organization's level of paranoia. If you wish to detect each and every possible SQL Injection attack, then you simply need to watch out for any occurrence of SQL meta-characters such as the single-quote, semi-colon or double-dash. Similarly, a paranoid way of checking for CSS attacks would be to simply watch out for the angled brackets that signify an HTML tag. But these signatures may result in a high number of false positives. To avoid this, the signatures can be modified to be made accurate, yet still not yield too many false positives. Each of these signatures can be used with or without other verbs in a Snort signature using the pcre [ref 4] keyword. These signatures can also be used with a utility like grep to go through the Web-server's logs. But the caveat is that the user input is available in the Web server's logs only if the application uses GET requests. Data about POST requests is not available in the Web server's logs. The link for this article located at is no longer available. . Monitor SQL Injection (SQLi) and XSS attacks effectively by tailoring regex patterns for IDS like Snort, ensuring robust security measures in place. SQL Injection Detection, XSS Detection, Snort Techniques, WebApplication Security, Attack Detection Methods. . Anthony Pell
Mar 18, 2004
•
Network Security
79
network protectionsecurity toolfirewallEnhance IPTables Efficiency by Implementing Snort Rules with fwsnort
Michael Rash submits fwsnort translates snort rules into an equivalent iptables ruleset. By making use of the iptables string match module, fwsnort can detect application layer signatures which exist in many snort rules. fwsnort adds a --hex-string option to . . . . Michael Rash submits fwsnort translates snort rules into an equivalent iptables ruleset. By making use of the iptables string match module, fwsnort can detect application layer signatures which exist in many snort rules. fwsnort adds a --hex-string option to iptables, which allows snort rules that contain hex characters to be input directly into iptables rulesets without modification. In addition, fwsnort makes use of the IPTables::Parse Perl module in order to (optionally) restrict the snort rule translation to only those rules that specify traffic that could potentially be allowed through an existing iptables policy. The link for this article located at CipherDyne is no longer available. . Boost your network defense with enhanced firewall capabilities by converting Snort rules into iptables rules through the utility fwsnort.. Firewall Translation Tool, Snort Rule Management, IPTables Security Tool. . LinuxSecurity.com Team
Oct 21, 2003
•
Security Projects
72
intrusion detectionnetwork monitoringfirewallImplementing Home Security with Snort IDS on a Linux Firewall System
When our home LAN graduated to a 24x7 Internet connection, my Linux box became the firewall and the router. I liked the ability to customize the firewall, and by using Snort I could keep an eye on the barbarians at the . . . . When our home LAN graduated to a 24x7 Internet connection, my Linux box became the firewall and the router. I liked the ability to customize the firewall, and by using Snort I could keep an eye on the barbarians at the gates. However, I could not experiment much without disrupting the entire household's Internet access. Adding a DSL/cable broadband router (see Resources) with a built-in firewall took my computer off the critical path and allowed me to experiment with various configurations and operating systems without domestic discord. But, I missed seeing what was going on. I do not want the first sign of someone attacking me to occur when they appear inside the firewall. Intrusion detection systems (IDSs) are standard practice in the corporate world, but they easily can cost more than an entire home network, including computers. With some free software (Snort), a cheap Ethernet hub and a custom cable, you can have an IDS that is almost as good as a commercial system. The major lack is the pretty reports and graphs necessary to justify a big salary. The link for this article located at LinuxJournal is no longer available. . Upgrading to a constant online connection turned my Linux machine into the main security barrier, boosting home network protection through the use of Suricata.. Linux Firewall, Snort IDS, Home Network Security, Intrusion Detection. . Anthony Pell
Jul 24, 2003
•
Firewalls
83
security advisorysendmailexploit riskSendmail And Snort Exploit Risks Reported: IT Threats Identified
Vulnerabilities have been uncovered in Sendmail and the Snort open source intrusion detection system IT departments suffered two serious vulnerabilities in enterprise-grade open source software systems last week. Top of the list was a newly reported vulnerability in Sendmail, which is a widely used mail transport agent (MTA). The second vulnerability was found in Snort, a popular open-source intrusion detection system (IDS). . . .. Vulnerabilities have been uncovered in Sendmail and the Snort open source intrusion detection system IT departments suffered two serious vulnerabilities in enterprise-grade open source software systems last week. Top of the list was a newly reported vulnerability in Sendmail, which is a widely used mail transport agent (MTA). The second vulnerability was found in Snort, a popular open-source intrusion detection system (IDS). Last week showed how quickly news of vulnerabilities can be exploited to produce software that wreaks havoc on the Net. Within 24 hours of the problems being made public, an easy-to-use exploit program for the Sendmail vulnerability was posted on the Bugtraq mailing list. According to Bugtraq, default installations of Sendmail and Red Hat Linux are not vulnerable to this particular exploit, but firms that have compiled Sendmail for use with Red Hat 7.1, 72 or 7.3 are vulnerable. The link for this article located at vnunet is no longer available. . Vulnerabilities have been uncovered in Sendmail and the Snort open source intrusion detection system. vulnerabilities, uncovered, sendmail, snort, source, intrusion, detection, system. . LinuxSecurity.com Team
Mar 11, 2003
•
Hacks/Cracks
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!
Explore top 10 tips to secure your open-source projects now. Read More