Welcome to WebmasterWorld Guest from 54.167.144.170

Forum Moderators: Ocean10000 & incrediBILL & phranque

Apache 2.2 How to block access to .htaccess file ITSELF?

   
6:42 am on Jan 11, 2013 (gmt 0)

WebmasterWorld Senior Member 5+ Year Member



Ever since 2.2 the most basic server security measure no longer works - I cannot block access to some of the internal files, including .htaccess, in httpd.conf

How come?

None of the usual config commands work anymore, such as
:

<FilesMatch "^\.ht">
Order allow,deny
Deny from all

Satisfy All
</FilesMatch>




You can still easily go to http://www.example.com/.htaccess and see the content in plain text, a ridiculous breach of security.

none of the other file name-based restrictions in httpd.conf work anymore either.

I understand that access is now managed by different modules in 2.2 and here is the list of what's loaded, am I missing something? :



Loaded Modules:
core_module (static)
authn_file_module (static)
authn_default_module (static)
authz_host_module (static)
authz_groupfile_module (static)
authz_user_module (static)
authz_default_module (static)
auth_basic_module (static)
include_module (static)
filter_module (static)
deflate_module (static)
log_config_module (static)
logio_module (static)
env_module (static)
expires_module (static)
headers_module (static)
setenvif_module (static)
version_module (static)
proxy_module (static)
proxy_connect_module (static)
proxy_ftp_module (static)
proxy_http_module (static)
proxy_scgi_module (static)
proxy_ajp_module (static)
proxy_balancer_module (static)
ssl_module (static)
mpm_prefork_module (static)
http_module (static)
mime_module (static)
status_module (static)
autoindex_module (static)
asis_module (static)
info_module (static)
suexec_module (static)
cgi_module (static)
negotiation_module (static)
dir_module (static)
actions_module (static)
userdir_module (static)
alias_module (static)
rewrite_module (static)
so_module (static)
bwlimited_module (shared)
suphp_module (shared)




Would appreciate any comment on this pressing matter.
Thanks!
8:43 am on Jan 11, 2013 (gmt 0)

WebmasterWorld Senior Member g1smd is a WebmasterWorld Top Contributor of All Time 10+ Year Member Top Contributors Of The Month



In an emergency,

RewriteRule ^\. - [F]


as the very first of your RewriteRule directives.
11:09 am on Jan 11, 2013 (gmt 0)

WebmasterWorld Senior Member lucy24 is a WebmasterWorld Top Contributor of All Time Top Contributors Of The Month



am I missing something


:: quick detour to MAMP site ::

Yup, I'm blocked from my own htaccess. (In case anyone wondered: I use htaccess in MAMP, rather than working directly with the config file, because I want to replicate my real site as closely as possible.) I already know I can't get to htaccess in the live site; the host blocks it by default. You get your ordinary 403 page.

:: further detour to MAMP config file ::

<FilesMatch "^\.ht">
Order allow,deny
Deny from all
Satisfy All
</FilesMatch>

That's a direct cut-and-paste. There's got to be something wonky in your system. Did it formerly work and then stop? Do other Allow and Deny directives work as intended?

That opening line "ever since 2.2" implies that you've just recently upgraded. (Ahem.) So this is when you'd expect to find issues. There may be others. You've now got a pretty powerful incentive for fine-tooth-combing ;)
4:53 pm on Jan 11, 2013 (gmt 0)

WebmasterWorld Senior Member 5+ Year Member



Lucy, "MAMP site"? As in LAMP but with an "M"? Mine are all LAMPs.

So, regarding the 2.2 thing: I have recently upgraded one server, and while I was looking for any sign of trouble right after the upgrade, I found this. Then I went back to all other servers I've upgraded to 2.2 since several months back, and ALL of them have the same problem (all cPanel installs, perhaps it matters here). None of the <File> or <FileMatch> directives work anymore.
I did some more digging and it turns out that these directives work in neither httpd.conf nor in respective sites' .htaccess 'es . Basically, the entire file name matching capability is gone!

This worked in 2.0 for sure but stopped in 2.2 I looked around the docs and it appears that mod_access is no longer used in 2.2 and is replaced by a slew of auth* modules and even though I seem to have all of them loaded, there's still something very basic that's missing.

I would have to say that my main concern is that non-working <File> and <Filematch> rules are the default, a very troublesome development.

@g1smd: RewriteRule still works, and this one does as well, but I would also call it an emergency because it would have to be done on each site hosted on this server individually - needless work because this is something I would always enable at the server level.
11:15 pm on Jan 11, 2013 (gmt 0)

WebmasterWorld Senior Member lucy24 is a WebmasterWorld Top Contributor of All Time Top Contributors Of The Month



I would have to say that my main concern is that non-working <File> and <Filematch> rules are the default

I assume that was a typo, since your fingers spelled it "Files" and "FilesMatch" in the first post. Besides, that kind of thing tends to generate 500-class errors and you'd definitely notice those!

The modules have new names and there are more of them, but they work the same. And the <...Match> envelopes are core.

Come to think of it: Any information in your error logs?
12:32 am on Jan 12, 2013 (gmt 0)

WebmasterWorld Senior Member 5+ Year Member



Found the issue!

It turned out that I was using a UserAgent - based 403 rule for bad bots that was within <Location> tags , which was (has to be) after <Directory> and <Files>, and which was conflicting with any file-based matches.

I think this was the part that was different about 2.2 - if you have any rule in <Location> tags that can also apply to an actual file that exists in the filesystem, it will take whatever is in <Location> and not in <Files>, and my UA-based rules were structured like Allow All, Deny BadBot so the Allow All in <Location> took precedence over Deny All in <Files>

I am still wrapping my head around why on Earth it would behave like this (de-403 a request that was already 403-ed by a previous rule) but even the manual says don't use <Location> rules for anything that can apply to actual files. I guess, the assumption is that it should only be used on "Virtual" URLs - like "prettyfied" URLs.
7:47 pm on Jan 12, 2013 (gmt 0)

WebmasterWorld Senior Member 5+ Year Member



Ah, not so quick! My fight with this is far from over! Darn, I should have tested it a bit more.

It looks like if I move the UA-based rules into the <Directory>, it no longer applies to URLs created using .htaccess but it I use ANY <Location> based directives, none of the <Files>-based one work anymore. What the heck? Anyone knows what's going on with <Location> directives canceling out the filesystem-based <Files> and <Directory> ?
 

Featured Threads

Hot Threads This Week

Hot Threads This Month