Building an Isolated Honeypot: Multi-Layer Security Architecture

I built an isolated Raspberry Pi honeypot running Cowrie and Dionaea to collect real-world attack data. The goal was simple: deploy honeypots that can be compromised without risking my internal network. This required a defense-in-depth architecture with multiple security layers working together.

This builds on my domain controller setup and dual-SIEM integration. The honeypot feeds attack data to the same infrastructure, giving me real threat intelligence to investigate.

Network Isolation:

First step was creating a dedicated Honeypot VLAN in UniFi. I enabled “Allow Internet Access” but left “Isolate Network” disabled. That isolation setting seems convenient, but it creates firewall rules you can’t fully control. I wanted explicit firewall rules I could test and verify.

The UniFi firewall got one critical rule: Block-Honeypot-to-RFC1918. This drops all traffic from the Honeypot network to private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Even if an attacker compromises the honeypot, they can’t reach my internal networks.

SSH Hardening: The Cloud-Init Discovery

Before deploying the honeypots, I needed to move SSH from port 22 to port 2200 (Cowrie needs 22). I edited /etc/ssh/sshd_config, set Port 2200, disabled password authentication and enabled public key authentication and restarted the SSH service.

SSH still allowed password authentication…

Here’s what I discovered. Raspberry Pi OS uses cloud-init, which has an override file at /etc/ssh/sshd_config.d/50-cloud-init.conf. This file was setting PasswordAuthentication yes and ignoring my port change. The override file takes precedence over the main config.

The fix: edit the cloud-init override file directly, not just the main config. I disabled password authentication and set up SSH key-only access. This time it stuck.

sudo nano /etc/ssh/sshd_config.d/50-cloud-init.conf
# Set PasswordAuthentication no
sudo systemctl restart sshd

This is critical for Raspberry Pi OS users. Most SSH hardening guides don’t mention the cloud-init override, so your changes get silently ignored.

Deploying Cowrie and Dionaea

I followed this guide (https://gist.github.com/n0xa/b179848093a4e346f7bd6b8ab61e2909) to deploy both honeypots via Docker on the Pi. Cowrie simulates SSH and Telnet, while Dionaea mimics multiple vulnerable services (FTP, SMB, MySQL, etc.).

# Deploy Cowrie
mkdir ~/cowrie && cd ~/cowrie
sudo wget "https://mhn.h-i-r.net/api/script/?text=true&script_id=3" -O deploy.sh
sudo bash deploy.sh https://mhn.h-i-r.net AyBab7u
sudo docker-compose up -d

# Deploy Dionaea  
mkdir ~/dionaea && cd ~/dionaea
sudo wget "https://mhn.h-i-r.net/api/script/?text=true&script_id=4" -O deploy.sh
sudo bash deploy.sh https://mhn.h-i-r.net AyBab7u
sudo docker-compose up -d

Both containers started successfully and began reporting to the HPFeeds server at mhn.h-i-r.net.

Initial Testing

With SSH moved to port 2200, Cowrie claimed port 22. I tested from my main network (VLAN1) by connecting to the Pi on port 22. Instead of my real SSH, I got Cowrie’s fake shell with old SSH key algorithms.

ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedKeyTypes=+ssh-rsa root@192.168.X.X -p 22

The fake shell showed fabricated processes, fake users, and a completely simulated Debian system. Perfect.

Next up: testing if this isolation actually works when a honeypot is compromised.

This is part of my hands-on SOC testing series where I build detection infrastructure and test real-world attack techniques.