Honeypot vs Canary Tokens: 4 Tools, $0 Start [2026]

Honeypot cybersecurity in late October 2026 comes down to a simple choice. You can run a fake machine that attackers poke at for hours, or you can plant one fake credential that raises an alarm the moment someone touches it. Four tools cover that range today: Cowrie, T-Pot, OpenCanary and the commercial Thinkst Canary. The OpenCanary documentation describes its daemon as the free sibling of Thinkst’s paid platform, and that family tree explains most of the trade-offs in this comparison.

This guide compares the four on what decides real deployments: what each tool captures, who maintains it, what it costs, and how its alerts reach your monitoring. If you already run detection stacks such as Wazuh, Security Onion and CrowdSec, you will see exactly where deception fits next to them. I checked each project’s official pages and release listings on October 26, 2026. Where a figure comes from a single third-party page, the text says so.

The short version: start with canary tokens and one OpenCanary host, because they cost almost nothing and produce alerts you can trust. Add Cowrie when you want to study what attackers do after they get a shell. Pick T-Pot when you have a spare machine and an analyst who enjoys reading logs. Buy Thinkst Canary when staff time costs more than the license.

·

Google · Preferred Sources

Don't miss new tech stories on Google

Add Tech Insider once in the Google app and our stories appear in your news suggestions.

Add Now

What Honeypot Cybersecurity Means in 2026

A honeypot is a system built to be attacked. It looks like a server, a router or a database, but no legitimate user has any reason to touch it. Every connection is suspicious by definition, which is the whole trick. Normal security tools hunt for bad behavior inside a sea of good behavior. A honeypot removes the sea.

The vocabulary around it gets muddy fast, so here are the terms this article uses. A honeypot is a decoy service or machine. A honeynet is a group of honeypots wired together with shared logging, which is what T-Pot delivers. A honeytoken is a planted piece of fake data, such as a credential, an API key, a document or a database row. A canary token is a honeytoken that phones home when opened or used. A canary in the Thinkst sense is a decoy device or service that behaves like a tripwire rather than a research trap.

Two goals sit under all of this, and they pull in opposite directions. The first goal is research: let attackers in far enough to learn their tools, passwords and habits. Cowrie and T-Pot serve that goal. The second goal is detection: learn about an intruder inside your network fast and with almost no false alarms. OpenCanary, Thinkst Canary and canary tokens serve that goal. Confusing the two goals is the most common mistake teams make when they first buy or build deception.

Placement matters as much as the tool. A research honeypot belongs on the internet side, where scanners hammer it all day and the noise is the data. A detection canary belongs inside your network, next to the file servers and admin workstations an intruder will probe after landing. A canary on the open internet will fire constantly and teach you to ignore it. A research honeypot buried in your server VLAN gives you a headache and little else. Network sensors like the ones in a Suricata IDS setup watch traffic you already have, while deception creates traffic that should never exist.

The risk profile differs too. Research honeypots deliberately accept hostile sessions, so a misconfigured one can become a launch pad against third parties. Detection canaries accept almost nothing and carry little risk. Keep that distinction in mind through the rest of the comparison, because it drives the maintenance, legal and staffing differences that matter most.

There is also an economics argument. Most detection tools get more expensive as your network grows, because more traffic means more data to ingest, score and store. Deception scales the other way. A tripwire that fires twice a year costs the same to watch as one that never fires, and each alert arrives with a much higher chance of being real. That asymmetry is why even mature security teams keep a few decoys around after they buy bigger platforms.

The Four Contenders at a Glance

The table below lines up the four tools across fifteen attributes. Rows about cost and licensing come from official project pages. Rows about interaction level and placement are my own classification based on how each project describes itself, so treat them as analysis rather than vendor specifications.

