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

In this guide, you will learn how to install Snort on Ubuntu, create a custom rate-limiting rule to monitor SSH activity, and use alerts to identify potential brute-force attacks on a dedicated server.

Introduction

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:

Bash

sudo apt update && sudo apt upgrade -y

Step 1: Install Snort

Install Snort directly from the standard Ubuntu repositories:

Bash

sudo apt install snort -y

⚠️

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

Bash

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:.

Bash

ip addr

eth0
ens3
ens18

Make a note of the interface connected to the public network..

Step 3: Configure Snort

Open the main Snort configuration file:

Bash

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:

Plaintext

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):

Bash

sudo mkdir -p /etc/snort/rules

Open the local rules file to add your custom alert:

Bash

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:

Plaintext

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:

Bash

sudo nano /etc/snort/snort.conf

Plaintext

include $RULE_PATH/local.rules

Validate the configuration to ensure there are no syntax errors:

Bash

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:

Bash

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

⚠️

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

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:

Bash

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:

Plaintext

[**] [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.

📚 Read Next: Security Related Guides & Tutorials

FAQ

Is Snort pre-installed on Servers99 dedicated servers?

Snort is not installed by default on all Servers99 dedicated servers. However, depending on the customer's requirements and deployment specifications, pre-installation and basic configuration may be available during server deployment. Conditions may apply based on the selected server configuration and service scope.

Do Servers99 servers include DDoS protection?

Yes. All Servers99 dedicated servers include DDoS protection with mitigation capabilities of up to 250 Gbps. Dedicated DDoS-protected server solutions are also available for customers who require enhanced protection against large-scale attacks.

What is Snort used for?

Snort is an open-source intrusion detection system (IDS) that monitors network traffic and generates alerts when suspicious activity, unauthorized access attempts, or potential attacks are detected.

Can Snort prevent attacks automatically?

By default, Snort primarily functions as an intrusion detection system. It can identify and alert administrators about suspicious activity, while additional security tools such as firewalls and Fail2Ban can be used to automatically block threats.

Does Snort affect server performance?

Snort consumes system resources to inspect network traffic. On properly configured dedicated servers, the impact is generally minimal, although resource usage may increase depending on traffic volume and the number of active detection rules.