Security Management Guide
Ericsson Service-Aware Policy Controller

Contents

1Security Management Guide Introduction
1.1Security Management Prerequisites
1.2Security Management Environment
1.3Security Management Definitions

2
Security Management Overview
2.1Threats
2.2Defense

3
Product Security Functionality
3.1Network Security Level
3.2Node Security Level
3.3OAM Security Level

4
Security Configuration
4.1Network Security Level
4.2Node Security Level
4.3OAM Security Level

5
Security in the Cloud

6
Default Parameter Values

7
Services, Ports, and Protocols

Reference List

1   Security ManagementGuide Introduction

This instruction describes the security functions available in the SAPC.

Internet Protocol (IP) networks are vulnerable to various types of attacks. Exposure to these threats has increased since IP is used at various parts of the mobile networks. The SAPC provides functions for withstanding and preventing different forms of attacks.

Strong security awareness is a necessity for any product either directly connected to the Internet or indirectly connected (such as, behind a firewall).

For this reason, the information contained in any product must be protected, which is not an exception, in the case of SAPC. The type of subscriber information contained in SAPC to protect comprises:

IP networks are vulnerable to various types of attacks:

Therefore, mobile networks are highly vulnerable since IP protocol is one of the most used protocols in the mobile networks. The number of internet threats exposed to hosts, routers, servers, and other network-connected equipment are overwhelming and constantly growing. As a result, network systems must support security precautions that safeguard the operation, service, and functions of all supported services.

The operator is responsible for implementing and deploying the proper countermeasures in networks to prevent any security intrusion, although the SAPC provides functions for resisting and preventing different forms of attacks.

In case, a security incident happens in a network where the SAPC is deployed, the operator investigates the issue, tracing back the problem to find the root cause of the security breach. If the security incident is related to a flaw in SAPC product, this is communicated timely and diligently.

This document covers the following issues:

Target Groups

This instruction is intended as an introduction to security functions for network operation and network optimizing personnel as well as system engineers and system administrators. It assumes a basic knowledge of telecommunications.

1.1   Security Management Prerequisites

Conditions

Before performing the procedures in Section 4, ensure that the following conditions are met:

1.2   Security Management Environment

The SAPC must be deployed behind a firewall, which offers protection from external attacks. Also, different types of traffic are separated in different VLANs.

1.3   Security Management Definitions

1.3.1   Basic Terms and Concepts

