A honeypot is a deliberately exposed, fake service designed to attract and detect attackers — any interaction with it is inherently suspicious, since no legitimate user should ever access it, providing an early, high-confidence warning signal.
What a Honeypot Actually Does
Rather than trying to distinguish legitimate from malicious traffic on your real services (inherently noisy), a honeypot is a decoy that has no legitimate traffic at all — any interaction is, by definition, unauthorized probing or an actual attack.
Common Honeypot Use Cases
- Detecting reconnaissance/scanning activity before it reaches your real services
- Gathering intelligence on attack patterns and techniques being used against your infrastructure
- An early-warning tripwire for network intrusion
Simple Approach: A Fake SSH Honeypot
Several open-source SSH honeypot tools simulate a vulnerable SSH server, logging all connection attempts and interaction — deploy on a port that shouldn't legitimately receive traffic, distinct from your real SSH port.
Basic Setup Example
docker run -d \
--name ssh-honeypot \
--restart unless-stopped \
-p 2222:2222 \
cowrie/cowrieCowrie is a well-known SSH/Telnet honeypot that logs attacker commands and interaction attempts in detail.
Placing the Honeypot Strategically
Deploy on a port that might attract automated scanners (common alternate SSH ports attackers try) while your genuine SSH service runs on a different, non-default port (see SSH Hardening: Change the Port, Disable Root Login & Use SSH Keys) — anyone hitting the honeypot port is exhibiting scanning/attack behavior.
Alerting on Honeypot Activity
tail -f /var/log/cowrie/cowrie.log | grep "login attempt"Integrate honeypot logs with your alerting system (see How to Set Up Effective Server Alerting) — since any activity is inherently suspicious, alert thresholds can be much more sensitive than for your real services' logs.
Using Honeypot Data to Improve Real Defenses
Analyze captured attack patterns/techniques from your honeypot to inform hardening of your actual production services — if you see specific exploit attempts or credential patterns, verify your real services are protected against the same techniques.
Web Application Honeypots
Beyond SSH, similar honeypot concepts exist for web applications (fake admin panels, fake vulnerable endpoints) — useful if you want to specifically detect web-focused reconnaissance and attacks.
Important: Isolate the Honeypot
Run your honeypot in an isolated environment (a separate container or VM) with no access to your actual production systems or data — a compromised honeypot should never provide a pivot point into your real infrastructure.
Realistic Expectations
A honeypot is a detection tool, not a prevention mechanism — it tells you attackers are probing (valuable intelligence), but doesn't stop them from also attacking your real services directly; deploy alongside, not instead of, genuine security hardening.
Common Errors
Honeypot generates no activity at all — verify it's genuinely reachable (not blocked by an overly restrictive firewall rule), since it needs some exposure to attract the scanning/attack traffic it's meant to detect.
Continue Reading
- SSH Hardening: Change the Port, Disable Root Login & Use SSH Keys
- How to Monitor Auth Logs and Detect Intrusion Attempts on a Linux VPS
- How to Set Up Effective Server Alerting (Without Alert Fatigue)
Browse more articles in Server Security & Hardening.
