Implementing Network Deception with Honeypots
When to Use
- When deploying deception technology to detect lateral movement
- To create early warning indicators for network intrusion
- During security architecture design to add detection depth
- When monitoring for unauthorized internal scanning or credential theft
- To gather threat intelligence on attacker techniques and tools
Common Misconfigurations & Verification
Honeypots most often provide false comfort because they are deployed in
monitor-only mode, are trivially fingerprintable, or sit where no attacker will
ever reach them:
- Monitor-only / no alerting: Cowrie or OpenCanary capture sessions to a
local log that nobody reads. Confirm log forwarding to the SIEM (syslog/
webhook) actually delivers and a detection rule fires, not just that the file
grows.
- Fingerprintable deployment: default Cowrie hostname
svr04, the canonical
T-Pot banner set, or an SSH server that responds too perfectly tips off
attackers who then avoid it. Customize banners, hostnames, and filesystem
contents away from known defaults.
- Placed off the attack path: a honeypot on an isolated VLAN with no
reachable services sees only internet background noise. Place decoys inside
segments where lateral movement and internal scanning actually occur, with
realistic SSH/SMB/RDP services exposed.
- No baseline for noise: mass scanner traffic drowns real signal; tune out
known scanner ranges so a credentialed login attempt stands out.
- How to confirm it works: from a separate host, run an SSH login against
Cowrie, an SMB connection and an
nmap sweep against OpenCanary/T-Pot, and
verify each interaction produces a forwarded alert with correct source IP,
service, and credentials captured.
Prerequisites
- Linux server or VM for honeypot deployment (Ubuntu 22.04+ recommended)
- Python 3.8+ with pip for OpenCanary installation
- Docker for T-Pot or containerized deployment
- Network segment with appropriate VLAN configuration
- SIEM integration for alert forwarding (syslog, webhook, or file-based)
- Firewall rules allowing inbound connections to honeypot services
Workflow
- Plan Deployment: Select honeypot types and network placement strategy.
- Install Honeypot: Deploy OpenCanary, Cowrie, or T-Pot on dedicated host.
- Configure Services: Enable emulated services (SSH, HTTP, SMB, FTP, RDP).
- Set Up Alerting: Configure log forwarding to SIEM and alert channels.
- Deploy Canary Tokens: Place credential files, shares, and DNS entries.
- Monitor Interactions: Analyze honeypot logs for attacker activity.
- Tune and Maintain: Update configurations based on detection results.
Key Concepts
| Concept |
Description |
| OpenCanary |
Lightweight Python honeypot with modular service emulation |
| Cowrie |
Medium-interaction SSH/Telnet honeypot capturing commands |
| T-Pot |
Multi-honeypot platform with ELK stack visualization |
| Canary Token |
Tripwire credential or file that alerts when accessed |
| Low-Interaction |
Emulates services at protocol level without full OS |
| High-Interaction |
Full OS honeypot capturing complete attacker sessions |
Tools & Systems
| Tool |
Purpose |
| OpenCanary |
Modular honeypot daemon with service emulation |
| Cowrie |
SSH/Telnet honeypot with session recording |
| T-Pot |
All-in-one multi-honeypot platform |
| Dionaea |
Malware-capturing honeypot for exploit detection |
| Splunk/Elastic |
SIEM for honeypot alert aggregation |
Output Format
Alert: HONEYPOT-[SERVICE]-[DATE]-[SEQ]
Honeypot: [Hostname/IP]
Service: [SSH/HTTP/SMB/FTP/RDP]
Source IP: [Attacker IP]
Interaction: [Login attempt/Port scan/File access]
Credentials Used: [Username:Password if applicable]
Commands Executed: [For SSH honeypots]
Risk Level: [Critical/High/Medium/Low]
1---2name: implementing-network-deception-with-honeypots3description: Deploy and manage network honeypots using OpenCanary, T-Pot, or Cowrie to detect unauthorized access, lateral movement, and attacker reconnaissance.4license: Apache-2.05---6
7# Implementing Network Deception with Honeypots
8
9## When to Use
10
11- When deploying deception technology to detect lateral movement
12- To create early warning indicators for network intrusion
13- During security architecture design to add detection depth
14- When monitoring for unauthorized internal scanning or credential theft
15- To gather threat intelligence on attacker techniques and tools
16
17## Common Misconfigurations & Verification
18
19Honeypots most often provide false comfort because they are deployed in
20monitor-only mode, are trivially fingerprintable, or sit where no attacker will
21ever reach them:
22
23- **Monitor-only / no alerting:** Cowrie or OpenCanary capture sessions to a
24 local log that nobody reads. Confirm log forwarding to the SIEM (syslog/
25 webhook) actually delivers and a detection rule fires, not just that the file
26 grows.
27- **Fingerprintable deployment:** default Cowrie hostname `svr04`, the canonical
28 T-Pot banner set, or an SSH server that responds too perfectly tips off
29 attackers who then avoid it. Customize banners, hostnames, and filesystem
30 contents away from known defaults.
31- **Placed off the attack path:** a honeypot on an isolated VLAN with no
32 reachable services sees only internet background noise. Place decoys inside
33 segments where lateral movement and internal scanning actually occur, with
34 realistic SSH/SMB/RDP services exposed.
35- **No baseline for noise:** mass scanner traffic drowns real signal; tune out
36 known scanner ranges so a credentialed login attempt stands out.
37- **How to confirm it works:** from a separate host, run an SSH login against
38 Cowrie, an SMB connection and an `nmap` sweep against OpenCanary/T-Pot, and
39 verify each interaction produces a forwarded alert with correct source IP,
40 service, and credentials captured.
41
42## Prerequisites
43
44- Linux server or VM for honeypot deployment (Ubuntu 22.04+ recommended)
45- Python 3.8+ with pip for OpenCanary installation
46- Docker for T-Pot or containerized deployment
47- Network segment with appropriate VLAN configuration
48- SIEM integration for alert forwarding (syslog, webhook, or file-based)
49- Firewall rules allowing inbound connections to honeypot services
50
51## Workflow
52
531. **Plan Deployment**: Select honeypot types and network placement strategy.
542. **Install Honeypot**: Deploy OpenCanary, Cowrie, or T-Pot on dedicated host.
553. **Configure Services**: Enable emulated services (SSH, HTTP, SMB, FTP, RDP).
564. **Set Up Alerting**: Configure log forwarding to SIEM and alert channels.
575. **Deploy Canary Tokens**: Place credential files, shares, and DNS entries.
586. **Monitor Interactions**: Analyze honeypot logs for attacker activity.
597. **Tune and Maintain**: Update configurations based on detection results.
60
61## Key Concepts
62
63| Concept | Description |
64|---------|-------------|
65| OpenCanary | Lightweight Python honeypot with modular service emulation |
66| Cowrie | Medium-interaction SSH/Telnet honeypot capturing commands |
67| T-Pot | Multi-honeypot platform with ELK stack visualization |
68| Canary Token | Tripwire credential or file that alerts when accessed |
69| Low-Interaction | Emulates services at protocol level without full OS |
70| High-Interaction | Full OS honeypot capturing complete attacker sessions |
71
72## Tools & Systems
73
74| Tool | Purpose |
75|------|---------|
76| OpenCanary | Modular honeypot daemon with service emulation |
77| Cowrie | SSH/Telnet honeypot with session recording |
78| T-Pot | All-in-one multi-honeypot platform |
79| Dionaea | Malware-capturing honeypot for exploit detection |
80| Splunk/Elastic | SIEM for honeypot alert aggregation |
81
82## Output Format
83
84```
85Alert: HONEYPOT-[SERVICE]-[DATE]-[SEQ]
86Honeypot: [Hostname/IP]
87Service: [SSH/HTTP/SMB/FTP/RDP]
88Source IP: [Attacker IP]
89Interaction: [Login attempt/Port scan/File access]
90Credentials Used: [Username:Password if applicable]
91Commands Executed: [For SSH honeypots]
92Risk Level: [Critical/High/Medium/Low]
93```
gabrielmoreira