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.
126.96.36.199 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:
In the preceding command, username is the user name. The following is an example of the command:
188.8.131.52 Enabling the Security Policies
/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_sshscript to reset the security policies.
harden_passwords_reset_root_sshscript restarts the cell.
- All operating system users must set a new password the next time they log in.
184.108.40.206 Viewing Failed Password Attempts
pam_tally2 operating system utility to view login attempts with incorrect passwords.
View failed password attempts using the
# /sbin/pam_tally2 Login Failures Latest failure From celladmin 1 09/18/18 11:17:18 dhcp-10-154-xxx-xxx.example.com
220.127.116.11 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.
18.104.22.168 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.defsfile 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
minparameter in the
/etc/pam.d/system-authfile.The Exadata factory default settings are
5,5,5,5,5. A setting of
5,5,5,5,5allows passwords to be as short as five characters, and removes character class restrictions. If you run the
/opt/oracle.SupportTools/harden_passwords_reset_root_sshscript, then the default settings are
- Reboot the database servers.
See Also:Refer to the
passwdqc.confman pages for additional information
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
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
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
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.
4.2.1 Creating Roles and Getting Information about Roles
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
CellCLI> LIST ROLE admin ALL DETAIL
4.2.2 Granting and Revoking Privileges
GRANT PRIVILEGE command to grant privileges to roles for Oracle Exadata System Software users.
- Grant privileges to roles using the
The following example grants all privileges to Oracle Exadata System Software users with the
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
CellCLI> REVOKE PRIVILEGE ALL ON griddisk FROM ROLE diskadmin
4.2.3 Creating Users
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 USERcommand to create a user and assign an initial password.
The following command creates a user called
CellCLI> CREATE USER fred PASSWORD = "changeME123"
- To grant privileges to the new user
fred, use the
GRANT ROLEcommand for a role that has already been configured.
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 USERcommand and does not apply to operating system users like
- To allow the user to change the password remotely, use the
ALTER CELLcommand to set the
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 CELLcommand to modify the
pwdExpInDaysattribute.Set the value n to the number of days before the password expires. If
pwdExpInDaysis 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 CELLcommand to modify the
pwdExpWarnInDaysattribute.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 CELLcommand to modify the
accountLockInDaysattribute.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
GRANT ROLE command to create roles to Oracle Exadata System Software users.
- Use the
GRANT ROLEcommand to grant roles to users.
The following example grants the
adminrole to the user
CellCLI> GRANT ROLE admin TO USER fred
- You can revoke roles from users using the
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: SSH service is enabled. You can access the cell using ssh or exacli. This is the default value for
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
You must use a user that has the privilege to alter the
- 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
celladministratoruser 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
Specifies whether SSH is enabled (
This value needs to be specified. There is no default value.
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 "
Specifies how long the access level should last. The duration is specified in the following format:
[any number of digits, followed by
[any number of digits followed by
[any number of digits followed by
To specify 1 hour:
To specify 90 minutes:
To specify 1 day:
To specify 1 day and 12 hours:
Specifies a reason for changing the access level, for example: performing an upgrade.
Default value: "none"
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
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
All database servers in an Oracle RAC cluster have the same content, ownership, and security for the database
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.