While several bugs have been filed to prevent Bugzilla user e-mail addresses from being harvested by spammers, by hiding them in various ways, I'd like to throw a complementary approach into the mix: prevent spammers from accessing Bugzilla in the first place. (OK, no technique is going to totally stop the bastards, but a variety of approaches which degrade spammer's ability to harvest addresses will lead to a better outcome.) My suggestion is to have an option to utilize one or more DNS Block Lists (DNSBLs) to limit access to Bugzilla. DNSBLs as are typically used to restrict access to e-mail servers from IP addresses which have been identified as "spammy". This is done by outright blocking of mail from listed addresses or counting listing(s) in a scoring scheme which might lead to rejection or tagging for possible routing into a junk e-mail folder. A Bugzilla utilization of a DNSBL would check the IP of a user attempting to access, log in or create an account and possibly subject the user to additional scrutiny/hoop jumping of various levels: 1. do nothing, just accumulate statistics 2. warn the user that his/her computer may be infected, but allow login/access. 3. warn the user that his/her computer may be infected and require additional steps to login/access, such as solve a simple math problem or a more sophisticated capcha. This would break spammer automation. 4. disallow the access. The DNSBL I most have in mind for this role is the Composite Block List (CBL), http://cbl.abuseat.org/ : QUOTE: The CBL takes its source data from very large spamtraps/mail infrastructures, and only lists IPs exhibiting characteristics which are specific to open proxies of various sorts (HTTP, socks, AnalogX, wingate etc) and dedicated Spam BOTs which have been abused to send spam, worms/viruses that do their own direct mail transmission, or some types of trojan-horse or "stealth" spamware, dictionary mail harvesters etc. NEW! The CBL also lists certain portions of SpamBot infrastructure, such as Spam BOT/virus infector download web sites, and other web sites or name servers exclusively dedicated to the use of Spam BOTs. Considerable care is taken to avoid listing IP addresses that have are or are likely to be shared with legitimate use, except in the case of infector download websites. In other words, the CBL only lists IPs that have attempted email connections to one of our servers in such a way as to indicate that the sending IP is infected, OR, IPs specifically dedicated to the propagation/use of Spam BOTs. /QUOTE These seem like IP addresses one does not want cruising around Bugzilla, harvesting stuff. Even if the IP is that of a legitimate user, a goal of this effort should be to get that user to fix the problem. In fact a bot infected legitimate user is really dangerous because that user will get access to Bugzilla information which is hidden from those browsing without logging in. One has to be very careful with the list(s) chosen. Many lists are specifically lists of end-user (home) IP addresses which are very inappropriate for sending e-mail, but quite appropriate for Bugzilla access. The Spamhaus Policy Block List (PBL) is an example of such. http://www.spamhaus.org/pbl/index.lasso One must be careful to select list which don't include end-user addresses. False positives is a potential problem, especially if Bugzilla is set to deny access. The CBL has an automated delist page, so the random glitch will be no problem. The user can delist themselves or the listing will expire. If the IP continues to send spam though, it will get re-listed. Perhaps Bugzilla could have some sort of whitelist mechanism... Further nefariousness is possible if the organization running Bugzilla works with the DNSBL it is using to hide spamtrap addresses throughout its Bugzilla pages and its organizational site in general. Spammers who harvest these addresses would then block their sending IPs (botnets?) not only from the organization running Bugzilla, but, in the case of the CBL, a huge chunk of the world, because the CBL is incorporated into the Spamhaus lists. Delightful thought, eh? (I have no idea whether the CBL or Spamhaus work with other organizations in planting spam traps...) This bug is somewhat speculative in that I have no idea of the relationship between spammy IP addresses and addresses used for harvesting, but my gut tells me that these days it is mostly being done with botnets and a compromised machine is not only a spam source, but a likely harvester. Likewise IP addresses identified as spammer infrastructure. It would be interesting as a first step to run some access logs against the CBL and see what kind of correlation, if any emerges.

Hey Rich. It's great that you're thinking about ways to prevent spammers from harvesting data from Bugzilla, but things that involve blocking at the IP level really belong in a firewall, not in Bugzilla. I wouldn't be surprised if there are already security products that do exactly what you want.

