Forum Moderators: open

Message Too Old, No Replies

Am I Blocking This OVH IP Correctly?

         

RedBar

9:12 am on Aug 3, 2020 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



I don't recall having this issue before however what am I doing wrong or is OVH / my server ignoring it?

From the OVH list here I included the OVH IP ranges:

[webmasterworld.com...]

One of them is given as:

198.27.64.0 - 198.27.127.255

I included it as

deny from 198.27.64.0 - 198.27.127.255

Yesterday I had one site hit by OVH using:

198.27.124.70

Have I done something wrong or is is this a "one-off" fluke?

Thanks

not2easy

1:24 pm on Aug 3, 2020 (gmt 0)

WebmasterWorld Administrator 10+ Year Member Top Contributors Of The Month



Those "98.27.64.0 - 198.27.127.255" numbers are the "range" - from the first IP to the last that are included in the CIDR "198.27.64.0/18". I understand that there are methods that use the range, the deny from should be using the CIDR and the range is listed with that so that people using that CIDR to deny know exactly the range that is being blocked.

You might want to read some older posts where it includes more information on blocking because just a list of "deny from" environments without instruction of a <files envelope is not the way it works. Try some searches here for 'allow, deny' and 'deny, allow' for example. Apache and its configuration allow for variations but it does require patterns. ;)

lucy24

4:05 pm on Aug 3, 2020 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



deny from 198.27.64.0 - 198.27.127.255
I am surprised this did not throw your entire server into Lookups mode. (In 2.4 it would probably lead to a 500 error.) You want
Deny from 198.27.64.0/18
which will eventually become
Require ip 198.27.64.0/18

RedBar

4:27 pm on Aug 3, 2020 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



@lucy24

Thanks however you've lost me! We've been doing it this way since the 90s with no problems insofar as I am aware and if there were any issues I'm sure my current host, who I know has seen this htaccess file, would have said something.
Deny from 198.27.64.0/18

Educate me please, why?

not2easy

5:09 pm on Aug 3, 2020 (gmt 0)

WebmasterWorld Administrator 10+ Year Member Top Contributors Of The Month



As I mentioned, there are other methods than those generally listed in discussions here. As mentioned by lucy24 I am surprised that you did not see errors, your entry would definitely have borked my sites. As mentioned in your most recent post your host uses a different method. I would ask your host about the best format that is used for the task since it does not appear to be typical.

Keep in mind that Apache version and the settings in httpd.conf can introduce variations. If your hosting is not what the average user here is concerned with, it would help if we have the general environment described to get useful responses. Apache is not a fixed unit that is the same for all users. What works fine for me may not be the correct answer for your case.
Educate me please, why?
Deny from 198.27.64.0/18 has been the most common method used on Apache servers when they are not private servers, when access is managed in .htaccess and CIDR is the 'efficient' way to block all IPs in a given range.
CIDR is the short for Classless Inter-Domain Routing, an IP addressing scheme that replaces the older system based on classes A, B, and C. A single IP address can be used to designate many unique IP addresses with CIDR.
-- from https://www.ipaddressguide.com/cidr which is an online calculator I use for such tasks.

lucy24

8:07 pm on Aug 3, 2020 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



your entry would definitely have borked my sites
This seems to have been a change between 2.2 and 2.4. In 2.2, if you had anything in an Allow/Deny line that couldn't be read as a CIDR, the entire site went into lookups mode: for example
Deny from 10.25, 10.52
with spurious comma means the site tries to see whether “10.25,” matches anybody’s name, and does the same for all other requests. It’s visible in logs because the lines no longer start with 10.25.42.abc and so on.

