312-50 Question 291
Select 2▪ Web Server Attack CountermeasuresAn organization hosts a public-facing Apache web server on Linux for an internal HR application. During a security review, the ethical hacker discovers that the server discloses its exact Apache version in HTTP response headers, directory listing is enabled on several folders, and unnecessary modules are loaded. The application itself cannot be rewritten immediately, so the security team wants the fastest countermeasures that reduce the web server's attack surface and information leakage without changing business functionality. Which TWO actions should the team implement first?
- A
Disable directory listing, remove or disable unused Apache modules, and suppress detailed server version banners in the web server configuration
- B
Rely on robots.txt to prevent attackers from discovering sensitive directories and files exposed by the web server
- C
Move the HR application to a different TCP port so automated scanners are less likely to identify the web server
- D
Apply the principle of least functionality by disabling unnecessary services/features and hardening Apache configuration to limit exposed information
- E
Enable verbose error messages so administrators can remotely troubleshoot attacks more quickly from client-side responses
Show answer and explanation
Correct answers: A, D
Explanation
The best immediate countermeasures are to harden the web server itself by reducing attack surface and minimizing information disclosure. In this scenario, the discovered issues are classic web server misconfigurations: excessive banner information, enabled directory indexing, and unnecessary modules. Apache hardening guidance commonly recommends reducing server-identifying headers with ServerTokens and ServerSignature, disabling directory indexing unless explicitly required, and removing unused modules and features. These measures support the principle of least functionality and are consistent with broadly accepted hardening guidance from sources such as the Apache HTTP Server documentation and security benchmarks like CIS guidance for web servers. By contrast, robots.txt is not an access control mechanism, moving to a different port is only obscurity, and verbose client-side errors worsen reconnaissance opportunities for attackers.
- A. Correct.
Correct. These are standard web server hardening measures that directly address the issues found: disabling directory listing prevents casual browsing of exposed directories, removing unused modules reduces attack surface, and suppressing detailed server banners limits information disclosure that can help attackers tailor exploits. In Apache, this commonly involves settings such as disabling autoindex where not needed and using directives like ServerTokens and ServerSignature to reduce version disclosure.
- B. Incorrect.
Incorrect. robots.txt is not a security control; it is only an advisory file for compliant search engine crawlers. Attackers and scanners can ignore it completely, and in some cases it can even reveal sensitive paths worth targeting. It does not mitigate directory browsing or protect exposed content.
- C. Incorrect.
Incorrect. Changing the listening port may reduce noise from unsophisticated scans, but it is security through obscurity and does not address the underlying weaknesses. Modern scanners quickly identify web services on nonstandard ports, and the exact Apache version, directory listing, and unnecessary modules would remain exposed.
- D. Correct.
Correct. This option captures the broader best-practice approach for web server attack countermeasures: reduce functionality to only what is required and harden configuration to minimize disclosure. This is directly aligned with secure configuration guidance for web servers and is the appropriate immediate step when application changes are not feasible.
- E. Incorrect.
Incorrect. Verbose error messages increase information leakage by exposing stack traces, software details, internal paths, or configuration behavior that can help attackers enumerate the environment. Best practice is to log detailed errors server-side while presenting minimal error details to clients.