How to Harden a Matomo Installation?

General questions
1

Installing Matomo i see a lot of files in the public folder (usually htdocs in apache) . This means the Readme, node_modules etc. are all Visible in the Webserver, and in case of Node the Sourcecode is all Visible. If there is some sensible data in config files, it will all be open.

Good Best Practice is to have the libraries and templates in a private folder and only dispatch public files like index.php clients javascript css and images, but never tools, documentation and code.

I think a lot could be blocked with a .htaccess file which filters which files are available to load in webserver and blocks the others. but there are many files and its not easy to have such a black-list/white-list and it would be needed to be maintained with the rest of files longterm.

had nobody had this issue before, i guess there are thousands of installations, and the folder structure is just bad practice.

i understand its a simplified approach put all in one folder so its easier to install (just put all in htdocs) . I know also Wordpress is bad at this, but at least there you have plugins like sucuri where you can harden folders and files and hide them from public and reduce attack vector by design. This is called “defensive programming”, by good architecture it’s hard to make security bugs.

Feel Free to point me to the right place here in Forum or Support to discuss this.

2 Likes
2

The matomo code is public (open source) on Github. The sensible data are in files in the config directory. In this directory is a .htaccess with rules for denying access to this files. All is good. or not?

A htdocs directory is possible not from matomo, but from your webhoster.

3

I know the code is on github and one can figure out the code behind.

still there is node_modules folders in a htdocs (LAMP) Apache/PHP environment.

one made up attack vector could be that a node_module (or simililar tools code) contains a upload.php which will then be deployed into the LAMP and is executable. But in the idea of the developer it was “just” node.js code which would not run anyways.

i think its just a bad file structure and makes it easier to have security risks. thats why i gave example of “defensive programming”.

this is “good luck” programming, as long as nothing happens, we are fine.
protecting configs with a .htaccess is a good step in the right direction.

when i have a wordpress installation (just to give and example) i remove the readme.html because it exposes the version and can easily be googled by script-bots and use exploits fitting to this version. if the information is not available, it makes it already harder to discover these things. its not preventing but as defensive programming making errors harder.

i am just shocked to have all this node tool-chain in my htdocs (public web) folder and have to trust there is no bad stuff and side-effects (running node.js code in a apache). probably its fine, but my warning alarms go off, knowing how easy wordpress gets infected with malware, because of bad practice. i just see matomo has similar bad practice and i communicate it.

i learned programming MVC, and only Controller (Dispatcher) is Public Facing and M,V is private. But with all the new Client-Frameworks a lot more stuff is moved to the client. (eg. reactjs templates)
in my opinion bash scripts and node_js code should not be able to be downloaded from a public webserver without execution. (eg. see the source, not the executed result).

it would not be so hard, to have a .htaccess and only whitelist some files. similar to robots.txt, but i dont even know what is actually used for the tracking and what are tools toolchain or apis (offline node) which have nothing to do with the running server. if i want node integration and tracking of my node app, then i would like to install a plugin into node and not have it unprotected in my apache.

maybe i am wrong, but this does not seem to be best practice and security.

4

OK, i understand. I dont know over the security of that. I see, the *.js scripts are available from outside on my default matomo installation.
example:
/node_modules/angular-animate/angular-animate.min.js

When you think its a security risk, you can open an issue in Github with the label c: Security.

By default JavaScript tracking without Tag Manager, the matomo use the /matomo.js only. I think, by tracking with the Tag Manager its use a individual *.js file with a filename like keijbj97me89786ene87786vgfsd65sdhdg6ds.js. But i can not garranty this.

The backend access use the index.php and probaply few other files and scripts.

5

It’s not a direct risk, but could be one when side effects are unlucky.

I think it is more similar to the analogy of a firewall.

By separating php/apache files from node.js (more intended as helper functions) or cli bash files (intended to use in ssh but not in the browser) gives an extra layer (fire wall) in the case, there would be some bad code in the tools then it would have no effect on LAMP / apache, as these files are blocked in htdocs.

The robots.txt is doing something similar, hiding files from Google index. As long the crawler is nice to respect the rules. But the files can still be read.