In 2.4--including mod_compat_whatsit (I forget its exact name) for legacy Allow/Deny directives--the same type of blunder takes you straight to a 500 error. No prizes for guessing how I know this :( (And ... that’s why every time I do anything whatsoever to htaccess, even things that couldn’t possibly make any difference, I immediately follow it up by grabbing some random page to make sure there’s no nasty 500.)

JamesSC

12:22 am on Aug 4, 2020 (gmt 0)

5+ Year Member Top Contributors Of The Month



Lucy24, could you clarify? I'm currently on Apache 2.4 using 2.2 Allow/Deny directives which are being accommodated by mod_compat.

Although for the most part I'm using CIDRs and not the IP ranges RedBar is using, in some places I am using truncated IPs as ranges in the manner of 123.45 without consequence.

I do, though, most assiduously check that my periods are not commas or anything else in the manner you prescribe. In fact, if I sneeze, I check, just to be sure

lucy24

1:59 am on Aug 4, 2020 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



You mean you said
deny from 198.27.64.0 - 198.27.127.255
and nothing broke? I’m stumped. Maybe it interprets the hyphen in some weird way. If so, you’re blocking only the exact IP 196.27.64.0, which will not melt your server but is certainly not what you want.

Truncated ranges, like 198.27 if you mean the entire /16, remain fine in 2.4.

What do some of your other Deny lines look like?

Incidentally, I suspect this whole discussion would get better attention in the Apache subforum, since we’re talking about syntax specific to one server type. (not2easy? got an opinion?)

not2easy

3:33 am on Aug 4, 2020 (gmt 0)

WebmasterWorld Administrator 10+ Year Member Top Contributors Of The Month



While I may agree that it has turned from "what to block" to more like "how to deal with Apache", I'd personally prefer to see a new thread on that topic there - or maybe report it and see if phranque can help. My ISP is not behaving (playing peek-a-boo with the internet for a week already) and I might make matters worse trying to split it. I'm afraid I can't do that.

JamesSC

6:21 am on Aug 4, 2020 (gmt 0)

5+ Year Member Top Contributors Of The Month



You mean you said

Truncated ranges, like 198.27


Yes, exactly, that's what I meant

if you mean the entire /16, remain fine in 2.4.


which is what I was trying to clarify, whether you meant simply the comma, or the truncation itself as well.

RedBar

1:00 pm on Aug 4, 2020 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



So, you people had me concerned therefore I contacted my ISP who, incidentally, has been one of the UK's top-voted ISPs since the noughties. I showed him the coding I was using, told him of the comments here and received this almost immediate response:

That looks fine.

PS: You can't bork a server in the way we have ours setup.

I don't know anywhere near enough to comment when he's okayed it.

not2easy

1:28 pm on Aug 4, 2020 (gmt 0)

WebmasterWorld Administrator 10+ Year Member Top Contributors Of The Month



Your .htaccess file has nothing to do with your ISP unless they are hosting your site(s).

RedBar

4:15 pm on Aug 4, 2020 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Ah, ok my ISP is also my webhosting provider, is that clearer?

lucy24

4:49 pm on Aug 4, 2020 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Heh. I'd actually forgotten that the same entity can do both. When I first had cable internet, it came with some modest amount of web space, but I don't think you could use your own domain name; it was something like example.isp/users/yourname/ And before that, there was members.aol.com/

You can't bork a server in the way we have ours setup.
No matter how a server is configured: if it supports htaccess it is always possible to do something that results in a 500 error. Not for the entire server, just for the directory subject to the htaccess file. In fact if you’re very clever* you can write code that results in a 500 error only on those requests that the code applies to; I achieved this once on a RewriteRule.


* I mean, of course, “clever” in the same way that a clever child can break the library’s computers in ways that they have been explicitly configured not to allow.

not2easy

6:57 pm on Aug 4, 2020 (gmt 0)

WebmasterWorld Administrator 10+ Year Member Top Contributors Of The Month



Thank you for clearing that up RedBar, then it makes sense. I did not think you were mistaken or confused, but for some readers it might be confusing.

wilderness

10:57 am on Aug 5, 2020 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



RedBar,
Over 20- years I've had multiple hosts.
As a general rule, few hosts have understanding of htaccess, which is surprising.
The ones that do have experience, generally have very limited experience.

RedBar

1:20 pm on Aug 5, 2020 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



As a general rule, few hosts have understanding of htaccess, which is surprising.

I've had several hosts over the years and I agree some didn't have a clue however my current hosts, probably 10+ years now, have been extremely good and more than once have saved my bacon when I didn't understand something, they actually walked me through it step by step.

I say "they", actually the company is still run from the top by the boss and is very hands-on.

Needless to say, they are not a household name!

lucy24

5:22 pm on Aug 5, 2020 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



As a general rule, few hosts have understanding of htaccess, which is surprising.
If you want to be really nasty, consider how many RewriteRules in the Apache documentation involve the pattern
.*blahblah