real newbie question on IP denial

[Dan99]

OK, I'm trying to understand how to block particular IPs from my site. It should be simple, right? I just put

order deny,allow
deny from 11.111.111.111
allow from all

in my .htaccess file, and that should do it, no? Well, I do that, and it blocks everyone, including me (I'm not 11.111.111.111 !) What in the world am I doing wrong?

Some places say I should be putting <Limit GET PUT HEAD> and </Limit> around the order, allow, and deny statements, but that doesn't seem to help. What do those Limit commands do, and when should I use them? I'm confused.

I presume that because it's paying attention to the .htaccess file in the first place, I have my httpd.conf file set up correctly.

This is Apache 1.3, BTW.

[aakk9999]

In your example the "allow" directive should override "deny" directive, so everything should be allowed, so I am not sure why you say everyone is blocked.

Have you tried using the order the other way around?

order allow,deny
deny from 11.111.111.111
allow from all

This should firstly evaluate "allow" (lets everybody through the first step) and then subsequently when evaluating deny, it should block 11.111.111.111

Apache 1.3 mod_access: [httpd.apache.org...]

[Dan99]

Yup, that did it. Reversing the order of deny and allow, exactly as you suggested. Works perfectly now. Everyone can get in except the IP I denied (I tested this on another IP I can VPN to.) Many thanks!

But that really doesn't make a lot of sense, does it? The original way to do it SHOULD have worked. One wonders if you can only deny an IP

after

it has been explicitly allowed?

That being resolved, what's this about "Limit HEAD GET POST PUT, etc" and why do many people put that before these allow-and-deny statements? What's that about?

[aakk9999]

One wonders if you can only deny an IP

after

it has been explicitly allowed?

These are two separate evaluations. So the second overrides the first.

what's this about "Limit HEAD GET POST PUT, etc"

I stand to be corrected, but I presume this limits the rules to listed methods. So if you have Limit POST then the blocking would only happen for POST requests, but GET etc. requests from the same denied IP would go through.

If you want to block any kind of access from a particular IP, I think you do not have to specify the "Limit" directive.

[JD_Toims]

I stand to be corrected, but I presume this limits the rules to listed methods. So if you have Limit POST then the blocking would only happen for POST requests, but GET etc. requests from the same denied IP would go through.

If you want to block any kind of access from a particular IP, I think you do not have to specify the "Limit" directive.

Correct.

Allow / Deny [Mod_Access]: [httpd.apache.org...]
Limit [Core Features]: [httpd.apache.org...]

[lucy24]

One wonders if you can only deny an IP
after
it has been explicitly allowed?

You may be reading the "Order" rules in --haha-- the wrong order.

Order onething,otherthing [no space]
=
First all lines beginning in "onething" are read.
Then all lines beginning in "otherthing" are read, potentially overriding "onething" directives.

The horse's mouth [httpd.apache.org] (add fragment #order if eaten by forums here) has a simple table showing all the permutations. Note in particular:

No match >> Default to second directive
Match both Allow & Deny >> Final match controls

I wish they wouldn't say "second directive" and "final match", making it sound as if they're entirely different things. But the key thing is that "otherthing" is the default when the rule fits either both conditions or none. No change between 2.2 and 2.4.

Hey, JD, I don't think I ever realized that apache dot org had a /current/ pseudo-directory paralleling the exact numbers 2.2 and 2.4.

[Dan99]

If you want to block any kind of access from a particular IP, I think you do not have to specify the "Limit" directive.

Excellent. That's what I figured, but wasn't sure. If I'm going to block a GET, I see no reason why I shouldn't block anything else!

Some examples I've seen have "Limit GET POST", and others have "Limit GET HEAD POST". Is there some reason why one would want to have someone access a header without being able to GET the file?

First all lines beginning in "onething" are read.
Then all lines beginning in "otherthing" are read, potentially overriding "onething" directives.

That makes sense, but I just didn't understand how what I originally wrote could be interpreted as "Deny all"! Something fishy here.

Many thanks again for your prompt advice!

[JD_Toims]

<OT>

Hey, JD, I don't think I ever realized that apache dot org had a /current/ pseudo-directory paralleling the exact numbers 2.2 and 2.4.

I didn't until today either -- I usually just click the first result for Apache and then change the 2.0 or 2.2 to 2.4 in the URL, but it didn't work for Mod_Access, because apparently it's been renamed to Mod_Access_Compat so I had to dig around the Apache site and ran into it.

</OT>

[lucy24]

Some examples I've seen have "Limit GET POST", and others have "Limit GET HEAD POST". Is there some reason why one would want to have someone access a header without being able to GET the file?

In general you can ignore this type of <Limit> unless there is some specific filetype on your specific site that you need to constrain to particular request types. There are more methods than you can shake a stick at but in practice all you'll ever see is GET HEAD POST.

If it were your own server you might want to say something about PUT, but on shared hosting you have to assume that the config file already blocks it appropriately. (Not out of the goodness of their hearts, but because cleanup can be expensive and time-consuming. Same goes for things like general blocks on files with names in .ht, or standard names for error documents.)

I do have a generic RewriteRule that blocks all POST requests except for those files (analytics, contact form) that actually allow POST input. But it's more for personal satisfaction, since they tend to try posting to things like wp-admin that I don't have anyway.

I have apache's mod_rewrite page bookmarked. If I need something else, I go there and then follow the "Modules" or "Directives" links at the top.

[Dan99]

Aaargh. So I get up this morning, and everyone is getting denied access! Status codes 500 all over the place. I could have sworn it was working before. What I have now, in my .htaccess file is just

order allow,deny
deny from 11.111.111.111
allow from all

In fact, if I just do

order allow,deny
allow from all

Everyone still gets denied.

Help!

[lucy24]

Awwwwk!

500 is not "getting denied". It's an error.

The three lines you quote don't have anything wrong with them. Unless your server is so persnickety that it insists on standard casing:

Order Allow,Deny
Deny from ...
Allow from ...

But I can't imagine this triggering a 500-class error. At worst it just wouldn't work. There has to be something else wrong. Do you have access to your site's error logs? If there's a syntax error in the htaccess file, the logs will point to exactly where the problem is. ("Unexpected blahblah here", or "Expected to find suchandsuch line".) For example
:: cough-cough, ahem, been there, done that ::
a <FilesMatch> envelope closed off with </Files> because you changed something at the last minute.

If you don't have access to the error logs we'll need to take a closer look at your htaccess. Start with anything you've changed recently.

[Dan99]

This is my own system (Mac 10.3.9, an old system that has been relegated to webserver-hood!) so I do indeed have error logs. Thanks for pointing that 500 out as an error. And here is what the error log says ...

[Mon Sep 16 08:30:00 2013] [alert] [client xx.xxx.xx.xxx] /Users/mysites/Sites/.htaccess: order not allowed here

So, yep, the order of something in that .htaccess isn't allowed. But that message isn't too helpful about what it is that it doesn't like.

I'll try uppercase.

[Dan99]

Nope. Uppercase doesn't help. Same Status 500 error.

Now, my .htaccess file is clearly getting read, because when I change it, things happen (for better or worse). But something about what I've written there is indigestible to my Apache 1.3.

[JD_Toims]

Sounds like the AllowOverride settings in your httpd.conf aren't inclusive of Limit, which means you can't use order, allow, deny in the .htaccess.

Editing the AllowOverride line in the httpd.conf file to be more relaxed [or at least inclusive of Limit] should fix the issue.

http://httpd.apache.org/docs/current/mod/core.html#allowoverride
[Delinked to keep the fragment identifier intact]

[Dan99]

OK, I *think* my httpd.conf file was, indeed, not set up right. Following some other advice, in /etc/httpd/httpd.conf I set

# This controls which options the .htaccess files in directories can
# override. Can also be "All", or any combination of "Options", "FileInfo",
# "AuthConfig", and "Limit"
#
AllowOverride All

and then in /etc/httpd/users/Me/httpd.conf I set

<Directory "/Users/Me/Sites/">
Options Indexes MultiViews
AllowOverride All AuthConfig
Order allow,deny
Allow from all
</Directory>

The I restarted Apache, by turning off Web Sharing and turning it back on.

So far so good. At least with the .htaccess as set above, there are no errors and it looks like everyone can get in who is supposed to be able to get in. I just need to check if the IP I'm testing denial on is really turned away.

Does this sound right?

[lucy24]

:: insert boilerplate about typing too slow ::

AllowOverride All AuthConfig

You may be confusing overrides with options. In AllowOverride directives, "All" really does mean all. (In Options it means everything except, uh, MultiViews? One item, anyway.)

When this directive is set to All, then any directive which has the .htaccess Context is allowed in .htaccess files.

Wording identical in 2.2 and 2.4. You're not running 1.3 at this late date, I hope! In 2.4 the default is None; earlier it's All. 2.4 also has a nifty extra called "Nonfatal" which appears to mean that if you goof in htaccess, the server will not explode. (I predict this will be a huge hit with hosts, as it effectively makes htaccess behave like HTML: "If you don't understand it, ignore it.")

If you have
Deny from ... some-IP-range
you probably also have something like
Deny from env=keep_out (or bad_bot or name of your choice)
that works with mod_setenvif on simple user-agents like "curl" or "MSIE 2.0". You can then test your mod_authz-whatsit lockout by setting your own IP-- or exact UA, or whatever feature is most likely to be unique-- to keep_out, and see if you're locked out.

Make sure you have a <Files> exemption for your custom 403 document!

Edit

Sounds like the AllowOverride settings in your httpd.conf aren't inclusive of Limit, which means you can't use order, allow, deny in the .htaccess.

I don't see the connection. "Order" and "Allow/Deny" directives can be loose in htaccess; they don't require <Limit> envelopes.

[Dan99]

You're not running 1.3 at this late date, I hope!

1.3.33 to be precise, sez curl. Ten year old Mac, flat out on 10.3.9. No options. If I could upgrade, I would.

I *think* it's doing the denials properly now. I denied access to 123.125.67 because someone in Beijing was doing mischievous and slightly bandwidth intensive stuff on my site. Now I see their latest access got a 403 in my log. They're gone. Yes!

Interestingly, many IP range formats don't seem to work for me.

deny from 123.125.67 works, but
deny from 123.125.67.0/155 does not work (produces an error), and so does
deny from 123.125.67.0-123.125.67.255

That's a bit strange, because I though this parsing was supposed to work in 1.3+.

[lucy24]

deny from 123.125.67.0/155 does not work (produces an error), and so does
deny from 123.125.67.0-123.125.67.255

I should hope so, since /155 is meaningless. And CIDR ranges are independent of Apache.

:: detour to refresh memory on mod_access (its name in 1.3) ::

The options are the same in 1.3 as in 2.x; it's just got a different name:

aa.bb.cc.dd (up to 4 sets of numbers, each in the 0-255 range)
aa.bb.cc.dd/xyz (where xyz is a number in the range 1-32)
aa.bb.cc.dd/ee.ff.gg.hh (too complicated to bother with ;))

So the possible forms are
123.125.67
123.125.67.0/24
123.125.67.0/255.255.255.0

When the number behind the / is a multiple of 8, the first form is obviously easiest.

Edit as shoe drops:
123.125.67? Sheesh, 123.112-135 is solid China. I've got them blocked as
123.112.0.0/12
123.128.0.0/13

[Dan99]

I should hope so, since /155 is meaningless.

Typo. That should have been /255. But why would /155 be meaningless? Isn't that .0-.155 (and not .156-.255)?

[Dan99]

Oh, of course. I still have to understand CIDR. Yeah. 123.125.67.0/24. I get it. Thanks.

[lucy24]

In the beginning I had to count on my fingers and write everything out in binary. But you internalize it after a while. Honest, Don, you do.

123 = 255 - 128 - 4 = 11111111 - 10000000 - 00000100 = 01111011
125 = 255 - 128 - 2 = 11111111 - 10000000 - 00000010 = 01111101
67 = 64 + 2 + 1 = 01000000 + 00000010 + 00000001 = 01000011

and so on.