Attribute	Cowrie	OpenCanary	T-Pot	Thinkst Canary
Type	SSH and Telnet honeypot	Modular multi-service honeypot	All-in-one multi-honeypot platform	Commercial deception platform
Maintainer	Michel Oosterhof and community	Thinkst Applied Research	Deutsche Telekom Security	Thinkst
Licensing model	Open source, BSD license	Open source	Open source	Commercial subscription
Core stack	Python	Python	Docker Compose with Elastic components	Hosted console plus decoys
Interaction level	Medium (emulated shell)	Low (service tripwires)	Mixed, depends on bundled sensors	Low to medium (decoy services)
Main purpose	Research and attacker study	Intrusion detection	Research and threat telemetry	Intrusion detection
Bundled sensors	One (itself)	One daemon, many selectable services	Several, including Cowrie, Dionaea and Heralding	Hardware, virtual and cloud canaries, plus tokens
Deployment	One self-hosted machine	Any Linux host you control	Dedicated machine running a container stack	Vendor console with decoys you place
Alert path	JSON logs, you build alerting	Logs plus configurable handlers	Elastic dashboards and attack map	Console alerts and documented webhooks
What you learn	Passwords tried, commands typed, files dropped	That something scanned or logged in	Broad attack telemetry across protocols	That a decoy or token was touched, with context
Setup effort	Moderate	Low to moderate	Highest	Lowest
Upkeep	You patch and tune	You patch and tune	You patch the whole stack	Vendor runs the console
False alarm profile	Internet noise by design	Low when placed internally	Internet noise by design	Vendor claims nearly zero
Best placement	Internet-facing research host	Internal VLANs	Isolated sensor network	Internal networks and cloud accounts
Support	Community	Community	Community	Vendor support in subscription
Cost to start	$0 software	$0 software	$0 software	Quote-based subscription

Read the table by purpose first and by feature second. Cowrie and T-Pot sit on the research side and demand analyst time. OpenCanary and Thinkst Canary sit on the detection side and demand placement discipline. Everything else is detail.

One more way to read it: the “what you learn” row is the real product. Cowrie sells you a transcript. OpenCanary sells you a timestamp and a source address. T-Pot sells you a dashboard of the internet’s bad weather. Thinkst sells you a ready-made alert with context attached. Decide which of those four outputs you can actually use, and the rest of the choice follows.

Cowrie: The SSH and Telnet Specialist

Cowrie is a self-hosted honeypot that pretends to be an SSH or Telnet server. The project’s documentation site describes a Python codebase under a BSD license, maintained since 2014. It records brute-force attempts and, if the attacker gets in, everything the attacker types into a fake shell. Michel Oosterhof is the maintainer named in the project material, and the project shows no commercial plans, support tiers or acquisition as of October 26, 2026.

The official documentation includes a sample session that shows why people run it. An attacker logs in, changes into a temporary directory, downloads a binary with wget, marks it executable and runs it. Cowrie logs each step and writes a structured event for the download, including the source address, the URL and a hash of the captured file. The sample uses a documentation-reserved address, so no real victim appears, but the flow matches what internet-facing SSH servers see every day. Analysts who collect samples this way can turn them into detections with the techniques in a guide to writing YARA rules for malware detection.

Release activity and the version question

Cowrie moved quickly this autumn. According to the project’s GitHub release pages, v3.0.15 landed on September 21 with a fix for a shell-parser problem involving pipelines and redirections. Version 3.1.0 followed on October 2, v3.1.1 on October 5 with shell and file-listing fixes, and v3.1.2 on October 12. One non-official page claims a v3.1.3 on October 19, but that claim lacked confirmation from the release page, so treat it as unverified.

There is a wrinkle worth flagging. The project’s current documentation build carries a 3.1.5 development tag, which suggests newer tagged releases may exist beyond the ones I could confirm. Before you deploy, open the releases page and install whatever it marks as latest. The headline for planning purposes is simple: Cowrie is alive, shipping several releases in about three weeks, and not a dormant research project.

What Cowrie does well and where it stops

Cowrie shines at one job: capturing credential stuffing and post-login behavior on SSH and Telnet. Telemetry from it feeds threat intelligence, blocklists and malware sample collection. It is a poor fit if you want an internal tripwire, because a tripwire needs to look like part of your estate and Cowrie advertises itself as a juicy SSH server. It also gives you raw logs, not a console. You write the alerting, the dashboards and the reputation lookups.

