homepage Welcome to WebmasterWorld Guest from 54.211.95.201
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Visit PubCon.com
Home / Forums Index / Code, Content, and Presentation / Apache Web Server
Forum Library, Charter, Moderators: Ocean10000 & incrediBILL & phranque

Apache Web Server Forum

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




msg:4535215
 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

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!

 

g1smd




msg:4535222
 8:43 am on Jan 11, 2013 (gmt 0)

In an emergency,

RewriteRule ^\. - [F]

as the very first of your RewriteRule directives.

lucy24




msg:4535251
 11:09 am on Jan 11, 2013 (gmt 0)

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 ;)

1script




msg:4535326
 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.

lucy24




msg:4535373
 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?

1script




msg:4535387
 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.

1script




msg:4535529
 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> ?

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / Apache Web Server
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved