Baseline Validation for a Fresh VPS: What to Check Before You Host Anything

A newly provisioned VPS feels clean, but "new" does not automatically mean "ready." Before you deploy a website, VPN, API, mail server, or internal tool, you should verify what the provider actually delivered.

This is not yet a hardening guide. It is a validation workflow for confirming identity, visibility, access, and system state before the server begins doing real work.

That distinction matters. If you start changing settings immediately, you lose the chance to observe the original baseline. A short review first helps you answer questions like:

• Is this really the operating system image I expected?
• Is anything already exposed to the internet?
• Are there preinstalled services I did not ask for?
• Do package sources and DNS settings look normal?
• Is there evidence of provider customization I need to understand?

If something is wrong, it is much easier to escalate to the provider before the VPS enters production.

What this tutorial is trying to achieve

The goal is simple: create a documented, trusted starting point.

By the end of the review, you should have:

1. Confirmed the VPS identity and assigned resources.
2. Verified the OS and image details.
3. Checked local and external network exposure.
4. Reviewed accounts, keys, services, and startup behavior.
5. Saved a baseline record for future troubleshooting and security work.

Step 1: Record the provisioned details before logging in

Start in the provider panel, not the shell.

Capture the details you were supposed to receive:

• VPS name or instance ID
• Public IPv4 and IPv6 addresses
• Region or datacenter location
• Assigned CPU, RAM, and storage
• Selected OS image and version
• Whether cloud-init, recovery console, snapshots, or provider firewalls are enabled

Why this matters:

• It gives you a reference for later verification.
• It helps catch wrong-image or wrong-region deployments.
• It creates a paper trail if billing or infrastructure disputes appear later.

A simple text file is enough at this stage. Note the time the VPS was created and the initial credentials or SSH key method used.

Step 2: Verify you reached the correct system

When you first connect, confirm that the machine is the one you intended to access.

Useful checks:

hostnamectl
uname -a
ip a
ip route
whoami
last -a | head
uptime

What to look for:

• Hostname matches your naming plan or provider pattern.
• Public and private addresses make sense.
• Default route looks normal for the provider network.
• Boot time aligns with recent provisioning.
• No suspicious login history appears before your own access.

If last shows logins before you connected, do not panic immediately. Some provider automation or console access may appear there. The point is to notice it and decide whether it is expected.

Step 3: Confirm the operating system image and release

Do not assume the selected template was applied correctly.

Check:

-token-keyword">cat /etc/os-release
lsb_release -a 2>/dev/null
uname -r
df -h
free -m
lscpu | sed -n '1,20p'

Review the results against what you ordered:

• Distribution name and version
• Kernel branch
• Available disk layout
• RAM amount
• CPU model and virtualized feature set

Questions to ask:

• Does the kernel look unusually old for this image?
• Is the root filesystem layout what you expected?
• Are there extra mounted volumes or strange filesystems?
• Is swap configured, and if so, by design?

This step is not about updating packages yet. It is about confirming the image is recognizable and sensible.

Step 4: Inspect cloud-init and provider customization

Many VPS images are modified by providers during provisioning. That is normal, but you should understand what changed.

Look for:

cloud-init status 2>/dev/null
ls /var/log/cloud-init* 2>/dev/null
-token-keyword">systemctl status cloud-init 2>/dev/null --no-pager

Also inspect:

• /etc/hosts
• /etc/hostname
• resolver configuration
• SSH authorized keys for the initial user
• any provider-specific agents

Examples of expected customization:

• Injected SSH public keys
• Network configuration
• Expanded filesystem size
• Added metadata or agent packages

Examples of things worth questioning:

• Unexpected repositories
• Extra users you did not create
• Monitoring agents with unclear purpose
• Startup scripts that contact unfamiliar endpoints

Provider tooling is not automatically bad, but it should never be invisible to you.

Step 5: Review listening services from inside the VPS

Before scanning from outside, see what the host itself says is listening.

Use:

ss -tulpn
-token-keyword">systemctl list-units --type=service --state=running

You are trying to map:

• Which ports are open
• Whether they bind to 0.0.0.0, ::, or only localhost
• Which process owns each listener
• Which services start automatically

Common things you may see on a minimal image:

