DEV Community: Nyra Amsi

How to Use Snort on Ubuntu Dedicated Servers to Detect SSH Brute-Force Attacks

Nyra Amsi — Fri, 03 Jul 2026 10:56:22 +0000

SSH brute-force attacks are among the most common threats targeting Linux dedicated servers. Attackers use automated tools to repeatedly attempt username and password combinations in an effort to gain unauthorized access. Even when login attempts fail, excessive authentication requests can clutter logs, consume resources, and make it harder to identify legitimate security events.

While traditional firewalls can block unwanted traffic, they often do not provide detailed visibility into suspicious connection patterns. This is where Snort can help.

⚠️ Note: This guide uses Snort 2 from the official Ubuntu repositories for a quick, beginner-friendly setup. For Snort 3, a manual source compilation is required.

The Problem
Consider a dedicated server that exposes SSH on port 22 for remote administration. Over time, the server may receive:

Automated login attempts from unknown IP addresses
Credential stuffing attacks
Bot-driven password guessing campaigns
Large volumes of connection attempts from multiple sources

Although SSH logs record these events, manually reviewing log files can be time-consuming, especially on busy servers. A network intrusion detection system such as Snort can monitor traffic in real-time and generate alerts whenever suspicious SSH activity is detected.

Prerequisites

Before starting, ensure you have:

Ubuntu 24.04 LTS
Root or sudo access
A dedicated server with SSH enabled
Internet connectivity for package installation

Update the system first:

sudo apt update && sudo apt upgrade -y

Step 1: Install Snort

Install Snort directly from the standard Ubuntu repositories:

sudo apt install snort -y

⚠️ Note: During installation, you may be prompted to enter your network interface and IP range.

Verify the installation:

snort -V

You should see version information confirming that Snort (version 2.9.x) is installed successfully.

Step 2: Identify Your Network Interface

List your available network interfaces:

ip addr

You will see output containing names like eth0, ens3, or ens18. Make a note of the interface connected to the public network.

Step 3: Configure Snort

Open the main Snort configuration file:

sudo nano /etc/snort/snort.conf

Locate the network variable section. Look for ipvar HOME_NET and set it to your server's IP subnet, or for broad monitoring:

ipvar HOME_NET any

Save the file and exit the editor.

Step 4: Create a Local Rule File

Ensure the rules directory exists (it usually does by default):

sudo mkdir -p /etc/snort/rules

Open the local rules file to add your custom alert:

sudo nano /etc/snort/rules/local.rules

Step 5: Create a Brute-Force Detection Rule
To accurately detect a brute-force attack (and avoid flooding your logs with normal SSH logins), we need to use a threshold (or detection filter). This tells Snort to only trigger an alert if a single IP address makes too many connection attempts within a short timeframe.

Add the following rule:

alert tcp any any -> $HOME_NET 22 (msg:"Possible SSH Brute Force Attack Detected"; flags:S; detection_filter:track by_src, count 5, seconds 60; sid:1000001; rev:1;)

How this rule works:

flags:S; looks for the initial connection attempt (SYN packet).
detection_filter:track by_src, count 5, seconds 60; ensures an alert is ONLY generated if the same source IP attempts to connect more than 5 times within 60 seconds.

Save the file.

Step 6: Load the Rule

Ensure Snort knows to look at your local rules. Open the configuration file again:

sudo nano /etc/snort/snort.conf

Add or ensure this line is uncommented:

include $RULE_PATH/local.rules

Validate the configuration to ensure there are no syntax errors:

sudo snort -T -c /etc/snort/snort.conf

A successful validation output indicates that Snort can load the rule correctly.

Step 7: Start Snort

Run Snort in alerting mode. Replace eth0 with your actual network interface noted in Step 2:

sudo snort -i eth0 -c /etc/snort/snort.conf -A console

⚠️ Note: Using -A console will print alerts directly to your screen. For background logging in production, use -A fast.

Step 8: Generate Test Traffic

From another system, initiate multiple SSH connections rapidly to trigger the threshold:

