Correct syntax to deny domain in mod access, mod auth host

deny by domain

[Iskandrian]

I am embarrassed to be having to ask this, but I am trying to block a certain frequently encountered 163data domain from China by domain rather than by individual IP and having no success.

These typically come in in the form of

### dot ### dot ### dot ### dot broad dot fz dot fj dot dynamic dot 163data dot com dot cn

According to apache.org, either mod_access or its successor mod_auth_host (some question now which Apache version my server is running) should allow me to mix textual domain names, full or partial, in their sections allowing/denying access by numerical IP.

Thus, I should be able to enter just example.com.cn as the partial root of the full remote IP example above and it should be blocked without having to block every dynamic IP address originating from that domain individually. But it is not blocked. Nor are such origins as example.xx, xx being a country code.

Either I am overlooking something incredibly obvious, in which case I apologize in advance for my obtuseness, or I am fundamentally misunderstanding the block by domain possibilities which to me appear to be unchanged from mod_access to mod_auth_host.

Perhaps I am simply using the wrong module/htaccess section to address these.

Your help is appreciated.

[penders]

I think that we probably need to see your code?

[not2easy]

If it makes a difference, you can usually find your Apache version by looking at headers or else in the host information in your control panel for some hosts.

[Iskandrian]

I think that we probably need to see your code?

My code is the traditional

Allow from all

Deny from ###.###.###.###
Deny from example.com.cn

Thus, as you can see below, "Deny from 163data.com.cn" has so far done nothing.

Since I posted this, I ran across this caution from another host, not mine:

Important! THIS IS NOT RECOMMENDED. If you use a host name in a Deny rule in the .htaccess, Apache will convert your Apache log into host names instead of IP addresses. This will remove your ability to see the logs with IP addresses. You will want to use the IP address instead of host name; unless, you want to check your site access by host name alone.

and so, just to be safe, temporarily commented out my example.com type entries earlier today after posting here.

Nonetheless, for some time my Apache has been logging the IP section with mixes of IPs and host names; these entries are a sample of the actual IP and date entries of successive lines from yesterday:

72-46-140.static.versaweb.net - - [12/Jul/2014:01:13:14 -0700]
197.77.197.218 - - [12/Jul/2014:01:14:20 -0700]
39.48.215.124 - - [12/Jul/2014:01:15:07 -0700]
129.60.151.27.broad.fz.fj.dynamic.163data.com.cn - - [12/Jul/2014:01:15:16 -0700]
13-139-3-149.rackcentre.redstation.net.uk - - [12/Jul/2014:01:15:53 -0700]
13-139-3-149.rackcentre.redstation.net.uk - - [12/Jul/2014:01:15:56 -0700]
d7142.dc.unit-is.com - - [12/Jul/2014:01:20:28 -0700]
192.240.218.214 - - [12/Jul/2014:01:26:14 -0700]

If it makes a difference, you can usually find your Apache version by looking at headers or else in the host information in your control panel for some hosts.

My host does not use the traditional cpanel and does not reveal the Apache version anywhere I have yet been able to discover. If I knew which headers you were referring to, I'd be happy to check.

In short, I should be blocking 163data.com.cn and, in the process (although not what I'd want to do at all), flipping my server from reporting IPs to reporting only hosts, but neither one seems to be happening.

[lucy24]

Important! THIS IS NOT RECOMMENDED

Oh, good, beat me to it. Nothing is worth the aggravation of losing IP info. In fact it doesn't only apply to named hosts; any departure from standard CIDR notation will do. Not long ago I did it by accidentally pasting in a CIDR address with following comma. Took me several days to pin down the problem.

My host does not use the traditional cpanel and does not reveal the Apache version anywhere I have yet been able to discover.

Hm, we may have the same host ;) In fact mine explicitly says they won't tell you what Apache version they're on ("security reasons"), though you should be able to deduce it from any error message you happen to see. However, there's an excellent loophole. I learned this from my host's own wiki.

#1. Create a directory on your site. Don't link it from anywhere. Give it a weird name. (i.e. not "wp-admin" or the like)
#2. Give this directory a file named index.shtml (it can be .html if you've enabled includes, but shtml is guaranteed to work) containing only this line:
<!--#printenv -->
#3. Make an htaccess file for this directory that says:

<IfModule mod_access.c>
SetEnv MOD_mod_access 1
</IfModule>
<IfModule mod_actions.c>
SetEnv MOD_mod_actions 1
</IfModule>
<IfModule mod_alias.c>
SetEnv MOD_mod_alias 1
</IfModule>

et cetera, listing any and all mods you can think of. You can see Apache docs for the mods used in 2.2 and 2.4; include both in the list.
#4. Navigate to this new directory in your browser.
#5. Open the page source using your browser's View Source command.
#6. Copy and paste this source into any text editor.
#7. Quickly delete this new directory before the next passing robot finds it.

#8. If mod_access is listed, you're on 1.3 and should change hosts.

[Iskandrian]

Yes, indeedy, Lucy. And, apropos of nothing at all, last night's celestial display, the first of three such this year, was explosively luminous and delightful to gaze upon as it rose. Tonight should be no different.