Attackers and scanners fingerprint honeypots, so change anything that ships as a default. Set a believable hostname, edit the fake file system so it resembles a real server of the age you want to imitate, and rotate the banner now and then. Nothing will fool a skilled operator forever, but the automated botnets that make up most of the traffic rarely check.

Here is the minimal configuration idea. Move your real SSH daemon to another port, run Cowrie on a high port, and redirect port 22 to it. Check the current documentation for the exact install steps for your release, then confirm the listen setting in the configuration file.

# etc/cowrie.cfg (override file) - confirm option names against the docs for your release
[ssh]
enabled = true
listen_endpoints = tcp:2222:interface=0.0.0.0

# Redirect the public SSH port to Cowrie after moving the real sshd elsewhere
sudo iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 2222

# Pull failed logins out of the JSON log
jq -c 'select(.eventid=="cowrie.login.failed") | {src_ip, username, password}' var/log/cowrie/cowrie.json

OpenCanary: The Lightweight Network Tripwire

OpenCanary is the open-source honeypot daemon maintained under the Thinkst organization on GitHub, where the project is titled a modular and decentralised honeypot. You switch on the services you want it to imitate, such as SSH, FTP, HTTP or SMB file shares, and it logs every connection attempt. Because no real user ever connects to a service that does not exist, every log line is a signal.

The project sits next to the commercial Canary product but is not the same thing. The official documentation states that Thinkst Canary is a separate paid platform and remains a Thinkst product. OpenCanary has no paid tier of its own. Its latest release in the listing I reviewed is v0.9.10 from September 21, which reportedly added limits on Redis buffers and connections plus fixes across several protocol modules. A GitHub workflow run on October 5 showed routine dependency maintenance, which tells you the repository is being looked after.

OpenCanary trades depth for simplicity. It does not give an attacker a convincing shell to play with, so you learn that someone knocked, but not much about what they would have done. For intrusion detection that is the correct trade. You want to know about the knock, quickly, from a machine that looks boring. A single small virtual machine on each sensitive VLAN, each imitating a file server or a legacy device, gives you wide coverage for the price of a few Linux hosts.

Naming and placement decide whether a canary works. Give each host a name that fits your estate, such as a backup server, an old file share or a print host, and put it in the address range where real machines of that type live. Avoid names like “honeypot” or “trap” in DNS. Keep a private register so your own administrators know the decoys exist and do not raise incidents when they trip one during a scan.

Configuration lives in a JSON file. Each service gets an enable flag and a port, and logging handlers decide where alerts go. The sketch below shows the shape. Check the project documentation for the full list of keys, since available modules change between releases.

# Install and generate a starter config
pip install opencanary
opencanaryd --copyconfig

# Edit the generated opencanary.conf, then start the daemon
# Example keys (names follow the project's sample config)
#   "device.node_id": "canary-fileserver-01"
#   "ssh.enabled": true,  "ssh.port": 22
#   "ftp.enabled": true,  "ftp.port": 21
opencanaryd --start

One packaging option exists for teams that avoid self-hosting. A third party lists an OpenCanary image on the AWS Marketplace for $100 per month, excluding AWS infrastructure charges. That price buys a prebuilt image and support from the seller, not a change to the software, which stays free. For most readers, a hardened Linux VM is cheaper and teaches more.

T-Pot: The All-in-One Honeynet Platform

T-Pot, maintained by Deutsche Telekom Security under the repository name telekom-security/tpotce, bills itself on GitHub as the all-in-one multi-honeypot platform. It bundles many honeypots, including Cowrie for SSH and Telnet, Dionaea for malware capture and Heralding for credential harvesting. It runs them with Docker Compose and feeds the output into Elastic components and an attack-map dashboard. In other words, T-Pot is Cowrie’s big sibling: the same research mindset, packaged as a ready-made sensor with visualization.

