You secure your own server across five areas, and in my experience this order pays off fastest. First, access: sign in with a key instead of a password, do not work in the administrative account all day, and keep remote management off the open internet. Second, updates, automatic ones for security patches, because that is the one measure that keeps running without you. Third, open services: first look at what is actually listening, then block what nobody outside needs. Fourth, backups, kept separately from the server and restored regularly. Fifth, logging, so that after an incident you have something to look at. That is a minimum baseline, not complete protection, and which point comes first for you depends on what is reachable from outside and what is stored on the machine. Germany's Federal Office for Information Security (BSI) lists updating first among its initial protective measures for businesses, then passwords, then backups with a test.
I run servers with things on them I do not want to lose, and I have handed the security work to an AI employee who checks from the outside and documents every finding. More on that below. Still weighing up whether a machine of your own makes sense: Your Own AI Server: Hardware and Cost and AI Server for Small Businesses. This article is about the server that is already running, and for the website on top of it about Check your website security online.
Access: a key instead of a password
The OpenSSH documentation gives yes as the default for both PasswordAuthentication and PubkeyAuthentication, and prohibit-password for the administrative account's PermitRootLogin. Those are upstream defaults, not automatically the ones on your server: distributions and cloud images set their own values through package configuration and drop-in files, and many ship with password login already disabled. What actually applies on your machine is what sshd -T prints. That output is your starting point, not the manual page.
Three steps, in this order:
- Create a key pair and put the public half on the server. The private half stays on your machine and gets a passphrase.
- Test in a second window that key-based login works before you switch anything off, and keep the first session open until the test has passed. That is the difference between a migration and a lockout.
- Only then set
PasswordAuthentication no, and PermitRootLogin to no once your working account can get administrative rights through sudo. Wait until a second key login has worked, not just the first. AllowUsers or AllowGroups narrow down who may sign in at all; by default, the documentation says, all users and groups are permitted.
The key then needs the same care the password used to get: a passphrase on it, rotated when staff change or you suspect a problem, and a second factor through AuthenticationMethods where the risk is higher. And if the switch makes you nervous: ask in my community first, plenty of people there have already done it.
On a Windows server, the equivalent is remote management. Microsoft writes that enabling Remote Desktop opens a port and that you should only turn the feature on in trusted networks; for access from outside your own network it points to port forwarding or a VPN. The standard path is the VPN or an administrative gateway, plus multi-factor sign-in, a restriction to the source networks administration may come from, and monitoring of login attempts. A plain port forward on the router is the justified exception, not the solution. Microsoft recommends Network Level Authentication (NLA) for most environments: users must authenticate before the session is established at all.
Updates, and why I put them first
The BSI calls vulnerabilities in software one of the main entry points for cyber attacks and puts installing security updates in first place on its list of initial protective measures. I rank them at the top for a practical reason too: every other measure needs you, this one keeps running on its own.
Debian and Ubuntu ship unattended-upgrades for this. The Debian wiki states that the default configuration auto-installs security updates but not new features; the Ubuntu server documentation lists the main archive and the security archive as the preconfigured origins, while -updates, -proposed and -backports are commented out. Two settings are worth a look: Unattended-Upgrade::Automatic-Reboot is documented as false, so a reboot after a kernel update does not happen by itself, and Unattended-Upgrade::Mail sends you a report. What is set on your server, though, is not what the documentation says but what is in /etc/apt/apt.conf.d/50unattended-upgrades and 20auto-upgrades, because provider images bring their own defaults. A dry run with unattended-upgrade -v --dry-run shows what would happen.
On Windows Server, Microsoft's documentation on Windows Update client policies notes a particularity: Windows Server does not receive feature updates through Windows Update, so only the quality update policies apply. Those are typically published on the second Tuesday of the month, according to the same source, and you can defer them by 0 to 35 days. A short deferral is a legitimate decision if you update one machine as a test first. An open-ended one is not. And if the server runs an application that cannot take a reboot, you also need a maintenance window with a fixed date.
Open services and the network filter
Before any firewall rule comes an inventory. On Linux, ss -tulpen shows which services are listening and which address they are bound to; on Windows, Get-NetTCPConnection -State Listen does the same. The most common avoidable finding is a service bound to all addresses although only the application on the same machine needs it. A database that is only used locally belongs on the local address, not behind a firewall rule someone opens up again later.
Then the filter. You usually have three layers side by side: nftables directly, a front end such as ufw, and your provider's firewall in front of the machine. On Ubuntu, ufw is common and often the simplest choice for a single server, which does not make it preinstalled or mandatory. Its manual page gives the default policy as deny incoming, deny forward, allow outgoing: you explicitly allow the services that should be reachable from outside and enable the firewall. For remote management there is ufw limit, which according to the documentation denies connections if an IP address attempts to initiate six or more within 30 seconds. That slows down automated login attempts, but it does not replace key-based access.
On Windows Server, the security baseline for Windows Server 2025 enables the Windows Firewall on all profiles with a default-deny stance for inbound traffic, leaving only ports with an explicit allow rule open; it also disables SMBv1 and restricts TLS to 1.2 or higher. Microsoft advises testing carefully before using it in production, because the TLS floor, for example, can prevent connections to older systems.
On a rented server there is usually another filter in front of it at the provider. Two filters are not a contradiction, but you should know which one is taking effect, or you will eventually spend an hour hunting a fault that sits one layer higher.
Backups, and the test almost everyone skips
In its IT-Grundschutz module CON.3 on backup concepts, 2023 edition, the BSI lists a separate risk headed "missing restore tests": backing data up regularly does not automatically guarantee that it can be restored without trouble. The same module carries regular testing as a basic requirement, not as an optional extra.
A backup that has never been restored is an assumption. The test is part of the procedure.
Five things that go wrong most often in practice:
- The copy sits on the same system. According to the BSI, mirroring via RAID does not count as a backup, because the mirrored data is changed simultaneously: it helps against a failed disk, not against overwriting or malware.
- The separate copy hangs on the same credentials. A backup target the server itself is allowed to delete is only half separated from malware.
- The key sits next to the encrypted copy. The BSI names exactly this case: if the key is affected by the same data loss, the data is gone.
- There is only one generation. If the only copy is overwritten every night, the night after a ransomware attack backs up the damage. At least one generation therefore belongs on storage that cannot be overwritten afterwards, or on a medium that is disconnected once the backup is done.
- Nobody has ever restored anything. The test is the point almost everyone skips, and the only one that uncovers the other four.
A test does not have to be big: an empty system, a restore, a look at whether the application starts and the data is from the day you expect, plus a note with the date and the time it took. That time tells you how long an outage would last. How often you test follows from two figures: how many hours of data loss you can absorb and how long a restore may take. The tighter both, the more often you test. What such a run looks like for a container environment is in Kubernetes Backup: etcd and Volumes.
Logging: seeing what happened
Logs prevent nothing. They decide whether you can say what happened after an incident, or whether you have to guess.
On systems with systemd, journald collects the messages. In the current documentation, Storage=persistent is the default value; with the auto setting, the mere existence of the /var/log/journal directory decides whether logs survive a reboot or only live in memory. Do not rely on the default here either: older systemd releases and individual distributions differ, and what applies on your machine is what systemd-analyze cat-config systemd/journald.conf prints. A log that disappears on reboot fails you exactly when you need it. As for the network filter, ufw defaults to a log level of "low" when nothing else is specified.
On Windows Server, the Event Viewer takes this role. In the Windows Server 2025 security baseline, Microsoft describes nearly all advanced audit subcategories capturing success and failure, auditing of logons, account management and sensitive privilege use, process creation recorded with the full command line, and the Security log sized to at least 192 MB.
At my place a copy of the logs also lives off the server, because someone with access can cover their tracks there. That copy is worth protecting in its own right, since logs hold IP addresses, user names and sometimes more: decide who may read them, how long they stay, when they are deleted and how you would notice if someone changed them.
Where a check from the outside begins
The five areas above are the floor, not the ceiling. Above them sit the applications themselves, least-privilege rights, the handling of secrets, TLS, a managed view of known vulnerabilities, alerting that actually reaches someone, and a plan for the worst case. And even then you only know that the doors you know about are closed, not what your server looks like from the outside. That is the question that counts in the end.
That part is handled at my place by Falk, my AI employee for security. He tests in stages rather than in one pass: first from the outside with no access at all, then as an unauthenticated visitor, and where I approve it, with access or a look at the source code. Every finding comes with evidence, a rating on the CVSS standard and a concrete fix, not just a list entry; how such an audit runs from authorisation to retest has its own post. The automated part runs throttled, in my setup at no more than 20 requests per minute, so a test does not disturb operations.
The framing matters as much as the method. Every engagement gets its own scope and a written approval for exactly the system in question, and until that approval exists, not a single request goes out. He does not test other people's systems without a written scope, and he does not perform destructive actions. That is also why this work does not come as an off-the-shelf package: the approval applies to one specific system. If you want to check in the meantime whether the encryption on your services is in order, the walkthrough in How to Check an SSL Certificate is enough.
Frequently asked questions
Isn't a very long password good enough?
A long, unique password is much better than a short one, and without a key mechanism it is the right choice. With SSH, a key has two advantages: a strong key is not realistically brute-forceable, and the private half is never transmitted to the server. It is attacked differently: copied, stolen, or protected by a weak passphrase. So: keys with a passphrase, and rotate them.
Should I move SSH to a different port?
It cuts the noise in your logs, because automated scanners usually knock on the standard port first. As protection it does little, a port scan finds the service anyway. Do it if the failed attempts bother you, but not instead of key-based login and a filter.
Can an automatic update break something?
Yes, that can happen, which is why the Debian and Ubuntu default is limited to security sources and does not reboot by itself. A dry run with --dry-run shows beforehand what would be installed. The counter-question belongs in the picture: a server with a hole that has been open for weeks is the bigger risk.
My server is rented. Doesn't the provider handle this?
That depends on the contract. With a managed offering the provider usually looks after the operating system; with an unmanaged server or a VPS, typically only hardware and network. Read where the line runs, and when in doubt assume everything above it is your job.
Is Linux or Windows more secure?
The question points in the wrong direction. Both systems ship usable built-in tools, and in both cases the setup decides: open services, access, patch level. The practical difference is what you know your way around: a system whose logs you can read is safer in your hands.
How to take this further
Set aside two hours and work in this order. One: write down which services are listening on your server. Two: switch login over to keys, with the second window as your safety net. Three: turn on automatic security updates and have the report sent to you. Four, the step almost everyone skips: restore a backup onto an empty system and note the date and how long it took. Put those four points in a table with the columns measure, done on, next check, and you are ahead of most small businesses I know. And if you want to go the step beyond, an AI employee who tests in stages and documents every finding: the path there is in my community Claude Practitioners.
