1. DSR Security Guide
  2. Implement Oracle Communications Diameter Signaling Router Security

3 Implement Oracle Communications Diameter Signaling Router Security

3.1 Diameter Signaling Router Web GUI Standard Features

This section explains the security features of the Oracle Communications Diameter Signaling Router software that are available to the Administrative User through the Graphical User Interface (GUI) using a compatible web browser.

3.1.1 User Administration

A predefined user and group are included in the system for setting up the groups and users. The following are details for this predefined user:

Table 3-1 Predefined User and Group

User Group Description
guiadmin admin Full access (read or write privileges) to all functions including administration functions

The User Administration page allows the admin user to add, modify, enable, or delete user accounts. Each user that is allowed to access the DSR GUI, is assigned with a unique Username. The correct username and its password must be provided during login.

If a user has made three consecutive unsuccessful login attempts, then that user's account is disabled. The value of the number of failed login attempts, before disabling an account, can be configured through Administrations > Options. This value can be set between 0-10. The default value is 3. If the value is set to 0, then the user account is not disabled for unsuccessful login attempts.

Each user can be assigned to one or more groups. Only a user with user admin or group admin privilege can make changes to the user accounts or groups. For more details on user administration, see the Users Administration section in DSR Operation, Administration, and Maintenance (OAM) Guide.

3.1.1.1 Establishing Groups and Group Permissions

You can assign each GUI user to one or more groups. The Groups Administration page enables you to create, modify, and delete user groups. Also, you can assign permissions to the group. The permissions determine the functions and restrictions for the users belonging to that group. The permissions on this page are categorized as follows:

  • Global Action Permissions
  • Administration Permissions
  • Configuration Permissions
  • Alarms & Events Permissions
  • Security Log Permissions
  • Status & Manage Permissions
  • Measurements Permissions
  • Communication Agent Configuration Permissions
  • Communication Agent Maintenance Permissions
  • Diameter Configuration Permissions
  • Diameter Maintenance Permissions
  • Diameter Diagnostics Permissions
  • Diameter Mediation Permissions
  • Diameter Troubleshooting with IDIH Permissions
  • Diameter AVP Dictionary Permissions

For more information about the available permissions for the groups, see the Group Administration section in DSR Operation, Administration, and Maintenance (OAM) Guide.

For non-admin users, a group with restricted authority is essential. To prevent non-admin users from setting up new users and groups, ensure that Users and Groups under the Administration Permissions section are unchecked, as shown in the following image.

Figure 3-1 Global Action and Administration Permissions


Global Action and Administration Permissions

3.1.1.2 Creating Users and Assigning to Groups

Before adding a user, determine which user group the user must be assigned based on the user’s operational role. The group assignment determines the functions a user can access. A user must either have user or group administrative privileges to view or make changes to the user accounts or groups. The admin user can set up or change user accounts and groups, enable or disable user accounts, set password expiration intervals, and change the user passwords.

The Insert User page displays the following elements:

  • User Name
  • Group
  • Authentication Options
  • Access Allowed
  • Maximum Concurrent Logins
  • Session Inactivity Limit
  • Comment

For more information, see the Administration chapter in DSR Operation, Administration, and Maintenance (OAM) Guide.

The User Administration page allows the admin user to perform the following actions:

  • Add a New User
  • View User Account Information
  • Update User Account Information
  • Delete a User
  • Enable or Disable a User Account
  • Change a User’s Assigned Group
  • Generate a User Report
  • Change Password

For more information, see the Administration chapter in the Operation, Administration, and Maintenance (OAM) Guide.

3.1.2 User Authentication

In the DSR GUI, Users are authenticated using either login credentials or Single Sign-On (SSO). For more information about setting up a password, see the Passwords section in the Operation, Administration, and Maintenance (OAM) Guide.

You can configure SSO to work with or without a shared LDAP authentication server. If the SSO is configured to work with an LDAP server, then SSO will require remote (LDAP) authentication for account access on an account-by-account basis. For more information about LDAP authentication, see the Operation, Administration, and Maintenance (OAM) Guide.

3.1.2.1 Passwords

The Administrator can perform password configurations such as setting passwords, password history rules, and password expiration. In the DSR GUI, the password configurations can be performed from the Users Administration page. For more information, see the Administration chapter in the Operation, Administration, and Maintenance (OAM) Guide.

3.1.2.2 Changing DSR Administrative Account Passwords

The System Installation procedure creates the following default accounts:

  • guiadmin – for DSR GUI
  • root – for CLI
  • admusr – for CLI

The installation procedure also conveys the passwords for the accounts created. As a security measure, these passwords must be changed.

To change the default password of an account created for the GUI access, see the Administration chapter in the Operation, Administration, and Maintenance (OAM) Guide.

To change the Operating System (OS) account passwords for a CLI account, see the Changing OS User Account Default Passwords section.

3.1.2.3 Password Complexity

Password complexity refers to the password selection requirements for better security. The user must ensure that the following conditions are fulfilled for a password to be valid:

  • A password must contain 8 to 16 characters.
  • A password must contain at least three of the four types of characters such as numeric, lower case letters, upper case letters, or special characters. For example: ! @ # $ % ^ & * ? ~.
  • A password must not be the same as the Username or contain the Username in any part of the password. For example, Username=jsmith and password=$@jsmithJS would be invalid.
  • A password cannot be the inverse of the Username. For example, Username=jsmith and password=$@htimsj would be invalid.
  • The user must not re-use the last three passwords.

For configuring the complexity of the password, set the required values in the MaxPasswordHistory field on the Administration > General Options screen in the user interface.

3.1.2.4 Password Expiration

Password expiration is enforced the first time a user logs in to the user interface. The admin user grants the new user with a temporary password during the initial user account setup. After logging in for the first time using the temporary password, the user interface forces the user to change the password. The user is re-directed to a password changing page that requires the user to enter the old password and then enter a new password twice.

The admin user can also configure the password expiration parameters on a system-wide basis. By default, password expiration occurs after 90 days. For more information about how to configure password expiration, see the Configuring the Expiration of Password section in the Operation, Administration, and Maintenance (OAM) Guide.

3.1.2.5 Restricting Concurrent Logins

The Insert User page has a Maximum Concurrent Logins field. The value in this field indicates the maximum number of concurrent logins a user can perform for each server. This feature cannot be enabled for users belonging to the Admin group. The value of this field can be set from 0 to 50.

The User Administration page has a Concurrent Logins Allowed field. The value in this field is the concurrent number of logins allowed.

Note:

For restricting the number of concurrent login instances for OS users, contact My Oracle Support.
3.1.2.6 External Authentication

Users can be authenticated remotely where an external LDAP server is used to perform the authentication.

3.1.2.7 LDAP Authentication for Users

You can configure, update, or delete LDAP authentication servers under the Remote Servers option. If multiple LDAP servers are configured, then the first available server in the list is used to perform the authentication. The secondary server is used only if the first server is unavailable for authentication.

The following elements are required to configure an LDAP server:

  • Hostname
  • Account Domain Name
  • Account Domain Name Short
  • Port
  • Base DN
  • Password
  • Account Filter Format
  • Account Canonical Form
  • Referrals
  • Bind Requires DN

For more information on how to configure the LDAP server, see the LDAP Authentication section in the Operation, Administration, and Maintenance (OAM) Guide.

3.1.2.8 SSO Authentication for Users

