How to Secure a Dedicated Server

8 min read

Securing a dedicated server starts with the same OS hardening as a VPS: SSH keys, a firewall, Fail2Ban and automatic updates. After that, you have things a VPS never gave you to worry about: a remote management controller (IPMI/KVM) with full control of the machine, plus firmware, CPU microcode and physical disks.

The OS steps already have their own guides, so this one links to them and spends its time on the rest.

Who Looks After What link

Every GoZen dedicated server is unmanaged unless you add managed services.

DDoS protection filters floods of traffic at the network edge. It won’t stop a stolen password or a vulnerable plugin, so the steps below still apply. If you’re not sure what your service includes, check the client area or ask support.

1. Harden the Operating System link

These guides mention VPS, but the steps work the same on a dedicated server. Follow them in this order:

1. First Boot: Initial Server Setup for a non-root user, SSH keys and basic firewall rules
2. VPS Security Checklist for the full baseline
3. Server Hardening Basics for sysctl settings, unused services and automatic updates

Your root password arrived by email, so treat it as exposed. Change it with passwd as soon as you log in, even if you plan to disable root login over SSH.

2. Lock Down IPMI/KVM link

IPMI is a second way into your server, and it doesn’t go through your operating system. If you’re short on time, do this section right after the OS basics.

It runs on a small computer on the motherboard called the BMC, which stays on even when the server is off. On most servers, anyone logged in to it can watch the console, reboot the machine and boot it from a disk image of their choosing. Your firewall and Fail2Ban never see any of that.

The protocol has a flaw too. With IPMI 2.0, anyone who can reach the interface and knows a valid username can pull a hash of that user’s password and try to crack it offline. No firmware update fixes this, because the flaw is in the specification. So the password has to be too long to crack, and as few networks as possible should be able to reach the interface.

Change the Password link

Log in with the IPMI details from your welcome email and change the password in the web interface. Use a random 20-character password from a password manager. That’s the limit in IPMI 2.0, and anything longer gets cut off.

Review the User Accounts link

You can see the accounts in the web interface, or list them from the server:

  sudo apt install ipmitool -y
sudo modprobe -a ipmi_si ipmi_devintf
sudo ipmitool user list 1
  

  sudo dnf install ipmitool -y
sudo modprobe -a ipmi_si ipmi_devintf
sudo ipmitool user list 1
  

Channel 1 is the usual network channel. If the list comes back empty, try 2. Disable accounts you don’t use, but if you see one you don’t recognize, ask support before you remove it.

Root on the server can also change IPMI users from the operating system, so if an attacker gets one, assume they have both.

Limit Who Can Reach It link

Check the IPMI address in your welcome email, then test whether it answers from the internet:

  # Run from another machine. Only scan addresses that belong to you.
sudo nmap -sU -p 623 your-ipmi-address
nmap -p 80,443,5900 your-ipmi-address
  

If those ports answer from a network you didn’t expect, open a support ticket and ask what access restrictions are available for your server.

When you finish a KVM session, log out and unmount any disk image you attached.

3. Update Firmware and Microcode link

apt upgrade and dnf update don’t touch your BMC or BIOS firmware, so they fall behind quietly. Check what you’re running:

  sudo ipmitool mc info | grep -i 'firmware revision'
sudo dmidecode -s bios-version
sudo dmidecode -s bios-release-date
  

Compare the versions with the motherboard manufacturer’s support page. If you’re behind, contact support before flashing anything. A failed flash can leave a server unable to boot.

CPU microcode is your job in a way it never was on a VPS, where the host deals with it. Here your OS loads it at boot, so the package has to be installed:

  sudo apt install intel-microcode -y   # Intel CPUs
sudo apt install amd64-microcode -y   # AMD CPUs
  

  sudo dnf install microcode_ctl linux-firmware -y
  

