As far as I understand, the most common case is when a single enroll_secret is used on all clients.
It seems like you can use several enroll_secret, but this is still not about the case of an individual secret (or certificate, as is often the case) for each user.
Suppose an one employee’s workstation was compromised, the attacker knew the Fleet address and port from osquery.flags and enroll_secret.
Please tell me if it is possible to potentially perform DoS or just generate thousands of fake hosts on Fleet and complicate the life of the information security department if it starts to automatically generate and send requests to enrollment (https://osquery.readthedocs.io/en/stable/deployment/remote/#tls-client-auth-enrollment)?
Are there any rate limits or other protection against this? Is this even possible?
Thank you for continuing to develop and improve Fleet!
04/05/2021, 3:26 PM
When a host enrolls with Fleet it uses the enroll secret to authenticate the first time, and then is issued a unique (per-host) node key that it uses for further authentication. This means that you can set up regular rotation (or rotate on demand) for enroll secrets to mitigate such issues. Already enrolled hosts will continue to work.
04/05/2021, 3:35 PM
In your opinion, from the point of view of your experience in developing and maintaining Fleet, it might be advisable to make a certain rate limit for enrollment based on IP (or hostname, or uuid, etc)? For example, once every 5 minutes or something like that.
04/05/2021, 6:30 PM
We've thought about such things... Partially I think it's going to be the job of the LB/proxy to handle malicious requests at the edge. It doesn't seem unreasonable to add some level of rate limiting for authenticated hosts. I'd be curious to hear more about what the community needs in this regard.