I have gone through the blog posts and documentation present on the Velocidex website to understand various aspects of the deployment.
The current documentation indicates an internal PKI setup as follows:
Create initial server certificates and any additional certificates for key rotation.
CA public certificate is embedded in the client’s configuration and is used to verify server communications.
The CA is used to create API keys for programmatic access. The server is then able to verify API clients.
But the documentation doesn’t indicate any mechanism that the server can authenticate and verify the clients.
One way to counter this situation is to implement client-side certificates which the server can verify. But this means the client certificate's private key will be exposed on each endpoint and every endpoint that will be using the same certificate.
In our corporate infrastructure we deploy the agent-based clients with static configuration pointing towards the server. We are planning to follow the same method for deploying Velociraptor clients. Unfortunately, this creates a risk in scenarios where a rogue client makes an out of band unauthorized communication with the server.
Based on the above two situations, is there any method you can suggest where we can limit or restrict the initiation of communication from the client side?
In general, I am looking for a solution that will prevent exploitation of clients or if a client goes rogue while communicating to the server.
I would greatly appreciate it if you could help me provide any solution to the above-mentioned problem and please do let me know if you have any follow-up questions or concerns.
Thanks,
|
--
You received this message because you are subscribed to the Google Groups "velociraptor-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to velociraptor-dis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/velociraptor-discuss/ddb20124-a175-4777-8763-4a44c2456f6en%40googlegroups.com.
Hello Mike,
Thanks for the quick response.
I agree with the introduction of nonce on client & server configuration, we can use it as a shared secret and create trust between client & server.
How do we manage the nonce?
Does this nonce remain constant? Or is there a method on the server side which can create a new nonce via command or something? Currently, in our infrastructure the client agent binary will be in dormant state and only when required based on investigation task, we will enable the binary.
Can we enable a client binary with an updated client.config.yaml(xml) file every time? If this is possible we might be able to use this idea to generate nonce on server side and replicate nonce onto client config and run client with new configurations.
To view this discussion on the web visit https://groups.google.com/d/msgid/velociraptor-discuss/cf83ec3e-6200-470a-87d9-bb3d9a0bce77n%40googlegroups.com.
Is there a method on the server side where we can create a new nonce via command or something?
Can we run a client binary with an updated client.config.yaml(xml) file every time? If this is possible we might be able to use this idea to generate nonce on server side and replicate nonce onto client config and run client with new configurations.