If you're interested in helping the SecKC HoneyNet:

  • Provision a Raspberry Pi, PC, Server or cloud instance for use as a honeypot.
  • If using a cloud provider or spinning up a VPS, consider deploying a honeypot in Asia, Europe, Africa or South American zones for diversity. We have a bunch of nodes in the US already.
  • Change the host name to something unique by editing /etc/hostname then rebooting, perhaps include your handle (e.g. ax0n-home-pi or ax0n-gcloud-ubuntu)
  • Make sure that the device is publicly accessible on the ports you care about (cowrie only needs ports 22 and 23 open) - The deploy script moves the host's real sshd to port 2101.
  • Preferably, host it in the DMZ so as to avoid horizontal spread and collateral damage inside your home/lab network.

    Once that's complete, run the following command line to download and install Cowrie, a telnet/SSH honeypot:
    wget "https://mhn.h-i-r.net/api/script/?text=true&script_id=18" -O deploy.sh && sudo bash deploy.sh https://mhn.h-i-r.net uOJvQdUR

    Email me, at ax0n (at) h-i-r.net, or hit me up on discord (ax0n#3338) for assistance or questions, and feel free to swing by the SecKC Discord Server. Install the Python3 HPFeeds client with:
    pip install hpfeeds
    The following command should subscribe the HPFeeds CLI to all available honeypot channels, though Cowrie.sessions is the only thing that's active most of the time.
    hpfeeds -i seckc-community -s fk6QgrnyvwbWSxCIwL5SIc2oARC4DXx46 --host mhn.h-i-r.net -p 10000 -c cowrie.sessions -c dionaea.connections -c snort.alerts -c conpot.events -c shockpot.events -c wordpot.events -c amun.events subscribe

    The following crontab entries are now added by the Cowrie deploy script to automatically purge old logs and restart the services (it periodically needs this due to the main MHN HPFeeds server restarting occasionally) 

    0 23 * * * supervisorctl restart all
0 5 * * * find /opt/cowrie/var/log/cowrie -type f -mtime +7 | xargs rm
    If you add the following to /etc/rc.local on RasPiOS (before the "exit 0" line at the end), you can keep any honeypot traffic and user-level honeypot escapes from pivoting to your LAN. This will not perfectly protect your LAN if a privilege escalation is used -- as root can disable the iptables rules. I've never seen this happen, though. 
    ## Allow outbound traffic to any destination
## if it's related to an inbound connection
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
## Block all outbound traffic to RFC1918 NAT networks
iptables -A OUTPUT -d 192.168.0.0/16 -j REJECT
iptables -A OUTPUT -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -d 10.0.0.0/8 -j REJECT