The average time between initial compromise and lateral movement is now 34 minutes, down from 48 minutes a year ago, according to IBM research. The fastest observed attack began moving laterally within four minutes. If your VPS hardening strategy still relies on perimeter firewalls and the assumption that your neighbours on shared infrastructure are benign, that timeline should recalibrate your thinking fast.

Shared-tenancy cloud is not inherently unsafe, but it does mean that a compromised instance on the same physical host, the same VLAN, or the same Kubernetes node as yours is a potential stepping stone. The controls that matter are not exotic. They are disciplined application of Linux-level isolation, network policy, and privilege boundaries that most teams know about but rarely enforce consistently.

This post is an opinionated checklist, ordered from the controls with the highest return on effort to those requiring more sustained investment. It assumes a Linux VPS, root or sudo access, and a workload that you actually care about protecting.

Start with the attack surface you expose on day one

As soon as a cloud provider assigns a public IPv4 address, automated scanners find it. Shodan, Censys, and purpose-built botnets crawl the entire IPv4 space continuously. Your instance is indexed before you have finished configuring it.

SSH is the primary remote management vector on most Linux VPS, and it is also the most abused entry point. The baseline configuration changes are not optional:

  • Set PasswordAuthentication no in /etc/ssh/sshd_config. Key-only authentication eliminates credential-stuffing as an entry path.
  • Set PermitRootLogin no. Root should never be the first account an attacker can target over the network.
  • Use AllowUsers or AllowGroups to whitelist exactly who may authenticate. Default-deny for every other account.
  • Disable weak key exchange algorithms and ciphers. Prefer curve25519-sha256 for KEX and chacha20-poly1305 or aes256-gcm for encryption.
  • Route interactive access through a bastion or jump host rather than exposing sshd directly on a public interface. Rate limiting with fail2ban or sshguard is a supplement, not a substitute.

Two-factor authentication via the Google Authenticator PAM module adds meaningful friction for any attacker who does obtain a private key, particularly in environments where keys are shared across a team.

Linux VPS firewall rules: default deny, not default allow

Most VPS instances leave the distribution’s default firewall policy in place, which is usually permissive. The correct starting point is the opposite: drop everything inbound and outbound, then open only what your workload explicitly needs.

With nftables (the current standard on modern kernels), a base ruleset should establish a default drop policy on the input and forward chains, permit established and related connections, allow loopback, and open only the specific ports and source CIDRs your application requires. The forward chain matters even on a standalone VPS if you run containers: Docker and similar runtimes manipulate iptables/nftables rules, and a misconfigured bridge interface can bypass your host-level policy entirely.

Outbound filtering is underrated for lateral movement prevention. An attacker who has code execution on your instance needs to reach their command-and-control infrastructure or pivot to adjacent services. Restricting egress to known destinations (your database, your object storage endpoint, your monitoring collector) limits what they can do with that foothold. Log everything that hits the default-drop rule; those logs are your earliest indicator of reconnaissance.

The firewall is not there to stop the first packet. It is there to ensure that a compromised process cannot become a pivot point for the next ten.

Kernel hardening: the sysctl parameters that actually matter

Several kernel parameters reduce the exploitability of vulnerabilities that are already on your system. These are not theoretical; CVE-2024-1086, a use-after-free in the Linux netfilter subsystem, was confirmed by CISA as actively exploited in ransomware campaigns in late 2025 and used by groups including RansomHub and Akira. ASLR and related controls raise the cost of exploiting bugs like this.

  • ASLR: kernel.randomize_va_space = 2. Full randomisation of stack, heap, and MMAP segments.
  • Reverse path filtering: net.ipv4.conf.all.rp_filter = 1. Drops packets whose source address is not reachable via the interface they arrived on, blocking a class of spoofing attacks.
  • ICMP redirects: Disable acceptance and sending. Redirects are a legitimate routing protocol feature that attackers abuse to redirect traffic.
  • Source routing: net.ipv4.conf.all.accept_source_route = 0. Source-routed packets should never arrive on a production VPS.
  • SYN cookies: net.ipv4.tcp_syncookies = 1. Mitigates SYN flood exhaustion without dropping legitimate connections.

Persist these in /etc/sysctl.d/ so they survive reboots. Apply them with sysctl --system after writing the file. None of these changes affect normal application behaviour.

VPS network segmentation and shared cloud tenant isolation

Host-level hardening is necessary but not sufficient in a shared environment. The network topology around your instance determines how far an attacker can move if they do get in, and how far a compromised neighbour can reach toward you.

Private networking between your VPS instances should use dedicated VLANs or overlay networks rather than the public interface. Traffic between your application tier and your database should never cross the public internet, and ideally should not be routable from any instance outside that application’s security group. Where your provider supports security groups or network ACLs at the hypervisor level, use them in addition to host-level rules: defence in depth means the controls do not share a failure mode.

We operate AMS1 in Amsterdam with dense peering at AMS-IX, which makes it a practical anchor for workloads that need low-latency private connectivity across Benelux, the UK, and Western European markets. Customers running multi-tier applications there use our private networking to keep database and cache traffic fully off the public interface, which eliminates an entire class of network-level lateral movement paths.

For container workloads, the isolation picture is more complicated. CVE-2024-21626 (a file descriptor leak in runc) and the three critical runc vulnerabilities disclosed in November 2025 demonstrated that the boundary between container and host is not as hard as it looks. Patch to runc 1.2.8 or later, and for GPU workloads, run NVIDIA Container Toolkit v1.16.2 or higher (CVE-2025-23266, CVSS 9.0, allows full host root access from a malicious container). Treat the host kernel patch cycle as a first-class operational concern, not a quarterly maintenance item.

Privilege boundaries and credential hygiene

Lateral movement in cloud environments frequently exploits over-permissioned service accounts and long-lived API tokens stored in environment variables or configuration files. The Change Healthcare breach in February 2024, which resulted in a reported $22 million ransom payment, followed exactly this pattern: stolen credentials enabled lateral movement across a flat network before ransomware was deployed.

The controls that close this path are operational, not just technical:

  • Rotate API keys and service account credentials on a defined schedule. Treat any token with more than 90 days of age as potentially compromised.
  • Apply least-privilege to every service account. A process that reads from object storage does not need write access, and it certainly does not need IAM permissions.
  • Use instance metadata service v2 (IMDSv2 on AWS-compatible APIs) to prevent SSRF attacks from harvesting instance credentials via the metadata endpoint.
  • Audit environment variables in running containers and systemd units. Secrets in environment variables are readable by any process running as the same user, and by anyone with access to /proc/<pid>/environ.
  • Separate workloads by privilege level across instances rather than running high-privilege and low-privilege processes on the same host.

The 14-day global median attacker dwell time reported in Mandiant’s M-Trends 2026 report means that credential exposure is rarely discovered before it has been used. The goal is to limit what any single compromised credential can reach, not to detect the compromise instantly.

Monitoring as a lateral movement control

Hardening reduces the probability and blast radius of compromise; monitoring is what tells you when hardening has failed. For VPS workloads, the minimum useful signal set is: authentication logs (successful and failed), outbound connection attempts to unexpected destinations, process execution from unexpected paths (auditd with appropriate rules), and changes to files in /etc, /bin, and /sbin.

Ship these logs off-host in near real-time. An attacker with root access will clear local logs. The value of the audit trail depends entirely on it being somewhere the attacker cannot reach.

Combine host-level monitoring with network flow data. A spike in outbound traffic from a VPS that normally sends a few kilobytes per minute is a stronger signal than any single log entry. Correlating the two is where automated detection becomes genuinely useful rather than just noise.