We weren’t able to figure out the way to do this, and we’re both wondering if
this isn’t a bug.
If you can say:
<Location />
Require env is_local_client
</Location>
to allow access contingent on the presence of a flag, it should also be
possible to do the inverse: allow access contingent on the absence of a flag:
<Location />
Require not env is_a_bogon
</Location>
Where is_a_bogon gets set via:
LoadModule setenvif_module modules/mod_setenvif.so
BrowserMatch “^$” is_a_bogon
BrowserMatch “^ZmEu$” is_a_bogon
BrowserMatch “^Morfeus “ is_a_bogon
…
<IfModule mod_geopi.c>
SetEnvIf GEOIP_COUNTRY_CODE CN is_a_bogon
SetEnvIf GEOIP_COUNTRY_CODE IR is_a_bogon
SetEnvIf GEOIP_COUNTRY_CODE RU is_a_bogon
SetEnvIf GEOIP_COUNTRY_CODE VN is_a_bogon
…
</IfModule>
etc.
So is_a_bogon only gets set if we’re seeing a User-Agent which is suspect, or
if the traffic is originating from hacker havens.
But this doesn’t seem to be doable in any obvious way.
This looks a bit like BZ 53069.
For what it’s worth, though, I also tried:
<Location />
<RequireAll>
Require all granted
Require not env is_a_bogon
</RequireAll>
</Location>
but that results in:
--b4972c7d-A--
[29/Mar/2017:18:47:29 --0600] WNxVoSGJcKzTWLcEbdzNJgAAAAA 192.168.1.38 50909
192.168.1.3 443
--b4972c7d-B--
GET /downloads/powercodebmu-r3813-964ba7a-x86-xeon-combined-squashfs.img
HTTP/1.1
User-Agent: Wget/1.14 (darwin12.3.0)
Accept: */*
Host: www.redfish-solutions.com
Connection: Keep-Alive
--b4972c7d-F--
HTTP/1.1 403 Forbidden
Content-Length: 276
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
--b4972c7d-E--
--b4972c7d-H--
Apache-Error: [file "mod_authz_core.c"] [line 873] [level 3] AH01630: client
denied by server configuration: %s%s
Stopwatch: 1490834849214254 1971 (- - -)
Stopwatch2: 1490834849214254 1971; combined=850, p1=725, p2=0, p3=1, p4=86,
p5=38, sr=452, sw=0, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.9.0 (http://www.modsecurity.org/);
OWASP_CRS/2.2.8.
Server: Apache/2.4.25 (Fedora) OpenSSL/1.0.2k-fips mod_nss/1.0.12 NSS/3.23
Basic ECC mod_perl/2.0.10 Perl/v5.22.3
Engine-Mode: "ENABLED"
--b4972c7d-Z—
so it’s not clear to me if there’s any way to achieve what I’m trying to do, or
why the solution in BZ 53069 wouldn’t be applicable (by analogy) here.
More broadly on a philosophical level, looking at Comment 3 by Daniel Gruno:
https://bz.apache.org/bugzilla/show_bug.cgi?id=53069#c3
He writes:
“[…] I have made some changes to the access howto to emphasize that a negation
cannot stand on its own.”
Just out of curiosity, why can’t it stand on its own?
I don’t see anything intrinsically wrong about gating on the _absence_ of
_negative factors_.
Can someone please set me straight?
Thanks,
-Philip
> Begin forwarded message:
>
> From: Philip Prindeville <[email protected]>
> Subject: Quick 2.4 question
> Date: March 28, 2017 at 2:32:03 PM MDT
> To: "William A. Rowe Jr." <[email protected]>
>
> Hi William,
>
> Sorry to bother you with a triviality, but I’ve been wracking my brain with
> this one for a couple of hours now.
>
> I had an httpd-2.4 server that’s been humming for years, but recently (like 2
> days ago following a Fedora 24 update) it started balking at ALL requests.
>
> Yes, I had been using Allow/Deny and mod_access_compat… I’ll turn that off
> momentarily.
>
> The culprit (and it took me a long time to find it!) was:
>
> <Location />
> Deny from env=is_a_bogon
> </Location>
>
> which I tried to rewrite as:
>
> <Location />
> Require not env is_a_bogon
> </Location>
>
> but that complains about:
>
> Mar 28 14:04:49 mail httpd[2964]: AH00526: Syntax error on line 81 of
> /etc/httpd/conf.d/mod_setenvif.conf:
> Mar 28 14:04:49 mail httpd[2964]: negative Require directive has no effect in
> <RequireAny> directive
>
> I’ve also tried:
>
> Require env !is_a_bogon
>
> but that gets me a syntax error.
>
> I looked at the 2.4 mod_setenvif pages but unfortunately it doesn’t go into a
> lot of detail of how to tie the tests together in with the actual Require
> directives.
>
> Can you set me straight here?
>
> Thanks,
>
> -Philip
>
