Target Aware Security

Target-Aware Security

Assume the system is a target and every change creates or removes attack paths. Prefer small, reversible, least-privilege changes with evidence, validation, and explicit exposure notes.

Operating Posture

• Treat public services, multi-user hosts, CI, DNS, databases, SSH, sudo, and writable directories as hostile interfaces.
• Treat outbound tunnels, reverse proxies, and overlay ingress as public exposure when they publish a route. Home or office NAT does not protect a service reached through one of these paths.
• Read current state before changing it. Capture enough context to distinguish intended exposure from accidental exposure.
• A read-only audit must not stop, restart, disable, or reconfigure a production process. Containment or remediation requires explicit authorization for the exact target and an impact check.
• Do not print secrets. Refer to credential locations, owners, permissions, and rotation steps instead of values.
• Prefer deny-by-default networking, least-privilege roles, per-service credentials, and short rollback paths.
• Preserve backups or evidence before mutating auth, firewall, DNS, service, database, or credential files.
• Avoid destructive cleanup unless the user explicitly requests it or a safe backup exists.

Attack-Vector Checklist

Before implementation, identify the likely attacker paths:

• Network: public ports, source ranges, DNS records, TLS identity, default credentials, protocol downgrade, brute force, exposed admin endpoints.
• Identity: shared passwords, broad roles, stale keys, weak file modes, password reuse, missing rotation, sudo scope, service accounts with login shells.
• Database: public bind/listen, broad pg_hba rules, superuser app roles, missing TLS, unbounded schemas, SQL injection surface, backups with secrets.
• Host: writable service scripts, world/group-writable config, systemd units running as root, temp-path execution, stale symlinks, PATH injection, and public applications sharing a Unix user with validators, keys, process managers, or privileged files.
• Cloud/DNS: wrong hosted zone, apex vs subdomain mistakes, stale records, long TTLs during cutover, missing rollback values, and tunnel routes not visible in local config.
• Operations: no backup, no rollback command, no health check, hidden dependency on a currently idle process.

Change Workflow

1. Inventory:

   • Confirm host, user, service names, ports, cluster names, current DNS records, firewall rules, file modes, and active clients.
   • Inventory process managers for every service user rather than only the current or root user. Inventory both local tunnel processes and provider-side route mappings before changing a tunnel.
   • Prefer structured commands such as systemctl show, pg_lsclusters, ss -tulpen, ufw status, cloud provider read calls, and metadata queries.

2. Design:

   • Choose the smallest exposure that satisfies the request.
   • Use unique credentials per service and purpose.
   • Prefer a dedicated app role over reusing admin or owner credentials.
   • Prefer a dedicated Unix service account for every public application. Do not colocate public app code with validator identities, signing material, or broad process-control authority.
   • Prefer TLS with hostname validation. If only encrypted-but-not-verified TLS is feasible, say so.
   • Prefer allowlisted source IPs. If public 0.0.0.0/0 is required, use a high-entropy secret, rate limiting where possible, and explicit risk disclosure.

3. Mutate:

   • Back up original files with timestamps.
   • Make one class of change at a time: database role/schema, service config, firewall/NAT, DNS.
   • Store generated secrets in root-only or service-owner-only files, mode 600.
   • Remove the narrowest route, unit, listener, or credential that satisfies the request. Do not stop or delete an entire shared tunnel unless its complete route inventory is known and the user accepts every affected route.
   • Keep secret-bearing URLs out of chat and shell output unless the user explicitly asks and the channel is appropriate.

4. Verify:

   • Test locally first, then through the intended network path.
   • Confirm logs, service status, auth failure behavior, and exact DNS record values.
   • Verify the app uses the intended credential and database, with no silent fallback.
   • Re-check for accidental exposure on adjacent ports.
   • Confirm critical production PIDs and health checks before and after infrastructure remediation.

5. Report:

   • Lead with exposure state and what changed.
   • Include credential locations, never credential values.
   • Include rollback steps and any remaining external dependency such as router port forwarding or DNS propagation.

Database Exposure Defaults

For PostgreSQL exposed beyond localhost:

• Create a separate cluster or database when isolation is requested.
• Use a dedicated login role with only required privileges.
• Use SCRAM passwords and a generated password of at least 32 random bytes.
• Put connection URLs in owner-only env files or root-only handoff files.
• Use hostssl in pg_hba.conf for remote clients.
• Avoid host all all 0.0.0.0/0 ... unless the user explicitly needs public access.
• Prefer SSH port forwarding, a private overlay, or a source-IP allowlist over Internet-wide PostgreSQL exposure. CloudFront is an HTTP CDN and is not a PostgreSQL TCP proxy.
• A nonstandard external port may reduce scanner noise but is not an access control and must not substitute for tunneling or source restrictions.
• Confirm listen_addresses, firewall rules, NAT rules, DNS, and sslmode in the final connection string.

DNS And Firewall Defaults

• Read hosted zones and current record sets before writing.
• Preserve previous record values for rollback.
• Use low TTLs during cutover when possible.
• Never assume DNS alone exposes a service; verify host firewall and upstream router/NAT forwarding separately.
• Inventory provider-side tunnel routes as well as DNS and local tunnel configuration; locally absent ingress rules do not prove that no remotely managed routes exist.
• For home or office NAT hosts, report whether edge-router port forwarding is still required.