OM Security (SRAN10.1 02)

SingleRAN
OM Security Feature Parameter

Description
Issue 02
Date 2015-05-15
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2015. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or representations
of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Issue 02 (2015-05-15) Huawei Proprietary and Confidential i

Copyright © Huawei Technologies Co., Ltd.
SingleRAN
OM Security Feature Parameter Description Contents
Contents
1 About This Document..................................................................................................................1

1.1 Scope..............................................................................................................................................................................1
1.2 Intended Audience..........................................................................................................................................................2
1.3 Change History...............................................................................................................................................................2
1.4 Differences Between Base Station Types.......................................................................................................................4
2 Overview.........................................................................................................................................5
3 Technical Description...................................................................................................................7
3.1 OMCH Security..............................................................................................................................................................7
3.1.1 SSL-Encrypted Transmission......................................................................................................................................7
3.1.2 Management Plane IP Address Isolation.....................................................................................................................8
3.2 Web Security..................................................................................................................................................................8
3.2.1 Overview.....................................................................................................................................................................8
3.2.2 User Authentication.....................................................................................................................................................9
3.2.3 HTTPS-based Data Transmission.............................................................................................................................10
3.2.4 Anti-attack.................................................................................................................................................................11
3.2.5 Rights Control............................................................................................................................................................11
3.3 User Management.........................................................................................................................................................12
3.3.1 Overview...................................................................................................................................................................12
3.3.2 Login Authentication.................................................................................................................................................13
3.3.3 User Rights Control...................................................................................................................................................15
3.3.4 Login Password Policy..............................................................................................................................................17
3.3.5 Simultaneous Online User Number Management.....................................................................................................21
3.3.6 Southbound Interface Access Management...............................................................................................................22
3.3.7 FTP User Management..............................................................................................................................................23
3.4 Sensitive Personal Data Security..................................................................................................................................23
3.4.1 User Data Anonymization.........................................................................................................................................24
3.4.2 Sensitive Personal Data Protection............................................................................................................................24
3.5 Security Management of Configuration Files..............................................................................................................24
3.5.1 Overview...................................................................................................................................................................24
3.5.2 Application Scenario.................................................................................................................................................24
3.5.3 Configuration File Encryption...................................................................................................................................25
3.6 Digital Signature-based Software Integrity Protection.................................................................................................25
Issue 02 (2015-05-15) Huawei Proprietary and Confidential ii

SingleRAN
OM Security Feature Parameter Description Contents
3.6.1 Definition...................................................................................................................................................................25
3.6.2 Application Scenarios................................................................................................................................................25
3.6.3 Digital Signature........................................................................................................................................................26
3.7 Time Security...............................................................................................................................................................29
3.7.1 SNTP Security for the Base Station Controller/eCoordinator...................................................................................29
3.7.2 NTP Security Authentication for the Base Station....................................................................................................29
3.8 Security Alarms, Events, and Logs..............................................................................................................................30
3.8.1 Overview...................................................................................................................................................................30
3.8.2 Security Alarms and Events......................................................................................................................................30
3.8.3 Security Logs and Security Audit..............................................................................................................................31
3.9 OMU Anti-attack..........................................................................................................................................................36
3.10 Security Policy Level Configuration..........................................................................................................................37
4 Engineering Guidelines.............................................................................................................40
4.1 OMCH Security............................................................................................................................................................40
4.2 Web Security................................................................................................................................................................40
4.2.1 When to Use Web Security.......................................................................................................................................40
4.2.2 Deployment...............................................................................................................................................................40
4.3 User Management.........................................................................................................................................................42
4.3.1 When to Use User Management................................................................................................................................42
4.3.2 Deployment...............................................................................................................................................................42
4.4 User Data Anonymization............................................................................................................................................44
4.5 Security Management of Configuration Files..............................................................................................................44
4.5.1 When to Use Security Management of Configuration Files......................................................................................44
4.5.2 Deployment...............................................................................................................................................................44
4.6 Digital Signature-based Software Integrity Protection.................................................................................................45
4.7 Time Security...............................................................................................................................................................46
4.7.1 When to Use Time Security.......................................................................................................................................46
4.7.2 Deployment of SNTP Security for the Base Station Controller/eCoordinator..........................................................46
4.7.3 Deployment of NTP Security Authentication for the Base Station...........................................................................46
4.8 Security Alarms, Events, and Logs..............................................................................................................................50
4.9 OMU Anti-attack..........................................................................................................................................................50
4.9.1 When to Use OMU Anti-Attack................................................................................................................................50
4.9.2 Required Information................................................................................................................................................50
4.9.3 Deployment...............................................................................................................................................................50
4.10 Security Policy Level Configuration..........................................................................................................................52
5 Parameters.....................................................................................................................................53
6 Counters........................................................................................................................................62
7 Glossary.........................................................................................................................................63
8 Reference Documents.................................................................................................................64
Issue 02 (2015-05-15) Huawei Proprietary and Confidential iii

SingleRAN
OM Security Feature Parameter Description 1 About This Document
1 About This Document
1.1 Scope
This document describes operation and maintenance (O&M) security, including its technical
descriptions, engineering guidelines, and parameters.
This document covers the following features:
l MRFD-210305 Security Management

l LBFD-004010 Security Management
l TDLBFD-004010 Security Management
Table 1-1 defines all types of base stations.
Table 1-1 Base station definition
Base Station Name Definition
GBTS GBTS refers to a base station deployed with GTMU and

maintained through a base station controller.
eGBTS eGBTS refers to a base station deployed with GTMUb, UMPT_G,

or UMDU_G and directly maintained by the element management
system (EMS).
NodeB NodeB refers to a base station deployed with WMPT, UMPT_U

or UMDU_U.
eNodeB eNodeB refers to a base station deployed with LMPT, UMPT_L,

UMPT_T, UMDU_L, or UMDU_T.
Issue 02 (2015-05-15) Huawei Proprietary and Confidential 1

SingleRAN
Base Station Name Definition
Co-MPT multimode Co-MPT multimode base station refers to a base station deployed
base station with UMPT_GU, UMDU_GU, UMPT_GL, UMDU_GL,
UMPT_GT, UMDU_GT, UMPT_UL, UMDU_UL, UMPT_UT,
UMDU_UT, UMPT_LT, UMDU_LT, UMPT_GUL,
UMDU_GUL, UMPT_GUT, UMDU_GUT, UMPT_ULT,
UMDU_ULT, UMPT_GLT, UMDU_GLT, UMPT_GULT, or
UMDU_GULT, and it functionally corresponds to any
combination of eGBTS, NodeB, and eNodeB. For example, Co-
MPT multimode base station deployed with UMPT_GU
functionally corresponds to the combination of eGBTS and
NodeB.
Separate-MPT Separate-MPT multimode base station refers to a base station on

multimode base station which different modes use different main control boards. For
example, base stations deployed with GTMU and WMPT are
called separate-MPT GSM/UMTS dual-mode base station.
NOTE
A UMDU cannot be used in a separate-MPT base station.
Unless otherwise specified, the descriptions and examples for the UMPT in a co-MPT base
station are applicable to the UMDU in a co-MPT base station.
1.2 Intended Audience

This document is intended for personnel who:
l Need to understand the features described herein

l Work with Huawei products
1.3 Change History

This section provides information about the changes in different document versions. There are
two types of changes:
l Feature change
Changes in features and parameters of a specified version as well as the affected entities
l Editorial change
Changes in wording or addition of information that was not described in the earlier version
SRAN10.1 02 (2015-05-15)
This issue includes the following changes.

SingleRAN
Change Change Description Parameter Change

Type
Feature Added the description of management plane IP Added the parameter

change address isolation. For details, see 3.1.2 GTRANSPARA.ONL
Management Plane IP Address Isolation. YOMIP.
Editorial None None

change
SRAN10.1 01 (2015-03-23)
This is the first official release. This issue does not include any changes.
SRAN10.1 Draft A (2015-01-15)

Compared with Issue 03 (2014-07-25) of SRAN9.0, Draft A (2015-01-15) of SRAN10.1
includes the following changes.

Type
Feature Added the user local login alarm on the base None
change station. For details, see 3.3.2 Login
Authentication.
Added descriptions about the eCoordinator. None
Enhanced user login security. For details, see None

3.3.2 Login Authentication and 3.10 Security
Policy Level Configuration.
Deleted the LST AUTHPOLICY and SET
AUTHPOLICY MML commonds.
Added the management function on the number None

of simultaneous online users. For details, see 3.3.5
Simultaneous Online User Number
Management.
Added the protection of sensitive personal data. None

For details, see 3.4.2 Sensitive Personal Data
Protection.
Editorial Incorporated the descriptions about O&M None

change security in ECO6910 Equipment and O&M
Security Feature Parameter Description.
Optimized descriptions about user rights control. None

For details, see 3.3.3 User Rights Control.

SingleRAN

Type
Optimized descriptions about southbound None

interface access management. For details, see
3.3.6 Southbound Interface Access
Management.
1.4 Differences Between Base Station Types

Definition
The macro base stations described in this document refer to 3900 series base stations. These
base stations work in GSM, UMTS, or LTE mode, as listed in the section Scope.
The LampSite base stations described in this document refer to distributed base stations that
provide indoor coverage. These base stations work in UMTS or LTE mode but not in GSM
mode.
The micro base stations described in this document refer to all integrated entities that work in
UMTS or LTE mode but not in GSM mode. Descriptions of boards, cabinets, subracks, slots,
and RRUs do not apply to micro base stations.
The following table defines the types of micro base stations.
Base Station Model RAT
BTS3902E UMTS
BTS3202E LTE FDD
NOTE
The co-MPT and separate-MPT applications are irrelevant to single-mode micro base stations.
The BTS3902E does not support any new and enhanced features or functions in SRAN10.1. For
details, see 1.3 Change History.
Feature Support by Macro, Micro, and LampSite Base Stations

None
Function Implementation in Macro, Micro, and LampSite Base Stations

None

SingleRAN
OM Security Feature Parameter Description 2 Overview
2 Overview
Table 2-1 lists the O&M security measures supported by Huawei network elements (NEs) in
SRAN9.0.
Table 2-1 Supported security measures
Security Measures MBSC eCoord eGBTS NodeB eNode MBT

inator B S
Operation and √ √ √ √ √ √
maintenance channel
(OMCH) security
Web security √ √ √ √ √ √
User management √ √ √ √ √ √
User data anonymization √ √ √ √ √ √
Digital signature-based √ √ √ √ √ √
software integrity
protection
Time security √ √ √ √ √ √
Security alarms, events, √ √ √ √ √ √

and logs
OMU anti-attack √ √ - - - -
Security policy level √ √ x √ √ √

configuration
NOTE
√ indicates that the NE supports this security measure.
x indicates that the NE does not support this security measure.
- indicates that the NE does not involve this security measure.

SingleRAN
OM Security Feature Parameter Description 2 Overview
NOTE
In this document, MBSC is called the base station controller, and eGBTS, NodeB, eNodeB and MBTS are
collectively referred to as the base station. For details about O&M security measures for the GBTS, see
GBTS Equipment and OM Security Feature Parameter Description.

SingleRAN
OM Security Feature Parameter Description 3 Technical Description
3 Technical Description
3.1 OMCH Security
3.1.1 SSL-Encrypted Transmission

An OMCH is configured between a base station (other than a GBTS), base station controller,
or eCoordinator and the U2000 or WebLMT to transmit information for base station management
and maintenance.
Data transmitted over OMCHs is secured using Secure Sockets Layer (SSL).
SSL is a cryptographic protocol designed to secure communication over the Internet. SSL at the
transport layer supports only TCP. As shown in Figure 3-1, SSL works between the transport
layer and the application layer. It secures data transmission for various application protocols,
such as Hypertext Transfer Protocol (HTTP) and File Transfer Protocol (FTP).
Figure 3-1 SSL-encrypted transmission
SSL protects transmitted data against eavesdropping, tampering, and forging using encryption,
integrity protection, and identity authentication.
l Encryption

