andreicscs

joined 3 days ago
[–] andreicscs@lemmy.world 7 points 6 hours ago

Cool idea, but I don't think it's working properly right now. I'm getting these errors and the site keeps reloading. It looks like my ad-blocker might be blocking your analytics, which then causes the app to panic and crash, I hope the logs help you figure out what's wrong.

Thanks for sharing, The UI design looks really cool! That said, there are quite a few established directories doing this already (Awesome-Selfhosted, selfh.st, etc.). I'm curious what is the main thing that differentiates yours from the existing ones?

[–] andreicscs@lemmy.world 3 points 1 day ago (1 children)

Hey! I just released a hotfix for the Hub to polish the deployment UX and make some minor UI improvements. While I was at it, I took the chance to add the events export feature you requested, It is now possible to download event logs straight from the events table in the dashboard view. Let me know what you think!

[–] 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!

[–] andreicscs@lemmy.world 1 points 1 day ago* (last edited 1 day ago) (2 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.

[–] andreicscs@lemmy.world 2 points 1 day ago (4 children)

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.

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

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/.

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

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!

[–] andreicscs@lemmy.world 1 points 2 days ago

Thanks! I'd love to get some feedback if you end up trying it out!

[–] andreicscs@lemmy.world 1 points 2 days ago

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 😂

[–] andreicscs@lemmy.world 1 points 2 days ago

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.

[–] andreicscs@lemmy.world 2 points 2 days ago (2 children)

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.

 

Hey everyone,

Today I'm sharing a project I initially built to solve a personal problem that has quickly been picking up traction: HoneyWire v2.0. Hopefully it will help you out as well!

I wanted to run high-fidelity network canaries in my network, 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.

Main Features:

Zero-Agent: No ongoing background overhead on your hosts.

Centralized UI: Manage fleet settings, deployments, View fleet health, uptime, and lateral movement alerts.

Alerting: Built-in push notifications and SIEM forwarding.

Privacy: 100% free, open-source.

UX: 60 seconds from a fresh Linux box to an active cyber canary.

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.world 4 points 3 days ago

Will do, my bad, thanks for the clarification!

 

Hey everyone,

I wanted to run high-fidelity network canaries in my network, 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.

 

Hey folks,

Just open-sourced a project called HoneyWire, a distributed deception platform built as an alternative to commercial honeypots and traditional agent-heavy canary setups.

It allows you to turn any Linux asset into a network canary in about a minute. Instead of installing heavy background daemons, a transient CLI wrapper configures and launches lightweight, distroless decoy containers that check back into a centralized management dashboard.

If an attacker attempts lateral movement and touches one of these decoys, it triggers an instant alert to your SIEM or webhook notifications.

Project Links:

GitHub: https://github.com/andreicscs/HoneyWire

Site: https://honeywire.dev/

It's completely free, self-hostable, and transparent. Let me know if you have any questions about the detection mechanisms or the tech stack!

 

Hey everyone, Deception technology is highly effective for early breach detection, but deployment friction especially with other OSS alternatives and supply chain risks (adding attack surface with heavy background daemons) often stall adoption.

On top of that i couldn't justify enterprise solutions pricing, and available open source alternatives just weren't good enough for me.

I built HoneyWire to solve this. It’s an open-source platform designed to deploy hardened cyber canaries across a distributed infrastructure in under 60 seconds without persistent agents.

Architectural Highlights:

Zero-Agent Deployment: Traps are provisioned via a point-in-time CLI tool that exits completely after spinning up the decoy container.

Attack Surface Reduction: Decoys are built using minimal, distroless container images, following principle of least privilege ensuring attackers cannot easily pivot from or leverage the trap itself.

Centralized Management: A centralized Hub monitors trap heartbeats and aggregates lateral movement alerts.

SIEM integration: Out-of-the-box support for log forwarding and immediate webhook alerting.

Code: https://github.com/andreicscs/HoneyWire Site: https://honeywire.dev/

I'm eager to get feedback from defensive practitioners on the agentless provisioning model and feature roadmap. I'd love to hear feedback on the Threatmodel docs!

 

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!

view more: next ›