| 11:33 pm on Apr 11, 2014 (gmt 0)|
denying to the precise Class D IP is a very bad practice.
188.8.131.52 - 184.108.40.206
deny from 220.127.116.11
18.104.22.168 - 22.214.171.124
see the Server Farm threads in the SSID forum for explantions on colo's.
| 11:47 pm on Apr 11, 2014 (gmt 0)|
|order allow,deny |
allow from all
I'm not an expert, but shouldn't this be "order deny,allow" to work the way th OP wants?
| 12:47 am on Apr 12, 2014 (gmt 0)|
|shouldn't this be "order deny,allow" to work the way th OP wants? |
"Deny,Allow" is whitelisting; "Allow,Deny" is blacklisting.
Both mean: if a given request matches rules on both sides (such as "Allow/Deny from all" paired with "Deny/Allow from some-specific-IP) or neither side, then default to the second item of the pair.
|I've got the following in my .htaccess file: |
Complete waste of time except in the rarest of exceptional cases. Find out what IP block each of those addresses belong to. If it's a server farm or similar, block the whole thing. Alternatively, block by user-agent or referer.
|#deny from .*domain\.com.* |
Keep this commented-out. It forces the server to parse all incoming requests and do lookups. More work for the server, and leaves you with unreadable logs. Besides, nobody ever visits from a named domain. It's much more likely to belong with your referer-based blocks.
| 8:54 pm on Apr 13, 2014 (gmt 0)|
Okay, so I should be blocking ranges instead of individual IPs. This leaves me with 2 questions:
1) Can anyone share a link with a good list of which ranges I should be blocking?
2) Why am I still getting form completions from the specific IPs that I am trying to block?
| 10:44 pm on Apr 13, 2014 (gmt 0)|
Lists don't do much good. You should learn what IPs are causing issues on your own site and look into blocking CIDRs that are not ISPs. Read through the discussions here in the forums and you can save a lot of work, but it is a bad idea to block every IP that has ever been on a list or every IP that gives you problems. With a little practice, you can see what requests are automated bots and which are problematic people. You don't want to block ISPs or you could lock out valid visitors.
As for why your blocks aren't working, it could be the way your host's server is set up, see if your host offers specific support. Many hosts show you examples you can adapt to your situation.
| 12:27 am on Apr 14, 2014 (gmt 0)|
|Why am I still getting form completions from the specific IPs that I am trying to block? |
Is it possible that these form completions are taking place somewhere outside the scope of the .htaccess file that contains your blocking code?
| 2:19 am on Apr 14, 2014 (gmt 0)|
To test whether your rules are working, see if you can lock yourself out.
Simplest is to include your own personal IP in the "Deny from..." list
As an alternative, include some distinctive part of your UA in this form:
BrowserMatch part-of-my-UA-here keep_out
Deny from env=keep_out
(This form is useful if you use a less common browser or OS, because you don't have to go check if your IP has changed since last week.)
That's assuming you have mod_setenvif-- which everyone does. This is also assuming that you have use of mod_authzthingummy. You'd know if you didn't. And, finally, this is all assuming your htaccess file is in the appropriate location. It has to be somewhere in the physical filepath leading to the area you want to protect. Generally this means in your root directory-- the same place you keep your favicon, robots.txt file and so on.
Start by confirming that your lockouts work at all, ever, on principle.