Single Sign-On (SSO) allows the user to log into multiple servers within an SSO zone by using a shared certificate among the subject servers within the zone. Once a user is authenticated successfully with any system in the SSO domain, the user can access other systems in the SSO zone without re-entering the authentication credentials.

When two zones in the SSO domain exchange certificates, a trusted relationship is established between the zones and all the systems grouped into the zone, expanding the authenticated login capability to servers in both zones. For more information on how to configure SSO zones, see the Certificate Management section in the Operation, Administration, and Maintenance (OAM) Guide.

3.1.2.9 Password Strengthening Procedures

This section describes various procedures to set the password strength for each and every server in the topology.

3.1.2.9.1 Setting Password Strength with Minimum Digit Characters

This section describes the procedure to set a strong password using minimum digits for each and every server in the topology.

Run the following procedure for each and every server in the topology:
  1. Log in as admusr on the server.
    login: admusr
Password: <current admin user password>
  2. Check out the file system-auth and password-auth:
    $ sudo rcstool co /etc/pam.d/system-auth
$ sudo rcstool co /etc/pam.d/password-auth
  3. Run the following commands:
    $ sudo sed -i --follow-symlinks "/pam_cracklib.so/ s/$/ dcredit=-1/" /etc/pam.d/system-auth
$ sudo sed -i --follow-symlinks "/pam_cracklib.so/ s/$/ dcredit=-1/" /etc/pam.d/password-auth
  4. Check in the file system-auth and password-auth:
    $ sudo rcstool ci /etc/pam.d/system-auth
$ sudo rcstool ci /etc/pam.d/password-auth
3.1.2.9.2 Setting Password Strength with Minimum Uppercase Characters

This section describes the procedure to set a strong password using minimum uppercase characters for each and every server in the topology.

Run the following procedure for each and every server in the topology:
  1. Log in as admusr on the server.
    login: admusr
Password: <current admin user password>
  2. Check out the file system-auth and password-auth:
    $ sudo rcstool co /etc/pam.d/system-auth
$ sudo rcstool co /etc/pam.d/password-auth
  3. Run the following commands:
    $ sudo sed -i --follow-symlinks "/pam_cracklib.so/ s/$/ ucredit=-2/" /etc/pam.d/system-auth
$ sudo sed -i --follow-symlinks "/pam_cracklib.so/ s/$/ ucredit=-2/" /etc/pam.d/password-auth
  4. Check in the file system-auth and password-auth:
    $ sudo rcstool ci /etc/pam.d/system-auth
$ sudo rcstool ci /etc/pam.d/password-auth
3.1.2.9.3 Setting Password Strength with Minimum Special Characters

This section describes the procedure to set a strong password using minimum special characters for each and every server in the topology.

Run the following procedure for each and every server in the topology:
  1. Log in as admusr on the server.
    login: admusr
Password: <current admin user password>
  2. Check out the file system-auth and password-auth:
    $ sudo rcstool co /etc/pam.d/system-auth
$ sudo rcstool co /etc/pam.d/password-auth
  3. Run the following commands:
    $ sudo sed -i --follow-symlinks "/pam_cracklib.so/ s/$/ ocredit=-2/" /etc/pam.d/system-auth
$ sudo sed -i --follow-symlinks "/pam_cracklib.so/ s/$/ ocredit=-2/" /etc/pam.d/password-auth
  4. Check in the file system-auth and password-auth:
    $ sudo rcstool ci /etc/pam.d/system-auth
$ sudo rcstool ci /etc/pam.d/password-auth
3.1.2.9.4 Setting Password Strength with Minimum Lowercase Characters

This section describes the procedure to set a strong password using minimum lowercase characters for each and every server in the topology.

Run the following procedure for each and every server in the topology:
  1. Log in as admusr on the server.
    login: admusr
Password: <current admin user password>
  2. Check out the file system-auth and password-auth:
    $ sudo rcstool co /etc/pam.d/system-auth
$ sudo rcstool co /etc/pam.d/password-auth
  3. Run the following commands:
    $ sudo sed -i --follow-symlinks "/pam_cracklib.so/ s/$/ lcredit=-2/" /etc/pam.d/system-auth
$ sudo sed -i --follow-symlinks "/pam_cracklib.so/ s/$/ lcredit=-2/" /etc/pam.d/password-auth
  4. Check in the file system-auth and password-auth:
    $ sudo rcstool ci /etc/pam.d/system-auth
$ sudo rcstool ci /etc/pam.d/password-auth
3.1.2.9.5 Setting Deny for Failed Password Attempts

This section describes the procedure to deny the user access for failed password attempts.

Run the following procedure for each and every server in the topology:
  1. Log in as admusr on the server.
    login: admusr
Password: <current admin user password>
  2. Check out the file system-auth and password-auth:
    $ sudo rcstool co /etc/pam.d/system-auth
$ sudo rcstool co /etc/pam.d/password-auth
  3. Run the following commands:
    $ sudo sed -i --follow-symlinks "/^auth.*sufficient.*pam_unix.so.*/i auth        required      pam_faillock.so preauth silent deny=5 unlock_time=604800 fail_interval=900" /etc/pam.d/system-auth

$ sudo sed -i --follow-symlinks "/^auth.*sufficient.*pam_unix.so.*/a auth        [default=die] pam_faillock.so authfail deny=5 unlock_time=604800 fail_interval=900" /etc/pam.d/system-auth 

$ sudo sed -i --follow-symlinks "/^account.*required.*pam_unix.so/i account     required      pam_faillock.so" /etc/pam.d/system-auth

$ sudo sed -i --follow-symlinks "/^auth.*sufficient.*pam_unix.so.*/i auth        required      pam_faillock.so preauth silent deny=5 unlock_time=604800 fail_interval=900" /etc/pam.d/password-auth

$ sudo sed -i --follow-symlinks "/^auth.*sufficient.*pam_unix.so.*/a auth        [default=die] pam_faillock.so authfail deny=5 unlock_time=604800 fail_interval=900" /etc/pam.d/password-auth 

$ sudo sed -i --follow-symlinks "/^account.*required.*pam_unix.so/i account     required      pam_faillock.so" /etc/pam.d/password-auth
  4. Check in the file system-auth and password-auth:
    $ sudo rcstool ci /etc/pam.d/system-auth
$ sudo rcstool ci /etc/pam.d/password-auth
3.1.2.9.6 Setting Minimum Password Length

This section describes the procedure to set the minimum length for a password.

Run the following procedure for each and every server in the topology:
  1. Log in as admusr on the server.
    login: admusr
Password: <current admin user password>
  2. Check out the file system-auth and grep for variable ‘minlen’ in the file using the following command: 
    
$ sudo rcstool co /etc/pam.d/system-auth 
$ grep minlen /etc/pam.d/system-auth
    • If a result is returned, then run the following command: 
      $ sudo sed -i "/password.*requisite.*pam_cracklib.so/s/minlen[^ ]*/minlen=14/" /etc/pam.d/system-auth
    • If no result is returned, then run the following command: 
      $ sudo sed -i "/password.*requisite.*pam_cracklib.so/s/$/ minlen=14/" /etc/pam.d/system-auth
  3. Check in the file system-auth:
    $ sudo rcstool ci /etc/pam.d/system-auth
3.1.2.10 Login and Welcome Banner Customization

The DSR GUI allows to enter custom messages to the Login screen and Welcome message after successful user login. The Administration > Options page allows the admin user to view a list of global options.

