Features Category

Loading...

8.Locks HexConnections CodeGlobe Esm H240

security advisoryintrusion preventionimportant

Intrusion 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. . Explore the dynamics between IDS and IPS, Snort's capabilities, and the risks associated with blocking traffic inline.. Snort, Intrusion Prevention, Network Traffic, Security Systems, Enforcement. . MaK Ulac

Mar 12, 2026 •

MaK Ulac

security advisoryaccess controlintrusion prevention

What Is Fail2Ban? Using Log-Based Intrusion Prevention to Secure Linux Servers

Open any internet-facing Linux server and check /var/log/auth.log or run journalctl -u ssh. If it has been up for more than a few minutes, you will see it. Repeated failed logins from IPs you do not recognize, cycling usernames, sometimes hitting root, sometimes trying “admin,” sometimes just random strings. It does not stop. . Most exposed systems start seeing automated brute force attack traffic almost immediately after they get a public IP. Even if you have already disabled password authentication, the attempts continue. They just fail faster. Over time, that background noise becomes normal, and that is where the risk starts to blur into routine. Fail2ban exists in that space. It is a lightweight intrusion prevention tool that watches your logs, detects patterns like repeated authentication failures, and temporarily blocks the source IP using local firewall rules. It does not sit on the wire. It does not inspect packets directly. It reacts to what your services record. That sounds simple, and it is. But what it changes in your Linux security posture depends entirely on how you run your systems. If you are still allowing password authentication over SSH, Fail2ban can reduce real exposure to brute force attack attempts. If you are key-only and behind a VPN, it may mostly reduce noise and log churn. In both cases, it introduces automation into your blocking decisions, and that has operational consequences. By the end of this article, you should understand how Fail2ban works under the hood, what it actually protects against, where it fits in a layered Linux security model, and what it adds to your monitoring and triage process. Not how to install it. Whether it belongs in your baseline build, your hardened tier, or nowhere at all. What Fail2ban Is and How It Works At its core, Fail2ban is a log-monitoring intrusion prevention tool built for Linux security. It does not analyze network packets or sit inline with traffic. It reads application logs, looks for patterns that matchknown failure conditions, and then reacts. The mechanism is straightforward. A service like SSH writes failed login attempts to a log file or to the systemd journal. Fail2ban monitors that source using a defined filter, which is usually a regular expression matching lines such as “Failed password for invalid user” or repeated authentication failures from the same IP. Once a threshold is crossed, it executes an action that inserts a temporary firewall rule using iptables, nftables, or firewalld. This logic is organized into what Fail2ban calls jails. A jail ties together three things: a log source, a filter, and a ban policy. The ban policy defines how many failures are allowed, over what time window, and how long the offending IP is blocked. In practice, that means something like five failed SSH attempts within ten minutes results in a ten-minute ban. Simple, but very configurable. The default and most common use case is SSH brute force attack detection. You expose port 22, bots start guessing credentials, and Fail2ban begins inserting temporary drop rules for IPs that cross the retry threshold. If you run fail2ban-client status sshd, you can see the current banned IPs and how many attempts triggered the action. That visibility matters because it shows you exactly what the system thinks is hostile behavior. There is an important limitation here. Fail2ban only knows what your logs tell it. If log rotation is misconfigured, if journald is not being read correctly, or if an application changes its log format after an update, detection can quietly fail. From the outside, it looks like protection is in place. Internally, nothing is being matched. So, what you are adding is reactive, host-level intrusion prevention that depends entirely on two things being correct: log integrity and firewall integration. If either breaks, Fail2ban does not degrade gracefully. It just stops acting. What Problem Fail2ban Actually Solves (and What It Doesn’t) When people first hear about Fail2ban, they tend toassume it “blocks attackers.” That is technically true, but only within a narrow slice of behavior. It is reacting to repetition. Specifically, repeated failures from the same source within a defined window. In practice, what it reduces is exposure to brute force attack attempts that rely on hammering a single host from a small set of IPs. You start to see it once you compare logs before and after enabling it. The same IP that would have generated hundreds of failed SSH attempts now disappears after five or ten tries because it is temporarily blocked at the firewall level. There are a few concrete things it improves: It limits repeated authentication attempts from a single IP during a brute force attack. It reduces log noise by cutting off sources that would otherwise keep retrying. It slows down automated credential guessing tools that assume unlimited retries. It provides a visible signal in your logs that an IP crossed a defined abuse threshold. That said, its protection is bound by how attackers behave. If a brute force attack is distributed across thousands of rotating IP addresses, each making only a few attempts, Fail2ban may never trigger. If an attacker already has valid credentials, there are no repeated failures to detect. If there is a service vulnerability that succeeds on the first request, there is nothing to count and nothing to ban. It also introduces edge cases. In environments where many legitimate users sit behind the same NAT address, a low retry threshold can block all of them because one person mistyped a password repeatedly. I have seen this happen in shared office networks and in university environments. The ban logic worked exactly as configured. The policy did not reflect reality. So the real question is not whether Fail2ban “improves Linux security.” It is whether in your environment it meaningfully reduces brute force attack risk, or mostly trims noise and makes logs easier to read. The answer depends on your authentication model,exposure level, and how disciplined your users are with credentials. Where Does Fail2ban Fit in a Layered Linux Security Model? Fail2ban operates at the host level. It is not a perimeter device, and it is not watching traffic before it reaches your system. It waits for a service to log a failure, then reacts by adjusting local firewall rules. That distinction matters more than people think. In a layered Linux security model, it sits somewhere between basic hardening and more advanced intrusion detection. If you have already disabled root login, enforced key-only SSH, and set a default deny firewall policy , Fail2ban adds another control that responds to abuse patterns rather than static rules. It complements those settings. It does not replace them. It also overlaps, slightly, with network-based intrusion prevention systems. An IDS or IPS might detect scanning behavior or suspicious payloads at the network layer. Fail2ban, by contrast, cares about application-level failures recorded in logs. If you are in a cloud environment, your security groups or load balancers may already filter obvious garbage. Even then, once traffic reaches the host, Fail2ban can still apply local bans based on real authentication failures. That extra friction sometimes matters. What it does not replace is strong authentication. It does not substitute for MFA, proper key management, or timely patching. If credentials are weak or if a service is vulnerable, intrusion prevention at the log layer will not save you. It is reactive by design. When you place Fail2ban into your stack, you are making a defense-in-depth decision. It becomes one control among several, not your primary shield. If you think of it that way, it fits cleanly. If you expect it to stand in for broader hardening, it will disappoint you. Operational Realities: Logs, Monitoring, and Tuning Running Fail2ban is not a one-time configuration task. It becomes part of your operational surface, whether you intended that or not. Everything starts withlogs. If SSH is logging to /var/log/auth.log, or journald is capturing authentication failures, Fail2ban needs reliable access to that stream. If logrotate truncates files unexpectedly, if permissions shift, or if you move from file-based logs to journal-based logs without updating the backend, detection quietly stops. The service may still be running. It just is not matching anything. On systemd-based distributions, the backend setting matters. If you are using the journal, the jail configuration has to reflect that. Otherwise, you end up watching an empty file while authentication failures scroll by somewhere else. I have seen teams assume bans were happening because the service was active. A quick fail2ban-client status showed zero bans over weeks, on a publicly exposed host. That is a signal. You should be checking a few things regularly. fail2ban-client status for overall health. Jail-specific status, especially for sshd. Ban counts over time, which can tell you whether attack volume is increasing or if a configuration change broke detection. If you centralize logs, confirm that Fail2ban’s own actions are visible there so you can correlate bans with authentication failures. Break points tend to cluster around changes. An application update alters its log format, and the regex filter no longer matches. A migration from iptables to nftables leaves the action configuration outdated. A containerized deployment does not have permission to modify the host firewall, so bans are recorded but never enforced. None of these failures is dramatic. They are quiet. False positives are the other side of the coin. Aggressive retry thresholds and long bantime values can lock out legitimate users or automation scripts that retry on transient failures. If your authentication policy allows a certain number of mistakes, your Fail2ban configuration should reflect that. Otherwise, you create friction that looks like an outage. Operationally, this means Fail2ban is not “set and forget.” It is a small intrusionprevention component that needs periodic validation. If you are not watching it, it can drift into irrelevance or cause problems at the edges. Risk, Policy, and Decision Points Before You Enable Fail2ban Before you enable Fail2ban, it helps to pause and look at your access model as it actually exists, not as it was originally designed. Start with exposure. Is SSH reachable from the public internet, or only through a VPN or bastion host? If password authentication is still enabled externally, then a brute force attack is not theoretical. It is ongoing. In that case, automated blocking may reduce real risk. If you are key-only and tightly scoped by IP, the risk profile is different, and the value shifts toward noise control. Then look at shared access patterns. Do you have users behind corporate NAT, remote offices, or cloud egress gateways where dozens of people appear as one IP. A strict retry limit in that environment can ban an entire group because one person mistyped a password repeatedly. That becomes a policy issue, not just a technical one. Cloud environments add another layer. IP addresses can rotate. Instances scale in and out. If you rely on host-level blocking, ask whether that aligns with how your infrastructure behaves. Also consider incident response. When an IP is banned, who reviews it? Is there a defined unban process? Are bans logged centrally so you can audit them later if needed? From a Linux security perspective, Fail2ban introduces automated enforcement based on log patterns. That sounds reasonable, but automation changes accountability. If a legitimate user is blocked during a critical deployment, someone needs to know how to diagnose and reverse it quickly. If your team cannot confidently run fail2ban-client set sshd unbanip and explain why the ban happened, you are adding friction without preparation. So the decision is less about whether Fail2ban works and more about whether automated, host-level blocking aligns with your operational maturity. If it fits yourauthentication model and your team can support it, it becomes a controlled layer. If not, it turns into another moving part that no one fully owns. Common Misconfigurations and Failure Modes Most issues with Fail2ban are not dramatic failures. They are small configuration decisions that quietly reduce effectiveness or create side effects months later. One of the most common mistakes is editing jail.conf directly. It works at first. Then the next package update overwrites it, and your customizations disappear. The service still runs, but your thresholds, ignore lists, or backend settings revert to defaults. If you are not checking, you may not notice until a brute force attack behaves differently than expected. Bantime is another area where intent and reality drift apart. Setting a very long ban period can feel decisive. In practice, it increases the chance of locking out legitimate users, especially in shared IP environments. I have seen teams configure multi-day bans for SSH, only to discover a remote contractor could not reconnect after a few failed attempts during key rotation. The system did exactly what it was told. Firewall persistence trips people up as well. Depending on how iptables or nftables is managed on your distribution, rules inserted by Fail2ban may not survive a reboot unless the backend is properly integrated. After a restart, the service appears active, but previously banned IPs are no longer blocked. If you assume continuity without verifying, your intrusion prevention layer is thinner than you think. Containerized deployments introduce another wrinkle. Running Fail2ban inside a container without access to the host firewall means bans are recorded internally but never enforced externally. You will see IPs listed as banned, yet traffic continues. That gap is subtle until you test it directly. Log format changes are quieter still. An application update modifies the wording of authentication failures, and the existing regex filter no longer matches. The brute force attacktraffic continues, but no new bans appear. Unless you periodically confirm that failed attempts increment the jail counters, detection can degrade silently. A final misconception is assuming that bans mean attacks have stopped. They have not. They have shifted. Attackers often rotate IP addresses or slow down attempts to stay below thresholds. Fail2ban reduces pressure from repeated failures, but it does not eliminate probing. Most of these failure modes share a theme. The service looks healthy from a systemd perspective, yet its protective value has changed. That is why periodic validation matters more than initial configuration. When Fail2ban Makes Sense and When It’s Just Noise Control There is a difference between reducing measurable risk and making your logs quieter. Fail2ban can do both, but not always at the same time. In environments where SSH is publicly exposed and password authentication is still enabled, the value is straightforward. A brute force attack will generate repeated failures from the same IP, and automated blocking reduces the number of guesses an attacker can make in a given window. That does not make weak credentials safe, but it limits repeated attempts and buys time. It tends to make sense when: SSH is exposed directly to the internet Password authentication is still allowed for some users You do not have upstream rate limiting or aggressive perimeter filtering A small team needs lightweight intrusion prevention without deploying a full IDS On the other hand, there are setups where the benefit is mostly operational. If SSH is key-only, root login is disabled, and access is restricted through a VPN or tightly scoped security groups, then the probability of a successful brute force attack drops sharply. In those cases, Fail2ban primarily reduces log churn and repeated failed attempts from scanners. That is useful, but it is not the same as risk reduction. It becomes more about hygiene when: SSH access is already restricted by networkpolicy Authentication relies entirely on strong keys or MFA A cloud WAF or perimeter control blocks most opportunistic traffic You are trying to keep auth logs readable for real incident triage In hardened environments, the gain is subtle. You see fewer repeated failures from the same IP. Your log review sessions are cleaner. In older or more permissive environments, the impact is more direct because repeated guesses actually matter. So the question is not whether Fail2ban is good or bad intrusion prevention. It is whether, in your specific Linux security context, it meaningfully changes attacker effort or mostly cleans up the background noise. Once you answer that honestly, the decision tends to make itself. Our Final Thoughts: Should You Run Fail2ban or Not? At this point, the mechanics are clear. Fail2ban is a reactive intrusion prevention layer that watches your logs and blocks IPs after repeated failures. It is not a perimeter firewall. It is not a replacement for strong authentication. It responds to patterns that your services record, nothing more. In environments where SSH is exposed and password authentication is still in play, it can materially reduce brute force attack pressure. Fewer retries per IP means fewer total guesses over time. That does not eliminate risk, but it narrows the window and forces attackers to rotate infrastructure more aggressively. In key-only or VPN-restricted setups, the impact shifts. Fail2ban still blocks noisy scanners, and your logs become easier to read, but the actual risk reduction may be modest because credential guessing was unlikely to succeed in the first place. In that case, you are mostly improving signal quality during incident triage. There is also the operational cost. Threshold tuning. Watching ban counts. Unbanning legitimate users when someone forgets a key or rotates credentials incorrectly. It depends entirely on clean logs and correct firewall integration. If either drifts, your Linux security posture looks stronger onpaper than it is in practice. Before you enable it, walk through a few direct questions: Is SSH exposed to the internet Are passwords still enabled for any users Are authentication logs centralized and reviewed Do you have a clear, documented unban process Are your firewall backends consistent and persistent across reboots If you cannot answer those confidently, fix that first. Automation should sit on top of clarity, not compensate for its absence. In the end, running Fail2ban should be a deliberate decision. Either you enable it, tune it, and monitor it as part of your layered intrusion prevention approach, or you decide your access model already makes brute force attack risk negligible and accept the log noise. Both choices can be defensible. What matters is that the decision matches how your systems are actually built, not how you assume they behave. . Explore how Fail2ban protects Linux systems from brute force attacks and improves log analysis while enhancing security.. Linux security, Fail2ban, intrusion prevention, SSH attacks, security tools. . Brittany Day

