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 ini_set()

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

Enabling the ini_set() 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 ini_set, 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 ini_set() is necessarily disabled on any php web server that wants any baseline for security.

It is absurd for an application to *require* ini_set() 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 ini_set() 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 ini_set() 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"

Create your piwik db & db user. Use a unique, randomly-generated password of exactly 70 characters for the db user. Store this password in the shared keepass; we'll also need it when we install Piwik through their WUI below.

CREATE DATABASE piwik_ose_db;
GRANT ALL PRIVILEGES ON piwik_ose_db.* TO "piwik_ose_user"@"localhost" IDENTIFIED BY "thisShouldBeARandomlyGeneratedPasswordOfExactly70Characters";
FLUSH PRIVILEGES;

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"