To enter a custom message to the Login screen, the admin user can enter the required message in the LoginMessage field. This enables the user to view the customized login message on the login screen.

To enter a custom message to the Welcome Banner, the admin user can enter the required message in the WelcomeMessage field. This enables the user to view the customized welcome message after successful login.

3.1.2.11 SSH Security Hardening Procedures

This section describes the security hardening procedures using Secure Socket Shell (SSH).

3.1.2.11.1 Setting SSH Client Alive Count

This section describes the procedure to set the count for SSH client.

Run the following procedure for each and every server in the topology:
  1. Log in as admusr on the server.
    login: admusr
Password: <current admin user password>
  2. Run the following command to check out the file sshd_config and grep for variable ClientAliveCountMax in the file :
    $ sudo rcstool co /etc/ssh/sshd_config
$ sudo grep ^ClientAliveCountMax /etc/ssh/sshd_config
  3. Run the following command if no result is returned after running step 2:
    $ sudo echo "ClientAliveCountMax 0" >> /etc/ssh/sshd_config

    Run the following command if some result is returned after running step 2:

    $ sudo sed -i "s/ClientAliveCountMax.*/ClientAliveCountMax 0/g" /etc/ssh/sshd_config
  4. Check in the file sshd_config:
    $ sudo rcstool ci /etc/ssh/sshd_config
3.1.2.11.2 Disabling SSH Access through Empty Passwords

This section describes the procedure to disable the SSH access through empty passwords.

Run the following procedure for each and every server in the topology:
  1. Log in as admusr on the server.
    login: admusr
Password: <current admin user password>
  2. Run the following command to check out the file sshd_config and grep for variablePermitEmptyPasswords in the file :
    $ sudo rcstool co /etc/ssh/sshd_config
$ sudo grep PermitEmptyPasswords /etc/ssh/sshd_config
  3. Run the following command if no result is returned after running step 2:
    $ sudo echo "PermitEmptyPasswords no" >> /etc/ssh/sshd_config

    Run the following command if some result is returned after running step 2:

    $ sudo sed -i '/PermitEmptyPasswords/c\PermitEmptyPasswords no' /etc/ssh/sshd_config
  4. Check in the file sshd_config:
    $ sudo rcstool ci /etc/ssh/sshd_config
3.1.2.11.3 Enabling SSH Warning Banner

This section describes the procedure to enable the SSH warning banner.

Run the following procedure for each and every server in the topology:
  1. Log in as admusr on the server.
    login: admusr
Password: <current admin user password>
  2. Run the following command to check out the file sshd_config and grep for variable Banner in the file :
    $ sudo rcstool co /etc/ssh/sshd_config
$ sudo grep Banner /etc/ssh/sshd_config
  3. Run the following command if no result is returned after running step 2:
    $ sudo echo “Banner /etc/issue" >> /etc/ssh/sshd_config

    Run the following command if some result is returned after running step 2:

    $ sudo sed -i '/Banner/c\Banner \/etc\/issue' /etc/ssh/sshd_config
  4. Check in the file sshd_config:
    $ sudo rcstool ci /etc/ssh/sshd_config
3.1.2.11.4 Denying SSH Environment Options

This section describes the procedure to deny SSH environment options on each and every server in the topology.

Run the following procedure for each and every server in the topology:
  1. Log in as admusr on the server.
    login: admusr
Password: <current admin user password>
  2. Run the following command to check out the file sshd_config and grep for variable PermitUserEnvironment in the file :
    $ sudo rcstool co /etc/ssh/sshd_config
$ sudo grep PermitUserEnvironment /etc/ssh/sshd_config
  3. Run the following command if no result is returned after running step 2:
    $ sudo echo “PermitUserEnvironment no" >> /etc/ssh/sshd_config

    Run the following command if some result is returned after running step 2:

    $ sudo sed -i '/PermitUserEnvironment/c\PermitUserEnvironment no' /etc/ssh/sshd_config
  4. Check in the file sshd_config:
    $ sudo rcstool ci /etc/ssh/sshd_config
3.1.2.11.5 Generating RSA SSH Key for Admin User

This section describes the procedure to generate a passphrase protected RSA SSH key for 'admusr' User Account.

Run the following procedure on each server in the topology. The order of execution in the topology must be from level 'A' servers to level 'C' servers:
  1. Log in as admusr on the server.
    login: admusr
Password: <current admin user password>
  2. Run the following command to stop the apwSoapServer process:
    $ sudo pm.set off apwSoapServer
  3. Run the following command to go to .ssh directory and remove the old DSA keys if they exist:
    $ cd /home/admusr/.ssh
$ sudo rm –rf id_dsa id_dsa.pub
  4. Run the following command to generate a new RSA key:
    $ ssh-keygen -t rsa -b 4096

    Provide the desired location to save the key or it can be left blank. On leaving it blank, the default location /home/admusr/.ssh/id_rsa is used: 

    $ Enter file in which to save the key (/home/admusr/.ssh/id_rsa):

    Enter the passphrase:

    $ Enter passphrase (empty for no passphrase):

    Confirm the passphrase again:

    $ Enter same passphrase again:
    A password protected RSA key is generated successfully.
  5. Run the following command to start the apwSoapServer process:
    $ sudo pm.set on apwSoapServer
After 60 seconds, the server will use the generated RSA key.

After running the procedure, any key-based SSH login for the 'admusr' account prompts for a passphrase. Setting a passphrase on the key affects the execution of procedures that require SSH access using the ‘admusr’ account. The admin user is prompted to enter the passphrase for each SSH access. For more information on how to run the procedures that require SSH access, see the Changing TPD Web Service Password and Changing the Configuration Web Services Password sections.

3.1.2.11.6 Setting SSH Log Level

This section describes the procedure to set SSH log level to INFO.

Run the following procedure for each and every server in the topology:
  1. Log in as admusr on the server.
    login: admusr
Password: <current admin user password>
  2. Run the following command to check out the file sshd_config:
    $ sudo rcstool co /etc/ssh/sshd_config
  3. Run the following command:
    $ sudo sed -i '/LogLevel/c\LogLevel INFO' /etc/ssh/sshd_config
  4. Check in the file sshd_config:
    $ sudo rcstool ci /etc/ssh/sshd_config
3.1.2.11.7 Enabling SSH IgnoreRhosts

This section describes the procedure to enable SSH IgnoreRhosts.

Run the following procedure for each and every server in the topology:
  1. Log in as admusr on the server.
    login: admusr
Password: <current admin user password>
  2. Run the following command to check out the file sshd_config:
    $ sudo rcstool co /etc/ssh/sshd_config
  3. Run the following command:
    $ sudo sed -i '/IgnoreRhosts/c\IgnoreRhosts yes' /etc/ssh/sshd_config
  4. Check in the file sshd_config:
    $ sudo rcstool ci /etc/ssh/sshd_config
3.1.2.11.8 Disabling SSH X11 Forwarding

This section describes the procedure to disable SSH X11 Forwarding.

Run the following procedure for each and every server in the topology:
  1. Log in as admusr on the server.
    login: admusr
Password: <current admin user password>
  2. Run the following command to check out the file sshd_config:
    $ sudo rcstool co /etc/ssh/sshd_config
  3. Run the following command:
    $ sudo sed -i '/X11Forwarding yes/s/^/#/g' /etc/ssh/sshd_config
