starred/headscale
1
0
Fork 0
mirror of https://github.com/juanfont/headscale.git synced 2026-01-11 20:00:28 +01:00
Code Issues 98 Packages Projects Releases 10 Wiki Activity

[Bug] Security Issue - Unwanted Control Plane client (bot/scraper/monitoring of users?) #1041

New Issue
Closed
opened 2025-12-29 02:27:53 +01:00 by adam · 1 comment
adam commented 2025-12-29 02:27:53 +01:00
Owner
Copy Link

Originally created by @metrafonic on GitHub (May 28, 2025).

Is this a support request?

  • This is not a support request

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

Digging through my reverse proxy logs, i noticed a suspicious VPN IP address connecting to my recently retired headscale instance. It was doing HTTP POSTs to /ts2021.

I expired all clients, machines, and pre-auth keys, and the host still continued to interact with the control plane.

Performing a tcp dump on the HTTP traffic between the reverse proxy and headscale, there was no indication in the http response that the session was invalid, just a session upgrade response. The POST data looked legitimate, although I could not assess the validity of the token that was included.

There was no way to see this control plane client using headscale-ui, or the headscale client interface. I was only able to detect it via HTTP traffic logs.

I have a strong suspicion that this client was custom made for monitoring/scraping. The traffic pattern deviated from other legitimate clients that were trying to connect. I have more details on this if needed.

Expected Behavior

I would expect some sort of unauthorized response from the server, especially when there are no non-expired clients or keys available. There should also be some sort of log or similar to identify such nodes.

I can assume maybe one of my clients could have been compromised at one point, but even with expired clients, this seems bad.

Steps To Reproduce

headscale v0.25.1 running in docker compose, with HAProxy as a reverse proxy

Environment

- OS: Docker on Ubuntu
- Headscale version: v0.25.1
- Tailscale version: latest

Runtime environment

  • Headscale is behind a (reverse) proxy
  • Headscale runs in a container

Debug information

I have PCAPs of the traffic.

Originally created by @metrafonic on GitHub (May 28, 2025). ### Is this a support request? - [x] This is not a support request ### Is there an existing issue for this? - [x] I have searched the existing issues ### Current Behavior Digging through my reverse proxy logs, i noticed a suspicious VPN IP address connecting to my recently retired headscale instance. It was doing HTTP POSTs to `/ts2021`. I expired all clients, machines, and pre-auth keys, and the host still continued to interact with the control plane. Performing a tcp dump on the HTTP traffic between the reverse proxy and headscale, there was no indication in the http response that the session was invalid, just a session upgrade response. The POST data looked legitimate, although I could not assess the validity of the token that was included. There was no way to see this control plane client using headscale-ui, or the headscale client interface. I was only able to detect it via HTTP traffic logs. I have a strong suspicion that this client was custom made for monitoring/scraping. The traffic pattern deviated from other legitimate clients that were trying to connect. I have more details on this if needed. ### Expected Behavior I would expect some sort of `unauthorized` response from the server, especially when there are no non-expired clients or keys available. There should also be some sort of log or similar to identify such nodes. I can assume maybe one of my clients could have been compromised at one point, but even with expired clients, this seems bad. ### Steps To Reproduce headscale v0.25.1 running in docker compose, with HAProxy as a reverse proxy ### Environment ```markdown - OS: Docker on Ubuntu - Headscale version: v0.25.1 - Tailscale version: latest ``` ### Runtime environment - [x] Headscale is behind a (reverse) proxy - [x] Headscale runs in a container ### Debug information I have PCAPs of the traffic.
adam added the bug label 2025-12-29 02:27:53 +01:00
adam closed this issue 2025-12-29 02:27:53 +01:00
adam commented 2025-12-29 02:27:53 +01:00
Author
Owner
Copy Link

@metrafonic commented on GitHub (May 28, 2025):

Ok, after more investigation, it is not as serious as first assumed. A user had a mobile device on this IP. However i still find it strange that this device was not being updated in the client-list.

I suspect that my headscale instance may have been corrupted, and therefore not responding to client messages correctly. Closing for now.

@metrafonic commented on GitHub (May 28, 2025): Ok, after more investigation, it is not as serious as first assumed. A user had a mobile device on this IP. However i still find it strange that this device was not being updated in the client-list. I suspect that my headscale instance may have been corrupted, and therefore not responding to client messages correctly. Closing for now.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
CLI
DERP
DNS
Nix
OIDC
SSH
bug
database
documentation
duplicate
enhancement
faq
good first issue
grants
help wanted
might-come
needs design doc
needs investigation
no-stale-bot
out of scope
performance
policy 📝
pull-request
Mirrored from GitHub Pull Request
 question
regression
routes
stale
tags
tailscale-feature-gap
well described ❤️
wontfix
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#1041
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?