The repository stays active. The separate T-Pot Attack Map project released version 4.0.0. According to that release, the map dropped its CARTO raster dependency in favor of an offline vector basemap, which removes third-party requests at runtime and the need for an API key. The same release documented pinned dependencies and integrity locking, a sensible move for a tool that sits on hostile networks. I could not confirm a dated T-Pot platform release number for October, so I will not name one. One third-party page mentions a tagged 24.04.1 release without establishing that it is current.

T-Pot wins on breadth. A single install gives you SSH, Telnet, malware drop sites and credential traps in one place, and the dashboards make trends visible without custom work. It loses on weight. You run a container stack that stores and indexes a lot of data, you patch all of it, and you have to decide what to do with the mountain of internet noise it records. If you want to see how Elastic-based tooling compares with other log platforms, the Wazuh, Elastic and Graylog comparison covers the storage and licensing angle.

Treat T-Pot as an appliance. Give it its own machine, its own network segment and its own firewall rules that block outbound traffic except for what it needs. Do not install it next to production workloads, and do not expect it to find an intruder inside your office network. It answers a different question: who is attacking the internet right now, and with what.

Teaching labs are a natural fit. Students get a live feed of real attack traffic with no risk to production, and instructors get a repeatable setup. For that purpose alone it earns its place in the comparison, even if it never touches your defensive stack.

Thinkst Canary and Canarytokens: The Commercial Tripwire

Thinkst Canary is the polished end of the market. Thinkst sells it as a commercial deception platform built from decoy devices managed through a hosted console. Its own site lists hardware, virtual, and cloud and container canaries, and a Canarytokens capability for planting fake documents, keys and links. The company’s homepage claims setup takes about two minutes and promises “nearly 0 false positives”, which is a vendor claim rather than an independent measurement. Product status looks healthy: no rename, retirement or acquisition turned up in my review, and the documentation was updated several times in early October.

Alert delivery is where the commercial product earns its price. Thinkst documents webhook events for Splunk and a generic format, and the sample payloads show the style. One example reports an FTP login attempt against a named canary at a private address. Another reports a web-bug canarytoken triggered from an external address, with background context noting earlier incidents from the same source. That “you have seen this source before” line is the kind of small touch that saves an analyst five minutes per alert.

Pricing is where reports diverge, so read this paragraph with care. Thinkst does not publish a simple price table on the pages I reviewed. A third-party comparison dated October 3 reports $7,500 per year for five canaries, covering hardware, virtual or cloud units, unlimited tokens on a private token server, an AWS-hosted console and a year of support and updates. The same research reports additional canaries at $800 per year each. By that report, the starter bundle works out to roughly $1,500 per decoy. Another third-party page from October 7 describes the virtual and cloud canaries as beta, which conflicts with Thinkst’s own listing, so ask Thinkst for current terms before budgeting.

A public procurement listing seen between October 16 and 26 describes a one-year Thinkst Canary subscription and calls the product a hardware-less deception platform. A buyer like that likely values vendor support over self-hosting. Free hosted tokens exist too. A third-party article dated October 6 describes canarytokens.org as a free service operated by Thinkst and separate from the commercial platform, which makes it the cheapest first experiment in this entire article.

Canaries also complement the intelligence side of security work. Alerts from decoys tell you who is inside, and platforms like those in this roundup of threat intelligence platforms tell you what that actor usually does next. Pairing the two turns a lonely alert into a story.

Honeypot vs Canary Token: Where the Line Falls

The cleanest way to separate the categories is to ask what the defender wants from the interaction. A honeypot invites a conversation. A canary token wants a single sentence. Deception practitioners have been explaining this for years, and two voices sum it up well.

Lance Spitzner, founder of the Honeynet Project, argues in a recorded interview that deception only works under one condition: “I’ve always said for deception to really work the bad guy has to interact with your technology, has to consume the information or the output from that interaction, and then they have to act on it.” He also pushes back on the idea that deception needs deep budgets: “You can start really, really, really simple: just put a very simple basic system on your network and see if anything starts interacting with it.” And on tokens: “You can sprinkle a couple of honey tokens, you know, URLs, fake login accounts. I mean, you don’t even need fancy technology.”