$ sudo sed -i '/X11Forwarding no/s/^#//g' /etc/ssh/sshd_config
  4. Check in the file sshd_config:
    $ sudo rcstool ci /etc/ssh/sshd_config
3.1.2.11.9 Disabling SSH HostbasedAuthentication

This section describes the procedure to disable SSH host based authentication.

Run the following procedure for each and every server in the topology:
  1. Log in as admusr on the server.
    login: admusr
Password: <current admin user password>
  2. Run the following command to check out the file sshd_config:
    $ sudo rcstool co /etc/ssh/sshd_config
  3. Run the following command:
    $ sudo sed -i '/HostbasedAuthentication no/s/^#//g' /etc/ssh/sshd_config
  4. Check in the file sshd_config:
    $ sudo rcstool ci /etc/ssh/sshd_config
3.1.2.11.10 Setting SSH LoginGraceTime

This section describes the procedure to set the SSH Login grace time to 1 min.

Run the following procedure for each and every server in the topology:
  1. Log in as admusr on the server.
    login: admusr
Password: <current admin user password>
  2. Run the following command to check out the file sshd_config:
    $ sudo rcstool co /etc/ssh/sshd_config
  3. Run the following command:
    $ sudo sed -i '/LoginGraceTime/c\LoginGraceTime 60' /etc/ssh/sshd_config
  4. Check in the file sshd_config:
    $ sudo rcstool ci /etc/ssh/sshd_config
3.1.2.11.11 Disabling SSH Insecure Key Exchange Algorithms and Setting Up Key Length

This section describes the procedure to disable diffie-hellman-group1-sha1 and gss-group1-sha1 key exchange (Kex) algorithms, and to set the moduli (key length) longer than 1024 bits.

Run the following procedure for each server in the topology:
  1. Log in as admusr on the server.
    login: admusr
Password: <current admin user password>
  2. Run the following command to check if the keys used are lesser than 1024 bits.
    $ sudo awk '$5 <= 1024' /etc/ssh/moduli
  3. If no result is returned after running step 2, it means there are no keys lesser than 1024 bits used. You can skip steps 4 and 5.
    Else, check-out the file moduli:
    $ sudo rcstool co /etc/ssh/moduli
  4. Run the following command to configure the SSH service to use Diffie-Hellman moduli that are greater than 1024 bits.
    $ sudo awk '$5 > 1024' /etc/ssh/moduli > tmp$$
    $ sudo mv tmp$$ /etc/ssh/moduli
  5. Run the following command to check-in the file moduli:
    $ sudo rcstool ci /etc/ssh/moduli
  6. Run the following command to verify if the diffie-hellman-group1-sha1 key exchange algorithm is supported:
    $ sudo sshd -T | grep diffie-hellman-group1-sha1
  7. If no result is returned after running step 6, it means diffie-hellman-group1-sha1 key exchange algorithm is already disabled. You can skip steps 8 and 9.
    Else, check-out the files sshd_config and ssh_config:
    $ sudo rcstool co /etc/ssh/sshd_config
    $ sudo rcstool co /etc/ssh/ssh_config
  8. Run the following commands to disable diffie-hellman-group1-sha1 key exchange algorithm:
    $ sudo grep -iq "^[ ]*KexAlgorithms" /etc/ssh/ssh_config && sudo sed -i "s/^[ ]*KexAlgorithms.*/KexAlgorithms $(sudo sshd -T | grep diffie-hellman-group1-sha1 | awk 'tolower($1)==kexalgorithms {$1="\n"$1;} {print $2;}' | sed 's/diffie-hellman-group1-sha1,//g; s/,diffie-hellman-group1-sha1//g')/i" /etc/ssh/ssh_config || sudo sed -i "$ a KexAlgorithms $(sudo sshd -T | grep diffie-hellman-group1-sha1 | awk 'tolower($1)==kexalgorithms {$1="\n"$1;} {print $2;}' | sed 's/diffie-hellman-group1-sha1,//g; s/,diffie-hellman-group1-sha1//g')" /etc/ssh/ssh_config
    $ sudo grep -iq "^[ ]*KexAlgorithms" /etc/ssh/sshd_config && sudo sed -i "s/^[ ]*KexAlgorithms.*/KexAlgorithms $(sudo sshd -T | grep diffie-hellman-group1-sha1 | awk 'tolower($1)==kexalgorithms {$1="\n"$1;} {print $2;}' | sed 's/diffie-hellman-group1-sha1,//g; s/,diffie-hellman-group1-sha1//g')/i" /etc/ssh/sshd_config || sudo sed -i "$ a KexAlgorithms $(sudo sshd -T | grep diffie-hellman-group1-sha1 | awk 'tolower($1)==kexalgorithms {$1="\n"$1;} {print $2;}' | sed 's/diffie-hellman-group1-sha1,//g; s/,diffie-hellman-group1-sha1//g')" /etc/ssh/sshd_config
  9. Run the following commands to check-in the files sshd_config and ssh_config:
    $ sudo rcstool ci /etc/ssh/sshd_config
    $ sudo rcstool ci /etc/ssh/ssh_config
  10. Run the following command to check if gss-group1-sha1- key exchange algorithm is supported:
    $ sudo sshd -T | grep gss-group1-sha1-
  11. If no result is returned after running step 10, it means gss-group1-sha1- key exchange algorithm is already disabled. You can skip steps 12 and 13.
    Else, check-out the files sshd_config and ssh_config:
    $ sudo rcstool co /etc/ssh/sshd_config
    $ sudo rcstool co /etc/ssh/ssh_config
  12. Run the following commands to disable gss-group1-sha1- key exchange algorithm:
    $ sudo grep -iq "^[ ]*GSSAPIKexAlgorithms" /etc/ssh/ssh_config && sudo sed -i "s/^[ ]*GSSAPIKexAlgorithms.*/GSSAPIKexAlgorithms $(sudo sshd -T | grep gss-group1-sha1- | awk 'tolower($1)==gssapikexalgorithms {$1="\n"$1;} {print $2;}' | sed 's/gss-group1-sha1-,//g; s/,gss-group1-sha1-//g')/i" /etc/ssh/ssh_config || sudo sed -i "$ a GSSAPIKexAlgorithms $(sudo sshd -T | grep gss-group1-sha1- | awk 'tolower($1)==gssapikexalgorithms {$1="\n"$1;} {print $2;}' | sed 's/gss-group1-sha1-,//g; s/,gss-group1-sha1-//g')" /etc/ssh/ssh_config
    $ sudo grep -iq "^[ ]*GSSAPIKexAlgorithms" /etc/ssh/sshd_config && sudo sed -i "s/^[ ]*GSSAPIKexAlgorithms.*/GSSAPIKexAlgorithms $(sudo sshd -T | grep gss-group1-sha1- | awk 'tolower($1)==gssapikexalgorithms {$1="\n"$1;} {print $2;}' | sed 's/gss-group1-sha1-,//g; s/,gss-group1-sha1-//g')/i" /etc/ssh/sshd_config || sudo sed -i "$ a GSSAPIKexAlgorithms $(sudo sshd -T | grep gss-group1-sha1- | awk 'tolower($1)==gssapikexalgorithms {$1="\n"$1;} {print $2;}' | sed 's/gss-group1-sha1-,//g; s/,gss-group1-sha1-//g')" /etc/ssh/sshd_config
  13. Run the following commands to check-in the files sshd_config and ssh_config:
    $ sudo rcstool ci /etc/ssh/sshd_config
    $ sudo rcstool ci /etc/ssh/ssh_config
  14. Run the following command to restart sshd service:
    $ sudo service sshd restart