Reboot, then check how the kernel sees your CPU:

  grep . /sys/devices/system/cpu/vulnerabilities/*
  

Lines that say Not affected or Mitigation are fine. Look into any line that says Vulnerable.

4. Encrypt Sensitive Data link

Disks leave servers. A failed drive gets replaced, and a cancelled server goes back into service. If yours holds customer records or anything else you wouldn’t want read, encrypt it. If it only holds public website files you can restore from backup, you can skip this step.

We’d avoid encrypting the whole system disk. On a remote server that means typing a passphrase through the KVM console after every reboot, including the unplanned ones. An encrypted data partition is easier to live with: the server boots normally and you unlock the data when you need it.

Install the cryptsetup package if your system doesn’t have it, then replace /dev/sdb1 with your own partition:

  sudo cryptsetup luksFormat /dev/sdb1
sudo cryptsetup open /dev/sdb1 data
sudo mkfs.ext4 /dev/mapper/data
sudo mkdir -p /mnt/data
sudo mount /dev/mapper/data /mnt/data
  

After a reboot, run the cryptsetup open and mount lines again.

5. Watch Your Disks link

Not every plan has RAID. Some have a single disk, and having two disks doesn’t mean they’re mirrored. Check what you have:

  lsblk
cat /proc/mdstat
  

On a software RAID array, [UU] means both disks are healthy and [U_] means one has dropped out. If /proc/mdstat lists no arrays, your disks are running separately or sit behind a hardware RAID controller.

Check each disk’s health with SMART, and turn on the background service so it keeps checking:

  sudo apt install smartmontools -y
sudo systemctl enable --now smartmontools
sudo smartctl -H /dev/sda
sudo smartctl -H /dev/nvme0
  

  sudo dnf install smartmontools -y
sudo systemctl enable --now smartd
sudo smartctl -H /dev/sda
sudo smartctl -H /dev/nvme0
  

Use the disk names from lsblk. If a disk reports anything other than PASSED, or an array loses a disk, open a ticket straight away. See Monitoring Your Server for setting up alerts.

6. Keep Backups Off the Server link

RAID protects you from a failed disk. It doesn’t protect you from ransomware, a deleted database or an attacker with root, because the damage is copied to every disk in the array.

Off-site backups are your responsibility unless your service includes them. Automated Backups walks through the setup. Keep them somewhere the server itself can’t delete them, because any access your backup job has, an attacker with root has too. And restore one now and then. You want to find out a backup is broken on a quiet afternoon, not during an outage.

7. Reduce What’s Exposed link

See what’s actually listening:

  sudo ss -tulpn
  

Anything bound to 0.0.0.0 or [::] is reachable from outside unless your firewall blocks it. These are the ones that catch people out:

• Your server has IPv6 addresses as well as IPv4, so your firewall has to cover both. For UFW, grep IPV6 /etc/default/ufw should show IPV6=yes. See How to Set Up a Firewall.
• MySQL, PostgreSQL and Redis should listen on 127.0.0.1 unless another machine needs them.
• Docker’s published ports bypass UFW. Bind them to localhost, as the firewall guide explains.
• If you run Proxmox or a similar panel, keep its web interface behind a VPN or an IP allowlist.

Then scan your server’s public IP from another machine with nmap -sV your-server-ip and confirm only the ports you meant to open are showing. Scanning addresses that aren’t yours is against our Acceptable Use Policy.

8. If You Think the Server Is Compromised link

1. Before you change anything, copy /var/log to another machine. The server logs are your best record of how the attacker got in.
2. Contact support early. If the server starts attacking other networks, its IP can be null-routed automatically under our Acceptable Use Policy.
3. Reinstall from a clean image. Don’t try to clean the server: once someone has had root, you can’t prove you’ve removed everything. Restore your data from a backup made before the breach.
4. From a clean machine, replace every credential: SSH keys, application and database passwords, your IPMI password and your client area password.

Quick Reference Checklist link

What to Do Next link

• Enabling Two-Factor Authentication - protect your client area and control panels
• How to Secure Nginx and Apache - harden your web server
• Malware Scanning with Maldet and ClamAV - scan for infected files
• GoZen Security Scanner - audit your server from the outside