SingleRAN
With SSL, the sender encrypts data at the application layer before transmission and the
receiver decrypts the received data. In this manner, data is transmitted as ciphertext,
preventing eavesdropping.
SSL supports multiple standard encryption algorithms, such as Triple Data Encryption
Standard (3DES), Advanced Encryption Standard (AES), and Rivest Cipher 4 (RC4).
l Integrity protection
SSL uses the Hash function to generate a digital signature for the data to be transmitted.
The receiver then checks the digital signature to determine whether the data was tampered
with during transmission.
SSL supports multiple standard Hash algorithms, such as Secure Hash Algorithm 1
(SHA-1).
l Identity authentication
SSL supports certificate-based authentication. The communicating parties authenticate the
digital certificates of each other before establishing an SSL connection.
Huawei equipment supports SSL versions SSL3.0, TLS1.0, TLS1.1, and TLS1.2. The SSL
version to be used can be negotiated with the peer party. The SSL version used is always TLS1.2
in SRAN8.0 or later and TLS1.1 in SRAN7.0 or earlier. During SSL negotiation, NEs choose a
supported SSL version from the list provided by the U2000.
For details about SSL, see SSL Feature Parameter Description.
The FTP connection between the base station controller, eCoordinator, or base station and the
U2000 is based on SSL. FTP files on the U2000 can be encrypted using SSL and then transmitted
in ciphertext format. For details about SSL application to FTP, see SSL Feature Parameter
Description.
NOTE
Currently, SSL 2.0 cannot be used. In addition, encryption and plaintext algorithms whose lengths are
shorter than 64 bits cannot be used.
3.1.2 Management Plane IP Address Isolation

This function isolates the control plane IP address from the management plane IP address,
preventing users from performing unauthorized operations using the control plane IP address.
You can run the SET OMCONNPOLICY command to enable this function. If the
GTRANSPARA.ONLYOMIP parameter is set to ENABLE(Enable) and the management
plane IP address is configured, the OMCH between the U2000 and the base station must be
established using the management plane IP address.
3.2 Web Security
3.2.1 Overview
A user can access the base station controller, eCoordinator, or base station to perform O&M
with a WebLMT. The WebLMT is an HTTP/HTTPS-based web application that takes the
following measures to ensure O&M security:
l User authentication

SingleRAN
l HTTPS-based Data Transmission

l Anti-attack
l Rights control
3.2.2 User Authentication

To log in to the WebLMT, a user must input the correct user name and password.
Users are classified as local users and domain users.
Local User
Information of local users is stored and authenticated on the base station controller and the
eCoordinator.
The password policies for local users are as follows:
l The minimum password length is specified by PWDPOLICY.PwdMinLen

(BSC6900,BSC6910).
l The password complexity is specified by PWDPOLICY.Complicacy
(BSC6900,BSC6910).
l The maximum number of single character repetitions is specified by
PWDPOLICY.MaxRepeatCharTimes(BSC6900,BSC6910).
l The period in which a password remains valid is specified by
PWDPOLICY.MAXVALIDDATES(BSC6900,BSC6910).
l The maximum number of login retries is specified by PWDPOLICY.MaxMissTimes
(BSC6900,BSC6910).
l The warning before the password expires (days) is specified by
PWDPOLICY.MAXPROMPTDATES(BSC6900,BSC6910).
l Users can change their passwords.
l The maximum number of previously used passwords recorded is specified
PWDPOLICY.HISTORYPWDNUM(BSC6900,BSC6910). Users cannot reuse
previously used passwords.
l If PWDPOLICY.FirstLoginMustModPWD(BSC6900,BSC6910) is set to ON(Open),
users are required to change their passwords when they log in to the WebLMT for the first
time.
l If PWDPOLICY.DICTCHKSW(BSC6900,BSC6910) is set to ON(Open), users cannot
use the passwords in the weak password dictionary.
Password security-related parameters can be configured by the security administrator and

accounts that have permission to configure PWDPOLICY.
Domain User
Domain users are managed by the U2000. User information is stored and authenticated on the
U2000.
The authentication module uses a brute-force cracking prevention mechanism to authenticate

users attempting to log in to the WebLMT.

SingleRAN
l A user must input a verification code after inputting the user name and password. The
verification code is an image randomly generated by the web server.
l If a user fails to log in to the WebLMT after several consecutive attempts, the account will
be locked and then automatically unlocked after a certain period of time. The
PWDPOLICY.MaxMissTimes(BSC6900,BSC6910,NodeB) parameter specifies the
maximum number of login attempts allowed and the PWDPOLICY.AutoUnlockTime
(BSC6900,BSC6910,NodeB) parameter specifies the duration for which the account is
locked. The two parameters can be configured. If no operation is performed within a
specified period of time, the WebLMT GUI will be automatically locked. GUI unlock
authentication is implemented on the base station controller. If the user cannot unlock the
GUI after multiple attempts, the current session will be locked for another 30 minutes.
3.2.3 HTTPS-based Data Transmission

The policy for logging in to the WebLMT is specified by the policy parameter in the SET
WEBLOGINPOLICY command. By default, the WebLMT uses HTTPS to secure data
transmission. A digital certificate is required to use HTTPS. The WebLMT uses a digital
certificate delivered with itself.
Table 3-1 WebLMT login policy
Scenario Protocol Used Protocol Used Protocol Used Policy

in the Internet in Login Web in the Description
Explorer Page WebLMT
Address Box GUI
Scenario 1 HTTP HTTPS HTTPS Forcible

HTTPS:
Scenario 2 HTTPS HTTPS HTTPS HTTPS
connection must
be used for the
login web page
and the
WebLMT GUI.
Scenario 3 HTTP HTTPS HTTP HTTPS for

login only:
Scenario 4 HTTPS HTTPS HTTP HTTPS
connection must
be used for the
login web page.
Scenario 5 HTTP HTTP HTTP Compatibility

mode: Either
Scenario 6 HTTPS HTTPS HTTPS HTTP or
HTTPS is used.

SingleRAN
NOTE
As of SRAN8.0, the default policy for logging in to the WebLMT changed from compatibility mode to
forcible HTTPS mode.
In compatibility mode, the policy for logging in to the WebLMT is determined by the protocol (HTTP or
HTTPS) entered in the Internet Explorer address box.
3.2.4 Anti-attack
The web server has been reinforced to prevent the impacts of various attacks. The following
types of attacks have been taken into consideration before delivery:
l Cross-site scripting attack

Attackers inject malicious scripts into web pages. If the web server does not filter out the
malicious scripts, the scripts will be executed when users view the web pages.
l Remote file inclusion attack
Attackers forcibly include their own files in the codes on the web server by exploiting the
Web server's vulnerability in filtering file inclusion. By doing this, the attackers can attack
certain websites.
l Directory traversal attack
Attackers use the security holes of applications to access data or directories without
obtaining authorization, thereby causing data leak or tampering.
l Distributed denial of service (DDoS) attack
Attackers use the inherent security holes of network protocols to forge reasonable requests
to consume limited transmission bandwidth or occupy excess resources. As a result, the
network or service cannot properly respond to authorized requests and breaks down.
l Structured query language (SQL) injection attack
SQL injection attacks are a common type of injection attacks. Attackers inject malicious
SQL commands into a web form entry to trick the web server into executing the SQL
commands.
l Broken authentication and session management attack
Attackers exploit the defects in functions related to identity authentication in web
applications to steal authentication information or session management data, causing user
or administrator account thefts.
3.2.5 Rights Control

When a local user or domain user account is created, it is allocated certain rights. After a user
accesses the NE over the WebLMT, all operations performed by the user take effect only after
being authenticated on the NE. If the authentication fails, the NE returns a message indicating
that the user does not have permission to perform the operations.
Accessing the Web Server Directory Using the File Manager

Each user that uses the WebLMT for access can download or upload files on the File
Manager tab. Different levels of users have different rights to obtain information:
l Administrator(s): Can upload, download, or delete files.

l Operator(s)/User/Guest: Can only download files.

SingleRAN
l Custom user: Can obtain information according to the added commands.
Performing Operations on the WebLMT GUI

As of SRAN8.0, local Custom users can be authorized based on function items.
3.3 User Management
3.3.1 Overview
User management implements authentication and access control on users who log in to an NE
to perform O&M. Authentication identifies users, and access control defines and restricts the
operations that users can perform and the resources they can access.
Table 3-2 describes user management functions.
Table 3-2 User management functions
Function Description
User account management l Adding, modifying, and deleting accounts

l Querying account information
User password management l Restricting the minimum password length

and enforcing password complexity
l Limiting the password validity period
l Prohibiting the reuse of recent passwords
Login management l Authenticating a user identity based on the

account, and password.
l Specifying the time during which users
can log in
l Requiring the verification code and
supporting brute-force cracking defense
against user accounts with successive
login failures.
l Locking the GUI if no operation is
performed within a specified period of
time

SingleRAN
Function Description
User operation authentication l Authenticating operation objects

l Authenticating operation NEs
l Limiting operation GUIs
l Specifying the MML commands that
users can execute
l Restricting directories that users can
access (over FTP or on the File
Manager tab of the WebLMT)
l Specifying message tracing permission
Centralized user monitoring l Monitoring online user status

l Monitoring user operations
l Forcing users out
Centralized user management l (EMS) to authenticate users in a

centralized manner
l Delivering and revoking rights of domain
users
l Degrading local user account
management
l Synchronizing local user account
management policies
NOTE
l Local users perform O&M in the event of site deployment and transmission faults.
l Domain users perform routine O&M and are managed by the U2000 in centralized mode. The
centralized mode indicates that all the domain user accounts are created, modified, authenticated, and
authorized by the U2000.
l In addition to local and domain users, the base station controller/eCoordinator provides the default OS
root account for logging in to the OMU to perform O&M.
l U2000 users can run the MOD OP command to remotely change the password for the admin account.
3.3.2 Login Authentication

User login authentication on an NE (the base station controller, eCoordinator, or base station)
involves two types of users:
l Local users: Managed by the WebLMT

l Domain users: Managed by the U2000
A domain user can also log in to the WebLMT to access an NE. In this case, the NE forwards
login authentication information to the U2000, which then authenticates the user.
As of SRAN8.0, challenge-response authentication has been used to enhance user login security.

SingleRAN
NOTE
In challenge-response authentication mode, the authentication server sends a different question

("challenge") to the client, which must provide a valid answer ("response"). Authentication is implemented
by exchanging the digest value of the random number and password, instead of simply transmitting
passwords. The enhanced user login mechanism protects passwords from disclosure and replay attacks.
Controlling Login Time

The following login time control policies are used to ensure access security:
l A validity period can be set for a user account. After the period elapses, login using the
account is not allowed. Administrators can modify validity periods of accounts.
l Permissible access time ranges can be set for a user account. The ranges include validity
date ranges, time ranges, and week restrictions. Login is not allowed beyond the permissible
access time ranges.
Displaying Login Status

Users are prompted with login status to identify security risks, if any:
l Login failure information does not include detailed information.
Locking Insecure Accounts

Administrators can enable or disable local user accounts by using the SET OPLOCK command;
or unlock locked user accounts by using the ULK USER command.
Disabled or locked user accounts cannot be used for login. The identities of locked user accounts
cannot be checked.
Monitoring Users
The U2000 allows users to query information about online local and domain users and monitor
their status (login or logout). The U2000 can monitor all operations of specified online users.
When detecting that users are forcibly logged out, the U2000 disconnects the management
connections from the users.
The base station controller, eCoordinator, and base station determine the users to be monitored
according to the commands from the U2000 and report the results to the U2000.
User Local Login Alarm

A local login indicates that a local or domain user logs in to the base station through the
WebLMT. Security risks arise if the U2000 and north-bound system cannot be aware of a local
login in real time.
To ensure security, the base station generates an alarm to notify the U2000 and north-bound
system of a local login in real-time. The north-bound system can subscribe to the alarm and
check local login information immediately after receiving the alarm.
Only the base station supports the user local login alarm.

SingleRAN
3.3.3 User Rights Control

