Ubuntu 22.04.1 LTS
Apache/2.4.54
Moodle 4.1+ (Build: 20221216)
Following the directions here https://docs.moodle.org/401/en/Apache#Hiding_internal_paths does not work for me. I added the rewriterules to /etc/apache2/apache2.conf
And it did not change the behavior, and the security check in Moodle still fails the public / private paths test.
I have found information on creating and doing it with the .htaccess file, but that causes a performance hit I believe
.htaccess file can be also put directly into server configuration files. In fact, the official Apache documentation recommends using server configuration files instead of .htaccess because Apache processes it faster that way.Not a certified security expert .... although I see by Google ads one can acquire such credentials in less than a year! :|
Consider below to be my 2 cents ... as well as some additional thoughts - thinking out-loud.
True ... using .htaccess files are read all the time ... with apache. Nginx?
Yes, small performance hit ... almost negliable. Not enough me thinks to drag the server to a creepy crawl, though.
.htaccess files are also hierarchial ... the one at code root controls everything below unless overridden by another .haccess file in some other location of code.
That is quite a listing presented ... obviously, this security check needs to discover to present. There are other ways of hiding directory listings ... a blank index.html or default.htm in a directory would not allow directory viewing /vendor/ and example.
All the readme.txt files in the package (prior to downloading or acquring via git could be renamed to .readme.txt. And if apache not allowed to display hidden 'dot' files ... problem solved. Even if not protected, calling them up usually shows the first version info ... like for 4.0 ... and not any additional information for 4.0.5+ - unless the update included something new.
Then there is what's expected to be there for other open sourced libraries in moodle.
Obviously, if one is using git to acquire the code, good idea not to allow group/others ... etc. to see contents of .git directory. Those should be set to read/write/ for root user ... and there's a rub for those who host moodle's on shared hosting ... everything in that users account belongs to that user login - can change to root nor any other user cause the other users don't exist ... well maybe the ftpuser. Some really cheapo shared hosting plans don't have a terminal anyway.
Mind providing a listing of what is failing?
I've going through a 4.0.highest and changing ownerships/permissions to get 'greens' ... but can see that will hinder checking server environment and updating the component via GUI Admin. :|
Conflicting advice as well .... run scripts with user apache and not root?
Another thought ... If this thing is discovering ... what about addons installed? (the readmes that come with those).
All in all, am wondering if this isn't better done with WAF's ... many providers now have mod_security available to users ... with basic rules.
Anyhoo ... like I said for what it's worth ... but again, mind sharing what is failing the check?
Here's one of mine:
mod/book/README.md
'SoS', Ken
Ok, we know OS, but what about hosting? Shared/VPS?
IF you have dedicated VPS and access to root user, the .git directory and all of it's contents need to have owner root and no group/other access recursively.
Ditto for .github directory. Any other .gitxxx file, root only.
Ya see, the fact that, git directory and files are replying with a 404 means the poke has info ... .git is there and access is denied. There is only one official git repo for moodle code (and one alt that could be used in a crunch) ... so If I could remotely poison your servers ability to look up that repo via DNS and point that to a rogue repo ... think you can see that if a hacker really wants to get to your server ... this security check is but tip of an iceburg ... but that's my 2 cents!
Take a look at those readme.txt files - or even upgrade.txt files. If I have a 3.9.highest maintained by git, many of the readme.txt and upgrade.txt files will disclose I have a 3.9.0 ... but not the 3.9.highest.
Besides that ... all one needs to do really is to download or acquire moodle code via git to a local machine and they can see ALL the code anyway!
Think most of what you listed could have their ownerships/permissions reset and moodle security check would then report 404 - green - but question is what have you just broken?
One I saw ... environment.xml and environment.php. If you lock those down and then go to Server Environment check via the web can you update the component?
Not a security person but do have to admin the backend. Wonder if some of those checks are kinda overly concerned.
What, of course, would be serious ... non-authenticated user being able to execute a script remotely. Wonder if mod-security and SeLinux aren't really enough without making it more difficult for you the admin user?
Shared hosting has an issue with this ... they cannot su to root ... matter of fact all files in moodle code belong to account login name and such a setup in a user jail can't use/change owners ... permissions yes.
One of the things one could do (not seen it mentioned) is to force logins ... NO GUEST access. Realize there would be some folks not happy with that, but ...
Another suggestion since you have Linux ... install logwatch. Set it to 10 reporting ... highest/all. Then check the daily email root user would get about the activity the day before. Focus on the http portion. You'll see what but not IP that did it. For IP that did it, you'll have to search your apache/web service access logs for that entry. See a bunch from one IP? Use operating system firewall to block - that's at the network layer ... never gets to application (WAF/Apache/Moodle/WordPress/Log4J whatever).
Something else observed ... if moodle code is in a directory rather than at root of web server docs, the bot scans miss you moodle. Now if you see stuff in logwatch pointed at that directory, then there is a good reason to investigate!
Anyhoo ...
'SoS', Ken
