Building Your First Internet-Facing Honeypot
A beginner's guide to safe network deception research with a VPS and a Raspberry Pi β safety-first architecture that never exposes your home IP.
Contents
What is a Honeypot?
A honeypot is a deliberately vulnerable system deployed to attract, detect, and study attackers. Unlike a real server, a honeypot has no production value β everything that touches it is either a scanner, a bot, or a human probing for weaknesses.
Low Interaction
Simulates services without running real software. Cowrie emulates SSH/Telnet shells. Dionaea emulates SMB/HTTP. Safe by design β the attacker never gets a real shell.
High Interaction
Runs a real OS in a sandbox. More realistic, but riskier. Only recommended inside isolated VMs with no network access to your home.
For beginners, start with low-interaction honeypots. They are safe, well-documented, and capture the same attacker behavior (credentials, commands, malware downloads) without the risk of a real compromise.
The Architecture: Why a VPS Front Door
The single most important design decision is never expose your home IP. If you port-forward honeypot ports on your home router, every scanner on the internet learns your residential address. Instead, use a disposable cloud server as the public face.
Why This Works
The Pi initiates an outbound WireGuard tunnel to the VPS. The VPS forwards attacker traffic through the tunnel to the Pi. If the VPS is compromised or blacklisted, you destroy it and spin up a new one for $5. Your home IP never appears in any scan.
What You Need
| Component | Purpose | Approximate cost |
|---|---|---|
| Disposable VPS | Public front door; forwards attacker traffic | $3β7/month |
| Raspberry Pi 4 or 5 (or any always-on Linux box) | Runs the honeypot containers | $50β80 (one-time) |
| microSD card (32 GB+) | Pi operating system and data | $8β15 |
| Your existing home internet | The Pi sits on your LAN but never exposes ports directly | Free |
You do not need a static home IP, port forwarding on your router, or a domain name. The Pi dials out to the VPS; the VPS never needs to reach in.
Setting Up the VPS
Choose a Provider
Any cheap VPS provider works. Popular choices:
| Provider | Why | Notes |
|---|---|---|
| Hetzner | Cheap, EU/US locations, hourly billing | Good for EU-based research |
| DigitalOcean | Easy setup, good documentation | Widely used |
| Vultr | Many global locations | Good for testing geographic differences |
| Linode/Akamai | Reliable, predictable pricing | β |
Disposable Mindset
Treat the VPS as expendable. It will get scanned, probed, and potentially abused. It holds no data of value. If it gets blacklisted or compromised, destroy it and deploy a new one. Never put anything sensitive on it.
Basic VPS Setup
# 1. Create a VPS (Ubuntu 22.04 or 24.04 LTS, smallest tier)
# 2. SSH in as root
ssh root@YOUR_VPS_IP
# 3. Update and harden SSH
apt update && apt upgrade -y
# Change SSH to a non-standard port (e.g., 4422)
sed -i 's/#Port 22/Port 4422/' /etc/ssh/sshd_config
systemctl restart sshd
# 4. Create a non-root user
adduser honeypi-admin
usermod -aG sudo honeypi-admin
# 5. Disable root SSH login
sed -i 's/PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
systemctl restart sshdImportant
The VPS admin SSH should be on a non-standard port. This is your management access β protect it with key-based auth only, disable password authentication, and never reuse passwords from other services.
The Secure Tunnel (WireGuard)
WireGuard creates an encrypted tunnel between the VPS and your Pi. The Pi dials out to the VPS, so no home router configuration is needed. The VPS never needs to know your home IP.

On the VPS
apt install wireguard
wg genkey | tee /etc/wireguard/privatekey | wg pubkey > /etc/wireguard/publickey# /etc/wireguard/wg0.conf on the VPS
[Interface]
Address = 10.42.0.1/24
ListenPort = 51820
PrivateKey =
[Peer]
# Pi's public key
PublicKey =
AllowedIPs = 10.42.0.99/32 On the Pi
sudo apt install wireguard
wg genkey | tee /etc/wireguard/privatekey | wg pubkey > /etc/wireguard/publickey# /etc/wireguard/wg0.conf on the Pi
[Interface]
PrivateKey =
Address = 10.42.0.99/24
[Peer]
PublicKey =
Endpoint = :51820
AllowedIPs = 10.42.0.0/24
PersistentKeepalive = 25 Verify the Tunnel
- From the VPS:
ping 10.42.0.99should succeed. - From the Pi:
ping 10.42.0.1should succeed. - If not, check that both peers have each other's public keys and that the Pi's firewall allows outbound UDP to the VPS on port 51820.
Port Forwarding (DNAT)
The VPS forwards attacker traffic from its public IP through the tunnel to the Pi's honeypot containers. This is done with iptables DNAT rules.