The base station controller, eCoordinator, and base station define five user levels: Administrator
(s), Operator(s), User(s), Guest(s), and Custom(s). Rights of these users to use command groups
are defined as follows:
l The rights of Administrator(s), Operator(s), User(s), and Guest(s) to use command groups
are fixed.
l The rights of Custom(s) to use command groups are defined depending on actual
requirements.
A command group is a group of commands that have the same attributes. For example, the G_8
command group consists of commands used to query equipment data, including the DSP
BRD and DSP BRDVER commands. The LST CCG command can be used to query the specific
commands in a command group.
To query accounts that are authorized to execute a command, perform the following steps:
1. Run the LST CMDVEST command to query the default and user-defined command groups
that contain a target command.
2. Run the LST OP command to query the accounts that are authorized to execute these
command groups.
Table 3-3 lists the mapping between user levels and command groups on base station controllers.
Table 3-3 Mapping between user levels and command groups on base station controllers
User Level Command Group
Administrator(s) G_0&G_1&G_2&G_3&G_4&G_5&G_6&
G_7&G_8&G_9&G_10&G_11&G_12&G_
13&G_14
Operator(s) G_0&G_2&G_3&G_4&G_5&G_6&G_7&
G_8&G_9&G_10&G_11&G_12&G_13&G
_14
User(s) G_0&G_2&G_4&G_6&G_7&G_8&G_9&
G_10&G_11&G_12&G_13&G_14
Guest(s) G_0&G_2&G_4&G_6&G_8&G_13
Custom(s) To be added by the user
Table 3-4 lists the mapping between user levels and command groups on eCoordinators.
Table 3-4 Mapping between user levels and command groups on eCoordinators
G_7&G_8&G_9&G_10&G_11&G_12

SingleRAN
G_8&G_9&G_10&G_11&G_12
User(s) G_0&G_2&G_4&G_6&G_7&G_8&G_9&
G_10&G_11&G_12
Guest(s) G_0&G_2&G_4&G_6&G_8
Table 3-5 lists the mapping between user levels and command groups on base stations.
Table 3-5 Mapping between user levels and command groups on base stations
G_7&G_8&G_10&G_11&G_12&G_13&G
_14&G_15&G_16&G_17&G_18&G_19&
G_20&G_21
G_8&G_10&G_11&G_12&G_13&G_16&
G_17&G_18&G_19&G_20&G_21
User(s) G_0&G_2&G_3&G_4&G_5&G_6&G_7&
G_8&G_10&G_11&G_12&G_13&G_16&
G_17&G_18&G_19&G_20&G_21
Guest(s) G_0&G_2&G_4&G_6&G_8&G_10&G_12
&G_16&G_18&G_20
Users can perform operations only after a successful login. All user operations are monitored
and operation permission is controlled. All operations must be classified according to permission
levels.
User operation permission is controlled by using MML commands or performing WebLMT

menu operations. Each MML command or menu can be associated with a command group. Base
station controllers and eCoordinators support authorizing users to use command groups. If a user
is authorized for a command group, the user can run all commands in the command group.
Before users operate NEs and objects, or run commands, the system checks their operation
permission levels to determine whether the operations are allowed. When users perform
operations beyond their permission, the system prompts them with a message, indicating that
the operations cannot be performed.

SingleRAN
User permission information is stored on servers. After users successfully log in to the clients,
the servers send user permission lists to the clients. The user permission lists are always stored
on clients before users log out.
The system does not allow users to run any commands beyond permissible time ranges.
If required, administrators can grant permission to a specific user. If users attempt to access base
station controllers beyond the permissible time range, the base station controllers and
eCoordinators refuse to perform user authentication. If users use expired passwords for login,
the system forces users to change their passwords. Administrators can cancel password
expiration policies.
3.3.4 Login Password Policy

The PWDPOLICY MO can be configured to specify the login password policy. Table 3-6
describes the parameters.
Table 3-6 Login password policy
Parameter Name Description
Password Minimal Length Meaning: Minimum length of a valid

password.
Value range: 6 to 32
Password Complicacy Meaning: Minimum requirements for

password complexity. This parameter is used
to set the character types that a password must
contain, which can be any combination of
lowercase letters, uppercase letters, digits,
and special characters. If NULL is displayed
in the query result, there is no special
limitation on the character type.
Value range: LOWERCASE(Lowercase),
UPPERCASE(Uppercase), DIGIT(Digit),
SPECHAR(Special character)
Password Max Miss Times Meaning: Maximum number of password

retries when a user logs in. When password
retries by a user exceed the maximum
number, the user account is locked.
Auto Unlock Time Meaning: Duration after which a locked user

account is unlocked automatically.
Unit: minute

SingleRAN
Resetting Interval of Account Lock Counter Meaning: Interval between two incorrect
password inputs. If a user inputs the password
incorrectly for x times (x can be configured)
and the interval between any two consecutive
incorrect inputs is smaller than the value
specified by this parameter, the user account
is locked.
Unit: minute
New Password Repeat Limit Meaning: How many previous passwords the
current password must be different from.
GUI value range: 1 to 10
Password Validity Meaning: Days in which a password is valid.

A password becomes invalid after being valid
for the days.
Value range: 0,7 to 90
Unit: day
Minimum Password Duration Meaning: Minimum validity period for the

password. Users are not allowed to change the
password in this period.
GUI value range: 1 to 10080
Unit: minute
Note: Only the base station supports this
parameter.
Password Expiration Reminder Meaning: Number of days in advance users

are notified that their passwords are about to
expire.
Unit: day
Must Modify Password When First Login Meaning: Whether the system forces a user to
Switch change the initial password. If this parameter
is set to ON(ON), the system forces a user
who logs in to an NE using the initial
password to change the password.
Value range: OFF(OFF), ON(ON)
Max Repeat Char Times Meaning: Maximum repeat times of one

character

SingleRAN
Weak Dictionary Check Switch Meaning: Whether the system checks the
password in weak password dictionary.
Value range: OFF(OFF), ON(ON)
Maximum Consecutive Characters from User Meaning: The number of consecutive

Name characters from a user name that cannot be
contained in a password. Note that characters
from a user name are case-insensitive in a
password.
For example, if a user name is userA123 and
this parameter is set to 3, a password cannot
contain three or more consecutive characters
from userA123. That is, passwords, such as
use5678, ser5678, and erA5678, cannot be
used.
Note: Only the base station supports this
parameter.
MML Example
On the base station controller or eCoordinator, run the following command to configure a
password policy:
SET PWDPOLICY: PWDMINLEN=8, COMPLICACY=LOWERCASE-1&UPPERCASE-1&DIGIT-1,
MAXMISSTIMES=3, AUTOUNLOCKTIME=30, RESETINTERVAL=5, MAXVALIDDATES=90,
MAXPROMPTDATES=10, HISTORYPWDNUM=5, MaxRepeatCharTimes=2,
FirstLoginMustModPWD=OFF,DICTCHKSW=ON;
The password policy defined by the command is as follows:

l The minimum password length is 8.
l The password must contain uppercases, lowercases, and digits.
l The maximum number of password retries is 3.
l The automatic unlocking time is 30 minutes.
l The reset interval is 5 minutes.
l The password remains valid for a maximum of 90 days.
l Users are notified that their passwords are about to expire 10 days in advance.
l A maximum of 5 previously used passwords are recorded.
l The maximum number of single character repetitions in a password is 2.
l The system does not force a user to change the initial password.
l The system checks a password in the weak password dictionary.
On the base station, run the following command to configure a password policy:
SET
PWDPOLICY:PWDMINLEN=8,COMPLICACY=LOWERCASE-1&DIGIT-1,MAXMISSTIMES=3,AUTOUNLOCKTIME

SingleRAN
=30,RESETINTERVAL=5,PASSREPLMT=5,MAXPERIOD=30,MINPERIOD=1440,PWDEXPRT=10,FirstLogi
nMustModPWD=OFF,MAXREPEATCHARTIMES=2,DICTCHKPWD=OFF,MAXCCUN=1;
The password policy defined by the command is as follows:
l The minimum password length is 8.

l The password must contain lowercases and digits.
l The maximum number of password retries is 3.
l The automatic unlocking time is 30 minutes.
l The reset interval is 5 minutes.
l A maximum of 5 previously used passwords are recorded.
l The password remains valid for a maximum of 30 days.
l The minimum validity period for the password is 1440 minutes.
l Users are notified that their passwords are about to expire 10 days in advance.
l The system does not force a user to change the initial password.
l The maximum number of single character repetitions in a password is 2.
l The system does not check a password in the weak password dictionary.
l The maximum number of consecutive characters from a user name that can be contained
in a password is 1.
Password Usage Rules

To ensure that passwords are not disclosed, tampered with, or stolen, the system adheres to the
following password usage rules:
l Passwords entered are displayed as asterisks (*).

l When creating passwords, users must verify the new passwords, and the passwords entered
cannot be copied.
l Users can change their passwords. The old password must be verified during a password
change.
l When changing other users' passwords, the administrators can only reset the passwords but
cannot view the passwords in plaintext.
l User accounts are locked when the number of consecutive password attempts reached a
specified threshold.
Password Storage and Transmission Rules

The system adheres to the following password storage and transmission rules:
l Passwords are encrypted using SHA256 when stored locally.

l Administrators cannot retrieve passwords in the form of plaintext or query other user
passwords.
Password Validity Period Management

The system manages password validity periods using the following methods:
l The system forces users to change their passwords when passwords expire.

SingleRAN
l When users first use default or factory passwords, which are automatically allocated by the
system, the system forces users to change the passwords.
l The system prompts users to change their passwords before the passwords expire. If
passwords are not changed after expiration, users cannot log in to the system, but the
passwords can be modified or changed on the U2000. Administrators can disable password
expiration policies on the U2000.
3.3.5 Simultaneous Online User Number Management

Concepts
l Number of online instances
A login instance is added each time a local user or domain user successfully logs in to an
NE through the WebLMT. This login instance is available until the user logs out.
A single user can be allocated multiple login instances through repeated login. The total
number of login instances of all users is referred to as the number of online instances on
an NE.
If five users use the same admin account to successfully log in to an NE, each successful
login is allocated a login instance, that is, the number of online instances is five.
l Maximum number of online instances
Each login instance of an NE occupies the system resources. The maximum number of
online instances is predefined, but not configurable. For example, the MBSC allows a
maximum of 32 online instances and a co-MPT MBTS allows a maximum of 6 online
instances.
Specifically, when the number of online instances on the MBSC or eCoordinator reaches
32 after one or more users log in to the MBSC or eCoordinator, the other users cannot log
in to the MBSC.
Implementation
Simultaneous online user number management is used to control the maximum login instances
of a user on an NE, thereby ensuring that multiple users can concurrently log in to an NE. Without
this function, one or more users may repeatedly log in to an NE and do not log out, preventing
other local users from login when the number of allowed online instances reaches the maximum
and affecting the O&M of the NE.
This function is configured using the SET USRMAXONLINE command, in which
Configuration Type can be set to any of the following values:
l LOCAL_USER_GENERAL(General configuration of local users): The maximum
number of online instances is set to the same value for all local users. For example, when
Max Users Online is set to 3, new login request of any local user with three online instances
is denied.
This configuration does not change the Max Users Online setting of a local user specified
in SPECIFIED_LOCAL_USER(Configuration of a specified local user).
l SPECIFIED_LOCAL_USER(Configuration of a specified local user): The maximum
number of online instances is specific to a local user. For a local user, this configuration
takes precedence over the preceding general configuration.
l DOMAIN_USER_GENERAL(General configuration of domain users): The
maximum number of online instances is set to the same value for all domain users. For

SingleRAN
example, when Max Users Online is set to 3, new login request of any domain user with
three online instances is denied.
l RESTORE_ALL_LOCAL_USER(Restore to general for all local users): The
maximum number of online instances for all local users reverts to the value specified in
general configuration for local users.
l RESTORE_SPECIFIED_LOCAL_USER(Restore to general for one local user): The
maximum number of online instances for a local user reverts to the value specified in
general configuration for local users.
The LST USRMAXONLINE command can be used to query the configurations, including
general configuration for local users, general configuration for domain users, and configuration
for a specified local user.
It is good practice to set the maximum number of online instances as follows:
l Set the maximum number to 1 for users of the administrator level, including the admin
user, thereby enhancing system security.
l Set the maximum number based on the number of admitted terminals and tools for accounts
used by the terminals or tools.
The login system applies also restrictions to the total number of online instances of online users
along with the number of online instances of each user. When the total number of online instances
of all online users reaches the upper limit, the other users cannot log in until an online instance
logs out.
3.3.6 Southbound Interface Access Management

