Building an SSH Honeypot Ahead of DenyHosts
An SSH honeypot creates a controlled target for automated login attacks, credential stuffing, and reconnaissance. Instead of allowing every connection attempt to reach a production shell, it presents a convincing but isolated service that records behavior for later analysis.
Used alongside DenyHosts, the honeypot can provide an earlier warning layer. DenyHosts is designed to watch authentication failures and block abusive addresses; a decoy service can reveal scanning activity before an attacker has a meaningful opportunity to interact with a real account.
The safest design treats deception and enforcement as separate functions. The honeypot collects evidence, while firewalls, DenyHosts, and other access controls protect legitimate SSH administration.
Define The Honeypot’s Boundary
A useful honeypot answers specific questions. You might want to identify recurring source addresses, observe username patterns, collect malware samples, or measure how quickly an exposed server is probed after deployment. Defining those goals prevents the project from becoming an uncontrolled data collection exercise.
The decoy should contain no production credentials, private keys, customer data, or routes to internal systems. Its apparent filesystem, user accounts, and service banners can be realistic, but its actual privileges must remain minimal. Assume that every connection will be hostile and that the honeypot itself may eventually be compromised.
A dedicated virtual machine or cloud instance is preferable to installing a trap beside important workloads. If the decoy must share hardware, use a separate network namespace, strict host firewall rules, and an independent account for log collection.
Place The Decoy Before The Real SSH Service
The most direct arrangement gives the honeypot the public address and moves the genuine SSH daemon behind a management-only address, VPN, or high internal port. Administrators then connect through a restricted path, while unsolicited Internet traffic encounters the decoy first.
A second option uses a dedicated public IP for the honeypot and leaves the real service on another address. This approach avoids complex port forwarding and makes emergency shutdown easier. A reverse proxy can also route connections, but it adds another component that must correctly handle SSH protocol behavior and preserve useful source information.
Do not run both services on the same exposed port without a clear ownership model. Binding conflicts, accidental forwarding, or a firewall rule that exposes the real daemon can defeat the entire design. Test from an external network and verify that the production SSH banner and authentication prompts cannot be reached through the decoy address.
| Design | Isolation | Useful For | Main Risk |
|---|---|---|---|
| Dedicated honeypot VM | Strong | Internet-facing research | Requires another host or instance |
| Separate public IP | Strong | Simple routing and shutdown | Needs address allocation |
| Same host, isolated port | Moderate | Lab experiments | Misconfiguration can expose production |
| SSH proxy in front | Variable | Centralized access control | Proxy bugs or logging gaps |
Capture Signals Without Creating New Exposure
Log connection timestamps, source addresses, requested usernames, authentication methods, client versions, and session commands. Record events in a write-only or append-focused location outside the honeypot where possible. Centralized logging prevents an attacker from erasing the only evidence after gaining access to the decoy.
Avoid collecting more data than the investigation needs. Passwords submitted to a fake service are sensitive, and retaining them indefinitely creates its own security and privacy concerns. Hash or redact values when full content is unnecessary, and define a short retention period for routine attack telemetry.
Network flow records add useful context. DNS lookups, outbound connection attempts, and unexpected process launches can indicate that the attacker is trying to use the honeypot as a staging point. The honeypot should have no unrestricted outbound Internet access; allow only the channels required for monitoring and updates.
Feed Evidence Into DenyHosts Carefully
DenyHosts normally reacts to repeated failed SSH authentication recorded by the genuine daemon. A honeypot can act as an earlier signal source, but its events should not automatically become permanent blocks without validation. Internet scanners often use spoofed, shared, or cloud-hosted addresses, and an overly aggressive rule can affect legitimate users.
A practical integration uses a small event adapter. It reads structured honeypot logs, applies thresholds, checks an allowlist, and submits only high-confidence addresses to the DenyHosts workflow or a firewall set. Keep the adapter separate from the decoy process so a failure in one component does not disable the other.
For example, five distinct usernames attempted within a minute may indicate automated credential stuffing, while one failed attempt from a corporate address may be harmless. Correlating honeypot events with real SSH logs, DNS history, and connection rates produces better decisions than relying on a single event.
The integration should also support expiration. Temporary bans limit collateral damage and let administrators review whether a source address belongs to a scanning service, a compromised host, or a legitimate network using a shared gateway.
Select An Implementation That Matches The Goal
A low-interaction honeypot can imitate an SSH banner and authentication exchange with little operational risk. It is easy to deploy and useful for measuring scans, usernames, and password attempts, but it will not reveal much about post-login behavior.
A higher-interaction project such as Cowrie provides a simulated shell and richer session recording. It can show which commands attackers run and which files they attempt to download, though it demands stronger isolation and more careful patching. A custom Python listener may be appropriate for a narrow experiment, but protocol edge cases and secure logging are easy to overlook.
Deployment quality matters as much as the honeypot code. Keep configuration in version control, pin dependencies, and make logs reproducible for later analysis. If the project produces packages or release artifacts, a build utility such as ReleaseForge project can help standardize how those artifacts are assembled and published.
Monitor The Trap And Protect Operators
A honeypot is valuable only when its signals reach someone who can act on them. Send alerts for unusual command execution, outbound connection attempts, privilege escalation, or a sudden increase in source addresses. Use rate limits so a scanning burst does not flood the monitoring channel.
Build routine checks around the deployment rather than trusting it indefinitely. Review firewall rules, verify that the real SSH service remains reachable only through its approved path, and compare the running image against a known baseline. A disposable instance can be rebuilt after investigation instead of cleaned manually.
Useful operational safeguards include:
- Place the decoy in a separate VLAN, virtual network, or cloud account.
- Allow administrative access only through a VPN or dedicated management address.
- Forward logs to storage the honeypot cannot modify.
- Use temporary blocking thresholds and maintain an explicit allowlist.
- Rebuild the instance after suspected compromise or major software changes.
Deploy In Stages And Measure Results
Begin with a private test network. Generate controlled login attempts, confirm that the honeypot captures them, and verify that DenyHosts or the associated firewall action handles the resulting event correctly. Test recovery as well: administrators should know how to disable the decoy and restore the legitimate SSH path without guessing.
After exposure, measure the ratio of unique sources to total attempts, common usernames, time to first probe, and the number of addresses that produce high-confidence alerts. These metrics show whether the honeypot is detecting activity earlier than ordinary authentication logs.
A staged rollout also reveals operational noise. If automated scanners create thousands of low-value events, refine thresholds and retention before enabling automatic blocking. The goal is a defensive feedback loop: attract unwanted attention to a controlled service, extract useful indicators, and keep the real SSH boundary difficult to reach.
Use the resulting data to tighten firewall policy, improve DenyHosts rules, and document the deployment. With clear isolation and disciplined monitoring, an SSH honeypot becomes a practical early-warning sensor rather than another exposed server to maintain.