Stay Ahead With Linux Security Features
network security threat detection If you’re relying on standard network logs to protect your Linux infrastructure, you’re flying blind. Most organizations believe they have network security monitoring because they’re capturing traffic, but they’re actually just collecting noise. Real security—the kind that stops an attacker—happens in the gaps between the network, the process, and the host. When an attacker breaches a Linux server, they rarely reach for a custom zero-day. They use what’s already there: curl, bash, python, or...
Jun 30, 2026
unauthorized access security practices SSH persistence usually does not look malicious at first. The login succeeds normally, the session opens cleanly, and the account already exists on the server, which is exactly why attackers continue using SSH keys after gaining a foothold on Linux systems. . Once a public key is added to authorized_keys , the server treats future access as trusted authentication. Attackers no longer need password resets or repeated exploit chains every time they reconnect because the server now accepts the...
Jun 26, 2026
network security threat detection Most security teams are locked into a perimeter-first mindset. They obsess over north-south traffic—the data hitting the edge—while ignoring the reality of the modern data center. Once an attacker gets a foothold, they don't stay at the edge. They pivot. They move laterally. That's the east-west traffic problem: the internal chatter between servers, microservices, and databases that we treat as "trusted" simply because it’s inside the fence. . Using Suricata for east-west monitoring isn't...
Jun 24, 2026
security advisory infrastructure risks More than 4,300 internet-facing devices have been pulled into a newly documented router malware campaign called AryStinger. The infected systems are mostly not enterprise servers. They are older routers, NAS appliances, and embedded Linux devices that stayed online long after anyone was likely checking them. . QiAnXin XLab researchers found that the campaign is leaning on known vulnerabilities, including flaws that have been public for years. That is the important part. AryStinger does not...
Jun 22, 2026
security advisory risk management If more than 12 million enterprise systems can be exposed by flaws in a security control designed to harden Linux, it's probably worth asking whether Linux gives people a false sense of security. That's a question that has come up repeatedly throughout 2026. . This year alone, researchers have disclosed privilege-escalation vulnerabilities, root-level kernel flaws, and multiple supply-chain compromises affecting Linux environments. That doesn't mean Linux suddenly became insecure. It means...
Jun 15, 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
Is application sandboxing truly safe?
Loading...
Explore Latest Linux Security features
We found -2 articles for you...
102
security advisoryintrusion preventionimportantIntrusion Detection Systems vs Prevention Systems Snort Overview
Intrusion detection and prevention systems are often treated as interchangeable. IPS is often described as IDS with blocking turned on. That sounds simple, but the moment traffic runs inline, mistakes start breaking real connections. IDS watches traffic and reports what looks suspicious, while IPS sits in the path and can block connections as they happen. Let’s walk through that shift using simple Snort examples. The goal is to show what breaks once blocking is enabled and why that changes how you operate the system. . Who Is Responsible for the Impact of IDS vs IPS Decisions? IDS and IPS often run the same detection engine . The same rule fires, the same signature matches, and the system reaches the same conclusion about the traffic. The rule logic stays the same. What changes is what happens when it fires. An IDS, or intrusion detection system , can reuse that detection logic safely because it only observes traffic. When the same rules are used inline, responsibility shifts immediately. You can reuse the same rules in both modes. But once you turn on blocking, someone owns the outages. A simple framing helps clarify the difference. IDS tells you something is wrong. IPS decides whether users feel it. IDS Observes traffic out of band Generates alerts for review Preserves availability when rules are wrong Supports human decisions before action is taken IPS Modifies traffic inline Drops or resets connections automatically Enforces decisions without review Owns the impact when something breaks The operational takeaway is that insight and enforcement are different jobs. IDS can generate alerts that turn out to be harmless. IPS can block legitimate traffic. Many teams make this explicit with a responsibility contract during design reviews. The artifact is simple, but it forces a necessary question before blocking is enabled: Who owns the outcome when detection becomes enforcement? What Happens When an IPS Blocks Traffic Inline? Whenan intrusion prevention system blocks traffic inline, it sits directly in the network path and makes a decision on every packet as it passes through. Traffic is inspected in real time and either allowed, dropped, or reset before it reaches the destination. There is no copy of the traffic and no later review. Whatever decision is made is immediately visible to users. Inline placement is the part that changes everything. A passive IDS watches a mirrored stream and cannot affect delivery. An inline IPS is different. All traffic must pass through it to get anywhere, which means if the rule is wrong, traffic breaks immediately. This is the point where the difference shows up. Inline packet flow looks like this: Client → eth0 → Snort (inspect + decide) → eth1 → Server There is no buffer in that path. No rewind. No second chance to reinterpret the decision. If the IPS misclassifies traffic, the application feels it immediately. Under the hood, every packet follows the same simple loop: Inspect the traffic Decide on a rule match Allow, drop, or reset the connection Both modes inspect traffic and match rules. The difference is whether the packet keeps moving. In detection mode, the outcome is an alert. In prevention mode, the outcome is broken or preserved connectivity. Here is a basic Snort inline configuration: snort -Q \ --daq afpacket \ --daq-mode inline \ -i eth0:eth1 \ -c /etc/snort/snort.conf The -Q flag is the turning point. It puts Snort inline instead of passive . Drop and reject rules only work here because Snort is no longer just watching traffic. It’s deciding whether packets move forward or not. At that point, detection stops being an alerting tool and starts actively controlling traffic. Once traffic is inline, a bad rule affects everyone using that connection. There is no “observe first” safety net. A bad rule doesn’t just generate an alert. It interrupts traffic. For wiring details and DAQ behavior, see the Snort inlinedeployment guide, but the risk is already visible here. Enforcement happens in the packet path, and mistakes affect traffic. Does an IPS Still Work If Systems Aren’t Fully Patched? Most IPS deployments quietly assume you already know what is vulnerable. That assumption rarely holds up for long. Patch data drifts, inventories lag, and services change faster than signatures do. IPS rules assume something about the system they’re protecting. A specific endpoint exists. A bug behaves a certain way. A fix has not been applied yet. When those assumptions are accurate, blocking can be precise. When they are not, the IPS is still forced to act, and enforcement turns into educated guessing. This is where people misunderstand intrusion prevention systems. IPS does not compensate for weak patching. It reflects it. When patch data is accurate, you can scope rules tightly. When it isn’t, you end up blocking more traffic than you intended. Consider a basic drop rule tied to a known vulnerable path: drop tcp $EXTERNAL_NET any -> $HOME_NET 443 ( msg:"IPS DROP - CVE-2023-XXXX exploit attempt"; flow:to_server,established; content:"/vulnerable_path"; http_uri; classtype:attempted-admin; sid:3000001; rev:1; ) From the IPS point of view, this rule is simple. If that request shows up, drop it. The problem is that the rule has no idea whether the target is actually vulnerable. Testing it is trivial: curl -k https://TARGET/vulnerable_path> If the service is fully patched, the request should not succeed anyway. Dropping it does not change real behavior, and nobody notices. This is the best-case scenario for intrusion detection prevention. If the service is unpatched, the IPS genuinely prevents exploitation. The request never reaches the application, and the risk is reduced, at least temporarily. If patch data is stale or wrong, the IPS blocks traffic that is no longer dangerous. Users experience breakage, not protection. From the outside, it looks arbitrary. From theinside, the IPS is doing exactly what it was told. This is where IDS and IPS behave very differently. Detection can live with uncertainty and still be useful. IDS can log something questionable and let you investigate later. IPS has to decide right now, even if it’s not fully sure. The less confidence you have in patch state, the more likely you are to block traffic that doesn’t need to be blocked. Why Do IPS Blocking Rules Fail So Quickly on Encrypted Traffic? They fail because once traffic is encrypted, the IPS can’t see what the request actually is anymore, but it still has to make a decision. TLS hides the URL, the path, the parameters, and any exploit string that would normally trigger a clean match. What’s left is the connection itself. At that point, an intrusion prevention system only sees where the traffic is coming from, where it’s going, and which port it’s using. IDS can live with that and log it. IPS can’t. It’s inline, so every session still has to be allowed, dropped, or reset. When blocking is required, and there’s nothing useful left to inspect, rules get written against the few fields that still exist. That usually means ports and direction, not behavior. You see rules like this show up: drop tcp $EXTERNAL_NET any -> $HOME_NET 443 ( msg:"IPS DROP - blunt port-based enforcement"; sid:3000009; rev:1; ) This rule doesn’t look inside the connection. It can’t. It just drops traffic headed to 443 based on where it’s coming from. Once traffic is encrypted, there isn’t much else to match on. In a lab, this often looks fine. Traffic is controlled. Applications are known. Nothing unexpected crosses the rule. It appears to work. Production environments are different. Almost all traffic is encrypted. Browsers, APIs, agents, background services. A rule this broad starts dropping legitimate sessions. When the IPS can’t see the request but still has to enforce a decision, real traffic gets blocked. Do TCP Resets and Session DropsActually Stop Attacks? They solve different problems. A drop blocks traffic. A reset interrupts a connection. Neither one guarantees prevention. What a drop does Packets are silently discarded The connection hangs until it times out Some clients retry automatically What a reset does A TCP RST is sent back The connection closes immediately Failures show up faster to users A basic Snort reset rule looks like this: reject tcp $EXTERNAL_NET any -> $HOME_NET 80 ( msg:"IPS TCP RESET demo"; flow:to_server,established; content:"test"; sid:3000002; rev:1; ) Resets feel cleaner, but they come with tradeoffs. Under load, attackers can send data before the RST arrives, so some traffic still reaches the application. The practical takeaway is simple. Resets interrupt sessions. Drops block packets. Both can reduce impact, but neither guarantees an attack is fully stopped once traffic volume climbs. Can You Tune an IPS Without Creating Permanent Blind Spots? Every IPS tuning change may create a potential blind spot if not done carefully, but proper methods exist to minimize or avoid that. Tuning usually starts when the IPS flags traffic that turns out to be legitimate. The alerts are technically correct, but they don’t reflect real risk. To stop the interruptions, a rule is added to let that traffic pass without inspection. That is what a bypass rule does in practice: pass tcp $HOME_NET any -> $HOME_NET 8443 ( msg:"BYPASS - internal API traffic"; sid:5000001; rev:1; ) Once this rule is in place, traffic on that port is no longer inspected. It does not generate alerts. It does not get checked by later rules. The IPS simply steps aside and lets it through. There are a few details that matter here. Pass rules are usually evaluated before drop rules. If the pass is broad, inspection is removed entirely for that traffic. If the rule order is wrong, nothing else has a chance to run. Over time, these exclusions tend tostick around. The service changes, the environment changes, but the bypass stays. Attackers don’t need to break the IPS if the IPS has already been told to ignore a path. That’s the trade you make when you start bypassing traffic. Every time you add a bypass rule, you remove inspection from that traffic. For a deeper look at how this plays out as environments grow, see IDS false positives and performance. Why Do IPS Configuration Changes Cause Outages So Easily? Because when an IPS is inline, config changes affect live traffic immediately. You’re not changing a policy in the background. You’re changing how packets are handled right now. If a rule is wrong, traffic starts dropping as soon as the process reloads. If the config is invalid, Snort may not come back up at all. Either way, users feel it before you finish checking logs. The usual workflow looks like this: # Validate config before reload snort -T -c /etc/snort/snort.conf # Restart inline Snort systemctl restart snort If you skip the test step, you’re guessing. A bad config can stop the service or load in a broken state, and because the IPS is inline, that guess turns into a traffic problem immediately. Even when the config is valid, timing matters. Restarting during active traffic means every mistake shows up at full volume. There’s no quiet failure mode. That’s why rollback planning has to come first. There’s very little room for mistakes once it’s inline. If you don’t already know how to bypass or revert the change, you find out the hard way, usually from users, not monitoring. How Is IPS Most Commonly Misused in Production Environments? Most IPS outages are not caused by bugs. They come from how blocking is turned on. The most common mistakes look like this: Using IPS to make up for systems that are not fully patched Treating alerts as final decisions instead of signals Enabling blocking without assigning clear ownership Having no rollback or kill switch when something breaks In production, an inline intrusion prevention system must have a way to step out of the path. Hardware bypass NICs or a software kill switch are recommended for fail-safe operation in production IPS deployments. If the IPS process fails, traffic should continue to flow. If there’s no bypass, one bad rule can take down traffic. When Does an Intrusion Prevention System Work? An intrusion prevention system is not always wrong. It just works in a narrow set of conditions. IPS works best when you know exactly what services are running, and they don’t change much. Services are fully inventoried. Patch status is accurate. Traffic paths are stable and predictable. When those pieces line up, blocking can be targeted instead of disruptive. A few things usually need to be true at the same time: You know which services are exposed and why Patch data reflects reality, not last quarter Traffic flows are consistent Someone owns rollback decisions The team accepts some false positives Turning on blocking doesn’t mean you’re more advanced. It means you’re prepared to deal with traffic being interrupted. If any of these pieces are missing, risk increases immediately. The IPS is still inline, and uncertainty shows up as broken traffic. Is Moving from IDS to IPS a Security Maturity Upgrade? No. IDS does not “graduate” into IPS. They solve different problems and fail in different ways. IDS and IPS carry complementary responsibilities. IDS focuses on visibility and understanding what is happening on the network. IPS focuses on enforcement and stopping traffic in real time. One helps you learn. The other forces you to act. Neither replaces the other. The failure modes are different, too. When IDS is wrong, you get noise. When IPS is wrong, users get blocked. That difference does not disappear as teams get more experienced. IDS remains foundational even in environments that use blocking. You still need visibility, context, and a way to respond withouttouching live traffic. That’s why IDS response and countermeasures matter alongside prevention, not after it. Prevention does not replace visibility. It depends on it. Why IPS Blocking Fails Without Certainty IPS has to decide immediately. It doesn’t get time to double-check whether the rule is perfectly accurate. When that decision is wrong, users notice right away. Detection can log something questionable and let you investigate later. IPS has to act even if it isn’t fully sure. That uncertainty gets enforced inline, and small mistakes turn into dropped traffic instead of alerts. IPS only works if someone validates the assumptions behind each blocking rule and is willing to own the impact. If you’re unsure about your rules, blocking doesn’t fix that. It just pushes the consequences onto live traffic. . Who Is Responsible for the Impact of IDS vs IPS Decisions? IDS and IPS often run the same detection . often, intrusion, detection, prevention, systems, treated, interchangeable, descri. . MaK Ulac
Mar 12, 2026
•
102
network securityopen source softwarecyber defenseImplementing Geolocation For Nftables: A New Era In Firewall Security
What if you could block connections to your network in real-time from countries around the world such as Russia, China and Brazil where the majority of cyberattacks originate? What if you could redirect connections to a single network based on their origin? As you can imagine, being able to control these things would reduce the number of attack vectors on your network, improving its security. You may be surprised that this is not only possible, but straightforward and easy, by implementing geographic filtering on your nftables firewall with Geolocation for nftables . . Geolocation for nftables is a simple and flexible Bash script released in December of 2020 designed to perform automated real-time filtering using nftables firewalls based on the IP addresses for a particular region. In a recent interview with LinuxSecurity researchers, the project’s lead developer Mike Baxter explained the mission of Geolocation for nftables, “I hope this project is beneficial to those who may not have the IT budget or resources to implement a commercial solution. The code runs well on servers, workstations and low-power systems like Raspberry Pi. The script has the built-in ability to flush and refill geo filtering sets after a database update without restarting the firewall, allowing servers to run uninterrupted without dropping established connections.” This article will examine the concept of geo filtering and how it could add a valuable layer of security to your firewall, and will then explore how the Geolocation for nftables project is leveraging Open Source to provide intuitive, customizable geo filtering on Linux. What Is Geo Filtering? Geo filtering is a firewall technology that filters and blocks both incoming and outgoing network connections based on geographic location using IP addresses. Geo filtering technology enables a computer firewall to compare the source or destination IP address of a network packet to a list of location specific IP address ranges, which can be found in freelyavailable geolocation databases such as db-ip.com . Firewall rules can then determine what to do with each packet - accept, reject, redirect to a server with localized content, drop, or simply count the packet - based on the location of its origin or destination. How Can Geo Filtering Enhance Firewall Security? Geographic filtering enables administrators to mitigate threats to their network by blocking IP addresses associated with countries or locations where the majority of cyberattacks originate, or that they have no reason to allow traffic from. If you have no reason to accept incoming online communications from certain countries, then implementing whole-country Geo filtering on your firewall may make sense. However, keep in mind that if you’re using software or online services from other countries, you may have to accept communications from these countries. Cutting off entire countries is quick and effective, but in many cases it makes sense to use more sophisticated IP filtering settings to either block only certain IP addresses, ranges of IPs or lists of IPs known to be malicious, or to create rules in your firewall that make exceptions and allow trusted IP addresses to access your systems. Geo filtering is a valuable security feature, but does have some limitations. For instance, the technology could potentially block legitimate online traffic, and isn’t able to prevent targeted attacks, as criminals can easily hide their location by using servers or compromised computers in different locations to launch attacks. Implementing Geo filtering on your nftables firewall can add a valuable layer of security to your network by reducing its attack surface and helping to protect against malware and other dangerous, persistent threats - but it should not be viewed as a cybersecurity cure-all. Baxter emphasizes the importance of implementing this technology as part of a comprehensive, defense-in-depth approach to cybersecurity: “Geo filtering is one layer of security that can help to reducethe number of attack vectors on a computer or network, but it’s not a silver bullet. There are ways around every type of computer security, so it’s important to do security in layers.” Geolocation for nftables Leverages Open-Source Development to Make Filtering by Country Seamless, Easy & Effective Geolocation for nftables makes implementing real-time geographic filtering on your nftables firewall simple, convenient and effective, while offering granular control over network traffic. The Bash script converts the 400,000 lines of IP address ranges and country codes in its database to a format that Linux nftables firewalls can access with firewall rules. The script automatically generates country-specific nftables address range sets, and automatically determines the installed version of nftables and recommends the correct "include" statements for an administrator’s ruleset. User settings are conveniently stored in a standard configuration file, as opposed to using command line arguments. The geographic database is automatically downloaded from db-ip.com in real-time, keeping nftables Geo Filtering sets up-to-date. This is critical, as the IP address ranges assigned to each country change over time and geographic databases must be updated regularly in order to remain accurate and effective. Geolocation for nftables also has the unique ability to automatically run an nftables script to flush and refill IP sets with new data after a database update, allowing servers to run uninterrupted - without dropping established connections. Geolocation for nftables is an open-source project, and offers users an array of unique benefits that can be attributed to its use of Open Source - namely, enhanced security and a high level of customization. The script is easy to set up, configure and tailor to meet your specific needs with open-source code that is heavily vetted by the community. The “many eyes” reviewing this code on an ongoing basis results in rapid identification and elimination ofvulnerabilities and security issues. The global community input that the project receives fosters innovation by offering ideas, feedback and programming expertise. Geolocation for nftables source code is heavily commented on, making it easy to understand and customize. This selection of benefits comes at no cost to the end user as, in the words of Baxter, open-source development is “just people helping people”. Geolocation for nftables seamlessly integrates with other firewall applications by allowing multiple matches per firewall rule, so matches can be combined with matches from other sources to determine how a network packet is handled. For instance, an administrator can accept a packet with an IP address that’s on his or her IP “allow” list, but not on his or her Fail2ban “block” list with a single firewall rule. Geo Filtering for nftables has a small memory footprint and offers flexible configuration, making the script ideal for any system - even those with limited RAM. Key feature and benefits of Geolocation for nftables include: A script written for the widely used Bash shell that automatically generates country-specific nftables address range sets Easy to implement, configure and customize with heavily reviewed open-source code Small memory footprint and flexible configuration makes the script run well on systems with limited RAM User settings are conveniently stored in a standard configuration file rather than using command line arguments Packets can be filtered by geography with a single nftables rule rather than two rules to mark and match packets Automatically determines your installed version of nftables and recommends the correct "include" statements for your ruleset Creates "include-all" files to allow you to include all geographic IP sets with a single reference on older versions of nftables that don't support include wildcards Offers a User Guide which explains how to define all element definitions for Geolocation sets in one file, eliminating thechance of having out-of-sync definitions in multiple files when flushing and refilling sets with new data Simplified directory structure to shorten "include" path names Creates ~500 IPv4 and IPv6 set files from the geographic database in about 10 seconds on a low power quad-core 2200ge server with SSD storage Tested on Ubuntu Server , Fedora Server , and Raspberry Pi OS Key Takeaways Geographic filtering is a valuable layer of defense that you should consider adding to your nftables firewall to reduce the attack surface on your network and help secure your system against malware and other serious, prevalent threats. Geolocation for nftables provides Linux users with a simple, flexible and automated way to implement real-time geographic filtering on their nftables firewall. Visit the project’s Github page to learn more about Geolocation for nftables and how you can install the script on your system. Please reach out to us if you have an open-source security project you would like us to cover in a future LinuxSecurity feature article! Connect with us on social media: Twitter | Facebook . Enhance your network security using Geolocation with nftables, a versatile Bash script designed for live geo-filtering on Linux firewall systems.. GeoFilter, NftablesSecurity, BashScript, FirewallEnhancement, LinuxSecurity. . Brittany Day
Feb 09, 2021
•
102
encryptionpacket snifferdata interceptionUnderstanding Packet Sniffers: Techniques and Detection Methods
A packet sniffer is a program which monitors network traffic which passes through your computer. A packet sniffer which runs on your PC connected to the internet using a modem, can tell you your current IP address as well as the IP addresses of the web servers whose sites you are visiting. . You can watch all the un-encrypted data that travels from your computer, onto the internet. This includes passwords and other sensitive data that is not secured by encryption. Put a packet sniffer on a router on the internet, and you can watch all the network traffic that passes through that router. This includes absolutely anyone whose data happens to pass through that router. Sniffers are basically data interception programs. They work because the Ethernet was built around a principle of sharing. Most networks use what is known as broadcast technology, meaning that every message transmitted by one computer on a network can be read by any other computer on that network. In practice, all the other computers, except the one for which the message is meant, will ignore that message. However, computers can be made to accept messages, even if they are not meant for them, by means of a sniffer. A sniffer is usually passive, it only collects data. Hence, it becomes extremely difficult to detect sniffer. When installed on a computer, a sniffer will generate some small amount of traffic, though, and is therefore detectable. Detection methods: 1. Ping Method: The trick used here is to send a ping request with the IP address of the suspect machine but not its MAC address. Ideally, no machine should see this packet, as each Ethernet adaptor will reject it since it does not match its own MAC address. If the suspect machine is running a sniffer, it will respond since it does not reject packets with a different destination MAC address. This is an old method and no longer reliable. 2. Address Resolution Protocol (ARP) Method: A machine caches ARPs, so what we do is send anon-broadcast ARP. A machine in promiscuous mode will cache your ARP address. Next, we send a broadcast ping packet with our IP address but a different MAC address. Only a machine that has our correct MAC address from the sniffed ARP frame will be able to respond to our broadcast ping request. 3. on Local Host: Often, after your machine has been compromised, hackers will leave sniffers on it in order to compromise other hosts. On a local machine, run ifconfig. 4. Latency Method: This method is based on the assumption that most sniffers do some parsing. Simply put, in this method, a huge amount of data is sent on the network, and the suspect machine is pinged before and during the data flooding. If the machine is in promiscuous mode, it will parse the data, increasing the load on it. It will therefore take extra time to respond to the ping packet. This difference in response times can be used as an indicator of whether or not a machine is in promiscuous mode. A point worth noting is the packets may be delayed because of the load on the wire, resulting in false positives. Prevention The best way to secure you against sniffing is to use encryption. While this won. Monitor unprotected data packets flowing from your device over the internet. Explore packet sniffer tools and strategies for detection.. Packet Sniffing, Data Interception, Network Monitoring, Traffic Analysis. . Benjamin D. Thomas
Jul 13, 2006
•
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
Is application sandboxing truly safe?
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