Renaming a GRR Server & Client Configuration

Renaming the Server & Updating the Clients

Rather than rebuilding a new server for every deployment you may feel it is easier to build a clean virtual build and clone that for each customer. As such renaming the VM would be potentially very useful. The issue is that you have set the URL for the agents now, so if you deploy one it wont communicate. So lets look at how to change it. This also works if you accidentally type in the wrong name 🙂

Firstly you need to know where the configurations for the clients are:

/etc/grr/server.local.yaml

As you scroll through the file, using your favourite text editor, you will notice between the public and private keys are the settings you need to update. Namely:

  • AdminUI.url
  • Client.control_urls

admin_ui_url client_control_url

Updating the Clients

Once this configuration has been changed the clients will need to be repacked. This is done using the following command

$sudo grr_config_updater repack_clients

This will give you a new set of binaries in your installers folder

new_agents

The top most dbg files have the old URL the latest 4 files have the new URL, I can only assume for debugging and fault finding purposes.

To prove that your agent has the correct control URL type the following command

$strings <client file> | grep http

The output should look something like

strings_old_vs_new

You can see the old file had a URL of “http://linux1:8080/control&#8221; and the new one has a URL of “http://ubuntu:8000/control&#8221;.

As a paranoid incident responder I recommend changing the defaults if you use this to carry out the identification phase in an investigation as you wont know what access the bad guy has.

More GRR stuff to come as I find it 🙂

This entry was posted in Google Rapid Response, GRR, Incident Response and tagged , , , . Bookmark the permalink.

Leave a comment