The U2000 and the NetEco connected to an NE over the southbound interface use the pre-shared
keys for identity authentication. The U2000 and the NetEco use the EMSCOMM account and
the EMSCOMMNETECO account, respectively, as the identity.
NOTE
The trace server (TS) is a subsystem of the U2000 and uses the U2000's identity credentials to access NEs.
Generally, the identity credentials do not distinguish between the U2000 and TS in NE logs, but
EMSCOMMTS is used to identify the TS in some MBTS logs.
The password for the account must be consistent between an NE and the NMS (either the U2000
or NetEco); otherwise, the NE cannot connect the NMS.
U2000
The U2000 can configure separate EMSCOMM passwords for different NEs. In SRAN8.0 and
later versions, the EMSCOMM password on an NE and the U2000 can be simultaneously
changed by choosing Security > Modify Password of OM Connection Administration on the
U2000.
When an NE is disconnected from the U2000 (for example, when the NE replaces its boards),
and the cause of the disconnection alarm is displayed as login failure on the U2000, perform the
following steps:
l On the NE side
– Use a local administrator account to log in to the LMT of the NE by using the U2000
proxy.

SingleRAN
– Run the MOD OP command to change the EMSCOMM password on the NE.
l On the U2000 side
– Select the NE on the U2000 topology.
– Right-click, choose NE Properties from the shortcut menu, and then specify Account
for Logging In to NE in the displayed window.
NetEco
The NetEco can configure separate EMSCOMMNETECO passwords for different NEs. To
change the EMSCOMMNETECO password for an NE, perform the following steps:
l On the NE side, run the MOD OP command to change the EMSCOMMNETECO

password.
l On the NetEco side, choose Maintenance > Data Transfer Setting to change the
EMSCOMMNETECO password.
3.3.7 FTP User Management

The base station controller or eCoordinator has two FTP users:
l FtpUsr: Uses a third-party FTP client to log in to the FTP server on the NE and then upload
or download information about the NE.
l U2000 user: Uploads or downloads data between the NE and the U2000.
In SRAN7.0 and earlier versions, user management is defined as follows:
l FtpUsr: The MOD FTPPWD command can be used to change the password, but the
password policy does not take effect on this user.
l U2000 user: The password can be changed on the U2000 GUI, but the password policy
does not take effect on this user.
SRAN8.0 and later versions have the following enhancements to user management:
l When an FtpUsr changes the password, the base station controller checks the password
complexity according to the configured password policy. The base station does not check
the complexity of the password input by the user during software installation. Instead, the
user, when logging in to the FTP server, is prompted with a message indicating that the
password complexity is lower than the current configuration and must be changed.
However, the user can still use the password to log in to the FTP server without interrupting
the current FTP connection. The user will be forced to change the password to meet the
password complexity requirements after a specified period of time. When a U2000 user
changes the password, the base station controller checks the password complexity
according to the configured password policy. However, if a U2000 user fails to log in to
the FTP server, the base station controller does not lock the account but reports a security
alarm. This is because the password is used to secure data transmission over the southbound
interface, which connects the U2000 to the base station controller.
3.4 Sensitive Personal Data Security

SingleRAN
3.4.1 User Data Anonymization

Huawei equipment supports user data anonymization. This function makes user identity
information anonymous during maintenance and commissioning to protect personal privacy.
For details, see User Data Anonymization Feature Parameter Description.
3.4.2 Sensitive Personal Data Protection

To protect sensitive personal data, Huawei supports the following:
1. Specifying and logging the causes for starting system tasks that involve sensitive personal
data. The tasks mainly include:
a. Trace tasks
b. Emergency diagnosis tasks
c. Port mirroring tasks
2. Periodically deleting system files that contain sensitive personal data. These files mainly
include:
a. CHR and MR files
b. Trace files
The interval at which such files are automatically deleted can be defined by users.
3.5 Security Management of Configuration Files
3.5.1 Overview
The configuration data contains some security-sensitive data, such as keys and passwords. The
security-sensitive data is encrypted to be stored in the system database. When the configuration
data is exported to a configuration file, the configuration file can be encrypted by adding a
password.
If the configuration data is not encrypted when being exported to a configuration file, the
configuration file may contain security-sensitive fields. In this case, the operator must store the
configuration file properly and then delete the security-sensitive fields immediately to avoid
information leakage.
3.5.2 Application Scenario

Configuration file encryption applies to the following scenarios:
l Offline transmission of a configuration file

l Export the configuration scripts from the CME and then copy the scripts to an NE to activate
the scripts.
l Export the configuration scripts from an NE and then copy the scripts to another NE to
activate the scripts.
l Permanent storage of configuration files
The NE data (including scheduled tasks) is backed up online on the U2000.

SingleRAN
3.5.3 Configuration File Encryption

The following changes have been added to support configuration file encryption:
l The ENCRYPTMODE and FILEPWD parameters are added to the southbound interface
commands and MML commands.
l Encryption and decryption options are added to the GUI of tools such as the U2000, CME,
and WebLMT.
The ENCRYPTMODE parameter (specifying the encryption mode) has two values:
l UNENCRYPTED: The configuration file is not encrypted.

l PWD_ENCRYPTED: If the parameter is set to this value, enter a password consisting of
6 to 32 digits.
In the event of offline transmission of a configuration file, the procedure for encrypting a
configuration file is as follows:
1. The user selects an exported configuration file to be encrypted. The system encrypts the
configuration file.
2. The configuration file is forwarded offline to the destination.
3. The user runs scripts or enters the password. The system decrypts the configuration file.
In the event of online permanent storage of configuration files, for example, online backup of
NE data on the U2000, the procedure for encrypting a configuration file is as follows:
1. The user selects the NE data to be backed up and select the encryption option on the GUI.
2. The U2000 delivers the command to back up the NE data. The NE data is backed up on
the NE and encrypted for storage.
3. The U2000 loads the encrypted file from the NE to the system for storage.
3.6 Digital Signature-based Software Integrity Protection
3.6.1 Definition
Software integrity protection adds a digital signature to software by using a private key before
uploading software to the target server or NE. When a target NE downloads, loads, or runs
software, the NE authenticates the digital signature by using a matched public key. This ensures
end-to-end software reliability and integrity.
With this function, any virus or software tampering can be promptly detected. This prevents
malicious software from running on NEs.
3.6.2 Application Scenarios

Software integrity protection applies to the following scenarios:
l Software installation
l Software upgrade
l OS (DOPRA Linux or Euler Linux) upgrade

SingleRAN
l OS (DOPRA Linux or Euler Linux) driver upgrade
3.6.3 Digital Signature
Overview
Integrity protection adopts the following two techniques: Hash algorithm: A one-way Hash
function.
l A Hash algorithm converts an arbitrary data block into a fixed-size bit string. The most
commonly used Hash algorithms are Message-Digest algorithm 5 (MD5), SHA-256, and
SHA-1.
l Public key cryptography: A pair of public and private keys is used for encryption and
decryption. The two keys relate to each other and belong to the same holder. The public
key is published for use, whereas the private key is confidential.
Principles
Figure 3-2 illustrates the principles of digital signatures.
Figure 3-2 Digital signature principles
The procedure for adding a digital signature is as follows:
1. A Hash algorithm calculates the message digest for the files to be signed in the software
package.
2. The private key is used to encrypt the message digest.
3. The encrypted message digest is saved to a digitally signed file.
The digitally signed file is then released with the software package.
After an NE or a U2000 receives the software package, it verifies the contained digital signature.
The procedure for verifying the digital signature is as follows:

SingleRAN
1. The same Hash algorithm calculates the message digest for the files to be verified in the
software package.
2. The public key is used to decrypt the digitally signed file to restore the message digest.
3. The restored message digest is compared with the original message digest.
If they are identical, the software was not tampered with. If they are different, the software
was tampered with.
Huawei Software Digital Signature Solution

In addition to the CRC function, the Huawei software digital signature solution in SRAN6.0 and
later incorporates the SHA256 algorithm and public key cryptography-based digital signature.
The Huawei solution implements digital signature and authentication during the software life
cycle (including software generation, release, installation, and running) to ensure software
integrity protection.
Figure 3-3 illustrates the procedure for Huawei software digital signature solution.
1. In the software package generation phase, SHA256 check codes are calculated for each
software component in the software package and saved to check code files. The check code
files are then digitally signed with the private key.
The check code files indicate files that are encrypted and added with verification
information and the algorithms that are used.
2. In the software version release phase, all software files and digitally signed files are
packaged and then uploaded to a version server, for example, http://support.huawei.com.
3. In the software version upgrade phase, when the U2000, WebLMT, or upgrade tool
downloads the software package from the version server, the U2000, WebLMT, or upgrade
tool authenticates the software package by using the public key. This is to verify the
software package authenticity.
4. Also in the upgrade phase, when the NE downloads the software package from the U2000,
WebLMT, or upgrade tool, the NE authenticates the software package by using the public
key to verify that the software has not been maliciously tampered with.

SingleRAN
Figure 3-3 Procedure for Huawei software digital signature solution
1: Calculate SHA256 check codes. 2: Release the software package.
3: Download the software package. 4: Distribute the software package.
External attackers or unauthorized internal users may tamper with the software after the OMU
software is installed. Therefore, the base station controller checks the integrity of the software
on the OMU and reports only one ALM-20723 File Loss or Damage if one or more files are
damaged or lost. This alarm is cleared after all the damaged or lost files are restored. For an OS
upgrade, the U2000 or upgrade tool checks the integrity of the OS upgrade package.
For an OS upgrade, the U2000 or upgrade tool checks the integrity of the OS upgrade package.
For an OS driver upgrade, the driver upgrade tool checks the integrity of the OS drive package.

SingleRAN
3.7 Time Security
3.7.1 SNTP Security for the Base Station Controller/eCoordinator

The NE must synchronize its time with the SNTP server (for example, the U2000) to ensure that
the system time is accurate. Time synchronization uses SNTP and supports two modes: plaintext
mode and authentication mode. The mode used is specified by the AUTHMODE
(BSC6900,BSC6910) parameter. The authentication mode refers to the SNTP security mode.
SNTP security prevents the NE from adjusting the time incorrectly after receiving a time
synchronization attack message. This improves the reliability of the NE on the network and helps
ensure normal O&M functions. The NE encrypts time synchronization request information, adds
the key ID and digest value to the time synchronization request, then sends the request to the
SNTP server. Upon receiving a time synchronization response from the SNTP server, the NE
identifies the encryption algorithm and key according to the configured key ID, calculates the
digest value based on the received SNTP packet, and checks whether the calculated digest value
is the same as that contained in the SNTP packet. If so, the NE considers the SNTP packet legal
and synchronizes its time with the SNTP server. If not, the NE considers the SNTP packet illegal
and the base station controller discards it.
The NE supports the SNTP V3 protocol and is compatible with the SNTP server and NTP server.
However, the time synchronization precision of the NE is the same as that supported by SNTP.
3.7.2 NTP Security Authentication for the Base Station

Base stations are deployed on public networks. If a base station uses an invalid reference clock,
the time on the base station becomes incorrect. This may cause errors in information such as
error alarms and logs, affecting base station maintenance.
NTP security authentication protects the integrity and authenticates the source of NTP packets
received by base stations to ensure that base stations use valid reference clock. The
AUTHMODE, KEY, and KEYID parameters in the NTPCP MO on a base station functioning
as an NTP client must be set to the same values as those on the NTP server. NTP security
authentication supports Data Encryption Standard (DES) and MD5. DES has been cracked and
is not recommended. NTP security authentication uses digital signatures to verify NTP packets
to ensure the validity of the reference time received by base stations. Figure 3-4 illustrates the
principle for NTP security authentication.
Figure 3-4 Principle for NTP security authentication

SingleRAN
If the AUTHMODE parameter in the NTPCP MO is not set to PLAIN(Plain), NTP security
authentication is performed in encryption mode. The authentication procedure is as follows:
1. After calculating the checksum of NTP packets, the NTP server sends the checksum and
NTP packets to the base station.
2. The base station calculates the checksum of the received NTP packets, and compares the
calculated checksum with that in the NTP packets.
l If the checksums are identical, the NTP packets were not tampered with during
transmission and pass the NTP security authentication.
l If the checksums are different, the NTP packets were tampered with and fail the NTP
security authentication.
If the AUTHMODE parameter in the NTPCP MO is set to PLAIN(Plain), the NTP server sends
NTP packets directly to the base station without encryption, and therefore the base station does
not need to decrypt the received NTP packets.
NOTE
Only 3900 series base stations support NTP.
3.8 Security Alarms, Events, and Logs
3.8.1 Overview
The U2000 and the WebLMT manage security alarms, events, and logs. If security faults occur,
users can be informed of the faults and perform fault diagnosis according to the reported alarm
or event information. In addition, security risks and vulnerability can be analyzed by tracing
history security alarms and logs.
Since SRAN7.0, user information and IP addresses can be recorded in the operation logs of
specific domain users. In versions earlier than SRAN7.0, domain users for the U2000 are not
distinguished and are collectively named EMSCOMM.
Since SRAN7.0, log tracing has been enhanced. Detailed information about the traced objects
is recorded in the tracing logs.
3.8.2 Security Alarms and Events

