search

osquery / osquery

SQL powered operating system instrumentation, monitoring, and analytics.
https://osquery.io
Other
21.84k stars 2.45k forks source link

[Feature Request] Allow carver TLS endpoint to differ from general TLS endpoint #4108

Open mattjane-okta opened 6 years ago

mattjane-okta commented 6 years ago

Background.

Currently it appears that both the start and continue endpoints for the carver require the endpoints to belong to the same domain and the general TLS endpoint used for configuration.

While this is understandable, it would be very beneficial to allow the carver to be located at a separate endpoint.

Use case

Enable flags --carver_start_endpoint and --carver_continue_endpoint to accept a fully qualified domain + path instead of just the path.

This allows for the separation of longer lived processes like a file carver to be separated in code and service from short lived tls sessions that we see in post requests from osquery nodes.

muffins commented 6 years ago

This is definitely on our roadmap for eventually, I just haven't had cycles to tackle it. As I mentioned in Slack, I'll see if I can find some time to hit it this week, but if someone beats me to it that'd be pretty cool ;)

groob commented 6 years ago

Related, since https://github.com/facebook/osquery/issues/3940 is about the TLS plugin and has a somewhat incompatible proposal (enforcing a specific versioned URL path for all TLS implementations)

@mattjane-okta I see the usecase for possibly wanting to point different endpoints to different servers. But how will you handle Authentication/Enrollment. If the TLS plugins would support separate servers for various endpoints then each endpoint must come with it’s own enrollment url, or the servers must be coupled among each other. I don’t see a proposed solution here but would be interested in your thoughts.

My approach to this would be to have a single proxy which routed regular TLS requests to one server and carver requests to another. Is that an option here?

securityclippy commented 6 years ago

@groob This is a fair question. In my particular use case, the concept was te use an API gateway with a lambda function backing it. The lambda function has the ability to tie back to the authentication used by the primary server, so auth is actually backed by the same system, but endpoints are provided at a different address.

Definitely a thing we can skip too if there's no support for it elswhere, this is quite specific.