The deception company Tracebit draws the same boundary from the product side in its history of canaries. Its framing for tokens is blunt: “A honeytoken is not a host. It is a piece of planted fake data like a credential, a file, a database record, or an API key that sits quietly inside a real system and reports the moment anyone uses it.” On when you can skip the fake machine entirely, Tracebit writes: “If the whole value of the decoy is the alert that fires when something touches it, you do not need a fake system at all. You need one planted thing that alerts the instant it is touched.”

Put those two views together and a practical rule appears. If you want to study an attacker, you need the attacker to keep talking, so you need a honeypot with a believable shell. If you want to catch an attacker, you need the first touch, so a token or a thin canary service is enough. Most organizations need the second goal far more than the first. Research honeypots feed the wider community and your own blocklists, while tokens protect your actual estate.

Tokens also reach places honeypots cannot. A fake AWS access key in a configuration repository, a decoy spreadsheet named like payroll data on a file share, or a fake database record fires on use no matter where the stolen data travels. No honeypot server can watch a credential that left your network. Phishing awareness programs, such as the simulation workflow in a GoPhish setup guide, test people. Tokens test the attacker.

Where should tokens go first? Think about what a thief grabs in the first ten minutes after landing on a laptop or server. Cloud credential files, SSH keys, browser-saved logins, “passwords” spreadsheets and source repositories top the list. Seed each of those with a believable fake, and give every fake a unique identity, so the alert tells you exactly which location was raided. A token that cannot tell you where it was found is only half a token.

Evidence Check: What the Data Shows and What It Does Not

Readers often ask for benchmarks. For honeypots, a fair answer starts with a limitation: the research behind this article found no independent head-to-head benchmark of Cowrie, OpenCanary, T-Pot and Thinkst Canary. Deception tools do not have frames-per-second or tokens-per-second numbers. What exists is a mix of release activity, vendor claims and third-party listings. I used three kinds of evidence and label each one.

Source one: project release activity. GitHub release pages show how each project behaved over the past few weeks. Cowrie shipped v3.1.0 on October 2, v3.1.1 on October 5 and v3.1.2 on October 12. OpenCanary’s latest tagged release is v0.9.10, and it logged dependency maintenance on October 5. The T-Pot repository showed updates in October and the Attack Map project shipped version 4.0.0. All four ecosystems show life, and none show abandonment.

Source two: vendor claims. Thinkst claims quick setup and “nearly 0 false positives”. Those claims are plausible for a tripwire design, because nothing legitimate should touch a decoy, but they are marketing until a customer measures them in their own network. Open-source projects make fewer promises. Cowrie documents what it records, and OpenCanary documents which modules exist.

Source three: third-party listings. The AWS Marketplace image at $100 per month, the October 3 price comparison and the October public procurement listing give a sense of what the market pays. Review roundups, including a deception technology review published by Cyberpress on October 22, group these tools under one heading, but roundups rarely test them side by side.

What should a buyer conclude? Measure with your own data. Run a two-week pilot, count alerts, count how many needed action, and divide. A canary that fires twice a month with both alerts real beats a honeypot that fires ten thousand times with none actionable. That ratio, actionable alerts per week of analyst time, is the only benchmark that matters here. For wider context on detection tooling, the cybersecurity category collects the comparisons and setup guides that sit around deception.

Pricing and Total Cost of Ownership

Software costs for three of the four tools are zero. That makes the license column nearly useless for ranking, so the table below adds the costs that actually bite: hosting, storage and people.

Tool	Software cost	Extra costs to plan for	Basis
Cowrie	$0 (BSD license)	One host or VPS, log storage, your time to build alerting	Project documentation
OpenCanary	$0	One small VM per network segment, optional $100 per month third-party AWS image (AWS charges excluded)	Project docs and AWS Marketplace listing
T-Pot	$0	Dedicated machine for the container stack, storage for indexed logs, analyst time for tuning	Project repository
Thinkst Canary	Commercial subscription, quote-based	Decoy placement time, token planning, written quote to confirm unit availability (see text for one third-party estimate)	Vendor site
Build-your-own tokens	$0	Your time to plant, document and monitor each token	Analysis

Staff time dominates every column. A free tool that needs three hours a week of tuning costs more over a year than a paid platform that needs fifteen minutes. Put your analyst’s loaded hourly rate against the subscription before you call anything cheap. Small teams with no spare hours should lean toward the vendor. Larger teams with an engineer who likes tinkering can run OpenCanary across dozens of segments for the cost of virtual machines.

Watch the hidden costs on research honeypots. Cowrie and T-Pot log everything, and logs grow. Decide on retention before you deploy, because a honeynet left alone can fill a disk with scanner noise. Budget for a log pipeline too. If you do not already forward events to a SIEM, the sections below show what that costs in effort.

Real-World Examples: Five Deployments and Alerts

Abstract comparisons only go so far, so here are five concrete cases drawn from public documentation and listings. I mark which are documented samples and which are real procurements.

1. Cowrie’s documented attack session. The official docs show a login, a wget download of a file named x86 from a documentation-reserved address, a chmod and an execution attempt. Cowrie’s JSON event for the download carries the source IP, the URL, a hash and a session ID. This is a documentation sample, but it mirrors typical botnet droppers, and it shows how malware samples reach analysts.
2. Thinkst’s FTP login alert. The webhook documentation includes a sample reporting an FTP login attempt against a canary at a private address, with a note that the same source had prior incidents. A real-world analog is a compromised workstation sweeping the local subnet for file servers.
3. Thinkst’s web-bug token alert. A second documented payload reports a web-bug token triggered from an external address along with the browser user agent. A planted document opened by a thief produces exactly this kind of record.
4. A public procurement of Thinkst Canary. A listing seen October 16 to 26 describes a one-year subscription and labels the product hardware-less. It is a real purchase signal, and it shows buyers choosing a managed platform over self-hosted sensors.
5. A telecom-maintained honeynet. Deutsche Telekom Security maintains T-Pot, and its repository shows the Docker, Elastic and attack-map design that other organizations copy. NxtFireGuard published a T-Pot integration guide earlier this year, which shows how service providers feed honeynet data into their own threat sensors.

Two more patterns come from practice rather than any one document. First, runtime tripwires inside containers complement honeypots, and the Falco runtime security setup shows one way to detect odd process behavior where a canary cannot go. Second, cloud credentials make superb tokens. A fake access key placed in a repository or a build server fires loudly the moment anyone tries it, and the alert arrives from the cloud provider’s logs, not from a server you operate.

Here is a scenario to make the choice tangible. A 40-person software company has no security staff. An attacker steals a developer laptop and tries to reach the file server. A single OpenCanary VM on the office network, imitating a file share, logs the attempt within seconds. A fake credentials file in the developer’s home directory would have fired the moment the attacker used it. Total spend: a small VM and an afternoon. This is a hypothetical, but every component is documented above.

Use-Case Recommendations: Six Situations

Match the tool to the job, not the other way around. The table gives the picks, and the paragraphs after it explain the reasoning.

Situation	Pick	Why
Small team, no security staff	Thinkst Canary or hosted tokens	Lowest setup and upkeep, alerts arrive ready to read
Detect lateral movement on a budget	OpenCanary plus tokens	Cheap internal tripwires with few false alarms
Study SSH brute-force campaigns	Cowrie	Captures credentials, commands and dropped files
Broad threat telemetry and teaching	T-Pot	Many sensors and dashboards in one install
Protect cloud credentials and repos	Canary tokens	Fire on use anywhere the secret travels
Public-sector or regulated buyer	Thinkst Canary	Vendor support, procurement-friendly subscription

Small team, no security staff. Skip self-hosting. Either pay for the commercial product or begin with free hosted tokens and expand later. Your scarce resource is attention, so choose the option that sends you an alert you can act on without a lab.

Lateral movement on a budget. OpenCanary on each sensitive segment, with tokens on the file shares and in code repositories, gives you coverage at the cost of a few small hosts. Name the canaries to match your estate, such as a backup server or a print host, so they look like targets.

