Deploying Sensors

A machine-readable (YAML) link to the latest version of the LimaCharlie Enterprise sensor is here.

Direct links are also available from

The sensor is signed and the same for everyone. The sensor's customization (who is the owner) is done at installation time based on the installation key used. The installation key specifies where the sensor should connect to enroll as well as the encryption key used to start the enrollment process.

Installing the sensor does not require a reboot. Also note that once installed the sensor does not have any visual components so instructions on confirming it is installed and running are found below.


The network connection required by the LimaCharlie sensor is very simple. It requires a single TCP connection over port 443 to a specific domain, and optionally another destination for the Artifact Collection service.

The specific domains are listed in the Sensor Downloads section of your organization's dashboard. They will vary depending on the datacenter you chose to create your organization in.

Currently, web proxies are not supported, but since LimaCharlie requires a single connection to a single dedicated domain, it makes creating a single exception safe and easy.

Downloading the Sensors

To download the single installers relevant for your deployment, access the /download/[platform]/[architecture] control plane. The platform component is one of win, linux or osx while the architecture component is either 32 or 64.

For example:

  • for the Windows 32 bit executable installer
  • for the Windows 64 bit executable installer
  • for the Windows 32 bit MSI installer
  • for the Windows 64 bit MSI installer
  • for the Linux 64 bit installer
  • for the Linux Apline 64 bit installer
  • for the Linux ARM 32 bit installer
  • for the Linux ARM 64 bit installer
  • for the MacOS 64 bit installer
  • for the Chrome extension

Installing the Sensor

The sensors are designed to be simple to use and re-package for any deployment methodology you use in your organization.

The sensor requires administrative privileges to install. On Windows this means an Administrator or System account, on MacOS and Linux it means the root account.

Before installing, you will need the installation key you want to use,


Executing the installer via the command line, pass the -i INSTALLATION_KEY argument where INSTALLATION_KEY is the key mentioned above. This will install the sensor as a Windows service and trigger its enrollment.

You may also install the Windows sensor using the MSI version. With the MSI, install using: installer.msi WRAPPED_ARGUMENTS="INSTALLATION_KEY".

System Requirements

The agent supports Windows XP 32 bit and up (32 and 64 bit). However, Windows XP and 2003 support is for the more limited capabilities of the agent that do not require kernel support.

Checking it Runs

In an administrative command prompt issue the command sc query rphcpsvc and confirm the STATE displayed is RUNNING.


Executing the installer via the command line, pass the -i INSTALLATION_KEY argument where INSTALLATION_KEY is the key mentioned above. This will install the sensor as a launchctl service and trigger its enrollment.

System Requirements

All versions of 64 bit macOS 10.9 and above are supported. If you need more, contact us.

Checking it Runs

In a Terminal, run the command sudo launchctl list | grep com.refractionpoint.rphcp which should return a single record with the first column of the output being a number (a - indicates it is NOT running).

Important Note

On MacOS, Apple has recently made installing kernel extensions (as the one used by LimaCharlie) much harder. Unfortunately this is entirely outside of our control. LC as well as many other vendors are affected by this. The net effect of this is that the first time the sensor installs onto a MacOS system, a popup will appear asking the user to go in the Security Control Panel and manually click on the button to approve the installation of the kernel extension.

Currently, the only way to automate the installation of the extension is to use an Apple approved MDM solution. These solutions are often used by large organizations to manage their Mac fleet. If you are using such a solution, see your vendor's documentation on how to add a kernel extension as whitelisted to your entire fleet.

We're aware this is a big inconvenient and hopefully Apple will eventually provide a solution for security vendors.


Executing the installer via the command line, pass the -d INSTALLATION_KEY argument where INSTALLATION_KEY is the key mentioned above.

Because Linux supports a plethora of service management frameworks, by default the LC sensor does not install itself onto the system. Rather it assumes the "current working directory" is the installation directory and immediately begins enrollment from there.

This means you can wrap the executable using the specific service management technology used within your organization by simply specifying the location of the installer, the -d INSTALLATION_KEY parameter and making sure the current working directory is the directory where you want the few sensor-related files written to disk to reside.

Common Linux packages may be available in the future.

A common methodology for Linux is to use init.d, if this sufficient for your needs, see this sample install script. You can invoke it like this:

sudo chmod +x ./

System Requirements

All versions of Debian and CentOS starting around Debian 5 should be supported. Due to the high diversity of the ecosystem it's also likely to be working on other distributions. If you need a specific platform contact us.

Containers and Virtual Machines

The LimaCharlie sensor can be installed in template-based environments whether they're VMs or Containers.

The methodology is the same as described above, but you need to be careful to stage the sensor install properly in your templates.

The most common mistake is to install the sensor directly in the template, and then instantiate the rest of the infrastructure from this template. This will result in "cloned sensors", sensors running using the same Sensor ID (SID) on different hosts/VMs/Containers.

If these occur, a sensor_clone event will be generated as well as an error in your dashboard. If this happens you have two choices:

  1. Fix the installation process and re-deploy.
  2. Run a de-duplication process with a Detection & Response rule like this.

Preparing sensors to run properly from templates can be done in one of two ways:

  1. Run the installer on the template, shut down the service and delete the "identity files".
  2. Script the sensor installation process in the templating process.

For solution 1, the identity files you will want to remove are:

  • Windows: %windir%\system32\hcp*
  • Linux: depending on the install location of the sensor, the hcp* files like /usr/local/hcp*.
  • MacOS: /usr/local/hcp*

For solution 2, you can start a simple shell script like this to fetch the installer and run it on first boot:

#! /bin/bash

