mirror of
https://github.com/juanfont/headscale.git
synced 2026-01-11 20:00:28 +01:00
[Missing documentation] Security considerations – what if Headscale server gets compromised? #500
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @codethief on GitHub (May 7, 2023).
I have been trying to find information about security aspects of Headscale (and Tailscale in general), in particular about what risk I'm facing should my Headscale server get compromised. So far, my impression is that a compromised Headscale instance would basically mean that my entire Tailnet is at risk, since the coordination server is not only able to modify ACLs and e.g. grant SSH access to nodes (also compare https://github.com/juanfont/headscale/issues/661) but, in the absence of Tailscale Lock (compare
https://github.com/juanfont/headscale/issues/1307), it can also add new nodes to the network (and then grant them access to everything). But even with Tailscale Lock enabled, if the machine on which the Headscale daemon is running is part of the Tailnet and that entire machine (and its private key) get compromised, or if the attacker has another way of obtaining a private key of one of the peers of the Tailnet, my impression is – and please correct me if I'm wrong here – that it'd be game over for the entire network.
Since this this doesn't seem to be a far-fetched risk (people usually run all kinds of things on their personal servers, and vulnerabilities abound) and the potential impact of the above attack vector is devastating, I'd be grateful for clarification. Moreover, if my concerns are indeed justified, I think they would also deserve a mention in the documentation and, also, proper warning (e.g. "Never run Headscale on a Tailnet node!"). And if they're not justified, all the better! But even in this case, adding documentation about potential attack vectors and their impact would be great.
Related issues: https://github.com/juanfont/headscale/issues/1072
@tillnelown commented on GitHub (Jul 31, 2023):
Regarding ssh access, Headscale currently doesn't support it and when it does it will only be an issue if you enable it on the clients as per
tailscale up -h:--ssh, --ssh=false run an SSH server, permitting access per tailnet admin's declared policy (default false)But taildrop may also be an issue, you can currently add files to any android device using it without user input though this may change when the app gets a ui for it. I haven't used it on other platforms so I can't comment on how it's handled there.
@github-actions[bot] commented on GitHub (Dec 15, 2023):
This issue is stale because it has been open for 90 days with no activity.
@github-actions[bot] commented on GitHub (Dec 23, 2023):
This issue was closed because it has been inactive for 14 days since being marked as stale.
@codethief commented on GitHub (Dec 24, 2023):
Ugh. The issue is not stale.
@IronBeardKnight commented on GitHub (Apr 29, 2024):
I am also concerned about how it is actually secured if your self hosting.
@zebogan commented on GitHub (May 10, 2024):
Same concern, only stuff I've found online so far is this and an unanswered tailscale forum post.
@street-grease-coder commented on GitHub (Nov 16, 2024):
I think I get it, this is just still very much in development, if the headscale coordination server, which is afaik just one, nonredundant system, all computers and internal networks are compromised. It's one giant point of failure and weakness