Host Security

Overview

The UnoLock container does not harden the host or configure its firewall for you. Securing the server, virtual machine and container runtime is the operator's responsibility. Secure the host before you expose the node publicly, and keep it secured for as long as the node runs.

Follow your operating system and hosting provider's hardening guidance, then apply the baseline below. See also Operator Responsibilities and Security Model.

Host baseline

Area	What to do
Dedicated host	Use a dedicated, supported Linux host. Do not run unrelated public services or workloads with access to the Docker socket.
Patching	Keep the operating system and container engine patched. Apply security updates through a recorded maintenance process. Reboot testing is part of the recovery plan.
Time	Keep system time synchronized. WebAuthn, TLS, bootstrap codes, registration codes and signed grants all depend on reliable time.
SSH	Restrict SSH to named administrators using SSH keys or equivalent strong authentication. Use least-privilege accounts. Disable unused accounts and services.
Docker access	Restrict Docker access to trusted administrators. Do not publish the container-engine socket.
Firewall	Default-deny inbound traffic except the administration paths the host needs and public TCP 80 and 443 for the node, plus TCP 9001 if you keep the default Tor relay. Do not publish the internal node, lookup, database or Tor control sockets.
Storage	Put the data volume and backup target on storage with capacity monitoring.
Logs	Configure bounded host and container log retention according to your audit and privacy policy.
Recovery material	Protect backups and recovery material, and keep them separate from each other.

The node image includes and controls its own Node.js, Tor, Caddy and native dependency versions. Do not replace those components inside a released image. Apply an updated image from the release notes using Upgrading Your Node.

Check Diagnostics for host warnings

Sign in to https://node.example.com/admin and unlock the node.
Open Diagnostics and refresh Node Health.
Review the host-security warnings, including swap and core dumps, and resolve them before public use.
Investigate every other failed check.

Warning

Review the swap and core dump warnings in Diagnostics before you expose the node publicly. Both can expose process memory.

Ports the node uses

Port	Purpose
TCP 80	HTTP-to-HTTPS redirects and HTTP certificate validation by the bundled Caddy proxy
TCP 443	HTTPS access to the admin console and Safes
TCP 9001	Default non-exit Tor relay. See Tor.

Keep ports 80 and 443 behind the bundled TLS proxy or an equivalently reviewed reverse proxy. The node listener and lookup listener stay on loopback inside the container.

Monitoring

The node does not ship a complete external monitoring or paging stack. Diagnostics is an authenticated point-in-time view. Set up separate host alerts for:

container exit or restart;
filesystem capacity;
certificate expiry;
DNS and HTTPS reachability;
failed backup jobs;
missed health-review intervals.

Monitoring must use aggregate status only. Do not export Safe, address, archive, onion-route, filename or activity metadata.

Routine checks

Each day

Confirm the container is running and has not restarted unexpectedly:

sudo docker ps --filter name=unolock-node
sudo docker inspect unolock-node --format '{{.RestartCount}} restarts; {{.State.Status}}'

Open Diagnostics, refresh Node Health, and investigate every failed check.
Check host and volume capacity. Leave headroom for database sidecars, uploads, archive staging, certificate renewal and an upgrade:
```
df -h
sudo docker system df
```

Review a bounded log window for warnings and failures:

sudo docker logs --since 24h --tail 1000 unolock-node

Each week

Verify DNS, public HTTPS, certificate validity and the admin sign-in path from your administration browser.
Check Clients for a required rebuild or signature problem.
Review Safe registration codes in Safes and disable unused codes.
Confirm the expected Tor and federation state in Diagnostics, without copying onion addresses or user metadata into tickets or chat.

Keep secrets and metadata private

Logs and diagnostics are security-sensitive metadata. Sanitize them before sharing. Never place these values in shell history, issue trackers, screenshots or shared logs:

admin setup codes, Safe registration codes or recovery codes;
Administrator PINs or authenticator recovery material;
TLS private keys or protected node configuration;
Safe identifiers, Receive Addresses, archive identifiers, filenames, onion addresses or user activity.

Use files with mode 0600 for secret maintenance input. Keep the recovery security key, exact node config, encrypted-data backup, operator-managed TLS key and DNS control separately protected, so that one stolen store is not a complete recovery kit.

Respond to a suspected compromise

Fence the node: stop it and prevent it from restarting or receiving traffic.
Preserve logs and immutable release identifiers, such as the installed image ID.
Recover on a clean host.
Do not reuse potentially exposed admin, TLS or recovery secrets.

FAQs

Does the UnoLock container configure my firewall?

No. The container does not harden the host or configure its firewall. Configure the provider firewall and the host firewall yourself.

Why does Diagnostics warn about swap and core dumps?

Active swap and core dump settings can write process memory to disk. Review these host-security warnings in Diagnostics and resolve them before public use.

Can I run other services on the same server?

Use a dedicated host. Do not run unrelated public services or workloads with access to the Docker socket.

Is Diagnostics enough to monitor my node?

No. Diagnostics is a point-in-time check. Set up separate host alerting for container restarts, disk capacity, certificate expiry, reachability and backup failures.

Can I update Node.js or Tor inside the container?

No. The image controls those versions. Apply an updated release image using Upgrading Your Node.

Back to Self-Hosted Overview