Forum Moderators: open
I am getting scanned by a lot of Korean persons and spiders, falling within the IP block of 211.104.0.0-211.119.255.255. I have congered up what I hope is the correct syntax for a RewriteCond based on Remote_Addr. Here is what I have:
RewriteCond %{REMOTE_ADDR} ^211\.(1[0-1][4-9]\.[0-2][0-5][0-5]\.[0-2][0-5][0-5])$ [OR]
# other conditions follow, then death
Is this correct for blocking the desired range?
If I just want to use a deny from line, inside a <LIMIT GET POST> section, what is the numeric trailing-slash number to append to 211.104.0.0/? to block the rest of those addresses? Seems like a shorter route, character-wise. A link to a sliderule-like IP range converter would be nice.
Wiz
The <Limit> statement is often misunderstood. The above example will put limits on GET and POST (and HEAD, because of GET), but absolutely no limits whatsoever on PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, or UNLOCK.
Normal access restrictions are valid for all methods, and because of this, the <Limit> method is generally NOT intended for access restriction. In stead, it is used in the case of exceptions to other rules - that is, to reduce the effect of other restrictions.
If you want to deny all requests from "127.0.0.0" you could do one of these two:
(A)
<Limit GET POST PUT DELETE CONNECT OPTIONS TRACE PATCH PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK>
Deny from 127.0.0.0
</Limit> (B)
Deny from 127.0.0.0 Clearly, option (B) is shorter and it is also the proper one to use. Even if one method is not stated in Example (A), it will still get caught in Example (B).
/claus
Here's a subnet mask calculator: [telusplanet.net...]
Wilderness, I am glad to see that leaving off a decimal group includes all of it. I was hoping for a shorter expression and got it, thanks to you.
From Claus:
The <Limit> statement is often misunderstood. The above example will put limits on GET and POST (and HEAD, because of GET), but absolutely no limits whatsoever on PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, or UNLOCK.
I already have this code at the end of my .htaccess, courtesy of one of the members of WebmasterWorld (I think JB):
<Files *>
<LimitExcept GET POST>
deny from all
</LimitExcept>
</Files>
May I ask a couple of followup questions?
(B)
Deny from 127.0.0.0
deny from (IP) seems to be free-standing; not inside a limit or files tag-set. Do I understand correctly that if I want to absolutely ban every contact method in the 218.x.x.x IP block that I can simply have a freestanding deny from 218. on a line all alone, with no <files> or <limit> around it? 2: Related to the above, I read a message where the poster has lots of IP addresses and even domain names in a space-separated group, all within a single <files *> deny from xxx.xxx.xxx.xxx yyy.yyy.yyy. etc etc</files> tag-set. It only has one deny from statement at the beginning, and all addresses are on space-separated lines. Is this correct syntax? It sure saves a lot of space if you have a lot of addresses to control.
Claus, thanks for the link to the calculator.
Wiz
2) In reagrds to condensing the number of lines? It's really not necessary. At one point I had 1500 lines of htaccess and it never slowed my sites down a bit. Condensing will make things more diffcult to grasp, especially when your starting out.
Don
That one made me look through my Apache-book and the online documentation for more than an hour. First, <LimitExcept> is the exact opposite of the <Limit> directive, no problem there - it will block all methods that are not GET, HEAD or POST. So far so good.
It will only block these methods when applied to files though, as you've put it inside a <Files> tag. All things that are not files will still be exposed to the other methods - that was the difficult thing that took an hour, because; what exactly is not a file and can hence be exposed to another method?
I haven't found the answer yet, i admit, but i did some tests and i was not able to make a request that was not for a file (i only used a browser though, and the setup of my test-site is not very advanced in terms of server configuration, i like to keep it simple). Remove the <Files></Files> if you don't want to take chances, otherwise just leave them there.
>> followup questions?
Wilderness has answered already i see - i can only add that the space-separated list is perfectly valid, and agree that the other method is easier to read.
You can also use * (meaning: any sequence of characters) or [], eg in 127.[1-5]00.0.0 (meaning: numbers from 127.100.0.0 to 127.500.0.0).
/claus
Claus, I guess a directory is not a file. I have this rule to protect directories from contents browsing:
DirectoryIndex index.html index.htm index.shtml index.php /noread.html. So far it has even kept me from browsing my folders from the web, without knowing a filename to GET. I guess I can leave things as they are for now, with the <files *> tag-set. If it turns out that I need to further protect folders I can just drop the <files> tags as you suggested.
I am trying to keep my blockades close to the offending IP address ranges, but as time goes on I seem to be taking in more IP ranges than less. Right now I don't have any business at all outside of the US and Canada. I might conceivably do some consulting in other English speaking countries (GB, Aus, NZ) and have one contact in Germany, but none with any Orientals or India. I am getting to the point where I don't care if I blockade all of the APNIC IP blocks, with the exception of Australia and New Zealand. If I can find the Aussie and NZ IP ranges I will poke a hole in my planned block rules to allow them.
Thanks again, Wiz Feinberg
PS: The Owl book is giving me headaches, but I am getting a handle on it. Evertime a Forumite corrects or confirms one of my attempts I get a better understanding of the whole concept of RegExps.
You won't have to change that at all. The "container" serves to limit the scope of the mod_access directives, either to request methods with <Limit> or to certain filetypes with <Files>, etc.
I'd suggest going straight to the source [httpd.apache.org] for concise information, and then digging into third-party books when something is unclear.
Jim