Installing Agent on macOS
Purpose
This document describes how to install Outpost24 Agents mobile assets that are rarely office based.
Introduction
The Outpost24 Agent is primarily designed for mobile employees who are rarely office based, but still requires vulnerability scanning of their assets. When working remotely, often via a VPN, it is not possible to run a remote vulnerability scan of these assets as it can have a serious impact on network performance. Using the Outpost24 Agent, makes it possible to get these results, with no impact on network capacity, giving details of missing patches, updates, and hotfixes for both OS and common business software.
It is recommended that the Outpost24 Agent is deployed and updated using your normal software deployment method. Follow the best practices of these software deployment mechanisms to ensure a successful installation. The methods outlined in this document guide you through the steps needed for a successful installation.
When running an Outpost24 Agent, some Anti Virus/Anti-Malware software will trigger on the agent.
To avoid triggering the AV/Malware platform, the path to the agents executable need to be whitelisted.
Example from Bitdefender
Requirements
It is required for agents to have full connectivity to teddysalad.outpost24.com
The MacOS Agent only support x64.
Installing the Agent
Overview
The following flowchart illustrates the two mechanisms through which a macOS Agent may be configured and enrolled.
For automated deployment to a large number of targets we recommend flow A, in which the system administrator first manually obtains an enrollment configuration file which is then deployed to the entire fleet.
In flow B, the agent application is instead provided with a REST API token and retrieves its configuration file from its enrollment host. This flow implies additional network traffic overhead and the potential exposure of a more general credential.
Flow A
This flow reduces the required network communication between the agent and the enrollment host, and also minimizes the exposure of the REST API token needed for enrollment configuration file acquisition.
Obtain enrollment configuration file
The system administrator installs the agent application on a single system, from which the enrollment configuration is bootstrapped.
This configuration file, which contains a long-lived enrollment token, is then deployed to all targets in the subsequent step.
Refer to the Acquiring_JSON and Obtaining Enrollment Configuration sections for guidance.Install agent .pkg and enrollment configuration file on targets
The enrollment configuration file is placed in the/etc/o24-agent.conf.d/
directory and the agent binary is installed to/usr/local/bin/o24-agent
. (see Installing the macOS Agent).
Granted that the configuration file is valid and readable, the agent will be able to enroll on first startup.
The configuration file should be owned by the root user and have its permissions set to 640.
Flow B
In this flow, the agent application retrieves its enrollment configuration file using a REST API token; automated installation on multiple targets using this flow would entail issuing a longer-lived token and distributing it to all installation targets.
Install agent .pkg on target(s)
Refer to the instructions in the Installing the macOS Agent section.Obtain enrollment configuration file
Obtain a REST API token and subsequently the enrollment configuration file as described in Acquiring_JSON and Obtaining Enrollment Configuration.
After concluding either flow A or B, see Starting the service for finalization.
Installing the macOS Agent
If you have access to the GUI, double-click the downloaded
.pkg
file and follow the installation wizard instructions.If prompted to choose installation directory, use the default (the volume the OS is installed to).
Otherwise, from the command-line, use the following command:
BASHinstaller -pkg <path-to-agent.pkg> -target /
Retrieve a REST API Token From XMLAPI
It is possible to retrieve a REST API token through the XMLAPI action GETRESTTOKEN
by using the XMLAPI apptoken.
This procedure requires a super user account.
Generate an API Token in the OUTSCAN UI Menu Menu > Settings > Security Policy.
With that key, run the API command
CODEhttps://<O24-URL>/opi/XMLAPI?ACTION=GETRESTTOKEN&APPTOKEN=<Key from Step 1>
<O24-URL>
could be either https://outscan.outpost24.com/ or your HIAB IP Address/FQDN.
A token is returned that lasts 10 minutes from the REST API.
Acquiring a JSON Web Token (JWT) for Interfacing with the Outpost24 REST API
An Outpost24 REST API may be acquired by issuing a POST request to the /opi/rest/auth/login
endpoint. The endpoint accepts the following request body parameters:
username
(mandatory) - Outpost24 sign-in username.password
(mandatory) - Outpost24 sign-in password.validUntil
(optional) - Timestamp indicating when the token will expire; default lifetime is 10 minutes.code
(optional) - Two-factor authentication (2FA) code, required if enabled for the user account.
Example POST request using cURL:
read -p "Username: " USER && \
read -sp "Password: " PASS && echo && \
curl --data-urlencode "username=${USER}" --data-urlencode "password=${PASS}" https://outscan.outpost24.com/opi/rest/auth/login && echo && \
unset USER PASS
Before Getting Enrollment Configuration
Make sure that the config folder has created properly.
mkdir /etc/o24-agent.conf.d
Obtaining Enrollment Configuration
The /usr/local/bin/o24-agent
binary provides a command fetch-enrollment-config
, it retrieves a configuration file and installs it to /etc/o24-agent.conf.d/10-base.yml
.
/usr/local/bin/o24-agent fetch-enrollment-config --token "<token>"
This command requires the following mandatory arguments:
--url:
This should point to the OUTSCAN/Scheduler that you wish to run against; this defaults to https://outscan.outpost24.com.
--token:
This should be a valid, non-expired JWT for the Outpost24 REST API, as outlined above.In order to restrict the token scope, we recommend issuing the JWT for an IAM restricted sub-user.
This command accepts the following optional arguments:
--no-config-install
: This skips installing the configuration file to/etc/o24-agent.conf.d/
, instead leaving it available in/tmp/
.By obtaining the configuration file in this manner you may subsequently incorporate it into a specific deployment workflow, for example automatically placing it in
/etc/o24-agent.conf.d/
during installation, Sidestepping the need to expose a valid JWT in the same flow.See the "Enrollment flow overview" for additional information.
--insecure-skip-verify
: Skips TLS certificate validation for the given--url
.Should only be utilized if required for particular DSAgent deployments.
This command must be invoked as the root user due to the privileged configuration file location.
Starting the Service
After the enrollment configuration file has been obtained, launch the agent service as such:
launchctl load -w /Library/LaunchDaemons/com.outpost24.agent.plist
On first run, the agent is enrolled against the OUTSCAN or Scheduler instance. This operation includes a randomized timeout in order to support large-scale deployments, and may thus require up to an hour to conclude.
Related Articles
- Using the Agent Info Command
- Updating the Agent
- Retrieving the Agent UUID
- Adding Agent Attributes
- Checking if Agent is Running
- Updating Agent Attributes
- Finding the Agent Version
- Retrieving Results From the Agent in OUTSCAN
- Discovering the Agent in OUTSCAN
- Removing an Agent from Windows
- Finding New Agents In OUTSCAN
- Setting Up the Firewall for Agents
- Checking Schedules from OUTSCAN in Agent
- Checking if the Agent has Produced Results
- Downloading Agents
Copyright
© 2024 Outpost24® All rights reserved. This document may only be redistributed unedited and unaltered. This document may be cited and referenced only if clearly crediting Outpost24® and this document as the source. Any other reproduction and redistribution in print or electronically is strictly prohibited without explicit permission.
Trademark
Outpost24® and OUTSCAN™ are trademarks of Outpost24® and its affiliated companies. All other brand names, product names or trademarks belong to their respective owners.