Security

Configuration

The default configuration of Monitoring Agent is entirely insecure. The default configuration is provided for evaluation purposes only so you can test commands and get something working quickly, however you should secure the configuration before using it anywhere outside of a sandbox.

Monitoring Agent enables Remote Code Execution. The default configuration will permit any code to be executed on monitored hosts using publicly available credentials (in this repository!).

The following changes are recommended to improve the security of monitoring agent:

• Change the default credentials
• Use Client TLS Certificates
• Limit the IP's that can execute commands
• Enable executable allow-lists
• Enforce minisigned scripts only

Authentication

Monitoring Agent supports HTTP Basic Authentication, which is configured by default.

"Authentication": {
	"Username": "test",
	"Password": "secret"
},

Use randomly generated values for Username and Password, restrict access to these secrets to relevant personnel.

Security

In order to provide the highest amount of security available within monitoring-agent, settings such as this should be configured inside the Security block.

TLS

Monitoring Agent uses TLS for all connections. The server.crt and server.key should either be in the configuration directory optionally specified at runtime or stored alongside the monitoringagent executable. The server.key permissions/ACLs should be suitably restrictive.

	"DisableHTTPs": false,

This should only be enabled only for debugging purposes, this exists so that traffic captures can be used to capture raw output if required.

Client Certificates

Use client certificates. You will need to create a certificate authority. Change UseClientCertificates to true and set ClientCertificateCAFile to be the path to your CAs certificate file, which will need to be deployed with Monitoring Agent. The CA's private key should not be deployed with Monitoring Agent.

	"UseClientCertificates": true,
	"ClientCertificateCAFile": "ca-cert.pem",

These enforce that the connection from the client must provide a TLS certificate signed by the ca within the ClientCertificateCAFile; this provides a stronger level of trust between the server and the client than just the credentials being correct within the request.

Script Signing

Monitoring Agent supports execution of signed scripts. If SignedStdInOnly is changed to true, each script script used with the /runscriptstdin endpoint must be signed and Monitoring Agent will verify the signature before executing the script. This is not supported with the /runexecutable endpoint. It is not a security feature per se as Monitoring Agent can still be used to run ad-hoc commands but it does give the assurance that scripts executed on a host via a monitoring platform are the same as those in a repository/filestore.

Monitoring Agent uses minisign for script signing. Set PublicKey to be the minisign public key. The private key should not be present anywhere other than the place the scripts are signed and suitably protected.

	"SignedStdInOnly": true,
	"PublicKey": "<your minisign public key>",

IP Restrictions

Restrict the IP addresses of the hosts which can use the Monitoring Agent API with AllowedAddresses. This range should ideally be restricted to your monitoring servers themselves.

	"AllowedAddresses": ["127.0.0.0/8","10.10.10.10/32","10.10.10.11/32"],

Executable Allow-listing

	"ApprovedExecutablesOnly": true,
	"ApprovedExecutableArguments": {
		"C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe": [
			["-command", "-"],
			["-command","start-sleep 1"],
			["-command","Write-Host 'Hello, World'"],
			["-command","Write-Host \"Hello, World\""],
			["-command"]
		],
		"sh": [
			["-s"],
			["-c"]
		]
	}

This will enforce that monitoring agent will only execute the commands with one of the listed argument lists, helping to prevent arbitrary command execution.

Allowing Script Arguments

Having a hard allow-list of every argument passed to scripts etc. makes management and change of these scripts very difficult as it requires deployment estate-wide. As a compromise, we support the ability to enable any arbitrary arguments to be passed to an executed script. To be clear, these arguments are concatenated onto the ExecutableArguments, so if the underlying script executable (powershell, perl, python, bash etc) has poor argument parsing or does not pass all these through to the script being executed then this will permit arbitrary commands to be executed.

Securing the configuration.json file

It is recommended that the permissions/ACLs on the configuration.json are restricted so that only system administrators and the user running the Monitoring Agent service has access to the file.

Example configuration.json

See the repository: https://github.com/infraweavers/monitoring-agent/blob/master/configuration.json