|
Author: M.Prince (30 Apr 07 4:49pm)
I'm not sure whether it is good for us to be white listing proxies like the Saudi example described above or not. Generally, I think that's a decision a website admin should make on their own site. As a result, we are currently recommending that implementations of http:BL white list at the local level. Here's how we implement it on the Apache module:
- Web admins can set a threshold of a threat score under which users are routed to a challenge page.
- The challenge page is user definable and can be a simple Javascript redirect (which bots will often fail) or a more complex CAPTCHA (e.g., type the following squiggly type, add these numbers together, identify which picture is a kitten, etc.).
- If the challenge is passed, the IP is added to a local white list and remains there for some period of time (web admin definable).
- The current version of the module does not relay this white list information back to Project Honey Pot, but we may build that functionality in at some point in the future.
One of the things we like about this type of white listing, and why we're encouraging it, is that good guys who don't know their computer has been taken over by a virus and been used to send spam can get a notice with instructions on what to do about it. For more information on why this can be a powerful tool to clean up the net, check out this article that was just written over at WashingtonPost.com:
http://blog.washingtonpost.com/securityfix/2007/04/building_a_webbased_neighborho_1.html
There is a place for a global white list, but we need to think carefully before we implement it. in order to 1) make sure it is not abused, and 2) make sure it doesn't create an overwhelming administrative burden. For now, remember that just because an IP is listed does not necessarily mean it belongs to a spammer.
Finally, do note that IPs automatically will fall off the http:BL list if no suspicious behavior has been noted for a period of time. This helps ensure the data remains fresh.
Matthew.
|
