EasyStart AMI security baseline
EasyStart is built to reduce default exposure on day one: AWS Systems Manager (SSM) access instead of open inbound admin ports, least-privilege service identities, hardened service/runtime permissions, and AMI handoff hygiene.
SSM-first administrationNo SSH by defaultReduced inbound exposureLeast-privilege defaults
What’s included / what’s not
Included: baseline host hardening, OpenClaw service hardening, secrets hygiene for image creation, and launch-time guardrails for a shareable Amazon Machine Image (AMI).
Not included: your ongoing security operations, your network design, your incident response process, your compliance controls, or your account-specific permissions model.
This does not replace your AWS controls
You are still responsible for security groups, IAM policies, log monitoring, key management, backup strategy, and any required compliance controls in your own environment.
Security baseline details
What we did
- We made AWS Systems Manager (SSM) Session Manager the intended way to administer the server.
- We verified the SSM agent is running so you can connect without opening inbound ports.
Why it matters
- If you don’t need inbound admin ports (like SSH), you dramatically reduce what attackers can probe from the internet.
What we did
- We stopped the SSH service and disabled it so it won’t start on reboot.
- We also masked it, which is stronger than “disabled” (it prevents accidental re-enabling).
Why it matters
- SSH is a common target. Removing it from the picture eliminates an entire class of password/key and remote-login attacks.
What we did
- Enabled Ubuntu’s built-in firewall tool (UFW) with:
- Default: deny all inbound traffic
- Default: allow outbound traffic
- Allow loopback traffic (the computer talking to itself)
- Block spoofed loopback traffic (deny
127.0.0.0/8coming from non-loopback interfaces)
Why it matters
- “Deny inbound by default” ensures services can’t be reached from the network unless you explicitly allow them.
- Blocking spoofed loopback helps prevent certain tricks where a remote host pretends to be “localhost”.
What we did
- Configured the OpenClaw Gateway to bind only to loopback (
127.0.0.1/::1) and a specific port (18789). - Disabled mDNS/discovery features (broadcast discovery) in the baseline config.
- Installed the gateway service, but the handoff AMI is intended to ship with the gateway disabled/stopped until the new operator runs onboarding and explicitly enables it.
Why it matters
- “Loopback-only” means the gateway is reachable only from the same machine, not from the VPC, not from the internet.
- Shipping the AMI with the service stopped helps prevent accidental exposure before configuration is complete.
What we did
- Created a dedicated
openclawservice user (separate from admin users likeubuntuorssm-user). - Kept OpenClaw state under
/var/lib/openclaw(owned by theopenclawuser). - Created a separate
linuxbrewuser for Homebrew so tooling installs don’t mix with the OpenClaw runtime identity.
Why it matters
- If OpenClaw (or any dependency) is compromised, the damage is limited to what the
openclawuser can access—not full system administrator access.
What we did
- Created directories with restrictive permissions (often “owner-only”):
- OpenClaw state and workspace: accessible only by
openclaw - OpenClaw logs: accessible only by
openclaw - Build logs: restricted to
root
- OpenClaw state and workspace: accessible only by
- Set the main OpenClaw config file to owner-only read/write (permission
0600) and owned byopenclaw.
Why it matters
- Sensitive configuration and runtime state shouldn’t be readable by other users on the machine.
- This also reduces accidental leakage when troubleshooting.
What we did
- Installed the OpenClaw CLI in a controlled location under
/opt/openclaw/.... - Created a wrapper at
/usr/local/bin/openclawso that when an operator typesopenclaw ..., it:- runs the real CLI as the
openclawuser - uses the expected state/config paths
- avoids common “permission” or “wrong PATH” surprises
- runs the real CLI as the
Why it matters
- Operators can use OpenClaw without needing to understand Linux user permissions.
- It reduces the chance someone accidentally runs OpenClaw as “root” or stores data in the wrong place.
What we did
We configured the OpenClaw gateway service with “sandbox” protections, including:
- NoNewPrivileges: prevents the service from gaining extra privileges
- PrivateTmp: gives the service its own temporary directory
- ProtectSystem=strict and related settings: makes much of the OS filesystem read-only to the service
- Drops Linux capabilities (no special kernel privileges)
- Restricts what the service can write to (only the OpenClaw state + log paths)
- Uses a restrictive default file-creation mask (UMask=0077)
Why it matters
- Even if the service is exploited, these controls make it harder to:
- modify the operating system
- access other users’ files
- tamper with sensitive system areas
What we did
- The AMI does not include:
- Telegram bot tokens
- OAuth credentials
- pairing approvals / identity material
- When Telegram is configured later, token is stored in a file readable only by
openclaw
Why it matters
- A shared image must not contain credentials. Otherwise anyone with access to the image could impersonate the bot/account.
What we did
- Removed transient runtime state (keeping the baseline config), such as:
- identity and credential-like folders
- caches and other runtime-generated artifacts
- Truncated/removed OpenClaw logs produced during testing
- Rechecked file permissions before creating the AMI
Why it matters
- The AMI-sourced instance at first-boot should be clean for the new user, not activity, tokens or identity data from image creation/validation.
What we did
- Kept OpenClaw unable to install OS packages by default (no persistent sudo access, and the gateway service remains sandboxed).
- Implemented a time-limited, allowlisted “maintenance window” that can be opened only by a human operator via AWS Systems Manager (SSM):
- The operator unlocks installs for a short period (for example, 10 minutes) and specifies exactly which package names are allowed.
- During that window, OpenClaw can request an install (for example, “install nginx”) without the user needing to know apt syntax.
- The window auto-locks after the time limit, and can also be locked manually immediately after the work is done.
- Added an OpenClaw skill so the bot follows the same safe workflow every time (no reliance on model memory).
Why it matters
- Reduces risk from prompt injection or accidental changes that could weaken the system.
- Prevents unexpected installs unless a human explicitly allowlists them for a short, controlled period.
What we did
- Required Instance Metadata Service v2 (IMDSv2) so instance metadata requires tokens.
- Built to a shareable Amazon Machine Image (AMI) requirement by targeting an unencrypted root volume so the AMI can be shared (recipients should encrypt at launch).
- Used encrypted storage during build: while the shared AMI is unencrypted for portability, the build Amazon Elastic Compute Cloud (EC2) instance is encrypted when created from the AMI (per your build setup).
- Applied AWS network-level inbound blocking: no inbound ports are allowed at the AWS layer, so even if someone opens a port on the OS, it is still not reachable from outside.
Why it matters
- IMDSv2 reduces credential theft risk from certain server-side request forgery (SSRF) paths.
- The AMI stays shareable while still supporting encryption at launch based on the recipient’s policies.
- AWS security group and networking controls provide a backstop even if an OS-level setting is misconfigured.
Continue your security planning
Read the OpenClaw security guide and OpenClaw troubleshooting guide for practical next steps.