3.1.2.11.12 Disabling SSH Weak Key Exchange Algorithms

This section describes the procedure to disable SSH weak Key Exchange (Kex) algorithms. Only the strong and secure KexAlgorithms and GSSAPIKexAlgorithms are to be enabled.

Perform the following procedure on each server in the topology:
  1. Log in as admusr on the server.
    login: admusr
Password: <current admin user password>
  2. To check-out the /etc/sysconfig/sshd file, run the following command:
    $ sudo rcstool co /etc/sysconfig/sshd
  3. To check if the CRYPTO_POLICY line in the /etc/sysconfig/sshd file is commented, run the following command:
    $ sudo grep -i "^[[:space:]#]*CRYPTO_POLICY" /etc/sysconfig/sshd
  4. If a result after running step 3 specifies that the CRYPTO_POLICY line in /etc/sysconfig/sshd file is commented, uncomment the line to opt out of the system-wide crypto policies for OpenSSH server by running the following command:
    $ sudo sed -i "s/^[ #]*CRYPTO_POLICY.*/CRYPTO_POLICY=/i" /etc/sysconfig/sshd

    Note:

    Else, you can skip this step.
  5. If the 04-configure-SSH.conf custom configuration file, to specify the crypto policy, is not located in the /etc/ssh/ssh_config.d/ directory, then create one configuration file to opt out of the system-wide crypto policies for OpenSSH client, by running the following commands:
    $ sudo touch /etc/ssh/ssh_config.d/04-configure-SSH.conf
    $ sudo chmod 644 /etc/ssh/ssh_config.d/04-configure-SSH.conf
    $ sudo chown root:root /etc/ssh/ssh_config.d/04-configure-SSH.conf
  6. To check-out the sshd_config and 04-configure-SSH.conf files, run the following commands:
    $ sudo rcstool co /etc/ssh/sshd_config
    $ sudo rcstool co /etc/ssh/ssh_config.d/04-configure-SSH.conf
  7. To check if the required KexAlgorithms in the server side are enabled in order, run the following command:
    $ sudo sshd -T | grep -i "^kexalgorithms" | grep "[[:space:]]curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp384,ecdh-sha2-nistp256,ecdh-sha2-nistp521,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group-exchange-sha256$"
  8. If a result after running step 7 specifies that the required KexAlgorithms in the server side are enabled in order, you can skip this step.
    Else, enable them in order in the sshd_config file, by running the following command:
    $ sudo grep -iq "^[ ]*KexAlgorithms" /etc/ssh/sshd_config && sudo sed -i "s/^[ ]*KexAlgorithms.*/KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp384,ecdh-sha2-nistp256,ecdh-sha2-nistp521,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group-exchange-sha256/i" /etc/ssh/sshd_config || sudo sed -i "$ a KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp384,ecdh-sha2-nistp256,ecdh-sha2-nistp521,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group-exchange-sha256" /etc/ssh/sshd_config
  9. To check if the required KexAlgorithms in the client side are enabled in order, run the following command:
    $ sudo grep -i "^[[:space:]]*kexalgorithms" /etc/ssh/ssh_config.d/04-configure-SSH.conf | grep "[[:space:]]curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp384,ecdh-sha2-nistp256,ecdh-sha2-nistp521,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group-exchange-sha256$"
  10. If a result after running step 9 specifies that the required KexAlgorithms in the client side are enabled in order, you can skip this step.
    Else, enable them in order in the 04-configure-SSH.conf file.
    If the 04-configure-SSH.conf file is empty (zero-byte file), run the following command:
    $ sudo echo "KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp384,ecdh-sha2-nistp256,ecdh-sha2-nistp521,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group-exchange-sha256" | sudo tee -a /etc/ssh/ssh_config.d/04-configure-SSH.conf > /dev/null
    If the 04-configure-SSH.conf file is non-empty, run the following command:
    $ sudo grep -iq "^[ ]*KexAlgorithms" /etc/ssh/ssh_config.d/04-configure-SSH.conf && sudo sed -i "s/^[ ]*KexAlgorithms.*/KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp384,ecdh-sha2-nistp256,ecdh-sha2-nistp521,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group-exchange-sha256/i" /etc/ssh/ssh_config.d/04-configure-SSH.conf || sudo sed -i "$ a KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp384,ecdh-sha2-nistp256,ecdh-sha2-nistp521,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group-exchange-sha256" /etc/ssh/ssh_config.d/04-configure-SSH.conf
  11. To check if the required GSSAPIKexAlgorithms in the server side are enabled in order, run the following command:
    $ sudo sshd -T | grep -i "^gssapikexalgorithms" | grep "[[:space:]]gss-group14-sha256-,gss-group16-sha512-,gss-nistp256-sha256-,gss-curve25519-sha256-$"
  12. If a result after running step 11 specifies that the required GSSAPIKexAlgorithms in the server side are enabled in order, you can skip this step.
    Else, enable them in order in the sshd_config file, by running the following command:
    $ sudo grep -iq "^[ ]*GSSAPIKexAlgorithms" /etc/ssh/sshd_config && sudo sed -i "s/^[ ]*GSSAPIKexAlgorithms.*/GSSAPIKexAlgorithms gss-group14-sha256-,gss-group16-sha512-,gss-nistp256-sha256-,gss-curve25519-sha256-/i" /etc/ssh/sshd_config || sudo sed -i "$ a GSSAPIKexAlgorithms gss-group14-sha256-,gss-group16-sha512-,gss-nistp256-sha256-,gss-curve25519-sha256-" /etc/ssh/sshd_config
  13. To check if the required GSSAPIKexAlgorithms in the client side are enabled in order, run the following command:
    $ sudo grep -i "^[[:space:]]*gssapikexalgorithms" /etc/ssh/ssh_config.d/04-configure-SSH.conf | grep "[[:space:]]gss-group14-sha256-,gss-group16-sha512-,gss-nistp256-sha256-,gss-curve25519-sha256-$"
  14. If a result after running step 13 specifies that the required GSSAPIKexAlgorithms in the client side are enabled in order, you can skip this step.
    Else, enable them in order in the 04-configure-SSH.conf file.
    If the 04-configure-SSH.conf file is empty (zero-byte file), run the following command:
    $ sudo echo "GSSAPIKexAlgorithms gss-group14-sha256-,gss-group16-sha512-,gss-nistp256-sha256-,gss-curve25519-sha256-" | sudo tee -a /etc/ssh/ssh_config.d/04-configure-SSH.conf > /dev/null
    If the 04-configure-SSH.conf file is non-empty, run the following command:
    $ sudo grep -iq "^[ ]*GSSAPIKexAlgorithms" /etc/ssh/ssh_config.d/04-configure-SSH.conf && sudo sed -i "s/^[ ]*GSSAPIKexAlgorithms.*/GSSAPIKexAlgorithms gss-group14-sha256-,gss-group16-sha512-,gss-nistp256-sha256-,gss-curve25519-sha256-/i" /etc/ssh/ssh_config.d/04-configure-SSH.conf || sudo sed -i "$ a GSSAPIKexAlgorithms gss-group14-sha256-,gss-group16-sha512-,gss-nistp256-sha256-,gss-curve25519-sha256-" /etc/ssh/ssh_config.d/04-configure-SSH.conf
  15. To check-in the /etc/sysconfig/sshd, sshd_config, and 04-configure-SSH.conf files, run the following commands:
    $ sudo rcstool ci /etc/sysconfig/sshd
    $ sudo rcstool ci /etc/ssh/sshd_config
    $ sudo rcstool ci /etc/ssh/ssh_config.d/04-configure-SSH.conf
  16. To restart sshd service, run the following command:
    $ sudo service sshd restart
