Forum Moderators: phranque

Message Too Old, No Replies

deny code and switches

understanding deny code and its switches

         

desjardins

6:17 pm on Jan 9, 2010 (gmt 0)

10+ Year Member



I have set access rules using the deny command. My command box looks something like this:

allow all
deny 90.xyz.xyz.xyz
deny 84.xyz.0./016
deny 84.xyz.0./024

I am confused on three issues.

1. what does the 0./016 and 0./024 switch do?
2. Why can someone with an ip on my deny list still enter my website?
3. How can I tell if someone is using a proxy server?

I went to Module mod_access and found some info but I am still learning and am confused.

thank you for any help.

[edited by: jdMorgan at 8:07 pm (utc) on Jan. 9, 2010]
[edit reason] cleaned up three-x obfuscation. [/edit]

desjardins

7:18 pm on Jan 9, 2010 (gmt 0)

10+ Year Member



just another note. I tried
deny from 90.*.*.*** and get an error.

someone with an ip the exact same as one that was on my deny list was able to enter my website. I am confused.

wilderness

8:32 pm on Jan 9, 2010 (gmt 0)

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



1) denying access to visitors does not prevent the denied lines from appearing in your visitor logs, rather the request appears with a "403 status".

2) the switches are a broader range of IP's (subnet) below IP range specified.
a) there are "CIDR Calculators" (tools) on some web pages,
which convert or determine these ranges.

3) regarding your follow up mail, you may not use wildcards in these ranges, nor do acutal websites "raw logs" provide IP ranges in this manner, nor may the visitor obscure the IP in a similar manner. The most likely scenario is that your server has some kind of script in place which generated the range in ERROR.

jdMorgan

8:34 pm on Jan 9, 2010 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



1) These are not switches, they are contiguous-mask-bit count specifiers.
They specify the number of ones, counting from the most-significant bit of the 64-bit IP address, to be used to mask the requesting IP address and the specified 'test' value against which it is to be compared.

The basic idea of all three forms of mod_alias address specifiers is that they all allow you to say, "I care about the values of these bits in the IP address, but I don't care about the values of any of these other bits." Therefore, you can block IP address ranges of varying sizes by specifying a base address, and then declaring which bits will and won't change within the range of the addresses that you want to Deny (or Allow).

Deny one IP address, exactly 192.168.0.1
Deny from 192.168.0.1
Deny from 192.168.0.1/255.255.255.255
Deny from 192.168.0.1/32
(These three lines are all equivalent)

Deny eight IP addresses, starting at 10.99.75.16:
Deny from 10.99.75.16/255.255.255.247
Deny from 10.99.75.16/29

Deny 65,536 IP addresses, starting at 192.168.0.0
Deny from 192.168
Deny from 192.168.0.0/255.255.0.0
Deny from 192.168.0.0/16

Note that the 'base' address cannot range freely. It must be a multiple of the size of the specified range in order for this system to work.

There's really no simple way to explain this, since this involves first translating the four-octet decimal IP address and comparison value into 64-bit binary numbers, applying the mask to both, and then testing for equality. Once you understand quad-decimal-octet to binary translation and the reverse, then this becomes a lot easier to understand, so focus your efforts there first.

2) They can't unless your code is wrong or is being overridden by other code in the configuration. The most obvious question here is, "What Order directive did you specify ahead of your Allow and Deny directives, and why?"

3) You can't always tell. The ones that declare themselves through the use of the "Via" and "X-Forwarded-For" HTTP request headers aren't usually the ones that are the problem -- It's the anonymous proxies that are the problem, and you can really only find out about them by watching the lists published on security Web sites and other sites that detect and keep track of (some of) them.

Most of the time, it's easier to detect other kinds of problems with the requests that are typical of non-browser user-agents or of people using real browsers but trying to hide their activities. You can look for invalid User-Agent strings, HTTP request headers that are inconsistent with the claimed user-agent, bogus referrers -- such as self-referring URLs or Referrers that have invalid formats, and all kinds of other things. But detecting anonymous proxies isn't something that's easy, and most folks don't really try to do it directly.

Jim

desjardins

8:50 pm on Jan 9, 2010 (gmt 0)

10+ Year Member



Thank you for your replies.

Jim,

so if I have the following:

Allow all
Deny 192.168.57.215

this person should not be able to gain access correct?

desjardins

9:07 pm on Jan 9, 2010 (gmt 0)

10+ Year Member



when I use the word from I get an error.

So I have it as follows

Allow all
Deny 192.168.57.215

will this work?

wilderness

10:33 pm on Jan 9, 2010 (gmt 0)

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



when I use the word from I get an error.

Than you have others issues that require resolution.

"deny from" (followed by IP range) is the proper syntax.

jdMorgan

3:37 pm on Jan 10, 2010 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



What Order directive did you place ahead of your allow and deny directives?

What is the specific error shown in your server error log file?

Jim