Honeypot deployment: choosing, placing and monitoring honeypots safely

A honeypot only earns its place if it is somewhere an intruder will look, convincing enough to touch, wired to an alert someone will act on, and contained so it cannot be turned against you. Most honeypot projects fail on one of those four, usually the last two: a decoy is installed, nobody watches its logs, and months later it is either forgotten or quietly forwarding traffic for someone else. This guide is the deployment manual: choosing a honeypot for a stated goal, placing it in the network, building the host safely, connecting it to the SOC, tuning and maintaining it, and measuring whether it works. It is for SOC engineers, detection engineers and network security teams. For the wider picture of deception, including honeytokens and decoy credentials, start with the Deception Technology Guide; this page goes deeper on honeypots alone. Sources were checked on 8 November 2026.

Key takeaways

• Decide the goal before the product. Internal breach detection and internet threat research need different honeypots, placements and alert handling.
• Internal honeypots should be silent. Nothing legitimate should connect to them, so every connection is worth a look and the false positive rate can be near zero once scanners are excluded.
• Placement beats realism. A simple decoy in the server subnet an attacker will scan catches more than a perfect replica in a corner nobody reaches.
• Contain every honeypot as if it will be compromised. Deny outbound traffic except logging, keep management separate and store no real data on it.
• An unmonitored honeypot is a liability. Send events to the SIEM, write a triage playbook and test the alert path regularly.

Start from the goal

Write one sentence stating what the honeypot is for. It decides almost everything else.

For most enterprise security teams the first two rows are the right start. Internet-facing honeypots see constant opportunistic scanning; that is useful intelligence, but it is not a breach alarm and it should not page the on-call analyst.

Choosing a honeypot

Open-source honeypots cover most needs. Three open-source projects illustrate the main options; they are listed alphabetically, and features come from each project's own documentation.

• Medium to high interaction SSH and Telnet (Cowrie): in its default shell mode it emulates a UNIX system with a fake filesystem, records sessions in a format that can be replayed with its playlog utility, saves files fetched or uploaded by the attacker for inspection, and writes JSON audit logs. Proxy mode places Cowrie in front of a real or emulated system for higher interaction. Suited to capturing brute force and post-login behaviour in an isolated network.
• Low interaction, many services (OpenCanary): a daemon whose JSON configuration file (/etc/opencanary/opencanary.conf, generated with opencanaryd --copyconfig) enables emulated services one by one through keys such as ssh.enabled, http.enabled, mysql.enabled, mssql.enabled, rdp.enabled, vnc.enabled, redis.enabled, snmp.enabled and tftp.enabled. The smb and portscan modules are log watchers that rely on Samba audit logs and iptables respectively. Each instance carries a device.node_id, and an ip.ignorelist excludes known scanners. Logging handlers include file, syslog, JSON over TCP, SMTP and webhook. Suited to internal tripwires.
• Multi-honeypot platform (T-Pot): runs many honeypots in containers with an analysis front end. A standard or hive installation needs 16 GB RAM and a 256 GB SSD, and sensors 8 GB RAM and 128 GB; a distributed design has sensors forwarding to a hive. Management runs on high ports (64294 for sensor data, 64295 for SSH, 64297 for the web interface). It submits captured data to a community backend by default, which is removed by editing the ewsposter section of its compose file. Suited to internet-facing research.

Commercial deception platforms add central management, automatic decoy generation and integrations; the Deception Technology Buyer's Guide covers how to evaluate them. Whatever you choose, check that it can send structured events to your SIEM, can be patched easily and can run on a host you can contain.

Placement design

Place honeypots where an intruder's discovery and lateral movement will touch them. The relevant ATT&CK techniques tell you what to expect: T1046 Network Service Discovery, T1018 Remote System Discovery and T1135 Network Share Discovery during reconnaissance, then T1110 Brute Force and T1021 Remote Services when moving on.

Practical placement rules:

• Look like a neighbour: use hostnames, banners and operating system fingerprints that match the real systems around the decoy. A Linux banner in an all-Windows server range stands out.
• Use real addresses in real ranges: put the decoy in the same subnet as production assets, not in a dedicated "honeypot VLAN" an attacker can identify from routing.
• Cover each segment once before adding depth: one decoy in every important segment beats five in one.
• Register it, quietly: record each honeypot in a restricted register so asset owners, vulnerability scanners and new staff do not mistake it for a forgotten server.

Segmentation and honeypots support each other: segmentation forces an intruder to explore, and decoys in each segment catch that exploration. See the Network Segmentation and Microsegmentation Guide.

Building the host safely

T-Pot's own documentation states that a compromise cannot be ruled out and that honeypots should not hold sensitive data. Design every honeypot on that assumption.

1. Dedicated host or virtual machine: never co-host a honeypot with production services or on a shared container host.
2. Deny outbound by default: allow only log forwarding to the collector and, if needed, update traffic to named repositories. An internet-facing research honeypot must not be able to reach other internet hosts in a way that harms third parties.
3. Separate management: administer over a separate interface or high port reachable only from a management network, with its own credentials and multi-factor authentication.
4. No real credentials or data: no domain-joined service accounts, no cached administrator logons, no copies of real files. Use synthetic content only.
5. Harden the real host underneath: patch the operating system and honeypot software, run the honeypot as an unprivileged user, and keep emulated services separate from the host's real SSH.
6. Forward logs off the box: an attacker who controls the honeypot can erase local logs, so stream events to the SIEM in real time.
7. Check data sharing settings: turn off any community data submission unless you have approved what is shared.

