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

3 Implement Oracle Communications Diameter Signaling Router Security

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.

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 privileges can view or make changes to user accounts or groups. For more details on user administration, see the Users Administration section in the Operation, Administration, and Maintenance (OAM) Guide.

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 the 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

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

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.

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.

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

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.

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.

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 Oracle technical support.
External Authentication

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

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.

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.

Password Strengthening Procedures

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

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

SSH Security Hardening Procedures

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

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
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
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 variableBanner 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
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 variablePermitUserEnvironment 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
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 the TPD Web Services Password and Changing the Configuration Web Services Password sections.

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
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
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
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
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
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
Services Hardening Procedures

This section describes various hardening procedures for the services.

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

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.

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.

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

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.

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 PMACserver 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 Appendix S in the PMAC Configuration Guide.

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.

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.

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.

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.

Creating Keystore and Certificate Signing Request

This procedure describes the steps to create a keystore and Certificate Signing Request (CSR).

  1. Log in to the application VM of IDIH using SSH.
  2. Run the following command to change the user to tekelec:
    sudo su – tekelec
  3. Run the following command to change the directory to the Weblogic domain (nsp):
    cd /usr/TKLC/xIH/bea/user_projects/domains/tekelec/nsp
  4. Run the following commands to take a backup of the existing key and trust stores:
    cp idih.jks idih_bkp.jks
cp idih-trust.jks idih-trust-bkp.jks
  5. Run the following command to create a keystore and a private key using the genkeypair or genkey command:
    keytool -genkeypair -alias <alias_name> -keyalg RSA -keysize 1024 -dname "CN=<ServerName>, OU=GTI, O=<CompanyName>, L=<City>, ST=<State>,C=<Country> " -keypass <key_password> -keystore <server_keystore>.jks -storepass <store_password>
    Where,
    • <alias_name> indicates the alias for the keystore.
    • <ServerName> indicates the server name.
    • <CompanyName> indicates your company name.
    • <City> indicates your city name.
    • <State> indicates your state name.
    • <Country> indicates your country name.
    • <key_password> indicates the password.
    • <server_keystore> indicates keystore name.
    • <store_password> indicates the store password.

    In the above command, Common Name (CN) can be a domain name/DNS Name/machine name or any other name. The CN must match your machine name or hostname. This allows the hostname verification to complete.

    The system generates a private and public key pair.

  6. To create a Certificate Signing Request (CSR), run the following command:
    keytool -certreq -v -alias <alias_name> -file <csr-for-myserver>.pem -keypass <key_password> -storepass <store_password> -keystore <server_keystore>.jks
    Where,
    • <alias_name> indicates the alias that was used during the creation of keystore.
    • <csr-for-myserver> indicates a file name for the CSR file.
    • <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.
    • <server_keystore> indicates the JKS file name that was generated during the keystore creation.

    The system creates the csr-for-myserver.pem file. The file is sent to a Certificate Authority (CA) to create a signed public key certificate.

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, do one of the following:
    • 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>
(Optional) Enter the result of the procedure here.
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 theserver 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
Creating Keystore in the Tomcat Server

This procedure describes the steps to create Keystore in the Tomcat server.

  1. Log in to the IDIH App VM using SSH as an admusr user.
  2. Run the following command to change the directory to conf folder of Tomcat:
    cd /usr/share/tomcat6/conf
  3. Run the the following command to take a backup of the existing jks file:
    cp idih.jks idih-bkp.jks
  4. Run the following command to copy the Keystore that was created for the WebLogic server into the Tomcat configuration folder:
    cp /usr/TKLC/xIH/bea/user_projects/domains/tekelec/nsp/<JKS file created for WebLogic in the previous step> .
sudo chown tomcat:root <JKS file created for WebLogic in the previous step>
Modifying the Tomcat File Configuration

This procedure describes the steps to modify the Tomcat file configuration.

  1. Run the following command to edit the server.xml file and update keystoreFile and keystorePass fields:
    sudo vim server.xml
  2. Modify the following tag in the server.xml file and ensure that the keystoreFile field is updated with the latest jks file name and keystorePass with its corresponding password.
    <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"

               maxThreads="150" scheme="https" secure="true"

               clientAuth="false" sslProtocol="TLS"

               keystoreFile="conf/<JKS file created for WebLogic in the  
               previous step>.jks"

               keystorePass="<Password used during the creation of 
               keystore>" />
  3. Run the following command to restart the Tomcat server:
    sudo service tomcat6 restart

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.