Table 3-7 lists the security alarms and events that may be reported by the base station
controller/eCoordinator when the related security faults occur.
Table 3-7 Security alarms and events
Alarm or Event ID Alarm or Event Name
ALM-20723 File Loss or Damage
EVT-22813 Domain User Login Failed
EVT-22814 Local User Login Failed

SingleRAN
Alarm or Event ID Alarm or Event Name
EVT-22815 Local User Locked
EVT-22805 Local User Modifying Other Operator's

Password
ALM-20732 SSL Certificate File Abnormity
ALM-20850 Digital Certificate Will Be out of Valid Time
ALM-20851 Digital Certificate Loss, Expiry, or Damage
ALM-20852 Exceeded Failures of Logins by the Local

User
ALM-20714 OMU Time Synchronization Abnormity
Table 3-8 lists the security alarms that may be reported by the base station when the related
security faults occur.
Table 3-8 Security alarms
Alarm ID Alarm Name
ALM-26204 Board Not In Position
ALM-25670 Water Alarm
ALM-25671 Smoke Alarm
ALM-25672 Burglar Alarm
ALM-26830 Local User Consecutive Login Retries Failed
ALM-25950 Base Station Being Attacked
ALM-26266 Time Synchronization Failure
3.8.3 Security Logs and Security Audit
O&M Event Recording

The base station controller, eCoordinator, and base station support security logs, in which
security operations and events during routine O&M are recorded and cannot be modified. Based
on the recorded information, the operators can perform security audit, identify sources of security
accidents and problems, and find ways to improve network security.
Logs record information about system security and user operations, and are classified into
operation logs of NEs and the U2000, system logs, and security logs. By querying logs, users

SingleRAN
can obtain information about the running status, system security situation, and user operations
on NEs or the U2000. Users can also save logs as files or print them out.
The U2000 can centrally manage NE logs by performing the following:
l Supporting centralized collection, query, measurement, analysis, and output of logs.

l Recording information about its own running status, security events, and operations. The
information can be queried and audited.
l Periodically collecting NE logs based on user settings.
Users can audit the security logs collected by the U2000 to evaluate O&M security.
O&M Event Recording

Logs of the U2000, base station controller, eCoordinator, and base station record separate
information about system security and user operations, that is, O&M security-related events
during the running process.
Operation Logs
When commands are sent to NEs from the WebLMT or U2000, the command execution results
are saved in operation logs. The operation logs include those of the U2000 and NEs.
Operation logs record the operations to create, modify, query, modify, load, switch over NEs
and so on. The operations can be manually performed by O&M personnel or automatically
started by scheduled tasks on the WebLMT or U2000.
System Logs
System logs mainly record the system running status of NEs or the U2000. System logs help
users to learn the system running status and identify causes of security faults. The system herein
refers only to Huawei-developed application systems and system logs include those of the U2000
and NEs.
System logs record the following information:
l Abnormal status and actions while the system is running, such as active/standby
switchovers, storage failures, and timer expiration
l Key events during system running, such as system startup and shutdown
l Operating status of the system process, such as the process start, exit, running, and
abnormality (for example, the system process stops responding)
l Usage of system resources, such as central processing unit (CPU), memory, and hard disk
Security Logs
Security logs record information about security events.
Security logs of base stations record the following:
l Events related to account login, such as user login, user logout, account locking, and account
unlocking

SingleRAN
l Events related to account management, such as account addition, deletion, and

modification, password change, and permission modification
l Events related to user authentication, such as unauthorized access
Security logs include those of the U2000 and NEs. Users can evaluate system security by auditing
security logs. For details, see Security Log Auditing.
Table 3-9 describes security events recorded in security logs that the base station controller/
eCoordinator can provide.
Table 3-9 Security logs of the base station controller/eCoordinator
Security Event Type Security Log
Account login event A domain user has logged in to the base

station controller.
A domain user has logged in to the base

station controller.
A local user has logged in to the base station

controller.
A local user has logged out of the base station

controller.
The system locks a local user account whose

failed login attempts exceed the maximum
number.
The system automatically unlocks a local user

account after the locking time expires.
A local user account is manually unlocked.
A local user account is locked by the

administrator.
An account is automatically locked when the

password expires.
Account management event A domain user or local user has been forced
to log out after having logged in to the base
station controller.
A local user account has been added,

removed, or modified.
The user group to which a local user belongs

has been changed.
The rights granted to a local user group have

been changed.
The commands in a command group have

been adjusted.

SingleRAN
Security Event Type Security Log
The rights granted to a local user have been

changed.
A local user has changed the user's password.
A local user has changed the password of

another user.
The account or password policy has been

changed.
OMU security event The OMU has started or stopped, or active

and standby OMUs have been switched over.
Digital certificate security event A digital certificate has been updated.
Upgrade-related security event The driver has been upgraded.
OMU configuration-related security event OMU network parameters, such as the

internal network, external network, VLAN,
mask, IP address, and host name, have been
modified.
Active and standby OMUs have been

configured.
OMU security event for changing the The password of the admin account has been
password of an initial account changed.
The password of a database account has been

changed.
SNTP time synchronization event SNTP time synchronization has failed.
Table 3-10 lists security-related operation logs that the base station controller/eCoordinator can
provide.
Table 3-10 Security-related operation logs of the base station controller/eCoordinator
Security Event Type Operation Log
Account authentication events A domain user or local user fails to be

authenticated to perform a certain operation.
A user attempts to access an object without

the permission, which is specified when the
user is created by running the ADD OP
command.

SingleRAN
The LST SECLOG and LST OPTLOG commands can be used to query security logs and
operation logs, respectively.
Centralized Log Management

The U2000 supports the following centralized management on U2000 logs and NE logs:
l Log collection
Users can set log collection tasks and specify task periods to enable the U2000 to
periodically collect NE logs. Users can also set dumping and export of U2000 logs and NE
logs.
l Log query and printing
By querying logs, users can obtain information about the running status, system security
situation, and user operations of the U2000 or NEs. Users can also save logs as files or print
them out.
l Log analysis
Based on U2000 logs and NE logs collected, users can analyze such information as system
running status, security events, and operations.
Log Collection
Users can collect and dump all operation logs, security logs, and system logs of the U2000 as
well as operation logs and security logs of NEs. NEs generate and save their own system logs
and automatically report the logs to the U2000. For details, see Log Management in the U2000
product documentation.
Log Query and Printing

For details about how to query or print logs on the U2000, see Log Management in the U2000
product documentation.
On the WebLMT, users can query log files generated during a time range, including operation
logs and security logs. For details, see MML Command Reference.
Security Log Auditing
Auditing Security Events

Security event auditing refers to a process where the base station controller, eCoordinator, or
base station generates audit records based on security events (security logs). Auditable security
events include:
l Startup and shutdown of the system or applications

l User login success and failure events: Including information about user names, login time,
workstation (such as its IP addresses), and causes of login failures (such as incorrect
passwords and invalid accounts)
l User logout success and failure events: Including information about user names, logout
time, workstation (such as its IP addresses), and causes of logout failures
l Users' attempt to access resources without their permission

SingleRAN
l All O&M and configuration events: Including information about user names, O&M time,
workstation (such as its IP addresses), operations, and responses
l Operations concerning user accounts and permission levels: Including addition, deletion,
and modification
Events to be recorded in security logs are configurable, and the configuration process must be
recorded in security events that can be audited. For details about how to audit security logs, see
Log Management in the U2000 product documentation.
Saving Security Logs

The base station controller, eCoordinator, and base station use databases to save security logs.
Users cannot modify or delete these logs.
If the number of audit records saved in any security log exceeds 200,000, the base station
controller, eCoordinator, and base station transfer the earliest 10,000 records to a Flash to prevent
the database from overflowing.
If the number of saved logs reaches a limit, earliest logs will be discarded at the arrival of new
logs.
NOTE
The maximum number of logs that can be saved can be configured by using the SET LOGLIMIT command
on the base station controller or eCoordinator, but not on the base station.
Querying Security Logs

Users can query audit records available in databases. The base station controller, eCoordinator,
and base station support query by time interval, user name, interface, workstation IP address,
result, and command name (for example, MML command names).
For details about how to query security logs, see Log Management in the U2000 product
documentation.
3.9 OMU Anti-attack

The integrated firewall performs the following operations on all IP data streams transmitted to
the OMU:
l IP address filtering, which enables the OMU to only accept IP data streams from authorized
IP addresses and network segments
l Defending against attacks, such as ICMP ping, IP fragmentation, low time to live (TTL),
Smurf, and distributed denial-of-service (DDoS) attacks
l Defending against TCP sequence prediction attacks and synchronization (SYN) flood
attacks
l Isolating the internal network from the external network on the base station controller and
eCoordinator side: Packets whose destination IP addresses are internal IP addresses or
belong to an internal network segment cannot flow in to the base station controller or the
eCoordinator through the OMU.
For a properly running network, specifying whitelisted and blacklisted IP addresses is generally
not required and the IP addresses used for access is not restricted. Specifying whitelisted and

SingleRAN
blacklisted IP addresses can be used to improve the security of the base station controller and
the eCoordinator:
l Whitelist: Only the specified IP address or IP addresses in the specified network segment
can be used to access the base station controller and the eCoordinator. The IP addresses
can be specified for a particular port or for all ports. Once some IP addresses are whitelisted,
all the other IP addresses are blacklisted and cannot be used for access.
l Blacklist: The specified IP address or IP addresses in the specified network segment cannot
be used to access the base station controller and the eCoordinator. The IP addresses can be
specified for a particular port or for all ports. All IP addresses that are not blacklisted are
whitelisted.
NOTE
Base stations do not have the OMU.
3.10 Security Policy Level Configuration

A large number of NEs are deployed on the RAN side and scattered. The required security
policies are various and complex. Therefore, security policies may be incorrectly or incompletely
configured.
Security policy level configuration, designed to drastically simplify security policy

configuration, allows hierarchical management of security polices and parameters based on
security risks and best practices in the industry.
Security policy level configuration is implemented by Consistency Check\Security Policy

Level function on the CME. This function manages some security policies for the entire network
and supports user-defined security policy management. The security policies to be managed
include:
l General security policies

l Security policies that are vulnerable to attacks
l Security policies that have little impacts on services
By default, there are two levels of security policies:
l Level 1 enables security policies on condition that function compatibility is guaranteed.

l Level 2 enables strongest security policies but may cause compatibility problems.
Table 3-11 provides a default example of the security policy configuration level template.
Table 3-11 Security policy configuration template
Property Level 1 Level 2 Belonging to
OS Password Complicacy LOWERCASE-1&D LOWERCASE-1& O&M security/

IGIT-1 DIGIT-1&UPPER user management
CASE-1
OS Password Minimal 8 10 O&M security/

Length user management

SingleRAN
OS Weak Dictionary ON ON O&M security/

Check Switch user management
Set the Activation Status ON OFF O&M security/

of the Local OAM user management
Account
Set Local OAM Account OFF ON O&M security/

Locked State user management
OAM Password LOWERCASE-1&D LOWERCASE-1& O&M security/

Complicacy IGIT-1 DIGIT-1&UPPER user management
CASE-1
OAM Password Minimal 8 10 O&M security/

Length user management
OAM Password Max 120 90 O&M security/

Period user management
Password Max Miss 5 3 O&M security/

Times user management
Password Dictionary ON ON O&M security/

Check Switch user management
Set OAM Connection SSL ALL ONLY_SSL O&M security/

Mode OMCH security
Set OAM Connection SSL NONE PEER O&M security/

Authentication Mode OMCH security
SSL Renegotiation Switch DISABLE ENABLE O&M security/

OMCH security
SSL Renegotiation Period 60 60 O&M security/

OMCH security
Set FTP SSL Mode Auto Encrypted O&M security/

OMCH security
Set FTP SSL Certificate NO YES O&M security/

Authentication OMCH security
FTPS Client Support YES YES O&M security/

