SSH Honeypot / Quicksand Project
A contained defensive research project for observing noisy SSH behavior while preserving isolation, log hygiene, and clear teardown controls.
Summary
A contained defensive research project for observing noisy SSH behavior while preserving isolation, log hygiene, and clear teardown controls.
Environment
| Platform | Disposable Linux environment |
|---|---|
| Scope | Isolated SSH observation service with no internal routing |
| Observability | Sanitized connection logs, authentication attempts, and source churn |
| Data policy | No real credentials, trusted network paths, internal systems, or provider-specific details included |
Problem
Internet-facing SSH services attract automated login attempts. The goal was to observe common patterns safely without exposing real credentials, trusted networks, production hosts, or administrative access paths.
Risk / Control
- The environment could not provide a path into internal systems.
- Logs had to be sanitized before sharing.
- The project needed clear stop conditions and a teardown path.
- Observed input had to be treated as hostile and operationally untrusted.
Rollback criteria
The environment would be torn down if it showed unexpected outbound behavior, collected data could not be sanitized safely, administrative access boundaries changed, or the observation scope expanded beyond SSH noise.
Timeline / Investigation
The setup observed connection frequency, username patterns, authentication behavior, and source churn. All observations were treated as untrusted input, and the collection path was separated from administrative access.
Evidence collected
- Connection frequency and source churn.
- Username and authentication-attempt patterns.
- Service log samples after sanitization.
- Network boundary checks confirming no internal route.
- Retention and teardown notes for collected telemetry.
The operational review focused on containment first: what could the service reach, what credentials existed, where logs were stored, how retention worked, and how the environment would be removed if behavior changed.
The project stayed intentionally narrow: observe SSH noise, preserve containment, document patterns, and avoid active engagement or attribution claims.
Decision record
The decision was to keep the project passive and disposable. The record explicitly rejected active engagement, attribution claims, credential reuse, and any dependency on internal monitoring paths.
Validation criteria
Validation required confirming isolation, confirming no internal routing, confirming logs were sanitized before review, and confirming teardown steps could remove the environment without affecting other systems.
Result
The project produced a sanitized summary of common SSH noise patterns and a reusable checklist for safe defensive experiments. The result was an observation pattern with explicit trust boundaries, sanitized telemetry, and no dependency on internal systems.
Lessons Learned
Security research projects need operational boundaries before collection begins. Clear containment made the work useful without increasing exposure or confusing research telemetry with production monitoring.