Welcome to WebmasterWorld Guest from 3.227.249.234

Forum Moderators: Ocean10000 & phranque

Message Too Old, No Replies

Multiple Require All Granted/Denied or Deny All / Allow Directives

     
1:02 am on Mar 9, 2016 (gmt 0)

Moderator

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

joined:June 2, 2003
posts:8055
votes: 101


After re-reading Apache.org's documentation concerning the merging of rules I'm still a bit unclear about how rules that set "Deny / Allow All" or "Require All Denied / Granted" work harmoniously. That is, how unrelated or separate "allow alls" and "deny alls" manage to NOT screw each other up when all directives are merged.

I've been working on building configuration files that incorporate a variety of directives, such as:

    <FilesMatch> - To bar access to files such as xmlrpc.php, wp-config, etc

    <RequireAll> -> Require all denied to block IP addresses

    SetEnvIfNoCase Rules to block bad bots, UAs or dubious query strings

    Rewrite Rules for anti-hotlinking

    Disallowing POSTs to certain files

    Etc


In several cases the multiple directives incorporate "Allow all" -> "Deny (this)" logic.

I've read that the order of merging directive "containers"(?) goes like this:
    <Directory> and htaccess merged first & simultaneously

    <DirectoryMatch> next

    <Files> and <FilesMatch> next & simultaneously

    <Location>

    <If>


Still, for all my reading, it remains unclear how separate allow all / deny all directives don't upset one another.

Can a final "Allow all", when it comes to a directive regarding UAs, interfere with separate "Deny all's" relating to blocking IP addresses or access to certain files?
3:00 am on Mar 9, 2016 (gmt 0)

Senior Member from US 

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

joined:Apr 9, 2011
posts:15896
votes: 876


Can a final "Allow all"

What does "final" mean in this context?

Remember that all those SetEnvIf directives do not, by themselves, say anything about access. You're just defining an environmental variable that will be used by later Allow or Deny or Require statements. To be fully effective, they should be at the highest possible directory level -- either lying loose in a <VirtualHost> envelope or in the <Directory /> section -- so they will apply to all requests, regardless of what you plan to do with them.

It would be perfectly legimate to have
Allow from env=special_case
in one place, and
Deny from env=special_case
(referring to the very same environmental variable) in a different place. The server doesn't care.*

In general, the essence of a <Files> envelope is to make special rules, whether those are stricter or looser than your default rules. (Let everybody see robots.txt; let nobody see your admin files.) Each new envelope has the potential to override all previous envelopes, where "new" and "previous" mean "in the order that the server meets them".

Now, I know I've asked this before, but are you absolutely certain you need a <Location> envelope? It seems like borrowing trouble. If there are a few rules that are only meant to apply to specific URLs, and those URLs cannot be made to conform to anything in the (physical) directory structure, you could always do it with a RewriteRule, where the body of the rule lays out the URL.


* Can't help thinking this line belongs on a T-shirt.
4:14 am on Mar 9, 2016 (gmt 0)

Moderator

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

joined:June 2, 2003
posts:8055
votes: 101


I am quickly learning that the server DOESN'T care, Lucy.

"Final" means when all the directives are gathered together in a Pre VirtualHost config include file and one of the several "Allow from all" or "Deny from all" is the last one digested / iterated over by Apache / the server.

Regarding my use of <Location />, when every other attempt I made to block IP's via a Pre VirtualHost include file FAILED an admin in Servint's NOC wrapped my IP block list in a <Location /> container and voila! The server stopped complaining. (Maybe he was just taking a shortcut?) The weird thing is I haven't checked to see if those IPs ARE actually being blocked . . or if the server just . . didn't care. Argh.

I also see this (below) in Apache's documentation and it leads me to believe that "it's acceptable" (YMMV. I'm relatively new to this effort as something other than "another copy+paste webster".)

An exception is <Location "/">, which is an easy way to apply a configuration to the entire server
From here: [url] [httpd.apache.org...]

Unfortunately, I'm at the really uncomfortable stage of not knowing by reading but not by experience AND not knowing enough to know what I don't know. I've probably invested ~50+ hours in the past 3 weeks studying Regex and Apache directives.

