Database, cache, queue and management service boundaries

Move from a reachable socket to a minimal proof of unintended service authority using synthetic records and paired identities.

Used in these playbooks#

Setup and invariant#

Record one service row: owner, exact IPv4 or IPv6 address, hostname, transport, port, product build, authentication method and intended access boundary. A hostname in web scope does not automatically include every backing service. Prepare a restricted account, an allowed account and one synthetic key, row, queue or management fixture. A network position or low-privilege account must not gain the protected data or administrative operation outside its stated permissions.

Use version banners only to select hypotheses. Vendor backports and disabled features can invalidate a banner-to-CVE match. First establish a normal connection, intended authenticated operation and expected rejection. Keep source network and timestamps constant when comparing identities.

Procedure#

1. Separate reachability from authority. Record a connection outcome without treating an open port as a vulnerability. Check whether the service is intentionally public, behind mutual TLS or protected by native authentication. A health response is not administrative access.

2. Use one exact resource. For Redis, request only the agreed canary key; do not run keyspace enumeration, configuration changes or flush commands. Compare anonymous access, the permitted principal and the restricted principal. Redis network protection, authentication, ACLs and TLS solve different parts of this boundary. Redis security

3. Check connection rules and database grants independently. In PostgreSQL, examine the owner-supplied host-based authentication rule selected by connection type, source, database and user. Establish whether authentication genuinely happened, then test permission for one fixture row. A trusted local administration connection is not evidence of internet exposure. PostgreSQL host authentication

4. Model queues as stateful resources. In an isolated broker, create two fixture virtual hosts and named queues. Compare whether A can declare, publish to or consume B's fixture according to the contract. Use a single marked message and account for acknowledgement behavior; consuming production messages changes application state. Broker login does not imply permissions across all virtual hosts. RabbitMQ access control

5. Evaluate management APIs and network parity. For an owned Docker daemon, review listener and client authentication configuration; use only an approved metadata endpoint for the initial proof. Do not create privileged containers to confirm broad authority on production. Compare an explicitly owned IPv4 and IPv6 service only when both are in scope: different exposure is relevant when it defeats the same promised restriction. Docker daemon protection

Command card#

The Redis endpoint below is an isolated local fixture. The environment removal prevents an inherited password from contaminating the unauthenticated control. The database example uses the supplied test account and private password file, with TLS identity verification and a read-only transaction.

env -u REDISCLI_AUTH timeout 10 redis-cli \
  -h 127.0.0.1 -p 16379 --raw GET bounty:canary

timeout 15 psql -X -w \
  "host=db.fixture.example port=5432 dbname=bounty_fixture user=lab_low sslmode=verify-full sslrootcert=./fixture-ca.pem connect_timeout=5 options='-c statement_timeout=3000'" \
  -v ON_ERROR_STOP=1 \
  -c "BEGIN READ ONLY; SELECT marker FROM bounty_canary WHERE id=1; ROLLBACK;"

An unauthenticated marker demonstrates read access to that fixture. NOAUTH, NOPERM, connection failure and an absent value mean different things; compare the known-good control. For PostgreSQL, distinguish TLS failure, authentication failure and SQL permission denial. Credentials can come from a password file even with -w; that flag disables prompting, not password authentication. Redis CLI, PostgreSQL connection parameters, psql options

Evidence, false positives and cleanup#

Save the endpoint, source, verified account, precise operation, response, fixture ownership and comparison. Public service banners, intentionally anonymous health checks and intended shared queues are not equivalent to data exposure. Reuse authorization matrices for per-resource checks and identity/session testing for revocation behavior.

• Allowed and denied controls have working connectivity.
• No wildcard reads, real queue consumption or configuration mutation.
• Network access distinguished from authentication and authorization.
• Lab result separated from unverified production applicability.
• Canary records, messages and test accounts removed using their recorded identifiers.

Vulnerability reverse references#

• Namespace or workload network restriction is ineffective — A disallowed fixture workload reaches a service across a network boundary that the deployment claims to enforce.
• Supported deployment default exposes a protected service — A supported installation path creates permissive service exposure or permissions that contradict the product's stated deployment boundary.
• Redis authentication or key ACL boundary failure — An anonymous or restricted client can read a key outside the service's intended access policy.
• PostgreSQL trust authentication exceeds the approved network boundary — An unintended source can connect as a protected database identity without the required authentication because an effective trust rule applies.
• Message broker permissions cross a virtual-host boundary — A restricted broker identity can act on a queue or exchange belonging to a different isolated fixture tenant.
• Container daemon management endpoint lacks required client authentication — An untrusted network client reaches protected container-management functionality without the required identity checks.

Nearby shared procedures#

Object, function, and property authorization · Authentication, recovery, federation, and session lifecycle · Trace input into queries, commands, and templates · Server-side fetching and network trust boundaries · Browser execution, cross-origin reads, and forged actions · Uploads, downloads, paths, archives, and XML · Workflow invariants, replay, idempotency, and races · REST, GraphQL, gRPC, WebSocket, and SSE permission parity