Debugging and trace information, within Automation Controller NGINX web server, used to diagnose the web server must be disabled.

It is important that Automation Controller NGINX web server debugging and trace information used to diagnose the web server is disabled, because debugging information can yield information about the Automation Controller NGINX webserver, like web server type, version, patches installed, plugins, modules, the hosted app’s code type. Back ends used for storage could be revealed, as well. An attacker would not need to cause an error condition to gain this information because they could reside in logs and general messages.

If debugging/trace information is enabled, attackers could get the information from logs and general information, without drawing attention to themselves via an error message.

For each Automation Controller NGINX web server, a system administrator must check to determine if any error or debug information is being logged to a persistent file (not stdout/stderr):

nginx -T 2>&1 | grep '^\s*error_log' | grep -v '/dev/stdout\|/dev/stderr\|/dev/null' && echo FAILED

If "FAILED" is displayed, this is a finding.

Note: In containerized deployments (AAP 2.6+), error_log /dev/stdout error; is the expected configuration - container runtimes collect stdout via journald or the container logging driver. This is NOT a finding. Only error_log directives pointing to persistent files on disk constitute a finding.

For each Automation Controller NGINX web server, identify the active configuration files:

nginx -T 2>&1 | grep '# configuration file'

If error_log points to a file on disk, either remove the directive or redirect to /dev/stdout: error_log /dev/stdout error;

Cause NGINX to reload its configuration file: pkill -HUP nginx