3.1.2.11.13 Disabling SSH Weak Host Key Algorithms, MACs, and Ciphers
This section describes the procedure to disable SSH weak Host Key Algorithms, MACs, and Ciphers. Only the strong and secure Host Key Algorithms, MACs, and Ciphers are to be enabled.

Perform the following procedure on each server in the topology:

  1. Log in as admusr on the server.
    login: admusr
Password: <current admin user password>
  2. To check-out the /etc/sysconfig/sshd file, run the following command:
    $ sudo rcstool co /etc/sysconfig/sshd
  3. To check if the CRYPTO_POLICY line in the /etc/sysconfig/sshd file is commented, run the following command:
    $ sudo grep -i "^[[:space:]#]*CRYPTO_POLICY" /etc/sysconfig/sshd
  4. If a result after running step 3 specifies that the CRYPTO_POLICY line in /etc/sysconfig/sshd file is commented, uncomment the line to opt out of the system-wide crypto policies for OpenSSH server by running the following command:
    $ sudo sed -i "s/^[ #]*CRYPTO_POLICY.*/CRYPTO_POLICY=/i" /etc/sysconfig/sshd

    Note:

    Else, you can skip this step.
  5. If the 04-configure-SSH.conf custom configuration file, to specify the crypto policy, is not located in the /etc/ssh/ssh_config.d/ directory, then create one configuration file to opt out of the system-wide crypto policies for OpenSSH client, by running the following commands:
    $ sudo touch /etc/ssh/ssh_config.d/04-configure-SSH.conf
    $ sudo chmod 644 /etc/ssh/ssh_config.d/04-configure-SSH.conf
    $ sudo chown root:root /etc/ssh/ssh_config.d/04-configure-SSH.conf
  6. To check-out the sshd_config and 04-configure-SSH.conf files, run the following commands:
    $ sudo rcstool co /etc/ssh/sshd_config
    $ sudo rcstool co /etc/ssh/ssh_config.d/04-configure-SSH.conf
  7. To check if the required HostKeyAlgorithms in the server side are enabled in order, run the following command:
    $ sudo sshd -T | grep -i "^hostkeyalgorithms" | grep "[[:space:]]ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp384,ecdsa-sha2-nistp384-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256,rsa-sha2-256-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp521-cert-v01@openssh.com$"
  8. If a result after running step 7 specifies that the required HostKeyAlgorithms in the server side are enabled in order, you can skip this step.
    Else, enable them in order in the sshd_config file, by running the following command:
    $ sudo grep -iq "^[ ]*HostKeyAlgorithms" /etc/ssh/sshd_config && sudo sed -i "s/^[ ]*HostKeyAlgorithms.*/HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp384,ecdsa-sha2-nistp384-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256,rsa-sha2-256-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp521-cert-v01@openssh.com/i" /etc/ssh/sshd_config || sudo sed -i "$ a HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp384,ecdsa-sha2-nistp384-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256,rsa-sha2-256-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp521-cert-v01@openssh.com" /etc/ssh/sshd_config
  9. To check if the required HostKeyAlgorithms in the client side are enabled in order, run the following command:
    $ sudo grep -i "^[[:space:]]*hostkeyalgorithms" /etc/ssh/ssh_config.d/04-configure-SSH.conf | grep "[[:space:]]ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp384,ecdsa-sha2-nistp384-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256,rsa-sha2-256-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp521-cert-v01@openssh.com$"
  10. If a result after running step 9 specifies that the required HostKeyAlgorithms in the client side are enabled in order, you can skip this step.
    Else, enable them in order in the 04-configure-SSH.conf file.
    If the 04-configure-SSH.conf file is empty (zero-byte file), run the following command:
    $ echo "HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp384,ecdsa-sha2-nistp384-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256,rsa-sha2-256-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp521-cert-v01@openssh.com" | sudo tee -a /etc/ssh/ssh_config.d/04-configure-SSH.conf > /dev/null
    If the 04-configure-SSH.conf file is non-empty, run the following command:
    $ sudo grep -iq "^[ ]*HostKeyAlgorithms" /etc/ssh/ssh_config.d/04-configure-SSH.conf && sudo sed -i "s/^[ ]*HostKeyAlgorithms.*/HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp384,ecdsa-sha2-nistp384-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256,rsa-sha2-256-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp521-cert-v01@openssh.com/i" /etc/ssh/ssh_config.d/04-configure-SSH.conf || sudo sed -i "$ a HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp384,ecdsa-sha2-nistp384-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256,rsa-sha2-256-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp521-cert-v01@openssh.com" /etc/ssh/ssh_config.d/04-configure-SSH.conf
  11. To check if the required MACs in the server side are enabled in order, run the following command:
    $ sudo sshd -T | grep -i "^macs" | grep "[[:space:]]hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com$"
  12. If a result after running step 11 specifies that the required MACs in the server side are enabled in order, you can skip this step.
    Else, enable them in order in the sshd_config file, by running the following command:
    $ sudo grep -iq "^[ ]*MACs" /etc/ssh/sshd_config && sudo sed -i "s/^[ ]*MACs.*/MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com/i" /etc/ssh/sshd_config || sudo sed -i "$ a MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com" /etc/ssh/sshd_config
  13. To check if the required MACs in the client side are enabled in order, run the following command:
    $ sudo grep -i "^[[:space:]]*macs" /etc/ssh/ssh_config.d/04-configure-SSH.conf | grep "[[:space:]]hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com$"
  14. If a result after running step 13 specifies that the required MACs in the client side are enabled in order, you can skip this step.
    Else, enable them in order in the 04-configure-SSH.conf file.
    If the 04-configure-SSH.conf file is empty (zero-byte file), run the following command:
    $ echo "MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com" | sudo tee -a /etc/ssh/ssh_config.d/04-configure-SSH.conf > /dev/null
    If the 04-configure-SSH.conf file is non-empty, run the following command:
    $ sudo grep -iq "^[ ]*MACs" /etc/ssh/ssh_config.d/04-configure-SSH.conf && sudo sed -i "s/^[ ]*MACs.*/MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com/i" /etc/ssh/ssh_config.d/04-configure-SSH.conf || sudo sed -i "$ a MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com" /etc/ssh/ssh_config.d/04-configure-SSH.conf
  15. To check if the required Ciphers in the server side are enabled in order, run the following command:
    $ sudo sshd -T | grep -i "^ciphers" | grep "[[:space:]]chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr$"
  16. If a result after running step 15 specifies that the required Ciphers in the server side are enabled in order, you can skip this step.
    Else, enable them in order in the sshd_config file, by running the following command:
    $ sudo grep -iq "^[ ]*Ciphers" /etc/ssh/sshd_config && sudo sed -i "s/^[ ]*Ciphers.*/Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr/i" /etc/ssh/sshd_config || sudo sed -i "$ a Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr" /etc/ssh/sshd_config
  17. To check if the required Ciphers in the client side are enabled in order, run the following command:
    $ sudo grep -i "^[[:space:]]*ciphers" /etc/ssh/ssh_config.d/04-configure-SSH.conf | grep "[[:space:]]chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr$"
  18. If a result after running step 17 specifies that the required Ciphers in the client side are enabled in order, you can skip this step.
    Else, enable them in order in the 04-configure-SSH.conf file.
    If the 04-configure-SSH.conf file is empty (zero-byte file), run the following command:
    $ echo "Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr" | sudo tee -a /etc/ssh/ssh_config.d/04-configure-SSH.conf > /dev/null
    If the 04-configure-SSH.conf file is non-empty, run the following command:
    $ sudo grep -iq "^[ ]*Ciphers" /etc/ssh/ssh_config.d/04-configure-SSH.conf && sudo sed -i "s/^[ ]*Ciphers.*/Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr/i" /etc/ssh/ssh_config.d/04-configure-SSH.conf || sudo sed -i "$ a Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr" /etc/ssh/ssh_config.d/04-configure-SSH.conf
  19. To check-in the /etc/sysconfig/sshd, sshd_config, and 04-configure-SSH.conf files, run the following commands:
    $ sudo rcstool ci /etc/sysconfig/sshd
    $ sudo rcstool ci /etc/ssh/sshd_config
    $ sudo rcstool ci /etc/ssh/ssh_config.d/04-configure-SSH.conf
  20. To restart sshd service, run the following command:
    $ sudo service sshd restart
