cheesetrap 한국어

SELF-HOSTED HONEYPOT

From attempts
to evidence.

Observe SSH and web attack attempts. Preserve the evidence. Review the report. On your server, under your control.

See how it worksReceived a report?

Automatic reporting is off by default.

OBSERVATION LOG
08:14:02SSH · authentication failed
08:14:07SSH · authentication failed
08:14:12SSH · authentication failed
EVIDENCE / SSHIllustrative example

Repeated login attempts

2026-10-01 · UTC

Observed source
203.0.113.24
Target service
SSH / TCP 22
Time zone
UTC
Supporting evidence
Observed log excerpts
Draft report · awaiting operator review
OBSERVE → PRESERVE → REVIEWPreserve the record. Then review the evidence.
SSHHTTPHTTPS

One server. From observation to report history.

YOUR SERVER. YOUR EVIDENCE.

From an observation to a report.

Reviewing logs, finding evidence, looking up contacts, writing reports. Bring these separate tasks into one workflow.

  1. 01

    Observe the attempts

    Collect SSH logins and web requests. Keep simple connections as observations, without treating every visit as an attack.

  2. 02

    Assemble the evidence

    Group repeated attempts and specific attack indicators by source IP. Look up network registration details and abuse contacts.

  3. 03

    Review the report

    Check the recipient, content and evidence. Approve or exclude a draft. Changed content requires another review.

  4. 04

    Send and keep a record

    Send approved reports through your own SMTP account. Keep acceptance, failure and uncertain outcomes distinct.

BUILT AROUND EVIDENCE

Before a claim,
a record you can check.

When, where, and what happened. Reports bring observed facts and log excerpts together so recipients can review the activity.

  • Source IP, service and observation time together
  • Passwords, tokens and other sensitive values redacted
  • Copies of the evidence used in each report retained
Illustrative example
SSH

Repeated login attempts

Observed source
203.0.113.24
Observation date · UTC
2026-10-01
Log excerpt
08:14:02  SSH  authentication failed
08:14:07  SSH  authentication failed
08:14:12  SSH  authentication failed

Review the repeated attempts alongside the source records.

Received an abuse report?

A cheesetrap report informs a network operator about activity observed by a honeypot. It records behavior from a source IP; it does not identify an individual.

Ask about a report

[email protected]

Check the observation details

Review the source IP, UTC timestamps, target service and port listed in the email.

Compare the evidence with your logs

Use the excerpts and observation window to investigate activity associated with the reported IP.

Reply if you need more context

Reply to the original email and include the report identifier. Please point out errors or details that need clarification.

This page explains the reporting process. It does not ask for your account credentials or passwords.

SELF-HOSTED, BY DESIGN

Your server.
Your evidence.

A tool for individual operators with a dedicated Linux server. Observation and review work without SMTP. Connect your own email account when you are ready to send reports.

Deployment
Docker Compose
Operating scope
One server · one administrator
Administration
Private access by default
Report delivery
Your own SMTP account
Preparing for source release

The repository is currently private. Source code and installation documentation will be linked when the public release is ready.

A few things to know.

Does cheesetrap block attacks?

cheesetrap observes honeypot activity and assembles evidence for reports. It does not automatically block an attack target or connect to the source system to take action.

Is every visiting IP reported?

No. Simple connections remain observations. Report candidates require repeated attempts or specific attack indicators, evidence and a valid contact. Automatic reporting is off by default.

Does sending a report mean action was taken?

Acceptance means the SMTP server accepted the message. It does not guarantee final delivery, reading or action by the network operator. Uncertain outcomes are not automatically resent.

Do installations send their data to a central server?

Each installation runs on the operator's own server and database. A project-wide collection server or shared SMTP relay is not required. Central management of multiple servers is outside the current scope.