Unfortunately, mod_authzthingy doesn't work as a toggle: "Deny all of A, but allow A.B, except don't allow A.B.C. unless it is specifically A.B.C.D.” In the vast majority of cases, Allow/Deny has one of two patterns:
Allow from all
Deny from {bad ranges here}
OR
Deny from all
Allow from {good ranges here}
but it's important to understand that, unlike many apache mods, the individual rules aren't handled in sequential order, one by one as you meet them. Instead, the “Order” directive means to read all the Allow lines first, and then read all the Deny lines--or, of course, vice versa. If any given request meets a condition on
both sides (like, by definition, "All" and then some exact number) or on
neither side (usually only if you don't have an "all" line) the second element applies.
In 2.4 you have more options
:: pause to direct dirty look hostwards ::
but, yeah, narrower allowing-and-denying has to be done in mod_setenvif. I've done a little bit of this myself:
SetEnvIf Remote_Addr ^52 bad_range
SetEnvIf Remote_Addr ^52\.5[56] !bad_range
SetEnvIf Remote_Addr ^52\.162 !bad_range
but also BrowserMatch nice-robot-name !bad_range
winding up with
Deny from env=bad_range
Edit: my SetEnvIf statements are before my "deny from" statements
Well, they'd have to be, otherwise you wouldn't be able to use mod_authwhatsit with environmental variables. (“Deny from env=blahblah”). Strictly speaking it isn't that they are “before” or “after”, but that mod_setenvif executes before mod_auththingummy. (“Reverse alphabetical order” is a good rough-and-ready rule, with exceptions that are out of your control.)
Recently, while experimenting, I was reminded that you can set an environmental variable in a subsidiary directory--or in a single site within a multi-site userspace--and it will still result in a lockout. This can be useful if you want to set or unset additional access-control criteria for only selected parts of your site.
Each module's 403s are independent; module A can't override a lockout issued by module B.
