SSRF hardening, api-key auth, rate limiting
This service takes a URL from a caller and returns the body, which makes it an SSRF primitive and a general-purpose fetch relay. It runs on venus, the fleet hub host. Required before it is exposed: (1) api-key auth on every request, no anonymous path, keys per-agent so use is attributable and revocable; (2) egress denylist resolved AFTER DNS resolution and re-checked on every redirect hop - block loopback, RFC1918, link-local 169.254.0.0/16 including the 169.254.169.254 metadata endpoint, IPv6 equivalents (::1, fc00::/7, fe80::/10); (3) redirect cap and no automatic protocol downgrade or scheme switch to file:// gopher:// etc, http and https only; (4) response size cap and request timeout; (5) per-key rate limit. Also decide and record whether responses are cached and for how long, since a cache turns the service into a store of third-party content. Rationale: whey holds the fleet's only GCABA VPN tunnel and Tailscale install - a fetch relay that can be pointed at internal addresses is a lateral-movement tool, not just a convenience.
Activity
-
parent=#3338
-
API dropped by Elazar 2026-09-04 in favour of a local script. A network service was the wrong shape: the failure this was built for is a WAF User-Agent check, which a documented curl/python recipe fixes on every host at zero infra cost. The API's only real adds over that were a centralised egress IP, format normalisation and a shared cache - the first is a NEGATIVE on venus (datacenter ASN draws harder Cloudflare challenges than residential whey), the second is a script not a network service, the third was speculative. Replaced by getpage.py in ~/.local/bin (sh.git, already on PATH on whey/venus/lezama), tracked in project agent-ops. Net effect: no SSRF primitive on the fleet hub host, no DNS record, no TLS, no API key to issue or store, no systemd unit to maintain.