How to block SSH brute force attacks with UFW

Why your SSH server is a constant target on the internet

As soon as a server connected to the internet gets a public IP address, automated bots scattered around the world start testing connections on the default remote access port. This port, usually 22, receives hundreds or even thousands of login attempts per minute based on common combinations of usernames and passwords. In practice, this means leaving access open without extra protection is the digital equivalent of leaving a front door unlocked on a busy street. To mitigate this risk without immediately turning to complex solutions, we can apply a combined strategy of packet filtering and network monitoring.

Before implementing any blocks, it is worth understanding how network traffic reaches your operating system. Network traffic is simply a continuous flow of data packets that must be accepted, rejected, or ignored by the system kernel rules. As we saw in previous articles about how to configure UFW firewall rules on Ubuntu Linux, strict control over these entry ports is the first line of defense against unauthorized access. However, modern brute force attacks go beyond simple scans and require refined security policies applied by the administrator.

How to prepare UFW to stop repeated access attempts

UFW, short for Uncomplicated Firewall, works as a simplified layer over iptables, which is the native Linux packet control tool. Instead of writing cryptic rules with complex parameters, UFW allows the operator to define clear policies using direct, easy-to-audit commands. Before creating advanced restrictions for the remote access service, we need to ensure the firewall is active and configured with a restrictive default policy, blocking everything not explicitly allowed.

To impose smart connection limits without hurting legitimate access from administrators, we can use UFW's rate-limiting module. This mechanism restricts the number of connection attempts coming from the same IP address within a specific time window. In practice, if an address tries to open an SSH connection more than six times in a thirty-second interval, the firewall automatically rejects new packets from that IP. This simple approach is extremely effective against common automated scripts on the internet because they quickly give up once they notice the service stops responding.

Configuring the rate-limiting rule step by step

The practical application of this defense requires just a few commands executed directly in the server terminal with administrative privileges. It is crucial to remember that before applying any severe restrictions to the remote port, you must ensure you have alternative access or that your current rule will not lock you out of the machine. Follow the steps below to implement rate-limiting protection in your environment:

1. Check if the firewall is active on the system by running the detailed status command:

   sudo ufw status verbose

2. Add the limit rule for the SSH port, ensuring excessive attempts are blocked:

   sudo ufw limit OpenSSH

3. Reload the firewall settings to apply the changes immediately:

   sudo ufw reload

After running these commands, any excessive connection attempt will be strictly handled by the filtering system. If you need to monitor the behavior of these connections in real time for auditing purposes or to convert logs and analyze events, the operating system keeps detailed records of every rejected packet. Cross-referencing this information with firewall behavior guarantees complete visibility over who is trying to breach your remote environment.

Monitoring system logs for security auditing

Keeping the firewall enabled is only half the protection job; the other half consists of actively monitoring what happens behind the scenes of the infrastructure. The operating system records authentication events and network blocks in dedicated files within the log directory, allowing the administrator to spot recurring attack patterns. When we combine the inspection of these records with an alerting policy or dynamic blocking, we turn a static defense into a resilient security mechanism.

On production servers, it is advisable to periodically review these log files to check for persistent IP addresses trying to bypass configured barriers. If you identify a continuous malicious actor managing to bypass basic limits, you can manually block them permanently with a direct command in the firewall. This monitoring routine ensures the server remains protected against novel intrusion tactics, preserving data integrity and hosted service stability. To explore these architectural concepts further in production, see our related technical analysis on How to test power supply input fuse with a multimeter.

Final considerations on protecting remote servers

Securing remote access to a Linux server requires a balanced combination of best practices, efficient native tools, and continuous network behavior monitoring. Using UFW combined with rate limiting offers a robust, low-cost barrier against the vast majority of automated attacks roaming the internet daily. By understanding how data packets interact with the system kernel and how to audit these events, you significantly raise your infrastructure's security maturity level.

Keep in mind that information security is a continuous process rather than a final state. Keeping system packages updated, using cryptographic keys instead of traditional passwords, and regularly reviewing network rules are indispensable habits for any technology operator. With these guidelines implemented, your server will be much better prepared to face threats and ensure continuous availability of essential services.