mod_userdir Does Not Seem To Be Working As Expected
I am trying to maintain PCI compliance with our server, but one of the issues that is standing in the way of that is the UserDir directive. I have mod_userdir protection enabled via WHM, but I find I can still reach the websites via IP_ADDRESS/~user/, which the compliance scanner claims is a vulnerability since the username is provided in the directory. Looking at httpd.conf, I see the following:
## User USERNAME # Needed for Cpanel::ApacheConf
UserDir disabled
UserDir enabled USERNAME
This is set up for nearly every zone. What is the purpose of enabling mod_userdir protection if the cPanel is simply going to override it in the apache configuration? How do I remove this feature once and for all? Is it safe to remove these UserDir lines from httpd.conf?
Thanks for any assistance offered.
-
I've never really looked at the specifics, but userdir protection seems to be very iffy. I've used ModSecurity to fix this on PCI scans before. Something like this old atomic rule in modsec2.user.conf or another modsecurity includes file: SecRule REQUEST_URI "/~(root|ftp|bin|nobody|named|guest|logs|sshd)/" "id:28374625,deny,status:404" You could change 'logs' to the appropriate username to block, or add more pipe characters and add other usernames. 0 -
[quote="RedNinja, post: 1686531">I have mod_userdir protection enabled via WHM, but I find I can still reach the websites via IP_ADDRESS/~user/
Are you sure you do not have protection excluded for the "DefaultHost (nobody)" user? Thank you.0 -
It seems a bit quirky, since there isn't an account with the username nobody, and for that to override every account while also being set as a default exclusion, to have it operate in this manner. However, removing that checkbox has done the trick. Is that part of a recent update? Because previously everything was unchecked (hence the reason it never popped up on any previous PCI scans before). Thanks for the assistance. 0 -
The "DefaultHost (nobody)" will allow you to access those URLs over the IP address or hostname of the server. It's enabled by default because it's fairly common for users to expect this behavior, and not realize that excluding protection for a domain name on it's own will not allow for viewing the temporary URL over the IP address. Thank you. 0 -
[quote="RedNinja, post: 1686531">What is the purpose of enabling mod_userdir protection if the cPanel is simply going to override it in the apache configuration? How do I remove this feature once and for all? Is it safe to remove these UserDir lines from httpd.conf?
What is the purpose of enabling mod_userdir protection if the cPanel is simply going to override it in the apache configuration? This is set up because of the way Apache inherits configuration settings. If userdir is enabled in the global area of httpd.conf, then all virtual hosts inherit that setting. The problem with this is, that others can also use your virtual host with their own username unless each virtual host specifies a different setting. For example: OK -> OK -> The "NOT OK" example, is generally something you probably don't want to allow. To keep userdir enabled for a single virtual host, but prevent other users, you must disable userdir in each virtual host (thereby wiping the global setting), then re-enable it with just the user(s) you want to allow. This ensures that no other user can come in through a different virtual host, but still access their own files (e.g. evading bandwidth quotas). How do I remove this feature once and for all? If you're sure you don't want any kind of userdir support, try creating a per-virtual host config for EACH virtual host, then add the following to it: UserDir disabled e.g. Assuming Apache 2.2, /usr/local/apache/conf/userdata/std/2_2/user/userdomain.tld/userdir.conf Is it safe to remove these UserDir lines from httpd.conf? It would be safer and easier to use per-virtualhost include configs, rather than setting up your own custom configuration template. You also need to consider Frontpage users, as well as shared SSL certificates if you are using either of these features.0
Please sign in to leave a comment.
Comments
5 comments