Hardening Octopus

We pride ourselves on making Octopus Deploy a secure product. If you are hosting the Octopus Server yourself, you are responsible for the security and integrity of your Octopus installation. This guide will help you harden your network, host operating system, and the Octopus Server itself.

Before you begin

Octopus Deploy is a complex system with many security features baked in and tuned by default. Take some time to understand what we’ve built in to the product, and what you are ultimately taking responsibility for when self-hosting Octopus Deploy.

Learn about security in Octopus Deploy.

Reading this guide carefully before you begin will help you prepare all the secure networking and server infrastructure you need for your Octopus installation. If you need any help along the way, don’t hesitate to get in touch!

Depending on your scenario you may want to relax or ignore these recommendations.

Familiarize yourself with Octopus Server

If you consider networking, the host operating system, Microsoft SQL Server, and Octopus Server: it is very likely Octopus Server is the new kid on the block. You should consider downloading a free trial of Octopus Server and setting it up on your local machine so you are familiar with how it works. This will eliminate some potential surprises as you progress through the security hardening.

Learn about getting started with Octopus Deploy.

Choose your order for hardening

Depending on your familiarity with Octopus Server, or SQL Server, or networking, or your host operating system, you should consider the order in which you perform the hardening. For example, if you are unfamiliar with Octopus Server, perhaps you should start there, getting your server up and running and working as you’d expect, then move on to the host operating system, the SQL Server, and finally your networking.

Harden your Octopus Server

1. Upgrade to the latest version.
2. Securely expose your Octopus Server to your users, infrastructure, and external services
   1. Use HTTPS over SSL.
   2. Configure HTTP security.
3. Configure your workers.
4. Configure the way Octopus Server communicates with deployment targets.

Upgrade to the latest version

Generally speaking, the latest available version of Octopus Server will be the most secure. You should consider a strategy for keeping Octopus Server updated. We follow a responsible disclosure policy so it is possible for you to be aware of any known issues which affect the security and integrity of your Octopus Server.

Securely expose your Octopus Server

For Octopus Server to be useful you need to expose its HTTP API to your users, and perhaps your infrastructure and some external services. There are many different approaches to solving this problem, but at its core you will want to:

1. Use HTTPS over SSL. Learn about safely exposing your Octopus Server.
2. Configure the built in HTTP security features as appropriate for your scenario. Learn about HTTP security headers.

Configure your Workers

Workers offer a convenient way to run scripts and certain deployment steps. Learn about workers.

We highly recommend configuring external workers running on a different host to your Octopus Server. This is the easiest and more secure approach to prevent user-provided scripts from doing harm to your Octopus Server.

Learn about the built-in worker.

Learn about external workers.

Configure how Octopus Server communicates with deployment targets

Octopus Server always uses a secure and tamper-proof communications transport for communicating with deployment targets:

• Learn about Octopus Server to Tentacle communication.
• Learn about Octopus Server to SSH communication.

The decisions you need to make are:

1. Which kind of deployment targets do you want to allow? Listening Tentacles? Polling Tentacles? SSH? This will have an impact on how you configure your network. See harden your network.
2. Do you want to use a proxy server? Learn about proxy support in Octopus Deploy.

Harden your host operating system

These steps apply to the host operating system for your Octopus Server. You may want to consider similar hardening for your deployment targets and any workers.

1. Rename local administrator account.
2. Configure malware protection.
3. Disable weak TLS protocols.
4. Prevent user-provided scripts from doing harm. a. Run workers under a different security context. a. Prevent unwanted file access. a. Prevent unwanted file execution. a. Prevent creating scheduled tasks.
5. Configure your operating system firewall - see harden your network.

Rename local administrator accounts

It might seem really simple, but by renaming your Administrator account to anything else makes it that much harder for attackers to use this attack vector in to your Octopus Server.

Here is an example script to rename the built-in Administrator account in Windows.

Write-Output "Ensure local Administrator account renamed..."

$user = Get-LocalUser -Name Administrator -ErrorAction SilentlyContinue

if($user) {
  Write-Output "Renaming local 'Administrator' account to 'Bob'..."
  Rename-LocalUser -Name Administrator -NewName Bob
} else {
  Write-Output "The local 'Administrator' account has already been renamed."
}

Configure malware protection

Depending on your host operating system, and your requirements for malware protection, you may want to install and configure a specific application. At the very least, Windows Defender is a very good starting place on modern Windows operating systems.

Here is an example script for configuring Windows Defender to exclude the Octopus work folders, and to automatically download new definitions.

Note: you may need to change the excluded folders/files if you install Octopus Server or Tentacle into a different location.

