Locking Down Your Farm
Version: Deadline 9 and later
There are some features in Deadline that require communication over a network. These may include connecting to an external database, executing commands on remote machines, or simply connecting to a Deadline connection server. While these features may be powerful and highly useful, they introduce potential security concerns. For example, being able to execute commands on a remote machine has a range of potential, but that potential also allows users to unintentionally (hopefully not maliciously) damage the remote machines they are executing commands on.
This article will go through three major security features that have been added in Deadline 9 and 10, focusing on how to use them and how they can help you secure your farm from various potential vulnerabilities.
SECURE DATABASE COMMUNICATION
Whether you are connecting to an external database, or only want specific machines to be able to access your database, the Deadline Repository installation now supports creating an SSL/TLS certificate and configuring your database to require it for access.
During the Repository installation, there is a section for database security. From here we can configure the database to require an SSL/TLS certificate and specify some details.
Require client authentication via SSL/TLS - This setting, if checked, configures the database to require a special certificate when Clients communicate with it.
Certificate Directory - The installer generates the certificate that is required by the database and stores it in this directory. Make a note of the directory you choose, since you will have to select the generated certificate for each Deadline Client installation.
Certificate Password - This field is used to secure the certificate so that only intended users can use it. By specifying a password you are safeguarding yourself against the unlikely occurrence that your certificate falls into the wrong hands. This kind of works like a PIN for a debit card. Nobody should ever obtain your debit card, but if they do they will additionally need your PIN to be able to use it. This field needs to be re-entered in the Confirm Password field. Be sure to remember the password, as it will be required during the Deadline Client installation.
Use Client certificate for DB user authentication - If enabled, the generated certificate will also be used for database user authentication. This will create a database user that corresponds with the generated certificate.
Once you’ve successfully completed the Deadline Repository install (which includes the database), you will now need to install your Deadline Clients to use the generated certificate when communicating with the database. In the Client installation, this is done immediately after selecting the Connection Type.
Database SSL Certificate - This specifies the certificate file to use for database authentication. This is the same certificate that was generated in the Deadline Repository installation, and should be in the Certificate Directory. In Deadline 9, the certificate file will be named "Deadline9Client.pfx", and similarly "Deadline10Client.pfx" in Deadline 10.
SSL Certificate Password - This should be the same password that was specified in the Deadline Repository installation as Certificate Password.
Once the Client installation is complete, you should be set. The database will now be installed and configured to use SSL/TLS, and your new Deadline Client installations will have all the information they need to connect to it.
You can also let an existing Deadline Client use the certificate when selecting a Repository. This selection feature is available in both the Deadline Monitor and Deadline Launcher.
REMOTE COMMAND WHITELIST
Next up is the whitelist for remote commands. Remote commands are a feature of Deadline that allow you to control Slave, Pulse, and Balancer machines from the Monitor. More information about remote commands can be found in our Remote Control documentation. Note that in order for remote commands to work, the Deadline Launcher must be running on the target machine and Remote Administration must be enabled in the Client Setup section of the Repository Options. Note that Remote Administration is disabled by default, but if you enable it, you will see that the remote command whitelist is then enabled by default.
If the remote command whitelist is disabled, any command is accepted. In this case, a command like"ls -al"could be executed to get detailed information about the current directory. However, there’s nothing stopping a more harmful command like"rm -rf ." (deletes current directory and subdirectories) from being executed either. As you can see below, the interface for executing a remote command accepts any command in its text field.
If the remote command whitelist is enabled, only the commands specified in the whitelist are allowed to execute. When using the interface for executing a remote command, you will only be able to pick from the approved list of commands, rather than entering the command into a text field.
Now only commands that are deemed acceptable can be executed remotely. If used correctly, this eliminates the chances of harmful or damaging commands being executed through Deadline.
The network whitelist is a new addition to the Repository Options, located between Wake on Lan Settings and Web Service Settings. This feature can be enabled or disabled, but will default to being disabled. The purpose of the network whitelist is to specify IPv4 addresses or ranges of IPv4 addresses that should be allowed to communicate with Deadline server applications; these include the Web Service, the Proxy Server, and (in Deadline 10) the Remote Connection Server. If the whitelist is enabled, machines that do not have a whitelisted address will be denied; the Deadline server will return a 403 Forbidden HTTP response with the message "Access Denied", and no operations will be performed. This allows intended users the same access they had before, but denies any unintended activity.
The format of these entries may be either a single IP address in IPv4 format, or a CIDR range (also in IPv4 format). Machine or host names cannot be added to the whitelist. At the moment, IPv6 addresses and IPv6 CIDR ranges are not supported.
Let’s go through what some of these entries mean:
- 127.0.0.1 - This indicates a single IPv4 address. This specific address is known as the IPv4 loopback address. It is included by default to allow applications running locally to communicate with the Deadline server.
- 192.168.2.0/24 - This represents a range of IPv4 addresses (note the /24). This rule will allow any address that starts with the 192.168.2 blocks, such as 192.168.2.0, 192.168.2.1, and so on.
- 10.0.0.0/8 - This is another range of IPv4 addresses. This rule will allow any address that starts with a 10 block, such as 10.0.0.1, 10.0.1.2, 10.1.2.3, and so on.
- 53.282.76.35 - This indicates a single IPv4 address. This is an arbitrary public address, such as one for a home or office. This would allow these home or office machines to connect to the Deadline server application.
You can enable the whitelist by checking the Enable Network Whitelist checkbox. This will allow you to add, edit, and remove items. Initially, the whitelist should only contain an entry for 127.0.0.1. When the network whitelist is enabled, the Deadline server applications will only allow communication from Client machines that have an IPv4 address included in the network whitelist.
If a non-whitelisted Deadline Client tries to connect to a Deadline server application, the Client application will act as though the server does not exist.
You should feel secure when using Deadline, and security concerns shouldn’t limit your decisions. Hopefully this article has provided some insight into the major security features that have been added in Deadline 9 and 10 so that you can incorporate them into your render farm.
MongoDB is a registered trademark of MongoDB, Inc.