search

fleetdm / fleet

Open-source platform for IT, security, and infrastructure teams. (Linux, macOS, Chrome, Windows, cloud, data center)
https://fleetdm.com
Other
3.06k stars 424 forks source link

[FR] Separate internal / external endpoints #3614

Closed gavinelder closed 2 years ago

gavinelder commented 2 years ago

Goal

Currently fleet exposes all HTTP routes on a single port as such if a Company whiches to expose Fleet to the internet they will have to set up a custom proxy to implement custom routes based upon the endpoint URL, this is covered in the following blog post https://defensivedepth.com/2020/04/02/kolide-fleet-breaking-out-the-osquery-api-web-ui/

An example request for this feature https://osquery.slack.com/archives/C01DXJL16D8/p1621319635003900

How?

Expose specific endpoints such as /version /metrics/ on a different port, users can then opt to expose this port or not.

noahtalerman commented 2 years ago

Expose specific endpoints such as /version /metrics/ on a different port, users can then opt to expose this port or not.

@gavinelder which endpoints do you think are most important to expose on a different ports ? Is it just /version and /metrics ?

gavinelder commented 2 years ago

Unsure of the value of each endpoint here so can't answer in full.

The reasoning for /version /metrics was to limit unauthenticated which could expose information about an estate that could be used for reconnaissance purposes but there may be more.

I did a quick crt.sh scan for the word "Fleet" and identified a number of Fleet Deploys and queried these two endpoints, the majority of servers were behind NGINX however a number had blocked either version or metrics but not both, for example, I could see internal metrics but not the running version.

I think the FR should probably be as follows.

1) Have a mechanism to expose sensitive or unauthenticated endpoints on a different port / localhost etc. 2) Determine if endpoint has to be public or internal and move.

zwass commented 2 years ago

@gavinelder as you mentioned, #2322 will cover the metrics endpoint.

Even if we make the /version endpoint authenticated, it will still be possible to get the Fleet version by looking at the cache-busting value on the css/js served by fleet (eg. Fleet 4.11.0 serves /assets/bundle-0a20f5b7670ecfb66a81.css, Fleet 4.12.1 serves /assets/bundle-c54e1baaad4a18cd09b7.css). I'd prefer to leave /version for easier debugging.

What do you think? If we feel good about that, we can close this in favor of #2322.

gavinelder commented 2 years ago

Happy to close.

The intent was to protect from trivial metrics & sensitive information disclosure by this FR, basic auth on sensitive endpoints covers that.

I feel even though the CSS bundle may expose the version this would not be detected by mass web scanning activity for example.