Status Firewall OMCH security
FTP Server Transfer AUTO ENCRYPTED O&M security/

Encrypt Mode OMCH security
Set Web LMT login policy LOGIN_HTTPS_O HTTPS_ONLY O&M security/

NLY Web security

SingleRAN
Invalid Packet Check ENABLE ENABLE Device security/

Switch integrated
firewall
ARP Spoofing Check ENABLE ENABLE Device security/

Switch integrated
firewall
ARP Learning Strict DISABLE ENABLE Device security/

Switch integrated
firewall
NOTE
Security policy level configuration invokes the batch configuration interface of an NE. Therefore, the
configuration restoration function on the CME can be used to roll back batch configuration or restore the
configurations of an NE.

SingleRAN
OM Security Feature Parameter Description 4 Engineering Guidelines
4 Engineering Guidelines
4.1 OMCH Security

OMCHs are secured using SSL. For details, see SSL Feature Parameter Description.
4.2 Web Security
4.2.1 When to Use Web Security

Web applications are vulnerable to attacks. It is good practice to configure the following:
l Password security policy

l WebLMT login policy
l Rights to access File Manager on the WebLMT
4.2.2 Deployment
Requirements
None
Activation
Using MML Commands

To set the password security policy, perform the following step:
Step 1 Run the SET PWDPOLICY command to set the password security policy for local WebLMT
users.
----End
To set the WebLMT login policy, perform the following step:

SingleRAN
Step 1 Run the SET WEBLOGINPOLICY command to set the policy for logging in to the WebLMT.
In this step, set Policy for login to LMT and transmission to an appropriate value.
Step 2 Run the RST OMUMODULE command to restart the WebLMT server for the configured
WebLMT login policy to take effect. In this step, set Target OMU to ACTIVE(Active
OMU) and Module Name to weblmt.
----End
NOTE
Running the RST OMUMODULE command disconnects all users from the WebLMT but does not affect
OMU services. The WebLMT server can be restarted within 5 seconds if no exception occurs during the
restart.
While the WebLMT server restarts, WebLMT clients are disconnected and therefore cannot receive the
restart command response from the WebLMT server. In addition, an error message indicating that the
command fails to be sent is displayed. Ignore this error prompt because the command was successfully
sent.
The configured WebLMT login policy takes effect only after you log out and then log back in to the
WebLMT.
You can run the LST WEBLOGINPOLICY command to query the current policy for logging in to the
WebLMT.
To configure the rights of the Custom user to access the File Manager, perform the following
steps:
Step 1 On the WebLMT GUI, click User-defined command Group to add commands and function
items to a specific command group.
Step 2 Run the ADD OP or MOD OP command with Operator Level set to Customs(Custom) and
Command Group set to the same value as that specified in Step 1.
----End
NOTE
The configured rights to access the File Manager take effect only after you log out and then log back in
to the WebLMT.
Using the CME

Security policy level configuration on the CME can be used to configure password security
policy and WebLMT login policy for existing base stations.
You can perform consistency check on the Current Area on the CME. If the check results need
to be delivered, create or select a planned area first.
Step 1 On the CME, choose CME > Advanced > Consistency Check > Security Policy Level (CME
client mode) to set the consistency check parameters for security policies.
Step 2 Select the NEs for which consistency check is to be performed, execute the check to generate a
check report.
Step 3 Based on the check report, correct the configurations on NEs in batches in the event of
inconsistency.
----End

SingleRAN
Activation Observation
N/A
4.3 User Management
4.3.1 When to Use User Management

User management provides the following security functions:
l User rights control

It is good practice to customize user rights based on user service requirements.
It is good practice to subscribe to the user local login alarm.
l Southbound access authentication
For southbound access authentication, it is good practice to change the password for
accessing the southbound interface immediately after an NE uses the default password to
access the network.
l FTP user management
It is good practice to enable SSL encrypted transmission for the FTP client.
4.3.2 Deployment
Requirements
None
Activation
Using the MML Commands
User Rights Control

You can add users in either of the following scenarios:
l Add a user of a predefined level (Administrator(s), Operator(s), User(s), or Guest(s)). Fixed

rights have been allocated to such users to use command groups and cannot be changed.
l Add a user of the Custom(s) level and manually configure the user's rights to use command
groups.
The following provides configuration examples.
l To add a user of a predefined level, for example, Operator(s), perform the following step:
Step 1 Run the ADD OP command to add an Operator user.
----End

SingleRAN
l To add a user of the Custom(s) level who has the rights to use the G_22 command group
including the COL LOG command so that the user can collect log files, perform the
following steps:
Step 1 Run the SET CCGN command to configure G_22 as the command group.
Step 2 Run the ADD CCG command to add commands to the G_22 command group. In this step, add
the COL LOG command to the command group.
Step 3 Add a user of the Custom(s) level and configure the rights to use the G_22 command group for
the user.
----End
FTP User Management

l To configure FTP clients to use encrypted transmission, perform the following step:
Step 1 Run the SET FTPSCLT command with The Encrypted Mode set to ENCRYPTED(SSL
Encrypted).
----End
NOTE
An FTP client refers to a module that has the FTP client function on the OMU. The SET FTPSCLT
command takes effect on all FTP clients.
After SSL encrypted transmission is configured for an FTP client, the FTP server must also be configured
with SSL encrypted transmission before running FTP-related MML commands. Otherwise, the MML
commands fail to be executed.
If the Support SSL Certificate Authentication(BSC6900,BSC6910) parameter is set to YES(Yes), a
digital certificate must be configured for the connected server. Otherwise, file upload and download fail.
For instructions on how to configure digital certificates when the U2000 functions as the FTP server, choose
Security Management > Data Management > Configuring Digital Certificates > Importing Cross
Digital Certificates > Installing a Device Digital Certificate > Activating a Device Digital
Certificate > Follow-up Procedure in the U2000 online help.
You can run the LST FTPSCLT command to query the transmission encryption mode of FTP clients.
l To configure the FTP server to use encrypted transmission, perform the following steps:
Step 1 Run the SET FTPSSRV command with Transport Encrypted Mode set to ENCRYPTED
(SSL Encrypted).
NOTE
If the FTP server is configured with the SSL encrypted transmission mode, the same mode must also be
configured for all FTP clients that access the FTP server. The detailed configuration method varies
depending on the third-party FTP client software.
Step 2 Reset the ftp_server module for the encrypted transmission mode to take effect.
1. Run the DSP OMU command to query the OMU mode. If only one result for Operational
state is displayed, the OMU works in standalone mode. If two results for Operational
state are displayed, the OMUs work in active/standby mode.
2. Run the RST OMUMODULE command to reset the ftp_server module on the active
OMU. In this step, set Module Name to ftp_server.
If the OMU works in standalone mode, the encrypted transmission mode takes effect after
you perform this step. If the OMU works in active/standby mode, go to 3.

SingleRAN
3. Run the RST OMUMODULE command to reset the ftp_server module on the standby
OMU. In this step, set Module Name to ftp_server.
----End
l To configure the port for transmitting data over FTP, perform the following step:
Run the SET FTPSSRV command to the value range of ports for transmitting data over
FTP. In this step, set Passive mode data port lower limit and Passive mode data port
upper limit to appropriate values.
NOTE
You can run the LST FTPSSRV command to query the encryption mode of the FTP server and the value
range of ports for transmitting data over FTP.
Using the CME

The transmission encryption mode for FTP clients can be configured using security policy level
configuration on the CME. For details, see the 4.2 Web Security.
N/A
4.4 User Data Anonymization

Wireless networks use the Hash algorithm to makes individual identification fields anonymous
in maintenance and commissioning data to protect individual privacy. For details, see User Data
Anonymization Feature Parameter Description.
4.5 Security Management of Configuration Files
4.5.1 When to Use Security Management of Configuration Files

You are advised to encrypt a configuration file in the following two scenarios:
l Offline transmission of a configuration file

l Online permanent storage of a configuration file
4.5.2 Deployment
Requirements
None
Data Preparation
Table 4-1 lists MML commands used for configuration file encryption.

SingleRAN
Table 4-1 MML commands used for configuration file encryption
MML Command Operation Parameter Description

Type
DLD BATCHFILE Import ENCRYPTMODE: Encryption mode of a

configuration file. This parameter has two values:
DLD CFGFILE Import UNENCRYPTED and PWD_ENCRYPTED. The
RUN BATCHFILE Import default value is PWD_ENCRYPTED.
FILEPWD: Password used for encrypting a
RTR DB Import configuration file. The value consists of 6 to 32 digits.
BKP CFGFILE Export
ULD CBCFGFILE Export
BKP DB Export
EXP CFGMML Export
EXP CFGBCP Export
Activation
MML Configurations
On the WebLMT, run an MML command listed in Table 4-1 to encrypt a configuration file.
GUI Configurations (on theU2000, CME, and Web LMT)

To enable configuration file encryption, perform the following steps on the U2000, CME, or
WebLMT:
l On the U2000, select the encryption option on the window for manual or automatic data
backup.
l Select the encryption option when the CME is generating a configuration file.
l On the Web LMT, browse and activate the encrypted configuration file.
l When a configuration file is exported, check whether the configuration file is encrypted by
observing the file name extension. If a configuration file is encrypted, the file name is
suffixed with .ecf. For example, the file name changes from NodeB.xml to NodeB.xml.ecf
after encryption.
l When an encrypted configuration file is imported, you can execute or browse the original
configuration file after entering the correct password.
4.6 Digital Signature-based Software Integrity Protection

This function is always enabled and is not configurable.

SingleRAN
4.7 Time Security

Correct time synchronization guarantees normal operation of O&M systems. A standalone NTP
server needs to be configured and wireless NEs function as NTP clients. NTP security ensures
correct time synchronization. The NTP server is generally configured by operators and therefore
the NTP security policies on wireless NEs are configured based on the interworking requirements
of the NTP server.
4.7.1 When to Use Time Security

N/A
4.7.2 Deployment of SNTP Security for the Base Station

Controller/eCoordinator
Requirements
Parameters related to time synchronization are configured on the NTP server.
Activation
To configure the SNTP security for the base station controller/eCoordinator, perform the
following step:
Step 1 Run the ADD SNTPSRVINFO command to add the IP address and port number for the SNTP
server on the base station controller/eCoordinator and set the SNTP time synchronization
security policy.
----End
NOTE
Set Key ID, Encryption Algorithm, and Key if SNTP security is used. Based on the values of these
parameters, the base station controller/eCoordinator sends encrypted and authenticated time
synchronization requests to the SNTP server and authenticates the time synchronization responses from
the SNTP server.
You can run the LST SNTPCLTPARA command to query information about the SNTP server.
NTP security is activated if the NTP parameters are correctly configured and NTP link status is
normal.
4.7.3 Deployment of NTP Security Authentication for the Base

Station
Requirements
Parameters related to time synchronization are configured on the NTP server.

SingleRAN
Data Preparation
Table 4-2 describes key parameters that must be set in the NTPCP MO to activate NTP security
authentication.
Table 4-2 Data to prepare before activating NTP security authentication
MO Parameter Parameter Setting Notes Data Source

Name ID
NTPCP IPv4 Address IP This parameter specifies the Network plan

of NTP Server IPv4 address of the NTP (negotiation
server. not required)
Port Number PORT This parameter specifies the Network plan

number of the time (negotiation
synchronization port on the not required)
NTP server. The NTP client
synchronizes with the NTP
server through the specified
port.
Synchronizati SYNCCYCL This parameter specifies the Network plan

on Period E NTP time synchronization (negotiation
interval. not required)
Authenticatio AUTHMOD This parameter specifies the Network plan

n Mode E NTP authentication mode. (negotiation
not required)
Authenticatio KEY This parameter specifies the Network plan

n Key key used for NTP (negotiation
authentication. not required)
Authenticatio KEYID This parameter specifies the Network plan

n Key Index index of the authentication key (negotiation
on the NTP server. The local not required)
index must be the same as that
on the NTP server.
Activation
Using MML Commands

Step 1 Run the ADD NTPC command to configure an NTP client on a base station.
----End
MML Command Examples

//Configuring an NTP client
ADD NTPC: MODE=IPV4, IP="192.168.88.168", PORT=123, SYNCCYCLE=10, AUTHMODE=PLAIN;

SingleRAN
Using the CME
Using the CME to Perform Single Configuration