SSH brute-force research. Deploy Cowrie on an isolated cloud instance with no trust relationship to your network. Forward its JSON logs to a collector and publish the indicators your firewall can block. This is the classic honeypot cybersecurity workflow, and it still pays off.

Broad telemetry and teaching. T-Pot gives students and junior analysts a live, safe feed of attacks. Give it a dedicated machine, and keep outbound access tight.

Cloud credentials and repositories. Tokens beat everything else here. A decoy key in a place where only a thief would find it never produces a false alarm from ordinary staff. Document every token in a private register so your own team does not trip them during audits.

Regulated buyers. If an auditor wants vendor support, an SLA and a clear owner, the commercial platform answers those questions. Open-source tools can pass audits too, but you document more yourself.

A sensible first month looks like this:

1. Week one: list the five places an intruder would loot first, then plant a uniquely labeled token in each.
2. Week two: place one canary host or OpenCanary VM in each sensitive network segment, named to fit the neighborhood.
3. Week three: route every decoy alert to a channel a human reads within minutes, and write a one-page response playbook.
4. Week four: test every decoy yourself, record how long each alert took to arrive, and fix gaps before declaring victory.

Alert Pipelines and Safe Deployment

A honeypot that nobody reads protects nothing. Route every alert to a place a human already watches. For the open-source tools, that usually means a SIEM or a chat webhook. The Wazuh agent can ingest Cowrie’s JSON log directly, as the snippet below shows, and a walkthrough such as Wazuh SIEM setup with Docker covers the server side.

<!-- ossec.conf on the Cowrie host: read the JSON event log -->
<localfile>
  <log_format>json</log_format>
  <location>/home/cowrie/cowrie/var/log/cowrie/cowrie.json</location>
</localfile>

Once events flow in, write detection rules around them. Vendor-neutral rule formats help here, and the guide to writing Sigma rules shows how to express “any session that downloads a file” or “any login on a canary host” once and convert it for several platforms. Treat canary alerts as high severity by default. If your SIEM scores them like routine events, you have misconfigured the pipeline.

Teams already running Splunk or Elastic can compare the cost of adding a new log source using the Splunk, Wazuh and Elastic Security comparison. Canary events are tiny, so ingest cost is rarely the issue. Research honeypots are the heavy sources.

Safety rules for research honeypots

Follow these guardrails before you expose anything. Put research honeypots on a separate network with no route to production. Block or tightly rate-limit outbound traffic, so a compromised decoy cannot attack other people. Never store real credentials, real customer data or real keys on a decoy. Check local law and your hosting provider’s terms, because some providers prohibit hosting intentionally vulnerable systems. Keep a clean-rebuild script, since a honeypot that an attacker fully controls is only a liability. For high-interaction setups, involve legal counsel before you capture attacker communications.

Canary deployments need a different kind of care: documentation. Record where every token and decoy sits, who owns it and what the response playbook says. A tripwire that fires with no runbook wastes the speed it gave you. Review the register every quarter, remove decoys for retired systems, and retest a sample to confirm alerts still reach a human.

Migration Guide: Moving From One Deception Tool to Another

Few teams pick the perfect tool on day one. Here are the migrations that come up most often and how to run each without losing coverage.

From nothing to tokens and OpenCanary. Week one, plant tokens in the three places a thief reaches first: a cloud-credentials file, a shared drive and a source repository. Week two, deploy one OpenCanary VM per sensitive segment and wire its log to your alert channel. Week three, run a controlled test by touching each decoy yourself, and confirm every alert lands with the right severity. Document the register of decoys.

From OpenCanary to Thinkst Canary. This path suits teams that outgrow hand-managed VMs. The two share design ideas, so your naming scheme and placement plan carry over. Pilot the commercial product on one segment while OpenCanary keeps running on the rest. Compare alert quality for a few weeks, then retire OpenCanary hosts segment by segment. Keep the old log pipeline until the new webhook integration has proven itself, and ask Thinkst about the status of virtual and cloud units, given the conflicting beta reports.