• sshd on port 22
• DNS stub resolver on localhost
• occasional DHCP or metadata-related processes

Things that deserve attention on a "fresh" system:

• Web servers you did not install
• Database listeners exposed on all interfaces
• RPC or administration services
• Control panel software you did not request

This is one of the most valuable parts of the entire review. A new VPS should usually be quiet.

Step 6: Validate external exposure from outside the VPS

Internal checks are not enough. You also want the internet-facing view.

From a trusted system you control, test the public IP:

nmap -Pn -sV YOUR_VPS_IP

If IPv6 is enabled, scan that too.

What this reveals:

• Ports visible externally
• Service banners
• Whether provider firewall rules differ from local firewall settings
• Accidental exposure on IPv6 while IPv4 looks restricted

Compare the external results with ss -tulpn from the VPS itself.

Typical mismatches include:

• A local service listening on all interfaces but blocked upstream
• A service exposed only on IPv6
• A provider firewall rule you forgot existed
• NAT or forwarding behavior you did not expect

The main lesson: observe from both perspectives.

Step 7: Check firewall state without changing it yet

You need to know what currently enforces traffic policy.

Review local firewall configuration:

iptables -S
iptables -L -n -v
ip6tables -S 2>/dev/null
nft list ruleset 2>/dev/null
ufw status verbose 2>/dev/null
firewall-cmd --list-all 2>/dev/null

Then compare that with any provider-level firewall controls visible in the cloud panel.

What to document:

• Whether filtering is active locally
• Whether filtering exists only at the provider edge
• Whether IPv4 and IPv6 are treated differently
• Whether the current rules match your intended design

At review time, the goal is not to perfect the rules. The goal is to avoid surprises.

Step 8: Review accounts, sudo access, and SSH trust paths

Access review matters before the VPS becomes part of a production workflow.

Check local users:

getent passwd | awk -F: '$3 >= 1000 {print $1,$3,$6,$7}'
-token-keyword">sudo -l -U YOUR_USERNAME 2>/dev/null
-token-keyword">grep -R "^ssh-" /home/*/.ssh/authorized_keys 2>/dev/null
-token-keyword">grep -R "^ssh-" /root/.ssh/authorized_keys 2>/dev/null

Also inspect:

• /etc/sudoers
• files under /etc/sudoers.d/
• SSH daemon configuration

sshd -T 2>/dev/null | egrep 'permitrootlogin|passwordauthentication|pubkeyauthentication|allowusers|allowgroups'

Questions to answer:

• Which human-accessible accounts exist?
• Is root login allowed?
• Are password logins enabled?
• Which keys were injected during provisioning?
• Is there any unexpected sudo delegation?

A lot of later incidents are really account review failures that started on day one.

Step 9: Inspect package sources and update channels

A clean VPS should use package repositories you recognize.

On Debian or Ubuntu-based systems:

-token-keyword">grep -Rhv '^#' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null
apt-cache policy | sed -n '1,80p'

On RHEL, Rocky, AlmaLinux, or CentOS-type systems:

dnf repolist -v 2>/dev/null || yum repolist -v 2>/dev/null

Why this matters:

• Third-party repositories change your trust boundary.
• Provider images sometimes include convenience repos.
• Future patching behavior depends on what is configured now.

You are not just checking whether updates exist. You are checking who the server trusts for software.

Step 10: Review startup persistence and scheduled tasks

A fresh VPS should not have mysterious persistence mechanisms.

Inspect common startup locations:

-token-keyword">systemctl list-unit-files --state=enabled
crontab -l 2>/dev/null
ls -al /etc/cron.*
ls -al /var/spool/cron 2>/dev/null

Also look at:

• /etc/rc.local
• systemd timers
• provider scripts under /usr/local/ or /opt/

You are looking for jobs that:

• call external URLs
• download scripts
• rotate or alter configs automatically
• restart services you did not expect

Not every scheduled task is suspicious. The goal is to identify anything you would struggle to explain later.

Step 11: Validate DNS and time configuration

These are easy to ignore, but they affect package validation, logging, and service reliability.

Check:

-token-keyword">cat /etc/resolv.conf
timedatectl
chronyc sources 2>/dev/null || ntpq -p 2>/dev/null