Honeypot logs contain IP addresses, usernames tried and sometimes typed content, so apply your data protection and retention rules to them like any other security log.

Connecting to the SOC

The alert path is the product. Plan it before the first decoy goes live.

• Structured events: ingest JSON events (OpenCanary's JSON handler, Cowrie's JSON log) with source address, destination service, username tried and node ID as parsed fields.
• Severity by location and action: a TCP connection to a user-segment decoy is medium; an authentication attempt on a management-segment decoy is high; a successful login on a medium-interaction honeypot followed by commands is critical.
• Enrich with the source: resolve the source address to an asset, its owner and the logged-on user, so the analyst starts with "which machine is this" answered.
• Triage playbook: confirm the source is not an authorised scanner, check the source host's endpoint telemetry, look for the same source touching real systems, and escalate to incident response if unexplained.
• Heartbeat: alert when a honeypot stops sending events or health checks. A silent internal honeypot and a dead one look the same unless you check.

Usernames attempted on a decoy are useful: if a real account name appears, that account may be targeted or already compromised elsewhere. Pair honeypots with decoy credentials for this reason; see the Honeytokens and Canary Credentials Guide.

Rollout, testing and tuning

1. Pilot one segment: deploy one low-interaction decoy in a server subnet with alerts going to a test queue.
2. Baseline for two to four weeks: record every connection. Expect vulnerability scanners, monitoring tools, asset discovery and backup agents.
3. Exclude known sources by name: add authorised scanners to the ignore list and document each exclusion, including who owns it. Too many exclusions create a blind spot an attacker can use from a scanner host.
4. Test the alert path: from an approved test host, connect to the decoy and attempt a login, then confirm the SIEM alert, enrichment and ticket all arrive. Repeat monthly.
5. Move to live alerting, then expand: route to the SOC, then add decoys segment by segment.
6. Rollback: if a honeypot causes operational issues (such as an emulated service answering broadcast discovery), disable that service in configuration or shut the host down; nothing depends on a decoy.

Refresh realism periodically: update banners and hostnames when the surrounding estate changes, rotate fake file contents, and rebuild long-running internet-facing honeypots so their fingerprints do not become well known.

Decision guidance

• Small organisations: two or three low-interaction decoys in the server and management networks, sending to existing log tooling, give useful detection at little cost. Skip internet-facing research honeypots.
• Large or segmented estates: a decoy per important segment and cloud virtual network, central configuration management, and a standard triage playbook. Consider a commercial platform once manual upkeep becomes the bottleneck.
• High interaction: only with a team that can analyse what it collects and maintain strong containment. Without both, it adds risk and little value.
• Regulated or OT environments: agree placement and emulated protocols with system owners first, and never place decoys that answer industrial protocols on live control networks without testing.

Measuring whether it works

• Coverage: share of important network segments and cloud networks with at least one decoy.
• Alert path test pass rate: monthly synthetic tests that produce a correctly enriched SOC alert.
• Time to triage: from honeypot event to analyst decision, which should be short because the signal is high.
• Unexplained hits: connections not traced to an authorised source; each should end in an investigation outcome.
• Honeypot health: share of decoys reporting heartbeats in the last 24 hours.
• Purple team detection: whether internal reconnaissance in exercises touched a decoy and raised an alert.

Framework mapping

Common failure patterns

• Nobody is watching: events land in a local log file or an unmonitored index, and the first hit goes unseen.
• Dead decoy, silent dashboard: the honeypot stopped months ago and no heartbeat alert noticed.
• Exclusion creep: every noisy source is ignored until a large part of the network can touch the decoy without an alert.
• Weak containment: an internet-facing honeypot with open outbound access is used to attack third parties.
• Obvious decoys: a dedicated honeypot VLAN, default banners or default hostnames identify the decoy at a glance.
• Real data on the decoy: copied production files turn a fake target into a real data exposure.

Practitioner checklist

• Write the goal of each honeypot and choose interaction level and placement from it.
• Place at least one decoy in each important server, management and cloud network segment, using real address ranges.
• Match hostnames, banners and services to the systems around each decoy.
• Run each honeypot on a dedicated host with outbound traffic denied except log forwarding.
• Keep management on a separate interface with its own credentials and multi-factor authentication.
• Store no real data or credentials on any decoy and turn off unapproved data sharing.
• Stream structured events to the SIEM, enrich them with asset and user context, and alert on missing heartbeats.
• Document every ignore list entry with an owner, and review the list quarterly.
• Test the alert path monthly from an approved host and keep a triage playbook current.

Standards and references

• NIST: SP 800-53 Rev. 5 (SC-26 Decoys)
• MITRE D3FEND: Integrated Honeynet
• MITRE D3FEND: Decoy Network Resource
• MITRE ATT&CK: Network Service Discovery
• NIST: Cybersecurity Framework 2.0
• OpenCanary: Configuration
• Cowrie: Documentation
• Deutsche Telekom Security: T-Pot

Related NHI Mgmt Group resources: Deception Technology Guide · Honeytokens and Canary Credentials Guide · Deception Technology Buyer's Guide · Detection Engineering Guide · Active Directory Security Monitoring Guide