Day: March 2, 2026
Approaches to Server Security: Stop Thinking Like It’s 2010
Server Security / March 2026
The patterns showing up in server logs over recent months suggest that the attack surface has shifted in some fairly predictable ways. A few straightforward measures appear to address the bulk of it.
The Pattern in the Logs: Digital Ocean
Anyone running a public-facing server and watching their /var/log/auth.log or fail2ban output will likely notice something consistent: a notable proportion of brute force and port scanning activity appears to originate from Digital Ocean IP ranges.
This is not particularly surprising. A low-cost VPS can be provisioned in seconds, carries a clean IP not yet on most blocklists, and can be destroyed without a trace once a campaign is complete. It would appear this has become a fairly common setup for automated credential testing.
This is not a criticism of Digital Ocean specifically. The same pattern appears across AWS, Vultr, Linode and others. It is simply where the activity seems most concentrated at present, based on log observation.
Once you can identify where the traffic is coming from, blocking it at the network level before it reaches your services is relatively straightforward.
Watching the Logs and Blocking at Range Level
Blocking individual IPs as they appear is largely ineffective since the same underlying infrastructure will simply rotate addresses. Watching for patterns across a few days and then blocking the entire subnet tends to be considerably more efficient.
Step 1: Extract the Top Attacking IPs
Run this over several days. The same /16 or /24 ranges will tend to reappear. That is the signal to act on.
Step 2: Find the Full CIDR Range
Step 3: Block the Entire Range
Rather than managing individual IPs, the script below blocks all known Digital Ocean IPv4 ranges in a single pass. Save it as block-digitalocean.sh and run as root. It skips ranges already blocked, detects your OS, and persists the rules across reboots on Debian, Ubuntu, AlmaLinux, and RHEL.
The Script: block-digitalocean.sh
1Avoid Predictable Usernames
Every automated credential campaign works from roughly the same list: admin, administrator, root, user, test. If your system account appears on that list, a significant portion of the work has already been done before any real effort is made.
The less obvious improvement is to move away from English usernames entirely. Credential wordlists are almost exclusively English-centric. A username like gweinyddwr (Welsh), rendszergazda (Hungarian), or järjestelmänvalvoja (Finnish) simply will not appear in any standard dictionary attack.
2A Practical Approach to Password Entropy
Take a memorable word, run it through an MD5 hash, and use a portion of the output as the password. The result is genuinely high-entropy, looks entirely random to anyone who does not know the source word, and can be regenerated at any time without ever being written down.
No dictionary-based attack will arrive at 6f6c60b5 by working through common English words. Additional complexity can be introduced by using a phrase rather than a single word, selecting a different character range, or appending a symbol.
3Restrict SSH to Known IP Ranges
There is generally no good reason for SSH to be reachable from the open internet. Restricting access to your known IP ranges at the firewall level means the majority of automated scanners will receive no response and move on.
UFW
iptables
For environments with dynamic IPs, a VPN is the sensible approach. Establish the connection first and SSH from within that tunnel. The VPN endpoint becomes the single controlled entry point.
4Consider a Honeypot for Threat Intelligence
The previous approaches are all preventative. A honeypot serves a different purpose: rather than blocking activity, it allows it into a controlled environment in order to observe it. When an attacker reaches a honeypot, you gain visibility into which vectors were used, what they do once they believe they have access, and where the traffic originated.
This is useful for auditing real systems. If the honeypot shows repeated attempts against a particular service or configuration, that is worth examining in production.
Cowrie presents a convincing SSH environment. Everything an attacker types within it is logged in full. The session logs tend to be instructive.
5Maintain Reliable Backups
The layers above reduce the likelihood of a successful intrusion considerably. They do not eliminate it entirely. A zero-day, a misconfigured service, or a compromised credential can all create an opening regardless of how well everything else is configured.
A well-maintained backup changes the calculus significantly. If an attacker gains access, causes damage, and the system is restored within a few minutes from a clean snapshot, the effort has achieved nothing of lasting consequence. The time spent on the attack is simply wasted.
Daily rsync to a Remote Server
Nightly Database Dumps via Cron
A backup that has never been tested is not a backup in any meaningful sense. Run a restore drill on a test machine periodically so the steps are familiar when they are actually needed.
Summary
None of this requires significant budget or specialist tooling. Most of it is a matter of configuration discipline. The automated activity showing up in server logs at present does not appear especially sophisticated. Systems that present even modest resistance tend to be skipped in favour of easier targets.
Further Reading
How to Deploy OpenAKC (Authorized Key Chain)
The approaches above reduce the attack surface considerably. OpenAKC takes a different step altogether. It is an open-source authentication gateway that allows the authorized_keys mechanism to be disabled entirely across an estate, with SSH trust managed centrally. It also introduces the ability to strip specific Linux capabilities from root, meaning even a fully privileged user cannot touch files or directories you have designated as protected. If centralised access control, full session recording, and granular root capability management are relevant to your environment, the deployment guide is worth reading.
nicktailor.com ↗