Forum Moderators: phranque
I'm using the following mod_access directive in conjunction with the bad-bot script from this site (can't recall the post offhand, but it's the one discussed at great length and writes the banned IP to .htaccess)...
<Files *>
order deny,allow
deny from env=getout
allow from env=allowsome
</Files>
The script writes the baned IP to htaccess in this format:
SetEnvIf Remote_Addr ^12\.34\.567\.89$ getout
I've been trying to convert many of the entries into ranges. This format seems to work:
SetEnvIf Remote_Addr ^12\.34\.56\.* getout
However, I want to be able to ban by CIDR range. I THOUGHT I was doing it correctly by doing this:
SetEnvIf Remote_Addr ^12\.34\.\56\.0\/15 getout
...But it's not working. Using a proxy, I was able to test an IP within a banned CIDR range and was granted access.
I've read dozens of tutorials and have attempted to follow examples - I'm just so confused now that I can't seem to spot what I'm doing wrong. I realize it must be something simple - I'm just not getting it.
I'm grateful for any guidance or pointers.
Busynut
You can hard-code your CIDR ranges and netmasks directly into additional "Deny from" directives instead:
Order Deny,Allow
Deny from env=getout
Deny from 12.34.0.0/15
Deny from 12.34.0.0/255.255.80.0
Allow from env=allowsome
Where would I have found the explanation that would have informed me of that in the first place? (meaning "SetEnvIf doesn't recognize the "special" netmask or CIDR notation formats")
Am I overlooking obvious information somewhere? There are oodles of 'tutorials' out there, but few are written in plain old English, and many 'beginner' level tutorials are just pathetic - they seem to be targeted for people to just copy & paste their code rather than comprehend what it does. Am I denser than most? (a likely scenario I must confess!).
Again, thank you. Pointers for searching out truly helpful answers would still be most welcome! (I've read and re-read so many docs at [httpd.apache.org...] - and I'm not finding the info that helpful).
If they're not documented, then they're not likely to work.
The Allow and Deny directives 'know' that these are IP addresses, and have handlers to recognize and process the four listed formats. SetEnvIf, on the other hand, only handles regular expressions and string compares; It ascribes no 'meaning' to the contents of the server variables that it can test. They are treated only as text strings. So, SetEnvIf is not 'programmed' to recognize 12.34.0.0/15 as anything except a string composed of those literal characters. And since you'll never receive a request from a client IP address formatted like that --it's invalid as an IP address-- SetEnvIf won't ever match it.
Please don't confuse Apache configuration directives with those in a sophisticated, consistent programming language like 'C' or scripting languages like PERL or PHP. Apache is a very small, simple program intended to accept HTTP requests, translate those requests to filesystem requests, submit those requests to the operating system, and then send the resulting file contents back to the requesting client using HTTP. So, it's a dirt-simple program compared to, say, MS Word, and its directives are not consistent or symmetrical or complete. Each module was written --usually by a different author-- to solve a particular problem or set of problems, and only to solve that problem or those problems. So, while Apache may appear to be an inconsistent mess, it's a very small, very fast, and very useful mess. :) (Actually, Apache itself is fairly clean, it's just all those modules --Apache's 'plug-ins,' if you like-- that are inconsistent.)
Anyway, the bottom line is that you can't use anything that is not specifically documented and expect it to work. In this respect, the Apache documentation is quite adequate, in that it contains a description of everything that will work.
Jim
ahaaa... my expectations of the documentation have been unreasonable. And I hadn't considered the inconsistency of the modules... thank you for setting me straight. Your explanation will go a long way toward helping me to 'read' the documentation for exactly what it is. I'm not saying I'll understand it any easier - but I'm less likely to make as many mistaken assumptions.