for i in {1..6}; do ssh -o ConnectTimeout=1 user@server-ip; done

Snort will detect the rapid connection attempts and output an alert:

[**] [1:1000001:1] Possible SSH Brute Force Attack Detected [**]

Understanding the Results
By using a detection filter, your alerts will specifically highlight high-frequency connection attempts rather than normal administrator logins. Not every alert represents a successful compromise, but it provides visibility into aggressive automated bot activity.

Reducing False Positives

To improve server security:

Restrict SSH access to trusted IP addresses only.
Change SSH to key-based authentication and disable password logins.
Adjust the count and seconds in your Snort rule based on your server's normal traffic baseline.

Why Snort Is Useful on Dedicated Servers

Dedicated servers often host websites, APIs, databases, and remote management services that are continuously exposed to the internet. Snort provides:

Real-time network monitoring
Intrusion detection capabilities
Custom alert rules with rate-limiting
Unmatched traffic visibility

By identifying brute-force attempts early, administrators can investigate and respond before minor events develop into larger security incidents.

Conclusion

Monitoring SSH traffic with Snort adds a critical layer of visibility for Ubuntu dedicated servers. Instead of relying solely on standard logs, administrators gain real-time insights into aggressive network behavior.

This proactive approach becomes especially important for servers running public-facing services, where continuous exposure to automated scanning is common. Robust network monitoring is highly suitable for enterprise-grade dedicated server setups, ensuring stable performance and secure deployments.

A layered security approach is always recommended, including:

A properly configured firewall (UFW or equivalent)
Strong SSH authentication using key-based access
Intrusion detection tools such as Snort
Automated protection tools like Fail2Ban
Regular system and package updates

When these components are implemented together, the server becomes significantly more resilient against common network-based attacks while maintaining full control and visibility for administrators.

Dedicated Server Security Checklist: Complete Linux Server Hardening

Nyra Amsi — Sat, 20 Jun 2026 09:00:04 +0000

When a Linux dedicated server receives a public IP address, it immediately becomes visible to internet-wide scanners and automated attack bots.

Many administrators focus on performance optimization, but security fundamentals are often overlooked until an incident occurs.

A secure production environment requires multiple layers of defense, including:

SSH hardening and key-based authentication
Multi-factor authentication (MFA)
Firewall configuration and access control
Intrusion prevention with CrowdSec and Fail2Ban
Runtime threat detection using eBPF technologies
Web Application Firewalls (WAF)
File integrity monitoring
Kernel hardening
Backup and disaster recovery planning

One important point often missed by server administrators is that moving SSH to a non-standard port is not a security control. While it may reduce automated log noise, strong authentication and access restrictions remain the real protection mechanisms.

Modern Linux security is also shifting toward kernel-level observability with tools such as Falco, Tetragon, and Tracee, providing deeper visibility into suspicious activity with minimal overhead.

Servers99 recently created a comprehensive guide covering these topics in detail, including practical recommendations for Ubuntu, AlmaLinux, and other Linux server environments.

Read the full guide: Dedicated Server Security Checklist: Complete Linux Server Hardening Guide

What security control do you consider absolutely mandatory on every production Linux server?

Why a Clean CI/CD Scan Isn't Enough: The Kubernetes Runtime Blind Spot

Nyra Amsi — Thu, 18 Jun 2026 07:48:37 +0000

If your container passes a CI/CD vulnerability scan, is it safe to run in production? Many engineering teams assume the answer is yes. But a clean image scan is just a green light to deploy—it is not a lifetime guarantee.

Pre-deployment gates like static configuration checks and vulnerability scanning are entirely predictive. They are great for catching known risks (published CVEs) before your code goes live. However, they leave a massive blind spot once the container is actively running.

A static scan cannot protect you from:

Zero-day exploits
Configuration drift and memory injections
Compromised third-party dependencies executing malicious behavior at runtime
Insider threats leveraging legitimate system tools to move laterally

Static security stops at the deployment line. True Zero-Trust requires active surveillance of your live environment.

