A systems administrator has deployed a new Linux server that will function as a secure web server. The administrator can connect to the server via SSH from a management workstation, but connections to the web service using HTTPS are timing out. A port scan confirms that port 22 is open, but port 443 is closed. To resolve this issue while adhering to the principle of least privilege, what is the MOST appropriate next step?
Request that the network team add an allow rule for port 443 on the network firewall.
Add a rule to the server's host-based firewall to allow inbound TCP traffic on port 443.
Disable the host-based firewall on the server.
Add a rule to the server's host-based firewall to allow inbound TCP traffic on port 80.
The correct action is to add a specific rule to the server's host-based firewall to allow inbound traffic on TCP port 443. The scenario indicates that the server is for a secure web service (HTTPS), which uses TCP port 443. Since SSH (port 22) is accessible but HTTPS is not, the issue is most likely the server's own host-based firewall blocking the required web traffic. Adding a specific rule for port 443 resolves the problem while adhering to the principle of least privilege by only opening the necessary port. Disabling the firewall would resolve the connectivity issue, but would expose the server to all other network threats, violating the principle of least privilege. Opening port 80 is incorrect because that is for unencrypted HTTP traffic; the scenario specifies HTTPS. While a network firewall could also be blocking traffic, the most common and immediate cause for this symptom on a newly deployed server is its own host-based firewall, making it the most appropriate place to check first.