Configuring Security for Oracle Exadata System Software

4 Configuring Security for Oracle Exadata System Software

This chapter explains how to configure security for Oracle Exadata System Software.

This chapter contains the following topics:

4.1 Understanding Operating System Security of Oracle Exadata Storage Servers

The security of the operating system on Oracle Exadata Storage Servers consists of the following:

Enforcing security policies
Protecting network access paths to the cells
Monitoring operating system-level activities

Oracle Exadata System Software includes security features to ensure the operating system and network access to the Oracle Exadata Storage Servers are secure.

4.1.1 Security Policies for Oracle Exadata Storage Servers

User access to the operating system can be secured by the use of secure, hardened passwords.

The passwords for operating system users who administer Oracle Exadata System Software adhere to the security guidelines enacted by Oracle Exadata Deployment Assistant (OEDA). See Default Security Setting Enacted by OEDA for more information.

4.1.1.1 Changing a Password

Users are notified of the need to change their passwords 7 days before the expiration date. To change a password, use the following command:

passwd username

In the preceding command, username is the user name. The following is an example of the command:

passwd celladmin

4.1.1.2 Enabling the Security Policies

The /opt/oracle.cellos/RESECURED_NODE file enables the security policies.

If the file does not exist, then you can reset the security policies for all operating system users by performing the following steps:

Shut down the Oracle Grid Infrastructure services on all database servers.

Shut down the cell services.

cellcli -e alter cell shutdown services all

Use the harden_passwords_reset_root_ssh script to reset the security policies.
Note:
The harden_passwords_reset_root_ssh script restarts the cell.
```
/opt/oracle.SupportTools/harden_passwords_reset_root_ssh
```
All operating system users must set a new password the next time they log in.

4.1.1.3 Viewing Failed Password Attempts

Use the pam_tally2 operating system utility to view login attempts with incorrect passwords.

View failed password attempts using the /sbin/pam_tally2 utility.

# /sbin/pam_tally2
Login           Failures Latest failure     From
celladmin           1    09/18/18 11:17:18  dhcp-10-154-xxx-xxx.example.com

4.1.1.4 Resetting a Locked User Account

If a user account has 5 failed login attempts, then the account is locked.

To reset an account, use the following command:

/sbin/pam_tally2 --user username --reset

In the preceding command, username is the name of the user that has the locked account.

4.1.1.5 Modifying Password Policies on the Database Servers

The password policies can be modified only for database servers.

On the database server, modify the settings in the /etc/login.defs file to change the aging policies, for example:
```
PASS_MAX_DAYS 90
PASS_MIN_DAYS 1
PASS_MIN_LEN 8
PASS_WARN_AGE 7
```
Modify the character class restrictions by changing the values for the min parameter in the /etc/pam.d/system-auth file.
The Exadata factory default settings are 5,5,5,5,5. A setting of 5,5,5,5,5 allows passwords to be as short as five characters, and removes character class restrictions. If you run the /opt/oracle.SupportTools/harden_passwords_reset_root_ssh script, then the default settings are min=disabled,disabled,16,12,8.
Reboot the database servers.

Related Topics

Default Security Setting Enacted by OEDA

4.1.2 Network Access to Oracle Exadata Storage Servers

Oracle Exadata System Software includes the cellwall service that implements a firewall on each cell. The service is located in the /etc/init.d/cellwall directory, and implements iptables firewall on the cell. In addition, the SSH server is configured to respond to connection requests only on the management network (NET0), and the InfiniBand network (BONDIB0).

To review the firewall rules, run the following command as the root user:

iptables --list

Note:

There is no firewall automatically configured for the database servers. Implement a set of iptables on the database servers to meet your network requirements for Oracle Exadata Database Machine.

4.1.3 Operating System Activity Monitoring on Oracle Exadata Storage Servers

Each Oracle Exadata Storage Server is configured with auditd to audit system-level activity.

To manage audits and generate reports use the auditctl command. The audit rules are in the /etc/audit/audit.rules file. Any changes are not preserved when applying a patch set.

Starting with Oracle Exadata System Software release 19.1.0 and Oracle Linux 7, the audit rules specific to Oracle Exadata Database Machine are stored in the /etc/audit/rules.d/01-exadata_audit.rules file.