The Shift to Kernel-Level Security with eBPF

Instead of relying on easily bypassed user-space tools, the industry is shifting toward kernel-level security using eBPF (Extended Berkeley Packet Filter) and Cilium Tetragon.

By moving security monitoring directly into the Linux kernel, infrastructure teams can correlate process execution with network activity in real-time. For example, if a routine nginx binary suddenly spawns a bash shell to run curl, eBPF detects this at the system-call level and instantly terminates the process via SIGKILL before the payload even executes.

Dive Deeper into K8s Runtime Security

We have put together a comprehensive architectural breakdown on the modern Kubernetes threat model and how to implement active runtime enforcement.

In our full guide, we cover:

The 5 primary attack vectors inside a K8s cluster (including DNS Tunneling).
How eBPF sensors (kprobes, tracepoints) provide deep visibility without performance latency.
How to write and deploy Tetragon TracingPolicy rules.
Achieving PCI-DSS (File Integrity Monitoring) and SOC 2 compliance using kernel-native visibility.

👉 Read the Full Architectural Breakdown and Interactive Guide Here

💻 Windows vs Linux Dedicated Server: A Technical Breakdown for 2026

Nyra Amsi — Fri, 24 Apr 2026 08:29:40 +0000

Hey everyone! 👋

If you are upgrading your backend infrastructure or moving away from shared hosting, choosing between a Windows and Linux dedicated server is one of the most critical decisions you'll make. It dictates your licensing costs, administrative overhead, security posture, and application compatibility for years.

I recently did a deep dive into this, and instead of biased opinions, I wanted to share some raw technical facts and benchmarks that can help you choose the right bare-metal infrastructure.

⚡ The Quick Verdict

Go with Linux if you need raw performance, zero licensing fees, containerization (Docker/Kubernetes), and native support for PHP, Python, or open-source stacks.
Go with Windows if your operations rely on ASP.NET, Microsoft SQL Server, Active Directory, or if your team requires a familiar graphical user interface (GUI) for server management.

🐧 Linux: Performance and Flexibility

Linux is open-source and renowned for its lightweight kernel architecture. Since it doesn't need a GUI to run, practically 100% of the server's computing power goes straight to your applications.

Why developers love it:

Zero Licensing Costs: Distros like Ubuntu, Debian, and AlmaLinux are free. You avoid per-core licensing fees.
Superior Resource Efficiency: Benchmarks show Linux can process up to 3x more web requests per gigabyte of RAM compared to GUI-heavy alternatives.
The Web Standard: It is the absolute standard for LAMP/LEMP stacks, WordPress, Node.js, and Python frameworks.

The Catch: It is heavily CLI-driven. If your sysadmins aren't comfortable with Bash or SSH, the learning curve is real.

🪟 Windows: Enterprise Integration

Built on the Windows NT kernel, a Windows server is designed for deep integration with Microsoft’s enterprise ecosystem. It provides a familiar GUI via Remote Desktop Protocol (RDP).

Why enterprises choose it:

Native Microsoft Compatibility: If you are running legacy ASP.NET or MSSQL, Windows is the only logical choice. MSSQL runs with deep kernel-level tuning here.
Active Directory: Unmatched for enterprise identity management across massive organizational networks.
Ease of Management: The visual Server Manager makes deploying roles (like IIS or Hyper-V) point-and-click easy.

The Catch: Licensing fees (around $40+ extra depending on the provider) and the GUI consumes baseline RAM and CPU.

🤔 How to Choose?

Don't just pick what's "popular." Ask yourself:

What is your stack? (Docker/K8s = Linux | Exchange/SharePoint = Windows)
What are your team's skills? (Bash/Ansible = Linux | PowerShell/Dashboards = Windows)
What is your budget? (Max hardware for the price = Linux | Need SLA-backed OS support = Windows)

Ultimately, it’s all about reducing operational friction for your specific use case.

What is your go-to OS for bare-metal servers? Let me know in the comments! 👇