Brute-force attacks are among the most common threats against internet-facing servers. They are usually automated, persistent and inexpensive to run. An attacker does not need to know much about a business before testing an SSH daemon, RDP endpoint, control panel, database or remote administration interface with thousands of stolen or guessed credentials.
Many attempts fail and create little immediate risk. The danger is that one succeeds, particularly when a password has been reused, an old account remains active or a service is exposed without multi-factor authentication. Repeated login failures should therefore be treated as useful security telemetry, not just background internet noise.
This guide covers how to recognise server brute-force attacks, which controls reduce them, where blocking strategies can fail and what to do when an attacker gets in.
What a server brute-force attack looks like
A brute-force attack is an attempt to gain access by trying many passwords, usernames or credential combinations. Modern campaigns often use credential stuffing rather than random guesses: the attacker tests username and password pairs collected from previous breaches. Password spraying takes a different approach by trying one common password against many accounts, helping the attacker avoid per-account lockouts.
SSH and RDP are frequent targets because they provide direct administrative access. Other exposed services can be just as important:
- Web hosting and server control panels
- VPN gateways and remote access portals
- Mail administration and webmail interfaces
- Database listeners such as MySQL, PostgreSQL or Microsoft SQL Server
- Application login pages and API endpoints
- Virtualisation, backup and monitoring consoles
The activity may come from one address, a rotating list of cloud servers or a broad IP range. A distributed attack can produce only a few attempts per address while generating a large number of failures overall. That is why looking at a single firewall rule or one server log is often insufficient.
How to detect automated login attempts
Start with authentication logs
Authentication logs are the first place to look. On Linux, SSH events commonly appear in the system journal or authentication log. Windows administrators should review RDP and other relevant events in Event Viewer or a central Windows logging platform. Control panels, VPN products and databases generally maintain their own audit logs.
Look for patterns rather than isolated events:
- Dozens or hundreds of failed logins within a short period
- Attempts against many usernames, including names that do not exist
- Repeated attempts against privileged accounts such as root, administrator or service accounts
- Connections arriving at regular intervals from changing addresses
- Successful authentication immediately after a long sequence of failures
- Logins at unusual times, from unusual countries or through unfamiliar networks
- New accounts, changed passwords, modified SSH keys or altered group membership
A single failed login is not an incident. A pattern of failures across several systems, especially when followed by a success, deserves investigation. Teams evaluating detection and blocking tools can compare approaches using these server brute-force detection and Fail2ban resources, but should validate any tool in their own environment before deploying automatic bans.
Use alerting and traffic signals
Log collection is useful only if someone or something reviews it. Alerts can be based on thresholds, such as ten failed SSH logins in five minutes, but threshold-only rules can miss slow password spraying. Better monitoring combines authentication events with source addresses, usernames, geolocation, asset criticality and successful logins.
Network telemetry can add context. Watch for a sudden increase in connection attempts to management ports, repeated TCP handshakes that never complete, scans across several services or unusual outbound traffic after a suspicious login. A compromised server may begin making connections to command-and-control infrastructure, scanning internal systems or transferring data.
Centralised monitoring is especially important for agencies managing several customer environments. A single dashboard or security information and event management platform makes it easier to spot the same IP range, username pattern or password-spraying campaign across multiple servers. Alerts should reach a person who can act, with enough detail to avoid forcing responders to search through raw logs during an incident.
Hardening SSH and other exposed services
Use strong authentication
Where practical, disable SSH password authentication and require individual cryptographic keys. Each administrator should have a separate account and key, with privileged access obtained through controlled elevation rather than shared root credentials. Protect private keys with passphrases and store them securely. Remove keys promptly when a staff member or supplier no longer needs access.
For RDP, VPNs and control panels, use MFA wherever the product supports it. Prefer phishing-resistant methods when available, particularly for administrator accounts. MFA does not make a vulnerable service harmless, but it significantly reduces the value of a stolen password.
Password policies still matter for services that require passwords. Use long, unique credentials, a password manager and separate accounts for administration, applications and databases. Never leave vendor defaults in place. Disable inactive accounts and review service accounts for unnecessary interactive access.
Reduce exposure
The safest management interface is one that is not publicly reachable. Restrict SSH, RDP and database access to a VPN, private network, bastion host or defined administrator IP ranges where operationally possible. A database listener generally has no reason to accept connections from the public internet.
Changing the default SSH port may reduce opportunistic scanning, but it is not a security control by itself. Attackers can discover non-standard ports quickly. Treat it as noise reduction, not protection. The stronger controls are network restriction, modern authentication, patching and monitoring.
Apply security updates to operating systems, control panels, VPNs and applications. Remove services that are no longer required and check that administrative interfaces are not accidentally exposed after migrations or firewall changes. Harden the host according to a documented baseline, then review it periodically rather than assuming a one-time configuration remains correct.
Blocking and rate-limiting techniques
Firewalls and provider-level filtering
Host firewalls can restrict management ports, limit source networks and reject traffic before it reaches the application. Network firewalls or provider-level filtering can absorb or discard unwanted traffic earlier, which is helpful when an attack generates enough connections to consume server resources.
Provider-level controls are not a substitute for secure accounts. They may also be less precise than application-aware controls, particularly when many legitimate customers share an address range. Establish approved administrator networks and maintain an emergency access path, so a mistaken rule does not lock out the people responsible for fixing it.
Fail2ban-style blocking
Tools such as Fail2ban watch logs and add temporary firewall rules after a defined number of failures. They are practical for SSH and other services with consistent log formats. A ban period, failure threshold and ignored address list should be chosen from observed behaviour rather than copied without review.
Temporary bans usually provide better balance than permanent blocks. They slow repeated attempts, reduce log noise and give administrators time to react without creating an ever-growing denylist. Make sure the monitoring tool itself survives log rotation, service restarts and changes to the authentication system.
Rate limiting and account controls
Rate limiting can be implemented at a reverse proxy, firewall, application or identity provider. It is particularly useful for web login pages and APIs, where a service may need to remain publicly available. Progressive delays, CAPTCHA challenges and risk-based MFA can reduce automation without denying every user access after one mistake.
Account lockouts require more care. A strict lockout can stop guessing against one account, but an attacker can deliberately lock out every employee in a password-spraying campaign. Prefer short, progressive lockouts or throttling, and create a tested administrative recovery process. Never rely on a lockout policy as the only defence for a privileged account.
Trade-offs and common blind spots
IP blocking is easy to understand but has limits. Addresses may be shared by offices, mobile networks, cloud platforms or carrier-grade NAT. Blocking an entire range can affect legitimate users, while blocking individual addresses may have little effect against a distributed campaign. Geolocation rules can also create false positives for travelling staff and remote suppliers.
False positives are more than an inconvenience. A blocked monitoring system, backup operator or emergency administrator can delay recovery. Keep an allowlist for trusted management paths where appropriate, but protect it carefully and review it regularly. Do not allowlist a broad dynamic range merely because it was once associated with a legitimate user.
Distributed attacks require identity-focused controls. If the same account is targeted from many networks, source blocking will not solve the problem. Strong MFA, unique credentials, disabled password authentication and centralised detection are more durable responses. Look for patterns by username, device, application and timing as well as by IP address.
How to investigate a suspected attack
Begin by preserving evidence. Record the affected host, time zone, relevant log entries, source addresses, targeted accounts and any automatic blocks already applied. Export logs before they are overwritten. Avoid restarting or cleaning the server prematurely if there is a realistic possibility of compromise; volatile evidence and active connections may be important.
Next, determine whether the activity was unsuccessful or whether an account was used. Search for successful logins near the failed attempts and verify the source, authentication method and time. Then check for:
- New local or domain accounts and unexpected group membership
- New SSH authorised keys, scheduled tasks, cron jobs or startup entries
- Changes to firewall rules, remote access settings or security policies
- Unexpected processes, listening ports and outbound connections
- Modified web files, binaries, scripts and configuration files
- Unusual data access, downloads, uploads or privilege escalation
Compare the host with a known-good configuration or build standard. Review identity-provider, VPN, firewall, endpoint and cloud logs as well as the server itself. Rotate credentials and revoke sessions when there is any reasonable suspicion that they were exposed. If the system handles regulated data, customer information or critical operations, follow the organisation's incident process and consider legal, regulatory and contractual notification requirements.
Blocking an attempt is not responding to compromise
A firewall rule or Fail2ban ban addresses an observed connection. It does not remove an attacker who has already authenticated. A successful login changes the situation from nuisance traffic to a potential security incident.
When compromise is suspected, isolate the server from the network while preserving necessary evidence and maintaining a controlled management route. Do not simply delete a suspicious account and put the host back online. An attacker may have created persistence, stolen credentials or changed binaries. The safer response is to identify the scope, rebuild from a trusted source when appropriate, patch the original weakness, rotate secrets and monitor restored services closely.
Recovery also depends on having clean, usable backups. Backups should be isolated from the server's normal credentials and management plane, because an attacker with administrator access may try to delete or encrypt them. Safenix provides off-site backup for business servers controlled by the customer. Data is encrypted using a key that Safenix never holds, stored in Germany and kept immutable for the length of the selected retention window. This is a recovery control, not a replacement for hardening or incident response: the customer remains responsible for controlling the protected server and deciding how to restore it.
VPS, dedicated and shared-hosting environments
The controls available to you depend heavily on who controls the operating system and network boundary. A customer-managed VPS normally provides access to the operating system, firewall and service configuration. That allows an administrator to enforce SSH keys, disable password login, install host monitoring and restrict management traffic, subject to the provider's platform limits.
A dedicated server usually offers more direct control over the host, network design and workload separation, although the exact responsibilities still depend on the contract and management model. A managed server may limit some changes while providing operational support. Document that division of responsibility before an incident occurs.
Shared hosting is different. The provider controls the host, operating system, web server configuration and the security boundary between customers. Customers may be able to change application settings, but they generally cannot install Fail2ban, alter host firewall rules, disable SSH for the platform or inspect all authentication logs. Guidance about security controls in customer-managed VPS infrastructure compared with shared hosting should therefore be read in the context of the access actually provided.
Safenix protects servers the customer controls. It does not sell a backup plan for a website running on shared hosting, and a shared-hosting site should not be presented as if it were covered by a Safenix server backup service. For shared hosting, the customer needs to use the host's available backup and export options, or move the workload to infrastructure where the organisation has the required control.
A practical operating routine
Brute-force defence works best as an operating routine rather than a single setting. At minimum, review exposed services and privileged accounts on a regular schedule. Test alerts with authorised simulations, confirm that bans expire as intended and verify that administrators can still reach an emergency access path.
- Maintain an inventory of internet-facing services, owners and approved management networks.
- Review failed and successful authentication trends, not just the latest alert.
- Use SSH keys, MFA, unique accounts and least privilege for administration.
- Patch operating systems and exposed applications, and remove unnecessary services.
- Centralise logs and make alerts actionable for the team responsible for response.
- Test backup restoration and confirm that recovery data is isolated from server credentials.
- Document escalation contacts, evidence-preservation steps and rebuild procedures.
Automated attacks will continue to probe exposed services, but they do not need to become a crisis. Reduce exposure first, make authentication difficult to abuse, use blocking as a measured layer and monitor for the signs that an attempt became a successful login. When the boundary is crossed, move from blocking to incident response and recovery without delay.