3.1.2.11.14 Disabling SSH Server CBC Mode Ciphers
Perform the following procedure on each server in the topology to disable SSH Server CBC Mode Ciphers:
  1. Log in as admusr on the server.

    User id: admusr

    Password: <current admin user password>

  2. Run the following command to create the DISABLE-CBC.pmod file, if not present:
    
sudo touch /etc/crypto-policies/policies/modules/DISABLE-CBC.pmod 
sudo chmod 644 /etc/crypto-policies/policies/modules/DISABLE-CBC.pmod 
sudo chown root:root /etc/crypto-policies/policies/modules/DISABLE-CBC.pmod {code}
  3. Run the following command to check the required configuration:
    
sudo grep -i "cipher = -AES-128-CBC -AES-256-CBC -CAMELLIA-256-CBC -CAMELLIA-128-CBC" /etc/crypto-policies/policies/modules/DISABLE-CBC.pmod  {code}
  4. If a result after running step 3 specifies that the required ciphers are disabled, you can skip this step:
    
sudo echo "cipher = -AES-128-CBC -AES-256-CBC -CAMELLIA-256-CBC -CAMELLIA-128-CBC" >> /etc/crypto-policies/policies/modules/DISABLE-CBC.pmod {code}
  5. Run the following command to check the required configuration:
    sudo grep -i "cipher@TLS = -AES-256-CBC -AES-128-CBC" /etc/crypto-policies/policies/modules/DISABLE-CBC.pmod {code}
  6. If a result after running step 5 specifies that the required ciphers are disabled, you can skip this step:
    sudo echo "cipher@TLS = -AES-256-CBC -AES-128-CBC" >> /etc/crypto-policies/policies/modules/DISABLE-CBC.pmod{code}
  7. Run the following command to enable the policy:
    sudo /usr/bin/update-crypto-policies --set DEFAULT:DISABLE-CBC {code}
  8. Restart for the change of policies to fully take place:
    reboot
3.1.2.12 Services Hardening Procedures

This section describes various hardening procedures for the services.

3.1.2.12.1 Uninstalling tftp-server Package

This section describes the procedure to uninstall the tftp-server package.

Run the following procedure for each and every server in the topology:
  1. Log in as admusr on the server:
    login: admusr
Password: <current admin user password>
  2. Run the following command to remove the tftp-server package:
    $ sudo yum erase tftp-server
3.1.2.12.2 Disabling xinetd Service

This section describes the procedure to disable the xinetd service.

Run the following procedure for each and every server in the topology:
  1. Log in as admusr on the server:
    login: admusr
Password: <current admin user password>
  2. Run the following commands to disable the xinetd service for all run levels and to stop the xinetd, if its currently running:
    $ sudo yum erase tftp-server
$ sudo /sbin/service xinetd stop

    Note:

    This step might fail if the xinetd service is already disabled or stopped.
3.1.2.12.3 Uninstalling xinetd Service

This section describes the procedure to uninstall xinetd service.

Run the following procedure for each and every server in the topology:
  1. Log in as admusr on the server:
    login: admusr
Password: <current admin user password>
  2. Run the following commands to disable the xinetd service for all run levels and to stop the xinetd, if its currently running:
    $ sudo yum erase xinetd
3.1.2.12.4 Disabling ntpdate Service

This section describes the procedure to disable the ntpdate service.

Run the following procedure for each and every server in the topology:
  1. Log in as admusr on the server:
    login: admusr
Password: <current admin user password>
  2. Run the following commands to disable the ntpdate service:
    $ sudo chkconfig ntpdate off

3.2 SNMP Configuration

The DSR GUI has an interface to retrieve KPIs and alarms from a remote location using Simple Network Management Protocol (SNMP). Only the active Network OAM&P server allows SNMP administration. For more information, see the SNMP Trapping section in the Operation, Administration, and Maintenance (OAM) Guide.

The Active Network OAM&P server provides a single interface to SNMP data for the entire network, and individual servers interface directly with SNMP managers. The application sends SNMP traps to SNMP Managers that are registered to receive the traps. You can view and change the IP addresses and authorization information from the SNMP Trapping page.

You must set up at least one Manager to enable the SNMP. The system allows configuring up to five different Managers to receive SNMP traps and send requests. These could be either a valid IPv4 address or a valid hostname known to the system. The hostname must be unique and is case-insensitive. You can enter up to 20 characters into the string. The valid characters are alphanumeric and the minus sign. The hostname must start and end with an alphanumeric.

The Enabled Versions field on this page lets you pick the version of SNMP. The traps can be enabled or disabled collectively or independently from individual servers by checking the traps enabled checkbox on this page.

The SNMP Trapping page provides the following functionalities:

  • Add an SNMP manager
  • View SNMP settings
  • Update SNMP settings
  • Delete the SNMP manager

For more information on how to perform these actions, see the Operation, Administration, and Maintenance (OAM) Guide.

3.2.1 Enabling SNMP Versions

The Enabled Versions field in the SNMP Trapping page lets the user to enable the required SNMP version as follows:

  • SNMPv2c: Allows SNMP service only to managers with SNMPv2c authentication.
  • SNMPv3: Allows SNMP service only to managers with SNMPv3 authentication.
  • SNMPv2c and SNMPv3: Allows SNMP service to managers with SNMPv2c or SNMPv3 authentication. This is the default option.

Note:

The recommended option is SNMPv3 for secure operation.

3.2.2 Configuring Community Names

When the SNMPv2c is enabled in the Enabled Versions field, you must configure the SNMPV2c Community Name since it is a required field. The maximum length of the Community Name (String) is 31 characters. It is recommended to use unique, hard to guess Community Name values and avoid using well-known Community Names such as “public” and “private.”

3.3 SNMPv3 on PMAC

This section provides an overview of procedures and sub-procedures required to enable overall SNMPv3 protocol support on the PMAC system. It also provides an overview of the procedure to configure SNMP Version 3 security model and trap servers.

