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.

  • andreicscs@lemmy.worldOPEnglish
    1·
    5 days ago

    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.

    • Alfredolin@sopuli.xyzEnglish
      2·
      5 days ago

      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.

      • andreicscs@lemmy.worldOPEnglish
        2·
        4 days ago

        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!