I’ve not heard back so I’m going to go ahead and file a bug as a placekeeper.

-Philip


> On Mar 29, 2017, at 7:04 PM, Philip Prindeville 
> <[email protected]> wrote:
> 
> 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
>> 
> 

Reply via email to