Sigh. Head down. Soldier on. (I really appreciate all your input and guidance.)
2:32 pm on Mar 9, 2016 (gmt 0)

Moderator

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

joined:June 2, 2003
posts:8055
votes: 101


Lucy, I'm beginning to see the light. <Location /> may not be my friend.

Sometimes a good night's sleep allows one to see things that blurry-eyed people fail to see.

Authorization / Authentication / Access Control? Who woulda thunk they're something other than "the same thing".

Oh, and that thing about directives that are only given their superpowers"in context". That reality creeps in slowly.

Machines are machines. Math is math. Some rules are cast in . . code.

Damn code! Why does it have to be so unforgiving, so demanding?!

Then again, my new friend may just be a little flexible <If> . .
3:12 am on May 2, 2016 (gmt 0)

Full Member

10+ Year Member

joined:May 5, 2003
posts: 319
votes: 0


WebWork;
Maybe i can help, since I publish IP blocklists, using Mod_Authz (previously Mod_Access).
When dealing with Apache 2.3 and older, I use "deny from" and "allow from" directives under the "Files" wrapper. There is a required statement called "order" which specifies the order in which the server processes the IP addresses, user agents, etc, in a blocklist. By stating the rule as "order deny,allow" one tells the server to deny from the specified deny rules first, then allow anything not listed.

For Apache 2.4 and newer the definition becomes (example):
<Files *>
<RequireAll>
Require all granted
Require not ip 000.000.000.000/12
Require ip 123.456.789.0/21
</RequireAll>
</Files>

Now the strange thing about Mod_Authz blocklists is that Mod_Rewrite rules can override them! So, to stop any of my rewrite conditions from interfering, I add thee following rewrite rule high up in the rewrite list (I am using a custom 403 page in this example):

RewriteRule ^403\.(s?html|php)$ - [L]

This tells the server to stop processing any further for any IP that has been 403'd.

The rewrites can be used to finetune an action for individual IP addresses that are in a blocklist. By placing a special action above that final [L] rule you can override the 403 response. I use this sometimes to send really unwanted (referer spam, etc) traffic into endless loops back to 127.0.0.1.
3:16 am on May 2, 2016 (gmt 0)

Full Member

10+ Year Member

joined:May 5, 2003
posts: 319
votes: 0


I forgot to show my use of "order deny,allow. Imagine this mini blocklist:

<Files *>
order deny,allow

# Unwanted IP addresses:
deny from {ips and cidrs}

#Poke a hole for a friendly user
allow from 123.456.789.0

</Files>

# Block world access to your .htaccess
<Files .htaccess>
deny from all
</Files>
6:04 am on May 2, 2016 (gmt 0)

Senior Member from US 

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

joined:Apr 9, 2011
posts:15896
votes: 876


<Files *>

PLEASE do not use this locution unless it's your own server-- and if it is your own server, why bother with a <Files> envelope at all? You can achieve the identical result by just dropping your rules loose in the config file.

The problem with <Files *> for most users (that means people on shared hosting) is that it will override any and all <Files> or <FilesMatch> rules set up at higher levels (config as opposed to your own directory) for specific filenames. So, for example: a rule in config poking a hole for "forbidden.html" (or equivalent name) will be overridden by a <Files *> in htaccess. A rule in config that comprehensively bars everyone from files in .ht (.htaccess, .htpasswd and so on) will be overridden by that same <Files *>. And then you have to make your own <Files> envelopes to restore the rules that you've just wiped out, where you could have avoided the whole problem-- and saved the server some annoyance-- by not having a * in the first place.
1:28 pm on May 2, 2016 (gmt 0)

Full Member

10+ Year Member

joined:May 5, 2003
posts: 319
votes: 0


Lucy;
In lieu of a <Files *> wrapper for a mod_authz blocklist, what would you use instead, in a shared hosting environment?
4:15 pm on May 2, 2016 (gmt 0)

Senior Member from US 

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

joined:Apr 9, 2011
posts:15896
votes: 876


Nothing. You don't need a wrapper at all.