During a hardening review, a DBA finds a new database server running with several default features enabled: a web-based management endpoint, a legacy remote-administration protocol, and an extra network listener. None of them are used by the applications or administrators. What should the DBA do?
Select an answer to reveal the explanation.
Short Explanation
Every open port is a window, and you don't leave windows open in rooms you never use. If nobody needs those services, you turn them off and close the ports. Watching an open window or painting it a different color doesn't make it shut.
Full Explanation
Port security and service hardening follow a simple principle: anything not required is disabled. Each enabled feature, protocol and listener adds code that can contain vulnerabilities and an entry point that must be patched, configured and monitored. Turning off the unused management endpoint, the legacy remote-administration protocol and the extra listener, and confirming their ports are closed, shrinks the attack surface with no functional loss because nothing depends on them. Leaving them running with monitoring detects use after the fact; it does not prevent exploitation and leaves the vulnerable code active. Renaming endpoints and service names relies on obscurity; scanning and fingerprinting reveal running services regardless of their names, and the exposure is unchanged. Moving the server to a separate VLAN narrows who can reach the services but still leaves them running for every host in that segment, including the database servers an attacker might pivot from, and it complicates the network without solving the root cause. Exam caveat: hardening means a minimal footprint first and compensating controls second. Operational check: after disabling the features, run a port scan of the server and confirm only the intended database listener and required management ports respond, then document the result as part of the baseline configuration.