Forum Moderators: phranque
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]
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.
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