My question should be: ‘how to harden matomo similar to a firewall’

The obvious way could be a whitest with htaccess.

A more clean way could be to separate node files and bashes into extra folders which can be blacklisted with htaccess. Now its mixed in the root folder and not so simple.

I can easily do that for my local install. But i want to be able to update matomo regularly. So the github Version should have ‘the Firewall’.

Also the question if i am the only one seeing this problem. Or if it is a no issue.

But i would compare it like with or without ‘firewall and anti-virus’. Sure most the time it will be fine.
But the defensive architecture can limit some surprises.

6

I think this issue in the tracker comes close to my comments to defensive architecture / firewall.

But its > 8 Month cycletime of the ticket already. so seems low priority and not on the radar of development.

7

The 3 users in your linked matomo Github issue are here in the forum under another nicknames. Maybe wait a minute for a comment from the users here. Your linking here is detected in the issue. Further, you can participate to the issue like a “push” and involve your knowledge about the security risks.

9

So basically you say. Nobody cares and does not see it as an issue. 99% will just install it as it is and not bother about security and best practice.

Sure i can talk with support to learn how the file structure works, but this is a general problem, and i am not motivated to fix it, seeing in this forum how nobody even sees this as an issue, or it its a open bug over 6 month.

It just shows the culture and architecture is not good. and i am sure there are a lot of good developers involved. i just don’t understand why this is just ignored.

I am a developer and could help fix it, but i have no hope as it will be too much bureaucracy to get that anywhere close to be part of the official installation.

The solution for now is “hope that nothing breaks” and the developers don’t shoot themselfs in the foot.

How many installation does matomo have ?
A quick googlesearch gives about 10k to 100k WP Plugininstalls for Matomo, and 1Mio Websites in 190 countries. This is more than a handful of users.

Shouldn’t security be some concern and not just be ignored and swept under the rug ?

If by accident some malicious files are installed in the node_modules or similar public folders and not checked for apache/php environment and only secured for node (which even should be serverside and never public in a node.js server).

Why am i the only one concerned by this with 1Mio users ? Something is fishy…

10

Hi Daniel, the post from adriel is Spam.

You can open an Issue in Github for a hint to this possible problem. Or you can open an Pull request and post a possible solution. First you should check whether your assumptions are true. The best way to do this is with an example.

Please give us an example, that other can imitate.

11

Thanks for the reply and taking it serious.

I will make a use case example of worst case scenario with some simulated situation.

(similar to the log4j bug affecting millions by having code executing in unexpected places. Using Murphey s law. What can go wrong, will eventually go wrong. Its not a matter of if. But when)

I am over dramatic to make it more clear. Its not a short term problem but a long term architecture flaw.

I will make examples and pull request or tickets. Whichever fits best to the example. Maybe a pull request with a final solution is not possible at the moment as it would break things like

  • moving folders
  • adding htacess sandbox /firewall

But i can do a next step towards the solution.

12

Hints: inform yourself by closed Issues and solved pull request before. Than you have a knowledge why is working.

13

What we did placing everything behind Cloudflare and we only give access to the the neccesary files matomo.php etc. All the rest is only accessible for interal traffic.

1 Like
14
15

That’s quite good and mostly solves solution 1 using htaccess as a sandbox.

Maybe a first step could be to have this file with good comments as a. .Htaccess.Example. (In the main github Version included)

Similar to phpmyadmin with an example configuration which you have to rename to get it running. And updates will then not override this manual config.

With the instruction to rename to… htaccess or integrate with an existing one.

Or with the installer wizard which is doing database config etc. Already and create a custom htaccess file automatically with the correct path. And the wizard could ask if you want to turn on sandbox for htdocs. Or not and avoid side effects.

In WordPress some Plugins like sucury can be too much and break features. So the final decision should be at the admin for matomo who knows the environment and side effects.

But the default would still raise awareness, even if the admin chooses to skip this step.