When the auditd service starts, it runs the augenrules utility. This utility merges all component audit rules files found in the audit rules directory, /etc/audit/rules.d, and places the merged results in the /etc/audit/audit.rules file. Component audit rule files, must end in .rules to be processed by augenrules. All other files in the /etc/audit/rules.d directory are ignored. The files are concatenated in order, based on their natural sort order and stripped of empty lines and comment (#) lines. Auditing rules not specific to Oracle Exadata Database Machine should be placed in a separate audit rules file in the /etc/audit/rules.d directory, such as /etc/audit/rules.d/20-customer_audit.rules.

As in previous releases of Oracle Exadata System Software, the audit rules are immutable. A reboot is needed to effect changes to audit rules.

4.2 Creating Exadata Software Users and Roles

You can control which Oracle Exadata System Software commands users can run by granting privileges to roles, and granting roles to users.

For example, you can specify that a user can run the LIST GRIDDISK command but not ALTER GRIDDISK. This level of control is useful in Cloud environments, where you might want to allow full access to the system to only a few users.

Oracle Exadata System Software users are required when running ExaCLI in on-premise or Oracle Cloud environments. ExaCLI enables you to manage cells remotely from compute nodes. When you run ExaCLI on a compute node, you need to specify a user name to use to connect to the cell node. The Management Server (MS) authenticates the user credentials, then performs authorization checks on the commands issued by the user. If the user does not have the proper privileges to run a command, MS returns an error.

The password security key is encrypted using Password-Based Key Derivation Function 2 (PBKDF2) with HMAC-SHA1.

To set up users and roles, you would perform these steps:

Create roles using the CREATE ROLE command.
Grant privileges to roles using the GRANT PRIVILEGE command.
Create users using the CREATE USER command.
Grant roles to users using the GRANT ROLE command.

You can also revoke privileges from roles using the REVOKE PRIVILEGE command. To revoke roles from users, use the REVOKE ROLE command.

Related Topics

Using the ExaCLI Utility

4.2.1 Creating Roles and Getting Information about Roles

Use the CREATE ROLE command to create roles for Oracle Exadata System Software users.

For example, to create a ADMIN role, you would use the following command:

CellCLI> CREATE ROLE admin

To get detailed information about a role, use the LIST ROLE command. The following command returns all the attributes for the admin role.

CellCLI> LIST ROLE admin ALL DETAIL

Related Topics

4.2.2 Granting and Revoking Privileges

Use the GRANT PRIVILEGE command to grant privileges to roles for Oracle Exadata System Software users.

Grant privileges to roles using the GRANT PRIVILEGE command.
- The following example grants all privileges to Oracle Exadata System Software users with the admin role.
```
CellCLI> GRANT PRIVILEGE ALL ACTIONS ON ALL OBJECTS TO ROLE admin
```
- You can also grant individual command privileges to a role.
```
CellCLI> GRANT PRIVILEGE list ON griddisk TO ROLE diskmonitor

CellCLI> GRANT PRIVILEGE list ON griddisk TO ROLE diskmonitor
```
- You can also grant all command privileges for specific objects to a role.
```
GRANT PRIVILEGE ALL ON griddisk TO ROLE diskadmin
```
You can revoke privileges from roles using the REVOKE PRIVILEGE command.
```
CellCLI> REVOKE PRIVILEGE ALL ON griddisk FROM ROLE diskadmin
```

Related Topics

4.2.3 Creating Users

Use the CREATE USER command to create Oracle Exadata System Software users.

A newly created user does not have any privileges. The Oracle Exadata System Softwareuser is granted privileges through roles granted to the user.

Use the CREATE USER command to create a user and assign an initial password.
The following command creates a user called fred with password changeME123.
```
CellCLI> CREATE USER fred PASSWORD = "changeME123"
```
To grant privileges to the new user fred, use the GRANT ROLE command for a role that has already been configured.

Related Topics

4.2.4 Configuring Password Expiration for Users Accessing the Server Remotely

You can configure CELL attributes to expire user passwords.

In Oracle Exadata System Software release 19.1.0, there are new CELL attributes for configuring password security for users that access Oracle Exadata System Software servers remotely, such as with REST API or ExaCLI. These attributes determine if the user is able to change the password remotely, the amount of time before a user password expires, and the number of days prior to password expiration that the user receives warning messages. In the default configuration, user passwords do not expire.

Note:

The CELL attributes for password expiration apply only to users created with Oracle Exadata System Software. Password expiration applies only to users that are displayed with the LIST USER command and does not apply to operating system users like celladmin or oracle.

To allow the user to change the password remotely, use the ALTER CELL command to set the remotePwdChangeAllowed attribute to true.
If you set the value to false, then the user receives a message indicating that they must contact the server administrator to have their password changed.
```
CellCLI> ALTER CELL remotePwdChangeAllowed=true
```
To change the length of time before a user password expires, use the ALTER CELL command to modify the pwdExpInDays attribute.
Set the value n to the number of days before the password expires. If pwdExpInDays is set to 0 (the default value), then the user password does not expire.
```
CellCLI> ALTER CELL pwdExpInDays=n
```
To configure the length of the warning period before the password expires, use the ALTER CELL command to modify the pwdExpWarnInDays attribute.
Set the value n to the number of days to warn the user before the password expires. The default user account password expiration warning time is 7 days.
```
CellCLI> ALTER CELL pwdExpWarnInDays=n
```
To specify the length of time before a user account is locked after the user password expires, use the ALTER CELL command to modify the accountLockInDays attribute.
Set the value n to the number of days before the user account is locked. The default user account lock time is 7 days.
```
CellCLI> ALTER CELL accountLockInDays=n
```

4.2.5 Granting and Revoking Roles

Use the GRANT ROLE command to create roles to Oracle Exadata System Software users.

Command privileges are granted to roles, and then the roles are granted to users. You do not grant command privileges directly to the Oracle Exadata System Software users.

Use the GRANT ROLE command to grant roles to users.
The following example grants the admin role to the user fred.
```
CellCLI> GRANT ROLE admin TO USER fred
```
You can revoke roles from users using the REVOKE ROLE command.

Related Topics

4.3 Disabling SSH on Storage Servers

By default, SSH is enabled on storage servers. If required, you can "lock" the storage servers to block SSH access. You can still perform operations on the cell using exacli, which runs on compute nodes and communicates using https and REST APIs to a web service running on the cell.

When you need to perform operations that require you to log in to the cell, you can temporarily unlock the cell. After the operation is complete, you can relock the cell.

Two new cell attributes control cell locking:

accessLevelPerm : This attribute specifies the access level at which the cell runs by default. It is either remoteLoginEnabled or remoteLoginDisabled.
- remoteLoginEnabled: SSH service is enabled. You can access the cell using ssh or exacli. This is the default value for accessLevelPerm.
- remoteLoginDisabled: SSH service is disabled. You can access the cell only through exacli.
accessLevelTemp: The access level can be changed temporarily for a specified duration. Once the duration has expired, the access level reverts back to the accessLevelPerm value. You typically change the cell's access level when the cell needs a software update.

The access level persists across cell reboots.

4.3.1 Locking a Cell

You lock a cell by setting its accessLevelPerm attribute to remoteLoginDisabled.

You must use a user that has the privilege to alter the accessLevelPerm attribute.

Grant the necessary privileges to a user.

On the storage server, run these commands:

cellcli> create role administrator
cellcli> grant privilege all actions on all objects all attributes with all options to role administrator
cellcli> create user celladministrator password=*
cellcli> grant role administrator to user celladministrator

Run ExaCLI as the celladministrator user and run the ALTER CELL command:

$ exacli -l celladministrator -c exam08cel01
Password=********

exacli> alter cell accessLevelPerm = remoteLoginDisabled

4.3.2 Unlocking a Cell Temporarily

You can unlock a locked cell for a short period of time to perform operations such as maintenance or upgrades that require SSH login to the cell. You can specify the start time of this "temporary access window" and how long it should last by setting the cell's accessLevelTemp attribute. This attribute has the following properties:

Table 4-1 Properties of accessLevelTemp

Property	Description
`accessLevel`	Specifies whether SSH is enabled (`remoteLoginEnabled`) or disabled (`remoteLoginDisabled`). This value needs to be specified. There is no default value.
`startTime`	Specifies when the specified access level starts. The time is specified in the ISO 8601 format: "yyyy-MM-ddTHH:mm:ssZ". You can also specify the keyword "`now`" to indicate that the specified access level should start immediately. Default value: `now`
`duration`	Specifies how long the access level should last. The duration is specified in the following format: [any number of digits, followed by `d` (for days)] [any number of digits followed by `h` (for hours)] [any number of digits followed by `m` (for minutes)] Examples: To specify 1 hour: `1h` To specify 90 minutes: `90m` To specify 1 day: `1d` To specify 1 day and 12 hours: `1d12h` Default value: `2h` (2 hours)
`reason`	Specifies a reason for changing the access level, for example: performing an upgrade. Default value: "none"

Examples:

1. The following example creates a two-hour temporary access window that will begin on June 20, 2015, at 1:01 AM.

exacli> alter cell accessLevelTemp=((accessLevel="remoteLoginEnabled", -
        startTime="2015-06-20T01:01:00-07:00",                         -
        duration="2h",                                                 -
        reason="Quarterly maintenance"))

2. The following example creates a two-hour temporary access window that starts immediately. The command uses the default values for start time and duration.

exacli> alter cell accessLevelTemp=((accessLevel="remoteLoginEnabled", -
        reason="Quarterly maintenance"))

3. The following example creates a 30-minute temporary access window that starts immediately

exacli> alter cell accessLevelTemp=((accessLevel="remoteLoginEnabled", -
        startTime="now",                                               -
        duration="30m",                                                -
        reason="Quarterly maintenance"))

4. The following example creates a two-hour temporary access window that will begin on June 20, 2015, at 1:01 AM. The command uses the default duration value.

exacli> alter cell accessLevelTemp=((accessLevel="remoteLoginEnabled", -
        startTime="2015-06-20T01:01:00-07:00",                         -
        reason="Quarterly maintenance"))

5. The following example extends the temporary access window created in example 4 above to 5 hours. Note that the start time has to match the window that is being adjusted.

exacli> alter cell accessLevelTemp=((accessLevel="remoteLoginEnabled", -
        startTime="2015-06-20T01:01:00-07:00",                         -
        duration="5h",                                                 -
        reason="Quarterly maintenance window extended to 5 hrs - Joe"))

6. The following example deletes the temporary access window. If the temporary access window is currently active, it is closed immediately and the access level will be set back to the permanent access level. If the temporary access window is in the future and not yet active, it is cancelled.

exacli> alter cell accessLevelTemp=''

Note the following:

Only one temporary access window is allowed at any time. You will get an error message if you try to create a new temporary access window when one is already in effect.

If the temporary access window is not yet active and is in the future, the newly created temporary access window will replace the one that is in the future.
To modify a temporary access window that is in the future and not yet active, simply run the "alter cell" command again with the new values.
To modify a temporary access window that is already in progress (for example, to extend the duration or to change the reason), run the "alter cell" command again with the updated duration and/or reason. The command must provide the exact start time of the existing temporary access window to modify. The (start time + duration) must be in the future.

4.3.3 Checking the Current Access Level

To see what the current access level is, run the following command:

exacli> list cell detail

Look at the values for the accessLevelPerm and accessLevelTemp attributes.

You can also run the following commands:

exacli> list cell attributes accessLevelPerm

exacli> list cell attributes accessLevelTemp

4.3.4 Alerts from the Management Server

A stateless alert is generated when the accessLevelPerm attribute is modified.

A stateful alert is generated when the accessLevelTemp window is created. An alert email is sent out when the accessLevelTemp window is activated. The alert is cleared when the window expires.

4.4 Configuring Data Security for Oracle Exadata Storage Servers

Oracle Exadata System Software data security is implemented by controlling which Oracle Automatic Storage Management (Oracle ASM) clusters and Oracle Database clients can access specific grid disks on storage cells. By default, all Oracle Database and Oracle ASM instances have access to all storage cell grid disks.

To set up security so that all database clients of an Oracle ASM cluster have access to specific grid disks, configure ASM-scoped security.
To set up security so that specific database clients of an Oracle ASM cluster have access to specific grid disks, configure DB-scoped security.

To have consistent security, ensure the following:

All grid disks that belong to the same Oracle ASM disk group have the same cell-side grid disk security defined to avoid confusion and errors.
All Oracle Real Application Clusters (Oracle RAC) servers in an Oracle ASM cluster have the same content, ownership, and security for theOracle ASM cellkey.ora file.
All database servers in an Oracle RAC cluster have the same content, ownership, and security for the database cellkey.ora file.
If DB-scoped security is implemented, then ensure it is implemented for all databases accessing the grid disks.
Do not mix ASM-scoped security and DB-scoped security.

While setting up security, it is imperative that the configuration is the same across cells. Using the dcli utility to make configuration changes ensures consistency by eliminating the potential of user errors.

For more information, see Configuring Data Security for Exadata Storage Servers in the Oracle Exadata Database Machine Security Guide.