Feb 25, 2026 •

Brittany Day

intrusion preventionopen sourcecyber defense

Exclusive Interview with CrowdSec CEO on Cybercrime Defense Strategies

Exclusive Interview with CrowdSec CEO Philippe Humeau With the widespread adoption of cloud and container infrastructure, protecting servers, services, containers and virtual machines exposed on the Internet with a reliable, intelligent intrusion prevention system is more important than ever. Cloud-native environments foster rapid growth and innovation, but also introduce an element of added complexity, along with new security challenges. . Recently, LinuxSecurity researchers had the opportunity to speak with CrowdSec CEO Philippe Humeau about modern cyber risk, CrowdSec’s unique and advantageous community-powered approach to intrusion prevention with an extremely accurate IP reputation system, what users can expect from the latest CrowdSec release, what the future holds for CrowdSec, and more! We’re excited to share key insights and highlights from this exclusive interview with our readers to help them better understand the modern cyber threat landscape and how they can bolster their intrusion prevention strategy to prevent attacks. Introducing CrowdSec: A Collaborative Open-Source Intrusion Prevention Solution CrowdSec is a cybersecurity solution designed to protect servers, services, containers and VMs with a server-side agent. It was inspired by Fail2Ban and aims to provide a modernized, collaborative version of the popular intrusion-prevention tool. CrowdSec leverages the power of the community to create an extremely accurate real-time IP reputation system that benefits all of its users. It uses a behavior analysis system to determine whether someone is trying to hack your system based on your logs. If your agent detects such aggression, the offending IP is then dealt with and sent for curation. If this signal passes the curation process, the IP is then redistributed to all users sharing a similar technological profile to “immunize” them against this IP. As for the IP that aggressed your machine, you can choose to remedy the threat in any manner that you feel appropriate. Interview with CrowdSec CEO Philippe Humeau LinuxSecurity: What are the main cyber threats Linux users face today that CrowdSec protects against? Philippe Humeau: CrowdSec is essentially a metasploit of defense. Everything creates logs nowadays - planes, cars, phones, TVs, and obviously servers and services. If an attack leaves traces in the logs - which over 95% of attacks do - then it’s simply a matter of writing the proper scenario to catch it. To date, we have tens of scenarios, ranging from L7 DDoS, to credential bruteforce, credit card stuffing, port or web scans, PHP attacks, and more. Lately we are active on the front of ransomware, using CrowdSec as a canary to avoid lateral moves. Possibilities are limitless! The only limit of CrowdSec’s protection capabilities is when an attack leaves no trace, either due to poor log configuration or because it's “silent”, like a stack overflow. That being said, those exploits are very rare and only demonstrate true stealth if the demon crashes aren’t logged or if the said attack doesn’t crash the process at all. The Power of Crowdsourcing LS: Can you explain the power of crowdsourcing? How are you leveraging it to benefit your users, or the people who participate in your “crowd”? How does open-source development facilitate this approach? PH: Crowdsourcing can be seen as a digital version of the famous neighborhood watch. If everyone is watching over everyone else’s servers and services, everyone is safer from attacks. By detecting and sharing IPs of bad actors, we are removing their most precious asset: anonymity. Since cybercriminals want to remain under the radar, they are either forced to stop when their IPs are shared, or at the very least slow down their operations tremendously. Members of our “crowd” benefit directly by constantly receiving IPs that target similar technological signatures as theirs. For instance, if you run a LAMP with Wordpress, you receive all IPs that are agressing SSH, Apache, MySQL,Wordpress, and the like. Crowdsourcing is the cornerstone of the CrowdSec project. Our point of view is that, through this collaboration, we are more numerous than the aggressors. Hence, instead of the out-powering approach, where a super soldier tries (and fails, except in Hollywood movies) to resist 1000 bad guys, we adopt the outnumbering approach. No one fights a bee hive! Open Source facilitates this approach by enabling us to create a product that is adapted to the largest base, where anyone can contribute and adapt it to meet their specific needs. It’s also free, meaning we do not have any friction in adoption - money typically being the first break. Since we are after a network effect, we need to have as many users as possible and Open Source is a great engine with the flexibility and trust it fosters. The Open Source Advantage LS: Expanding on our discussion of Open Source, what are the main advantages of the open-source development model? Do you feel that Open Source provides a superior vehicle for engineering exceptionally secure, resilient software and technology? PH: Well, there are pros and cons, honestly. It’s surprisingly complex to offer something for free! First, people look for the catch and think you might be a trickster, until they realize the business model is not based on their data or a belated monetization strategy. Second, each line of code written requires three times more checking prior to publication, especially given the responsibility you have toward your users and other contributors. On the bright side, many people get to test open-source code, report bugs or inconsistencies and collaborate to improve upon software. It is no secret that the concept of security through obscurity has failed big time, and it’s true that being audited constantly by the community is also a great strength. Thus, nowadays proprietary products are typically considered less trustworthy. LS: How did you make the decision to open source part of your technology while leavingsome of it proprietary? PH: To be transparent, this is a question of pace. On the IPS part, we are 100% open sourced, with an MIT license, while the “Consensus” engine is not (yet) open. The reason behind this choice is that we are extremely agile and constantly fine tuning the Consensus engine, which is used to avoid false positives and poisoning. It’s taking a lot of extra time to make a piece of code “Open Source compliant”, and making it open as of day one would have only slowed us down. Also, at first, we thought it could be a weakness to reveal how we defeat aggressions toward this set of algorithms. Now time has passed and we have grown more confident that this piece will also be opened to scrutiny and contribution soon. We just need to sprint for half a year before adopting a steadier pace and letting the community review and contribute to the Consensus engine. LS: CrowdSec is a community-powered, open-source version of the popular Fail2Ban intrusion prevention tool designed to run on complex modern architectures including clouds, containers and lambdas. Can you explain the similarities between CrowdSec and Fail2Ban, and the key differences between the two. What are the main advantages that CrowdSec offers over Fail2Ban? Can these advantages be attributed to (or partially attributed to) CrowdSec’s collaborative, open-source approach? PH: Fail2ban created the 1st “anti bruteforce system”. Simple in essence, it nevertheless dealt with a lot of credential bruteforce attempts, over a large spectrum of services, on millions of machines, for sixteen years. Quite a legacy for code initially written as Python training for its author! CrowdSec borrows the philosophy of Fail2Ban in the sense that it’s working out of the box to protect the services running on your machine, based on what it finds in your log. And that’s where the parallel between the two ends, because the software design, scope, architecture, orientation, goals and performance are entirely different. CrowdSec iswritten in Golang, to deliver 60x faster treatments, but also to be able to run in all environments - from VM to Docker, from Linux to Windows. It is designed to support a large surface of attacks with L7 DDoS, credential or credit card stuffing, port scans, web scans, and any attack that leaves trails in your logs. It’s modern in the sense that it’s not monolithic and detection is separated from remediation. Furthermore, remediation can be anything you would like it to be - not just banning in your firewall (like Captcha, MFA, messaging, etc.). CrowdSec is also made to meet the needs of individuals and enterprises alike, running successfully on personal firewalls as well as on hundreds of thousands of machines for large hosting companies. Last but not least, CrowdSec shares the IP it bans with other instances (after a curation on our end), to help further protect all members of the network against known offenders. Monumental Changes in CrowdSec v1.1 & v1.2 LS: As part of the CrowdSec v1.1.x release , CrowdSec services were moved to PackageCloud, a fast, reliable and secure cloud-hosted package distribution. Can you explain how this transition is benefiting your customers? PH: Yes, we love PackageCloud! This is a huge step forward for us. We often joke internally that some Debian packages are old enough to buy alcohol! But it’s not only Debian - the majority of platforms are somewhat slow to move. When you release features every other week for more SoC, more OS, more packaging systems than ever before, you need the proper tooling. This packaging is an effort to make CrowdSec available to the largest number of Linux, BSD and even Windows systems running on ARM or Intel. Now customers constantly receive the freshest packages, regardless of their environment, which is key for any security product. LS: CrowdSec v1.1 and v1.2 feature a brand-new Console. What are the main changes and improvements that have been made to the CrowdSec Console? PH: We are extremely excited about this newConsole! First, because it helps people see what is happening on their machines in a consolidated, centralized view. When you run many CrowdSec agents in your network, the standalone metabase running in Docker isn’t enough to provide this level of observability. Beyond the observability aspect, we have two important goals with this Console: gamification and monetization. Gamification is part of what we want the community to experience. A bit like the SETI at home project, except that instead of hunting aliens, we hunt cybercriminals. You’ll get badges, ranks, and maybe swag or other forms of recognition for helping other users. The second part is monetization - and the console will be its headquarters! We are absolutely fine with making money while being an open-source editor. Some would love to see talented authors only feed on edible moss and little animals, wear monk robes and walk in bare feet because “it’s the way Open Source should be”. Well, I strongly disagree. If you want talented people committed overtime and dedicating 100% of their time and effort to a project, you need to pay them well, hence to monetize. With CrowdSec, the “crowd” that makes us stronger benefits for free, while large corporations with more complex and extensive requirements have the option of paying for additional services. BlackHat USA 2021 Reflections LS: You recently received a Black Unicorn Award at BlackHat USA 2021 for the Top 10 cybersecurity startups of the year. Congratulations on this accomplishment! Can you briefly reflect on what this award means to you and your team. What are some of the biggest challenges you have faced and what are some of the most notable accomplishments you’ve experienced as a startup? What was the “mission” behind starting CrowdSec? Do you feel this mission is being fulfilled? PH: I was a rookie red team pentester when I first attended a Blackhat. This conference is both legendary and very insightful! Now, having a Black Unicorn Award sitting on my desk has aspecial taste indeed. What it precisely represents is that we DO have a different approach. What the BlackHat jury saw in CrowdSec is a new approach to cyber - the collaboration age, the very concept that sharing is not giving away and getting poorer, but instead it’s making everyone stronger. We have a good IPS, that I’m sure of, but the fact that it’s coupled with a CTI approach and that tens of thousands of machines enrolled in our “crowd” in under a year proves with out a doubt that this path needs to be explored. In four years from now, we should have millions of machines sharing the rogue IP addresses they identify, making CrowdSec the biggest collaborative effort to date to influence the war against cybercrime. This will become the real-time world map of criminals over the Internet, like Waze became the de-facto standard for road hazards worldwide. Have we delivered yet? Yes, sort of. We took off, some trust we are up to something and adoption is accelerating. Have we achieved something? Not yet, it’s still day one, so please don’t hesitate to help us by contributing, adopting the product , commenting on the roadmap and connecting with us on Gitter ! A Bright Future for Crowdsec LS: What does the future hold for CrowdSec? Upcoming releases? New features and capabilities in the works? PH: This is a make or make (I don’t like the break part!) year for CrowdSec. The Console, the new premium features, the growing network, all is uncharted territory to us. We’ll probably have another fundraiser around early 2023, and plan to work on a blockchain approach, which could also be a game changer. We need to expand our team and reach probably 35 people while building a rock solid relationship with our community. The future is bright, our team is under constant shots of serotonin and the market offers us great feedback. As CEO, I also have to prepare the team and company for the hangover, when we’ll discover the world isn’t just about bull adoption, unicornpictures on the walls and encouragement messages on our Gitter . At some point, there will be harder times - missed deadlines, concerns on our KPIs, meaningful bugs, trials to try to slow us down or people leaving the company. I know it for a fact, and this will be the moment where we’ll see if we are experienced enough to persevere, giving us the opportunity to build the team and company to be resilient to those challenges. But for now, I wouldn’t wish to be anywhere but here in our journey! Closing Remarks LS: Thank you so much for your time and shared insights! Is there anything else you think the LinuxSecurity community should know about CrowdSec? Any closing remarks? PH: It’s up to you to defend yourselves, while helping everyone else around you. It doesn’t require you to be a bodybuilder or an expert in a martial art - all it takes is an apt-get install … Will you be involved in this cyberwar alongside CrowdSec’s community? Next Steps Download CrowdSec v1.2.0 from the project’s GitHub page to join the fight on cybercrime! Have a thought to share or another open-source security tool you’d like us to cover? Connect with us on Twitter and let us know! . Uncover perspectives from CrowdSec's founder regarding the power of collective security in combating cyber threats and enhancing online protection.. Collaborative Security, CrowdSec, Open Source Protection, Cyber Defense, Intrusion Prevention. . Brittany Day