Review:

• Which resolvers are configured
• Whether they are provider resolvers, public resolvers, or internal addresses
• Whether the system clock is synchronized
• Whether timezone settings make operational sense

Time drift and resolver surprises can waste hours later. Catch them while the system is still empty.

Step 12: Look for provider agents and management hooks

Many VPS platforms install helpers for monitoring, backups, recovery, or console support. Those may be necessary, but they should be known.

Useful checks:

ps aux --sort=start_time | tail -n 30
-token-keyword">systemctl list-units --type=service | egrep -i 'agent|monitor|guest|cloud|qemu|vm'
rpm -qa | egrep -i 'agent|cloud|guest' 2>/dev/null
dpkg -l | egrep -i 'agent|cloud|guest' 2>/dev/null

Document:

• service name
• package name
• purpose if known
• whether removal would break provider features

This is a review step, not a removal step. First understand what is there.

Step 13: Gather a lightweight integrity baseline

You do not need a full enterprise asset system to create a useful baseline.

At minimum, save:

• OS release and kernel version
• IP configuration
• open ports and listeners
• running services
• enabled units
• local users and sudo-related files
• package repositories
• external scan results
• firewall rules
• current package list

Examples:

-token-keyword">mkdir -p ~/vps-baseline
hostnamectl > ~/vps-baseline/hostnamectl.txt
uname -a > ~/vps-baseline/uname.txt
ip a > ~/vps-baseline/ip-a.txt
ip route > ~/vps-baseline/ip-route.txt
ss -tulpn > ~/vps-baseline/ss-tulpn.txt
-token-keyword">systemctl list-units --type=service --state=running > ~/vps-baseline/running-services.txt
-token-keyword">systemctl list-unit-files --state=enabled > ~/vps-baseline/enabled-units.txt
getent passwd > ~/vps-baseline/passwd.txt
iptables -S > ~/vps-baseline/iptables.txt 2>/dev/null
nft list ruleset > ~/vps-baseline/nftables.txt 2>/dev/null

Store this baseline somewhere controlled outside the VPS as well.

A practical review order if you only have 15 minutes

If time is limited, do the highest-value checks first:

1. Confirm identity

• hostnamectl
• ip a
• uptime
• cat /etc/os-release

2. Check local exposure

• ss -tulpn
• systemctl list-units --type=service --state=running

3. Check external exposure

• nmap -Pn -sV YOUR_VPS_IP

4. Review access paths

• users
• sudo rights
• SSH configuration
• authorized keys

5. Save evidence

• command outputs to text files

That short workflow catches a surprising number of real-world mistakes.

Red flags that justify pausing deployment

Stop and investigate if you find any of the following:

• Services listening publicly that you did not install
• Unrecognized user accounts or SSH keys
• Package repositories from unknown third parties
• Strange startup scripts or scheduled tasks
• Unexpected root login behavior
• External ports open on IPv6 but not IPv4
• Logs showing unexplained prior access
• OS version or kernel inconsistent with the image you selected

None of these automatically means compromise. But each one is a valid reason to pause production use until you understand it.

What not to do during the review

Avoid these common mistakes:

Do not start by changing everything

If you immediately harden, patch, install agents, or deploy apps, you erase evidence of the original state.

Do not rely only on the provider dashboard

The panel may show intended settings, not actual runtime behavior.

Do not check only from inside the VPS

External visibility can differ from local expectations.

Do not ignore IPv6

A lot of accidental exposure lives there.

Do not skip documentation

A baseline that lives only in memory is not a baseline.

After the review, what comes next?

Once you trust the baseline, then it makes sense to move into your normal build process:

• patching
• hardening
• application deployment
• logging and monitoring setup
• backups
• service-specific firewall policy

The important part is the order. Validate first, then modify.

Final thoughts

A new VPS should be treated like any other newly acquired system: useful, but not yet trusted. A short validation pass helps you verify what exists before your own changes complicate the picture.

That makes the VPS easier to secure, easier to troubleshoot, and easier to explain later if something goes wrong.

If you build this into your standard provisioning routine, reviewing a fresh VPS stops being a one-off caution step and becomes part of disciplined operations.