Show HN: Tailsnitch – A security auditor for Tailscale | Hacker News Reader

Show HN: Tailsnitch – A security auditor for Tailscale

github.com

280 pointsthesubtlety28 comments

So this is a configuration linter; what I was hoping it might be is something that provides live auditd notices for when a tailscale user connects by SSH to a common "admin" account.

The tailscale daemon definitely knows which user it is making the connection, as it publishes that info into the journal and I've seen people scrape it out of there, but I'd much rather it go through a structured reporting pipeline. AFAICT, tailscale itself provides several things that look like they're this, but aren't quite the right thing, for example https://tailscale.com/kb/1203/audit-logging is about logging changes to the tailnet itself (eg adding nodes), and https://tailscale.com/kb/1246/tailscale-ssh-session-recordin... is recording the ssh sessions rather than simple events for XYZ logged in / XYZ session idle / XYZ disconnected.

(And yes, I know people have opinions about common admin accounts, but tailscale is another route into what FB described as far as everyone accessing the same root account but doing so with their own credentials [good!] rather than a shared key [very bad!]: https://engineering.fb.com/2016/09/12/security/scalable-and-...)

Oh that's a cool idea. Super useful for detection and response teams, guessing they're able to get some of that by standard OS telemetry via agents/EDR.

Having an audit trail is really important for medium-sized shops where a lot of senior devs still have the keys to prod and kind of need to as they're still the defacto ops team and have to be able to get in quickly to investigate faults or poke at systems to get them back online.

At the same time, when something is left in a bad state, you want to know how it got that way and when; not even necessarily just to punish people, but so that the right people are in the room to explain the full circumstances of what they did and why.

It sounds like you want the sort of logs that Teleport captures https://github.com/gravitational/teleport

I guess so, yeah, though that sounds like that's a whole separate ecosystem, and positions itself as a direct competitor:

https://goteleport.com/compare/tailscale-alternative/

OTOH, a lot of people who think they need a VPN really just need tunneling and authenticated access, so I can see the pitch for why Teleport's offering is a fit for many users who would otherwise consider tailscale.

Theres more to it. This falls into the realm of privileged access management. I think if you are critical infrastructure, financial institution, healthcare tech. This is non negotiable and it is part of your compliances. Just VPN do not cut it out. At adaptive [1], we do the same for server, databases and kubernetes clusters. It is a double digit billion dollar TAM.

[1] https://adaptive.live

Not really? We use Teleport behind Tailscale.

Just merged https://github.com/tailscale/tailscale/pull/18333

Holy cow. Well... that's awesome. Thanks so much!

I see how the power of HN community manifests. Really cool work!

Will this also work with Headscale [1]?

[1] https://headscale.net/ | https://github.com/juanfont/headscale

This is what I've been looking for. I love Tailscale, but as our tailnet has grown from "just me and a few servers" to "entire engineering team + prod/staging/dev environments," the ACL file has become terrifyingly long.

I always have this low-level anxiety that I accidentally left a tag too open or messed up a source/destination rule in the HuJSON. Anyone else? The fact that this can run in CI/CD is a huge win.

Tailscale policy tests are a bit hard to write but help us have confidence in our changes.

https://tailscale.com/kb/1337/policy-syntax#tests

I've tried using policy tests but as far as I remember you can't test access to specific hostnames, only tags. I know Tailscale ACLs operate on tags but in tests I want to validate that users can access specific things, validating they can access tags isn't very useful. I also don't really think the tests should be in the ACL file itself, I would much prefer if it were external, or if the Tailscale CLI had a command to run ad-hoc reachability testing.

We did a refactor of our big ACL file recently but it took a lot of work and people inevitably lost access to things. I don't feel that Tailscale's ACL tests are really sufficient for making changes fearlessly.

Maybe a dumb question, but is there any reason or incentive for Tailscale to not run something like this for every user, or atleast offer a "scan now" button or something? I love the idea of this tool and will for sure be using it, just would like to see something like this native to the platform itself. Seems on brand for them, and it's not like they offer paid security audits or anything

(n=1, imho, ymmv, etc)

No, not only should Tailscale offer a point in time report (click button in GUI, scan queued and report created, report link is preserved in GUI, any user with sufficient access can retrieve the report), they should expose whatever is needed via API to make these attestations available to automated GRC evidence collection systems (Vanta and Anecdotes, for example). Think continuous compliance monitoring of the software defined network tenant/control plane, similar to what you would get out of a CNAPP but scoped for this use case and more geared towards audit and compliance.

I would be somewhat surprised if their enterprise users haven't or are not asking for this to be honest.

Very nice! As a two-user household I was surprised I am not supposed to use tags for user devices: https://tailscale.com/kb/1068/tags

How am I supposed to work with user devices (laptop/phone) then if not tags? Because from the Laptop I want the user (me) to be able to use e.g. the SSH ports on my servers, but from the phone I don't want SSH enabled.

I currently assign the tag SSH to the phone/laptop which either enables or disables SSH, now I am unsure because without tags I can only assign the user the tag?

Hahaha, I love it. But also, a security tool you're going to be using against your core infrastructure should probably not be a random binary that you also tell users to strip quarantine off of to use: `sudo xattr -rd com.apple.quarantine`. Sigh at the state of running stuff on macOS sometimes.

All joking aside, this looks great. Is there a plan to allow for "custom checks" with custom rules users create? Think of "never should happen" access from a to z, etc.

Ha, I wrote `sketchy` for that.. Agreed though. Not a bad idea, will add it to the list.

Suspect you’d probably want to copy config and this into a vm anyway

Else you’re just adding risk imo

What's your suggestion? Not everyone is willing to pay to notarise their little CLI tools.

Sadly not a whole lot you can do. You could try and gain some legitimacy by getting your recipe added to homebrew but otherwise no clue. I wasn't laughing at it at the author, more so just the irony of the situation.

I’ve been using Tailscale to connect remote edge devices into a single network, and one thing that’s always missing is good visibility into what’s actually happening on the tailnet.I hope Tailsnitch will fit that gap nicely if it makes traffic patterns explicit without turning into a heavyweight security product. For setups with distributed devices, this kind of local, understandable observability is really valuable, especially when you want to debug or sanity-check access instead of just trusting that everything is fine.

Very cool! Does it check for https://github.com/tailscale/tailscale/issues/11717 ?

It's checking ACLs via API but not sure about this, I'll have to dig into it a bit.

I'm probably not 100% up to date with their progress (feel free to educate me/us), but to me Tailscale seems perfect for a small startup of highly competent people but has the risk of falling apart catastrophically when you grow and hire people who maybe aren't.

I just use the free version at home. The mere existence of this tool feels a bit like validation of my skepticism.

This tool makes providing evidence for SOC2 slightly easier, and I do wish I had had this when I started my SOC2 journey at $dayJob.

Reply on news.ycombinator.com