# Create a directory where the install will live.
mkdir lc_sensor

# Set the permissions on the directory to be limited to root.
chown root:root ./lc_sensor
chmod 700 ./lc_sensor

# Installer the sensor from within the directory to it install to the CWD.
cd lc_sensor

# Use an environment variable containing the Installation Key.
# Write it to a temporary file to limit the exposure of the key.
echo $LC_SENSOR_INSTALLATION_KEY > lc_installation_key.txt

# Fetch the latest sensor installer from
wget -O lc_sensor_64

# Limit permissions to the sensor.

# Run the sensor.
chmod 500 ./lc_sensor_64
./lc_sensor_64 -d - > /dev/null 2>&1 &

# Remove the Installation Key from the environment.

# We started the sensor detached, so we give it a few seconds to read
# the Installation Key we put on disk before deleting it.
sleep 2
rm lc_installation_key.txt

cd ..

Container Clusters

You can also run LimaCharlie at the host level in a container cluster system like Kubernetes in order to monitor all running containers on the host with a single sensor. In fact, this is the prefered method as it reduces the overhead of running LC within every single container.

This is accomplished by a combination of a few techniques:

  1. A privilged container running LC.
  2. LC runs with HOST_FS environment variable pointing to the host's root filesystem mounted within the container.
  3. LC runs with the NET_NS environment variable pointing to the host's directory listing network namespaces.
  4. Running the container with the required flags to make sure it can have proper access.

The first step is straight forward, for example, set the environment like ENV HOST_FS=/rootfs and ENV NET_NS=/netns as part of your Dockerfile. This will let the LC sensor know where it can expect host-level information.

The second step is to run the container like: docker run --privileged --net=host -v /:/rootfs:ro --env HOST_FS=/rootfs --env NET_NS=/netns --env LC_INSTALLATION_KEY=your_key your-lc-container-name.

Remember to pick the approriate LC sensor architecture installer for the container that will be running LC (not the host). So if your privileged container runs Alpine Linux, use the alpine64 version of LC.

A public version of the container described below is available from dockerhub as: refractionpoint/limacharlie_sensor:latest.

Sample Configurations

This is a sample Dockerfile you may use to run LC within a privileged container as described above:

# Requires an LC_INSTALLATION_KEY environment variable
# specifying the installation key value.
# Requires a HOST_FS environment variable that specifies where
# the host's root filesystem is mounted within the container
# like "/rootfs".
# Requires a NET_NS environment variable that specific where
# the host's namespaces directory is mounted within the container
# like "/netns".
# Example:
# export ENV HOST_FS=/rootfs
# docker run --privileged --net=host -v /:/rootfs:ro -v /var/run/docker/netns:/netns:ro --env HOST_FS=/rootfs --env NET_NS=/netns --env LC_INSTALLATION_KEY=your_key refractionpoint/limacharlie_sensor

FROM alpine

RUN mkdir lc

RUN wget -O lc_sensor
RUN chmod 500 ./lc_sensor

CMD ./lc_sensor -d -

And this is a sample Kubernetes deployment:

apiVersion: apps/v1
kind: DaemonSet
  name: lc-sensor
  namespace: lc-monitoring
    app: lc-monitoring
  minReadySeconds: 30
    type: RollingUpdate
      maxUnavailable: 1
      app: lc-monitoring
      namespace: lc-monitoring
        app: lc-monitoring
        - name: lc-sensor
          image: refractionpoint/limacharlie_sensor:latest
          imagePullPolicy: IfNotPresent
            allowPrivilegeEscalation: true
            privileged: true
              memory: 80M
              cpu: 0.01
              memory: 128M
              cpu: 0.9
            - mountPath: /rootfs
              name: all-host-fs
            - mountPath: /netns
              name: all-host-ns
            - name: HOST_FS
              value: /rootfs
            - name: NET_NS
              value: /netns
            - name: LC_INSTALLATION_KEY
              value: <<<< YOUR INSTALLATION KEY GOES HERE >>>>
        - name: all-host-fs
            path: /
        - name: all-host-ns
            path: /var/run/docker/netns
      hostNetwork: true


The Chrome sensor is available in the Chrome Web Store.

  1. In the LimaCharlie web app (, go to the "Installation Keys" section, select your installation key and click the "Chrome Key" copy icon to copy the key to your clipboard.
  2. Install the sensor from:
  3. A new tab will open where you can add your installation key from before. If you close it by mistake, you can re-open it by:
  4. From the Extensions page at chrome://extensions/ click on the "Details" button of the LimaCharlie Sensor extension.
  5. Go to the "Extension options" section, and enter your installation key from the previous step. Click save.

The installation key can also be pre-configured through the Managed Storage feature (key named installation_key) if you are using a managed Chrome deployment.

Staging Deployment

When a new version of the sensor is made available, it can be useful to test the new version on specific hosts within an Organization without upgrading the whole Organization.

This can be achieved using a sensor tag called latest. When you tag a sensor with latest, the sensor version currently assigned to the Organization will be ignore for that specific sensor and the latest version of the sensor will be used instead. This means you can tag a representative set of computers in the Organization with the latest tag in order to test-deploy the latest version and confirm no negative effects.

Uninstalling the Sensor

Using an installer, as administrator / root, simply invoke it with one of:

-r to remove the sensor but leave in place the identity files. This means that although the sensor is no longer running, re-running an installer will re-use the previous sensor config (where to connect, sensor id etc) instead of creating a new one.

-c to remove EVERYTHING. This means that after a -c, the previous sensor's identity is no longer recoverable. Installing a new sensor on the same host will result in a brand new sensor registering with the cloud.