![[Home]](http://meatballwiki.org/meatball.gif)
WildHoneyPot
MeatballWiki | RecentChanges | Random Page | Indices | CategoriesA frequent if extreme strategy for combatting attacks is to construct HoneyPots; that is, dummy targets that invite temptation to attack, yet are in truth under complete observational control of the white hats. The goal is to learn about the attackers, not to stop them.
While exceptionally useful in learning about black hats, HoneyPots are rather expensive and cumbersome to create. They have a number of additional drawbacks, such as creating more vulnerable targets and therefore more attacks (the reverse of what we want), exposing the white hats if a HoneyPot is compromised, and being a potential vector for misinformation if a compromised HoneyPot continues to be unwittingly trusted by the white hats.
An alternative is not to create a HoneyPot, but to observe legitimate targets in the wild just as one would observe a HoneyPot. Such a WildHoneyPot could be unobtrusively observed to collect data on black hats without necessarily incurring the same costs or liabilities as an actual HoneyPot. Of course, it's still true that once a black hat becomes aware that a white hat is observing a particular target, that target can be used as a vector for misinformation. The difference is that a white hat need never announce their observations in any way.
While it may seem cruel or inhumane to let a legitimate target be attacked, there are many situations when it is impossible to DefendEachOther and intervene on the target's behalf. For instance, a GhostTown on the Internet has no one to contact, yet they are major targets for LinkSpam. If we observed GhostTowns, we could collect data about spam and spammers in order to take actions against them.
Ostensibly, one would first create a method to detect OnlineCommunities and then have a good statistical test to determine their current vitality. What makes WildHoneyPots different than simple unobstrusive observation is that online community engineers should be encouraged to publish the kinds of statistics that SearchEngines can use to automatically discover and track the health of them. While this will also make it easier for spammers to detect GhostTowns, that could also be a benefit as a way to MisdirectTemptation? away from living sites. That is, if we build into our software means to attract spammers to abandoned GhostTown away from living sites, the nuisance level of spam could be dramatically lowered. At least until SearchEngines begin to cull GhostTowns from their data sets. In the latter case, this has the added benefit of motivating the tracking of GhostTowns, a valuable set of data we can use to clean our statistical data sets.
CategorySpam CategoryHardSecurity
GhostTown detection
The clear major technical hurdle is how does one statistically detect a GhostTown? -- SunirShah
How about a Wiki whose recent changes exclusively match ShotgunSpam?
Good idea! We can use a known list of ShotgunSpam (and GhostTowns) to correlate to other ShotgunSpam (and GhostTowns). Thus, it will snowball.