Why Conpot matters
Conpot is a low-interaction ICS/SCADA honeypot that emulates common industrial services (Modbus, S7, SNMP, HTTP, EtherNet/IP). It is useful for:
- collecting reconnaissance traffic,
- validating SIEM/IDS detection rules,
- training teams with real OT protocol interactions,
- demonstrating exposure to management.
Run it on an isolated VM/VPS so nothing production-facing shares its network.
Conpot as a bounded computational system
Conpot is not a real industrial process — it’s a computationally limited emulation. This limitation is crucial: it bounds the complexity of interactions.
In real ICS, the state space is enormous — physical sensors, actuators, PLC logic, network events, timing, etc. Conpot reduces this to finite, predictable state transitions: Modbus read/write, S7 communication, HTTP responses.
Formally speaking, Conpot represents a decidable system — the number of possible states and transitions is finite and fully describable. This boundedness makes the “attack problem” tractable, while still retaining enough realism to study attacker strategies.
“A honeypot is an NP problem made P — it transforms an unbounded, complex environment into a controlled, solvable simulation.”
1) Prepare the VM / VPS
Update the system, install Docker and Nmap:
sudo apt update && sudo apt upgrade -y
sudo apt install -y docker.io nmap ufw
sudo systemctl enable --now docker
Firewall (example, adjust to your policy):
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp # SSH
sudo ufw allow 80/tcp # HTTP (optional)
sudo ufw allow 502/tcp # Modbus (if you expose it)
sudo ufw allow 102/tcp # S7 (if you expose it)
sudo ufw enable
2) Pull and run Conpot (map host → container ports)
Conpot’s default templates in the image often bind to container ports like 5020 and 10201. Map the host standard ports to the container ports so external scanners and Nmap hit it correctly:
sudo docker pull honeynet/conpot:latest
sudo docker run -it \
-p 80:80 \
-p 102:10201 \
-p 502:5020 \
-p 161:161/udp \
--name conpot_lab \
--network bridge \
honeynet/conpot:latest /bin/sh
Inside the container start Conpot:
~/.local/bin/conpot -f --template default
You should see:
Modbus server started on: ('0.0.0.0', 5020)
S7Comm server started on: ('0.0.0.0', 10201)
HTTP server started on: ('0.0.0.0', 8800)
3) Tail logs (host)
Watch activity in real time from the host:
sudo docker logs -f conpot_lab
4) Nmap: quick port check
Verify the service is reachable:
sudo nmap -sT -p 502,102 <target-ip>
# example when testing locally on the VPS
sudo nmap -sT -p 502,102 127.0.0.1
Expect 502/tcp open and 102/tcp open if port mapping and firewall are correct.
5) Nmap Modbus discovery
Use the NSE modbus-discover script to enumerate slave IDs and device identification strings:
# basic
sudo nmap -sT -p 502 --script modbus-discover.nse <target-ip>
# aggressive (more unit ID probing; noisy)
sudo nmap -sT -p 502 --script modbus-discover.nse --script-args='modbus-discover.aggressive=true' <target-ip>
What you get: Slave IDs, Slave ID data and any human-readable device strings — useful to learn which devices or scanners are probing you.
6) Nmap S7 discovery
Probe Siemens S7 emulation with the NSE s7-info script:
sudo nmap -sT -p 102 --script s7-info <target-ip>
# or with version detection
sudo nmap -sT -sV -p 102 --script s7-info <target-ip>
What you get: CPU/device identification or fingerprints — with Conpot you’ll usually see simulated or partial responses, but they still indicate probing activity.
7) Ensure NSE scripts are present
If a script is missing, update the Nmap script DB or add the script manually:
sudo nmap --script-updatedb
ls /usr/share/nmap/scripts | grep -E 'modbus|s7'
# if missing: download from Nmap repo into /usr/share/nmap/scripts then run --script-updatedb
8) Shodan: find Conpot instances
For research / threat-intel you can search Shodan for public Conpot instances using this filter:
product:"Conpot"
Use that filter in the Shodan search bar to find exposed honeypots (and study how others deploy Conpot). Don’t abuse — use results for defensive research and responsible disclosure if you discover sensitive exposures.
Safety & operational notes (short)
- Do not deploy Conpot on the same network segment as production OT assets.
- Treat a public VPS as disposable — snapshot, monitor, rebuild regularly.
- Limit outbound connections and ship logs off the VPS to a secure SIEM or storage.
- Only scan networks and addresses you own or have permission to test.
- Container hardening: run with least privilege where possible (non-root user, drop capabilities, read-only filesystem) — test because the official image may require adjustments.
- Port mapping: map host ports to Conpot’s internal ports (e.g.,
-p 80:8800,-p 502:5020,-p 102:10201) to ensure external scanners reach the services.
Conclusion
Conpot is more than a trap — it’s a computational model. By constraining state and transitions we make an intractable real-world problem analyzable. That’s the defender’s advantage: convert infinite-state complexity into a finite, decidable system and observe how attackers compute against it.