|Apache 2.2 How to block access to .htaccess file ITSELF?|
| 6:42 am on Jan 11, 2013 (gmt 0)|
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
None of the usual config commands work anymore, such as
Deny from all
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? :
Would appreciate any comment on this pressing matter.
| 8:43 am on Jan 11, 2013 (gmt 0)|
In an emergency,
RewriteRule ^\. - [F]
as the very first of your RewriteRule directives.
| 11:09 am on Jan 11, 2013 (gmt 0)|
:: 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 ::
Deny from all
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)|
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)|
|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)|
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)|
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> ?