# On the VPS: forward port 22 (SSH) and 23 (Telnet) to the Pi
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 22 -j DNAT --to-destination 10.42.0.99:22
iptables -t nat -L PREROUTING -n --line-numbers # verifyRepeat for each honeypot port you want to expose. Common choices for IoT research:
| Port | Service | Why attackers target it |
|---|---|---|
22 | SSH | Brute force, botnet enrollment |
23 | Telnet | IoT botnets (Mirai family) β highest volume |
80/443 | HTTP/HTTPS | Web exploits, router CGI attacks |
445 | SMB | EternalBlue-style scanning |
3389 | RDP | Windows brute force |
6379 | Redis | Ransomware deployment |
8080 | HTTP alt | Web exploits, admin panels |
Key Principle
The VPS's admin SSH port is separate from the honeypot ports. Never forward the VPS's own management SSH port to the Pi.
Firewall and Isolation
This is the most critical safety layer. Without it, a compromised honeypot container could pivot to your home network or reveal your real IP.
On the Pi: Seal Container Egress
The Pi's firewall must block all outbound traffic from Docker containers except the WireGuard tunnel. This prevents a compromised honeypot from phoning home (which would leak your home IP).
# Block all container egress (sealed mode)
iptables -A FORWARD -j DROP
# Allow established connections back in
iptables -I FORWARD 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# Block containers from reaching the home LAN
iptables -A FORWARD -d 192.168.0.0/16 -j DROP
iptables -A FORWARD -d 10.0.0.0/8 -j DROP
iptables -A FORWARD -d 172.16.0.0/12 -j DROPWhy This Matters
If an attacker compromises a honeypot container and tries to scan your home network or phone home to a C2 server, the firewall drops it. The attacker sees a dead end, not your home network.
Network-Level VLAN Isolation
Firewall rules are important, but they are a software control that can be bypassed if the host itself is compromised. The strongest protection is network-level separation β putting the honeypot Pi on a subnet that physically cannot reach your trusted devices.

How to Implement VLAN Isolation
| Option | How it works | Difficulty |
|---|---|---|
| VLAN on your router | Most modern routers support VLANs. Assign the Pi to an "IoT" or "untrusted" VLAN with inter-VLAN routing disabled. | Low |
| Dedicated firewall appliance | Place a firewall device between the Pi and the rest of your network. Configure it to block all traffic from the Pi's subnet to trusted subnets. | Medium |
| Physical separation | Connect the Pi to a separate switch or router that has no uplink to your main network (only internet access). | Low |
Defense in Depth
Use both layers β VLAN isolation (network-level, hardest to bypass) and host firewall rules (software-level, catches what VLANs miss). Neither alone is sufficient β together they ensure a compromised honeypot cannot pivot to your real devices.
Monitoring What You Capture
At minimum, you want to know:
- Who is connecting (source IP, country, ASN)
- What credentials they try
- What commands they run after a successful login
- What files they try to download
Log Storage Options
| Option | Complexity | Best for |
|---|---|---|
Cowrie JSON logs + jq | Low | Getting started, quick analysis |
| SQLite with a simple collector | Medium | Structured queries, dashboards |
| Elasticsearch + Kibana | High | Large-scale visualization |
| Grafana + SQLite | Medium | Dashboards on a Pi |
What to Look For in Your First Week
- Top source IPs β who is scanning you most?
- Top credentials β
root/admin,admin/12345, etc. - Commands after login β
uname,cat /etc/passwd,wget - Downloaded files β malware samples (save the SHA-256, do not execute them)
- Port distribution β Telnet (23) usually dominates for IoT honeypots
Legal and Ethical Considerations
Consent Banner
Configure your honeypot to display a legal banner before the login prompt. Cowrie supports this via banner_file in its configuration. This supports a "consent to monitoring" argument under computer fraud laws in many jurisdictions.
- Do not actively attack back. Honeypots are passive observers.
- Do not use captured credentials against real systems.
- Do not share malware samples outside controlled research channels.
- Do report abusive IPs to AbuseIPDB or your hosting provider.
- Do anonymize data before publishing (redact your VPS IP, home network details).
Common Beginner Mistakes
| Mistake | Consequence | How to avoid it |
|---|---|---|
| Exposing your home IP via port forwarding | Attackers know your physical location | Always use a VPS front door |
| Running high-interaction honeypots on your main LAN | Compromise can pivot to real devices | Use low-interaction or isolated VMs |
| Executing captured malware "to see what it does" | Infecting your own machine | Static analysis only; use a disposable VM if you must detonate |
| Storing API keys or credentials in the honeypot filesystem | Attackers steal your secrets | Use synthetic, obviously fake content |
| Forgetting to persist firewall rules after reboot | Honeypot becomes an open relay | Use iptables-persistent or a systemd unit |
| Not monitoring disk space | Logs fill the SD card and crash the Pi | Set up log rotation and disk alerts |
| Using default passwords on the VPS | VPS gets compromised, home IP exposed | SSH key auth only, non-standard port, disable root login |
Pre-Launch Checklist
Before You Go Live
- VPS has SSH key auth only, non-standard port, root login disabled
- WireGuard tunnel is up and both peers can ping each other
- DNAT rules forward only honeypot ports (not your admin SSH)
- Pi firewall blocks all container egress except the tunnel
- Pi firewall blocks all traffic to home LAN subnets
- Honeypot containers bind only to the tunnel IP, not 0.0.0.0
- Legal banner is configured
- Log storage has adequate disk space and rotation
- You have a plan for what to do if a container is compromised
Want a Hardened Network β Not Just a Honeypot?
A honeypot shows you who is knocking on the door. Our Network Hardening service seals the doors, hardens the router, and locks down every device on your SOHO network β so the attackers your honeypot catches never make it past your real perimeter.
Sources & Further Reading
- Cowrie documentation β the most widely deployed SSH/Telnet honeypot
- Dionaea documentation β SMB/HTTP/malware capture
- WireGuard quick start β tunnel setup
- T-Pot β all-in-one honeypot platform (heavier, but good for comparison)
- AbuseIPDB β report and check abusive IPs