Piwik

Why

Piwik is a self-hosted alternative to Google Analytics (GA). Unlike GA, Piwik is FOSS and can be self-hosted, so we're not dependent on sending (sensitive user's) data to an external service provider.

Security Concerns

When first adopted into the OSE stack in 2017, Piwik appears to be the best self-hosted GA alternative. That said, it is not without issues. Specifically, we found many eyebrow-rasising red flags about the project's security history & practices

Note: In the end, piwik is not a publicly accessible service. As such, the usual concerns (SQL Injection, XSS attacks, etc) are moot if the service runs behind http basic auth. Therefore, we use Piwik on "basic auth lockdown" until a better option is available

Requires set_ini()

The piwik project expects (in fact, very explicitly requires) the set_ini() function to be enabled.

Enabling the set_ini() function would effectively allow any php site to override all our php hardening made in php.ini. For example, we disabled exec() that prevents php from executing commands on our server. If Piwik can execute set_ini, then it could re-enable the exec() function. Combine that with a PHP injection vulnerability--which the Piwik project has had issues with in the past, and we have a huge security issue. This is why set_ini() is necessarily disabled on any php web server that wants any baseline for security.

It is absurd for an application to *require* set_ini() to be enabled, and--in fact--this is exactly what Piwik does. During the install process, Piwik errors-out (from 'core/testMinimumPhpVersion.php') if the function set_ini() is disabled.

Moreover, this issue was raised to them in 2009 (7 years ago from the time of writing), and the offical response was "wontfix"

See the Installation section below for instructions on how to bypass the set_ini() check during the install process.

Opaque Security Audits

Piwik likes to boast that they have strong security in their project, including a blog post from 2011 describing a professional security review of Piwik.

But the audit itself is glaringly missing from the blog post.

Professional security audits are a great idea, but the results should be published--especially after the remediations & patches have been released. Without transparently publishing the results of the audit, how can the community establish any vetting of the project that was audited? For example, maybe some critical, fundamental security concerns were marked "wontfix" as above. Without the results of the audit being published, we can't know.

Install

The following commands will install piwik in a vhost

# settings
vhostDir="/var/www/html/piwik.opensourceecology.org"
piwikDocroot="${vhostDir}/htdocs"
stamp=`date +%Y%m%d_%T`
tmpDir="/var/tmp/piwik.${stamp}"

# make vhost docroot
mkdir -p "${piwikDocroot}"

# download
mkdir "${tmpDir}"
pushd "${tmpDir}"
wget https://builds.piwik.org/piwik.zip

# extract & copy to docroot
unzip piwik.zip
rsync -av --progress piwik/* "${piwikDocroot}/"

# remove ini_set() requirement
perl -pi -e ' BEGIN{undef $/;} s%(.*)if(.*)function_exists(.*)ini_set[^}]*}%${1}\n/***************************************************************************\n * disabling ini_set detction\n * it was intentionally disabled for security! -maltfield\n****************************************************************************\nif${2}function_exists${3}ini_set${4}\n*/%smg' "${piwikDocroot}/core/testMinimumPhpVersion.php"

# htpasswd for basic auth; use a long, random password for the 'admin' user to
# be stored in the shared keepass. feel free to add additional admin-specific
# usernames here (all with long, random passwords) to be added to the admin's
# personal keepass--without needing to open the higher-security shared keepass
# on every login
htpasswd -c -B "${vhostDir}/.htpasswd" admin

# use -B for bcrypt for all users
htpasswd -B "${vhostDir}/.htpasswd" maltfield

# set (hardened) permissions
chown -R apache:apache "${vhostDir}"
find "${vhostDir}" -type d -exec chmod 0750 {} \;
find "${vhostDir}" -type f -exec chmod 0640 {} \;

chown apache:apache "${vhostDir}/.htpasswd"
chmod 0400 "${vhostDir}/.htpasswd"

Next, create your vhost file, such as /etc/httpd/conf.d/piwik.opensourceecology.org

Listen 4444

<VirtualHost piwik.opensourceecology.org:4444>
        ServerName piwik.opensourceecology.org
        ServerAlias piwik.opensourceecology.org
        DocumentRoot "/var/www/html/piwik.opensourceecology.org/htdocs"

        Include /etc/httpd/conf.d/ssl.opensourceecology.org

</VirtualHost>

<LocationMatch .*\.(svn|git|hg|bzr|cvs|ht)/.*>
        Deny From All
</LocationMatch>

<Directory "/var/www/html/piwik.opensourceecology.org/htdocs">

        # we don't trust piwik due to obvious sec incompetence in the project, so we
        # restrict the whole site with basic auth *in addition* to the untrusted
        # applicaiton-level auth
        AuthType Basic
        AuthName "Authentication Required"
        AuthUserFile /var/www/html/piwik.opensourceecology.org/.htpasswd
        Require valid-user

        Options -Indexes -Includes
        AllowOverride None

        Order allow,deny
        Allow from all

        # Harden vhost docroot by blocking all request types except the 3 essentials
        <LimitExcept GET POST HEAD>
                deny from all
        </LimitExcept>

</Directory>

# disable mod_security with rules as needed (found by logs in:
#  /var/log/httpd/modsec_audit.log
<Location "/">
        <IfModule security2_module>
                SecRuleEngine On
        </IfModule>
</Location>

Now browse to the site in your browser, auth with the password given to htpasswd above, and follow the WUI to install Piwik.

TODO

Finally, after install we can lock-down the site-specific config file (this can't be created before the install):

touch "${piwikDocroot}/config/config.ini.php"
chown apache:apache "${piwikDocroot}/config/config.ini.php"
chmod 0440 "${piwikDocroot}/config/config.ini.php"