# Install and Configure: https://docs.microsoft.com/en-us/windows/threat-protection/windows-defender-antivirus/windows-defender-antivirus-on-windows-server-2016
# Automatic Exclusions: https://docs.microsoft.com/en-us/windows/threat-protection/windows-defender-antivirus/configure-server-exclusions-windows-defender-antivirus
# Configure Custom Exclusions: https://docs.microsoft.com/en-us/windows/threat-protection/windows-defender-antivirus/configure-extension-file-exclusions-windows-defender-antivirus

Write-Output "Installing Windows Defender..."
Install-WindowsFeature -Name "Windows-Defender"

Write-Output "Setting Windows Update to 'Download updates but let me choose whether to install them'."
Write-Output "This value allows Windows Defender to download and install definition updates automatically, but other updates are not automatically installed."
cscript C:\Windows\System32\Scregedit.wsf /AU 3

Write-Output "Excluding the Tools folder for Octopus Server (e.g. Calamari) from Windows Defender..."
Add-MpPreference -ExclusionPath "C:\Octopus\OctopusServer\Tools"
Add-MpPreference -ExclusionPath "C:\Octopus\OctopusServer\Tools*"

Write-Output "Excluding the Tools folder for Octopus Tentacles/Workers (e.g. Calamari) from Windows Defender..."
Add-MpPreference -ExclusionPath "C:\Octopus\Tools"
Add-MpPreference -ExclusionPath "C:\Octopus\Tools\*"

Write-Output "Excluding Octopus Work folder from Windows Defender..."
Add-MpPreference -ExclusionPath "C:\Octopus\Work"
Add-MpPreference -ExclusionPath "C:\Octopus\Work\*"

Disable weak TLS protocols

All communication between Octopus Server and Tentacles is performed over a secure (TLS) connection. Since both Server and Tentacle rely on the host OS for the available TLS version to use when establishing a secure TLS connection when communicating, you can harden the available TLS implementation.

Disable SSLv3, TLS 1.0 and 1.1 on Windows

On Windows, the easiest way to disable weak versions of SSL and TLS are by using a tool like IISCrypto to change the Windows Registry.

If you prefer, you can also script it too. This can be useful when automating Server installation. The following example PowerShell script will disable SSLv3, TLSv1 and TLSv1.1:

# SSLv3
New-Item "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server" -Force | Out-Null
New-ItemProperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server" -name "Enabled" -value "0" -PropertyType "DWord" -Force | Out-Null
New-ItemProperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server" -name "DisabledByDefault" -value 1 -PropertyType "DWord" -Force | Out-Null
New-Item "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client" -Force | Out-Null
New-ItemProperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client" -name "Enabled" -value "0" -PropertyType "DWord" -Force | Out-Null
New-ItemProperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client" -name "DisabledByDefault" -value 1 -PropertyType "DWord" -Force | Out-Null

# TLSv1.0
Write-Output "Disable TLS 1.0"

New-Item "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" -Force | Out-Null
New-ItemProperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" -name "Enabled" -value "0" -PropertyType "DWord" -Force | Out-Null
New-ItemProperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" -name "DisabledByDefault" -value 1 -PropertyType "DWord" -Force | Out-Null
New-Item "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client" -Force | Out-Null    
New-ItemProperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client" -name "Enabled" -value "0" -PropertyType "DWord" -Force | Out-Null
New-ItemProperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client" -name "DisabledByDefault" -value 1 -PropertyType "DWord" -Force | Out-Null

# TLSv1.1
Write-Output "Disable TLS 1.1"

New-Item "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" -Force | Out-Null
New-ItemProperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" -name "Enabled" -value "0" -PropertyType "DWord" -Force | Out-Null
New-ItemProperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" -name "DisabledByDefault" -value 1 -PropertyType "DWord" -Force | Out-Null
New-Item "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" -Force | Out-Null
New-ItemProperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" -name "Enabled" -value "0" -PropertyType "DWord" -Force | Out-Null    
New-ItemProperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" -name "DisabledByDefault" -value 1 -PropertyType "DWord" -Force | Out-Null

Disable SSLv3, TLS 1.0 and 1.1 on Ubuntu Server

On Ubuntu 20.04 using OpenSSL 1.1.1f (the latest at time of writing), you can specify the minimum TLS version to use to be TLSv1.2 by setting the MinProtocol directive in the /etc/ssl/openssl.cnf OpenSSL config file:

[system_default_sect]
MinProtocol = TLSv1.2

On Ubuntu 18.04, if the MinProtocol directive doesn’t work, you can try this alternative. When using OpenSSL 1.1.1 (the latest at time of writing), you can specify the available TLS Protocols explicitly in the /etc/ssl/openssl.cnf OpenSSL config file:

[system_default_sect]
Protocol = -SSLv3, -TLSv1, -TLSv1.1, TLSv1.2

Verification of disabling weak TLS protocols

Once you have performed changes to the available versions of TLS, you should verify that they have been disabled successfully. Tools such as openssl and nmap, and web sites like Qualys SSL Labs can be used to verify the TLS version and cipher suites available.

