IP Range Block may not be working?

Blocking IP Ranges with Limit

[EastTexas]

IP Range Block may not be working?


Bad guy got through 91.196.51.21

<Limit GET POST PUT>
order allow,deny
allow from all

deny from 91.0.0.0/91.205.99.255 91.205.104.0/91.209.5.255
deny from 91.209.7.0/91.209.56.255 91.209.58.0/91.225.247.255
deny from 91.225.252.0/91.255.255.255 91.228.

</Limit>

NOTE: I did add 91.196. to the list just to be on the safe side.

[lammert]

Apache's mod_access has two different ways to express an IP range. If you want to block 91.196.0.0 to 91.196.255.255 for example, you can use either of these two notations:

91.196.0.0/16
91.196.0.0/255.255.0.0

You read them both as: The IP of an incoming client should be compared with 91.196.0.0 where the first 16 bits are significant.

If you write 91.0.0.0/91.205.99.255, then you can rewrite this in binary notation as:

91.0.0.0/01011011.11001101.01100011.11111111

The bits of the second part give an indication which bits of the incoming IP will be used in a match with 91.0.0.0 to see if the IP should be denied or not. I am quite sure that is not what you want to do.

As a side note, the 91.x.x.x range is assigned in Europe to many organizations in many countries. Although I don't know what the target countries of your website are, you might block legitimate traffic by blocking such a broad range in your .htaccess.

[lucy24]

you can use either of these two notations

Or, most simply, just 91.196

Why bother with a <Limit> envelope at all? Are there request methods you don't want to block? Seems like, if so, whitelisting would be safer:

<Limit HEAD>
Order Allow,Deny
Allow from all
</Limit>

Apache docs recommend LimitExcept for access control, precisely so nobody sneaks in with a hitherto unknown method. Exact format depends on your individual situation.

[EastTexas]

Blocking all none USA traffic.

These are the main problem makers .cn, .nl, .ru, .ua

This will block a lot of .cn
deny from 180.

[wilderness]

Apache's mod_access has two different ways to express an IP range. If you want to block 91.196.0.0 to 91.196.255.255 for example, you can use either of these two notations:

91.196.0.0/16
91.196.0.0/255.255.0.0

Why make this unnecessarily complicated?
Per lucy's 91.196

My sites and their widgets are quite different than most websmasters.
RewriteCond %{REMOTE_ADDR} ^9[01245]\. [OR]

(could even include the 93-8, however I've one Class C exception for an acquaintance.
Otherwise:
RewriteCond %{REMOTE_ADDR} ^9[0-5]\. [OR]

[lammert]

Why make this unnecessarily complicated?
Per lucy's 91.196

EastTexas already mentioned in his post that they had added 91.196. But the main problem they posted was that they suspected the current IP block not working properly. As you might have noticed, the OP was posting 91.0.0.0/91.205.99.255 and more of this type of network blocks which are--although correct syntax--probably not what they wanted to do.

For the purpose of education I have explained what the notation xx.xx.xx.xx/yy.yy.yy.yy means and that in the notation in OP's message, it doesn't block one continuous IP range, but shoots a large number of small holes in the whole IP range between 0.0.0.0 and 255.255.255.255.

[wilderness]

lammert,
It's my understanding that such uses of CIDR-variance are only possible with Apache 2.4, and I've yet to see anybody provide that 2.4 has been implemented?

It mod-rewrite, it's long been (through most every version of Apache) entirely possible specify very small blocks (even multiple small blocks across a variety of Class-ranges) of ranges, although most people find the syntax too complicated.
EX:
RewriteCond %{REMOTE_ADDR} ^199\.74\.(6[4-9]|[789][0-9]|1[01][0-9]|12[0-7])\. [OR]

[lammert]

It's my understanding that such uses of CIDR-variance are only possible with Apache 2.4

CIDR compliance is available in Apache 2.0 according to the documentation of the Allow directive [httpd.apache.org] and was even already implemented in Apache version 1.3, according to O'Reilly's "Apache, The Definitive Guide", second edition chapter 5.6.1 printed in 1999.

Theoretically using CIDR notation in the pre-compiled httpd.conf should be much faster than regular expressions because it can be implemented as simple bitwise AND and OR operations.

[lucy24]

Incidentally...

Apache's mod_access

It was called mod_access only through Apache 2.0. In 2.2 and 2.4 the job is farmed out to assorted mod_auth-thingummy. But the "Allow" and "Deny" syntax is still essentially the same.

Theoretically using CIDR notation in the pre-compiled httpd.conf should be much faster than regular expressions because it can be implemented as simple bitwise AND and OR operations.

Almost anything is faster than mod_rewrite in .htaccess, but wilderness likes using RewriteRules so we may as well show alternative ways of doing the same thing ;) Regular Expressions in the config file are not so bad, because they're only compiled once, at server startup. But it's hard to imagine anything being faster than "91.196" since that would be the first few characters of the first line of a request header.

This will block a lot of .cn
deny from 180.

It will also block pieces of Japan, Korea, Malaysia, India ... Australia and New Zealand ... and so on. A-level ranges are not allocated to countries, except where the whole range is assigned to a single corporation or governmental entity.

If you want to get a rough idea of what's what without spending any money, here's one source:
[countryipblocks.net...]
There are plenty of others. As a general rule of thumb: If a particular range comes up in very small (< /24) slivers, it will almost certainly turn out to be servers, colo or similar.