3.3.1 Enabling SNMPv3 Support on PMAC

There are multiple procedures and sub-procedures required to enable overall SNMPv3 protocol support on the PMAC system as follows:

  • Updating the SNMP service on existing remote servers on the PMAC control network.
  • Updating the SNMP service on the PMAC server service to support SNMPv3.
  • Updating the PMAC messaging system to support SNMPv3.
  • Updating the SNMPv3 Security settings.

For more information about performing the above steps, see PMAC Configuration Guide.

3.3.2 Configuring SNMPv3 Security Model and Trap Servers

The SNMPv3 security model supports only HP 6125G/XLG and Cisco 4948E/E-F switches. For more information about configuring the SNMPv3 security model and trap servers, see Procedure 18 and Procedure 19 in the PMAC Configuration Guide.

3.4 Authorized IPs

IP addresses that have permission to access the GUI can be added or deleted from the Authorized IPs page. If an IP address does not have permission to access the GUI and attempts to connect, a notification displays on the GUI, and access is not granted to that IP address.

Before enabling this feature, you must add the IP address of the client to the list of authorized IPs. Enabling the Authorized IPs functionality prevents unauthorized IP addresses from accessing the DSR GUI.

For more information about how to enable this feature, see the Authorized IPs section in the Operation, Administration, and Maintenance (OAM) Guide.

3.5 Certificate Management

The Certificate Management feature allows you to configure digital security certificates to secure the following:

  • Diameter Signaling Router (DSR) web sessions
  • user authentication through secure LDAP over TLS
  • Single Sign-On (SSO) authentication across a defined zone of DSR servers.

The feature functionalities are as follows:

  • supports certificates based on the hostname or fully qualified hostname.
  • allows building certificate signing requests (CSRs) for signing by a known certificate authority and later import the signed certificate into the DSR.
  • allows generating a Certificate Report of individual or all (wildcard) defined certificates.

For more information about the Certificate Management feature, see the Operation, Administration, and Maintenance (OAM) Guide.

3.5.1 Creating a New Certificate for WebLogic and Tomcat Servers

This section describes the procedures that allow you to create customized certificates and replace the default Appworks certificate provided by DSR.

3.5.1.1 Importing Certificate

This procedure describes the steps to import the certificate.

  1. When the CA returns the signed public key with the intermediate and root certificates, run the following command to import the intermediate and root certificates into your Keystore:
    keytool -importcert -v -noprompt -trustcacerts -alias <alias_for_root_certificate> -file <root_certificate_file> -keystore <server_keystore>.jks -storepass <store_password>
    Where,
      • <alias_for_root_certificate> indicates an alias for the root certificate.
      • root_certificate_file indicates the file name of the root certificate issued by CA.
      • server_keystore indicates the JKS file name that was generated during the Keystore creation.
      • store_password indicates the store password that was provided during the Keystore creation.
  2. Import the public certificate into the Keystore using the private key alias.
  3. To obtain the certificate:
    • From the CA’s website, download the root CA and intermediate CA if available.
    • Double-click the certificate file, and then go to the Certification Path tab.

    • The first certificate in the list is the root CA and the second one is the intermediate CA if available. If you highlight the root CA, and then click View Certificate, it opens the Root CA certificate. Then, you can go to the Details tab and click <Copy to file>. Select Base 64 as the format and save the file. Repeat the same steps to copy the intermediate CA to a file.

  4. When you obtain root CA, intermediate, and certificate files, if you have an intermediate CA, edit it and copy all the content.
  5. Edit the certificate file and paste the intermediate at the bottom of the server certificate. Skip this step if you do not have an intermediate CA.
  6. Repeat the same step for the root CA and paste it at the end of the previously added certificate.
    The following is a sample certificate:
    -------BEGIN CERTIFICATE---------
dfsfsdfdf
sfsdfwehdfhdf <---------certificate
dgdfgfgfdg
--------END CERTIFICATE-----------
-------BEGIN CERTIFICATE---------
hghjgfjgj
sfsdfwejjhdfhdf <---------intermediate
dgdfgiuiyuiuiyufgfdg
--------END CERTIFICATE-----------
-------BEGIN CERTIFICATE---------
dfsfsmbvmvbmdfdf
sfsdetetrtyrfwehdfhdf <---------root CA
dgdfgnbnbvnvbfgfdg
--------END CERTIFICATE-----------
  7. Run the following command to import the certificate:
    keytool -importcert -v -alias <alias_name> -file <mycert> -keystore <server_keystore>.jks -keypass <key_password> -storepass <store_password>
    Where,
    • <alias_name> indicates the alias that was used during the creation of Keystore.
    • <mycert> indicates the file name of the certificate issued by CA.
    • <server_keystore> indicates the JKS file name that was generated during the Keystore creation.
    • <key_password> indicates the Keystore password that was provided during the Keystore creation.
    • <store_password> indicates the store password that was provided during the Keystore creation.
  8. Run the following command to check whether the Keystore creation is complete:
    keytool -list -v -keystore <server_keystore>.jks -storepass <store_password>
  9. Run the following command to import the root CA of your signed certificate to the Trust KeyStore file:
    keytool -alias server_cert -import -file rootcacert.cer -keystore trustkeystore.jks -storepass <Password>
3.5.1.2 Configuring Keystore on WebLogic

This procedure describes the steps to configure Keystore on WebLogic.

  1. Log in to the WebLogic Server Administration Console using your login credentials.
  2. In the left navigation pane, click Environment > Servers.
  3. In the Customize this table section, in the Name column, click nsp(admin).

    nsp(admin) is the server for which the identity and trust keystores configuration is performed.

  4. In the Settings for nsp section, click Configuration > Keystores.
  5. To edit or modify the existing settings of the Keystore configuration, in the left navigation pane, click Lock & Edit.
  6. In the Keystores section, edit the following fields as required:
    • Custom Identity Keystore: Enter the fully qualified path to the identity Keystore.
    • Custom Identity Keystore Type: Enter the type of Keystore.

      This attribute is a Java KeyStore (JKS). The default value is JKS.

    • Custom Identity Keystore Passphrase: Enter the password required for reading or writing to the Keystore, for example, weblogic1234.
    • Custom Trust Keystore: Enter the fully qualified path to the trust Keystore.
    • Custom Trust Keystore Passphrase: Enter the passphrase of the custom trust Keystore.
    • Confirm Custom Trust Keystore Passphrase: Re-enter the passphrase of the custom trust Keystore.
  7. Click Save.
  8. In the Settings for nsp section, click Configuration > SSL.
  9. In the Identity section, edit the following fields as required:
    • Private Key Alias: Enter the fully qualified path to the identity Keystore.
    • Private Key Passphrase: Enter the same password used for the creation of Keystore, for example, weblogic1234.
    • Confirm Private Key Passphrase: Re-enter the same password used in the Private Key Passphrase field.
  10. Click Save.
  11. In the left navigation pane, click Activate Changes.
  12. Restart WebLogic by logging in to app server using admusr, and then run the following command:
    sudo service xih-apps restart

3.6 SFTP Administration

Oracle Communications Diameter Signaling Router (DSR) supports SFTP sessions with external servers to transfer various files from DSR. The authentication process requires a digital certificate to authenticate the sessions. The external server drives the files transfer process.

For more information, see the SFTP Users Administration section in the Operation, Administration, and Maintenance (OAM) Guide.