How to Secure a New Fast Hive VPS: A First-Hour Checklist

A Fast Hive VPS deploys in about 55 seconds with full root access and no opinions from us about what you run on it. That freedom means the security of the server is yours to configure. Automated scanners find new public IP addresses within minutes of deployment, so this is not a task to leave for later. This checklist takes roughly half an hour and closes the gaps that account for the overwhelming majority of compromised servers.

1. Update everything, first

# Ubuntu / Debian
apt update && apt upgrade -y

# AlmaLinux / CentOS Stream / Fedora
dnf upgrade -y

Your image was built at some point in the past. Patching is the single highest-value action on this list.

2. Create a non-root user

# Ubuntu / Debian
adduser yourname
usermod -aG sudo yourname

# AlmaLinux / CentOS Stream / Fedora
adduser yourname
passwd yourname
usermod -aG wheel yourname

Copy your SSH key across so the new user can log in, then verify it in a separate terminal:

rsync --archive --chown=yourname:yourname ~/.ssh /home/yourname

# From your own machine, in a NEW terminal:
ssh yourname@your.vps.ip.address
sudo whoami   # should print: root

3. Harden SSH

Edit /etc/ssh/sshd_config and set:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
X11Forwarding no
MaxAuthTries 3
ClientAliveInterval 300

Then validate the file before restarting - this catches typos that would otherwise leave SSH refusing to start:

sshd -t && systemctl restart sshd

4. Configure the firewall

Default-deny inbound, and open only what you actually serve.

# Ubuntu / Debian (ufw)
ufw default deny incoming
ufw default allow outgoing
ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status verbose

# AlmaLinux / CentOS Stream / Fedora (firewalld)
firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --reload
firewall-cmd --list-all

Notice what is not opened: database ports. MySQL, PostgreSQL, Redis and MongoDB should listen on 127.0.0.1 only. An exposed database with a default password is one of the most common ways a server is lost.

5. Block brute-force attempts

# Ubuntu / Debian
apt install fail2ban -y

# AlmaLinux / CentOS Stream / Fedora
dnf install fail2ban -y

systemctl enable --now fail2ban
fail2ban-client status sshd

Fail2ban watches the logs and temporarily bans IP addresses that fail repeatedly. Configure your own rules in /etc/fail2ban/jail.local rather than editing jail.conf, which is replaced on upgrade.

6. Turn on automatic security updates

# Ubuntu / Debian
apt install unattended-upgrades -y
dpkg-reconfigure --priority=low unattended-upgrades

# AlmaLinux / CentOS Stream / Fedora
dnf install dnf-automatic -y
systemctl enable --now dnf-automatic.timer

7. Reduce the attack surface

• Uninstall services you do not use. Anything listening is something that can be exploited.
• Audit what is currently open:

  ss -tulpn

• Every line bound to 0.0.0.0 or [::] is reachable from the internet. Justify each one or bind it to localhost.
• Change every default password on anything you install.

8. Set up snapshots and backups

Every VPS tier includes snapshots. Take one once the server is configured and working, so you have a known-good state to return to. Snapshots protect against your own mistakes; keep off-server copies of important data as well, since a snapshot lives in the same place as the thing it protects.

9. Set the time zone and enable NTP

timedatectl set-timezone Europe/London
timedatectl set-ntp true

Accurate time matters more than it looks: log correlation, certificate validation and time-based authentication all depend on it.

10. Know where the logs are

journalctl -u sshd --since "1 hour ago"    # SSH activity
journalctl -p err --since today             # errors today
last -a | head -20                          # recent logins
lastb | head -20                            # recent failed logins

Quick reference checklist

Troubleshooting

Frequently asked questions

Is my VPS secured by Fast Hive out of the box?

The infrastructure around it is ours; the operating system is yours. You have root access, which means you also have responsibility for what runs on it. This checklist is the baseline we recommend.

Do I need all of this for a small personal project?

Yes. Automated scanners do not care how small your project is - they look for reachable servers with weak credentials, and a compromised VPS becomes a platform for attacking others.

What if I already suspect a compromise?

Do not simply reboot. Open a ticket with Technical Support straight away and preserve the current state, so the entry point can be identified. Rebuilding without finding the cause invites a repeat.

Does Fast Hive offer managed VPS support?

Our engineers are available 24/7 for server-level matters. If you would prefer not to administer the operating system yourself, ask Sales & Solutions about the management options available for your plan.

Can I do this on a cPanel VPS?

Yes, but be careful: cPanel manages the firewall and some services itself. Coordinate changes with its configuration rather than working around it.