Chapter 6. Using director to configure security hardening
This chapter describes how director can apply security hardening values as part of the deployment process.
openstack overcloud deploy, remember that you will always need to include all necessary environment files needed to deploy the overcloud, in addition to any changes you want to make.
6.2. Audit for system events
Maintaining a record of all audit events helps you establish a system baseline, perform troubleshooting, or analyze the sequence of events that led to a certain outcome. The audit system is capable of logging many types of events, such as changes to the system time, changes to Mandatory/Discretionary Access Control, and creating/deleting users or groups.
Rules can be created using an environment file, which are then injected by director into
/etc/audit/audit.rules. For example:
resource_registry: OS::Tripleo::Services::AuditD: /usr/share/openstack-tripleo-heat-templates/deployment/auditd/auditd-baremetal-puppet.yaml parameter_defaults: AuditdRules: 'Record Events that Modify User/Group Information': content: '-w /etc/group -p wa -k audit_rules_usergroup_modification' order : 1 'Collects System Administrator Actions': content: '-w /etc/sudoers -p wa -k actions' order : 2 'Record Events that Modify the Systems Mandatory Access Controls': content: '-w /etc/selinux/ -p wa -k MAC-policy' order : 3
6.3. Manage firewall rules
Firewall rules are automatically applied on overcloud nodes during deployment, and are intended to only expose the ports required to get OpenStack working. You can specify additional firewall rules as needed. For example, to add rules for a Zabbix monitoring system:
parameter_defaults: ControllerExtraConfig: tripleo::firewall::firewall_rules: '301 allow zabbix': dport: 10050 proto: tcp source: 10.0.0.8 action: accept
You can also add rules that restrict access. The number used during rule definition will determine the rule’s precedence. For example, RabbitMQ’s rule number is
109 by default. If you want to restrain it, you switch it to use a lower value:
parameter_defaults: ControllerExtraConfig: tripleo::firewall::firewall_rules: '098 allow rabbit from internalapi network': dport: [4369,5672,25672] proto: tcp source: 10.0.0.0/24 action: accept '099 drop other rabbit access': dport: [4369,5672,25672] proto: tcp action: drop
In this example,
099 are arbitrarily chosen numbers that are lower than RabbitMQ’s rule number
109. To determine a rule’s number, you can inspect the iptables rule on the appropriate node; for RabbitMQ, you would check the controller:
iptables-save [...] -A INPUT -p tcp -m multiport --dports 4369,5672,25672 -m comment --comment "109 rabbitmq" -m state --state NEW -j ACCEPT
Alternatively, you can extract the port requirements from the puppet definition. For example, RabbitMQ’s rules are stored in
tripleo.rabbitmq.firewall_rules: '109 rabbitmq': dport: - 4369 - 5672 - 25672
The following parameters can be set for a rule:
port: The port associated to the rule. Deprecated by
dport: The destination port associated to the rule.
sport: The source port associated to the rule.
proto: The protocol associated to the rule. Defaults to tcp
action: The action policy associated to the rule. Defaults to accept
jump: The chain to jump to.
state: Array of states associated to the rule. Default to [NEW]
source: The source IP address associated to the rule.
iniface: The network interface associated to the rule.
chain: The chain associated to the rule. Default to INPUT
destination: The destination cidr associated to the rule.
extras: Hash of any additional parameters supported by the
6.4. Intrusion detection with AIDE
AIDE (Advanced Intrusion Detection Environment) is a file and directory integrity checker. It is used to detect incidents of unauthorized file tampering or changes. For example, AIDE can alert you if system password files are changed.
AIDE works by analyzing system files and then compiling an integrity database of file hashes. The database then serves as a comparison point to verify the integrity of the files and directories and detect changes.
The director includes the AIDE service, allowing you to add entries into an AIDE configuration, which is then used by the AIDE service to create an integrity database. For example:
resource_registry: OS::TripleO::Services::Aide: ../puppet/services/aide.yaml parameter_defaults: AideRules: 'TripleORules': content: 'TripleORules = p+sha256' order: 1 'etc': content: '/etc/ TripleORules' order: 2 'boot': content: '/boot/ TripleORules' order: 3 'sbin': content: '/sbin/ TripleORules' order: 4 'var': content: '/var/ TripleORules' order: 5 'not var/log': content: '!/var/log.*' order: 6 'not var/spool': content: '!/var/spool.*' order: 7 'not nova instances': content: '!/var/lib/nova/instances.*' order: 8
The above example is not actively maintained or benchmarked, so you should select the AIDE values that suit your requirements.
An alias named
TripleORulesis declared to avoid having to repeatedly out the same attributes each time.
The alias receives the attributes of
p+sha256. In AIDE terms, this reads as the following instruction: monitor all file permissions
pwith an integrity checksum of
For a complete list of attributes available for AIDE’s config files, see the AIDE MAN page at https://aide.github.io/.
To apply this change to your deployment, save the settings as a file called
aide.yaml, and then pass it to the
overcloud deploy command as follows. The
<full environment> indicates that you must still include all of your original deployment parameters. For example:
openstack overcloud deploy --templates -e <full environment> /usr/share/openstack-tripleo-heat-templates/environments/aide.yaml
6.4.1. Using complex AIDE rules
Complex rules can be created using the format described previously. For example:
MyAlias = p+i+n+u+g+s+b+m+c+sha512
The above would translate as the following instruction: monitor permissions, inodes, number of links, user, group, size, block count, mtime, ctime, using sha256 for checksum generation.
Note, the alias should always have an order position of
1, which means that it is positioned at the top of the AIDE rules and is applied recursively to all values below.
Following after the alias are the directories to monitor. Note that regular expressions can be used. For example we set monitoring for the
var directory, but overwrite with a not clause using
6.4.2. Additional AIDE values
The following AIDE values are also available:
AideConfPath: The full POSIX path to the aide configuration file, this defaults to
/etc/aide.conf. If no requirement is in place to change the file location, it is recommended to stick with the default path.
AideDBPath: The full POSIX path to the AIDE integrity database. This value is configurable to allow operators to declare their own full path, as often AIDE database files are stored off node perhaps on a read only file mount.
AideDBTempPath: The full POSIX path to the AIDE integrity temporary database. This temporary files is created when AIDE initializes a new database.
AideHour: This value is to set the hour attribute as part of AIDE cron configuration.
AideMinute: This value is to set the minute attribute as part of AIDE cron configuration.
AideCronUser: This value is to set the linux user as part of AIDE cron configuration.
AideEmail: This value sets the email address that receives AIDE reports each time a cron run is made.
AideMuaPath: This value sets the path to the Mail User Agent that is used to send AIDE reports to the email address set within
6.4.3. Cron configuration for AIDE
The AIDE director service allows you to configure a cron job. By default, it will send reports to
/var/log/audit/; if you want to use email alerts, then enable the
AideEmail parameter to send the alerts to the configured email address. Note that a reliance on email for critical alerts can be vulnerable to system outages and unintentional message filtering.
6.4.4. Considering the effect of system upgrades
When an upgrade is performed, the AIDE service will automatically regenerate a new integrity database to ensure all upgraded files are correctly recomputed to possess an updated checksum.
openstack overcloud deploy is called as a subsequent run to an initial deployment, and the AIDE configuration rules are changed, the director AIDE service will rebuild the database to ensure the new config attributes are encapsulated in the integrity database.
6.5. Review SecureTTY
SecureTTY allows you to disable root access for any console device (tty). This behavior is managed by entries in the
/etc/securetty file. For example:
resource_registry: OS::TripleO::Services::Securetty: ../puppet/services/securetty.yaml parameter_defaults: TtyValues: - console - tty1 - tty2 - tty3 - tty4 - tty5 - tty6
6.6. CADF auditing for Identity Service
A thorough auditing process can help you review the ongoing security posture of your OpenStack deployment. This is especially important for keystone, due to its role in the security model.
Red Hat OpenStack Platform has adopted Cloud Auditing Data Federation (CADF) as the data format for audit events, with the keystone service generating CADF events for Identity and Token operations. You can enable CADF auditing for keystone using
parameter_defaults: KeystoneNotificationFormat: cadf
6.7. Review the login.defs values
To enforce password requirements for new system users (non-keystone), director can add entries to
/etc/login.defs by following these example parameters:
resource_registry: OS::TripleO::Services::LoginDefs: ../puppet/services/login-defs.yaml parameter_defaults: PasswordMaxDays: 60 PasswordMinDays: 1 PasswordMinLen: 5 PasswordWarnAge: 7 FailDelay: 4