FamReynaBrain/projects/factory/emi-production-perimeter-audit-2026-08-18.md

EMI production perimeter audit — 2026-08-18

Scope and verdict

Read-only perimeter follow-up on aeroreyna@192.168.68.119 (emiserver). Inspected only non-secret listener/firewall service facts, Docker published-port/network/container metadata, detected proxy metadata, DNS, and unauthenticated HTTP GET, HEAD, and OPTIONS behavior. No authentication, form submission, secret/environment/configuration reading, dirty Compose diff inspection, source modification, service/container/proxy/firewall change, or Mac-mini backend WIP interaction occurred.

Verdict: perimeter is not production-clean. Authentication controls prevent unauthenticated root access to the backend, and the tested origins were not granted browser CORS read access. However, the EMI backend remains directly published on every IPv4 and IPv6 interface at TCP 3001; the effective UFW rule policy could not be read without elevation; and the intended public frontend/API origin and proxy path remain unproven. Do not infer a proxy-only or firewall-restricted production posture.

Verified exposure controls

• ufw.service is enabled and active (exited). This verifies that UFW is installed/enabled, not which allow/deny rules are effective; unprivileged ufw status, iptables, and nft rule reads were denied and no elevation was attempted.
• The backend container is emi-backend-app-1 (Compose project emi-backend, service app) with restart policy always.
• Direct, unauthenticated backend root requests at http://127.0.0.1:3001/ returned 401 Unauthorized for both GET and HEAD; neither response carried a redirect location. The HEAD probe's status/header result is valid, although curl reported a transfer-length warning after the server advertised a body.
• The same direct backend preflight (OPTIONS, Origin: https://emmint.com, Access-Control-Request-Method: GET) returned 204 No Content, Vary: Origin, Access-Control-Request-Headers, Access-Control-Allow-Credentials: true, and Access-Control-Allow-Methods: GET,HEAD,PUT,PATCH,POST,DELETE.
• Direct preflights for https://emmint.com, https://www.emmint.com, https://florida.emmint.com, https://api.emmint.com, and https://invalid.example returned no Access-Control-Allow-Origin. Thus none of those tested browser origins was granted cross-origin read access by the direct backend response.
• api.emmint.com resolved to 76.108.184.110. Its unauthenticated HTTPS root behavior was 302 Found with Location: /login for both GET and HEAD; its preflight was 204 No Content. The public responses identify an upstream Caddy (Via: 1.1 Caddy) and Express application; no Access-Control-Allow-Origin was observed on the tested public preflight.

Listener, container, network, and proxy facts

• emi-backend-app-1 publishes 3001/tcp as 0.0.0.0:3001 and [::]:3001, confirmed both by Docker and the host listener table. It is not loopback-only.
• The backend is attached to Docker bridge emi-backend_default, whose metadata is internal=false, attachable=false, and IPv6 disabled. The container has a read-write bind mount from /home/aeroreyna/EMI-Backend to /app, a read-write node-modules volume, and ReadonlyRootfs=false.
• Other all-interface TCP listeners observed on .119 were 22, 222, 2283, 3000, 8085, 9000, 9001, 9443, and 18789–18790. Docker metadata attributes these to Immich, Gitea, Nextcloud, Authentik, Portainer Agent, and OpenClaw as applicable. This audit makes no claim that each is reachable outside the host/LAN because effective firewall and upstream NAT policy were not readable.
• The Paseo daemon listens only on 127.0.0.1:6767; an OpenCode process listens only on 127.0.0.1:45243.
• No Caddy, Nginx, Traefik, HAProxy, or Apache systemd unit was found. Apache processes were present, but no port 80/443 listener was present in the host listener table. No Docker reverse-proxy container was present. The Caddy observed at public api.emmint.com is therefore not verified as a local .119 service/container; its upstream placement and forwarding policy remain unresolved.
• Documented frontend hostnames resolve away from the .119 LAN address: emmint.com and www.emmint.com to 198.175.150.40, and florida.emmint.com to 35.164.64.246. Their unauthenticated HTTPS root behavior was consistent with external WordPress/LiteSpeed (emmint.com: GET/HEAD 301 to www; OPTIONS 200), www.emmint.com (GET/HEAD/OPTIONS 200), and an external Caddy-backed site for florida.emmint.com (GET/HEAD/OPTIONS 200). They are not verified .119 reverse-proxy frontends.

Unresolved exposure and CORS findings

1. Direct API exposure remains the primary perimeter finding. TCP 3001 is published to all host interfaces and the Docker network is non-internal. UFW's active rule set and the router/NAT policy were intentionally not elevated/read, so this audit cannot establish whether LAN or Internet clients can reach the direct port.
2. Public API proxy topology is unresolved. api.emmint.com presents Caddy/Express behavior and redirects unauthenticated GET/HEAD to /login, but its public address does not identify the local .119 LAN endpoint and no local Caddy listener/container was found. It is not proven whether the proxy protects all API paths, which upstream it uses, or whether direct 3001 bypasses it.
3. CORS is deny-by-observation, not intent-verified. Every tested direct preflight, including https://emmint.com, lacked Access-Control-Allow-Origin; the tested public API preflight also lacked it. This blocks browser cross-origin reads for those requests, but it does not establish the intended credentialed frontend origin or prove that a production frontend can call the API successfully. Access-Control-Allow-Credentials: true is present without a tested allowed origin.
4. Published public websites are not evidence of an API frontend. The documented emmint.com, www.emmint.com, and florida.emmint.com hostnames resolve to third-party/external web endpoints rather than verified .119 proxy listeners. No documented production frontend hostname was shown to be an allowed CORS origin for this API.

Context received after audit

Authoritative infrastructure context: api.emmint.com is served by Caddy on FamReynaServer .110, which routes to the EMI backend on .119. That shared Caddy/Authentik/DNS/firewall layer is outside the EMI project's ownership. This report's observation that the proxy placement was unresolved is therefore superseded as a project-boundary question: the route may be documented and health-verified by EMI work, but must not be modified by an EMI task. Any proxy remediation needs a separately scoped shared-infrastructure task and explicit approval.

Minimal remediation options — require explicit human approval

Choose only after confirming the intended API hostname, frontend origin(s), required credential mode, and LAN/Internet exposure policy:

1. Proxy-only API: bind Docker 3001 to loopback only (or remove the host publication), then explicitly proxy the required HTTPS API hostname through the approved reverse proxy. Review the dirty Compose change in an isolated worktree before any lifecycle action.
2. Firewall-restricted direct API: retain the published port only if necessary, and approve explicit UFW/router rules limiting 3001 to the named trusted proxy/LAN sources. Verify from an authorized external and LAN vantage point after the approved change.
3. Explicit CORS allowlist: configure only the confirmed HTTPS frontend origin(s), preserve Vary: Origin, and test allowed and denied preflights plus an unauthenticated request through the real proxy. Do not use a wildcard origin with credentialed requests.

Any option requires separate approval for configuration review/change, rebuild/recreate/restart, deployment, or firewall/proxy modification. The Mac-mini backend CORS WIP remains untouched and uncommitted.