.htaccess to ban an IP range

Expression for 3rd Octet

[Wighty]

I have read several of the Webmaster World topics on the subject of banning IP ranges (domains, etc.), and I am trying to adapt one particular version of these methods that I find quite elegant. However, I feel my expression is somehow not quite correct - did I mention I'm somewhat new to UNIX expressions...?

This is the .htaccess reference code:
# block inhoster
SetEnvIf Remote_Addr "^(85.255.1(1[2-9]¦2[0-7])).[0-9]{1,3}$" block
deny from env=block

This is the IP range I wish to block 62.194.0.0 - 62.194.255.255

This is the expression I want to subsitute in the above code, however, I'm having trouble with the expression for the 3rd octet (NNN): "^(62.194.NNN.[0-9]{1,3}$"

Would someone help with that part of the expression...?

Thank you, Mike

[spinnercee]

deny from 62.194.

will do it.

[jdMorgan]

The expression would be the same as for the final octet, since both range from 0-255. (Note that the pattern you've shown actually matches 0-999, but that's OK, since no octet can be transmitted with a value greater than 255 {2^8 - 1} anyway.)

However, there's no need to specify a pattern for those octets at all, since both the third and fourth octet values are "don't care." Just omit them and the end-anchor:

SetEnvIf Remote_Addr "^62\.194\." block

That will bock any IP starting with "62.194." and ending with any values in the third and fourth octets.

Jim

[Wighty]

Thank you both for the prompt replies. Unfortunately in my haste I noted the wrong IP range. It should have been shown as:

...I wish to block 62.194.0.0 - 62.194.83.255

If it were as I first listed it, I knew there were easier ways (as noted in your replies). Sorry...

[jdMorgan]

Haste makes waste...

62.194.0.x - 62.194.83.x :

^62\.194\.([1-7]?[0-9]¦8[0-3])\.

Replace the broken pipe "¦" character with a solid pipe character before use; Posting on this forum modifies the pipe characters.

Jim

[spinnercee]

It's still pretty simple -- you're over-complicating things.

You want to block 62.194.[0..83].* The last octet is implicitly [0..255] so you and Apache don't really care what it is.

So just pay attention to the third octet and Apache will take care of the rest -- it reads left to right just like you do.

[Wighty]

Again, thank you. I appreciate both approaches - I've learned something from each... ;)

[Wighty]

Follow-up queston:
Having added the blocked IPA ranges to the .htacccess file, I've found a number of entries in the error log that are simliar to this one:
[Thu Oct 12 15:20:56 2006] [alert] [client 71.226.208.224] /home/cityofbr/public_html/.htaccess: Invalid command 'SetEnvlf', perhaps mis-spelled or defined by a module not included in the server configuration

The odd thing (IMHO) is that all the IPAs listed are NOT in the range of those that I blocked...?

What's happening here...?

For reference, this is what I added to the .htaccess file:

# Block Chello (Amsterdam)
SetEnvIf Remote_Addr "^62.194.[0..83].*$" block
SetEnvIf Remote_Addr "^24.132.226.*$" block
deny from env=block

[SteveWh]

I have to admit I'm not familiar with the method you're using (the SetEnvIf command). So I'm just posting this in case this other method turns out to be easier in practice. I just use a single deny from line in .htaccess:

deny from nnn.nnn.nnn.nnn

(In order to use this method, it is possible you might have to rearrange some of the other allow,deny lines in your .htaccess.)

I find this site very helpful for calculating the netmasks to use: <admin note: url removed - link rot>

Although the CIDR method looks more complicated than others, once I read the description I actually find it much easier to understand and use than the others if the net/host boundary doesn't break exactly on an octet boundary.

I notice that the range in your third octet of 0-83 isn't really a valid range. It's either not contiguous or it's not complete. The net part of the netmask has to be a contiguous set of bits reading from the left.

To ban the IP address range you gave of 62.194.0.0-62.194.83.255, the line I would use (using CIDR netmask) is

deny from 62.194.0.0/17

This will actually deny 62.194.0.1 to 62.194.127.254. Notice the 127 instead of the 83. That will ban the 0-83 you want, plus a bit more. The alternative of

deny from 62.194.0.0/18

would only ban 62.194.0.1 to 62.194.63.254. Note the 63; that's not quite enough for your purpose. That's why I say the range in the third octet seems odd.

I looked up the address range you gave, and it does show in WhoIs just the way you say it does. However, this is the first time I've seen an IP address with this strange characteristic of not being able to be cleanly represented with a CIDR netmask. Can't explain it; just thought I'd mention it.

[edited by: tedster at 8:39 pm (utc) on April 6, 2008]

[Wighty]

Steve,
Thanks for the link. I believe you are correct that the range in the third octet of 0-83 isn't really a valid range as I found this address having accessed my website today: 62.194.13.19
So it would appear that the [0..83] expression is not working.

I believe I'll try the netmask method in a regular deny from statement. I may also try JP's expression for that IP range just to see how that works. ;)

[edited by: tedster at 8:40 pm (utc) on April 6, 2008]
[edit reason] link rot fix [/edit]

[spinnercee]

I should have mentioned:

62.194.[0..83].* is pseudocode, and not the correct syntax for a SetEnv or deny. The regex posted above by jdMorgan is the correct way to express it.

I was trying to make it simple to read. LOL

[jdMorgan]

SteveWh,

> However, this is the first time I've seen an IP address with this strange characteristic of not being able to be cleanly represented with a CIDR netmask. Can't explain it; just thought I'd mention it.

You were on the right track above starting with the smaller /18 range:

First block /18 starting at 0: 0-63 (64 class C addresses)
then block /20 starting from there: 64-79 (16 class C addresses)
then block /22 starting from there: 80-83 (4 class C addresses)

Note how all of the sizes of the "chunks" that make up the entire range are powers of 2.

So the whole mess would be:

Deny from 62.194.0.0/18
Deny from 62.194.64.0/20
Deny from 62.194.80.0/22

And that covers the desired 0-83 range precisely.

Wighty,

If using the correct regex pattern I posted above does not fix your SetEnvIf errors, then look at your server error log to see if the error message is still the same. If so, it's telling you that mod_setenvif is not loaded on your server, and so none of that module's directives will be available to you.

Jim

[Wighty]

Thanks for the feedback on that [0..83] issue - I did note that I was new to UNIX expressions ;)

JP -
Your information is very helpful, and I'll try your expression. After rereading the error log, it seems somehow I typed SetEnvlf instead of SetEnvIF (noted the "l" vs. "I") - I swear It typed it correctly, but the log says differently...

I'm beginning to get a clearer understanding of how to breakdown an IPA range (the docs referenced in Steve's link helped considerably)

Thank you all!

[Wighty]

JP -
What key combination produces the solid pipe caharter? Looking on my keyboard I see the broken pipe Shift \ key (above the ENTER key).

[jdMorgan]

Have you tried hitting that combination? In most cases, that produces a solid pipe on-screen, despite the marking on the key.

Jim

[Wighty]

No, but I'll try it. The only reason I didn't do that intially was that I inferred from your comment that there might be another key combination...

[SteveWh]

jdMorgan,

Thank you for the "3-range" solution. It will be useful, and I didn't realize it was permissible.

Wighty,

If mod_setenvif is not available to you, it would make sense that the plain "deny from" lines should still work. They rely on mod_access, which I can't imagine a server being without: [httpd.apache.org...]

[jdMorgan]

Yeah, the problem was that setenvLf isn't available on *any* Apache server... :) -- See post above.

(I didn't spot that mispell, either, but then, my eyes are pretty much shot from 30 years of staring at code...)

Jim