Honeypot

When Joe reported the new spam on this wiki, he noted that several pages seem to act as honeypots that attract spammers like light will attract moths. Joe is correct: most (if not all) of the spam we have seen on this wiki was from spammers who used Google to search for spammable resources on the web.

So far, I have only seen two strategies used by our spammers:

1. Search for the links of other spammers and then spam the spammed pages, either completely changing the page (and thus possibly hurting the competition) or adding your links to the spammed pages (probably because you are the original spammer).
2. Search for phrases identifying wikis, such as "Edit text of this page".

Since our wiki uses the phrase "Edit text of this page" and has several pages that contain spammy URLs, this wiki should attract many spammers. I am wondering whether we could use this honeypot effect to punish spammers.

In the wast and gastly world of email spam, there are two kinds of honeypots that are sometimes used to punish spammers:

1. Scripts like webpoison that try to attract spiders looking for email addresses. These spiders are then kept busy with pages that contain many (made-up) email addresses and that are delivered only slowly. While the spiders are busy with the webpoison script they cannot do anything else and they ruin their master database of email addresses.
2. SMTP honeypots. Spammers are tricked into using fake SMTP servers that pretend to relay email when in fact they do only feed email to /dev/null. This approach is called teergrubing.

The question is: Could we do something similar to the above?

The dirty little questions are:

1. How would we identify a spam attempt?
2. How could we punish the spammer?

1) should not be too difficult if we don't try to be too clever and catch every possible spam attempt. For example, we could simply watch for Chinese keywords linking to Chinese sites.

2) is a bit more difficult. Could we send invalid html that crashes their browser? Provoke a blue-screen? Could we make them click through endless confirm this and that forms?

Any kinds of comments very welcome.

– Manni - 2004-11-09 13:32

1. This won't work as you don't know what "browsers" they use.
2. Best punishment would be to tell them that their edit was successful while not saving the spam. Just make a copy of the page that is showed only to them. Then they don't know about our countermeasures and cannot react.

– d2-168.vdsl.isp-service.de

Why don't we know what browser they use? 95% of users use IE. And the browser string tells us what browser they are using. Spammers have not yet advanced to the level of faking that because there is no need. There are known ways to crash IE, and there are ways to crash at least some versions of Mozilla. The next most likely browser would be VBScript which uses IE or Java which I am sure can be made to crash also if they are using a GUI to display pages. If they are using just command line an parsing the page its very unlikely we are going to be able to crash them.

Giving them a fake page to think their edits were successful would require a lot of work for little reward. For a punishment to be useful it would have to be widely enough used to actually slow them down. The SMTP email honeypot trap is designed to keep their program thinking their spam is working but very slowly. That works becuase they are sending out thousands at a time and unlikely monitoring the programs. Wiki spammers hit a single wiki usually between 1 and about 50 times in a single attack. And we have some evidence that makes us think most wiki spammers do some monitoring of their programs.

Chongqed has a growing following, but each wiki software would require its own honeypot punishment code. This would mean it would be hard for spammers to identify a honeypot, but also unlikely many people are going to use it.

Manni, not that I think this is a useful idea, but what browsers were the spammers using that have hit us? Is the browser they were using when comming from the search engine the same as the one that hit us? You should add stuff like that to the idiot spammer pages when you have time. Its still interesting. Maybe mozilla.org would like stats on wiki spammer use of browsers. 100% IE would actually be a good stat in this case. ;-)

A better honeypot which spammers would likely fall for is to create a page that only allows <pre> text. There would be no way for them to make a link, but their text link appearing seems to make many dumb spammers happy. The reason JoesTempSpamHolder accidently turned out to be such a good honeypot is because it contains the URLs of so many of their buddies/competition. If you don't leave the spam there (with dead links) then spammers will be less likely to find your honeypot page.

As for identifying the spammer, I think percentage of text added vs. URLs would be good on most wikis, but since we use this wiki to list lots of spammers URLs that would not work. Perhapse percent of text vs. URLs not in <pre> tags. A chongqer whitelist would help too. We can't just go by Chinese IPs adding Chinese URLs because most have bought .com addresses.

– Joe - 2004-11-09 17:37 UTC