In this forum sometimes… htaccess is avoided as it can have side effects when it’s used with WordPress in the same folder. But i think it should be possible to find a compromise without side effects. Usually the htaccess is inside a matomo folder and the htaccess rules don’t t spill outside.

My point is. This configuration should be the default and not for the 1% experts. Security is a problem especially for beginners. A sysadmin can always add some Firewall etc.

I have the same problem with WordPress. As with a default install it is very likely to catch malware in 3 month, but with some simple configuration and Plugins the risk to get malware is nearly zero.

That’s my pesonal opinion (having some experience with that topic) but open for discussion.

16

Hi @Unterberger.Media
In addition to the GitHub ticket you mentioned on February, the 14th:

In Matomo, some security best practices are available:

Also,the admin view offers some security checks:

Finally, there is a Matomo Security Bug Bounty Programme in case of critical security issue:

1 Like
17

Thanks for collecting that useful information, not so easy to find as a beginner after initial installation.

I see one part even tries to explain which file are important and should be whitelisted in the htaccess.

  • Use web server features to restrict access to a few files only, and restrict by IP address
    If you use an Apache web server, it’s easy to use .htaccess files to restrict access to Matomo to your IP addresses, or many more options. Check out the examples.
    When you restrict access to files, please note that you need to allow external access to the following files:
    • matomo.php, matomo.js, piwik.php, piwik.js,
    • and to the URL index.php?module=CoreAdminHome&action=optOut and for the files plugins/CoreAdminHome/javascripts/optOut.js and favicon.ico to make sure the opt-out iframe will work without password prompt.
    • and to js/container_*.js files for TagManager to deliver the container files
    • and to plugins/HeatmapSessionRecording/configs.php if you use Heatmaps or Session recordings

So this information is hidden in the forum. Just took a while to surface.

Technically maybe the best practice could be to put a .htaccess.example in the github as a starting point and admins who want to improve security can use it to make a whitelist.

Then more can be aware of this and less surprises.

I will try these recommendation and sometime make a pull request with an example htaccess which should not cause side effects.

2 Likes
18

Thanks for the discussion. And just to clarify, Matomo already creates automatically the .htaccess to protect the installation. The problem is more apparent for NGINX where this doesn’t apply. For Apache it shouldn’t be a problem with the .htaccess.

19

Thats by mine Matomo Installation not the case. Perhaps, because the server is a mix of nginx and apache. I must add the .htaccess manually.

20

You are correct that having all files in the public folder (htdocs in Apache) is not a good practice from a security standpoint. If sensitive information such as configuration files or source code is stored in the public folder, it can be accessible to anyone who visits the website.

To improve the security of your Matomo installation, you can move the sensitive files outside of the public folder and configure Matomo to access them from there. This is also known as a “non-public” installation.

To do this, you can create a new directory outside of the public folder, for example, /var/www/matomo, and move all files except the ones that should be publicly accessible (such as index.php, piwik.js, piwik.php) to this directory.

Next, you can edit the index.php file in the public folder and update the PIWIK_INCLUDE_PATH constant to point to the new location of the Matomo files. For example:

sqlCopy code

define('PIWIK_INCLUDE_PATH', '/var/www/matomo/');

Finally, you can configure your web server (such as Apache or Nginx) to point to the index.php file in the public folder as the entry point for the Matomo installation.

As for blocking files with an .htaccess file, it is possible to do so, but as you mentioned, it can be difficult to maintain and may not provide full protection. It is better to follow the best practice of having sensitive files outside of the public folder to reduce the attack surface.

21

Yes i understand your idea, and as a developer i can make a workarround and fix it, worst case read the sourcecode to figure out what is active and what are build files.

my point is, it should be easier to do it secure (99% of users) than to make it insecure and fix the installation (1% of admins) , who do it already as they know the “problem”.

Nobody will download the default installation with the wizard from github, and then move files arround like you explained. but just keep it and leave the attack vector.

The point is “defensive programming”, making it impossible to get an exploit like log4j, which could be done here with bad chain of events (eg. somebody uploads malware php into a npm modules which ends up in the node_modules folder).

the .htaccess “sandbox, whitelist” is the most practical approach for now.