Rich Gibbs

Ubuntu/Debian EC2 hardening checklist (2026)

Sun, 10 May 2026 00:20:00 +0000

You spun up an EC2 instance, pointed a domain at it, and now real traffic — and real bots — can reach it. Most “hardening guides” online are either copy-paste cargo cult from 2014 or vendor whitepapers selling a SIEM. This is the version I actually run on Ubuntu 22.04, Ubuntu 24.04, and Debian 12 boxes, written for solo founders and small teams who don’t have a dedicated security person.

Work through it top to bottom on a fresh box. On an existing box, treat it as a diff: read each section, run the audit command, fix the gap, move on.

Why this checklist

The threats most small EC2 fleets actually get hit by aren’t APTs. They’re:

SSH brute force from random botnets
Exposed services you forgot were listening (Redis, Postgres, Docker API, an old admin panel)
Stolen IAM credentials via SSRF on a misconfigured app reaching the EC2 metadata service
An unpatched kernel or library with a known CVE
A compromised dependency or container image that opens a reverse shell

Everything below is aimed at those concrete risks. There’s no checklist on earth that makes you “secure” — but a tight baseline closes the cheap, automated attack paths so an attacker has to actually work.

Threat model assumptions

Before any commands, make these explicit:

This is a single-tenant Linux server (or small fleet) on AWS EC2.
You are the only admin, or there’s a tiny ops team with shared SSH keys.
The instance runs a public-facing web app and/or some background workers.
You’re not in a regulated environment yet (PCI/HIPAA/SOC 2 controls are not what this checklist gives you).
You can tolerate a few minutes of downtime to reboot for kernel updates.

If any of those don’t match, adjust before applying.

1. SSH

SSH is still the single biggest “front door” on a Linux server.

Use keys, not passwords. Disable root login. Limit who can log in.

Edit /etc/ssh/sshd_config (or drop a file in /etc/ssh/sshd_config.d/ on Ubuntu 22.04+):

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no
X11Forwarding no
MaxAuthTries 3
LoginGraceTime 20
ClientAliveInterval 300
ClientAliveCountMax 2
AllowUsers ubuntu deploy

Replace ubuntu deploy with the actual non-root accounts you use. Then validate and reload:

sudo sshd -t
sudo systemctl reload ssh

Optional but worth it on small boxes:

Move SSH off port 22. It doesn’t stop a determined attacker, but it cuts log noise from internet-wide scanners by ~95%. If you do this, update the EC2 security group too.
Restrict the SSH security group to your office/VPN IP, your home IP, or a bastion. 0.0.0.0/0 on port 22 is a choice, not a default.
Install fail2ban for cheap brute-force throttling:

bash sudo apt-get update && sudo apt-get install -y fail2ban sudo systemctl enable --now fail2ban

Audit:

sudo sshd -T | grep -Ei 'permitrootlogin|passwordauth|pubkeyauth|allowusers|port'

2. Firewall and listeners

The cheapest mistake on EC2 is a service binding to 0.0.0.0 that you thought was on 127.0.0.1. Defense in depth: lock it down at the OS and at the security group.

See what’s actually listening:

sudo ss -tulpn

Anything bound to 0.0.0.0 or :: that isn’t your web server, SSH, or something you explicitly want public is a finding. Common offenders: Redis (6379), Postgres (5432), MySQL (3306), Docker API (2375/2376), Elasticsearch (9200), Memcached (11211), node dev servers.

Bind to localhost in the service config (e.g. bind 127.0.0.1 in /etc/redis/redis.conf, listen_addresses = 'localhost' in postgresql.conf).

Then layer UFW on top:

sudo apt-get install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

On the AWS side, the security group is your real perimeter. Rules of thumb:

One SG per role (web, db, worker), not one giant SG that allows everything internally.
DB and cache SGs accept traffic only from the app SG, never from 0.0.0.0/0.
SSH SG limited to known IPs or a bastion/VPN SG.
No 0.0.0.0/0 on anything except 80/443 on the public web tier.

Audit:

sudo ss -tulpn | awk '$5 ~ /0\.0\.0\.0|\[::\]/'
sudo ufw status numbered

Cross-check the AWS console / CLI:

aws ec2 describe-security-groups \
  --query 'SecurityGroups[].{Name:GroupName,Ingress:IpPermissions}' \
  --output json

3. OS updates and reboots

Unpatched kernels and OpenSSL/libc libraries are the most boring and most common way servers get owned.

Enable unattended security upgrades:

sudo apt-get install -y unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades

Check /etc/apt/apt.conf.d/50unattended-upgrades includes the security pocket and that Unattended-Upgrade::Automatic-Reboot is set deliberately. On a single box with a real user, automatic reboots at 3am can be fine; on production-critical workers, prefer notification + manual.

Patch now:

sudo apt-get update
sudo apt-get -y dist-upgrade
sudo apt-get -y autoremove --purge

Detect a needed reboot:

[ -f /var/run/reboot-required ] && cat /var/run/reboot-required.pkgs

