Export all hosts/client IDs?

[Xavier Mertens]

Is there a way to quickly export all ClientId's and corresponding hostnames?

(by example in a CSV format)

/x

[Wes Lambert]

How about something like the following in a notebook, then export to CSV. 

SELECT client_id AS ClientId, os_info.hostname AS Hostname FROM clients()

--
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/76e219dc-23fc-47ba-b039-83f70cd5cc37n%40googlegroups.com.

--

https://twitter.com/therealwlambert

https://securityonion.net/

[Xavier Mertens]

So nice! Tx!

/x

[Mike Cohen]

Just collect this

https://docs.velociraptor.app/artifact_references/pages/server.information.clients/

[Gert Koopman]

Thats a great way to regularly create an overview of the clients, thanks! Question: when a client image is cloned and spun up including the exact same agent client config and same hostname will there be a new ClientId generated and/or do you get duplicates in the velociraptor management server? Any risk of overwriting historic info (firstseen at lastseen at timestamps for example). Use case: base image used to install large groups of computers with identical function using cloning method, then only hostname is changed, wondering if reinstall velociraptor agent afterwards is required to guarantee uniqueness. Second use case: VM image cloned to now run on upgraded hardware.

Txs

Op vr 26 aug. 2022 23:21 schreef Mike Cohen <mi...@velocidex.com>:

To view this discussion on the web visit https://groups.google.com/d/msgid/velociraptor-discuss/CACREbPBXWhGh2nRt_bN33Z-BFN0%3DLw_4C2ykxOW47bfGR52htA%40mail.gmail.com.

[Mike Cohen]

The client id is derived from the client's public key. When the client starts up it loads it key from the write back file and therefore maintains its client id from there . if a write back is missing then the client wll create a new key and write it in the writeback file.

Sometimes people accidentally deploy a client into the base image and then each new image will have the same writeback file and will claim it is the same client id. The server does not allow more than one client of the same client id to connect at the same time (to avoid confusion) so one client will be connected and everyone else will be rejected with a conflict message.

Since 0.6.4 i think we have Server.Monitor.ClientConflict artifact that is a server monitoring artifact. If you find you accidentally imaged the client write back to the base image, you can add this artifact to the server event table to force duplicated clients to rekey and overwrite their writeback with new keys and client ids.

https://docs.velociraptor.app/artifact_references/pages/server.monitor.clientconflict/

Thanks

Mike

Mike Cohen  Digital Paleontologist,  Velocidex Enterprises E mi...@velocidex.com