On the CME, set the parameters listed in the "Data Preparation" section for a single base station.
For detailed instructions, see CME Single Configuration Operation Guide.
Using the CME to Perform Batch Configuration for Newly Deployed Base Stations
Enter the values of the parameters listed in Table 4-3 in a summary data file, which also contains
other data for the new base stations to be deployed. Then, import the summary data file into the
CME for batch configuration.
The summary data file may be a scenario-specific file provided by the CME or a customized
file, depending on the following conditions:
l The MO in Table 4-3 is contained in a scenario-specific summary data file. In this situation,
set the parameters in the MOs, and then verify and save the file.
l The MO in Table 4-3 is not contained in a scenario-specific summary data file. In this
situation, customize a summary data file to include the MO before you can set the
parameters.
Table 4-3 MO related to NTP security
MO Sheet in the Parameter Group Remarks

Summary Data
File
NTP Common Data For details, see -

Data Preparation.
For instructions about how to perform batch configuration for each type of base stations, see the
following sections in 3900 Series Base Station Initial Configuration Guide.
l For a NodeB, see "Creating NodeBs in Batches."

l For an eNodeB, see "Creating eNodeBs in Batches."
l For a separate-MPT multimode base station, see "Creating Separate-MPT Multimode Base
Stations in Batches."
l For an eGBTS and a co-MPT multimode base station, see "Creating Co-MPT Base Stations
in Batches."
Using the CME to Perform Batch Configuration for Existing Base Stations
Batch reconfiguration using the CME is the recommended method to activate a feature on
existing base stations. This method reconfigures all data, except neighbor relationships, for
multiple base stations in a single procedure. The procedure is as follows:
Step 1 After creating a planned data area, choose CME > Advanced > Customize Summary Data
File (U2000 client mode), or choose Advanced > Customize Summary Data File (CME client
mode), to customize a summary data file for batch reconfiguration.

SingleRAN
NOTE
For context-sensitive help on a current task in the client, press F1.
Step 2 Export the base station data stored on the CME into the customized summary data file.
l For co-MPT multimode base stations: Choose CME > SRAN Application > MBTS
Application > Export Data > Export Base Station Bulk Configuration Data (U2000
client mode), or choose SRAN Application > MBTS Application > Export Data > Export
Base Station Bulk Configuration Data (CME client mode).
l For separate-MPT GSM-involved multimode base stations or GO base stations: Choose
CME > GSM Application > Export Data > Export eGBTS Bulk Configuration Data
(U2000 client mode), or choose GSM Application > Export Data > Export eGBTS Bulk
Configuration Data (CME client mode).
l For separate-MPT UMTS-involved multimode base stations or UO base stations: Choose
CME > UMTS Application > Export Data > Export Base Station Bulk Configuration
Data (U2000 client mode), or choose UMTS Application > Export Data > Export Base
Station Bulk Configuration Data (CME client mode).
l For separate-MPT LTE-involved multimode base stations or LO base stations: Choose
CME > LTE Application > Export Data > Export Base Station Bulk Configuration Data
(U2000 client mode), or choose LTE Application > Export Data > Export Base Station
Bulk Configuration Data (CME client mode).
Step 3 In the summary data file, set the parameters in the MOs listed in Table 4-3 and close the file.
Step 4 Import the summary data file into the CME

l For co-MPT multimode base stations: Choose CME > SRAN Application > MBTS
Application > Import Data > Import Base Station Bulk Configuration Data (U2000
client mode), or choose SRAN Application > MBTS Application > Import Data > Import
Base Station Bulk Configuration Data (CME client mode).
l For separate-MPT GSM-involved multimode base stations or GO base stations: Choose
CME > GSM Application > Import Data > Import eGBTS Bulk Configuration Data
(U2000 client mode), or choose GSM Application > Import Data > Import eGBTS Bulk
Configuration Data (CME client mode).
l For separate-MPT UMTS-involved multimode base stations or UO base stations: Choose
CME > UMTS Application > Import Data > Import Base Station Bulk Configuration
Data (U2000 client mode), or choose UMTS Application > Import Data > Import Base
l For separate-MPT LTE-involved multimode base stations or LO base stations: Choose
CME > LTE Application > Import Data > Import Base Station Bulk Configuration
Data (U2000 client mode), or choose LTE Application > Import Data > Import Base
----End
To verify that NTP security authentication is activated on a base station, perform the following
steps:

SingleRAN
Step 1 Run the LST NTPC command to query the NTP configuration information. Verify that the
parameter settings in the command output are consistent with that configured in the activation
procedure.
Step 2 Run the DSP NTPC command to query the time synchronization information of the base station.
Verify that the value of Link State of Current NTP Server is Available in the command output.
Step 3 Run the LST LATESTSUCCDATE command to query the latest successful time
synchronization of the base station. Verify that the value of Latest Successful Synchronization
Time is the same as the time that time synchronization was recently performed.
----End
If all the preceding verifications are true, NTP security authentication is activated.
Reconfiguration
To change the authentication mode for a base station, run the MOD NTPC command and change
the encryption algorithm on the NTP server to be consistent as that on the base station.
Deactivation
N/A
4.8 Security Alarms, Events, and Logs

Security alarms, events, and logs are always enabled and do not involve engineering guidelines.
4.9 OMU Anti-attack
4.9.1 When to Use OMU Anti-Attack

OMU anti-attack is supported by base station controllers but not base stations and
eCoordinators. The IPTable function of the OS is used to implement OMU anti-attack.
Configuring the whitelist and blacklist for the IPTable function has high risks. To ensure the
normal operation of a base station controller, do not configure the whitelist or blacklist if the
network runs properly.
4.9.2 Required Information

Collect the IP address and port data of the OMU and any peer NE that exchanges service data
with the OMU.
4.9.3 Deployment
Requirements
None

SingleRAN
Activation
Step 1 Log in to the OMU locally or remotely using PuTTY.
Step 2 Run the DOPRA Linux command iptables -A INPUT -s restricted IP -i Ethernet adapter -p
transport protocol --dport restricted port -j DROP. In this step, set parameters as follows:
----End
l Set restricted IP to an IP address to be denied or allowed access. The IP address can be a

single IP address or IP addresses in a network segment.
l Set Ethernet adapter to the external network adapter of the OMU.
l Set transport protocol to TCP or UDP. This parameter is used with restricted port.
l Set restricted port to the port over which access is denied.
If you do not specify the -p transport protocol and --dport restricted port parameters, access
over all ports is denied.
The following is a command example used to allow only users in the 10.141.148.0 network
segment to access the WebLMT:
iptables -A INPUT -s ! 10.141.148.0/255.255.255.0 -i bond1 -p tcp --dport 80 -j DROP
NOTE
"!" is a logical negation operator.
----End
Step 1 Log in to the PC whose IP address has been restricted.
Step 2 Run the DOPRA Linux command iptables –L to query all filtering criteria on the OMU. Verify
that the new criteria have been added successfully.
l If access over port 80 is denied, you cannot access the WebLMT. In this situation, check
whether you can access the WebLMT on the PC.
l If access over port 22 is denied, you cannot log in to the OMU remotely. In this situation,
check whether you can log in to the OMU using PuTTY on the PC.
NOTE
Execute caution when disabling port 22, because this operation prohibits users from remotely logging in
to the OMU.
l If access over port 21 is denied, you cannot access the ftp_server module on the OMU. In
this situation, check whether you can access the ftp_server module on the OMU using an
FTP client on the PC.
----End
Deactivation
Step 1 Log in to the OMU locally or remotely using PuTTY.
Step 2 Run the DOPRA Linux command iptables -D INPUT -s restricted IP -i Ethernet adapter -p
transport protocol --dport restricted port -j DROP. In this step, set parameters as follows:

SingleRAN
l Set restricted IP to an IP address to be denied or allowed access. The IP address can be a

single IP address or IP addresses in a network segment.
l Set Ethernet adapter to the external network adapter of the OMU.
l Set transport protocol to TCP or UDP. This parameter is used with restricted port.
l Set restricted port to the port over which access is denied.
If you do not specify the -p transport protocol and --dport restricted port parameters, access
over all ports is denied.
Step 3 Run the DOPRA Linux command iptables –L to query all filtering criteria on the OMU. Verify
that the new criteria have been removed successfully.
----End
The following command example is used to deactivate OMU anti-attack.

iptables -D INPUT -s ! 10.141.148.0/255.255.255.0 -i bond1 -p tcp --dport 80 -j DROP
4.10 Security Policy Level Configuration

This function is configured using batch configuration management of common security policies
on the CME. Therefore, no engineering guidelines are involved.

SingleRAN
OM Security Feature Parameter Description 5 Parameters
5 Parameters
Table 5-1 Parameters
Parame NE MML Feature Feature Description

ter ID Comma ID Name
nd
ONLYO BTS390 SET None None Meaning: Indicates whether to enable the security
MIP 0, OMCO policy of accessing the NE by using the maintenance IP
BTS390 NNPOL addresses (OMCH IP and LOCAL IP) only. This
0 ICY parameter does not take effect when OMCH IP is not
WCDM DSP configured.
A, OMCO GUI Value Range: DISABLE(DISABLE), ENABLE
BTS390 NNPOL (ENABLE)
0 LTE ICY Unit: None
LST Actual Value Range: DISABLE, ENABLE
OMCO
NNPOL Default Value: ENABLE(ENABLE)
ICY
PwdMin BSC690 SET None None Meaning: Minimum length of an LMT login password.
Len 0 PWDPO When a password is shorter than this length, the
LICY password is invalid.
GUI Value Range: 6~32
Unit: None
Actual Value Range: 6~32
Default Value: 8
PwdMin BSC691 SET None None Meaning: Minimum length of an LMT login password.
Len 0 PWDPO When a password is shorter than this length, the
LICY password is invalid.
Unit: None
Default Value: 8

SingleRAN

nd
Complic BSC690 SET None None Meaning: Complexity of a password. LOWERCASE

acy 0 PWDPO (Lowercase) indicates that the password must include
LICY lowercase letters. UPPERCASE(Uppercase) indicates
that the password must include uppercase letters. DIGIT
(Digit) indicates that the password must include digits.
SPECHAR(Special character) indicates that the
password must include special characters. Special
characters are ~!@#$%^&*()_+-{}|[]:<>?./.
GUI Value Range: LOWERCASE(Lowercase),
UPPERCASE(Uppercase), DIGIT(Digit), SPECHAR
(Special character)
Unit: None
Actual Value Range: LOWERCASE, UPPERCASE,
DIGIT, SPECHAR
Default Value: LOWERCASE:1,UPPERCASE:
1,DIGIT:1,SPECHAR:0
Complic BSC691 SET None None Meaning: Complexity of a password. LOWERCASE

acy 0 PWDPO (Lowercase) indicates that the password must include
LICY lowercase letters. UPPERCASE(Uppercase) indicates
that the password must include uppercase letters. DIGIT
(Digit) indicates that the password must include digits.
SPECHAR(Special character) indicates that the
password must include special characters. Special
characters are ~!@#$%^&*()_+-{}|[]:<>?./.
GUI Value Range: LOWERCASE(Lowercase),
UPPERCASE(Uppercase), DIGIT(Digit), SPECHAR
(Special character)
Unit: None
Actual Value Range: LOWERCASE, UPPERCASE,
DIGIT, SPECHAR
Default Value: LOWERCASE:1,UPPERCASE:
1,DIGIT:1,SPECHAR:0
MaxRep BSC690 SET None None Meaning: Maximum number of single character repeats
eatChar 0 PWDPO allowed in an LMT login password. When a single
Times LICY character in a password repeats for more times than this
number, the password is invalid.
Unit: None
Default Value: 2

SingleRAN

nd
MaxRep BSC691 SET None None Meaning: Maximum number of single character repeats
eatChar 0 PWDPO allowed in an LMT login password. When a single
Times LICY character in a password repeats for more times than this
number, the password is invalid.
Unit: None
Default Value: 2
MAXV BSC690 SET None None Meaning: Days between the day when a password takes
ALIDD 0 PWDPO effect and the day when the password expires. The
ATES LICY password becomes invalid after being valid for the days.
Unit: day
Default Value: 90
MAXV BSC691 SET None None Meaning: Days between the day when a password takes
ALIDD 0 PWDPO effect and the day when the password expires. The
ATES LICY password becomes invalid after being valid for the days.
Unit: day
Default Value: 90
MaxMis BSC690 SET None None Meaning: Maximum number of password retries when
sTimes 0 PWDPO a user logs in. When password retries by a user exceed
LICY this number, this user is locked.
Unit: None
Default Value: 3
MaxMis BSC691 SET None None Meaning: Maximum number of password retries when
sTimes 0 PWDPO a user logs in. When password retries by a user exceed
LICY this number, this user is locked.
Unit: None
Default Value: 3