If the kernel was updated, schedule a reboot. Live-patching (Ubuntu Pro / Livepatch) is great if you’re paying for it, but it doesn’t cover everything — you’ll still need occasional reboots.

Audit:

apt list --upgradable 2>/dev/null
uname -r

4. Admin surface

Every account that can sudo is part of your admin surface. Trim it.

getent group sudo
getent group adm
awk -F: '($3 == 0) {print}' /etc/passwd   # any extra UID 0 account is a finding

Rules:

One sudo user per real human, no shared logins where avoidable.
Service accounts (www-data, postgres, deploy) should not have shell or sudo. Use usermod -s /usr/sbin/nologin <user> if needed.
Rotate or remove SSH keys when someone leaves the team. ~/.ssh/authorized_keys for every login user is your source of truth — review it.
Disable cloud-init’s default password if any (cloud-init shouldn’t set one on official AMIs, but check).
If you must allow sudo without a password for automation, scope it to specific commands in /etc/sudoers.d/, not blanket NOPASSWD: ALL.

Audit:

for u in $(awk -F: '$7 ~ /sh$/ {print $1}' /etc/passwd); do
  echo "== $u =="; sudo cat /home/$u/.ssh/authorized_keys 2>/dev/null
done

5. EC2 metadata service (IMDSv2)

This one is non-negotiable in 2026. The EC2 instance metadata service hands out IAM role credentials. With IMDSv1 enabled, any server-side request forgery (SSRF) bug in your app can pop those credentials and walk into your AWS account.

Force IMDSv2 only, with a low hop limit:

