when running `--tls_dump` I see what appears to be...
# kolide
z
when running
--tls_dump
I see what appears to be html in the output, is that expected?
while I'm seeing the results go into kolide successfully from my test fleet, I'm also getting
tls negotiation
errors as well, and I'm attempting to figure out why that is
z
No. That probably means that you've configured osquery to hit the incorrect endpoints, or your LB is serving HTML for some reason.
Under normal conditions you will only see JSON in the
--tls_dump
output.
z
it's an AWS NLB, so it's entirely possible.
I see the html right after this
[14:00:57] ~$ I0903 14:00:58.274202 23479 tls.cpp:253] TLS/HTTPS POST request to URI: <https://dev.fleet.sec.xxxx.org>
It returns the node_key just fine, then a bunch of html
I can't imagine I'm hitting incorrect endpoints, given that the results from the queries are showing up.
z
There's nothing after
.org
?
Maybe you're missing
config_tls_endpoint
?
z
I don't think so, the test instance is pulling down configs, and
config_tls_endpoint
is configured in the flags file. It occurs to me that this is a result of the fleet server being behind a network gateway, and that' is what is returning the html.
z
If you are hitting the root path then it's pulling down the login page
So you need to figure out why osqueryd is hitting that path
It's probably one of the
_endpoint
flags missing
z
Copy code
sudo osqueryd --verbose --tls_dump --tls_hostname <http://dev.fleet.sec.xxx.org|dev.fleet.sec.xxx.org> --config_plugin tls --tls_server_certs /etc/osquery/certs/kolide_fleet.crt --logger_tls_endpoint /api/v1/osquery/log --config_tls_endpoint /api/v1/osquery/config --logger_plugin tls --enroll_tls_endpoint /api/v1/osquery/enroll --enroll_secret_path /etc/osquery/enroll_secret
I think I have all the endpoint flags defined.
should the
tls_hostname
be something else?
Copy code
--tls_hostname <http://dev.fleet.sec.xxx.org|dev.fleet.sec.xxx.org>
right now that's the url we use to get to the web ui
s
Well, what’s the html?
Maybe it’s telling you what’s wrong….
z
it's actually the html from the web ui...
z
Yeah, sounds like osquery is just hitting the root path and Fleet is serving the root path as expected.
z
well, the tls_hostname is the same URL has the ui so I guess that's expected. Not sure what would make them different.
z
osquery is supposed to append the
_endpoint
flags to the hostname. That's why I suggested checking that they are all configured properly.
z
so it'd be
<http://dev.fleet.sec.xxx.org/api/v1/osquery/{config|dev.fleet.sec.xxx.org/api/v1/osquery/{config>, enroll, log}
right?
I guess I don't understand, afaik I have configured things correctly.
z
Did you configure distributed read/write?
z
facepalm
that was set in my flags file, but not when I was running osquery from the command line
z
Ah yeah that could explain it
z
the html was being generated because it wasn't hitting the distributed endpoints, just the root hostname?
z
Correct. It would have just seen the login page because it wasn't hitting an api endpoint.
z
are the distributed endpoints used mainly for ad-hoc queries? I don't see a ton in the docs about them.
z
Yeah, just for ad-hoc queries
z
👍 Thank you, this was helpful. Would it be a correct statement to say if the distributed endpoints aren't configured, then any ad-hoc queries sent from fleet wouldn't make it to the hosts?
z
Yes
And if you don't want ad-hoc queries then you're best off setting
--disable_distributed
(which is the default) so osquery doesn't even try.
z
or in this case, fleet has the ability to send that config to hosts as well?
z
Yes, I believe osquery will respect that flag if set in Fleet.
z
Awesome, thank you!