Oct 03, 2021 •

Brittany Day

intrusion preventionsecurity toolopen source

CrowdSec v1.1.x Release: Exciting Features and Installation Steps

On July 8, 2021, the CrowdSec team released CrowdSec v1.1.x - the latest version of their free and open-source cybersecurity solution designed to protect Linux servers, services, containers, or virtual machines exposed on the Internet with a server-side agent - with new packages and repositories, as well as improvements to to the CrowdSec agent itself. LinuxSecurity spoke with the CrowdSec team to provide readers with insight into what they can expect from this exciting release, and how they can get started with CrowdSec v1.1.x. . A Brief Introduction to CrowdSec CrowdSec is a modernized, collaborative version of the Fail2Ban intrusion-preventio n tool that is designed to run on complex modern architectures including clouds, containers and lambdas. It leverages a behavior analysis system based on logs to determine whether someone is trying to hack you. If your agent detects such aggression, the offending IP is then sent for curation. If it passes the curation process, the IP is then redistributed to all users sharing a similar technological profile to “immunize” them against this IP. Philippe Humeau, CEO and co-founder of the company explains, “The goal is to leverage the power of the crowd to create a real-time IP reputation database. Ultimately, CrowdSec harnesses the power of the community to create an extremely accurate IP reputation system that benefits all its users. With its collaborative, transparent roots, Open Source has provided and continues to provide our team with the optimal framework to accomplish this mission”. Enhancing Package Support with Package Cloud As part of the CrowdSec v1.1.x release, CrowdSec has moved its services to Package Cloud , a fast, reliable and secure cloud-hosted package distribution. This move has enabled CrowdSec to distribute more packages to their customers . Thibault Koechlin, CTO, elaborates, “Alongside existing packages for Debian and Ubuntu including Bionic, Bullseye, Buster, Focal, Stretch, Focal for x86-64 and arm, we now provide packagesfor Red Hat Enterprise Linux (RHEL), CentOS and Amazon Linux. We encourage users to update repositories’ URLs as soon as they can. The “old” repository (S3 bucket used as a repository) will no longer be updated and will be decommissioned shortly.” As part of this landmark release, CrowdSec has also added RPM and Debian package support to its firewall bouncer , which fetches new and old decisions from a CrowdSec API and adds them to a blocklist used by supported firewalls, and its custom bouncer , which fetches new and expired or removed decisions from a CrowdSec Local API and passes them as arguments to a custom user script. Various improvements have also been made to CrowdSec itself, one of the most notable being a revamp of the data acquisition process to add support for CloudWatch sources. Their CTO states, “We are excited to announce that CrowdSec can also now act as a syslog server, which should allow for the addition of many more data sources in future releases!” Getting Started with CrowdSec v1.1.x With the release of v1.1.x, getting started with CrowdSec is now easier than ever! To install CrowdSec on Ubuntu or Debian, add the repositories: curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash Then install: sudo apt-get install crowdsec -y On a CentOS or Red Hat Enterprise Linux (RHEL) system, add the repositories: curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.rpm.sh | sudo bash Then install: sudo dnf install crowdsec If you install new services after this, you can update CrowdSec to install the required collections using: /usr/share/crowdsec/wizard.sh -c Repel Attacks with Bouncers CrowdSec’s detection capabilities provide visibility into the threats targeting your system; however, deterring attacks requires an intelligent, proactive security strategy, which is where bouncers come into play! Bouncers work by querying CrowdSec’s API to know when to block anIP. They can be downloaded directly from the CrowdSec Hub . To install the Cs-firewall-bouncer in an Ubuntu or Debian repository, use: sudo apt install crowdsec-firewall-bouncer-nftables crowdsec-firewall-bouncer If you are an CentOS or RHEL user, use: sudo dnf install crowdsec-firewall-bouncer-nftables The CrowdSec Console: CrowdSec Values Your Feedback! The brand-new CrowdSec Console, which is now in private beta, provides an easy-to-use web interface to inspect multiple CrowdSec agents spread across different networks. You can create a Console account and find instructions to enroll the CrowdSec agent app . Philippe, CEO, concludes, “The CrowSec team encourages testing and feedback! To get in touch with us, visit our Gitter channel . We look forward to continuing to provide our users with versatile, reliable and user-friendly intrusion-prevention services.” . Explore the latest enhancements in CrowdSec v1.1.x for bolstered protection and learn straightforward installation methods across different operating systems.. CrowdSec Installation,Linux Security Tools,Intrusion Detection,Cloud Package Management. . Brittany Day

