securityonion
securityonion copied to clipboard
Security-Onion-Solutions
Installation Bug Report - ElasticSearch Container
During fresh installation, I determined that the ElasticSearch container deployment will fail if a non-default UMASK is set on the server OS.
Deploying to Ubuntu 20.04 hardened image which includes a less permissive default UMASK setting defined in /etc/login.defs. This results in files created with 0600 permissions. While this setting was configured, the so-elasticsearch container would stop a few seconds after starting. Associated log message:
org.elasticsearch.ElasticsearchSecurityException: failed to load SSL configuration [xpack.security.transport.ssl] - not permitted to read the PEM certificate file [/usr/share/elasticsearch/config/elasticsearch.crt]
By manually starting the container and attempting to access the file from the shell, I determined that its permissions did not allow the elasticsearch service account to read the file - the file was owned by root and had 0600 permissions. Based on this, I concluded that the file must have been imported to the container with default permissions, which due to the UMASK setting, were too restrictive.
To reproduce:
- Set UMASK in /etc/login.defs to 077 on Ubuntu 20.04 (possibly also applicable to other distributions, but not tested)
- Execute installation per https://docs.securityonion.net/en/2.3/installation.html#installation-on-ubuntu-or-centos
- Installation will hang, as so-elasticsearch will not run.
Workaround - Modify the UMASK setting to during installation to allow world-readability to the elasticsearch.crt file.
Recommended solution - explicitly set required permissions on the elasticsearch.crt file during installation.
From https://docs.securityonion.net/en/2.3/best-practices.html#avoid-third-party-software-and-modifications: hardening guidelines may break functionality, so if you must apply those hardening guidelines, we recommend testing thoroughly before deploying to production
From https://docs.securityonion.net/en/2.3/best-practices.html#avoid-third-party-software-and-modifications: hardening guidelines may break functionality, so if you must apply those hardening guidelines, we recommend testing thoroughly before deploying to production
Of course. That is what I was doing when I discovered this bug.
My point is that it's a known issue that hardening guidelines may break functionality. If you're going to implement hardening guidelines, then you must be prepared to implement your own workarounds.