Docker Image Scan results for apache2use/pig
Scan performed at 2022-12-12 15:23:07 using the CoGuard CLI
Summary
26 Total failed checks.
18 High / 3 Medium / 5 Low.
Details
| Rule identifier | Severity | Documentation |
|---|---|---|
| tomcat_disable_shutdown_port | 5 | Tomcat, by default, listens on port 8005 for messages with a shutdown request. The message by default is SHUTDOWN, which of course could be probed. One should change this value to a random one not known to attackers, if one is not disabling the shutdown port explicitly.Remediation: Ensure that in the server.xml file, inside the Server tag, the attribute shutdown attribute is set to anything but SHUTDOWN.Source: https://tomcat.apache.org/tomcat-9.0-doc/config/server.html |
| tomcat_shutdown_different_value | 5 | Tomcat, by default, listens on port 8005 for messages with a shutdown request. The message by default is SHUTDOWN, which of course could be probed. One should change this value to a random one not known to attackers, if one is not disabling the shutdown port explicitly.Remediation: Ensure that in the server.xml file, inside the Server tag, the attribute shutdown attribute is set to anything but SHUTDOWN.Source: https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html#server.xml |
| tomcat_ensure_autodeploy_false | 5 | Tomcat allows deployment of applications on runtime. This can be used by malicious actors to deploy their own applications, and hence should not be allowed. Remediation: For every Host tag in the server.xml file, ensure that the attribute autoDeploy is set to false (default is true).Source: https://tomcat.apache.org/tomcat-9.0-doc/config/host.html |
| tomcat_deploy_on_startup_false | 5 | Tomcat allows deployment of applications upon startup. This can be used by malicious actors to deploy their own applications, and hence should not be allowed. Remediation: For every Host tag in the server.xml file, ensure that the attribute deployOnStartup is set to false (default is true).Source: https://tomcat.apache.org/tomcat-9.0-doc/config/host.html |
| tomcat_do_not_let_root_start_tomcat | 5 | There is a way to ensure that Tomcat is not started by the root user, which would give it root-privileges. Remediation: In the server.xml, ensure that a Listener tag is present, with the attribute className being org.apache.catalina.security.SecurityListener and root not being part of the comma separated list in the attribute checkedOsUsers (default is root).Source: https://tomcat.apache.org/tomcat-9.0-doc/config/listeners.html#Security_Lifecycle_Listener_-_org.apache.catalina.security.SecurityListener |
| tomcat_error_page_not_debug | 4 | The lesser anyone connecting to the server knows about the underlying architecture, the better. If an error page is displayed for a Tomcat server, it usually prints out a debug, revealing useful information for a potential attacker. This should be avoided. Remediation: Ensure that in any web.xml file that there is a <error-page> tag right below the <web-app> tag. Inside the <error-page> tag, there should be a tag of the kind Source: https://docs.oracle.com/cd/E14571_01/web.1111/e13712/web_xml.htm#WBAPP502 |
| tomcat_error_page_not_debug | 4 | The lesser anyone connecting to the server knows about the underlying architecture, the better. If an error page is displayed for a Tomcat server, it usually prints out a debug, revealing useful information for a potential attacker. This should be avoided. Remediation: Ensure that in any web.xml file that there is a <error-page> tag right below the <web-app> tag. Inside the <error-page> tag, there should be a tag of the kind Source: https://docs.oracle.com/cd/E14571_01/web.1111/e13712/web_xml.htm#WBAPP502 |
| tomcat_error_page_not_debug | 4 | The lesser anyone connecting to the server knows about the underlying architecture, the better. If an error page is displayed for a Tomcat server, it usually prints out a debug, revealing useful information for a potential attacker. This should be avoided. Remediation: Ensure that in any web.xml file that there is a <error-page> tag right below the <web-app> tag. Inside the <error-page> tag, there should be a tag of the kind Source: https://docs.oracle.com/cd/E14571_01/web.1111/e13712/web_xml.htm#WBAPP502 |
| tomcat_error_page_not_debug | 4 | The lesser anyone connecting to the server knows about the underlying architecture, the better. If an error page is displayed for a Tomcat server, it usually prints out a debug, revealing useful information for a potential attacker. This should be avoided. Remediation: Ensure that in any web.xml file that there is a <error-page> tag right below the <web-app> tag. Inside the <error-page> tag, there should be a tag of the kind Source: https://docs.oracle.com/cd/E14571_01/web.1111/e13712/web_xml.htm#WBAPP502 |
| tomcat_error_page_not_debug | 4 | The lesser anyone connecting to the server knows about the underlying architecture, the better. If an error page is displayed for a Tomcat server, it usually prints out a debug, revealing useful information for a potential attacker. This should be avoided. Remediation: Ensure that in any web.xml file that there is a <error-page> tag right below the <web-app> tag. Inside the <error-page> tag, there should be a tag of the kind Source: https://docs.oracle.com/cd/E14571_01/web.1111/e13712/web_xml.htm#WBAPP502 |
| tomcat_error_page_not_debug | 4 | The lesser anyone connecting to the server knows about the underlying architecture, the better. If an error page is displayed for a Tomcat server, it usually prints out a debug, revealing useful information for a potential attacker. This should be avoided. Remediation: Ensure that in any web.xml file that there is a <error-page> tag right below the <web-app> tag. Inside the <error-page> tag, there should be a tag of the kind Source: https://docs.oracle.com/cd/E14571_01/web.1111/e13712/web_xml.htm#WBAPP502 |
| tomcat_error_page_not_debug | 4 | The lesser anyone connecting to the server knows about the underlying architecture, the better. If an error page is displayed for a Tomcat server, it usually prints out a debug, revealing useful information for a potential attacker. This should be avoided. Remediation: Ensure that in any web.xml file that there is a <error-page> tag right below the <web-app> tag. Inside the <error-page> tag, there should be a tag of the kind Source: https://docs.oracle.com/cd/E14571_01/web.1111/e13712/web_xml.htm#WBAPP502 |
| tomcat_use_lockout_realms | 4 | To mitigate brute force attacks, it is important to use Lockout realms, which block any login-attempts for a certain period of time. Remediation: Ensure that for any Realm tag in the server.xml file, that it is enclosed within a Lockout Realm definition. This has the following form:<Realm className="org.apache.catalina.realm.LockOutRealm" failureCount="3" lockOutTime="600"><Realm ... /></Realm> Source: https://tomcat.apache.org/tomcat-9.0-doc/config/realm.html#LockOut_Realm_-_org.apache.catalina.realm.LockOutRealm |
| tomcat_require_certificate_authentication | 4 | The best way to authenticate clients to Connectors is via certificate authentication. That should be enforced for every connector. Remediation: For every Connector tag in the server.xml file, ensure that the attribute clientAuth is set to true, and for every SSLHostConfig tag, ensure that the certificateVerification attribute is set to required.Source: https://tomcat.apache.org/tomcat-9.0-doc/config/http.html#SSL_Support_-_SSLHostConfig |
| tomcat_ssl_enabled_for_all_connectors | 4 | No communication should be done without encryption. Hence, all Connectors should have SSL enabled. Remediation: For every Connector tag in the server.xml file, ensure that both the attributes SSLEnabled and secure are set to true (defaults are false).Source: https://tomcat.apache.org/tomcat-9.0-doc/config/http.html |
| tomcat_do_not_use_http_scheme | 4 | No communication should be done without encryption. Hence, all Connectors should not have HTTP as a scheme enabled. Remediation: For every Connector tag in the server.xml file, ensure that the attribute scheme is not set to http (default is http).Source: https://tomcat.apache.org/tomcat-9.0-doc/config/http.html |
| tomcat_ensure_deploy_xml_is_false | 4 | Developers may assign increased privileges to their applications, which they should not do. The way to prevent it is to forbid the deployment of custom context.xml files for deployments.Remediation: For every Host tag in the server.xml file, ensure that the attribute deployXML is set to false (ambiguous default).Source: https://tomcat.apache.org/tomcat-9.0-doc/config/host.html |
| tomcat_do_not_allow_cross_context | 4 | There is a setting to allow an application to call a request dispatcher for other applications on the same host. This sort of privilege can be potentially exploited to gain access to restricted resources. Remediation: Ensure in the context.xml file that any Context tag does have the attribute crossContext set to false (no clear default in the documentation).Source: https://tomcat.apache.org/tomcat-9.0-doc/config/context.html |
| tomcat_hide_server | 3 | The lesser anyone connecting to the server knows about the underlying architecture, the better. Any Connector instance returns a well-known server string by default, revealing that Tomcat is being used. This should be remediated. Remediation: Ensure that in any server.xml file that every Connector instance does have a random string in the attribute server.Source: https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html#Connectors |
| tomcat_do_not_use_certain_realms | 3 | Tomcat can use different implementations to handle user authentication and authorization. Certain implementations are not recommended for production use, and this check fails if one of them is encountered. Remediation: Ensure that for any Realm tag in the server.xml file, the className attribute is not one of the following: - MemoryRealm, - JDBCRealm, - UserDatabaseRealm . Source: https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html |
| dockerfile_create_volume_for_var_log | 3 | In linux systems, important operating system logs are stored in the /var/log subfolder. This folder should always be made available to the host through a volume, so that log tracking and log analysis systems can capture them. Remediation: In every Dockerfile, there should be a VOLUME directive which has /var/log as an argument.Source: https://docs.docker.com/engine/reference/builder/ |
| dockerfile_container_healthcheck_parameter | 2 | Dockerfiles have an instruction called HEALTHCHECK. It enables a user to define a command to figure out if the program(s) running inside the container are working properly. It is generally advisable to have healthchecks in place to assist monitoring of running containers. Remediation: Have at least one HEALTHCHECK instruction in your Dockerfile.Source: https://docs.docker.com/engine/reference/builder/#healthcheck |
| dockerfile_env_and_arg_defined_and_right_away_used | 1 | When creating Docker images that use environment variables or build arguments, it is advisable to position the ARG or ENV directives close to their actual uses, since otherwise the caching for building the images is not greatly used.Remediation: Every variable defined by an ENV or ARG directive should be used within the next five commands inside the Dockerfile. |
| tomcat_log_effective_web_xml | 1 | To avoid long debugging if a web application is not deployed as intended, it is useful to see which web applications exactly have been deployed. Tomcat allows extended logs to be shown at startup to see which web.xml files have been loaded or not.Remediation: Ensure in the context.xml file that any Context tag does have the attribute logEffectiveWebXml set to true (default is false).Source: https://tomcat.apache.org/tomcat-9.0-doc/config/context.html |
| dockerfile_do_not_use_maintainer | 1 | Dockerfiles allow for a specification of a MAINTAINER. This directive is deprecated, and should generally be replaced with the LABEL directive. Remediation: Remove any MAINTAINER directive in your Dockerfile and replace it with LABEL.Source: https://docs.docker.com/engine/reference/builder/#maintainer-deprecated |
| dockerfile_do_not_use_add | 1 | Dockerfiles have two directives that allow you to add files from the machine where you build the image into the image, namely COPY and ADD. Both are technically similar, but ADD also has side-effects like automated decompression of archives. It is generally recommended to only use COPY Remediation: Remove any ADD directive in your dockerfile and replace it with COPY.Source: https://docs.docker.com/engine/reference/builder/#copy |
Scan performed at 2022-12-12 15:23:07 using the CoGuard CLI