The moment a new VDS is handed over to you, it starts living in the noisiest neighbourhood on the internet. Within minutes of provisioning — before you have installed a single application — automated scanners will begin knocking on your SSH or RDP port. These bots do not know who you are and do not care what you plan to host. They simply walk through public IP ranges looking for weak passwords and unpatched services. This guide walks through the first ten security steps to take before a new server carries production traffic. All of them can be completed in an afternoon, and together they eliminate the majority of problems you would otherwise face over the life of the server.
Server hardening is usually pushed onto the "I'll do it later" list. The problem is that attackers do not follow your calendar. Freshly allocated IP ranges are scanned continuously, and a server left with default settings can be compromised within hours of going live. A compromised server is rarely wiped — it is quietly repurposed for crypto mining, spam relaying, or attacks against other targets. By the time you notice, performance has degraded and your IP address is on public blocklists.
The good news is that the overwhelming majority of these attacks are opportunistic rather than targeted. Bots do not linger on hard targets; they move to the next easy one. The steps below do exactly that — they take you off the easy-target list.
Linux servers are typically delivered with the root account. Root has unlimited authority over the system, so if that password is compromised there is nothing left to protect. Create a normal user for yourself and elevate with sudo only when needed:
Turkey (Türkçe)
Worldwide (English)
adduser myuser.usermod -aG sudo myuser (Debian/Ubuntu) or usermod -aG wheel myuser (AlmaLinux/Rocky).sudo whoami returns root.Do not close your existing session until that check passes, or you may lock yourself out of the machine.
Password-based SSH is the single door that brute-force attacks knock on. An SSH key replaces a guessable secret with a cryptographic pair that is not practically guessable. Generate one on your own machine with ssh-keygen -t ed25519, copy it across with ssh-copy-id user@server-ip, and confirm that key-based login works.
Only then edit /etc/ssh/sshd_config:
PasswordAuthentication noPermitRootLogin no (or at minimum prohibit-password)PubkeyAuthentication yesValidate the file with sshd -t before restarting the service, and keep your current session open while you test a login from a second terminal. If something is wrong, the open session is your way back in.
Moving SSH off port 22 is not security by itself, but it dramatically reduces log noise because most automated scanners only probe the default port. If you change it, remember to open the new port in your firewall. Beyond that, MaxAuthTries 3, LoginGraceTime 30 and an explicit AllowUsers directive meaningfully narrow the attack surface.
If you work from a static IP address, restricting management ports to that address alone is the most effective single control available to you.
A correct firewall policy is not "block the dangerous things" but "block everything except what is required". On Ubuntu and Debian, ufw makes this straightforward:
ufw default deny incomingufw default allow outgoingufw allow 22/tcp (or your chosen SSH port)ufw allow 80,443/tcp if you are running a web serverufw enableOn AlmaLinux and Rocky, firewalld does the same job. On a Windows VDS, set the inbound default action in Windows Defender Firewall to block and add rules only for the ports you need. If you run game servers, remember your UDP ports — services such as MTA, FiveM and TeamSpeak all operate over UDP.
fail2ban is a small but highly effective tool that watches log files and temporarily bans an IP address in the firewall after a set number of failed logins. After installing it, tune maxretry, findtime and bantime for SSH in jail.local. Ready-made jails also exist for web servers, mail services and control panels.
On Windows, the closest equivalents are account lockout policies in Group Policy and Network Level Authentication for RDP. Where it is practical, placing RDP behind a VPN instead of exposing it directly to the internet is considerably safer.
A large share of server compromises exploit known vulnerabilities that were patched months earlier, not zero-days. Run apt update && apt upgrade (or dnf update) immediately after provisioning, then automate security patching: unattended-upgrades on Debian and Ubuntu, dnf-automatic on RHEL derivatives.
If you are not comfortable with fully automatic updates, at least automate the security repository and apply version upgrades manually. For business-critical applications, set a fixed weekly maintenance window rather than patching ad hoc.
Services that ship with the image but that you never use quietly accumulate risk. Run ss -tulpn to see which service is listening on which port, and ask one question about every line: "does this actually need to be reachable from the internet?"
127.0.0.1 only.Unauthenticated Redis and Memcached instances are a particularly common finding: they expose data directly and can also be abused as reflectors in amplification attacks against third parties.
The most realistic definition of security is how quickly you can recover on a bad day. Ransomware, a dropped table, a broken upgrade — the answer to all of them is a working backup. Aim for the 3-2-1 rule: at least three copies, on two different media, with one copy off the server.
The most common mistake is keeping backups on the server's own disk. When a server is compromised, deleting backups is the attacker's first move. The account that writes backups should not have permission to delete existing ones, and you should run a restore test at least monthly. An untested backup is not a backup.
You can only fix what you can see. At a minimum, monitor CPU, memory, disk usage and network throughput. A database that stopped because the disk filled up causes far more outages in practice than any attacker does.
For logs, journalctl, /var/log/auth.log and your web server access logs are the first places to look. A sudden, unexplained spike in traffic can be an early sign of an attack; we covered how attack scale and network capacity relate to each other in our article on what DDoS protection capacity actually means.
The first nine steps protect the server itself. The tenth concerns what runs on it: strong passwords and two-factor authentication on admin panels, an up-to-date CMS and plugins, correct file permissions, and encrypted traffic using a free SSL certificate.
The network layer, however, is not something you can solve from inside the operating system. A volumetric attack saturates the uplink before it ever reaches your server, which is why the network your host runs matters. Nubitro's Istanbul-located AMD Ryzen 9 9950X VDS servers run on a DDoS-protected network infrastructure, and projects that outgrow a virtual server can move to our dedicated server options.
The logic is identical; only the tooling differs. On Windows, pay attention to the following:
Administrator account and use a separate admin account for day-to-day work.Not on its own. Changing the port adds no encryption and no authentication; it only reduces automated scanning noise. Real protection comes from SSH keys, disabled password login and a restrictive firewall. Treat the port change as an addition to those measures, never a replacement.
Around two hours the first time, and roughly twenty minutes once you are familiar with the steps. If you provision servers regularly, turn the sequence into a setup script so every new machine starts from the same known-good baseline.
No — they complement each other. The firewall decides which ports are open at all, while fail2ban watches the ports you must keep open and temporarily blocks addresses that misbehave on them. Use both.
Typical signs include sustained high CPU usage on an otherwise idle server, unfamiliar scheduled tasks or processes, unexplained outbound traffic, your IP appearing on spam blocklists, and successful logins in auth.log that were not yours. If you suspect a compromise, isolating the server and restoring from a clean backup is safer than trying to clean the running system.
Only partly. Hardening prevents compromise and application-layer abuse. Volumetric DDoS attacks are a question of network capacity and cannot be solved with settings inside the server; that protection has to come from the hosting provider's network.
Securing a new VDS is not complicated, it is sequential. Stop working as root, move to SSH keys, disable password login, configure the firewall to deny by default, block brute-force attempts automatically, keep the system patched, close unused services, back up off the server, add monitoring, and do not neglect the application layer. These ten steps neutralise almost every automated attack your server will face.
What remains is volumetric network attacks, and that part is solved by infrastructure. You can review our Turkey-located VDS servers or get in touch for help sizing a configuration for your project. Setup is instant, and DDoS-protected network infrastructure with 24/7 support comes as standard.