Aug 01, 2021 •

Brittany Day

intrusion preventionsecurity measuresfirewall

Enhancing Network Security With Netfilter's Content-Based Filtering

This article will discuss a very useful but seemingly overlooked functionality of Netfilter, a firewall code widely used in Linux, that provides content matching and filtering capabilities. . This feature is offered as patch to Netfilter kernel-space code (Linux kernel) and user-space code (iptables) Since version 1.2.7a, it's been made available as a separate package called patch-o-matic. Traditional network-level firewall can inspect packets based on IP addresses, ports, TCP/IP flags completely ignoring the content in the payload. Imagine, what you can do with a firewall that can inspect more than just headers but the content in payload of every packet. With that type of firewall, you can easily block malicious worms and viruses that , I believe, are still hiting your machine every minute of the day. More interestingly, there are tools that will convert snort signatures into iptables-aware format (even with hex string support), enabling intrusion prevention at the kernel space and stopping the attacks before they occur. Having said all that, I shall show you how to put things together: First thing you need to do is to grab all the required packages: Kernel source code which has Netfilter kernel-space code integrated and compatible with the latest Netfilter user-space code (version 2.4.18+) . The latest stable version can be downloaded at ( https://mirrors.edge.kernel.org/pub/linux/kernel/v2.4/linux-2.4.21.tar.bz2 ) Netfilter user-space code which is now iptables, (latest version is 1.2.8) but currently only version 1.2.7a supports hex string patch ( https://netfilter.org/projects/iptables/files/iptables-1.2.7a.tar.bz2 ) and the corresponding patch-o-matic package ( https://netfilter.org/projects/patch-o-matic-ng/files/patch-o-matic-20030107.tar.bz2 ) FWSnort, a perl script that will convert most snort rules into iptables rules. Don't forget to grab a hex string support patch that adds a hex-string capability to libipt_string.c to iptables source also. All these stuff areavailable at ( www.cipherdyne.com/fwsnort/ ) Unpacking them in appropriate directory: [tony@0x90 src]$ tar -jxf linux.2.4.21.tar.bz2 [tony@0x90 src]$ tar -jxf iptables-1.2.8.tar.bz2 [tony@0x90 src]$ tar -jxf patch-o-matic-20030107.tar.bz2 Apply libipt_string patch to iptables source and build iptables kernel and user spaces code: [tony@0x90 src]$ cd iptables-1.2.7a/extensions [tony@0x90 extensions]$ patch -p1 < libipt_string.c.patch [tony@0x90 iptables-1.2.7a]$ make KERNEL_DIR=../linux-2.4.21 [tony@0x90 iptables-1.2.7a]$ sudo make install KERNEL_DIR=../linux-2.4.21 Next step is to apply a string match support from a patch-o-matic package. A patch-o-matic is a series of Netfilter add-ons that provides extra functionality to original Netfilter. It has a nice automated script that will allow you to choose which patches you want integrated and checks their dependencies. You should be aware that,some patches might not work with one another, so carefully read the comments before you apply any patches. In this case, we will apply only string-match support patch: [tony@0x90 src]$ cd patch-o-matic-20030107 [tony@0x90 patch-o-matic-20030107]$ KERNEL_DIR=../linux-2.4.21 ./runme extra Welcome to Rusty's Patch-o-matic! Each patch is a new feature: many have minimal impact, some do not. Almost every one has bugs, so I don't recommend applying them all! ------------------------------------------------------- Testing... fuzzy.patch NOT APPLIED ( 2 missing files) The base/fuzzy patch: Author: Hime Aguiar e Oliveira Jr. Status: Under development , but works . This option adds CONFIG_IP_NF_MATCH_FUZZY, which allows you to match packets according to adynamic profile implemented by means of a simple Fuzzy Logic Controller (FLC) . Suppported options are: --upper-limit => Desired upper bound for traffic rate --lower-limit => Lower bound over which the FLC starts to limit traffic ----------------------------------------------------------------- Do you want to apply this patch [N/y/t/f/a/r/b/w/v/q/?] N This patch is not of our interest, so answer no (N) to go to the next one. Keep going until you find our string-match (-m string -string) patch and answer yes (y) to apply it: Testing... string.patch NOT APPLIED ( 2 missing files) The extra/string patch: Author: Emmanuel Roger Status: Working, not with kernel 2.4.9 This patch adds CONFIG_IP_NF_MATCH_STRING which allows you to match a string in a whole packet. THIS PATCH DOES NOT WORK WITH KERNEL 2.4.9 !!! ----------------------------------------------------------------- Do you want to apply this patch [N/y/t/f/a/r/b/w/v/q/?] y Testing patch extra/string.patch... Placed new Config.in line Placed new Configure.help entry Placed new Makefile line Patch extra/string.patch applied cleanly. Applying patch extra/string.patch... Patch extra/string.patch applied cleanly. Placed new Config.in line Placed new Configure.help entry Placed new Makefile line [Press enter to continue] Now, go back to the directory where you unpacked the kernel source and proceed with the compilation. (If you have compiled your own kernel before, you can just skip reading this section), Instructions on how to compileand customize your kernel can be read at (https://tldp.org/HOWTO/Kernel-HOWTO.html) [tony@0x90 linux-2.4.21]$ make mrproper && make menuconfig [tony@0x90 linux-2.4.21]$ make menuconfig [tony@0x90 linux-2.4.21]$ make dep && make bzImage [tony@0x90 linux-2.4.21]$ sudo make modules && make modules_install [tony@0x90 linux-2.4.21]$ sudo cp arch/i386/boot/bzImage /boot/vmlinuz-2.4.21 [tony@0x90 linux-2.4.21]$ sudo mkinitrd -f -v /boot/initrd-2.4.21.img 2.4.21 Finally, we are done with building all the components, reboot the system and enjoy your new toy. Now let's test this new functionality and use it as an active defense system: # This rule rejects all incoming mails with a string of "Buy Now" which many people consider it #as spam iptables -A INPUT -p tcp -dport 25 -m string --string "Buy Now" -j REJECT --reject-with tcp-reset # Blocks superscan ping but allows other types ping iptables -A INPUT -p icmp -icmp-type 8 -m string -string "|0000000000000000|" -j DROP # This will reset any connection that attempts to access a shell, in which you will find in most exploit codes iptables -A INPUT -p tcp -m string --string "/bin/sh" -j REJECT --reject-with tcp-reset Let's see if it works, on the server side execute nc -vv -l -p 23, on the remote host execute: telnet 10.0.0.1 23 Trying 10.0.0.1 Connected to 10.0.0.1 Escape character is '^]'. hello /bin/sh Connection closed by foreign host. # Thanks to hex string support, now we can easily block x86 NOOP sleds used in most buffer overflow exploits (use this with care, since it is possible that binary files transfer in e-mail may contain these strings and will get dropped!) iptables -A INPUT -p tcp -dport 22 -m string --hex-string "|90 90 90 90 90 90|" -j DROP iptables -A INPUT -p tcp -dport 80 -m string --hex-string "|90 90 90 90 90 90|" -j DROP You can try any buffer overflow exploits and will find that most of them get silently dropped! Now, you begin to have some idea on how to use this new feature as a content-based firewall system either for your local host or internal network. The FWSnort script that you have downloaded in the beginning will come into play as we will use it to convert some snort signatures into iptables rules. First unpack the source and install it: [tony@0x90 fwsnort-0.1]$ sudo perl install.pl Edit the configuration /etc/fwsnort/fwsnort.conf file to suit your needs and start the conversion: [tony@0x90 fwsnort-0.1]$ sudo fwsnort -c /etc/fwsnort/fwsnort.conf --ipt-drop A converted set of snort rules will be written to /etc/fwsnort/fwsnort.sh in a form of a shell script. Modify it again to suit your need , and merge it with your existing firewall rule. One thing you should keep in mind when working with a large iptables rules is that, everytime you perform an APPEND or INSERT, iptables will allocate a memory and invoke this function every time , resulting in a very slow performance. Iptables has a solution to this problem byproviding you scripts that will load a large rule set into the kernel very quickly or dump the current rule set from the kernel into iptables configuration file. So I suggest you first run your firewall script and then save it as iptables format using the command: iptables-save > /etc/syconfig/iptables Then whenever you need to reload the firewall rule-set you simply issue the command iptables-restore , and all rules will be reloaded in a much faster manner. Up to this point, you may think that if this functionality is so powerful, why doesn't anyone use it in replacement for snort? Although, Netfilter can perform a stateful inspection of content in a packet at the network level, it still lacks advanced capabilities in handling fragmented packets, polymorphic shell codes, traffic normalization, etc. Snort, on the other hands, can perform a pattern matching using a much faster algorithm called Boyer-Moore, supports a stateful packet analysis and stream reassembly. If you are interested in using snort as defense system, there is an ongoing honeypot project ( ) that uses a modified version of snort called snort_inline and a special set of firewall rules to achieve a hybrid firewall system. In conclusion, I would like to comment that intrusion prevention is still at its early stage and there is no out-of-the-box product that will perfectly fits your requirements. Every network has its own culture and usage behavior thus needs a distinctly unique tuning. Don't simply rely on a single tool but do correlate data from various sources and use them to understand your network and improve your security infrastructure. Nawapong Nakjang has been working in the areas of information security, network security and cryptography for several years. Hisinterests include intrusion detection, honeypots, incident investigation, malicious code analysis, computer forensics and penetration testing. Occasionally, he writes security-related article and answers security questions in mailing lists. He plans to pursue his second degree in Information Security and publishes more papers to the security community. . Network security is crucial as new threats emerge. Netfilter, a robust Linux firewall, enhances security with advanced content filtering and intrusion prevention. Netfilter Content Filtering, Intrusion Prevention System, iptables Configuration. . Brittany Day

Aug 04, 2003 •

Brittany Day

risk managementintrusion preventionsecurity techniques

Enhancing Security With Behavioral Intrusion Prevention Techniques

Scott Wimer, CTO Cylant Software, discusses methods for improving the security of a computer system in spite of their vulnerabilities in order to break out of the current security cycle. . The software you depend on contains security vulnerabilities. Not all of these vulnerabilities have been found yet. Some are known only to "black hat" hackers, a trump card they can play against your organization if and when they choose to. This is not alarmism. It is an honest and rational statement of the current security risk born by organizations with networked computer systems. The software running on your systems was written by people. People make mistakes. People are more prone to make mistakes when performing complicated and difficult tasks. Unfortunately, designing and writing secure software is a difficult and tedious process. As a result, the software you use contains flaws causing security vulnerabilities. Since you do not have the option of running software without vulnerabilities, the challenge is to mitigate the risks the vulnerabilities can cause. Cyclic Security Process Managing the risk created by vulnerable software is currently a cyclic process. Consequently, security is a continual cost center. Furthermore, if the process stops or breaks down, earlier gains in risk reduction are effectively lost, since an attacker only needs to find one way in. The heart of the cycle is the sequence of events below: Vulnerability, "V-19" is discovered in program "e-serve" versions 1.2 - 1.5. V-19 is publicly announced. You audit your systems for vulnerable versions of e-serve. You increase the monitoring of the systems running a vulnerable e-serve. Exploit, "r00t-19", for V-19 is released. An IDS signature to spot r00t-19 is released. You update your IDS's rule-set with the r00t-19 signature. You develop an action plan for recovery from r00t-19 attacks. Thee-serve vendor releases version 1.6, which fixes the V-19 vulnerability. But, may introduce other vulnerabilities. You upgrade e-serve on a test system to make sure that version 1.6 works properly in your environment. You deploy e-serve 1.6 on all production systems. You update your IDS rule-sets to reduce the priority of r00t-19 attacks, since they can not succeed now. Perhaps the worst aspect of the security cycle above is that you do not, and can not, control the start of the cycle. Instead, some arbitrary individual makes a discovery that kicks off the cascade of risk, cost, and work in the security cycle. Running a close second for the worst aspect of the security cycle is that even when you follow best practices, your systems are unavoidably open to attacks for large blocks of time. This is a game you can not win. There has to be a better approach. Today, vulnerability discovery dictates the risk associated with connecting systems to the Internet. The attackers constantly have the upper hand, is it any wonder that they usually win? Vulnerability Mitigation The existence of security vulnerabilities in software is an unavoidable fact. Methods for securing systems in spite of their vulnerabilities are needed in order to break out of the current security cycle. Breaking out of the security cycle requires changing the impact of software vulnerabilities. Once the impact of vulnerabilities is mitigated, effort can be directed at forward progress, instead of responding to vulnerabilities just to maintain status quo. Behavioral Intrusion Prevention A few simple observations about software form the framework of a security approach that mitigates vulnerabilities rather than responding to them. Software executes in quantifiable patterns. Software execution variation is measurable. The source of the variation can be isolated. Targeted countermeasures can be deployedagainst the source. When an attacker exploits a vulnerability in an application, they cause the application to begin executing in a different way. In fact, the PURPOSE of the exploit is to change the application's execution. If we can spot the change in execution behavior soon enough, we should be able to stop the vulnerability from being used to compromise the system. This is the rationale behind the behavioral approach to intrusion prevention. Attacks can be stopped before they inflict damage, without needing specific rules to spot each attack or attack type. Successful behavioral intrusion prevention requires meeting three challenges. First, execution observation must be able to spot changes in the execution caused by exploiting any vulnerability. Second, this observation must be made soon enough to take corrective measures before the system is compromised. Third, policies governing the responses need to be established. Security is a process, and with behavioral intrusion prevention, it is a process under your control. When your business practices change, the usage patterns of your software unsuprisingly change accordingly. New software (and upgrades of existing software) creates new execution behavior. With behavioral intrusion prevention these events require you to revisit and potentially update your policies and countermeasures. Instead of uncontrollable outside events setting off a cycle of work and risk, business decisons require the creation or modification of policies. Modifying the policies and countermeasures becomes just another step in the process of deploying software or changing business practices. Behavioral intrusion prevention stops attacks before they succeed, rather than reporting their success. If for some reason you want attacks to succeed, behavioral intrusion prevention lets you do this as well; apply passive countermeasures. In most cases though, your business is better off stopping attacks than letting themcontinue. Conclusion Signature and rule-based intrusion detection systems are not sufficient to prevent attacks from succeeding. Current IDS techniques can not deal with the inescapable fact that software contains security vulnerabilities. Behavioral intrusion prevention can help by observing and stopping attacks as soon as a vulnerability exploitation occurs. By stopping attacks this soon, the risk associated with software vulnerabilities can be mitigated. About Cylant Cylant, a division of Software Systems International, develops technologies and systems for measuring the execution behavior of running software. Cylant provides tools to observe the behavior of running software and measure that behavior against a stored behavioral baseline. . Enhance system defenses against software threats by implementing adaptive defensive strategies systematically.. Behavioral Intrusion Prevention, Software Risk Management, Security Techniques. . Brittany Day

Jan 20, 2002 •

Brittany Day

Stay Ahead With Linux Security Features

Refine features

Get the latest News and Insights

Community Poll

What got you started with Linux?

Trending Features

Top Linux Vulnerability Scanners in 2026: A Guide to Open-Source Security Tools

How Linux Pentesting Improves Network Security

Understanding Log Management and Analysis Tools for Linux Systems

What is Nmap? How To Use It Effectively for Network Security

Explore Latest Linux Security features

Intrusion Detection Systems vs Prevention Systems Snort Overview

What Is Fail2Ban? Using Log-Based Intrusion Prevention to Secure Linux Servers

Exclusive Interview with CrowdSec CEO on Cybercrime Defense Strategies

CrowdSec v1.1.x Release: Exciting Features and Installation Steps

Enhancing Network Security With Netfilter's Content-Based Filtering

Enhancing Security With Behavioral Intrusion Prevention Techniques

Get the latest News and Insights

Community Poll

What got you started with Linux?

Trending Features

Top Linux Vulnerability Scanners in 2026: A Guide to Open-Source Security Tools

How Linux Pentesting Improves Network Security

Understanding Log Management and Analysis Tools for Linux Systems

What is Nmap? How To Use It Effectively for Network Security

Powered By

Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases

QUICK LINKS

subscribe to newsletters!

Stay Ahead With Linux Security Features

Refine features

Topics

Authors

Published Date

Get the latest News and Insights

Community Poll

What got you started with Linux?

Trending Features

Explore Latest Linux Security features

Get the latest News and Insights

Community Poll

What got you started with Linux?

Trending Features

Search Topics

Powered By

Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases

QUICK LINKS

subscribe to newsletters!