orcharhino Security Guide

Firewall Configuration

This is not an exhaustive introduction or documentation of firewalld. Please refer to the official firewalld documentation or the firewalld documentation of your operating system vendor before making any changes to your firewall configuration.

orcharhino uses firewalld. It’s enabled by default on every Kickstart installation and available on CentOS, Oracle Linux, and Red Hat Enterprise Linux version 7 or newer. The firewall daemon can be enabled by running systemctl enable firewalld and started/stopped via systemctl {start|stop} firewalld. Running systemctl status firewalld shows whether the firewall service is currently running; firewall-cmd --help shows the inbuilt documentation. firewalld relies on zones and services:

Zones define the level of trust of a connection. One interface, source, or connection belongs to exactly one zone; one zone can be used by many interfaces, sources, or connections. By default, zone example files are located at /usr/lib/firewalld/zones/ and describe an individual zone. firewall-cmd --list-all-zones lists all available zones on your machine. Refer to the official documentation for more information about zones in firewalld or the firewalld documentation of your operating system vendor.
Services bundle and allow traffic regarding certain ports and protocols. By default, SSH, DNS, HTTP, and HTTPS services are added to the public zone. An orcharhino tailor-made service is defined at /usr/lib/firewalld/services/orcharhino.xml and specifies several ports and protocols, e.g. port 80 with tcp protocol for the orcharhino web server.

Do not overwrite /usr/lib/firewalld/services/orcharhino.xml as this file is being managed by orcharhino itself and will be overwritten with every upgrade.

Adding a Custom Service

firewall-cmd --zone=internal --list-all lists all services of the internal zone. firewall-cmd --permanent --zone=work --add-service=orcharhino allows you to enable the orcharhino service for the work zone permanently, i.e. persistent after rebooting. You may specify a network interface with the --add-interface=<INTERFACE> option, e.g. --add-interface=eth0. Make sure to reload the firewalld configuration afterwards: firewall-cmd --complete-reload. This can be reverted by running firewall-cmd --permanent --zone=work --remove-service=orcharhino. You can also add or disable arbitrary services like HTTP. Refer to the official documentation for more information about services in firewalld or the firewalld documentation of your operating system vendor.

Opening a Custom Port

Specific ports on your orcharhino can be opened or closed by running the following command: firewall-cmd --permanent --remove-port=5000/tcp (e.g. Katello for Docker registry). Run firewall-cmd --complete-reload to reload the firewalld configuration. Revert removing a port by using the --add-port=PORT/PROTOCOL option.

Altering the Firewall Configuration

You can change the firewall configuration by adding a custom service. Write a custom service and save it in the /etc/firewalld/services/ directory. Run firewall-cmd --permanent --zone=internal --new-service-from-file=my_service.xml to add your service to the internal zone and reload the firewalld configuration: firewall-cmd --complete-reload.

Make sure to not remove the SSH service unless you have other means of accessing your orcharhino.

Restricting User Access

You can restrict user access to orcharhino via roles and filters.

You can also restrict access using a location and organization context. This limits the user’s access to orcharhino’s resources, e.g. hosts and job templates.

Dedicated Remote Execution User

If you want to run job templates against the orcharhino server or orcharhino proxies, then orcharhino’s remote execution features require SSH access. To make setting up the required SSH access easy, ATIX provides the orcharhino-rex-user RPM package.

Installing the orcharhino-rex-user RPM package allows any sufficiently privileged orcharhino management UI user to run arbitrary commands against the orcharhino server as root. By installing this package, you are opting in to the security implications.

Mitigation strategies include:

Restricting job template access for any regular orcharhino users.
Adopting more restrictive sudo rules for the or-rex user in /etc/sudoers.d/or_rex_user. Note that future orcharhino updates may revert your local changes.
Uninstalling the orcharhino-rex-user package after use (yum remove orcharhino-rex-user). This will completely revert the changes introduced by installing the package.

Install the package to set up the or-rex linux system user, along with sudo rules, and the required authorized_keys file:

yum install -y orcharhino-rex-user

You will also need to set a host parameter for orcharhino’s remote execution features to use the new user:

Navigate to All Hosts > Hosts.
Select the host you have installed the user on, e.g. orcharhino.example.com or orcharhino-proxy.example.com.
Click the Edit button.
On the Parameters tab, add the host parameter remote_execution_ssh_user of type string and with value or-rex.

Your sufficiently privileged orcharhino users can now run job templates against the relevant target host.