On Wed, Aug 31, 2016 at 07:48:50PM +0000, James MacWhyte wrote: > > > > >I've always assumed honeypots were meant to look like regular, yet > > >poorly-secured, assets. > > > > Not at all. Most servers have zero reason to have any Bitcoin's accessible > > via them, so the presence of BTC privkeys is a gigantic red flag that they > > are part of a honeypot. > > > > I was talking about the traditional concept. From Wikipedia: "Generally, a > honeypot consists of data (for example, in a network site) that appears to > be a legitimate part of the site but is actually isolated and monitored, > and that seems to contain information or a resource of value to attackers, > which are then blocked." > > I would argue there are ways to make it look like it is not a honeypot > (plenty of bitcoin services have had their hot wallets hacked before, and > if the intruder only gains access to one server they wouldn't know that all > the servers have the same honeypot on them). But I was just confirming that > the proposal is for an obvious honeypot.
Ah, yeah, I think you have a point re: naming - this isn't quite the traditional honeypot, as we uniquely have the ability to give the attackers a reward in a way where it's ok for the intruder to know that they've been detected; with traditional non-monetary honeypots it's quite difficult to come up with a scenario where it's ok for an intruder to gain something from the intrusion, so you're forced to use deception instead. Perhaps a better term for this technique would be a "compromise canary"? Or "intruder bait"? After all, in wildlife animal research it's common to use bait as a way of attracting targets to discover that they exist (e.g. w/ wildlife cameras), even when you have no intention of doing any harm to the animal. -- https://petertodd.org 'peter'[:-1]@petertodd.org
signature.asc
Description: Digital signature
_______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