From Cowrie to T-Pot. T-Pot already bundles Cowrie, so this migration is mostly about moving your analysis habits. Export your Cowrie logs and any indicator lists first. Stand up T-Pot on a separate machine, point your public SSH redirect at the new sensor and run both in parallel for a week. Check that your blocklist feeds pick up the new log format. Expect the data volume to jump, so set retention rules on day one.

The reverse direction. Leaving T-Pot for a slimmer setup is common once the novelty fades. Keep Cowrie as a single sensor if SSH is the traffic you care about, and move your internal detection to OpenCanary or a commercial platform. You lose the dashboards but gain a smaller attack surface and less to patch.

Pros, Cons and the Verdict

Tool	Pros	Cons
Cowrie	Deep SSH and Telnet capture, free, actively released this autumn	Logs only, no console, needs isolation and tuning
OpenCanary	Free, light, good internal tripwire, quick to deploy	Shallow interaction, you manage patches and alert routing
T-Pot	Many sensors and dashboards in one install, backed by Deutsche Telekom Security	Heavy to run, lots of noise, dedicated machine needed
Thinkst Canary	Fast setup claims, console, documented webhooks, vendor support	Paid, quote-based, conflicting reports on pricing and beta features

The verdict. For most organizations, the best first move in honeypot cybersecurity is not a honeypot at all. It is a handful of canary tokens, followed by one OpenCanary host in each sensitive network segment. That combination costs close to nothing, produces few false alarms, and catches the thing that matters most: an intruder already inside. Spend your first month there.

Add Cowrie if you have internet-facing SSH and want to see what hits it. Add T-Pot only if you have a spare machine, a person who enjoys reading logs, and a reason to want broad telemetry, such as training or threat research. Choose Thinkst Canary if the numbers favor it: one third-party report puts five decoys at $7,500 per year, so the purchase makes sense once the analyst hours you would spend on self-hosting cost more than that. Confirm prices and unit availability with the vendor, since the figures I found came from outside sources.

One last thing worth remembering from the practitioners quoted earlier: complexity is optional. Both Spitzner and Tracebit argue that a simple decoy or a single planted credential is often enough. Start small, measure alerts, and grow only when the data tells you to.

Frequently Asked Questions

What is a honeypot in cybersecurity?

A honeypot is a decoy system that imitates a real server or service so defenders can detect and study attackers. Because legitimate users have no reason to touch it, any connection is suspicious. Cowrie, OpenCanary and T-Pot are open-source examples.

What is the difference between a honeypot and a canary token?

A honeypot is a fake system that invites a longer interaction, which is useful for research. A canary token is a piece of planted fake data, such as a credential or document, that alerts the moment someone uses it. Tokens detect, honeypots study.

Is OpenCanary the same as Thinkst Canary?

No. OpenCanary is the free open-source daemon maintained in Thinkst’s GitHub organization. Thinkst Canary is the separate paid platform with a hosted console, hardware, virtual and cloud canaries, and Canarytokens.

Which honeypot is best for beginners?

Free hosted canary tokens and a single OpenCanary virtual machine are the gentlest starts. T-Pot is easy to install conceptually but heavy to operate, and Cowrie needs log handling skills.

Is it legal to run a honeypot?

Running a honeypot on systems you own is generally lawful, but rules differ by country and hosting provider. Avoid collecting more personal data than needed, block outbound abuse, and ask a lawyer before capturing communications in a high-interaction setup. This is general information, not legal advice.

How much does Thinkst Canary cost?

Thinkst sells by quote and does not publish a simple price list on the pages I reviewed. Third-party estimates exist, but they can lag behind current terms, so request a written quote that states unit counts, token limits and support length.

Can a honeypot be used against me?

Yes, if you build it carelessly. A poorly isolated research honeypot can serve as a foothold or a launch pad. Isolate it from production, restrict outbound traffic, store nothing real on it, and rebuild it from a clean image on a schedule.

Do honeypots replace EDR, SIEM or an IDS?

No. Deception adds a high-confidence alert layer on top of those tools. It catches intruders who evade signature-based detection, but it does not block attacks, patch systems or give you full visibility.