Honeypots

A honeypot is a decoy, not a counterattack. It exposes a service that legitimate users should not need, so interaction can create a high-signal alert. It does not replace patching, endpoint monitoring, segmentation, or incident response.

Safe design rules

• Put the decoy in a dedicated account, project, network segment, or tightly controlled subnet.
• Give it no production credentials, customer data, mounted secrets, trusted keys, or administrative path.
• Deny or tightly restrict outbound traffic so a compromised decoy cannot attack other systems.
• Send alerts and logs to a separate trusted system that the decoy cannot modify.
• Use an intentionally fictional server identity. Do not copy real documents or personal data.
• Obtain security, legal, privacy, and network-owner approval before exposing or recording traffic.
• Define how to isolate, preserve, rebuild, and retire the decoy.

Quick OpenCanary lab

OpenCanary can emulate services and send an alert when they are used. Start in a disposable lab network—not on a production host.

python3 -m venv /opt/opencanary/venv
sudo /opt/opencanary/venv/bin/pip install --upgrade pip opencanary
sudo /opt/opencanary/venv/bin/opencanaryd --copyconfig

Edit the generated configuration to set a unique device.node_id, enable only the decoy services you intend to monitor, and send alerts to a protected destination. Validate the JSON and start in the foreground first:

sudo jq . /root/.opencanary.conf
sudo /opt/opencanary/venv/bin/opencanaryd --dev

Paths vary by the service account and packaging method. Follow the current OpenCanary getting-started guide, pin an approved version, and manage the final process with a reviewed system service or container definition.

Network policy

The safest useful pattern is:

untrusted or monitored network
        │
        ▼
decoy subnet ── alerts ──▶ protected log collector
        │
        └── outbound: deny by default

production networks: no route or explicit deny

If the decoy needs DNS, time synchronization, updates, or an alert webhook, allow only those named destinations through a controlled egress path. Do not grant broad internet access.

Test before trusting it

From an authorized test host:

1. Connect once to an enabled decoy service.
2. Confirm the expected event reaches the central collector.
3. Confirm the alert identifies the decoy, source, destination, service, and time.
4. Verify the on-call route and runbook link.
5. Confirm the decoy cannot reach production or arbitrary internet destinations.
6. Rebuild the decoy from its approved definition.

Triage an alert

Treat interaction as suspicious, not automatically malicious. Check whether the source is an approved scanner, a configuration mistake, an internal host, or an external address. Then correlate identity, DNS, flow, firewall, and endpoint events around the same time.

Escalate when the source is internal, multiple decoys are touched, the behavior follows a deliberate sequence, production systems show related activity, or the decoy attempts unexpected outbound communication.

Operate it like a security sensor

• Keep ownership, patching, alert testing, and expiry dates in the asset inventory.
• Measure alert-delivery failures and sensor silence.
• Rotate the decoy personality when it no longer represents a useful detection opportunity.
• Rebuild after confirmed compromise; do not treat the decoy as a trusted forensic workstation.
• Retire unused decoys so they do not become forgotten internet-facing assets.

References

• OpenCanary documentation
• NIST SP 800-61 Rev. 3: Incident Response