Hardening Honeypot Technologies in IoT with HoneyFarm Environment

📌 Overview

This repository contains the design, implementation, and analysis of HoneyFarm — a scalable environment for deploying, managing, and hardening IoT honeypot technologies. The project aims to improve IoT security through cyber psychology deception-based defense mechanisms that can capture malicious activity, analyze attack patterns, and strengthen system resilience.

---

🏗 Architecture

• Components:

  • Honeypots for various IoT device emulations, such as SSH/Telnet on Cowrie, HTTP on SNARE, PJL on MiniPrint.
  • Upgraded with psychological enhancements such as tailored responses aimed at exploiting emotional states of an attacker after identifying a personality trait based on the latter's command execution sequence. Furthermore, several cognitive biases are also incorporated throughout the system
  • Data collection and storage pipeline.
  • Threat intelligence and analytics modules.

• Diagram:

• Design Notes: The Cowrie nodes are configured to respond according to an a personality trait based on an attackers command execution sequence. The responses are tailored to evoke emotions such as CONFIDENCE, SURPRISE, CONFUSION, FRUSTRATION, SELF_DOUBT. Moreover, the layout and structure of the SSH and Telnet honeypot is configured to mimic a realistic IoT server with fake third party software toolkit and notes. The website is developed to represent the dashboard of a smart home IoT environment and serves as the control center for the devices. In the source code there are cues and fake scripts communicating with SSH/Telnet, and PJL servers, that aim to enhance the illusion of interconnetivity.

---

🚀 Deployment

This section explains how to set up and run the HoneyFarm environment (SNARE + Cowrie variants + Miniprint) using Docker Compose.

• Prerequisites: Before you begin, make sure you have the following installed:

  • Docker (with Docker Compose support)
  • Python 3.9+
  • Git

• Setup Instructions:

  1. Clone the repository:

     git clone https://github.com/chensy618/HoneyFarm.git
     cd honeyfarm

  2. Build and start the services:

     docker-compose build

     docker-compose up -d

  3. Run SNARE

     The SNARE service requires a separate setup. Navigate to the /tanner directory and run the same commands:

     cd tanner
     docker-compose build
     docker-compose up -d

• Notes:

  • Use docker-compose logs -f <service_name> to view logs for a specific service.
  • Use docker-compose stop to stop all containers.
  • Make sure all required ports are available before starting the services.

⚙️ Configuration Guide

This section explains how to adjust the configurations for honeypot settings, network rules, and data sinks.

---

1) Honeypot Settings

SNARE

• Configuration location
  • Place the cloned website folders under tanner/snare/dist/pages/ so each page is accessible to SNARE.
    Example:

    tanner/
      snare/
        dist/
          pages/
            iot_system_cloned/
    

Cowrie (all variants)

• Configuration location
  • ...-etc volumes → /cowrie/cowrie-git/etc (main config: cowrie.cfg)
  • ...-var volumes → /cowrie/cowrie-git/var (runtime data, logs)
• Common changes
  • Change SSH/Telnet ports: adjust the ports mapping in docker-compose.yml
  • Modify fake system identity: edit hostname and related settings (e.g. prompt) in cowrie.cfg
  • Update honeytokens: add/remove files in the honeytoken config (e.g. appliance/cowrie/src/honeytoken/honeyfiles.py) to trigger alerts

Miniprint

• Configuration location
  • Bind mounts:
    • ./log/ → /app/log/ (incoming print job logs)
    • ./uploads/ → /app/uploads/ (uploaded files)
• Common changes
  • Adjust exposed port in docker-compose.yml (9100:9100)
  • Modify fingerprint to avoid honeypot detection

---

2) Network Rules

• Network definition
  • All services are connected to a custom honeynet bridge network with a fixed subnet (192.168.100.0/24)
  • Each service has a static IP (ipv4_address)
• Common changes
  • Change ipv4_address for a service (must be unique within subnet)
  • Update ports mapping to expose services on different host ports
  • Restrict access using firewall rules (e.g., iptables) or cloud security groups

---

3) Data Sinks

• Local logging
  • Cowrie logs: in the ...-var volume under /cowrie/cowrie-git/var/log/cowrie/
  • Miniprint logs: miniprint/log/
• SMTP alerts (for honeytokens)
  • Controlled by the shared x-environment variables:

    SMTP_FROM: "sender@example.com"
    SMTP_TO: "recipient1@example.com,recipient2@example.com"
    SMTP_USER: "sender@example.com"
    SMTP_PASS: "app_password_here"
    SMTP_SERVER: "smtp.example.com"
    SMTP_PORT: "587"

  • Change SMTP_TO to update recipients
• External log forwarding
  • Optionally add a logging/forwarding container (e.g., ELK stack) and mount the honeypot log volumes into it for analysis.
• Webhook integration
  • For GitHub, configure a repository webhook to receive JSON payloads from the honeypot automatically.

---

4) Testing Your Configuration

• SSH access example:

  ssh -p 2222 david@localhost
  ssh -p 5900 david@localhost
  ssh -p 5000 david@localhost
  

📊 Data Analysis & Threat Intelligence

A customised data analysis dashboard was developed using Plotly Dash, a Python based web framework for interactive data visualization.

• Launching the Dashboard:

  Navigate to the /data_visualization directory, run app.py, and open http://localhost:8050 in your browser.

• Data Collection:

  • Log files from honeypots
  • Interaction data analysis
  • User study data analysis

• Analysis Tools:

  • Python (plotly, pandas, numPy)

• Metrics & KPIs:

  • Number of unique human attackers
  • Command execution sequence analysis
  • Average time spent on honeypot

• Visualization Examples:

  • Total interactions per honeypot:

• Top commands used on the lighting node:

*Top username and IP on the lighting node:

• Human Attacker Interaction:

• Interaction data:

• Username and passwords used: