Exercise 1: Why localhost-Only Is a Control, Not an Obstacle — Possible Solution ==================================================================== WHAT THIS CHAPTER SAYS ------------------------------ Per this chapter, "a database listening only on localhost, reachable by nothing outside that one machine, is a deliberate security practice - the same reasoning Network Troubleshooting covers for firewall rules: reducing the attack surface by not exposing anything that doesn't genuinely need to be reachable from outside." WHY THIS IS A DELIBERATE CHOICE, NOT AN ACCIDENT ------------------------------ The database could technically be configured to listen on all interfaces and be reachable directly - the fact that it's restricted to localhost is a specific decision to minimize the number of ways an attacker could reach it. Fewer exposed entry points means fewer things that need to be individually secured and monitored against external attack. WHY SSH TUNNELING IS THE RIGHT RESPONSE, NOT A WORKAROUND ------------------------------ Per this chapter, "SSH port forwarding is the sanctioned way to reach such a service for legitimate diagnostic work, without weakening that security posture by opening the port more broadly to make things convenient... tunneling through SSH works with it, not around it." Tunneling doesn't remove or bypass the localhost restriction - the database is still only reachable from its own machine; the tunnel simply extends a legitimate, already-authenticated SSH session to include that specific access, rather than changing the database's own exposure at all. WHY THIS WORKS AS AN ANSWER ------------------------------ It explains the specific security reasoning behind the localhost restriction, and explains precisely why SSH forwarding respects that restriction rather than undermining it, using the chapter's own explicit "works with it, not around it" framing.