Admin security

[Virtualchronos]

Hello,

Sorry if it's not the good place to post it and thanks for this nice forntend

here's the points :

-enabling or disabling routes by switch doesn't work (greyed) but it work with others frontend -cant register new computer (get strange message everytime : Failed to create node: Unspecified Error: {"code":2,"message":"key hex string doesn't have expected type prefix mkey:","details":[]} ) maybe a exemple cmd text would help or maybe it's because i'm using headscale beta5 -PLEASE ADD A PASSWORD TO HEADSCALE ADMIN INTERFACE ! Since you have to host it on the same url as headscale you can't secure or restrict it with nginx proxy manager and anybody who get your headscale dns name can access headscale admin interface wich is awfully dangerous

Thanks for everything

[GoodiesHQ]

Alright addressing these points one at a time:

• I have just run into this problem as well when using alpha5. headscale-admin will not let you toggle routes when the node is offline, and headscale alpha5 seems to not properly report that nodes are online all the time. I'm currently seeing if there is a workaround for this.
• This is definitely relating to a change introduced in alpha5 since they introduced a change to use the prefix "mkey". I can address this with a patch, thank you for pointing it out!
• Security from the server side is not needed beyond typical SSL protections. Your API key is your password and it is only ever stored in your browser's localStorage and sent to the headscale server directly. It does not interact with headscale-admin in any way whatsoever and it is certainly never stored on, or transmitted to, the web server. If someone else accesses your headscale-admin portal, they still need your API key to do anything with it. Fundamentally, there is absolutely nothing that headscale-admin does which can't be accomplished with cURL requests, so technically speaking, anyone can interact with your headscale installation anyways as long as they have your API key. Hopefully that makes sense!

[Virtualchronos]

Thanks for the answer. I didn't knew that the api key must be provided each time you change of browser. for the rest, i suppose you'll fix it in a next release hoping that the next headscale version won't break everything one more time

[GoodiesHQ]

It's been really fun having new headscale betas break so many things c:

[Virtualchronos]

I can understand ^.^

Other question (not related to headscale-admin sorry) Does headscale-tailscale allow windows network discovery over VPN (I know zerotier can but it can't be 100% selfhosted like tailscale) ? I tried without any success so far. Maybe there's things to do to allow this but I don't know what.

[GoodiesHQ]

I don't believe so. There is no layer 2 extension, but everything is done over many point-to-point layer 3 connections. Windows discovery utilizes multicast protocols for network discovery. It seems MAYBE it's possible to have windows network discovery if you utilize a WINS server? I have no personal experience, but I think it's worth trying, maybe? You'd have to go into your windows control panel IPv4 settings and manually set a WINS server (e.g. to a member of the tailnet which has the WINS role installed and turned on), but it seems like it may possibly work. If you try it, let me know how it goes! Would be interesting.

[Virtualchronos]

Seems promising and you're the first to answer and even propose a solution. wins server seems a bit extreme for a gaming purpose VPN but i may try later since I've a lot of servers to setup correctly first but it seems to be a good idea. I'll stick to headscale for administration between servers and lxc/vms and for the moment self hosted zerotier manager for gaming. Do you know if netbird have computer discovery functionnality ?

Here's also some upgrades i thinked of : -for headscale admin, a "change client xxx IP" functionnality would be excellent (just changing the last part 100.64.XXX) since you can't change IP (except by modifying database)

• then, maybe a reboot headscale button (or an auto reboot) could be usefull to apply some changes safely when you mess in db or also a download database button to back-up / reupload it
• for interface : that's not a big deal but it's a bit frustrating that you can't go to the correct menu by clicking to the appropriate rectangle infos in home (online users, nodes etc...) it's a display only

[GoodiesHQ]

@Virtualchronos while I do REALLY love these ideas and would love to implement them, unfortunately I am limited with headscale-admin to what the API supports, and that does not include changing IP's, as much as I would like it to. As a design decision early on, I figured that I wanted it to be completely static as this would mean it can be hosted on any environment, completely independent of the headscale server itself. Interacting with the database would require interacting with the file system of the server, which is just something that can't be guaranteed by this app. It also improves security by reducing the attack surface. Hacking into an application that just serves static HTML files with no authentication keys or anything that can be used to further an attack is a lot less rewarding than an application with direct access to the headscale file system.

As for the interface, you're not the first to mention it, so I suppose I should do that! The issue is a few things: 1) The filtering is only done by name. So "Total Users" and "Online Users" would just redirect to the same page. Same with nodes. There is no filter as of right now that can be applied to search for only online users. 2) Some of those do not have dedicated pages. In the dev branch that I just updated a few minutes ago, I finally added a dedicated Routes page, but there is not a dedicated page for PreAuthKeys (PAKs). This means that clicking on the PAKs card would not take you to any location where you could see all PAKs in a single pane, but would just take you to the Users page since that's where PAKs are defined.

I will go ahead and make those cards do something, though :) I just pushed dev, but I will make another push before I version it as 0.1.12.