SingleRAN

nd
MAXPR BSC690 SET None None Meaning: Longest days for which users are prompted in
OMPTD 0 PWDPO advance to notice that the password is going to expire.
ATES LICY When this day arrives, users will be prompted with the
remaining days.
Unit: day
Default Value: 5
MAXPR BSC691 SET None None Meaning: Longest days for which users are prompted in
OMPTD 0 PWDPO advance to notice that the password is going to expire.
ATES LICY When this day arrives, users will be prompted with the
remaining days.
Unit: day
Default Value: 5
HISTO BSC690 SET None None Meaning: Maximum number of historical passwords
RYPW 0 PWDPO that can be saved. When this number is reached, the
DNUM LICY earliest historical password will be deleted at the arrival
of a new one.
Unit: None
Default Value: 5
HISTO BSC691 SET None None Meaning: Maximum number of historical passwords
RYPW 0 PWDPO that can be saved. When this number is reached, the
DNUM LICY earliest historical password will be deleted at the arrival
of a new one.
Unit: None
Default Value: 5
FirstLog BSC690 SET None None Meaning: Switch for forcing users to change the
inMust 0 PWDPO password upon their first login to the LMT.
ModPW LICY GUI Value Range: OFF(Close), ON(Open)
D
Unit: None
Actual Value Range: ON, OFF
Default Value: OFF(Close)

SingleRAN

nd
FirstLog BSC691 SET None None Meaning: Switch for forcing users to change the
inMust 0 PWDPO password upon their first login to the LMT.
ModPW LICY GUI Value Range: OFF(Close), ON(Open)
D
Unit: None
DICTC BSC690 SET None None Meaning: Switch for checking whether the password is
HKSW 0 PWDPO in the weak password dictionary when users add or
LICY modify user's password. Weak passwords are inlcuded
in the weak password dictionary. After this switch is
turned on, you must not use common words or
combinations of simple letters and digits as passwords,
such as 111111, aaaaaa, abc123, linda, and snoopy.
GUI Value Range: OFF(Close), ON(Open)
Unit: None
DICTC BSC691 SET None None Meaning: Switch for checking whether the password is
HKSW 0 PWDPO in the weak password dictionary when users add or
LICY modify user's password. Weak passwords are inlcuded
in the weak password dictionary. After this switch is
turned on, you must not use common words or
combinations of simple letters and digits as passwords,
such as 111111, aaaaaa, abc123, linda, and snoopy.
GUI Value Range: OFF(Close), ON(Open)
Unit: None

SingleRAN

nd
MAXMI BTS390 SET None None Meaning:

SSTIME 0, PWDPO Indicates the maximum times of attempts with
S BTS390 LICY incorrectly entered passwords. The default value of this
0 LST parameter is 3. If the times of attempts with incorrectly
WCDM PWDPO entered passwords reached this parameter,the NE will
A, LICY lock the operator account.
BTS390
0 LTE User passwords comply with this policy as follows:
Local users' passwords must comply with this policy.
NMS users' passwords (emscomm or emscommneteco

user) do not comply with this policy.
WiFi users' passwords do not comply with this policy.

Unit: None
Default Value: 3
AutoUnl BSC690 SET None None Meaning: Duration after which a locked user is
ockTime 0 PWDPO unlocked automatically.
LICY GUI Value Range: 1~65535
Unit: min
Default Value: 30
AutoUnl BSC691 SET None None Meaning: Duration after which a locked user is
ockTime 0 PWDPO unlocked automatically.
LICY GUI Value Range: 1~65535
Unit: min
Default Value: 30

SingleRAN

nd
AUTOU BTS390 SET None None Meaning:

NLOCK 0, PWDPO Indicates the time that needs to elapse for an account to
TIME BTS390 LICY be unlocked after it is locked due to incorrect password
0 LST inputs. The default value of this parameter is 30.
WCDM PWDPO
A, LICY User passwords comply with this policy as follows:
BTS390
Local users' passwords must comply with this policy.
0 LTE
NMS users' passwords (emscomm or emscommneteco
user) do not comply with this policy.
WiFi users' passwords do not comply with this policy.

Unit: min
Default Value: 30
AUTH BSC690 ADD None None Meaning: Authentication mode used when the active
MODE 0 SNTPS OMU (NTP client) synchronizes with the NTP server.
RVINF GUI Value Range: PLAIN(PLAIN), NTPV3(NTPV3)
O
Unit: None
Actual Value Range: PLAIN, NTPV3
Default Value: PLAIN(PLAIN)
AUTH BSC691 ADD None None Meaning: Authentication mode used when the active
MODE 0 SNTPS OMU (NTP client) synchronizes with the NTP server.
RVINF GUI Value Range: PLAIN(PLAIN), NTPV3(NTPV3)
O
Unit: None
Actual Value Range: PLAIN, NTPV3
Default Value: PLAIN(PLAIN)
AUTH BTS390 ADD None None Meaning: Indicates the encryption mode. If this
MODE 0, NTPC parameter is set to PLAIN, data is transmitted in
BTS390 MOD plaintext.
0 NTPC GUI Value Range: PLAIN(Plain), DES_S(DES_S),
WCDM DES_N(DES_N), DES_A(DES_A), MD5(MD5)
A, LST
BTS390 NTPC Unit: None
0 LTE Actual Value Range: PLAIN, DES_S, DES_N, DES_A,
MD5
Default Value: PLAIN(Plain)

SingleRAN

nd
KEY BTS390 ADD None None Meaning:

0, NTPC Indicates the key used for NTP authentication.
BTS390 MOD
0 NTPC This key must be consistent with that on the server.
WCDM
LST The key used in the DES_S algorithm is a hexadecimal
A,
NTPC number whose length is 64 bits in binary format. The
BTS390
seven least significant bits of each byte are used to
0 LTE
construct 56-bit key data, and the eighth bit is the odd
parity bit for each byte. Any empty bit is filled with 0
to ensure that the key data is composed of 16
hexadecimal digits and has an odd number for parity
check. The key used in the DES_N algorithm is similar
to the key used in the DES_S algorithm. The only
difference is that in the key used in the DES_N
algorithm, the most significant bit is used for parity
check of each byte. The key used in the DES_A
algorithm is an ASCII string of one to eight characters.
The seven least significant digits of the ASCII value
corresponding to each character are used to construct
56-bit key data. For any ASCII string of less than eight
characters, 0s are appended to the string to ensure that
the key data is composed of 56 bits. The key used in the
MD5 algorithm is an encrypted ASCII string of one to
eight characters.
GUI Value Range: 1~16 characters
Unit: None
Actual Value Range: 1~16 characters
Default Value: None
KEYID BTS390 ADD None None Meaning: Indicates the server-side index of the NTP
0, NTPC authentication key. The index must be the same as the
BTS390 MOD setting on the server.
0 NTPC GUI Value Range: 1~4294967295
WCDM
A, LST Unit: None
BTS390 NTPC Actual Value Range: 1~4294967295
0 LTE Default Value: None

SingleRAN

nd
IP BTS390 ADD None None Meaning: Indicates the IPv4 address of the NTP server.
0, NTPC GUI Value Range: Valid IP address
BTS390 MOD
0 Unit: None
NTPC
WCDM Actual Value Range: Valid IP address
A, RMV
NTPC Default Value: 0.0.0.0
BTS390
0 LTE SET
MASTE
RNTPS
PORT BTS390 ADD None None Meaning: Indicates the port number of the NTP server.
0, NTPC An NTP client performs time calibration with the NTP
BTS390 MOD server through the port specified by this parameter.
0 NTPC GUI Value Range: 123~5999,6100~65534
WCDM
A, LST Unit: None
BTS390 NTPC Actual Value Range: 123~5999,6100~65534
0 LTE Default Value: 123
SYNCC BTS390 ADD None None Meaning:

YCLE 0, NTPC Indicates the period based on which NTP time
BTS390 MOD synchronization is performed periodically. The switch
0 NTPC for periodic NTP time synchronization is turned on
WCDM automatically.The time of a base station may have
A, LST
NTPC differences with the standard time, and a large
BTS390 difference affects the accuracy of KPIs. Therefore, a
0 LTE period must be configured for the base station to
perform time synchronization with the NTP server
periodically to ensure the accurate time.
The period for periodic NTP time synchronization must

be configured based on the NTP server performance,
transport network quality, and base station quantity.
A smaller period for periodic NTP time synchronization

leads to higher loads for the NTP server and transport
network. A larger period leads to lower loads.
Unit: min
Default Value: None

SingleRAN
OM Security Feature Parameter Description 6 Counters
6 Counters
There are no specific counters associated with this feature.

SingleRAN
OM Security Feature Parameter Description 7 Glossary
7 Glossary
For the acronyms, abbreviations, terms, and definitions, see Glossary.

SingleRAN
OM Security Feature Parameter Description 8 Reference Documents
8 Reference Documents
1. GBTS Equipment and OM Security Feature Parameter Description for GSM BSS
2. SSL Feature Parameter Description for SingleRAN
3. User Data Anonymization Feature Parameter Description for SingleRAN


OM Security (SRAN10.1 02)

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

OM Security (SRAN10.1 02)

Caricato da

Copyright:

Formati disponibili

SingleRAN

OM Security Feature Parameter

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 02 (2015-05-15) Huawei Proprietary and Confidential i

1 About This Document..................................................................................................................1

Issue 02 (2015-05-15) Huawei Proprietary and Confidential ii

Issue 02 (2015-05-15) Huawei Proprietary and Confidential iii

1 About This Document

This document covers the following features:

l MRFD-210305 Security Management

Table 1-1 defines all types of base stations.

Table 1-1 Base station definition

Base Station Name Definition

GBTS GBTS refers to a base station deployed with GTMU and

eGBTS eGBTS refers to a base station deployed with GTMUb, UMPT_G,

NodeB NodeB refers to a base station deployed with WMPT, UMPT_U

eNodeB eNodeB refers to a base station deployed with LMPT, UMPT_L,

Issue 02 (2015-05-15) Huawei Proprietary and Confidential 1

Base Station Name Definition

Separate-MPT Separate-MPT multimode base station refers to a base station on

1.2 Intended Audience

l Need to understand the features described herein

1.3 Change History

Issue 02 (2015-05-15) Huawei Proprietary and Confidential 2

Change Change Description Parameter Change

Feature Added the description of management plane IP Added the parameter

Editorial None None

SRAN10.1 Draft A (2015-01-15)

Change Change Description Parameter Change

Added descriptions about the eCoordinator. None

Enhanced user login security. For details, see None

Added the management function on the number None

Added the protection of sensitive personal data. None

Editorial Incorporated the descriptions about O&M None

Optimized descriptions about user rights control. None

Issue 02 (2015-05-15) Huawei Proprietary and Confidential 3

Change Change Description Parameter Change

Optimized descriptions about southbound None

1.4 Differences Between Base Station Types

The following table defines the types of micro base stations.

Base Station Model RAT

BTS3202E LTE FDD

Feature Support by Macro, Micro, and LampSite Base Stations

Function Implementation in Macro, Micro, and LampSite Base Stations

Issue 02 (2015-05-15) Huawei Proprietary and Confidential 4

Table 2-1 Supported security measures

Security Measures MBSC eCoord eGBTS NodeB eNode MBT

User data anonymization √ √ √ √ √ √

Security alarms, events, √ √ √ √ √ √

Security policy level √ √ x √ √ √

Issue 02 (2015-05-15) Huawei Proprietary and Confidential 5

Issue 02 (2015-05-15) Huawei Proprietary and Confidential 6

3.1 OMCH Security

3.1.1 SSL-Encrypted Transmission

Figure 3-1 SSL-encrypted transmission

Issue 02 (2015-05-15) Huawei Proprietary and Confidential 7

For details about SSL, see SSL Feature Parameter Description.

3.1.2 Management Plane IP Address Isolation

3.2 Web Security

Issue 02 (2015-05-15) Huawei Proprietary and Confidential 8

l HTTPS-based Data Transmission