Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

此内容没有您所选择的语言版本。

Chapter 5. Using director to configure security hardening

This chapter describes how director can apply security hardening values as part of the deployment process.

Note

When running 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.

5.1. Use SSH banner text
复制链接

You can set a banner that displays a console message to all users that connect over SSH. You can add banner text to /etc/issue using the following parameters in an environment file. Consider customizing this sample text to suit your requirements. 

    resource_registry:
      OS::TripleO::Services::Sshd: ../puppet/services/sshd.yaml

    parameter_defaults:
      BannerText: |
        ******************************************************************
        * This system is for the use of authorized users only. Usage of  *
        * this system may be monitored and recorded by system personnel. *
        * Anyone using this system expressly consents to such monitoring *
        * and is advised that if such monitoring reveals possible        *
        * evidence of criminal activity, system personnel may provide    *
        * the evidence from such monitoring to law enforcement officials.*
        ******************************************************************
Copy to Clipboard Toggle word wrap

To apply this change to your deployment, save the settings as a file called ssh_banner.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> -e  ssh_banner.yaml
Copy to Clipboard Toggle word wrap

5.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: 

    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
Copy to Clipboard Toggle word wrap

5.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
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

In this example, 098 and 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
Copy to Clipboard Toggle word wrap

Alternatively, you can extract the port requirements from the puppet definition. For example, RabbitMQ’s rules are stored in puppet/services/rabbitmq.yaml: 

    tripleo.rabbitmq.firewall_rules:
      '109 rabbitmq':
        dport:
          - 4369
          - 5672
          - 25672
Copy to Clipboard Toggle word wrap

The following parameters can be set for a rule:

  • port: The port associated to the rule. Deprecated by puppetlabs-firewall.
  • 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 puppetlabs-firewall module.

5.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 /var/adm/utmp':
        content: '!/var/adm/utmp$'
        order: 8
      'not nova instances':
        content: '!/var/lib/nova/instances.*'
        order: 9
Copy to Clipboard Toggle word wrap
Note

The above example is not actively maintained or benchmarked, so you should select the AIDE values that suit your requirements.

  1. An alias named TripleORules is declared to avoid having to repeatedly out the same attributes each time.
  2. The alias receives the attributes of p+sha256. In AIDE terms, this reads as the following instruction: monitor all file permissions p with an integrity checksum of sha256.

For a complete list of attributes available for AIDE’s config files, see the AIDE MAN page at http://aide.sourceforge.net/stable/manual.html#config.

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
Copy to Clipboard Toggle word wrap

5.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
Copy to Clipboard Toggle word wrap

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 ! with '!/var/log.*' and '!/var/spool.*'.

5.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 AideEmail.

5.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.

5.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.

If 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.

5.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
Copy to Clipboard Toggle word wrap

5.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 KeystoneNotificationFormat: 

  parameter_defaults:
    KeystoneNotificationFormat: cadf
Copy to Clipboard Toggle word wrap

5.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
Copy to Clipboard Toggle word wrap
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2025 Red Hat