Much appreciated! Feel free to open additional issues if you'd like to request more features. I like having them as a reference/checklist!

[Virtualchronos]

I'm a bit disapointed to know that there won't be any ip changing function (unless headscale server allow to do it via api key of course), but i understand your choices and security concerns shoud come before trivial add-ons wich are not absolutely necessary (thaugh ip change function should have been implemented in headscale server, i don't understand why anyone does seems to see the benefit of it)

cards are not absolutely required but i must admit that i clicked dozen of times on them hoping a new menu would pop if i insist (dumb behaviour I know). route page is great. A quick view of all available routes is very nice (thaugh i still don't understand what the "allow lan acces" do exactly, I didn't see any difference but the answer is probably i don't know how to use it and what is the purpose of it)

I've a few ideas but i don't know if you'll like them since that's just a few tips and not any incredible features :

-disable "accept dns" button enabled by default (for those like me who use proxmox, it forces the proxmox dns to be replaced by the one of headscale and break the internet connectivity of vm/lxc, that's not catastrophic but it gave me some trouble on three machines)(maybe at minimim put a /!\ warning icon with a message advertising that it's advised to proxmox users to leave this option unchecked) -remember if a button have been checked or not (return to default config each time is a bit annoying and can lead to errors) -custom icons for nodes ? Not a banger (and not absolutely necessary) but a phone, laptop, desktop, or else icon for clients could help to quickly visualize wich client is what kind of device (wifi icon is cool but lack of precision)

[GoodiesHQ]

I like them a lot!

1) I think I'm going to change the default defaults to all unchecked to make things simpler.

2) This would be very good to add a "Save Defaults" button, but since there is no server storage with headscale-admin, it will have to save them in localStorage in the browser along with everything else like the API URL/Key, settings, theme, etc. This is definitely a good idea though. I think the PreAuthKey should be ignored from the defaults. Possibly some other fields.

3) The icons one is quite a bit tougher. This, too, would have to be saved in localStorage so it wouldn't transfer between devices you use for management, but the bigger issue is that, when headscale-admin is built, it uses the the @iconify/json package in the build stage. This package is very large because it contains ALL vector information for the entire set of icons that iconify uses. It's hundreds of megabytes in size if I remember correctly. Once it is built, the end result only contains the icons that are actually imported and used by the app. It would be different if I utilized the public Iconify API instead of embedding the icons in the app, but that causes slower loading of the page when the icons aren't cached and I would prefer to not rely on an external API if it can be avoided. I'll mull it over and see if there's a good alternative. One option is to put the ENTIRE iconify package into the final image, but that package alone is several times the size of the entire resulting image with Caddy and everything else (51 MB).

[Virtualchronos]

That's a really pleasant conversation ^.^

from what i see, icons is a semi good idea. if the purpose of headscale-admin is to be as compatible as possible with anything, the lightweight form should also a big advantage, so 50Mo for icons that 30% of the people will use is in fact a "bad" idea.

after what you said previously here's what i thaught :

1 headscale admin in it's current form is good but easily limited by api-key and no has memory (and multiplatform data export ) 2 the most advanced useful features and settings are limited to database and direct commands 3 an all in one headscale-admin is impossible to have because point 1 and point 2 are incompatible by their approach

If we think of it, the only option would be to make a fork of the actual release with DB support and with some security changes. Release 1 headscalse-admin-light for it's lightweight and adaptability functions, release 2 headscale-admin-pro for it's more advances functions and maybe an admin and client access control (admin can change/ modify / delete everything and clients could only register nodes or a few other things related and limited to their own registered machines wich could be verified by DB). It could also allow admin to access config file in a web form and edit on the fly the settings (of course that could be dangerous but also incredibly powerfull, flexible and usefull). Maybe (it would need some test) it could even allow to create some isolated networks in the same headscale server (client A and B use 100.64.0.XXX and client C and D use 100.64.8.XXX).

Unfortunately that implies more work and even if I would love to help you on this, my coding knowledge is limited to C and C++ on arduino and esp8266/32 chips, I don't think it would help at all.

[Virtualchronos]

I've seen that headscale has been updated to alpha 8, do you need a tester ?