Hey everyone,
I wanted to run high-fidelity network canaries in my homelab, but I couldn’t justify enterprise pricing, and I wasn’t a fan of managing custom orchestration across all my VMs to make available oss solutions work.
So, I built HoneyWire. It’s a completely free, open-source distributed deception platform.
It uses a point-in-time CLI wizard to deploy hardened, distroless Docker traps. You run the command once, it spins up the decoy, registers it to your centralized Hub dashboard, and the setup agent completely exits. No persistent background daemons.
Features:
Zero-Agent: No ongoing background overhead on your hosts.
Centralized UI: View fleet health, uptime, and lateral movement alerts in dark mode.
Alerting: Built-in push notifications and SIEM forwarding.
Privacy: 100% free, open-source, and strictly zero telemetry.
GitHub Repo: https://github.com/andreicscs/HoneyWire Landing Page: https://honeywire.dev/
Would love to hear your thoughts on the architecture or any feedback if you test it out!
AI Disclosure: As a student and solo developer/maintainer, I used AI as a “junior dev” during project development to help accelerate boilerplate writing and documentation. All core architecture, system structure, and security logic were fully designed and implemented by me.
Just going to comment here because I don’t need to keep dismissing reports repeatedly - this post is entirely on-topic, breaks no rules, inclusive of the newly formed rule (not yet made official in the sidebar, but so far with rather consistent support as written) as its fully open and not paywalled in any way, and licensed under AGPLv3.
@andreicscs@lemmy.world I would recommend you add your AI disclosure to the post itself though, noting how you used it as you already have in the comments.
Will do, my bad, thanks for the clarification!
Is this for homelab penetration testing?
Well, you could use it for blue team simulations i guess, but not really, it is a Deception platform, meaning it is a tool used to deploy micro honeypots, or as i like to call them, tripwires, that report back to the hub as soon as they are tripped. Since these tripwires offer no real services or value every interaction with them is pretty suspicious, meaning that if something for example tries to poke around a server that has been deployed with HoneyWire tripwires, it will report back to the hub with information about what interacted with it, when, where, and what was done. Check the project’s official website for more details: https://honeywire.dev/ You can also check out the concept of Canaries on Thinkst Canary s website i think they do a great job explaining the idea https://canary.tools/.
Hi.
hw-sensor-tcp-tarpit crashes and that stops also the hub. I don’t know how to check the logs for that container.
I can’t open issues or anything on Github (this the reminder for every foss project participant: please use an alternative to github).
Hi thanks for the report! I understand wanting to avoid github I’ll consider alternatives! But for now github is the most convinient for the for the project.
Could you provide details about the environment you are deploying in and what your honeywire-compose.yml file generated by the hub looks like?
I’d love to look into your specific edge case it would be awesome if you could provide info that would help me debug it!
You could try to run ‘docker logs hw-sensor-tcp-tarpit’ command and see if it shows any useful info about the crash
Are you deploying the sensors in the same host as the hub ? If so, What ports are you running the tcp tarpit sensor on and what port is the hub running on ?
The Tarpit sensor crashing is strange, but the Hub crashing too is a huge red flag that I need to fix, a dead sensor should never take down the main Hub!
It doesn’t matter if Github is more convenient, I, for example, am straight banned from it with no possibility to sign-up. Issue with arkoselabs not working from my ip/device, which is required to complete captcha for signup, and the support is non existent, see this post.
Ok, issue is clear: tcp-tarpit is trying to use an already occupied port. I was not sure how to check the containers log, your command was correct.
Yes, I was trying to deploy everything on the same machine as starter.
I found that I could change the port from the hub, under fleet management, now it seems to work.
I still don’t get why the hub stopped working though. Cpntainer log is only showing from the last start.
I see, i get your feelings about GitHub, i checked out your post and it really is an annoying problem, I’ll see what i can do for you and others who can’t access GitHub. For now anyone who has trouble accessing GitHub, please feel free to either reach out right here on this post, or via email at info@honeywire.dev.
As for the issue, it would be great if you could provide a little more information about your deployment. Did you use the setup wizard, or did you go with a manual deployment? What does your compose file look like? (It will be located at /opt/honeywire/sensors/honeywire-compose.yml if you used the setup wizard).
The setup wizard is built to prevent you from applying a conflicting config to the node, so this is either a bug with the wizard’s environment checks, or a manual deployment that happened to use conflicting ports.
The containers crashing and only showing logs from the last start is definitely interesting behavior. My best guess until I see the config and deployment type is that the Docker daemon hit a fatal error on the port collision panicked and kept restarting the containers, forcing the previous logs to clear as well.
Yes I used the wizard, which is very neat. Yeah, during the setup, all occupied ports are listed, including the one which was already occupied but nevertheless got used by one of the tcp tarpit decoys.
Now I just moved that decoys port (just did +1, I hope that doesn’t matter) from the UI which correctly changed the honeywire-compose.yml file. Now it seems to be running properly, and firedrill triggers the notifications.
I think you are right on the compose up crash upon port occupied.
Thank you so much for the additional info, since you used the wizard this shouldn’t have happened at all. Can i also ask what port you originally had the hub on?
bumping up the port won’t cause any issues at all!, it is what the wizard should have done once it realized the port was already in use. You can run the decoys on any ports you want as long as they are not already bound to that host. I’m glad to hear everything else worked as intended and that the Firedrill successfully triggered your notifications
I have already found the issue and I’m pushing an hotfix for the tcp tarpit sensor right now. Your feedback was very helpful!
Since you’ve got it running, I’d love to use this opportunity to get your thoughts on the sensor updating process whenever you get a chance to try it.
The hub is running as follow:
services: ... hub: ports: - "myportbehindreverseproxy:8080" ...That way I had to change as less as possible and just setup a quick reverse proxy. I 100% followed the steps from the README.md in Github for the quick start guide, so this was all wizard and
honeywire apply. 3306 was the already occupied port, occupied by a native program, not a container.That explains it, i still find it weird that the hub was crashing too, but the issue is now solved either way. I just released a hotfix for the sensor. I also released a hotfix for the hub to polish deployment UX and fix a minor issue with sensor updates, i recommend you run ‘docker compose up -d --pull always hub’ to update the hub and, you should be able to update the sensor from the hub if you haven’t already.
Thanks for the help!
Do I understand correctly that with HoneyWire you deploy ‘false assets’? I guess along the lines of a honeypot but the ability to deceive bots and other nefarious actors into thinking there are specific assets that they might want to exploit?
That’s exactly how it works. You deploy these low-interaction decoys (traps) across your internal network to act as tripwires. Since legitimate users have no reason to touch them, any interaction is a high-fidelity alert indicating a potential breach or lateral movement. Right now, you can spin up a few different types of traps, like a network scan detector that sits completely quietly and triggers an alert if it detects a port or network scan hitting that specific node, or a Web Router Login Page, that looks like a legacy admin interface and instantly alerts you if someone tries to brute-force or log in. The best part about HoneyWire’s architecture is that developing new sensors is the easiest part, so the ecosystem is designed to be highly extensible as the community grows.
That’s very interesting. Thanks.
Now for the burning question on everyone’s mind…was this vibe coded, or AI assisted in any way? I don’t outright reject AI assisted projects, but of course my concerns are always security. Also, what is the depth of your experience coding?
Thanks
No issue that’s a completely fair question, yes AI was used as an accelerator for writing boilerplate code, scaffolding the initial UI layout, and helping me structure the documentation. However, the core security logic, container architecture, and threat model were entirely designed and verified by me. I have about 8-9 years of software development experience. While HoneyWire is my first major public release, it’s the culmination of years of building internal tools, network utilities, and lab environments.
Because security is the primary focus, I deliberately designed the architecture to minimize risks. I highly encourage you to review the source code on GitHub, I’d be happy to receive feedback about the architecture or any threat-modeling critiques!
Looks like the following from github:
Suite of Official HoneyWires: Includes native TCP Tarpit, Web Router Decoy, File Canary (FIM), ICMP Canary, and Network Scan Detector.
I don’t see any AI disclosure on github or here OP. Can you specificy how AI has been used on this project?
AI Disclosure: As a student and solo developer/maintainer, I used AI as a “junior dev” during project development to help accelerate boilerplate writing and documentation. All core architecture, system structure, and security logic were fully designed and implemented by me.
Ok, so see this AI Disclosure would be helpful in the original post. You’re going to get downvoted either way, but at least it’s upfront. Don’t take it personal, it’s just that there is a faction of very vocal anti-AI users here.
My 2p.
I appreciate the feedback and the 2p! I definitely don’t take it personally. I completely understand the skepticism around AI in this community, which is why I don’t hide it. At the end of the day, the core engine, the distroless container architecture, and the threat model were entirely engineered by me. HoneyWire is fully open-source and transparent, so anyone is welcome to audit the codebase. I also have several other public, non-AI projects on my GitHub if anyone wants to vet my background. But fair point I’ll make sure to be more upfront about using it as a scaffolding tool in future posts
“Artificial Intern” is the right way to use it to code.
I agree! Not all AI usage is bad, it definitely can be if you just copy paste its output or let it “build” on its own, but it can be a great tool if used correctly. At the end of the day the best “harness” for ai is the dev himself.
Awesome. I have bookmarked it in my Projects folder. It does look rather intriguing.
Thanks so much! I’d love to get your feedback if you end up deploying it. I’ve been staring at this codebase for so long that I’m sure I have some tunnel vision and might be blind to obvious issues. Let me know what you think!
Can you specificy how AI has been used on this project?
I cannot. I’m not the dev.
Another AI generated project from a person who has zero comment history beyond promoting said project and is likely to stop committing to the repo in a week.
Thanks for the feedback! Not quite, but I get the skepticism with how many low-effort vibecoded projects are launching right now! I’d love for you to take a look at the project (or my other projects), I’m not a vibe coder, and I’m not new at coding at all. This project is 3 months old and as you can see from the commit history I’ve been consistently fixing things and adding new features to it since when it first launched. This is the v2.0 release, there were other releases before over the course of the last few months, this update in particular is a Security and UX update focused on improving supply chain security, and deployment friction. Feel free to check out the changelogs for a closer look at the changes: https://github.com/andreicscs/HoneyWire/blob/main/CHANGELOG.md
I’m sharing this tool because it fixed a personal problem, and i noticed many others had the same feelings regarding available deception technology options especially in OSS.
Appreciate you taking the time to respond. I’m so jaded by the low effort posts here that it’s made me grumpy 😂
No problem at all, i get it! If you end up actually taking a look at the project or even deploying it I’d love to get some feedback on it, I’m currently starving for feedback and opinions 😂
