Krawl honeypot lab
A locally operated deployment of an upstream deception service for observing hostile web behavior.
Scope and ownership
Krawl is an upstream open-source project deployed and operated in my lab, rather than an application I authored from scratch. My project work is the container deployment, configuration, isolation, monitoring, testing, and interpretation of its telemetry.
The lab container was stopped on August 20, 2026 by a forced termination rather than a clean shutdown, and it has not been restarted. A companion reconnaissance tool was stopped cleanly the same day. No decision has been recorded about whether the lab is retired or waiting on the dashboard-access work below, and recording that decision is the next action for this project.
Deception capabilities
Krawl exposes realistic but fake web surfaces designed to attract automated scanners and malicious behavior. Features include spider traps, fake administration and login pages, honeypot paths advertised through robots.txt, fake credentials, canary-token integration, varied server headers, random error behavior, and a real-time dashboard.
Architecture
The Python code separates configuration, server handling, models, database access, analysis, sanitization, IP and geographic helpers, generated templates, wordlists, and scheduled tasks. Docker is the current deployment path; Kubernetes manifests and a Helm chart provide more advanced isolation and scaling options.
Testing and telemetry
The repository includes focused checks for headers, fake credentials, SQL-injection detections, simulated attacks, and inserted test addresses. Reputation analysis considers risky methods, robots.txt violations, timing anomalies, user-agent consistency, and suspicious paths.
Safe operation
- Use only fake credentials and synthetic content; never expose real secrets as bait.
- Restrict the dashboard to a trusted management network and place it behind real authentication; a secret URL is not an access-control boundary.
- Set retention and storage limits so hostile traffic cannot exhaust the host.
- Run with minimal privileges, read-only configuration where possible, and a dedicated network/volume.
- Treat automatic block lists as evidence to review, not unquestionable truth.
- Keep legal authorization and monitoring boundaries documented.
The dashboard currently relies on a weak, guessable secret path while the service is host-published. Isolate the management route and add real authentication before treating dashboard access as protected. Fake login pages remain deception surfaces, not genuine user accounts. Read the complete review.
Lessons and roadmap
The lab demonstrates that detection quality depends on context and clean telemetry. A honeypot is not a firewall; it supplements prevention by producing evidence. Future work should integrate reviewed alerts, central log retention, resource monitoring, and a documented containment process without exposing the dashboard publicly.