Prevent user-provided scripts from doing harm

These steps only apply if you are running either the built-in worker or an external worker on the same host operating system as the Octopus Server itself. You should prevent custom scripts executed by these workers from doing harm to your Octopus Server.

Run as a different user

Applies to: Built-in worker and External worker running on the Octopus Server

The first step is to make the worker run under a different security context to the Octopus Server. This enables you to make the distinction between what the Octopus Server should be able to do, versus what the worker should be able to do.

See configuring workers.

Prevent unwanted file access

Applies to: Built-in worker and External worker running on the Octopus Server

Here is an example script preventing the worker from accessing the Octopus Server configuration which contains sensitive information.

Note: In your scenario you may need to use a different username and/or Octopus Home folder path.

$username = "svcWorker"
$octopusHome = "C:\Octopus"
$acl = Get-Acl -Path $octopusHome
$acl.SetAccessRule(New-Object System.Security.AccessControl.FileSystemAccessRule("$username","FullControl","Deny"))
Set-Acl -Path $octopusHome -AclObject $acl

If you are using an external worker, that’s all you need to do. However if you are using the built-in worker you should allow access to its Work directory which is located under the Octopus Home directory.

$workDirectory = Join-Path $octopusHome "OctopusServer\Work"
$acl = Get-Acl -Path $workDirectory
$acl.SetAccessRule(New-Object System.Security.AccessControl.FileSystemAccessRule("$username","FullControl","Allow"))
Set-Acl -Path $workDirectory -AclObject $acl

Prevent unwanted execution

Applies to: Built-in worker and External worker running on the Octopus Server

Here is an example script for preventing execution of certain Windows executables which could be used by an attacker to learn information about your network.

$username = "svcOctopus"
$executables = @("C:\Windows\System32\NETSTAT.EXE", "C:\Windows\System32\ROUTE.EXE", "C:\Windows\System32\NETSH.EXE")
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule("$username","Read","Deny")

foreach ($executable in $executables) {
  $acl = Get-Acl -Path $executable
  $acl.SetAccessRule($rule)

  Write-Output "Denying read access to $executable for $username..."
  Set-Acl -Path $executable -AclObject $acl
}

Prevent creating scheduled tasks or chron jobs

Applies to: Built-in worker and External worker running on the Octopus Server

Attackers could potentially create a scheduled task or chron job to run as a privileged user account.

Here is an example script to prevent members of the Authenticated Users group from creating Scheduled Tasks in Windows.

Write-Output "Prevent users from creating scheduled tasks..."

# /grant:r    replace existing permissions
# S-1-5-11    "Authenticated Users"
# (CI)        "Container Inherit"
# (Rc)        "Read Permissions"
& "$env:SystemRoot\System32\icacls.exe" "$env:SystemRoot\System32\Tasks\" "/grant:r" "*S-1-5-11:(CI)(Rc)"

Harden your SQL Server

You don’t need to do very much here specific to Octopus Server.

1. Use Integrated Security for the database connection if possible, otherwise use a strong password.
2. Prevent the Octopus Server’s Server Principal (Login) from doing harm outside its own database.

Learn about managing your Octopus SQL database.

Harden your network

Your Octopus Server is very similar to any other secure web server: to do anything useful you need to allow certain network traffic in/out. Depending on your scenario you will need to apply these rules at several levels including:

• network control infrastructure
• the firewall in the host operating system

The TCP ports listed below are defaults, and can be changed if required - refer to the relevant documentation if you need to change from these default ports.

Inbound rules

Outbound rules

Harden your containers

If you run an Octopus Deploy container, in addition to your usual security measure for running apps out of containers, take the following steps to secure it:

• Move your docker data directory (the default location is /var/lib/docker) so that your containers are stored on a separate partition.
• Assign resources carefully:
  • Consider pinning CPUs to namespaces in order to give them a boundary.
  • Consider the amount of memory required, if you assign too much the container is susceptible to denial of service attacks, but if you assign too little or make use of memory ballooning performance will be impacted.
• Consider which containers reside in each network namespace as all processes in a namespace can talk to the namespace interface.

The security of your Linux container host and its Docker configuration can be analyzed in detail by using Docker Bench for Security from the Center for Internet Security. For more generalized advice for your platform they provide their benchmarks as PDF documents.

Samples

We have an Octopus Admin Space on our Samples instance of Octopus. You can sign in as Guest to take a look at some examples of how we have used Octopus for hardening tasks.

Getting help

We are more than happy to help if you are having trouble with self-hosting Octopus Deploy, or are concerned about the security or integrity of your Octopus installation. Don’t hesitate to get in touch!

Help us continuously improve

Please let us know if you have any feedback about this page.

Send feedback

Page updated on Wednesday, October 4, 2023