Security Ripcord

Cutaway Security Blog and Projects

Deploying GRR Clients With GRR Docker

For the TL;DR crowd, GRR Rapid Response can be configured to run on a development or small test network using GRR Docker. The GRR setup requires a repack of the GRR client as described in the repacking the client documentation and installation of the clients as described in the GRR Quick Start: Install the Clients documentation. There are a few caveats to getting it configured so that the GRR Clients can communciate with the GRR Server running in Docker. These steps are covered in this blog post.

In last weeks blog post, Creating a Docker IEEE 802.15.4 Toolkit, I talked about getting Docker up and running to test GRR Rapid Response. Installing GRR Docker is straight foward and outlined by GRRs Getting Started documentation. I will begin from there.

Accessing the Docker command line interface was covered in the last blog post. As I mentioned, selecting the “Docker CLI” button will open a terminal interface. If running Docker on a Windows 10 system, as I am, this will be a PowerShell terminal. While usable, it have found that it does not work well when interacting with Docker or one of the containers. Instead, I recommend finding another terminal that will provide a better interactive experience. To this end I started using Cygwins terminal to ssh to the Docker command line.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
cutaw@cutsec-sager ~
$ ssh docker@192.168.99.100
docker@192.168.99.100's password:
                        ##         .
                  ## ## ##        ==
               ## ## ## ## ##    ===
           /"""""""""""""""""\___/ ===
      ~~~ {~~ ~~~~ ~~~ ~~~~ ~~~ ~ /  ===- ~~~
           \______ o           __/
             \    \         __/
              \____\_______/
 _                 _   ____     _            _
| |__   ___   ___ | |_|___ \ __| | ___   ___| | _____ _ __
| '_ \ / _ \ / _ \| __| __) / _` |/ _ \ / __| |/ / _ \ '__|
| |_) | (_) | (_) | |_ / __/ (_| | (_) | (__|   <  __/ |
|_.__/ \___/ \___/ \__|_____\__,_|\___/ \___|_|\_\___|_|
Boot2Docker version 1.11.1, build HEAD : 7954f54 - Wed Apr 27 16:36:45 UTC 2016
Docker version 1.11.1, build 5604cbe
docker@default:~$

Logging into Docker via SSH requires the username “docker” and password “tcuser”. This provides access to Docker via a Busybox shell. Running the command docker will produce a list of options to interact with individual or multiple containers. Some of the most useful commands are docker images, used to obtain a list of installed containers, and docker ps, used to obtain a list of running containers. Once a container is running the command docker exec is used to interact with that container.

To ease in the repeated use of the exec command I decided to set up a few aliases. Dockers Busybox uses the “.ashrc” file to manage configuration settings. I added one command to connect to a container with a Bash shell, _con, and another to run the Screen command with Bash, _screen_con. The later requires the installation of screen within that container and I also configure the system to use a .screenrc file. The following textbox shows my updates to the .ashrc file.

1
2
3
4
5
6
7
8
9
10
11
12
13
[SNIP .ashrc content for brevity]

# Personal aliases.
_screen_con() {
    docker exec -i -t $1 /bin/bash -c \"export TERM=xterm; exec >/dev/tty 2>/dev/tty </dev/tty && /usr/bin/screen -s /bin/bash\"
}

_con() {
    docker exec -i -t $1 /bin/bash
}

alias screen_con='_screen_con'
alias con='_con'

Getting back to running GRR Docker. Once the GRR Docker container is up and running, using the commands provided on the GRR Docker instructions, the GRR server will accept connections to the administration interface on port 8000. GRR Clients will communicate back to the GRR server on port 8080. While this configuration is simple the issue is that Docker initially sets up a host only network. Meaning that while the GRR administration interface can be connected to from the local system it cannot be accessed by systems on the actual network. While this configuration may be okay for the administration interface it is not okay for any clients on the network.

For GRR Clients to connect to the GRR server a Port Forward has to be configured in the VirtualBox settings for Docker. Accessing VirtualBox was covered in the last blog post when updating the USB configuration was demonstrated. Modifying the network configuration is handled by selecting the Docker settings button and then accessing the “Network” settings. “Adapter 1” should be the interface that the Guest image uses to communicate with the Host. VirtualBox can be configured to forward a port from the Host IP address to the Guest IP address. Selecting the “Port Forwarding” button will open a pop-up window with the appropriate configuration settings. The following image shows the settings that were required to configure my test container.

VirtualBox Network Port Forwarding

Once configured correctly, the remote connectivity to the GRR Server can be tested by making a request for the GRR servers certificate, used for establishing secure communications with the GRR Clients. The following textbox is an example of using the ‘curl’ command to request the GRR Server’s certificate as a GRR client would from the remote system. If a certificate is not return then the there may be other issues such as a host-based firewall on the Host system.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
cutaw@cutsec-hp ~
$ curl http://192.168.1.3:8080/server.pem
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   955  100   955    0     0    955      0  0:00:01 --:--:--  0:00:01  932k-----BEGIN CERTIFICATE-----
M1oXDTE3MDYxMDE1MTEwM1owGzELMAkGA1UEBhMCVVMxDDAKBgNVBAMTA2dycjCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAPIusPCSkKkgKB/8Hul3Qdp2
8c3OAWwvCSUv1CrcCL8Kl7hq1Ve+C1AFY8qWSiDMF00dsMNlFOQjdycSOHMCvEp4
N6ovxnfB4cAEaSs8QdY0ZWffcwEaL/rnkFERsU6x9CrOCuzRxuyFJTOo0+oRq8vq
r5d1VwJ0pZ8AakQileiBIM7IdmAKW6VlhNaWQXRDNGCtyYM9WpWq3Iw9IFbJ+1r1
o5nJ9p3aO4RCwbYqErsV94ZJHpnNCmKoGYsgacNFsMoYjNwRkp7JIeKtdK7BpA0C
wD3Y7X9usRSSA7Wx6PqM6qD/X/vMU4d0Q24swh253rz92wpxOOj/HPxsTuyNclCX
vm3+Hra+cd0hwoiamPxjbp9/zix5t2SUC5/p5Inx42aQgZEUp8IZt4J7GrapeZbJ
0UaPAFQ6I6YY/Xf2S5ChenFG+nKZEYy02cQDtVl0tYzjqiJ5mzkGx7tkWSmWBwT3
uy3vwJJOPKNzdWhJkHj/WPCDw0DplyOddnsCo75Y1z8UxuNLjG7BMA==
-----END CERTIFICATE-----

Once the GRR Server is running correctly it is time to the get GRR Clients deployed and communicating with the server. Installation of the GRR Client is covered in the GRR Quick Start: Install the Clients documentation. Unfortunately, the GRR Clients in the GRR Docker implementation are configured to communicate to with the GRR Server using the following link: http://localhost:8000/control. The “localhost” host is not the same as the IP address assigned to the Host operating system (in this example it is 192.168.1.3) therefore the GRR Clients cannot actually connect back to the GRR Server. As with a production deployment, the GRR Clients need to be reconfigured to point to the URL associated with the GRR Server. GRR documentation describes this process as repacking the client.

While this should be a straight-forward process, and it is when it works, there is currently an issue with repacking GRR Clients. This most likely due to refactoring some of the GRR configuration code which means that the issues will be addressed by the GRR Team soon. I opened the topic Docker Client Repack and Network Issues on the GRR-Users Google Group and was quickly pointed to two relating GRR issues.

Following the information from these threads I successfully repacked the GRR Clients using the following command. The “-p” option allows the configuration of specific settings without modifying any of the configuration files. Using the full URL was necessary and must include the “http”, “:8080”, and “/control” in order for this stop-gap configuration setting to work.

1
grr_config_updater -p Client.control_urls="http://192.168.1.3:8080/control" repack_clients

NOTE: The GRR Team is actively working this issue. Check the documentation, GRR-User forum, and GRR issue pages to understand how to properly configure and repack the GRR Client in future versions.

Once repacked the new clients can be access by logging into the GRR Server administration page. Select the “Manage Binaries” in the left sidebar. Drill into “executables”, select the desired operating system, and then click on “installers”. This will provide a list of clients for the different types of OSes build automatically by the GRR Server. Currently the GRR Clients are named with the version of the GRR Server and I have not found a way to modify the GRR Client name in the configuration file. For now I rely on the “Age” field to determine if the GRR Clients are the version I need to deploy. Later I may want to rename the GRR Clients by hand so that I don’t have to rebuild each time for differnt deployments. The following image shows the successful build of the GRR Clients after troubleshooting the refactoring issue.

GRR Installer Binaries

Once the GRR Clients were configured I installed them on an OSX and a Windows system. Excitedly I returned to the GRR Server administration interface and stared at it. Hmmm, how do I locate GRR Clients. After a few minutes of poking around and then reading the GRR documentation I learned the easiest way to “find” clients is to “search” for them. This lead me to entering “192.168.1” in the search textbox and I was rewarded with information about the two systems I had deployed GRR Clients, as seen in the following image.

GRR Client Administration

What did I do next?

Actually, I started that but I realized I was not done testing. The next thing I did was check to see if I could get information back from the GRR Client. One-way communication was good, but I needed to ensure two way communications was possible. To test this I decided to get a list of running processes. I clicked on one of the GRR Clients and, once it was selected, the options in the left sidebar changed. I selected “Start new flows” and then drilled into “Processes” and “ListProcesses”. Without reading any of the information (pfft, why when there is a button right there) I clicked on “Launch”. The “flow” ran and, after a few moments, the button on the top right corner of the GRR Server administration interface changed from a blue “0” to a red “1”. I clicked on the button and it provided a pop-up window with a list of completed tasks. I selected the “ListProcesses” task and was taken to the “Browse Virtual Filesystem” page. The “ListProcesses” results were documented in the “analysis” -> “ListProcesses” folder. The initial display only provided information about the “flow” itself in the “Stats” tab. To get the results of the “flow” I selected the “Results” tab and was rewarded with a list of processes on that system during the time the “flow” was run. The following image shows this information.

GRR Client Process List

That is it. I now have a successful installation of GRR Rapid Response running out of Docker. Since the GRR Clients are communicating with the GRR Server I can now start reviewing the information provided by the GRR Clients and automating flows. NOW, I can dance a jig.

Go forth and do good things,
Don C. Weber (cutaway)