(In reply to comment #1) > ... but things that involve blocking at the IP level really belong > in a firewall, not in Bugzilla. I wouldn't be surprised if there > are already security products that do exactly what you want. Max, it had not occurred to me that a firewall would be a plausible way to do this, but I can see that now. Certainly, a firewall could be used to keep "bad" IP addresses out of a Bugzilla site by simply blocking them totally, or at least on port 80. But given these blocklists aren't perfect, one must consider the possibility that a legitimate user's IP is listed. Perhaps that user's machine is ok, but the user is sharing a NAT'd IP with another spammer controlled machine. Or perhaps the listing is simply in error in some way. A simple firewall would just cause that user to fail to connect, with no explanation. Not good. I would guess that there are firewalls that can return an HTML error page so at least the rejected user got a clue as to why the user was being blocked from the Bugzilla server? Are there more sophisticated firewalls/proxy-like packages that could even impose some sort of simple "are you a human" test such as a math problem or CAPTCHA, then connect on to Bugzilla if the user succeeds? It seems to me that a firewall would most likely be a limited, unhelpful thing which would not allow much flexibility while adding cost and complexity. (It might not be easy to do on a small, hosted webserver such as a small open source project might use.) I guess that's why I never seriously considered one. (Of course firewalls have their place in fending off DOS attacks or blocking regions of IP space that have no legitimate reason at all to be connecting to a site.) Please let me know if I'm wrong about firewall capabilities/cost. I think you are thinking too strictly about protocol levels and not thinking of IP address/DNSBL lookup as simply input data to Bugzilla's session logic. Consider that in SMTP, mail servers have been using DNSBLs to reject spam from "bad" addresses for ages. The simplest case is to do a DNS lookup against the list, and if the IP is there, issue an SMTP level reject message, so that a legitimate sender gets information back as to what happened: 550 5.7.1 E-mail from 11.22.33.44 refused. See http://www.example.org/blocked.html Modern mail servers and their add-ons are capable of a wide variety of application level actions using the presence of the connecting IP address in one or more DNSBLs as well as various info from the message headers and text. Back to Bugzilla. A DNSBL lookup is easy. To see if IP address 11.22.33.44 is in example.net's dnsbl, one does a DNS lookup (gethostbyname()?) for host name 44.33.22.11.dnsbl.example.net. If you get a result, the IP is listed, if you get NXDOMAIN, it is not. Bugzilla can then use that info to do things like the four options suggested above. The cost of this seems low. The Spamhaus FAQ describes using their DNSBLs for non-email applications and querying from your own application in the entries here: http://www.spamhaus.org/faq/answers.lasso?section=DNSBL Usage#260 . (They also list modules for Apache and Squid which can use DNSBLs to restrict access.) The SBL-XBL list at Spamhaus, which incorporates the CBL, would be another good choice for restricting access to Bugzilla.

The preceding URL should be http://www.spamhaus.org/faq/answers.lasso?section=DNSBL#260 , the last two entries in their FAQ. Sorry about the bug spam. :/

A CBL team member e-mailed me with the following: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A couple of disconnected comments: 1) We're aware of _no_ firewall product that supports DNSBLs. The thought tends to give firewall designers/network gurus fits. Violates their notion of network stack layering. Firewalls like having their ACLs stored _on_ the box. 2) Generally speaking, general DNSBL protection of an application like Bugzilla is better done in the web server, not the application itself. There are numerous plugins/modules for doing DNSBLs in Apache and other web servers. 3) That said, there's nothing wrong with an application using it for specialized purposes. Some payment systems use DNSBLs to help detect fraudulent transactions. 4) Watch out for the terms and conditions. See: http://cbl.abuseat.org/tandc.html If you _really_ want to use the CBL for something other than email, you must not mention the CBL in the error message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I still suspect that there are advantages over the blockage that may be afforded by a web server plug-in by having a DNSBL option in the session/login logic of Bugzilla. But I could be wrong. Guess some research into what these plug-ins could do. And of course, I'd still love to see a list of IPs used by guests and valid login users run against a blocklist for a major site like bugzilla.mozilla.org. Does this approach have any validity? I'm a mere b.m.o user, with no exposure to Bugzilla coding. Just wanted to get a different idea on the table.