Honeypot Design - Information Camouflage

I’ve run various honeypots for a long time. I ran a WordPress honeypot off and on from 2013 to 2018. I’ve run endlessh on my home server for years. Before that, I ran the cowrie ssh/telnet honey pot for a while. Currently, this website runs a fake WordPress login that tells you that you’ve used the wrong password after a 5 second delay. Feel free to try it. This website’s contact page does nothing but wastes spammers time and effort. I believe that everyone who has the ability and resources to run honey pots should run one or more. I believe that if a significant fraction of all attempts to scan or otherwise abuse internet services were met with a time wasting, or otherwise abusive or irritating honey pot, scanners and internet bottom feeders would be discouraged, and abandon their low level criminal behavior. High-level grey area behavior, like AI companies scraping the entire web every 10 or 12 hours whether it’s changed or not, would also be inhibited. There’s also the vigilante thrill of punishing bad internet behavior yourself. Beyond the slight moral obligation to deter low lifes by running honey pots, I believe those with the ability should write their own. An overwhelming number of idiosyncratically behaving false services is an insurmountable barrier even to “hyperscaler” corporations. What should someone designing a honeypot think about? Are there any considerations such a person should take into account? Based on the above experience with various honey pots, I wrote the following design considerations. I’m only numbering these to be able to refer back to them later. My numbering is not meant to be a prioritization.

Minimize your own resource consumption, eliminate resource exhaustion, of your own systems. Maximize attacker’s resource consumption

Reserve attacker resources if protocol allows Send malformed or inappropriate responses

Mimic an existing (real, functional) server as closely as possible Log as much as possible, even malformed data, or data outside the protocol in question.

Avoid collateral damage

Packet-level attribution is sometimes impossible (i.e. UDP services) Avoid mirror amplification attacks

Be attractive to attackers

Maximize attacker’s resource consumption might be in direct opposition to minimizing your own resource consumption, or mimicking existing software. If you want to jerk attackers around, you may not be able to mimic existing software very well. The choices made depend on what goals you’ve got. Tension between considerations exists, and I think tensions can only be resolved in practice, by experience, not in up-front design. Resolving the tensions in requirements and desires lies at the heart of designing and writing any complicated software system, but honey pots go beyond that. What your software initially does can teach you more about attacker’s behavior, motivating you to rewrite. Running honey pot software requires ongoing updates, and has similarities to an arms race. Bibliography Weirdly, the internet is somewhat short on this topic. All I could find was a couple of out-of-print books, and some maybe “predatory journal” papers.

Lance Spitzner, Addison-Wesley, 2002, Honeypots: tracking hackers Mohammed Mohssen, CRC Press, 2016, Honeypots and routers : collecting internet attacks Enrico Cambiaso and Luca Caviglione, Scamming the Scammers: Using ChatGPT to Reply Mails for Wasting Time and Resources, PDF Neha Titarmare, Nayankumar Hargule, Anand Gupta, An Overview of Honeypot Systems, PDF Zeenat Nisa, Honeypots: Concepts, Types and Challenges, PDF Abe Hayat Khan, Waseem Ullah Khan,

Ilham Hamid, Arbab Waseem Abbas, Muhammad Hassaan Chaudhry, and Noor Ul Arfeen, Analysis and Implementation of Honeypot Framework for Enhancing Network Security, PDF Tian Bin, Changhong Yu, Study on Application and Design of Honeypot Technology, PDF Dr Balaji k, Yashaswini G T, Rakshita Itagi, Sahana L, Shreya Ravi Shastri, HONEYPOT IN NETWORK SECURITY PDF This one is from the International Journal of Creative Research Thoughts, which is definitely predatory.