TOKEN=$(curl -sX PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 60")
curl -sH "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/instance-id

If that works but the same call without a token also works, you’re still on IMDSv1.

Enforce v2 on the instance (run from your laptop with the AWS CLI):

aws ec2 modify-instance-metadata-options \
  --instance-id i-xxxxxxxxxxxxxxxxx \
  --http-tokens required \
  --http-endpoint enabled \
  --http-put-response-hop-limit 1

hop-limit 1 means a container or proxy can’t trivially relay a request to the metadata service. If you run Docker with bridge networking, you may need 2 — but start at 1, raise only if needed, and never to 64.

Also: the IAM role attached to the instance should be least privilege. “Read this one S3 bucket and write to this one log group” beats AdministratorAccess every time.

Audit:

aws ec2 describe-instances \
  --query 'Reservations[].Instances[].[InstanceId,MetadataOptions.HttpTokens,MetadataOptions.HttpPutResponseHopLimit]' \
  --output table

Anything where HttpTokens is not required is a finding.

Mid-article CTA

If you’d rather have someone else go through this list on your servers and hand you back a clear report, that’s exactly what Tuck Sentinel QuickCheck does: a one-shot, read-only audit of a single Linux box with prioritized findings and copy-pasteable fixes. You can see what the output looks like in this sample report before deciding.

Back to the checklist.

6. Logging and time sync

You can’t investigate what you didn’t record, and you can’t correlate logs that disagree on what time it is.

Time sync. Ubuntu 22.04+ and Debian 12 ship systemd-timesyncd or chrony. Either is fine, just make sure one is running:

timedatectl
# or
chronyc tracking

If you’re on AWS, the local time source 169.254.169.123 is reliable and low-latency. chrony config example:

server 169.254.169.123 prefer iburst minpoll 4 maxpoll 4

Logging. journald is the default. A few sane settings in /etc/systemd/journald.conf:

Storage=persistent
SystemMaxUse=1G
SystemMaxFileSize=128M
ForwardToSyslog=no

Then:

sudo systemctl restart systemd-journald

For anything beyond a single box, ship logs off the instance — CloudWatch Logs, a Loki/Grafana stack, or any hosted log service. The reason isn’t compliance, it’s that the first thing an attacker tries to do is rm /var/log/* and journalctl --rotate --vacuum-time=1s.

Auditd is worth installing if you want a record of which user ran which command:

sudo apt-get install -y auditd
sudo systemctl enable --now auditd

You don’t need elaborate rules to start; the defaults plus shipping /var/log/audit/audit.log off-box is already a huge upgrade.

Audit:

journalctl --disk-usage
timedatectl | grep 'System clock synchronized'

7. Backups and restore drills

A backup you’ve never restored is a wish, not a backup.

For a small EC2 setup:

Use AWS Backup or scheduled EBS snapshots for the volume(s).
For databases, also take logical backups (pg_dump, mysqldump) on a schedule and copy them to S3 with versioning + lifecycle to Glacier.
Encrypt at rest (EBS encryption + S3 SSE-KMS). On modern AWS regions/accounts, EBS encryption-by-default should be on — check it.
Keep at least one backup copy in a different AWS account or region. Ransomware-style attackers will delete in-region snapshots if they get the chance.

Restore drill — once a quarter, on a throwaway instance:

Pick a recent snapshot/dump.
Spin up a new instance/volume from it.
Verify the app starts and recent data is present.
Time how long it took. That’s your real RTO.

If you’ve never done step 4, you don’t know your RTO; you have a hope.

Audit:

aws ec2 describe-snapshots --owner-ids self \
  --query 'Snapshots[?StartTime>=`2026-01-01`].[SnapshotId,StartTime,VolumeSize,Description]' \
  --output table

8. Docker basics (if applicable)

If you don’t run Docker on the box, skip this. If you do, the most common foot-guns:

Don’t expose the Docker daemon over TCP. 2375 unauthenticated is root-on-box for anyone who can reach it. Use the local socket (/var/run/docker.sock) and SSH for remote control.
Mind the -p flag. -p 5432:5432 binds to 0.0.0.0 and bypasses UFW on most Docker setups (Docker writes its own iptables rules). If you only need the port locally, use -p 127.0.0.1:5432:5432.
Run containers as non-root where possible. USER directive in your Dockerfile, or --user 1000:1000 at runtime.
Pin base images to a digest (FROM ubuntu:24.04@sha256:...) for production, and rebuild on a schedule to pick up CVE fixes.
Don’t bind-mount the Docker socket into containers unless you fully understand that’s equivalent to giving that container root on the host.
Set --read-only and --cap-drop=ALL for containers that don’t need to write to their filesystem or hold extra capabilities; add back only what’s needed.

A useful audit one-liner:

docker ps --format '{{.Names}} {{.Ports}}' | grep -E '0\.0\.0\.0|:::'

Anything in that list is reachable from the public internet (modulo the security group). Decide if that’s intentional.

For containerd/k8s setups this barely scratches the surface — but on a single EC2 box running a few containers, those bullets close ~80% of the cheap holes.

What this is not

Be honest with yourself about what a checklist like this does and doesn’t do.

It is not a penetration test. Nobody is exploiting your application logic, your auth flows, or your business rules here. A pentest is a different (and more expensive) thing.
It is not compliance. SOC 2, HIPAA, PCI, ISO 27001 all require documented policies, evidence collection, access reviews, vendor management, and a lot more. A hardened box is part of that, not a substitute.
It is not a guarantee. New CVEs ship every week. Your application code changes. Someone leaks a key on GitHub. Hardening is a continuous practice, not a one-time event.
It is not opinionated about your app stack. TLS configuration, WAF rules, secrets management, dependency scanning, CI/CD security — all out of scope here.

What it does do: dramatically reduce the set of “stupid ways your server gets owned by a bot at 3am” and give you a baseline you can re-run on every new instance.

End-article CTA

If you got this far and want to skip the manual audit, that’s exactly what I built Tuck Sentinel QuickCheck for: a single-instance, read-only Linux audit that runs the kind of checks above and produces a prioritized report with concrete fixes — no agent left behind, no ongoing access. Take a look at the sample report to see exactly what you’d get.

Either way: run the checklist. Future-you will thank present-you.

About Tuck Sentinel

Tuck Sentinel is a small, focused security tooling project from indie operator Rich Gibbs. It produces practical, no-nonsense audits and content for solo founders and small teams running their own Linux infrastructure — the kind of work most SOC platforms ignore because the deal size is too small. Start with QuickCheck if you want a one-shot review of a single server.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Ubuntu/Debian EC2 hardening checklist (2026)",
  "description": "A practical 2026 hardening checklist for Ubuntu and Debian EC2 instances: SSH, UFW, IMDSv2, updates, logging, backups, and Docker basics.",
  "author": {
    "@type": "Person",
    "name": "Rich Gibbs",
    "url": "https://richgibbs.dev/"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Tuck Sentinel",
    "url": "https://richgibbs.dev/"
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://richgibbs.dev/blog/ubuntu-debian-ec2-hardening-checklist-2026/"
  },
  "image": "https://richgibbs.dev/og/ubuntu-debian-ec2-hardening-2026.png",
  "datePublished": "2026-05-10",
  "dateModified": "2026-05-10",
  "keywords": "ubuntu, debian, ec2, hardening, security, devops, sysadmin, aws, imdsv2, ssh, ufw",
  "inLanguage": "en"
}

The Indie Founder's VPS Security 101

Sun, 10 May 2026 00:22:00 +0000

You shipped the thing. It runs on one Linux box at DigitalOcean or Hetzner or wherever. Customers are starting to show up, and somewhere in the back of your head a little voice is asking: is this thing actually safe?

This guide is for that voice.

It’s written for solo founders and very small teams who are not security professionals but can copy a command into a terminal. The goal is “secure enough that you can sleep” — not “audit-grade fortress.” Those are different jobs, and treating one like the other is how you waste a weekend installing seven intrusion detection tools and shipping nothing for a month.

What “secure enough” looks like for one box

For a single VPS running your SaaS, “secure enough” is a short list:

Nobody can log in as root from the internet.
Logging in requires a key you have, not a password someone could guess.
Only the ports you actually use are open.
The OS gets security patches automatically.
You’d notice if something obviously bad started happening.
If the disk caught fire tomorrow, you could rebuild from a backup before the end of the day.

That’s the whole bar. Everything else is optimization. Hit those six and you’ve already done more than the majority of small-team production servers I’ve seen.

First-day setup

Do these once, when the server is fresh. They take about twenty minutes.

1. Create a non-root user with sudo

Logging in as root is a footgun. One typo and you’ve nuked the box. Make a normal user instead.

# As root, on a fresh server
adduser deploy
usermod -aG sudo deploy

Pick a real password for deploy even though you’ll be using SSH keys — you’ll need it for sudo prompts.

On your laptop, if you don’t already have a key:

ssh-keygen -t ed25519 -C "you@laptop"

Copy it to the server:

ssh-copy-id deploy@your.server.ip

Now log in as deploy and confirm sudo works:

ssh deploy@your.server.ip
sudo whoami   # should print: root

Once you’re sure key login works, lock down SSH. Edit /etc/ssh/sshd_config (or drop a file in /etc/ssh/sshd_config.d/):

sudo tee /etc/ssh/sshd_config.d/99-hardening.conf >/dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
EOF

sudo sshd -t          # test config — must print nothing
sudo systemctl reload ssh

Do not close your existing SSH session yet. Open a second terminal and confirm you can log in fresh. If that works, you’re good. If it doesn’t, you’ve still got the first session to fix things.

3. Turn on the firewall

Ubuntu ships with ufw, which is a friendly wrapper around iptables/nftables. Default-deny inbound, allow only what you need:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

If you don’t run a web server on this box, drop the 80/443 lines. The rule is simple: open a port only when something on the box actually needs to listen on it.

4. Enable automatic security updates

Most successful attacks are not clever zero-days — they’re known bugs in software you forgot to patch. Let the OS patch itself.

sudo apt update
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades   # answer "Yes"

Then check /etc/apt/apt.conf.d/50unattended-upgrades and make sure security updates are uncommented. On Ubuntu the default config already covers ${distro_id}:${distro_codename}-security, which is what you want.

For peace of mind, make it tell you when reboots are needed and when to install them:

sudo tee /etc/apt/apt.conf.d/51auto-reboot >/dev/null <<'EOF'
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";
EOF

Pick a time when nobody’s using the app. Yes, this means the box reboots itself sometimes. That’s fine. Your app should already survive a reboot — and if it doesn’t, that’s a bigger problem than security.

That’s first-day setup. Non-root sudo user, keys-only SSH, default-deny firewall, automatic patching. You’re now ahead of a lot of production servers.

Worried you missed something on first-day setup?

Run a free QuickCheck on your server →

It’s a read-only scan that flags the boring stuff: SSH still allows passwords, port 22 open to the world, no automatic updates configured, sketchy listening services, and so on. No agent, no signup wall. Here’s a sample report if you’d like to see the format first.

What to actually monitor

You don’t need a SIEM. You need a few things you can eyeball once a week (or get a tiny script to email you about). For a single VPS, this short list catches almost everything that matters.

Failed logins

If somebody is hammering your SSH port, this shows it:

sudo journalctl -u ssh --since "24 hours ago" | grep -i "failed\|invalid"

A handful of attempts per day is internet background noise. Thousands per hour from one IP is worth blocking with ufw or installing fail2ban.

Listening ports

What’s actually accepting connections on this box? Run this every so often and make sure nothing surprising is there:

sudo ss -tulpn

You’re looking for things bound to 0.0.0.0: or :::. Anything bound to 127.0.0.1 is fine — only your box can talk to it. The classic mistake: running a dev database with bind = 0.0.0.0 and no password. Don’t do that.

Disk free

Servers don’t usually die from hackers. They die from full disks at 3 AM.

df -h /
du -sh /var/log /var/lib/docker 2>/dev/null

If / is over 80% full, plan on cleaning it up before it hits 100% and your database refuses to write.

Package updates available

Even with unattended-upgrades, it’s worth a manual sanity check now and then:

sudo apt update
apt list --upgradable 2>/dev/null

And: is a reboot pending after a kernel update?

[ -f /var/run/reboot-required ] && cat /var/run/reboot-required

If yes, schedule one. A patched kernel that hasn’t been booted into is just a download.

You can wire any of these into a weekly cron that emails you a one-page digest. Five lines of bash. Don’t overthink it.

Backups and restore drills

This is the boring section everyone skips. Skip it and you have a hobby project, not a business.

The minimum viable backup setup for a single VPS:

Database: nightly dump (pg_dump, mysqldump, or your equivalent), encrypted, sent off-box. To S3, B2, or any object store. Keep at least 7 daily and 4 weekly copies.
User-uploaded files: same deal — sync to object storage on a schedule. restic and rclone both work fine.
Config: keep it in git. If your nginx.conf lives only on the server, it’s already half-lost.

That’s the easy part. Here’s the part people skip:

Actually do a restore. From scratch. On a fresh VPS. Once.

Spin up a new box. Pull last night’s backup. Restore the database. Boot the app. Did it work? How long did it take? What did you forget? (Spoiler: an environment variable, an SSL cert, a cron job, or a system package.)

If you’ve never done this drill, you don’t have backups. You have files you hope will work. There is a meaningful difference, and you really, really don’t want to discover it during an outage.

Re-do the drill at least once a year, or any time you make a big infrastructure change.

Don’t over-do it

There is a tempting path where, in the name of “being thorough,” you install:

An intrusion detection system
A second intrusion detection system in case the first one misses something
A file integrity monitor
A custom auditd ruleset you found on a blog
An EDR agent
A SIEM forwarder

…on a VPS that hosts one Rails app and gets 200 visitors a day.

Don’t. Each of these has a cost: CPU, memory, alert noise you’ll learn to ignore, and your time. For one small box, the basics in this article handle 95% of realistic risk. Adding more tools without tuning them often makes you less secure, because real signals get buried in junk alerts you stop reading.

If your business actually grows into the territory where you need that stuff (regulated data, big customer base, real compliance), you’ll know — and at that point you’ll also have the budget to do it properly. Until then: keep the surface small, keep it patched, and keep watching the four things in the monitoring section.

Common mistakes

The same handful of things bite small-team servers over and over:

Port 22 open to the entire internet with password login still enabled. This is the #1 thing scanners look for. Even with a strong password, you’re contributing to the noise. Keys only.
Logging in as root. Either directly, or via a sudoers rule that means a single mistake takes the whole box down. Make a real user.
Skipping reboots after kernel updates. A patched-but-not-rebooted kernel still runs the old, vulnerable kernel. unattended-upgrades with Automatic-Reboot "true" fixes this for free.
IMDSv1 left enabled on AWS. If you’re on EC2/Lightsail, the legacy instance metadata endpoint can be reached by anything that can make an outbound HTTP request from the box — including a bug in your app. Enforce IMDSv2 (HttpTokens=required) so a token is required to read instance credentials.
Dev services bound to 0.0.0.0. Postgres, Redis, MongoDB, Elasticsearch, a debug UI, that one Jupyter notebook you spun up “just for a sec” — anything that listens on all interfaces with no auth is a free shell waiting to happen. Bind to 127.0.0.1, or at minimum require a password and put it behind the firewall.
No backups, or backups that have never been restored. See previous section. This is the one that ends businesses.
Storing secrets in committed .env files. You’ll forget, push to a public repo, and your API keys are now public. Use a .env.example checked in, and the real .env ignored.

None of these are exotic. All of them are still everywhere.

Worth a free second opinion?

Even after a careful first-day setup, things drift. A teammate enables password auth “just for a minute.” A new service starts listening on 0.0.0.0. Auto-updates silently break and stop running. The point of a periodic external check is to catch that drift before it matters.

Run a QuickCheck on your VPS → — read-only, no install, takes a few minutes. Or look at a sample report first to see what it covers.

What this is not

This article is a sensible starting checklist for one Linux VPS run by one person or a tiny team. It is not:

A replacement for security advice from someone who knows your specific stack and threat model.
A compliance program. If you handle health data, payment data, or anything else regulated, you need more than a blog post.
A guarantee. Nothing in security is. The goal is to make yourself a much less appealing target than the millions of other servers on the internet that haven’t done any of this.

Do the basics, do them well, then go back to building the actual product. That’s the job.

About Tuck Sentinel

Tuck Sentinel is a small operation focused on practical security checks for indie founders and small teams running production on a VPS. We build QuickCheck, a free read-only scan that highlights the boring-but-important configuration issues most one-person ops teams miss. No agents, no upsell maze — just the things worth fixing.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "The Indie Founder's VPS Security 101",
  "description": "A practical, no-nonsense guide for solo founders running one Linux VPS. Lock the doors, watch the right things, and skip the security theater.",
  "author": {
    "@type": "Organization",
    "name": "Tuck Sentinel",
    "url": "https://richgibbs.dev/"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Tuck Sentinel",
    "url": "https://richgibbs.dev/"
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://richgibbs.dev/blog/indie-founder-vps-security-101/"
  },
  "image": "https://richgibbs.dev/og/indie-founder-vps-security-101.png",
  "keywords": "VPS security, indie founder, Linux server hardening, Ubuntu, Debian, SSH, ufw, unattended-upgrades, backups",
  "articleSection": "Security",
  "inLanguage": "en"
}

AWS IMDSv2 Migration Without Breaking Things

Sun, 10 May 2026 00:22:00 +0000

If you have EC2 instances older than a year or two, some of them probably still allow IMDSv1. The Instance Metadata Service is the HTTP endpoint at 169.254.169.254 every EC2 instance can hit to learn about itself: instance ID, region, attached IAM role, and the temporary credentials that come with it. IMDSv1 is the original unauthenticated GET protocol. IMDSv2 is the session-token version that blocks a class of SSRF and confused-deputy attacks from walking off with your IAM Role credentials.

AWS has been nudging everyone toward IMDSv2 for years, but existing fleets, AMIs baked before the change, and ASGs pinned to old launch templates are full of IMDSv1-allowing instances. Migration is conceptually simple — flip a setting per instance — and operationally annoying, because flipping it on the wrong workload breaks credential lookups for SDKs, kubelet, the ECS agent, or your own scripts.

This guide walks through the migration the way an operator actually has to do it: detect what is still using v1, change instances in safe waves, validate, and have a rollback path.

Why Migrate

IMDSv1 is a plain HTTP GET against the link-local address. Anything inside the instance that can make an outbound HTTP request — including a vulnerable web app with SSRF — can read instance metadata, including the IAM Role Credentials path:

GET http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>

That returns short-lived credentials for whatever role is attached to the instance. With IMDSv1, no proof of locality is required. An SSRF in a public-facing service can pivot directly to your IAM credentials.

IMDSv2 changes the protocol in two important ways:

Session tokens. Callers PUT to /latest/api/token for a session token, then send it back as X-aws-ec2-metadata-token. SSRF primitives that only allow GET are blocked.
Hop limit. The token response honors a TTL hop limit. Default is 1, so a container behind a Docker bridge or a pod behind a CNI cannot reach IMDS unless explicitly allowed.

Set IMDSv2 to required and v1 stops responding. That’s the goal state.

What Breaks

The realistic breakage list is short and well-known. Knowing it upfront is most of the migration.

Old AWS SDKs. Anything older than the published cutoffs only knows IMDSv1: AWS CLI v1 < 1.18.x, boto3 < 1.12.x, AWS SDK for Java v1 < 1.11.678, Go SDK v1 < 1.25.38, .NET SDK before late-2019. Modern SDKs auto-negotiate v2 with v1 fallback, but if v2 is required the fallback never engages.
Containers behind Docker bridge or CNI. The default hop limit of 1 denies pods/containers that route through the bridge. Raise the hop limit to 2 — or better, use IRSA on EKS, EC2 Pod Identity, or task roles on ECS so workloads don’t depend on instance metadata at all.
kubelet on self-managed nodes. Older kubelets only spoke v1. Modern EKS-optimized AMIs are fine; legacy kops clusters and old custom AMIs are the usual offenders.
ECS agent. amazon-ecs-init >= 1.50 supports IMDSv2. Old ECS-optimized AMIs not re-rolled in years can fail credential fetch.
CloudWatch / SSM agent. Recent versions fine; very old pinned versions not.
Custom scripts. curl http://169.254.169.254/latest/meta-data/... without a token will 401 once v1 is off.
Third-party agents in old AMIs. Old Datadog, New Relic, Splunk, or backup agents from years-old golden images can be v1-only.

That’s the whole list. Everything else either works on day one or never touched IMDS.

Detect IMDSv1 Use

Don’t flip the switch blind. Find the callers first.

CloudWatch metric: `MetadataNoToken`

Every EC2 instance emits a CloudWatch metric called MetadataNoToken in the AWS/EC2 namespace. It increments every time something on the instance hits IMDSv1. This is the single most useful signal you have.

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name MetadataNoToken \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --statistics Sum \
  --period 3600 \
  --start-time "$(date -u -d '7 days ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time   "$(date -u +%Y-%m-%dT%H:%M:%SZ)"

If Sum across the last 7 days is 0, that instance is not making any IMDSv1 calls and is safe to switch. Anything non-zero means something is still hitting v1.

For a fleet view, query across all instance IDs or use CloudWatch Metrics Insights / Metric Math to graph MetadataNoToken aggregated. Tag the noisy instances and dig in.

Inventory: which instances even allow v1?

aws ec2 describe-instances \
  --query 'Reservations[].Instances[].{
    Id:InstanceId,
    State:State.Name,
    HttpTokens:MetadataOptions.HttpTokens,
    HopLimit:MetadataOptions.HttpPutResponseHopLimit,
    Endpoint:MetadataOptions.HttpEndpoint
  }' \
  --output table

HttpTokens is what you care about. It will be one of:

optional — IMDSv1 still allowed (the thing you’re trying to remove)
required — IMDSv2 only (the goal state)

A simple “what’s left?” query:

aws ec2 describe-instances \
  --filters "Name=metadata-options.http-tokens,Values=optional" \
            "Name=instance-state-name,Values=running" \
  --query 'Reservations[].Instances[].InstanceId' \
  --output text

CloudTrail and VPC flow logs

CloudTrail does not log calls to IMDS itself — those never leave the instance. What it does show is the AWS API calls made with the credentials IMDS handed out, via userIdentity.sessionContext and the accessKeyId of the temporary credentials. Useful for finding workloads still authenticating via instance role that should have moved to IRSA or task roles.

VPC flow logs do not see 169.254.169.254 traffic either — link-local stays inside the host. Stick to MetadataNoToken plus the inventory query.

On-host detection

If you have shell access to a candidate instance, run something quick before you change settings:

# Try IMDSv1 — if this returns data, v1 is still on
curl -s -o /dev/null -w "%{http_code}\n" \
  http://169.254.169.254/latest/meta-data/instance-id

# Try IMDSv2 — should always return 200 once v2 is supported
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/instance-id

To find callers on a host, auditd rules on connects to 169.254.169.254 plus ss -tnp snapshots usually identify the offending process. On a Kubernetes node, look at old DaemonSets and sidecars first.

Migration Steps

The flow that has worked reliably for small and mid-size fleets:

1. Baseline and freeze new IMDSv1

Set account-level defaults so anything launched from now on is IMDSv2-required and any new AMIs are also v2-required:

# Default IMDS options for new instances in this region
aws ec2 modify-instance-metadata-defaults \
  --http-tokens required \
  --http-put-response-hop-limit 2 \
  --http-endpoint enabled

# Default for newly-registered AMIs
aws ec2 modify-image-attribute \
  --image-id ami-xxxxxxxxxxxxxxxxx \
  --imds-support v2.0

Use modify-image-attribute --imds-support v2.0 on each AMI you control. Once set, instances launched from that AMI get v2-required automatically.

Also set the launch template / Auto Scaling group launch template versions to require IMDSv2:

aws ec2 create-launch-template-version \
  --launch-template-id lt-0123456789abcdef0 \
  --source-version 1 \
  --launch-template-data '{
    "MetadataOptions": {
      "HttpTokens": "required",
      "HttpPutResponseHopLimit": 2,
      "HttpEndpoint": "enabled"
    }
  }'

This stops the bleeding. Old instances may still be on v1, but no new ones are.

2. Sort instances into waves

Pull the list of HttpTokens=optional instances. Group them by:

Wave 0 — disposable. Stateless workers, batch nodes, dev/test. Cheap to break, cheap to recreate. Migrate first.
Wave 1 — replaceable through autoscaling. ASG-managed web tiers, ECS/EKS nodes. New launches are already v2-required; old nodes get rotated out by simply triggering an instance refresh.
Wave 2 — stateful or hand-built. Bastions, databases on EC2, single-instance services, anything pet-shaped.

For waves 0 and 1, prefer rotation over modification — relaunch from updated launch templates rather than mutating live instances. Less risky, fewer surprises.

3. Optional: try `optional` → `required` with a hop bump

For a stateful instance you cannot easily relaunch, raise the hop limit first (so containers keep working), then flip tokens to required:

# Step A: bump hop limit while still allowing v1
aws ec2 modify-instance-metadata-options \
  --instance-id i-0123456789abcdef0 \
  --http-put-response-hop-limit 2 \
  --http-tokens optional \
  --http-endpoint enabled

# Verify everything still works for at least one full agent cycle
# (CloudWatch agent, SSM agent, your app, container credential lookups)

# Step B: require v2
aws ec2 modify-instance-metadata-options \
  --instance-id i-0123456789abcdef0 \
  --http-tokens required

Watch MetadataNoToken after step A — if any callers are still using v1, they will keep showing up in the metric. Fix or upgrade them before step B.

4. Roll Auto Scaling groups

After the launch template is updated:

aws autoscaling start-instance-refresh \
  --auto-scaling-group-name my-asg \
  --preferences '{"MinHealthyPercentage": 90, "InstanceWarmup": 300}'

For EKS managed node groups, the equivalent is updating the node group to a new launch template version and letting AWS drain and replace nodes. For ECS, update the capacity provider’s launch template and either drain instances or wait for natural turnover.

5. Sweep and confirm

After each wave, re-run the inventory query and the MetadataNoToken check. Anything still on optional should have a name attached to it and a reason.

Mid-article CTA: Want a one-shot read-only audit that tells you which of your EC2 instances still allow IMDSv1, plus a dozen other quiet AWS posture issues? That’s exactly what QuickCheck is built for. Skim a sample report before you decide.

Validation

After you flip an instance, you want fast confirmation it’s actually on v2 and nothing is silently failing.

Confirm v2-required at the API level

aws ec2 describe-instances \
  --instance-ids i-0123456789abcdef0 \
  --query 'Reservations[0].Instances[0].MetadataOptions'

Expected:

{
  "State": "applied",
  "HttpTokens": "required",
  "HttpPutResponseHopLimit": 2,
  "HttpEndpoint": "enabled",
  "HttpProtocolIpv6": "disabled",
  "InstanceMetadataTags": "disabled"
}

State: applied matters — pending means the change has not landed yet.

Confirm v1 is actually rejected on the host

# Should now return 401 Unauthorized
curl -s -o /dev/null -w "v1: %{http_code}\n" \
  http://169.254.169.254/latest/meta-data/instance-id

# Should return 200 with the instance ID
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  -w "\nv2: %{http_code}\n" \
  http://169.254.169.254/latest/meta-data/instance-id

v1: 401 and v2: 200 is the correct pair.

Confirm credentials still resolve

TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
ROLE=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/)
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE \
  | head -c 200; echo

You should see AccessKeyId, SecretAccessKey, Token, and Expiration.

Confirm app-level health

aws sts get-caller-identity from the instance using whichever SDK your workloads use.
Container credential lookups from inside one container per host (especially if you raised the hop limit).
ECS agent: curl -s http://localhost:51678/v1/metadata should still respond.
kubelet health: nodes still Ready, image pulls from ECR still work.

Confirm `MetadataNoToken` is zero

After 24–48 hours on v2-required, MetadataNoToken should be a flat zero line. If not, something is still calling v1 — which now means it is failing. Find it.

Rollback

You want this written down before you need it.

Per-instance rollback is one CLI call:

aws ec2 modify-instance-metadata-options \
  --instance-id i-0123456789abcdef0 \
  --http-tokens optional \
  --http-put-response-hop-limit 2 \
  --http-endpoint enabled

That re-enables IMDSv1 immediately, no instance restart required. It is the same call you used to flip forward — just with optional instead of required.

Launch template rollback: revert to the previous version.

aws ec2 modify-launch-template \
  --launch-template-id lt-0123456789abcdef0 \
  --default-version 1

Auto Scaling rollback: trigger another instance refresh against the previous LT version, or roll forward with a fixed template once you know what broke. Avoid the temptation to mutate live ASG instances; relaunch is cleaner.

For account-level defaults, you can re-relax them, but generally do not. Once new instances are v2-required by default, leave that in place even if you have to roll back individual stragglers.

QuickCheck CTA

If you’d rather not hand-roll the inventory queries and CloudWatch checks across every account and region, QuickCheck runs a read-only, one-shot review of your AWS posture and produces a plain-English report. IMDSv1 stragglers are one of the dozen things it surfaces — alongside open security groups, public S3, missing MFA on root, untagged keys, and a few other “you’d rather know” items. See an example in the sample report. It is not magic and not a replacement for proper cloud security tooling, but it is a fast way to know where you stand before you start migrating.

What This Is Not

To set expectations clearly:

This is not a penetration test. It is a configuration migration, not an adversarial exercise.
This is not a certification or compliance attestation. Migrating to IMDSv2 is a control improvement; it does not by itself constitute SOC 2, ISO 27001, PCI, or anything else. Your auditor still wants the artifacts they always want.
This is not a guarantee. Cloud security is a portfolio of controls. IMDSv2 closes one well-known SSRF-to-credentials path; it does not address misconfigured security groups, overly broad IAM policies, leaked long-lived keys, or vulnerable application code. Treat it as one item on the list.
This is not a substitute for moving workloads to IRSA / EC2 Pod Identity / ECS task roles where those fit. IMDSv2 makes instance metadata safer; per-workload identity is still the better long-term answer for containers.

Migrate to IMDSv2 because it is cheap, well-understood, and removes a real foot-gun. Then keep going.

About Tuck Sentinel

Tuck Sentinel is the security-focused side of an indie operator workshop by Rich Gibbs. It builds small, sharp tools — like QuickCheck — for founders and small teams who want a competent read of their cloud posture without an enterprise platform. The bias: fast, honest, read-only assessments and migrations you can actually finish.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "AWS IMDSv2 Migration Without Breaking Things",
  "description": "A practical, indie-founder guide to migrating EC2 instances from IMDSv1 to IMDSv2 without breaking SDKs, containers, kubelet, or the ECS agent.",
  "author": {
    "@type": "Organization",
    "name": "Tuck Sentinel"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Tuck Sentinel",
    "url": "https://richgibbs.dev/"
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/blog/aws-imdsv2-migration-without-breaking-things"
  },
  "image": "https://example.com/og/aws-imdsv2-migration.png",
  "articleSection": "Cloud Security",
  "keywords": "AWS, EC2, IMDSv2, IMDSv1, cloud security, IAM, SSRF, migration",
  "about": [
    { "@type": "Thing", "name": "AWS EC2 Instance Metadata Service" },
    { "@type": "Thing", "name": "IMDSv2" },
    { "@type": "Thing", "name": "Cloud Security Posture" }
  ]
}

Rich Gibbs

Ubuntu/Debian EC2 hardening checklist (2026)

Why this checklist

Threat model assumptions

1. SSH

2. Firewall and listeners

3. OS updates and reboots

4. Admin surface

5. EC2 metadata service (IMDSv2)

Mid-article CTA

6. Logging and time sync

7. Backups and restore drills

8. Docker basics (if applicable)

What this is not

End-article CTA

About Tuck Sentinel

The Indie Founder's VPS Security 101

What “secure enough” looks like for one box

First-day setup

1. Create a non-root user with sudo

2. Set up SSH keys and disable password login

3. Turn on the firewall

4. Enable automatic security updates

Worried you missed something on first-day setup?

What to actually monitor

Failed logins

Listening ports

Disk free

Package updates available

Backups and restore drills

Don’t over-do it

Common mistakes

Worth a free second opinion?

What this is not

About Tuck Sentinel

AWS IMDSv2 Migration Without Breaking Things

Why Migrate

What Breaks

Detect IMDSv1 Use

CloudWatch metric: MetadataNoToken

Inventory: which instances even allow v1?

CloudTrail and VPC flow logs

On-host detection

Migration Steps

1. Baseline and freeze new IMDSv1

2. Sort instances into waves

3. Optional: try optional → required with a hop bump

4. Roll Auto Scaling groups

5. Sweep and confirm

Validation

Confirm v2-required at the API level

Confirm v1 is actually rejected on the host

Confirm credentials still resolve

Confirm app-level health

Confirm MetadataNoToken is zero

Rollback

QuickCheck CTA

What This Is Not

About Tuck Sentinel

CloudWatch metric: `MetadataNoToken`

3. Optional: try `optional` → `required` with a hop bump

Confirm `MetadataNoToken` is zero