Selfhosted

60177 readers

489 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

Detailed Rules Post

Be civil.
No spam.
Posts are to be related to self-hosting.
Don't duplicate the full text of your blog or readme if you're providing a link.
Submission headline should match the article title.
No trolling.
Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details.

Resources:

selfh.st Newsletter and index of selfhosted software and apps
awesome-selfhosted software
awesome-sysadmin resources
Self-Hosted Podcast from Jupiter Broadcasting

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 3 years ago

MODERATORS

curbstickle@anarchist.nexus

curbstickle_lw@lemmy.world

HoneyWire: Open-source, zero-agent cyber canaries for your homelab (Thinkst/OpenCanary alternative) (lemmy.world)

submitted 4 days ago by andreicscs@lemmy.world to c/selfhosted@lemmy.world

29 comments fedilink hide all child comments

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!

you are viewing a single comment's thread
view the rest of the comments

[–] Alfredolin@sopuli.xyz 3 points 1 day ago (1 children)

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.

[–] andreicscs@lemmy.world 1 points 1 day ago* (last edited 1 day ago) (1 children)

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.xyz 2 points 1 day ago (1 children)

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.world 2 points 1 day 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!