Stay Ahead With Linux Security Features
threat detection scalability Building a SIEM is easier than scaling one. Most open-source deployments start as a simple "all-in-one" server. It is easy to set up, but that design rarely survives the transition from a lab to a production workload. . A SIEM watching 20 endpoints is not doing the same job as one watching 500. More endpoints mean more logs; more logs require more storage; more storage makes search heavier. Eventually, the very architecture that made your lab easy to deploy becomes the reason your production...
Jun 04, 2026
security advisory apache A newly disclosed attack technique called HTTP/2 Bomb is drawing attention because it targets the software that sits at the front of much of the Linux internet. Apache HTTP Server, NGINX, Envoy, and the ingress layers that many Kubernetes environments depend on can be forced into consuming disproportionate amounts of memory using relatively small amounts of attacker traffic. . For Linux administrators, the concern is not the HTTP/2 protocol itself. It is the possibility that a single...
Jun 04, 2026
security advisory important The compromise of Nx Console shows how much infrastructure now sits behind a single developer account. GitHub repositories, CI/CD pipelines, container build systems, Terraform projects, Kubernetes deployments. None of those systems was the initial target. The workstation was. . Attackers did not need a Linux privilege escalation bug or a remote code execution chain. They needed developers to trust a tool they were already using. For many organizations, that was enough. What Happened? Federal...
Jun 03, 2026
security advisory open-source You remove the malware. You rotate the compromised credentials. You patch the original vulnerability and close the ticket. Two weeks later, the attacker is back. . What happened? You didn't lose the battle at the exploit; you lost it at the cleanup. In many modern Linux intrusions, the malware you found wasn't the main problem—it was the fallback mechanisms left behind. These hooks quietly restore attacker access the moment you look away. If you clean a host but miss these persistence layers,...
Jun 02, 2026
security advisory Red Hat Researchers investigating a campaign now tracked as Miasma found that more than 30 packages in Red Hat's @redhat-cloud-services npm namespace had been altered to deliver credential-stealing malware. . The packages weren't being used to deploy ransomware or sabotage systems. From what has been reported so far, the objective appears to have been much simpler: collect credentials from developer environments and use that access elsewhere. GitHub tokens, cloud credentials, SSH keys, and other...
Jun 02, 2026
Refine features
X Clear Filters
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Loading...
Explore Latest Linux Security features
We found -1 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. . 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
•
102
Linux securitytraffic analysisnetwork intrusion detectionUnderstanding the Snort NIDS: What It Changes in Your Monitoring and Risk Model
You can lock down UFW or nftables, tighten SSH, layer in fail2ban, and still not know what is actually moving across your network. At some point, that gap becomes obvious. You see a strange outbound connection in netstat, or a spike in DNS requests, and realize your controls are mostly about blocking, not observing.. Firewalls enforce what you tell them to enforce. They do not inspect application payloads deeply, and they do not tell you when allowed traffic starts behaving in ways it should not. That is where a network intrusion detection system comes into the picture. Snort is a network intrusion detection system that analyzes live network traffic against rule sets designed to detect suspicious patterns. It looks at packets, sessions, and payload content in real time, then generates alerts when something matches known attack signatures or abnormal behavior rules. In practical terms, Snort gives you visibility into traffic that your firewall already permits. That shift matters more than it sounds. Instead of relying solely on host logs or firewall denies, you gain a layer that can detect command and control callbacks, lateral movement attempts, malformed HTTP requests, or exploit signatures moving across internal segments. You start to see patterns across systems rather than isolated events on a single host. In this article, we will break down what Snort actually does under the hood, where it fits into Linux security architecture, and how it changes your monitoring and policy decisions. We will also look at the operational trade-offs, because deploying a NIDS without planning for alert handling and tuning can quietly create more noise than insight. If you are evaluating whether Snort belongs in your environment, the real question is not whether it can detect threats. It is whether you are prepared to use what it shows you. What Snort Actually Is (and Is Not) Before you can decide whether Snort belongs in your stack, you need a clean mental model of what it does. A lot of confusioncomes from treating a NIDS like a smarter firewall or a lightweight SIEM . It is neither. Snort is a NIDS that inspects network traffic against rule-based signatures and detection logic. It listens to packets as they move across a segment, reconstructs sessions where needed, and evaluates that traffic against a set of rules that define suspicious patterns. Those rules might look for known exploit byte sequences, abnormal protocol behavior, or policy violations such as cleartext credentials. It does not live inside your kernel like iptables or nftables. It does not enforce access control lists. It observes traffic from the network layer outward and generates alerts when something matches. At a practical level, this is what that means: Snort analyzes packets, flows, and payload content in real time. It runs in IDS mode for alerting, or IPS mode when deployed inline for blocking. It depends heavily on rule sets that must be updated and tuned. It can detect exploit attempts, scanning behavior, and suspicious outbound patterns. It does not patch vulnerabilities, rotate keys, enforce MFA, or replace endpoint detection. That distinction matters. I have seen environments where SSH brute force attempts were already being rate-limited by fail2ban, but Snort flagged outbound traffic matching a command and control signature from a compromised web process. The firewall allowed the connection because it was outbound over 443. From a policy standpoint, nothing looked wrong. From a detection standpoint, everything was wrong. Here is what you need to do. Stop thinking of Snort as something that blocks. Think of it as a sensor that tells you when allowed traffic is behaving in ways it should not. Once you see it that way, the role becomes clearer. You move from a model of “block known bad ports” to “detect suspicious behavior inside permitted flows.” That changes expectations. It also changes your incident workflow, because alerts from Snort often require correlation withapplication logs, auth logs, or DNS records before you know whether you are looking at noise or compromise. How Does a Network Intrusion Detection System Fit into Linux Security? Once you understand what Snort is , the next question is where it actually sits in your Linux security stack. This is where a lot of deployments go sideways. People install it, see alerts, and never quite connect it to the rest of their monitoring model. In a typical Linux environment, you already have layers. A firewall such as UFW, iptables, or nftables enforces access policy. System logs track authentication attempts, sudo use, service failures. Maybe you have EDR on endpoints, maybe not. A network intrusion detection system fits beside those controls, not on top of them. Firewalls filter based on IP, port, protocol, and connection state. They are excellent at enforcing boundaries. Snort inspects deeper into payload and session behavior. It can flag a suspicious HTTP request that technically complies with your firewall policy, or detect an exploit attempt embedded inside traffic that was otherwise allowed. That difference becomes obvious when you look at real traffic. A web server listening on 443 will receive constant background noise from scanners. Your firewall will allow it because the port is open by design. A network intrusion detection system will parse those requests and alert when a known exploit signature appears in the payload. Same connection. Different visibility. Snort can also feed its alerts into a SIEM or centralized logging system, where you correlate them with auth logs, systemd journal entries, or DNS queries. This is where the value compounds. An outbound alert that lines up with a suspicious new process and a recent failed login attempt is not just noise anymore. It is a story forming across layers. Placement is where many people underestimate the work. Start with this: identify your traffic aggregation point. Is it a core switch mirror, an edge router, a virtual switch in a hypervisor?Do not guess. If Snort only sees internet ingress traffic and not east-west movement between internal hosts, you are blind to lateral movement. What good looks like is mirrored traffic that includes both north-south and east-west flows, with packet visibility that matches your segmentation model. What broken looks like is a sensor watching only external traffic while internal compromise moves quietly between servers. The impact here is architectural. You are not just adding a package to a Linux server. You are deciding where in your network security model you want visibility, and whether your topology actually supports that visibility. If the traffic is not flowing past the sensor, Snort cannot help you, no matter how well-tuned it is. What Snort Changes in Your Monitoring and Alerting Workflow The technical part of deploying Snort is not the hard part. The shift in monitoring is. The moment you enable it, you introduce a new log source into your environment. And unlike a tidy service log that rotates every few megabytes, a NIDS can generate a steady stream of alerts depending on your exposure. On a public-facing server, background internet noise alone can trigger hundreds of events a day. Default rule sets are broad by design. They try to detect a wide range of known exploit patterns and suspicious behaviors. In a real environment, that means noise. Not useless noise, but unfiltered signal that needs context. Snort alerts rarely stand on their own. A SQL injection alert means something very different if your web logs show a 200 response and normal query handling versus a 500 error and a suspicious database call. An outbound policy violation alert looks minor until you line it up with a new cron job and an unfamiliar binary in /tmp. Here is how I approach this. First, I confirm that traffic visibility is correct. No point tuning alerts if the sensor is blind to half the segment. Then I enable a conservative subset of rules rather than everything available. I let it run for severaldays and measure alert volume and type. Good looks like a manageable number of daily alerts with recurring patterns you can classify. Broken looks like thousands of low-priority events that no one reviews and no one trusts. If you are seeing constant SQL injection alerts against a public application, check whether they are generic scanner traffic that your app is already handling safely. Internet-facing services attract background probing. Escalating every one of those will burn out your on-call rotation quickly. This is where network security stops being abstract. You have to define severity in your environment. What counts as critical? What gets ticketed. What gets logged and trended but not paged? Snort signatures detect patterns, not intent. Context is your job. Operationally, that means adjusting your triage process. You may need new playbooks, clearer alert routing, and explicit ownership for reviewing NIDS alerts. Snort adds visibility, but it also adds overhead. If you do not plan for that shift, alert fatigue will set in quietly, and the system will be ignored just when you need it most. Deployment Models That Matter to Linux Admins This is the part where design decisions quietly determine whether Snort helps you or just gives you a false sense of coverage. There are a few common ways to deploy a NIDS like Snort. Each one changes what you see and how much risk you are actually observing. You can run Snort passively using a SPAN or mirror port. Traffic is copied from a switch and sent to the sensor. Snort analyzes it and generates alerts, but it does not sit inline with production traffic. You can deploy it inline as an IPS, where traffic flows through the engine and can be blocked in real time. That moves you from detection to enforcement, but it also introduces latency and failure considerations. You can run it on dedicated hardware with direct network interfaces, or inside a virtual machine attached to a virtual switch. That decision affects throughput, packet loss,and overall reliability. Throughput is not theoretical. I have seen VM-based Snort deployments on busy hypervisors start dropping packets under load. CPU spikes, packet queues fill, and suddenly the sensor is missing traffic. The logs still look clean. The coverage is not. If you are deploying Snort, verify packet capture statistics regularly. Check for dropped packets. Compare interface counters with what the sensor reports. If drop rates climb during peak hours, you have a blind spot that no alert will warn you about. Inline deployments introduce a different risk. A misconfiguration or performance bottleneck can affect production traffic. That is not just a monitoring issue anymore. It becomes an availability issue. Integration is another practical layer. Snort needs to send alerts somewhere useful. That might be a centralized logging stack such as ELK or Splunk. Without that integration, alerts stay local to the sensor and rarely get correlated with system logs or authentication events. Do not skip this design work. Where you place Snort in the network determines what risk you are actually monitoring. A NIDS watching only edge ingress traffic will not see lateral movement between internal Linux servers. A sensor attached to the wrong virtual switch may never see database traffic at all. Deployment decisions are risk decisions. If placement is wrong or performance is undersized, you end up with invisible gaps. And the dangerous part is that everything appears operational on the surface. Common Failure Modes and What Breaks First Most Snort deployments do not fail dramatically. They fade. At first, alerts come in, and people pay attention. Then, rule updates introduce new signatures, alert volume shifts, and tuning never quite catches up. A few noisy rules get disabled. Ownership becomes vague. Months later, the sensor is technically running, but no one is using it with confidence. Outdated rule sets are one of the first cracks. Snort depends on current signatures to detect knownexploit patterns. If rules are not updated consistently, detection quality degrades quietly. You still see alerts, just not the ones that matter. The opposite problem shows up just as often. Overly broad or aggressive rules generate false positives that overwhelm the team. A burst of alerts after a rule update is not unusual. I watch for sudden spikes in specific signature IDs. That usually means something changed upstream, or a new rule is matching benign traffic in your environment. Encrypted traffic adds another limitation. Modern network security has to deal with TLS everywhere. Without decryption, Snort can only inspect metadata and observable patterns, not full payload content. That does not make it useless, but it narrows visibility in ways that are easy to forget. Performance bottlenecks are less visible but just as serious. High-throughput links can saturate a sensor if hardware or tuning is not aligned with traffic volume. Packet drops under load create blind spots. And unless you are actively checking interface stats and capture metrics, you may not notice. Then there is integration drift. Alerts that never make it into your centralized logging system eventually get ignored. A network intrusion detection system that operates in isolation tends to become background noise. This is the part people underestimate. Snort is only as effective as the attention it receives and the processes around it. In practical terms, you need defined ownership. Someone has to monitor rule updates, review recurring alerts, and periodically validate that the sensor still sees the traffic it is supposed to see. Without that, Linux security posture slowly erodes, not because the tool failed, but because the workflow did. When Snort Is Worth Deploying and When It’s Not At some point, the technical discussion turns into a resource question. Not whether Snort works, but whether it makes sense for your environment. There are environments where a NIDS adds clear value: Public-facing servicesthat handle sensitive data and attract constant probing Segmented internal networks where lateral movement is a real concern Multi-tenant or shared infrastructure where visibility between zones matters Systems subject to compliance requirements that expect network-level monitoring High-value data environments where outbound traffic patterns need scrutiny In those cases, Snort gives you something your firewall and host logs cannot. It lets you observe patterns across the wire, not just inside a single box. That visibility can surface command and control traffic, exploit attempts against exposed services, or suspicious movement between internal hosts. But there are environments where the overhead outweighs the benefit. A small lab with minimal exposure and no dedicated monitoring workflow may not gain much from deploying a network intrusion detection system. If no one has time to review alerts, tune rules, and check for packet drops, the sensor becomes a checkbox. Monitoring without review is risk theater. You also need to consider team maturity. If you do not have a defined alert path, documented triage flow, and log retention policy, Snort will amplify confusion rather than clarity. The tool assumes that someone is listening. Here is the practical lens. Do you have the capacity to operationalize it? Can you absorb the additional alerts into your existing process without burning out your on-call rotation? Can you commit to periodic rule tuning and performance validation? When the answer is yes, Snort strengthens your network security posture by giving you visibility you did not have before. When the answer is no, installing it anyway does not reduce risk. It just redistributes it into ignored alerts and blind spots. The decision shifts from “Can we install Snort?” to “Can we support it responsibly in our Linux security model?” Our Final Thoughts for Linux Admins Considering Deploying the Snort NIDS Snort earns its place when you care about what is happening insideallowed traffic. That is the core shift. A firewall enforces boundaries. A network intrusion detection system observes behavior within those boundaries, and that difference becomes obvious once you start correlating alerts with real events. Snort will not replace patching, hardening, log review, or endpoint controls. It adds another signal source. Sometimes that signal is the first indication that something moved laterally between two internal servers, or that a web process initiated an outbound connection pattern it never used before. It also adds work. Rule tuning, alert triage, packet capture validation, performance monitoring. None of that happens automatically in a useful way. If alerts are not reviewed and rules are not maintained, Snort becomes background noise quickly. The sensor keeps running, but trust in its output fades. Before deploying, slow down and answer three practical questions. Where will the traffic mirror or inline feed come from, and does it actually cover the segments you care about? Who owns rule updates and tuning, and how often will they review recurring alerts? Where do alerts go, and who is accountable for reviewing them within a defined time window? What good looks like is a manageable alert volume, clear triage steps, and measurable visibility into traffic patterns you could not see before. What broken looks like thousands of ignored events, packet drops under load, and a team that stops trusting the data. I have seen Snort surface real command and control traffic that no host-based log exposed. I have also seen it installed, left untuned, and quietly sidelined because no one had time to manage it. The decision is not whether Snort works. It is whether you can integrate this network intrusion detection system into your workflow in a way that strengthens, rather than complicates, your Linux security posture. . Learn how Snort enhances traffic monitoring and refines risk management in your Linux environment for better security insights.. networkmonitoring, Snort deployment, Linux traffic analysis, alert management, security administration. . Brittany Day
Feb 26, 2026
•
102
network securityintrusion detectionnetwork monitoringEffective Network Intrusion Detection Guide: Snort Configuration Details
This document takes you through the basics of intrusion detection, the steps necessary to configure a host to run the snort network intrusion detection system, testing its operation, and alerting you to possible intrusion events. . Snort is a software-based real-time network intrusion detection system developed by Martin Roesch that can be used to notify an administrator of a potential intrusion attempt. The ever-increasing amount of Internet crackers, armed with "ready-to-run" exploits, as well as the sophisticated attacker that's intent on defacing your web page necessitates the use of a method to track their activity and alert you to this. Until now, intrusion detection devices were either dedicated-use commercial products, or not real-time and difficult to install. Snort is the solution for monitoring small TCP/IP networks where it is not cost-effective to deploy commercial products. Snort is an easy-to-use, "lightweight", and very functional alternative. What is Network Intrusion Detection? A Network Intrusion Detection System (NIDS) is a system that is responsible for detecting anamolous, inappropriate, or other data that may be considered unauthorized occuring on a network. Unlike a firewall, which is configured to allow or deny access to a particular service or host based on a set of rules. If the traffic matches an acceptible pattern, it is permitted regardless of what the packet contains. However, an NIDS captures and inspects all traffic, regardless of whether it's permitted or not. Based on the contents, at either the IP or application level, an alert is generated. Snort is a "lightweight" NIDS in that it is non-intrusive, easily configured, utilizes familiar methods for rule development, and takes only a few minutes to install. Snort currently includes the ability to detect more than 1100 potential vulnerabilities. Keep in mind that Intrusion Detection devices work in conjunction with other security measures, and are not a replacement for other good security practices. It is also quitefeature-packed right out of the box. Among its features include the ability to: Detect and alert based on pattern matching for threats including buffer overflows, stealth port scans, CGI attacks, SMB probes and NetBIOS queries, NMAP and other portscanners, well-known backdoors and system vulnerabilities, DDoS clients, and many more; Use syslog, SMB "WinPopUp" messages, or a file to alert an administrator; Develop new rules quickly once the pattern (attack signature) is known for the vulnerability; Record packets in their human-readable form from the offending IP address in a hierarchial directory structure. Used as a "passive trap" to record the presence of traffic that should not be found on a network, such as NFS or Napster connections; Used on an existing workstation to monitor a home DSL connection, or on a dedicated server to monitor a corporate web site Snort uses the popular libpcap library, the same library that tcpdump uses to perform its packet sniffing. Snort decodes all the packets passing by on the network to which it's attached by entering promiscous mode. Based upon the content of the individual packets and the rules defined in the configuration file, an alert is generated. Why Use Intrusion Detection? Intrusion detection devices are an integral part of any network. The Internet is constantly evolving, and new vulnerabilities and exploits are found regularly. They provide an additional level of protection to detect the presence of an intruder, and help to provide accoutability for the attacker's actions. Before Installing Snort There are a few things you should determine before you install snort. Do you have approval to run an intrusion detection device by your organization? Is the system you're installing snort on secure? The last thing you want is the feeling of that false sense of security that you get by looking at what you think is happening but really has been modified by an intruder. The use of OpenSSH is mandatory for remote access. Reading the SolarisSecurity FAQ and the Linux Security HOWTO should provide you with a starting point. Where are you going to put it? If you are simply trying to find out who is port scanning or attempting to attack your home system, it's an easy decision. However, placement in an organization may be more difficult. Is the date and time correct? Ensure the time and date are correct on the host that snort will be running on. Install the xntpd time server so you can be sure the time of the events you are recording is correct. Chances are it is included with or already installed on your system but may still need to be configured. Once you have found a suitable timeserver from the URL provided above, a root crontab entry such as the following should suffice: 00 * * * * root /usr/sbin/ntpdate -u The device may be placed outside an organization's firewall between the firewall and the external untrusted network. This allows snort to detect not only the attacks that may make it through the firewall, but also those that are blocked by the firewall. The presence of switches, routers and firewalls will all have an effect on the correct placement of the box. A decision must be made as to which network segment will catch the traffic you actually want to monitor. Placement of the NIDS on the local side of the firewall will allow the NIDS to monitor traffic that the firewall has already determined to be permissable, but not necessarily benign. This will, of course, not catch traffic that the firewall has already blocked, potentially masquerading port scans, probes and other types of attack. Single Interface The easiest configuration is a box with a single interface. The same interface that listens to the network traffic is the same one from which administration is done. Images Courtesy Network Flight Recorder This will be the typical configuration for home network users and administrators monitoring internal networks. Dual Interface In a dual-interface configuration, oneinterface is used to listen to network traffic in promiscuous mode while the other is used for remote administration. This type of configuration is used in environments where it is not possible to administrate the box from the same interface that is listening to the network traffic. In this configuration, the external interface should be well-protected and the box designed explictly for this purpose. The box should not be offering any network services except for ssh on the internal interface only. Images Courtesy Network Flight Recorder Installation of Snort The file INSTALL included with the distribution contains information on installing and configuration snort from the downloadable source code. It is very easy to compile, configure, and install. If you are a Red Hat or compatible user, a precompiled RPM file is available from . You will also need the libpcap-0.4 package which is included with all Linux distributions. The source code and other information are downloadable from . Installing the Snort Ruleset After snort is installed, you'll want to download the latest rules file. Currently there are two different rulesets that people use. A ruleset developed by Jim Forster can be downloaded from Another ruleset, developed as part of Max Vision's ArachNIDS work, is available from and updated hourly. The Max Vision ruleset is particularly nice because it follows the Common Vulnerabilities and Exposures (CVE) database, allowing people to refer to a particular vulnerability using a consistent name. From the CVE Frequently Asked Questions: "CVE is a list of information security vulnerabilities and exposures that aims to provide common names for publicly known problems. The goal of CVE is to make it easier to share data across separate vulnerability databases and security tools with this "common enumeration." " If you've installed the snort RPM, the /usr/sbin/snort-update script written by Dave Dittrich can be used to download thelatest Max Vision ruleset from cron: 00 00 * * * root /usr/sbin/snort-update -q It can also be downloaded from This assumes the wget package is installed, the local box can download the file at , and it can successfully deliver mail to an administrator. The snort-update script will place the vision.conf file in /etc/snort/vision.conf.new and an email notification will be sent to the local root account with the differences from the previous version, if any. You must then rename the vision.conf.new to vision.conf . You might also consider using the snort.org ruleset in addition to the Max Vision ruleset. This can be achieved by downloading the snort.org ruleset. Information on combining these rulesets together is included below. The backdoor-lib , misc-lib , overflow-lib and other similar files are included with the source code, but are pretty dated and not typically used. Before snort can be started, a few variables must be defined. Also included in the snort RPM is a file called rules.base which was derived from Max Vision's vision.conf file. It is a short file that contains a few variables that define your internal and external networks, hosts that snort should ignore portscans from, and on which networks snort should watch for portscans. It can also be downloaded from . A portscan is defined as TCP connection attempts to more than P ports in T seconds or UDP packets sent to more than P ports in T sections. Read Martin's "Writing Snort Rules" for a full description of portscan. You'll need to supply the information for your INTERNAL and EXTERNAL networks, and from DNS servers which tend to trigger the portscan detection. The rules.base file looks as follows: # # Taken and modified from "vision.conf", part of Max Vision's # ArachNIDs work. See /usr/doc/snort-1.6/README.snort-stuff for more # information on how to use this file. var INTERNAL 192.168.1.0/24 var EXTERNAL 63.87.101.0/24 var DNSSERVERS63.87.101.90/32 63.87.101.92/32 preprocessor http_decode: 80 443 8080 preprocessor minfrag: 128 preprocessor portscan-ignorehosts: $DNSSERVERS preprocessor portscan: $EXTERNAL 3 5 /var/log/snort/portscan.log # | # Log file (path/name) ----------------------------------+ # Ruleset, available (updated hourly) from: # # # Include the latest copy of Max Vision's ruleset include /etc/snort/vision.conf # # Uncomment the next line if you wish to include the latest # copy of the snort.org ruleset. Be sure to download the latest # one from # # include /etc/snort/06082k.rules # # If you wish to monitor multiple INTERNAL networks, you can include # another variable that defines the additional network, then include # the snort ruleset again. Uncomment the two following lines. # # var INTERNAL 192.168.2.0/24 # include /etc/snort/vision.conf # include other rules here if you wish. If you are on a dialup machine, the INTERNAL setting would be your dialup interface with a /32 subnet mask, indicating the host itself. Additionally, you may need to configure syslogd to log snort and other security events to a specific log file. Edit /etc/syslog.conf to log snort alerts, then signal syslogd to re-read the /etc/syslog.conf file: authpriv.* /var/log/secure.log [root@krypton ~]# /usr/bin/killall -HUP syslogd Using Preprocessors The preprocessor directives listed above are used to examine the data flow before the intrusion detection engine applies the ruleset to the packets. This can be used to modify the contents of the packet, or to signal the detection engine to not process a particular packet. The preprocessor http_decode: directive instructs the detection engine to convert the data within HTTP URI strings into a format that defeats attempts at eluding the content analysis strings used to examine HTTP traffic for suspicious activity. Supply the ports on which a web serveris running. The preprocessor portscan: directive is used to define the host or network for which snort should watch for a portscan. The /32 appearing after the IP addresses indicates CIDR notation for a 32-bit subnet mask (the host itself). For a Class C network, use /24 . It may also be necessary to exclude some hosts from triggering the portscan detection module. Boxes that generate legitimately generate traffic on a large number of ports in a short amount of time, including NFS or DNS servers are typical candidates. More on Patrick Mullen's portscan preprocessor can be found at . The portscan-ignorehosts preprocessor is used for this, and includes the hosts to ignore as its argument seperated by spaces: preprocessor portscan-ignorehosts: 63.87.101.90/32 63.87.101.92/32 You might consider trying it without the portscan-ignorehosts directive first, as you don't want to unnecessarily disable the ability to detect portscans if it's not necessary. The minfrag preprocessor checks for fragmented packets which can be used to disguise TCP packets from IP filters used in routers and hosts. Packets less than 512 bytes do not need to be fragmented with modern networks, and packets found smaller than that typically indicate attempts to subvert a firewall or intrusion detection. You should now be able to test your configuration file and the normal operation of snort: [root@krypton ~]# snort -d -l /var/log/snort -c /etc/snort/rules.base Initializing Network Interface... User level filter, protocol ALL, raw packet socket Decoding Ethernet on interface eth0 Initializing Preprocessors! ------------------------------------------------- Keyword | Preprocessor @ -------------------------------------------------http_decode : 0x8053070 minfrag : 0x8053290 portscan : 0x8053ce0 portscan-ignorehosts: 0x8054340 -------------------------------------------------InitializingPlug-ins! ------------------------------------------------- Keyword | Plugin Registered @ -------------------------------------------------content : 0x8052050 offset : 0x8052080 depth : 0x80520f0 nocase : 0x8052160 flags : 0x8052710 itype : 0x80528f0 icode : 0x8052a00 ttl : 0x8052b10 id : 0x8052bf0 ack : 0x8052cd0 seq : 0x8052dc0 dsize : 0x8052ec0 ipopts : 0x8054420 rpc : 0x8054670 icmp_id : 0x8054830 icmp_seq : 0x8054930 session : 0x8055300 -------------------------------------------------Initializating Output Plugins! ------------------------------------------------- Keyword | Output @ -------------------------------------------------alert_syslog : 0x8054a20 log_tcpdump : 0x8054ff0 ------------------------------------------------- +++++++++++++++++++++++++++++++++++++++++++++++++++ Initializing rule chains... 255 Snort rules read... 255 Option Chains linked into 140 Chain Headers +++++++++++++++++++++++++++++++++++++++++++++++++++ Performing Rule List Integrity Tests... ---------------------------------------Alert TCP Chains : OK Alert UDP Chains : OK Alert ICMP Chains : OK Log TCP Chains : Empty list... Log UDP Chains : Empty list... Log ICMP Chains : Empty list... Pass TCP Chains : Empty list... Pass UDP Chains : Empty list... Pass ICMP Chains : Empty list... --------------------------------------- -*> Snort! 192.168.200.189:32771 TCP TTL:42 TOS:0x0 ID:5410 ***F*P*U Seq: 0x0 Ack: 0x0 Win: 0x400 00 00 00 00 00 00 ...... The corresponding syslog entry looks like: Jun 18 00:48:31 krypton snort[8757]: MISC-Attempted Sun RPC high port access: 192.168.100.189:57554 -> 192.168.200.189:32771 Several perl scripts exist to process this information intoan HTML page which can be accessed periodically to determine what is occuring on the network. The snort2html is a perl script written by Dan Swan that does a nice job of producing useable information in HTML format. If you decide to save this in a directory accessable by a web server, be sure to apply the proper authentication mechanism to prevent outsiders viewing this file. It contains a great deal of helpful information to a potential intruder. It can be used as follows: [root@krypton ~]# /usr/bin/snort2html /var/log/auth.log This will produce an HTML file in /var/log/snort-log.html that is for use with the Max Vision ruleset and creates links to the CVE definition of each intrusion attempt. This version has been modified from the original to accept the filename from the command-line. You can edit this file to save the resulting HTML file in another location. Resources Lance Spitzner shows snort in action as he tracks an intruder and performs forensic analysis on the trails of the intruder. Fyodor has put together a document that describes the snort internals The snort download page includes pointers to source code, plugins to send snort output data directly to a database, the Win32 port, and the latest rulesets. The snort.org has a wealth of helpful information and documentation. Have questions or comments about this document? We'd love to discuss them with you- please leave a comment below! . Delve into Suricata, the advanced network threat detection framework. Configure triggers and observe network breaches in real-time.. Snort Detection, Network Monitoring, Intrusion Alerts, Open Source Solutions. . Brittany Day
Jan 14, 2022
•
102
intrusion detectionsecure communicationsnortComprehensive Guide to Secure Syslog-ng and Snort Integration for Logging
A Comprehensive Guide to Building Encrypted, Secure Remote Syslog-ng Servers with the Snort Intrusion Detection System . Introduction The precursor to this article, Creating Secure Remote Log Servers, was the first in a series of papers focused on walking readers through configuring and deploying secure remote log servers. This second paper in the series offers a much more robust alternative to first generation SYSLOG servers; providing a much more reliable remote logging facility that is effective for use within Honeynets ( ) and Intrusion Detection System deployments. Remote log servers can provide centralized logging capability for IDS' spread across large network environments. I have proposed this approach for centralized logging in large IDS deployments on government networks that typically consist of multiple CLASS A networks. What this paper hopes to accomplish is to walk its readers through building next generation secure remote log servers to use in any environment, more specifically those wanting to utilize this form of logging with the Snort Intrusion Detection System ( https://www.snort.org/ ). For those of you who follow my papers regularly, you know that my writing style is that of precise detail without any real expectations from its readers of intimate knowledge on how to configure and use the utilities I write about. This proves the same for this paper as well. I will walk you through installing and configuring the Snort IDS as well as downloading, installing, and configuring Syslog-ng (Syslog, Next Generation). I will detail how to configure Snort to log to syslog for alerts to be generated locally and remotely to the offsite Syslog-ng server over an encrypted SSL tunnel. This will be the most comprehensive paper available to the community; offering a step-by-step guide to configuring Secure Remote Log Servers and interaction with Intrusion Detection Systems. Preparing Your Systems Ok, the first thing you're going to want to do is setup both systems and identify which one willbe the (CLIENT); the Snort box running Syslog-ng that will send its logs to the (SERVER); the system that listens for incoming connections for logs from the Syslog-ng client. Let's lay out a few ground rules to set the foundation for this paper. I will be referring to each system accordingly as outlined above. The IP addresses for each system are: CLIENT 192.168.0.1 SERVER 192.168.0.2 The Client The first task we'll accomplish is downloading and configuring Syslog-ng for use as the client. Now if you remember, the client must be configured to send the Syslog alerts remotely to the other server. Syslog-ng stands for Syslog Next Generation. As the name implies, Syslog-ng was designed to meet higher standards of stability in logging as well as added security and encryption functionality. A unique feature of Syslog-ng is its capability to offer TCP logging, which all of you should hopefully already know is different from first generation SYSLOG as its predecessor utilizes UDP only. To download Syslog-ng hop over in your favorite lynx browser ;) to and download. As of this writing, the current version is 1.4.15. You will also need to download libol as the instructions imply. pa-obsd01# pwd /export/syslog-ng-1.4.14 pa-obsd01# ./configure && make && make install Alright, for some reason when I installed and configured Syslog-ng, it didn't create the /etc/syslog-ng directory, nor provide me any default configuration files. So for obvious reasons you won't have to worry about that because I'll be providing the configurations for you. Go ahead and mkdir the /etc/syslog-ng directory and untar Syslog-ng after installing libol. Once completed you should have a binary for syslog-ng in your /usr/local/sbin directory. The following configuration information should be stored as /etc/syslog-ng/syslog-ng.conf ################################################### # # This is a working Syslog-ng file for a Syslog-ng # CLIENTsystem only. # # Refer to the comments below for some of the # syntax being used. # File: /etc/syslog-ng/syslog-ng.conf # # Syslog-ng configuration file created by # Eric "Loki" Hines # Email: loki@fatelabs.com # # Syslog-ng is # Copyright (c) 1999 Balazs Scheidler # #################################################### # This identifies the source machine (gateway) and # gives it a name. You can name the identifier anything # you want, e.g. source barney.localhost # { unix-dgram("/dev/log"); internal(); }; or whatever you # want. Have fun, but make sure to remember what name # you give it for the log statement. source gateway { # If you are not using OpenBSD, you will need to change # this to your specific syslog device file. # The different options for each OS is provided at # https://www.oneidentity.com unix-dgram("/dev/log"); internal(); }; # What I've done here (thanks Jason Ish), is configured # Syslog-ng to log locally to our /var/log directory as well as # remotely to the remote Syslog-ng SERVER. This is an awesome # idea as it creates 2 locations for log files to eliminate # single points of failure. (Also an awesome idea with # honeynets, dig? J destination localhost { file("/var/log/syslog-ng.all"); }; destination shell { tcp("192.168.0.2" port(514)); }; # This ties our source and destination together, think of it # this way (src + dst = logging) log { source(gateway); destination(localhost); source(gateway); destination(shell); }; You should now have a working configuration file for the sylsog-ng client, let's go ahead and setup Snort for logging to the Syslog server. This will actually be more trivial than you might think. Go ahead and download Snort from https://www.snort.org/ . As of this writing, the current version is 1.8.6. If you are worried about the new fragroute IDS evasion tool and protectingagainst these types of attacks, currently, Snort offers a stable-snapshot release for download. The next release of Snort will evidently provide these enhancements, so choose your poison. Go ahead and untar Snort and let's walk through the configuration. 192.168.0.1 pa-obsd01# pwd /export/snort-1.8.6 pa-obsd01# ./configure && make && make install I feel kind of ridiculous pasting in those ./configure commands but some of you would be surprised with the kind of emails I get after writing a paper :D So that table is for some of you that don't yet know how to compile and install a program. Then again, if you already didn't know that I'd question your idea of building a secure remote log server at this early in the game ;) But we've all got to start somewhere right? Moving on. We're going to go ahead and make a quick modification to the Snort configuration file. # or you can specify the variable to be any IP address # like this: var HOME_NET 192.168.0.1 # Set up the external network addresses as well. # A good start may be "any" var EXTERNAL_NET any Lets go ahead and start up Snort to log to syslog. The Snort development team made this extremely simple for us. Because we've configured Syslog-ng to log remotely for us, Snort doesn't have to do ANYTHING but log locally to syslog. This is accomplished merely by using the following syntax 192.168.0.1 pa-obsd01# adduser Snort pa-obsd01# passwd Snort pa-obsd01# ./snort –D –A full –c snort.conf –d –D –e –u snort –g snort –s (Please don't run snort as root.) The other flags can be omitted without any problems, but making sure to leave the –s flag in tact as that is what enables Snort logging to Syslog. Upon initiation of Snort, our Syslog-ng will now be trapping those alerts and sending them over the wire to the remote Syslog-ng server. However, because it isn't yet configured those alerts will be lost,maybe I should have done this step last :D, hah, man I crack myself up. The Server Let's go ahead and configure the remote Syslog-ng server now for receipt of those alerts. For obvious reasons, go ahead and download Syslog-ng again for the server and run through the configure and make install again. After doing so, we'll go ahead and configure Syslog-ng to accept alerts from the Client. 192.168.0.2 source shell { unix-dgram("/dev/log"); internal(); # Listen on public interface, port 514 for incoming connections tcp(ip(192.168.0.2) port(514) max-connections(1)); }; destination localhost { file("/var/log/syslog-ng.all")); }; # Again, we tie both statements together with the log function. log { source(shell); destination(localhost); }; To start up Syslog-ng we'll go ahead and execute /usr/local/sbin/syslog-ng. Oh, go ahead and start up Syslog-ng on the CLIENT as well. You should now be successfully logging Snort alerts from the remote system as demonstrated below. 192.168.0.2 pa-obsd01# tail –f /var/log/syslog-ng.all May 14 02:37:18 localhost/localhost/192.168.0.1 Snort: [1:1002:4] WEB-IIS cmd.exe access [Classification: Web Application Attack] [Priority: 1]: {TCP} 192.168.0.2:3434 -> 192.168.0.1:80 May 14 02:37:19 localhost/localhost/192.168.0.1 Snort: [1:1002:4] WEB-IIS cmd.exe access [Classification: Web Application Attack] [Priority: 1]: {TCP} 192.168.0.2:3458 -> 192.168.0.1:80 May 14 02:37:19 localhost/localhost/192.168.0.1 Snort: [1:1002:4] WEB-IIS cmd.exe access [Classification: Web Application Attack] [Priority: 1]: {TCP} 192.168.0.2:3474 -> 192.168.0.1:80 May 14 02:37:20 localhost/localhost/192.168.0.1 Snort: [1:1002:4] WEB-IIS cmd.exe access [Classification: Web Application Attack] [Priority: 1]: {TCP} 192.168.0.2:3496 -> 192.168.0.1:80 May 14 02:37:20 localhost/localhost/192.168.0.1 Snort: [1:1002:4] WEB-IIS cmd.exe access[Classification: Web Application Attack] [Priority: 1]: {TCP} 192.168.0.2:3515 -> 192.168.0.1:80 May 14 02:37:20 localhost/localhost/192.168.0.1 Snort: [1:1002:4] WEB-IIS cmd.exe access Priority: 1]: {TCP} 192.168.0.2:3547 -> 192.168.0.1:80 May 14 02:37:21 localhost/localhost/192.168.0.1 Snort: [102:7:1] (spp_http_decode) Overlong Unicode character received {TCP} 192.168.0.2:3565 -> 192.168.0.1:80 May 14 02:37:21 localhost/localhost/192.168.0.1 Snort: [1:1002:4] WEB-IIS cmd.exe access [Classification: Web Application Attack] [Priority: 1]: {TCP} 192.168.0.2:3565 -> 192.168.0.1:80 May 14 02:37:21 localhost/localhost/192.168.0.1 Snort: [102:7:1] (spp_http_decode) Overlong Unicode character received {TCP} 192.168.0.2:3585 -> 192.168.0.1:80 The Firewall Now we will want to install a firewall on the remote Syslog-ng server. This will allow us to specify what systems are and are not allowed to connect to our system as well as specify an ACL for what IP's are allowed to log to our Syslog port. We will be accomplishing this through a simple PF (Packet Filter) config file. I have provided mine below. For you other users of IPF, the syntax should work the same. 192.168.0.2 #### #### SET VARIABLES. CHANGE THIS TO YOUR NIC INTERFACE ID #### ifconfig -a EXT="de0" #### #### BLOCK IN ALL RFC 1918 #### block in quick on $EXT inet from 192.168.0.0/16 to any block in quick on $EXT inet from 172.16.0.0/12 to any block in quick on $EXT inet from 10.0.0.0/8 to any block out quick on $EXT inet from any to 192.168.0.0/16 block out quick on $EXT inet from any to 172.16.0.0/12 block out quick on $EXT inet from any to 10.0.0.0/8 #### #### EXPLICITY ALLOW ONLY 192.168.0.1 TO PORT 514 (syslog-ng) #### IF YOU USE THIS FIREWALL CONFIG FOR STUNNEL, CHANGE IT TO #### THE INCOMING STUNNEL PORT WE SET, 5140 pass in quick on $EXT inet proto tcp from { 192.168.0.1/32 } to any port = 514 #### ####EXPLICITY BLOCK ALL OTHER TRAFFIC AND LOG #### ALLOW ALL OUTGOING #### block in log quick on $EXT from any to any pass out quick on $EXT from any to any keep state Stunnel I have decided to break this paper up into (2) two sections. The following section and configuration files for Syslog-ng will only be for those of you who want to encrypt the syslog data over SSL. For those of you who have your own ways of handling the encryption (vpn, etc), feel free to ignore this section and only use the configuration files provided previously. Client Your first task, should you choose to accept it, is to download and configure Stunnel J. You can download Stunnel from . Now, for some reason I keep getting the same compile errors when compiling on OpenBSD 3.0. So for those of you who are experiencing the same problems, simply install stunnel from ports, RPM, or whatever alternative or binary distribution your platform offers. I did in fact install from ports, so aside from the ./configure and make install, I think all of you can pretty much handle this on your own. After the installation has completed, you will want to configure Syslog-ng to log to LOCALHOST to a port where Stunnel will be awaiting connections. Stunnel will then be the carrier of the data over to the SERVER where another Stunnel daemon will be waiting for connections. Use the following configuration file for Syslog-ng located in /etc/syslog-ng/syslog-ng.conf 192.168.0.1 ########################################################################## # # This is a working Syslog-ng file for a Syslog-ng CLIENT system using # STUNNEL only. # Refer to the comments below for some of the syntax being used. # File: /etc/syslog-ng/syslog-ng.conf # # Syslog-ng configuration file created by Eric "Loki" Hines # Email:
May 29, 2002
•
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Search Topics
Powered By
Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases
QUICK LINKS
subscribe to newsletters!
Like staying secure? So do we.
Sign up for updates, tips, and alerts!
Discover faster search, smarter navigation, and deeper Linux security insights. Read More