HoneyGo

• 

  Logo

• 

  Dashboard

• 

  Database

• 

  CMD panel

🍯 Honeygo: About the Project 💡 Inspiration Traditional cybersecurity defenses are generally reactive and passive; an attack occurs and is logged. Approaching this with a computer engineering vision, we wanted to develop an "active" defense mechanism that doesn't just watch the attacker but proactively delays them, feeds them fake data, and physically isolates the system when a critical threshold is crossed. Our goal was to build an industry-standard honeypot capable of making its own decisions and instantly cutting off lateral movement, rather than just a simple logging tool.

🏗️ How We Built ItWe wrote the core of the project in Go (Golang) due to its high concurrency capacity and low system resource consumption. Adhering to Clean Architecture and Dependency Injection principles, we isolated the network, storage, and defense modules from each other.To counter Resource Exhaustion (DoS) attacks at the network layer, we modeled incoming attack requests using a Poisson distribution. Given the average number of attack packets lambda arriving in a specific time interval t, we defined the probability of k concurrent requests arriving as follows: Based on this theoretical modeling, we optimized the maximum number of concurrent connections our TCP server could handle and the Semaphore (channel buffer) capacity. We stored the resulting logs using CGO-free SQLite (modernc.org/sqlite) to provide an independent architecture that can boot up instantly. For the presentation layer, we exposed a REST API via the Fiber framework and reflected the data in real-time on a dark-themed dashboard using TailwindCSS.

🛑 Challenges We Faced Our biggest bottleneck during the development process was the system environment we initially planned. We designed the project to run on PostgreSQL and Docker-Compose, but virtualization (WSL 2) issues in the development environment prevented the engine from booting up. At this critical, time-sensitive point, we made a fast and forward-looking pivot and completely shifted the architecture to a dependency-free, "standalone" pure SQLite-based model. Another major challenge was OS-level integration. In the "Kill-Switch" (Emergency Network Isolation) mechanism we developed, asynchronously dropping the local Wi-Fi adapter connection via os/exec within milliseconds of the attacker interfering with the fsnotify-monitored bait file (Honeytoken)—while simultaneously logging the final state to the database without deadlocking—required serious engineering effort in terms of process management.

🧠 What We Learned We saw that when designing an industry-standard system, it is not enough for the code to "just work"; the architecture must be designed defensively from the ground up against memory leaks and deadlocks. Additionally, when moving from theoretical planning to practice, we experienced the critical importance of being able to make pragmatic architectural changes without compromising the business logic of the project during infrastructural issues (like our Docker crisis).

Built With

• golang
• html5
• sqlite