number of shared links (and the number without a password)
I’m just thinking, if it’s considered best practice to disable even nginx’ and apache’s reporting of server/os version, then maybe the range of system metrics that nextcloud expose to public by default is a little too much. I’m a little worried these might become valuable info for a potential attacker, so I’m probably going to deny public access to these pages.
Is there any more places that nextcloud serves server metrics?
What do you think about the level of info exposed by default, in terms of security and privacy? Maybe I’m over-paranoid?
I just wanted to write the same. And not only do you have to be logged in, only a logged in admin can see meaningful information with this link.
As a “normal” user, I only get:
Sorry to relaunch the subject.
I made an audit of my nextcloud installation (uptodate) and find again this status.php which gives information on the system without beeing logged.
Knowledge on the release of an app, it’s upgrade status, … is very valuable for an attacker.
Those informations enable the attacker to select the right vulnerability to use to enter a system, and avoid detection as he will not try the ones that were corrected.
When a particular vulnerablity will be found, attackers will have prepared a list of servers to attack and rush on those with the right release…
So I do have a different point of view and say that those informations are very sensitive…
Then it is up to you to filter out that URL in a reverse proxy like HAProxy… The other thing is to keep yourself up-to-date and to deploy a security monitoring solution so you can detect when someone tries to do bad things to your setup.
Here, I have Q-Radar Community Edition and guess how many times someone came on my server and probed that status.php file ?
–ZERO–
How many IPs probed your Nextcloud server during last 30 days ? From how many different countries ? Trying to reach which URLs ? How many attempted a password login ?
If you can not answer these questions, status.php is completely insignificant because you are blind to million time worst.
For the question of how many attemps, I can tell that from time to time, I get some bunch of coordinated attemps, comming from a lot of countries around the world, yet, with dictionary type attacks.
The more the nextcloud solution will be spread, the more attacks will raise, and the probability of vulnerability is raising with the number of functionality.
The subject is not yet an urgent matter, but clasifying it as a non issue is agains any concept of defense in depth that should be applied everywhere.
In terms of system architecture, correcting the code is better than trying an external monitoring, which make the security solution more complex and difficult to maintain in the long term.
Yet I don’t know why it is not protected by loggin restriction, and if it’s a complicated matter, to be able to propose a patch of this code. May be others could answer more quicly.
My suggestion is not to correct it in nc15, but in nc19 or nc20, somewhere in a not so long future.
Security by obscurity does not work. Patch management, updates, monitoring, hardening, … These mechanisms work. No point trying to hide in the dark and lie to yourself.
Here, I have been monitoring my cloud for over a year with Q-Radar and never had any brute force attempt against the server. Should an attacker wishes to try one, it will be flagged right away by Q-Radar, long before he will have any reasonable chance to pass the first factor and even less chance to defeat the second one.
By using the docker container, I can easily update my server and have it strictly restricted in the system. By putting data on a FreeNAS server, I ensure that the container has no privilege against it. Even a fully compromised container will not be able to destroy the data beyond a point where I would need more than 5 minutes to restore it.
By using server side encryption, only access that are performed live during the incident can have a chance to be decrypted by both the server and the intruder. The rest will be unusable because file encryption keys are protected by users’ passwords.
That is defense in depth. What you are asking for is not defense in depth, it is security by obscurity.
I agree partly on what you said.
Note: I do have the same type of defenses.
I was refering to security in depth simply to say that it’s one of the elements of a set of barriers. Not that it’s the sole item I am running.
Security in depth => Put many barriers on the hacker path => obscuring the software release, … is one aspect of the complete set.
Even if you used update, monitoring, hardening, in case some day a zero-day exploit is introduced or disocovered in a dedicated release, there will be a race between the update on your server, and the hacker using it.
If he does not know the release of your install, he will need to learn the release of your server, and you will have a chance to catch it’s tries through your Q-Radar and have an automatic ban.
If not as your release is accessible to anybody, he will just ask, get the info and be in a position to execute the exploit without been detected.
By avoiding a person not authorised to access this information, I am just closing some doors.
A person not authorised on my server does not need to know which release I do run on my server.
It is the same for the list of users using it, … I need a layer to manage authentication…
Note: in your case, once logged into you fiirst stage, you may imagine that the harmfull will produce a man in the middle attack against your users password…
I disagree 100% with you on that one. Obscurity is by no mean a security layer.
When a system is designed with actual security, no single incident should be able to take it down by itself. If a single incident is enough, it proves that you do not have defense in depth.
With my setup, the most catastrophic incident would be Remote Exec before completing authentication. Should something like that happen, I can first react by blocking the DNS name I use for my cloud that allows everyone and use only my private one which requires a client side SSL certificate controlled by HAProxy in front of Nextcloud. That is for reaction.
Before that, lets acknowledge that the guy made it in. Great : he is now trapped in a Docker container as a regular User. It has no access to the FreeNAS backend server beyond reading encrypted data or writing extra stuff or deleting stuff. All of that I will recover in a few minutes by rolling back my snapshot. Also, all of these would be without any consequence.
The only thing would be to inject code to intercept credentials, than extract file decryption keys from the database and then recover few files. But even that he will not be able to do for users who will not log in during the incident. Also, my Q-Radar will flag me the guy in no time, so he will have only a few hours before I kick him out of my server.
My server is secured, so does not requires obscurity. Again, security by obscurity does not work. Obscurity is not a security mechanism, so must not be counted for as one of the security layer.
Nextcloud 15.0.7
/status.php
/ocs/v2.php/apps/serverinfo/api/v1/info
I don’t worry about that at all.
We all do small mistakes all the time, so no worries