Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Using secure configurations and setup of Docker images #732

ioah86 started this conversation in General
Discussion options

Hello,

I recently ran the CoGuard CLI (https://github.com/coguardio/coguard-cli) on the wordpress Docker image. It found an Apache HTTPD configuration file, in addition to doing some scans on the last Dockerfile itself.

It found 20 issues, out of which 13 were high severity. Here are a couple of lines of the output:


 XXXXXXXXXXXK
 xXXXXXXXXXXXXXXXXXXl
 XXXXX. ;XXXXO .XXXXXXXXXX oXXXX XXXXc xXXXX' 'XXXXXXXXXXXXO XXXXXXXXXXX;
 lXXXx lXXXXXXXX, 0XXX; cXXXXXXXXXXXXXX. oXXXX XXXXc :XXXXXX 'XXXXXXXXXXXXXXX. XXXXXXXXXXXXXX'
 dXXX. .XXXXXx 0XXXXX ... dXXXX' cXXXX. oXXXX XXXXc .XXXXXXX0 'XXXX' OXXXX XXXXo .XXXXk
;XXX xXXX do .XXXc 'XXXX, oXXXX XXXXc XXXX.oXXXd 'XXXX' ,XXXX. XXXXd XXXXd
0XXl ;XXk ,, KXX. lXXXX oXXXX XXXXc OXXXl 0XXX: 'XXXX' .XXXXk XXXXd lXXXX
XXX: oXX: cll. ,ll: oXX; oXXXX .XXXXXXXXo oXXXX XXXXc oXXXO .XXXX. 'XXXXXXXXXXXXXX; XXXXd lXXXX
OXXo ;XXO do KXX. cXXXX. .XXXXXXXXo oXXXX XXXXc ;XXXX :XXXX 'XXXXXXXXXXXXl XXXXd xXXX0
;XXX. oXXX ,, .XXX: .XXXXo XXXXo lXXXX .XXXX: .XXXXXXXXXXXXXXXO 'XXXX' .XXXXd XXXXd ,XXXX;
 oXXX. XXXXXX:lXXXXXK ;XXX: .XXXXX. XXXXo XXXXX .XXXX0 XXXXx XXXXo 'XXXX' .XXXX0 XXXXd .XXXXX,
 cXXXO ;XXXXXXXX. XXXX' xXXXXXXXXXXXXXX. kXXXXXXXXXXXXd kXXXX ,XXXX:'XXXX' XXXXK XXXXXXXXXXXXXl
 KXXXX; lXXXXx 'XXXXXXX cXXXXXX; lXXXX, dXXXXlXXXX' KXXXX XXXXXXXXK
 oXXXXXXXXXXXXXXXXXX:
 OXXXXXXXXXXd
 
Docker version 20.10.17, build 100c70180f detected.
SCANNING IMAGE wordpress
Found file /etc/apache2/apache2.conf
Found configuration files for apache in non-standard location. Keep in mind that this is a heuristic method.
SCANNING OF wordpress COMPLETED
Scan result_jsons: 20 checks failed, 13 High/5 Medium/2 Low
 X Severity 5: apache_deny_root_directory
Documentation: Ensure that the root directory access is specifically denied. Otherwise, it is possible that an attacker can
 gain access to files through root directory mapping. Remediation: Create a <Directory> Require all denied
 </Directory> directive Source:https://httpd.apache.org/docs/2.4/mod/core.html#directory
 X Severity 5: apache_root_directory_options_none
Documentation: With the options directive, one can allow scripts to be executed, follow symlinks, do content negotiation, etc.
 In the root directory, the Options directive should always be set to None. Remediation: Create a <Directory>
 Options None </Directory> directive Source:https://httpd.apache.org/docs/2.4/mod/core.html#directory
 X Severity 5: apache_enable_ssl
Documentation: We should never have any communication done using unencrypted channels. This check tests if the mod_ssl.so
 module is loaded and that SSLProtocol is set, together with a proper SSL certificate file and a key file.
 Remediation: Load the `mod_ssl.so` modules, and set the `SSLCertificateFile` and `SSLCertificateKeyFile` keys to
 the paths of the respective certificate and key file.
 X Severity 5: apache_load_logging_module
Documentation: Logging is important to monitor the activity on the server and detect anomalies. Remediation: Load the module
 `mod_log_config` module in the configuration Source: https://httpd.apache.org/docs/2.4/mod/mod_log_config.html
 X Severity 5: apache_load_security_module
Documentation: ModSecurity is a module that acts as a web application firewall for monitoring, logging, and access control. It
 should always be loaded and configured Remediation steps: Load the module by adding `LoadModule security2_module
 modules/mod_security2.so` Source: https://www.modsecurity.org/download.html
 X Severity 4: dockerfile_last_user_should_be_non_root
Documentation: When creating a docker container, it is possible to set the user who is actually running the application and any
 command on the container. It is important to specifically use the `USER` directive in any Dockerfile to ensure
 that the user is not root and has unnecessary privileges. Remediation: Have at least one `USER` directive in
 your Dockerfile, and the last user directive should not reference the root user or root group. Source:
 https://docs.docker.com/engine/reference/builder/#user
...

I don't think it would be hard to address these issues, and harden the produced Docker images. Furthermore, there is a github action which can be used to ensure that configurations stay hardened in future images: https://github.com/marketplace/actions/coguard-docker-image-scan

I would love to open the discussion on fixing some of those configuration issues, and also add the continuous check into the workflow.
It is free and would help maintain a high degree of quality.

Thoughts?

You must be logged in to vote

Replies: 1 comment 2 replies

Comment options

Most of our Apache configuration comes from Debian's own defaults (or direct recommendations from WordPress, where available). 😬

A few notes:

  • apache_enable_ssl - definitely not trivial to enable out-of-the-box (which certificate do we use? generate a new self-signed? IMO that would make things even worse because it would train users to ignore the security warning entirely 😬)

  • dockerfile_last_user_should_be_non_root - this image is following a similar pattern to many other official images where we default to running as root such that we can correct permissions before we step-down, but support users invoking directly as non-root if they prefer to handle permissions themselves in favor of a slightly more secure setup

You must be logged in to vote
2 replies
Comment options

Yes, some scan results may be not applicable here, but others are. The last user not being root is something which is considered best practice in general, and, as you may foresee, if someone uses a template (which these public images are), they assume it is done in the best way possible. Most of the time, people are not even aware that they are running their final commands as root, and to enforce an intermediate user on the higher level is beneficial to making the world of Docker images and containers more secure.

Comment options

And, keep in mind that these are just a snapshot. You can run CoGuard-CLI on any of those images and see the output and what it may find. I am happy to discuss further and assist in finding ways to fix it. We also have a GitHub action which can be included into the general build process: https://github.com/marketplace/actions/coguard-docker-image-scan

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
2 participants

AltStyle によって変換されたページ (->オリジナル) /