The basic terms and concepts listed are of paramount importance (For further details, refer to https://tools.ietf.org/html/rfc2196).

Availability It is the system ability to withstand a Denial of Service.
Accountability It is the system ability to withstand tampering or manipulation.
Attack It is an action taken against a network system with the intention of doing harm.
Authentication It is the system ability to validate the user identity.
Authorization It is the system ability to validate the user access rights.
Basic Elements The three basic elements to protect in any systems are: software, hardware, and data or information.

Essentially, the most important item to protect is information, since it constitutes one of the major assets of any organization.

Distributed Denial of Service It is a DoS attack using distributed resources over the network.
Denial of Service It is an attempt to make a machine or network resource unavailable to its intended users. It generally consists of efforts to interrupt or suspend services of a host connected to a network.
Reliable System In general, a system is said to be reliable if it satisfies the following properties:
  • Confidentiality: It concerns the protection of system resources from unauthorized disclosure. Preservation of confidentiality is defined as ensuring that resources are accessible only to elements authorized to have access.
  • Integrity: system resources are modified or changed by those elements that have authorization (these operations include creation, deletion, modification, and so on). Preservation of integrity is defined as safeguarding the accuracy and completeness of resources and processing methods.
  • Availability: system resources are always accessible by the authorized elements. It also concerns the safeguarding of necessary resources and associated capabilities. Preservation of availability is defined as ensuring that the authorized elements have access to resources and associated assets when required.
Risk Risk is a combination of the probability of an event and its consequence. Risk is a quantitative concept. Therefore it is possible to estimate the value of the risk: Expected value = estimated loss from risk ($) x likelihood of loss (%)
Secure network A secure network is one that fulfills the following conditions:
  • The traffic keeps passing legitimate customer traffic (availability).
  • Traffic goes where it is supposed to go, and only where it is supposed to go (availability, confidentiality).
  • The Network Elements remain manageable (availability).
  • Only authorized users can manage Network Elements (authentication, authorization).
  • There is a record of all security-related events (accountability).
  • The network operator has the necessary tools to detect and respond to illegitimate traffic.
Threat It is the potential for the occurrence of a harmful event to the network system, such as an attack.
Value The Security concept is associated to another concept from which it gets the sense: value. The SAPC only protects those assets that have an important value for the customer, and therefore, security is intimately associated to the value SAPC provide to the assets.
Vulnerability It is a weakness that makes the network system susceptible of an attack.

1.3.2   Security Pillars

All elements that are implemented in an organization or product must be based on these three pillars:

1.3.2.1   Risk Assessment

This process allows SAPC to detect which security deficiencies have the product and to analyze which would be the best form to protect the product against these risks that have been detected. An analysis of risks provides the organization with reasonable evidences from security point of view. An analysis of risks can be considered a photo of the security inside the organization or the product.

The elements to be considered in the process of risk assessment are the following:

2   Security Management Overview

The security mechanism and functions in the SAPC are designed with the following perspective in mind:

For information about the interfaces supported by the SAPC, refer to Service-Aware Policy Controller.

The SAPC provides two main mechanisms for perimeter defense:

Also, the SAPC provides the following surveillance mechanisms:

2.1   Threats

There are several potential threats to SAPC, but only few of these threats have large risk of occurring and causing damage, such as DoS attack or fraud.

The following are examples of actors that pose a threat:

2.2   Defense

The SAPC Security, based on the perimeter defense principle, provides protection at the following levels:

3   Product Security Functionality

3.1   Network Security Level

The SAPC provides a set of functions securing the communications between the SAPC and the nodes it interacts with. Most network security configuration can be done on each interface.

3.1.1   ICMP Reply

The Internet Control Message Protocol (ICMP) is allowed by default, since it use does not pose any risk and the SAPC is not supposed to be exposed to external networks. However, to prevent the SAPC from being flooded with ICMP messages, other network infrastructure elements (such as firewalls or routers) must be configured.

3.1.2   Traffic Separation

The SAPC provides traffic separation among all the interfaces. The following list depicts the interfaces supported in the SAPC which are not interconnected among them:

The SAPC is connected to several external IP networks through several interfaces. On important aspect, form security point of view is that the SAPC does not route traffic between different interfaces (that is, acting as proxy).

3.1.3   Denial of Service Attacks

DoS attacks can prevent legitimate clients from accessing the SAPC. An attacker floods the system with traffic that blocks the entry for others clients or consumes all available resources. To protect the SAPC from such DoS attacks, configure the firewall / router connected to the SAPC (that isolates the SAPC from the outer network) to limit the request rate which the clients use when connecting to the node.

3.2   Node Security Level

This section describes the node security, or the integrity of the node itself, such as authentication of management operations and prevention of DoS attacks. The SAPC offers the following user management tools from a security perspective:

3.2.1   Ericsson Command-Line Interface

Details on the security features provided by Ericsson Command-Line Interface (ECLI) can be found at Ericsson Command-Line Interface User Guide. Any ECLI session is running securely over SSH protocol.

3.2.2   NETCONF User Management

Details on the security features provided by NETCONF can be found at Security Management for ECLI, NETCONF, and File Transfer Protocols. User authentication and secure NETCONF connection and transport over the Secure Socket Layer (SSL) is provided by the SSH daemon or the Transport Layer Security (TLS) proxy component.

3.3   OAM Security Level

3.3.1   Confidentiality and Integrity Protection of OAM Traffic

Concerning security, the communication between the NBI user and the SAPC is encrypted with SSH.

3.3.2   Node Operator Authentication and Access Control

When logging on to the SAPC, the SAPC makes an authentication check of the username and password. It is possible to log on to the SAPC through either one of the following domains: the Common Management (COM) domain, through the Operating System (LDE) domain, and through the Provisioning (REST) domain.

At initial start of the SAPC, a set of administrators are created in the COM domain. For the administrators and their corresponding roles, see System Administrator Guide. The COM only supports local authentication for the administrators. For more information, see the Local Authentication Management Operating Instructions.

Access control to REST services and LDE file system is provided through COM.

The administrator can manually log off from the system. An inactive user is automatically logged off after a certain time has elapsed.

3.3.3   Logging

The SAPC sends system-important events to syslog.

4   Security Configuration

4.1   Network Security Level

4.1.1   Denial of Service Attack Prevention Configuration

So as to prevent Denial of Service (DoS) attacks, the iptables utility can be used. The iptables utility is a framework available in the SAPC, which allows intercepting and manipulating packets. Additionally, not only does iptables filter packets but also it logs any action on the packets handled.

Configuration of iptables utility is described in LDE Management Guide.

4.2   Node Security Level

4.2.1   Ericsson Command-Line Interface

Details on how to facilitate the encryption of OAM protocols with TLS can be found at Security Management for ECLI, NETCONF, and File Transfer Protocols.

4.2.2   NETCONF User Management

For how to manage security in the NETCONF domain, see Security Management for ECLI, NETCONF, and File Transfer Protocols.

Sapcadmin with the SuperUser role is able to create new administrators belonging to the SapcSystemReadOnly or SapcProvisioningAdministrator role listed in System Administrator Guide. For how to manage users, see User Management.

4.2.3   Linux User Management

Root is only an LDE administrator in the SAPC. The sapcadmin can access to the Linux Domain by SSH.

4.2.3.1   Administrator Password Expiration Policy

The password expiration policy in Linux can be configured with the change command.

For example, to force a user to change their password every 30 days warning the needed change 10 days before, the following command can be used:

chage <account> --mindays 0 --maxdays 30 --expiredate -1 --warndays 10

The default password validity of SAPC administrator is infinite days, with password change reminder 10 days before password expiration. The recommended value for the password expiration policy is 30 days.

4.2.3.2   Idle Session Time-out

The idle time-out for any Linux session can be set through editing the /etc/profile file and adding the following lines:

The recommended value for the idle session time-out is 5 minutes.

To enable the inactivity timer for logon through the SSH interface, edit the /etc/ssh/sshd_config file on both SC-1 and SC-2 and add the following text:

ClientAliveInterval 1800
ClientAliveCountMax 0

15 minutes is the recommended value.

4.2.3.3   Maximum Number of Failed Logon Attempts

The Maximum Number of Failed logon Attempts for any Linux session can be set through editing the /etc/ssh/sshd_config file in both SC and adding the following lines:

MaxAuthTries 3

The maximum number of failed logon attempts has been set to 3.

The recommended maximum number of failed logon attempts is 3.

4.2.3.4   Password Strength Policy

The password strength policy can be changed by editing the /etc/pam.d/login file and adding (if not existing) the following line as required according to the policy rules:

password requisite pam_cracklib.so difok=3 maxrepeat=3 retry=3 minlen=8 lcredit=-1 ucredit=-1 dcredit=-1 ocredit=-1 reject_username

The recommendation is that the password contains at least one character of the following groups: alpha lower characters, alpha upper characters, numeric characters, punctuation characters (that is, ‘?*’).

Refer to the following documentation for more information on the options available: /usr/share/doc/packages/pam/README.cracklib , /usr/share/doc/packages/pam/modules/README.pam_cracklib.

4.2.3.5   Lockout Period

The lockout period for any administrator account can be set by editing the /etc/pam.d/common-password file and adding the following text at the beginning of the auth section in the pam file:

auth required pam_tally2.so file=/var/log/tallylog deny=3 even_deny_root unlock_time=1200

This locks the root account for 60 seconds and anyone else is locked for 1200 seconds.

The recommended value for the lockout period is 1800 seconds.

4.2.3.6   Emergency Access

Local Linux users belonging to the com-emergency Linux group can authenticate locally and get complete Management Information Base (MIB) access through the ECLI and NETCONF interfaces.

To configure a new emergency user, the following procedure is followed in the Linux environment:

  1. Log on to one of the system controllers as root: ssh -l <user> <address>.
  2. Add an emergency account: useradd -G com-emergency <emergency_user> --home-dir <home_directory>
  3. Assign an initial password for the newly created emergency user: passwd <emergency_user>. The system prompts the user to enter a password.
  4. Enter a password. The system prompts the user to repeat the selected password.
  5. Enter the password again.
  6. Allow the user account to log on to all nodes in the cluster by editing the login.allow file. Add <emergency_user> to the /cluster/etc/login.allow file.
  7. Check logon permissions for the emergency user: cat /cluster/etc/login.allow. The login.allow file now also includes the following row: <emergency-user> all
  8. Add the user globally to the cluster: lde-global-user --user <emergency_user>
  9. Verify that this emergency user works by logging on to the system controller through SSH and through the Northbound Interface (NBI).

4.2.4   Node Log On

When an operator (administrator) attempts to log on to SAPC, the node by default verifies the operator username and password (Individual authentication of OAM accesses). Username and password must be configured by a system administrator. For instruction on configuring username and password, refer to System Administrator Guide.

Configure strong passwords for accessing the SAPC product. Strong passwords are eight or more characters long and consist of a series of upper and lower case letters, numbers, punctuation marks, and special characters. These recommendations are summarized in the following list:

Note:  
Change the root password immediately after installation of the SAPC.

4.2.4.1   Disabling remote SSH root logon

Remote logon for the root user is enabled by default. Remote logon for the root user can be disabled:

  1. Replace the line ssh.rootlogin control on with ssh.rootlogin all off in cluster.conf.
  2. Reload the configuration on both SC-1 and SC-2: cluster config -r -a

4.2.4.2   Enabling remote SSH root logon

If remote logon for the root user has been disabled, remote logon for the root user can be enabled:

  1. Connect to either SC-1 or SC-2 (console logon).
  2. Replace the line ssh.rootlogin all off with ssh.rootlogin control on in cluster.conf.
  3. Reload the configuration on both SC-1 and SC-2: cluster config -r -a

4.2.5   Cipher List

The default cipher list configured at startup, which can be found in the ManagedElement > SystemFunctions > SecM > Tls Managed Object, is the following:

cipherFilter="kEECDH:kEDH:kRSA:!kPSK:!aPSK:!aDSS:!aNULL:!NULL:!SEED:!3DES:!MD5:!RC4:!CAMELLIA:!SSLv3"

This cipher list may be changed according to customer needs, i.e., in order to harden any SAPC communication using TLS.

4.3   OAM Security Level

4.3.1   Logging

Full personal accountability entails the ability to log watch OAM actions are taken by users logged in to the system. This is accomplished through enabling the Linux auditing framework.

The pam configuration files /etc/pam.d/common-session-lde (symlinked from /etc/pam.d/common-session) are modified to add the following line:

 session required pam_tty_audit.so enable=*

The common audit dispatch daemon configuration file /etc/audisp/plugins.d/syslog.conf is modified to contain the following:

active = yes

direction = out

path = builtin_syslog

type = builtin

args = LOG_INFO LOG_LOCAL0

format = string

Sending the audit logs to syslog local facility 0.

Also, on SLES, the audit daemon configuration file /etc/audit/audit.rules is filled with the following content:

# First rule - delete all

-D

# Increase the buffers to survive stress events.

# Make this bigger for busy systems

-b 320

# Feel free to add below this line. See auditctl man page

-e 1

Which enables the audit daemon.

When logs are written to the syslog, each line typically receives a header consisting of the time stamp and the issuing host/machine that sent the log. To read this logs with aureport for further investigation, one has to remove this header. Recommended way to do this is using sed:

$ sed 's/^.*audispd: //' /path/to/log_file > outputfile

$ aureport --tty -i outputfile

4.3.2   Certificates Management

The configuration of the certificate to use in a secure communication involving the HTTPS protocol, such as in REST interface, is described in Certificate Management. This document provides instructions on how to install and update any Server Certificate or any Client Certificate.

For security reasons, both Server and Client certificates should be updated regularly. A self-signed certificate can be used but intended only for demonstrations or testing environments. Do not use this certificate in a production environment. It is recommended to use a certificate obtained from an external trusted Certification Authority.

There are two ways of generating or installing a self-signed signed certificate:

Additionally, the operator has the opportunity to generate and install a self-signed certificate in one step, as described in Section 4.3.2.5.

4.3.2.1   Manual Generation of a self-signed certificate

A self-signed certificate can be generated by the sapcadmin administrator:

  1. Generate an RSA private key: openssl genrsa -out <Key Filename> <Key Size>

    Where:

    • <Key Filename> is the desired filename for the private key file
    • <Key Size> is the desired key length of either 1024, 2048, or 4096

    For example: openssl genrsa -out my_key.key 2048

  2. Generate a Certificate Signing Request: openssl req -new -key <Key Filename> -out <Request Filename> -config <config.cnf>

    Where:

    • <Key Filename> is the input filename of the previously generated private key
    • <Request Filename> is the output filename of the certificate signing request
    • <config.cnf> is a file containing the following information:

      [req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
[req_distinguished_name]
countryName = Country Name (2 letter code)
countryName_default = ES
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Spain
localityName = Locality Name (eg, city)
localityName_default = Madrid
organizationalUnitName    = Organizational Unit Name (eg, section)
organizationalUnitName_default    = Ericsson
commonName = <SAPC_VIPP_FQDN> or <SAPC_VIPP_Adress> or <SAPC_VIPO_FQDN> or <SAPC_VIPO_Address>
commonName_max    = 64
[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
[alt_names]
IP.1 = <SAPC_VIPP_Address> or <SAPC_VIPO_Address>

    The following list gives an overview of the fields used in the config.cnf file.

    • countryName: This field contains the two-code country code defined in ISO 3166.
    • stateOrProvinceName: This field contains the state or province name of the organization which this certificate has been issued to.
    • localityName: This field contains the city of the organization which this certificate has been issued to.
    • organizationalUnitName: This field contains the organization which this certificate has been issued to.
    • basicContraints: The basic constraints extension identifies whether the subject of the certificate is a Certification Authority (CA) and how deep a certification path may exist through that CA. For the generation of the self-signed certificate, this field is set to FALSE.
    • The values to use in the keyUsage field are: digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyAgreement, keyCertSing, cRLSign, encipherOnly, decipherOnly. Depending on the usage of the certificate, the specific value should be used. For the generation of the self-signed certificate, which is aimed to provide encryption to the SAPC clients, the nonRepudiation, digitalSignature and KeyEncipherment should be used.
    • subjectAltName The subject alternative name extension allows additional identities to be bound to the subject of the certificate (alternative IP Addresses, DNS, and so on). Whenever any additional identity is to be bound into a certificate, the subject alternative name extension must be used. If the subject field contains an empty sequence, the subjAltName must contain a valid subjectAltName. When the alt name is the only identity used, then the subjAltName must be present and the Subject Name must be left empty.
    Note:  
    subjectAtName field is optional. It should be included if additional identifies needs including in the certificate.

    For example: >openssl req -new -key my_key.key -out my_request.csr -config config.cnf

  3. Follow the on-screen prompts for the required certificate request information. It is recommended to use a Fully Qualified Domain Name (FQDN) in the CN field of the certificate, or alternatively using an IP address in the altName field of the certificate.
  4. Create a v3.ext file containing the following information:

    subjectAltName = @alt_names
      [alt_names]
      IP.1 = <SAPC OAM VIP Address>

    Note:  
    Optional file if FQDN is provided, but mandatory in other case.

  5. Generate a self-signed public certificate (X509 v3) based on the request: openssl x509 -req -days 3650 -in <Request Filename> -signkey <Key Filename> -out <Certificate Filename> -extfile <v3_ext Filename>

    Where:

    • <Request Filename> is the input filename of the certificate signing request
    • <Key Filename> is the input filename of the previously generated private key
    • <Certificate Filename> is the output filename of the public certificate
    • <v3_ext Filename> is the filename of the file generated at previous step.>
      Note:  
      The -extfile v3.ext option is mandatory if the SAPC FQDN has not been provided, but optional in any other case.

    For example: openssl x509 -req -days 3650 -in my_request.csr -signkey my_key.key -out my_cert.crt -extfile v3.ext

  6. Generate a PKCS#12 file: openssl pkcs12 -keypbe PBE-SHA1-3DES -certpbe PBE-SHA1-3DES -export -in <Public Certificate Filename> -inkey <Private Key Filename> -out <PKCS#12 Filename> -name "<Display Name>"

    Where:

    • <Public Certificate Filename> is the input filename of the public certificate, in PEM format
    • <Private Key Filename> is the input filename of the private key
    • <PKCS#12 Filename> is the output filename of the pkcs#12 format file
    • <Display Name> is the desired name that will sometimes be displayed in User Interfaces.

    For example: openssl pkcs12 -keypbe PBE-SHA1-3DES -certpbe PBE-SHA1-3DES -export -in my_cert.crt -inkey my_key.key -out my_pkcs12.p12 -name "SAPC API"

An example of a self-signed certificate can be found at the following path:

/cluster/storage/system/software/coremw/repository/ERIC-SAPC_RestServer-CXP9032712_7-R2C53/sapc-demo.p12

This self-signed certificate is provided as reference, but it cannot be used at production since the certificate was generated using an internal IP of the SAPC cluster as Domain Name (DN).

4.3.2.2   Automatic generation of a self-signed certificate

The SAPC provides an easy way to create a simple self-signed certificate that may be used in most of scenarios. The sapcadmin administrator can automatically generate the self-signed certificate running the sapcRestCertificate script in any of the SCs.

The IP(s) and the DNS can be added to the generated self-signed Certificate depending on the URL used by the client when connecting to the SAPC.

If the URL used for connecting to the SAPC is similar to the following pattern:

https://135.203.12.35:8443/provisioning/v1

Then the self-signed certificate must be generated using the following command:

sapcRestCertificate simple-cert certname -i 135.203.12.35

if the URL used for connecting to the SAPC is similar to the following pattern:

https://sapc.internal.com:8443/provisioning/v1

Then the self-signed certificate must be generated using the following command:

sapcRestCertificate simple-cert certname -d sapc.internal.com

Where:

At least one IP or one DNS must be specified. Multiple IP(s) and DNS can be specified at the same time using a comma separate list. For instance, sapcRestCertificate simple-cert certname -d sapc.internal.com,policyserver.local.com -i 135.203.12.35,120.77.56.33

Further details about the supported options of the sapcRestCertificate script can be obtained using the -h option: sapcRestCertificate -h

An example of the output of the command is shown:

sapcadmin@SC-1:~> sapcRestCertificate simple-cert my-cert -d sapc.internal.com
# Creating self-signing key
Generating RSA private key, 2048 bit long modulus
.......+++
.................................................................................+++
e is 65537 (0x10001)

# Creating certificate
Signature ok
subject=/C=SE/ST=SAPC-Demo-State/L=SAPC-Demo-City/OU=SAPC-Demo-Section/CN=sapc.internal-com
Getting Private key

# Sign the certificate
Enter Import Password:
Verifying - Enter Import Password:

# Certificate created with files
my-cert.crt
my-cert.p12

# Extract the fingerprint
SHA224(my-cert.p12)=
10:20:03:47:34:ec:f6:5a:3f:0d:1c:38:68:13:15:3f:d1:31:7f:6b:ad:38:5d:50:9a:14:d7:be

4.3.2.3   Manual Installation of a self-signed certificate

A self-signed certificate or a certificate obtained from a Trusted Certification Authority can be installed by the sapcadmin administrator:

  1. Stop the SAPC REST process:
    • Log on to SC-1 as SAPC administrator and execute the command:
      sapcadmin@SC-1:~> sapcRestServer stop
    Note:  
    The sapcRestServer script will log on in to every PL requesting the sapcadmin password at every PL.

  2. Delete the current Node Credential for sapc-rest-server, as described in Delete Node Credential.
    Note:  
    Only if a previous certificate has been generated and installed.

  3. Create a Node Credential for sapc-rest-server, as described in Install or Renew Node Credential by PKCS 12. The value for the new NodeCredential MO has to be NodeCredential=sapc-rest-server.
  4. Start the SAPC REST process:
    • Exit from the ECLI (but maintaining the connection with the SC).
    • Execute the command:
      sapcadmin@SC-1:~> sapcRestServer start
    Note:  
    The sapcRestServer script will log on in to every PL requesting the sapcadmin password at every PL.

Once the certificate is installed, the attribute certificateContent of the NodeCredentialMO contains the X.509 content of the certificate (public key of the certificate), which can be exported to any other client for trusting purposes.

4.3.2.4   Automatic installation of a self-signed certificate

Once, the self-signed certificate has been generated, the sapcadmin administrator can automatically install the self-signed certificate running the sapcRestCertificate script in any of the SCs:

sapcRestCertificate install my-cert.p12

Where my-cert.p12 is the name of the file containing the self-signed certificate, and it can be substituted by the actual name of the generated self-signed certificate.

The following text shows an example of the command output:

sapcadmin@SC-1:~> sapcRestCertificate install my-cert.p12
A certificate already exists in the Sapc Provision Server.
If the command continues, the existing certificate will be overwritten continue? [y/N] y
Enter Import Password:
Verifying - Enter Import Password:
Stopping RestServer in PL-3 ...
Stopping RestServer in PL-4 ...
/usr/local/bin/sapcRestServer action -stop- finished.
Starting RestServer in PL-3 ...
Starting RestServer in PL-4 ...
/usr/local/bin/sapcRestServer action -start- finished.
SUCCESS: installed from the container file

4.3.2.5   Automatic generation and installation of a self-signed certificate

Automatic generation and installation of a self-signed certificate can be done at the same time using the following command:

sapcRestCertificate simple-cert certname -d sapc.internal.com -I

or

sapcRestCertificate simple-cert certname -i 135.203.12.35 -I

The following text shows an example of the command output:

sapcadmin@SC-1:~> sapcRestCertificate simple-cert my-cert -d sapc.internal.com -I
# Creating self-signing key
Generating RSA private key, 2048 bit long modulus
..................+++
...............................................................................+++
e is 65537 (0x10001)

# Creating certificate
Signature ok
subject=/C=SE/ST=SAPC-Demo-State/L=SAPC-Demo-City/OU=SAPC-Demo-Section/CN=sapc.internal-com
Getting Private key

# Sign the certificate
Enter Import Password:
Verifying - Enter Import Password:

# Certificate created with files
my-cert.crt
my-cert.p12
# Extract the fingerprint
SHA224(my-cert.p12)=
63:98:37:d4:0d:41:4d:db:25:c2:9e:5a:38:3e:93:fe:3b:60:3c:c7:d9:15:e4:ca:e2:56:1a:f3

# Install the certificate
Stopping RestServer in PL-3 ...
Stopping RestServer in PL-4 ...
/usr/local/bin/sapcRestServer action -stop- finished.

Starting RestServer in PL-3 ...
Starting RestServer in PL-4 ...
/usr/local/bin/sapcRestServer action -start- finished.
SUCCESS: installed from the container file

4.3.3   Recommended Periodic Operations

The following activities are recommended to be done regularly (weekly or monthly):

4.3.4   Handling of Patches

Patches to security vulnerabilities and alerts are delivered in the form of Correction Packages (CP) or Emergency Packages (EP).

5   Security in the Cloud

The Virtual SAPC is only deployed in trusted clouds to protect security information contained in it and to avoid information leakage to non-authorized third parties.

The following requirements are applicable when deploying the SAPC in the Cloud:

6   Default Parameter Values

The default values for the security parameters are listed in the following table:

Table 1    Parameters and Default Values

Parameter

Default Value

Minimum Password Age

0

Maximum Password Age

99999

Password Expiration Warning

7

Password Inactive

-1

TMOUT

0

ClientAliveInterval

0

ClientAliveCountMax

3

MaxAuthTries

6

7   Services, Ports, and Protocols

Keep the number of open ports in the SAPC to the minimal necessary for the node to be operational.


Reference List

Ericsson Documents
[1] Ericsson Command-Line Interface User Guide.
[2] LDE Management Guide.
[3] Logging Events.
[4] Measurements.
[5] Security Management for ECLI, NETCONF, and File Transfer ProtocolsEricsson Command-Line Interface User Guide.
[6] Service-Aware Policy Controller.
[7] System Administrator Guide.
[8] User Management.
Legal | © Ericsson España, S