To the point. Yes, I had already run the exercise you included above using the default wiki offerings and mod_access was missing. Just now I added mod_authz_host.c, previously not included, and received a positive return. So, good, I am at least definitely on either 2.2 or 2.4 which means, let's face it, the edge of the spoon, 2.2 not 2.4.

This narrows my problem, which may yet remain unsolvable. If I want to avoid mixing hosts under mod_authz_host and risk losing IPs - which I definitely do want to avoid - is there any recourse left to me to block entities which reveal themselves in the IP section such as 163data.com.cn or slaskdatacenter.pl at the domain level? I've tried using HTTP_HOST under mod_rewrite, e.g.

RewriteCond %{HTTP_HOST} 163data\.com\.cn [NC,OR]

but that hasn't seemed to work either, at least not with respect to 163data.com.cn or slaskdatacenter.pl specifically, although mod_rewrite is enabled. For my site's purposes excluding entire domains of this sort will not deprive me of measurably useful traffic.

Control by UA has not proved an option so far either. What might?

[lucy24]

Well, you could take the easy way out and just block China ;) Not by name, by IP. They're easy to look up. Start with the biggest ranges-- /15 and up-- and work downward as your aggravation level increases. They've currently got over 100 lines in my shared htaccess, where each A block is one or two lines. Cursory lookup turns up only seven <16 ranges (17-22) that have annoyed me enough to merit blocking.

Another option is to wander next door to the SSID thread and look for a list of Slask ranges. I've only got 91.188.96.0/19 and 185.24.216.0/22 marked, but there are probably lots more. (Inexplicably, Forums search comes up completely cold. Even tried "Slesk" in case I've been misspelling it all along. But I know they're out there.)

[Iskandrian]

Hmmm...so blocking by CIDR is the only easy way. Oh, well.

Thanks again, Lucy.

[penders]

I've tried using HTTP_HOST under mod_rewrite...

HTTP_HOST is the host being requested, not the resolved host from which the user is visiting.

Just a thought... you could always do this in your app/script? But I guess you are trying to avoid this? To be honest, I always thought domain lookups are slow and best avoided in real time (would need to cache everything at the very least)? Is Apache OK with this?

[Iskandrian]

HTTP_HOST is the host being requested, not the resolved host from which the user is visiting.

Ah, of course then. And mod_authz_host is the resolved host module, which puts me back at square one, right?

Just a thought... you could always do this in your app/script? But I guess you are trying to avoid this? To be honest, I always thought domain lookups are slow and best avoided in real time (would need to cache everything at the very least)? Is Apache OK with this?

I'm running WordPress, so I'm trying to filter guests from the free memory load buffet; after that, to minimize server load itself. But if what you say is true, I'm actually better off blocking CIDRs at the server level than launching domain lookups if I want to minimize server load as well, no?

Is Apache OK with, uh, what, exactly, and how would I find out? As far as I know, everything is running fine. I just keep trying to make it run finer. And thanks for the heads up about HTTP_HOST.

[lucy24]

HTTP_HOST is the host being requested, not the resolved host from which the user is visiting.

Oops, missed that. Iskandrian, you want %{REMOTE_HOST}. (Otherwise known as "the IP"; mod_setenvif also calls it Remote Host, though I don't have the punctuation & capitalization internalized so don't quote me.) And even there, it only works as an IP address.

I always thought domain lookups are slow and best avoided in real time

Same here. I start with the assumption that nothing is less trouble for the server than a raw numerical IP. Well, hey, it's the very first line in the headers. So if you can block by IP alone, do so. And once the server is forced to look up one thing, it for some reason has to look up all things, hence the wonky logs.

There was a recent thread that talked about the really staggering server load placed by WP activity of any kind. It starts with the universal mandatory !-f lookup and from there goes on to ... someone added up the separate database calls resulting from a single page request, and it's a jaw-dropping number. (Well, anything more than two would make my jaw drop.)

[Iskandrian]

Excellent, all. Thanks again.

[penders]

you want %{REMOTE_HOST}. (Otherwise known as "the IP"

I believe REMOTE_HOST should contain the resolved host (not IP) of the client, providing HostnameLookups are enabled on the server. However, this is Off by default and most (shared) hosts will not enable it (performance reasons it would seem). If HostnameLookups is not enabled then REMOTE_HOST returns the IP address (same as REMOTE_ADDR).

However, I don't think HostnameLookups effects mod_authz_host?
Reference: HostnameLookups Directive [httpd.apache.org]

[lucy24]

(same as REMOTE_ADDR)

D'oh! Cancel what I said before. I was of course thinking of REMOTE_ADDR -- the only form I've personally used. Anyway this is all on the the dreaded core.html page. I go there as seldom as I possibly can.

Regardless of the setting, when mod_authz_host is used for controlling access by hostname, a double reverse lookup will be performed. Note that the result of this double-reverse isn't generally available unless you set HostnameLookups Double.

That seems to be saying that mod_authzzzzwhatsit always uses double-reverse lookups, but it doesn't do the rest of the installation any good unless you've explicitly said so.

DNS lookups can take considerable amounts of time

Given the ordinary meaning of "unintended consequences" in Apache docs, you can confidently say that "considerable time" means it adds a week and a half to the ordinary turnaround time.

The utility logresolve

blahblah, sounds useful but also sounds like something you can't make use of in htaccess. Phooey.