Still trying get this secure


#1

My ideal scenario is I can use analitics over vpn to my sites.
Unfortunately give it a go with lot of scenarios already.
Really can’t understand why you are thinking that metrix server should be external accessible when you just offer apache solution to secure it.
But any way htaccess file when is a bit more basic from you offer breaking all the installation.
I understand that metrix need be good connected to site and but still cant understand why I need dedicate some box just to get this working.
Is this failure against commercial solutions?
Guys you like to advise everyone to have external server just to get your soft working?
How about VPN networks.
You are advising that some major solution works on your development also but this is not true.
You are not compatible even with .htaccess from apache project.
My scenario is get piwik server over vpn to my sites
For now nothing from your offered options works.
Basicly if you start play with htaccess following apache advise you can brake your matomo install.
Be there already.
I appreciate your soft but do you have some projects going more like matomo proxy or whatever or you like make manuals up to date?
Thanks in advance
I’m open source man and already build lot of nice companies on top of it.
Just don’t be lack in functionality.


(Fabian Dellwing) #2

I’m till trying to see why Matomo is not secure if it is publicly available. Do you know anything, that everyone else does not know?

And just to be sure: The only tracking method that needs Matomo to be open to the public is the JS tracking. Every other method like PHP or Log, does not have this requirement. So, don’t tell me there are no possibilities, there are MANY of them. You just want to use the easy out and are not even able to contruct an htaccess that fits your needs while keeping Matomo working. A thing that many people here in the forum were able to.

Here is a very very basic way to completely shut down every not needed access to your Matomo instance.

<Files "*">
 AuthType Basic
 AuthName "Piwik"
 # to be explicit, state the provider
 AuthBasicProvider file
 AuthUserFile "/PATH/TO/.htpasswd"
 Require valid-user
</Files>
 
# Allow external access to piwik.php, matomo.php, piwik.js, piwik.php and robots.txt
<FilesMatch "(^(piwik|matomo)\.(php|js)|robots\.txt)">
 Require all granted
</FilesMatch>

# Allow Opt-Out
<Files "index.php">
 <If "(%{QUERY_STRING} =~ /^module\=CoreAdminHome\&action\=optOut(?!.*module\=)(?!.*action\=)/)">
   Require all granted
 </If>
</Files>

(Lukas Winkler) #3

In case you (or someone else) does: You can now earn money by telling us with our new bug bounty on hackerone:


#4

This file just give me internal error.
I’m on Centos7 and Apache 2.4.6. Apache auth is working and directory is restricted but Matomo is death.

AuthType Basic
AuthName "Metrix"
AuthBasicProvider file
AuthUserFile /var/www/html/.htpasswd

# All files by default require authentication...
<Files "*">
    Require valid-user
</Files>

# ... except piwik.php and piwik.js which do not require authentication
<FilesMatch "^piwik\.(js|php)|robots\.txt$">
    Require all granted
</FilesMatch>

Tried with Login Http Auth module on and off and still the same.


(Fabian Dellwing) #5

Show the error from the error_log, we are not able to guess what is wrong…


#6

Ok figured out. The problem was .htaccess and .htpasswd file permission.Is it any way to exclude some networks from auth so for ex IOS app can be used?


(Fabian Dellwing) #7

If you use apache2 >= 2.4 you can just add Require ip 1.2.3.4 after your Require valid-user. If not, it is a bit more complicated, ask if needed.


#8
<Files "*">
   AuthName "Metrix"
   AuthType Basic
   AuthBasicProvider file
   AuthUserFile /var/www/html/.htpasswd
   Require valid-user
   Require ip 192.168.0
</Files>

When did that this open access for everyone again.
I mean to external IP also.


(Fabian Dellwing) #9

Your english is so bad, I’m not quite sure what you want to tell me. But I can say, that 192.168.0 is not a valid IP.


#10

Require directive can be noted not only by single IP can be also in IP/netmask or cidr note “Require ip 192.168.0” mean you are allowing all 192.168.0.0/24 net range.


(Fabian Dellwing) #11

Never heard of that, but ok maybe I’m to used to CIDR for that.

You did not tell me what you meant with:

When did that this open access for everyone again.
I mean to external IP also.


#12

When i have added "Require ip 192.168.0” to my .htaccess file like you recommended this open access to any IP address on the Matomo server.
What I’m trying to achieve is I will be able to access Matomo from my local subnet without auth. But all external request will be authenticated.


(Fabian Dellwing) #13

That is exactly what this line should do.

  • If client IP in 192.168.0.0/24 allow access
  • If client IP not in 192.168.0.0/24 use basic auth

Please confirm, that you are indeed using apache version 2.4 or higher.


#14

Already confirmed in this post.


#15

Tried CIDR notation also and singl IP.
When add this directive all Matomo became open to external IP also.


(Fabian Dellwing) #16

Is your Matomo instance behind some sort of proxy or do you use portforwarding?

My advise is taken from: mod_authz_core - Apache HTTP Server Version 2.4

When multiple Require directives are used in a single configuration section and are not contained in another authorization directive like <RequireAll>, they are implicitly contained within a <RequireAny> directive. Thus the first one to authorize a user authorizes the entire request, and subsequent Require directives are ignored.

Did you maybe authenticated via user/password before trying the IP setting? Most browsers will hard cache the authentication and send it again.


#17

Matomo is behind revers proxy.
I’m testing it both from local and external.
I’m trying to find the way because with authentication can’t use IOS app for Matomo.

Tried also wrap it

# <RequireAll>
#   Require ip 192.168.0.0/24
#   Require all granted
# </RequireAll>

No success. (without the hash #) of course.


(Fabian Dellwing) #18

Well, this is most likely the reason. Take a look at your access log, I think all requests will come from the same IP (the IP of the proxy) and this IP is in 192.168.0.0/24.


#19

This is not a case because when I comment this subnet line I get proper behaviour.
But following Apache tutorial probably this line should be before auth request in htaccess file.