Вы находитесь на странице: 1из 110

SingleRAN

Equipment Security Feature Parameter Description

Issue

02

Date

2016-09-30

HUAWEI TECHNOLOGIES CO., LTD.

SingleRAN Equipment Security Feature Parameter Description Issue 02 Date 2016-09-30 HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2016. 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:

Email:

support@huawei.com

SingleRAN Equipment 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

1.5

Functional Differences Between NB-IoT and FDD

.......................................................................................................

5

2

Overview

.........................................................................................................................................

6

3

Technical Description

...................................................................................................................

7

3.1

Physical Security

............................................................................................................................................................

7

3.2

OS Security

.....................................................................................................................................................................

7

3.2.1

OS Hardening

..............................................................................................................................................................

8

3.2.2

OS Patches

...................................................................................................................................................................

9

3.2.3

Antivirus Software

9 .......................................................................................................................................................

3.3

Trusted Environment

....................................................................................................................................................

10

3.3.1

Secure Startup

............................................................................................................................................................

10

3.3.2

Secure Storage

...........................................................................................................................................................

10

3.4

Self-check Upon Startup

...............................................................................................................................................

10

3.5

Process Auditing

...........................................................................................................................................................

11

3.6

Key File Integrity Monitoring

.......................................................................................................................................

11

3.7

Integrated Firewall

........................................................................................................................................................

12

3.7.1

ACL-based Packet Filtering

......................................................................................................................................

12

  • 3.7.1.1 Base Station

............................................................................................................................................................

12

  • 3.7.1.2 Base Station Controller/eCoordinator

....................................................................................................................

14

 

3.7.2

Automatic ACL Rule Configuration

.........................................................................................................................

14

  • 3.7.2.1 Automatic Configuration Mechanism ....................................................................................................................

15

  • 3.7.2.2 Restriction on Application Scenarios

.....................................................................................................................

15

  • 3.7.2.3 Automatically Configured ACL Rule Group

.........................................................................................................

16

  • 3.7.2.4 Automatic ACL Rule Configuration for FTP Packets

............................................................................................

21

  • 3.7.2.5 ACL Rule ID Ranges

..............................................................................................................................................

22

 

3.7.3

Network Attack Prevention

.......................................................................................................................................

22

  • 3.7.3.1 Rate Limitation on Broadcast Packets

....................................................................................................................

23

  • 3.7.3.2 ICMP Flood Attack Prevention

..............................................................................................................................

23

SingleRAN Equipment Security Feature Parameter Description

Contents

  • 3.7.3.3 ARP Flood Attack Prevention

................................................................................................................................

24

  • 3.7.3.4 ARP Spoofing Prevention

......................................................................................................................................

25

  • 3.7.3.5 Smurf Attack Prevention

........................................................................................................................................

26

  • 3.7.3.6 Illegal Packet Attack Prevention

............................................................................................................................

26

3.8

Physical Port Security

...................................................................................................................................................

27

  • 3.8.1 Physical Port Security For the Base Station Controller

.............................................................................................

28

  • 3.8.2 Physical Port Security for the eCoordinator

..............................................................................................................

33

  • 3.8.3 Physical Port Security for the Base Station

...............................................................................................................

36

  • 3.8.4 Port Mirroring Security

.............................................................................................................................................

38

  • 3.8.5 Secure USB Flash Drive

............................................................................................................................................

38

  • 4 Related Features

...........................................................................................................................

40

  • 4.1 Features Related to MRFD-210102 Operate System Security Management

...............................................................

40

  • 4.2 Features Related to MRFD-210305 Security Management

.........................................................................................

40

  • 4.3 Features Related to LBFD-004010 Security Management

...........................................................................................

41

  • 4.4 Features Related to LOFD-003014 Integrated Firewall

...............................................................................................

41

  • 4.5 Features Related to LOFD-00301401 Access Control List (ACL)

..............................................................................

41

  • 4.6 Features Related to LOFD-00301402 Access Control List (ACL) Auto Configuration

..............................................

42

  • 4.7 Features Related to MLOFD-003014 Integrated Firewall

............................................................................................

42

  • 4.8 Features Related to MLOFD-00301401 Access Control List (ACL)

...........................................................................

42

  • 4.9 Features Related to MOFD-00301402 Access Control List (ACL) Auto Configuration

.............................................

43

  • 4.10 Features Related to TDLBFD-004010 Security Management

...................................................................................

43

  • 4.11 Features Related to TDLOFD-003014 Integrated Firewall

........................................................................................

43

  • 4.12 Features Related to TDLOFD-00301401 Access Control List (ACL)

.......................................................................

44

  • 4.13 Features Related to TDLOFD-00301402 Access Control List (ACL) autogeneration

..............................................

44

  • 5 Network Impact

...........................................................................................................................

45

  • 6 Engineering Guidelines

.............................................................................................................

46

6.1

Integrated Firewall

........................................................................................................................................................

47

  • 6.1.1 Required Information

................................................................................................................................................

47

  • 6.1.2 Deployment for the Base Station Controller/eCoordinator

.......................................................................................

47

  • 6.1.2.1 Requirements ..........................................................................................................................................................

47

Data Preparation

  • 6.1.2.2 .....................................................................................................................................................

47

Activation

  • 6.1.2.3 ...............................................................................................................................................................

51

  • 6.1.2.3.1 Using MML Commands

......................................................................................................................................

52

  • 6.1.2.3.2 MML Command Examples

.................................................................................................................................

52

  • 6.1.2.4 Activation Observation

...........................................................................................................................................

53

  • 6.1.2.5 Deactivation

............................................................................................................................................................

54

  • 6.1.2.5.1 Using MML Commands

......................................................................................................................................

54

  • 6.1.2.5.2 MML Command Examples

.................................................................................................................................

54

6.1.3

Deployment for Base Stations

...................................................................................................................................

54

  • 6.1.3.1 Required Information

.............................................................................................................................................

54

  • 6.1.3.2 Requirements

..........................................................................................................................................................

55

SingleRAN Equipment Security Feature Parameter Description

Contents

Data Preparation

  • 6.1.3.3 .....................................................................................................................................................

56

Activation

  • 6.1.3.4 ...............................................................................................................................................................

64

  • 6.1.3.4.1 Using the CME

....................................................................................................................................................

64

  • 6.1.3.4.2 Using MML Commands

......................................................................................................................................

65

  • 6.1.3.4.3 MML Command Examples

.................................................................................................................................

66

  • 6.1.3.5 Activation Observation

...........................................................................................................................................

67

  • 6.1.3.6 Deactivation

............................................................................................................................................................

68

  • 6.1.3.6.1 Using MML Commands

......................................................................................................................................

68

  • 6.1.3.6.2 MML Command Examples

.................................................................................................................................

69

6.2 Physical Port Security

...................................................................................................................................................

70

  • 6.2.1 When to Use Physical Port Security

..........................................................................................................................

70

Data Preparation

  • 6.2.2 ........................................................................................................................................................

70

Activation

  • 6.2.3 ..................................................................................................................................................................

72

  • 6.2.3.1 Using the CME

.......................................................................................................................................................

73

  • 6.2.3.2 Using MML Commands

.........................................................................................................................................

73

  • 6.2.3.3 MML Command Examples

....................................................................................................................................

73

  • 6.2.4 Activation Observation

..............................................................................................................................................

74

  • 6.2.5 Deactivation

...............................................................................................................................................................

74

  • 6.2.5.1 Using MML Commands

.........................................................................................................................................

74

  • 6.2.5.2 MML Command Examples

....................................................................................................................................

75

  • 7 .....................................................................................................................................

Parameters

76

  • 8 ......................................................................................................................................

Counters

103

Glossary

  • 9 .......................................................................................................................................

104

10 Reference Documents

.............................................................................................................

105

SingleRAN Equipment Security Feature Parameter Description

1 About This Document

1 About This Document

1.1 Scope

This document describes equipment security, including its technical descriptions, engineering guidelines, and parameters.

This document covers the following features:

  • l MRFD-210102 Operate System Security Management

  • l MRFD-210305 Security Management

  • l LBFD-004010 Security Management

  • l LOFD-003014 Integrated Firewall

  • l LOFD-00301401 Access Control List (ACL)

  • l LOFD-00301402 Access Control List (ACL) Auto Configuration

  • l MLOFD-003014 Integrated Firewall

  • l MLOFD-00301401 Access Control List (ACL)

  • l MLOFD-00301402 Access Control List (ACL) Auto Configuration

  • l TDLBFD-004010 Security Management

  • l TDLOFD-003014 Integrated Firewall

  • l TDLOFD-00301401 Access Control List (ACL)

  • l TDLOFD-00301402 Access Control List (ACL) autogeneration

This document applies only to LTE FDD and LTE NB-IoT. Any "LTE" in this document refers to LTE FDD or LTE NB-IoT, and "eNodeB" refers to LTE FDD eNodeB or LTE NB- IoT eNodeB.

Table 1-1 defines all types of base stations.

SingleRAN Equipment Security Feature Parameter Description

1 About This Document

Table 1-1 Base station definitions

Base Station

Definition

Name

GBTS

A base station configured with a GTMU, GTMUb, or GTMUc and maintained through a base station controller.

eGBTS

A base station configured with a GTMUb, GTMUc, UMPT_G, or UMDU_G and directly maintained by the element management system (EMS).

NodeB

A base station configured with a WMPT, UMPT_U, or UMDU_U.

eNodeB

A base station configured with an LMPT, UMPT_L, UMPT_T, UMDU_L, or UMDU_T.

Co-MPT

A base station configured with only one main control board, which is

NOTE

multimode base

the UMPT or UMDU. A co-MPT multimode base station consists of

station

two or more standards and it functionally corresponds to any physical

combination of GBTS, NodeB, and eNodeB. For example, a co-MPT multimode base station configured with a UMPT_GU or UMDU_GU functionally corresponds to the physical combination of eGBTS and NodeB.

Unless otherwise specified, the descriptions and examples of the UMPT in a co- MPT base station also apply to the UMDU in a co-MPT base station.

Separate-MPT

A base station on which each mode uses its separate main control board.

multimode base

For example, a base station configured with a GTMU and WMPT is

station

called a separate-MPT GSM/UMTS dual-mode base station.

NOTE

A UMDU cannot be used in a separate-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 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

SingleRAN Equipment Security Feature Parameter Description

1 About This Document

SRAN12.0 02 (2016-09-30)

This issue includes the following changes.

Change

Change Description

Paramete

Type

r Change

Feature

Added descriptions about NB-IoT. For details, see 1.1 Scope,

None

change

1.4 Differences Between Base Station Types, and 1.5 Functional Differences Between NB-IoT and FDD.

Added the following NB-IoT feature:

None

l

MLOFD-003014 Integrated Firewall

For details, see 4.7 Features Related to MLOFD-003014 Integrated Firewall and 6.1.3.2 Requirements.

Editorial

None

None

change

SRAN12.0 01 (2016-08-30)

This issue does not include any changes.

SRAN12.0 Draft A (2016-06-23)

Compared with Issue 01 (2016-02-29) of SRAN11.1, Draft A (2016-06-23) of SRAN12.0 includes the following changes.

Change

Change Description

Parameter Change

Type

Feature

Added restrictions on the peer IP address for

  • l STARTDATAPOR

change

automatically configured OMCH ACL rules to

T

improve security. For details, see 3.7.2.3

  • l ENDDATAPORT

Automatically Configured ACL Rule Group.

  • l OMPEERIPLIMI

TSW

Optimized automatic ACL rule configuration for FTP and DHCP. After the optimization, the frequency of updating automatically configured ACL rules for FTP and DHCP decreases, which reduces the impact on transmission efficiency. For details, see 3.7.2.3 Automatically Configured ACL Rule Group and 3.7.2.4 Automatic ACL Rule Configuration for FTP Packets.

None

Added the UBBPei board. For details, see 6.1.3.2 Requirements.

None

SingleRAN Equipment Security Feature Parameter Description

1 About This Document

Change

Change Description

Parameter Change

Type

Editorial

Optimized the organization and descriptions in

None

change

this document.

1.4 Differences Between Base Station Types

Definition

The macro base stations referenced in this document are the 3900 series base stations listed in the "Scope" section. These base stations may be configured to work in GSM, UMTS, or LTE mode.

The LampSite base stations referenced in this document are distributed base stations designed for indoor coverage. These base stations work in UMTS or LTE mode and do not work in GSM mode.

The micro base stations referenced in this document are all integrated entities that work in UMTS or LTE mode and do not work in GSM mode. Descriptions of boards, cabinets, subracks, slots, and RRUs do not apply to micro base stations.

The following table lists micro base station models.

Base Station Model

RAT

BTS3202E

LTE FDD

BTS3911E

UMTS+LTE FDD

NOTE

NOTE

The multimode micro base station BTS3911E is used in UMTS+LTE FDD co-MPT scenarios but not in separate-MPT scenarios.

Co-MPT and separate-MPT applications are not relevant to single-mode micro base stations.

Feature Support by Macro, Micro, and LampSite Base Stations

The features described in this document are implemented in the same way on macro, micro, and LampSite base stations. For NB-IoT, these features can be used only with macro base stations.

Function Implementation in Macro, Micro, and LampSite Base Stations

Function

Difference

Physical security

As integrated entities, micro base stations differ from macro base stations in physical security and port security.

SingleRAN Equipment Security Feature Parameter Description

1 About This Document

1.5 Functional Differences Between NB-IoT and FDD

There are no functional differences between NB-IoT and FDD.

SingleRAN Equipment Security Feature Parameter Description

2 Overview

2 Overview

Table 2-1 lists the equipment security measures supported by Huawei network elements (NEs).

Table 2-1 Supported security measures

Security Measures

MBS

eCoordi

eGB

Node

eNod

MBT

C

nator

TS

B

eB

S

Physical security

 

Operating

OS hardening

-

-

-

-

system (OS)

             

security

OS patches

-

-

-

-

Antivirus

-

-

-

-

software

Trusted environment

x

x

Self-check upon startup

x

x

Process auditing

 

x

x

Key file integrity monitoring

Integrated firewall

 

Physical port security

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.

NOTE

NOTE

In this document, MBSC is also called the base station controller, and eGBTS, NodeB, eNodeB and MBTS are collectively referred to as the base station.

For details about equipment security measures for the GBTS, see GBTS Equipment and OM Security Feature Parameter Description. For details about integrated firewall measures for the GBTS, see GBTS Integrated Firewall Feature Parameter Description.

SingleRAN Equipment Security Feature Parameter Description

3 Technical Description

3 Technical Description

  • 3.1 Physical Security

Physical security refers mainly to physical security measures.

  • l The following measures are taken to protect physical security of base station controllers and indoor macro base stations:

Base station controllers and indoor base stations are often located at equipment rooms with door locks to protect them against illegal intrusion.

Base station controllers and indoor macro base stations are housed in cabinets with locks and door status switches. Only authorized users can open the cabinet. Alarms are reported for unauthorized access to cabinets.

Environment monitoring units and sensors can be configured to detect the equipment room environment. When a threshold is reached, related alarms (such as water damage alarms and smoke alarms) are reported.

  • l Outdoor macro base stations are secured in cabinets with door locks.

  • l Micro base stations are highly integrated and secured with special screws. Therefore, they are hard to disassemble after being installed.

  • 3.2 OS Security

Base stations have integrated OSs that are reinforced before delivery. This section focuses on OS security of the base station controller and eCoordinator.

The OMU acts as the bridge to exchange information between the base station controller/ eCoordinator and the LMT/U2000. Table 3-1 describes the OSs and security measures supported by the OMUs of the base station controller/eCoordinator.

SingleRAN Equipment Security Feature Parameter Description

3 Technical Description

Table 3-1 OSs and security measures supported by the OMUs of the base station controller/ eCoordinator

Product

OS

Description

OS

OS

Antivirus

Model

Hardenin

Patch

Software

g

BSC6000

SUSE Linux

After a BSC6000 is upgraded to a BSC6900, the default OS is SUSE Linux.

x

BSC6810

Windows

After a BSC6810 is upgraded to a BSC6900, the default OS is Windows.

BSC6900

DOPRA

Supports only

-

BSC6910

Linux

DOPRA Linux.

Stand-

alone

ECO6910

Built-in

Euler Linux

After a BSC6910 is

-

ECO6910

upgraded to a BSC6910 having a built-in ECO6910, the OS must be upgraded to Euler Linux.

NOTE

NOTE

indicates supported. x indicates not supported. – indicates N/A.

For details about OS hardening for DOPRA Linux and Euler Linux, see Dopra Linux OS Security Feature Parameter Description and Euler Linux OS Security Feature Parameter Description, respectively of SingleRAN.

3.2.1 OS Hardening

OS software has security holes and potential risks, which may be exploited by local or remote attackers to impose security threats on the OS and related software, thereby affecting the normal operation of the OS.

Huawei provides OS hardening solutions. These solutions cover network access, network security, system service, and system installation to improve antivirus and anti-attack capabilities, system reliability, and the service quality of the entire network.

The OS hardening solutions include the following functions:

  • l Disabling unnecessary services

  • l Reinforcing Secure Shell (SSH) services

  • l Restricting access to files and directories

SingleRAN Equipment Security Feature Parameter Description

3 Technical Description

 

l

Authorizing system access

l

Managing user passwords

l

Recording operation logs

l

Detecting system malfunctions

Table 3-2 describes the security hardening solutions of different OSs:

Table 3-2 OS hardening solutions

OS

Security Hardening Solution

Windows

For details, see BSC6900 UMTS OMU Administration Guide or BSC6900

SUSE Linux

GSM OMU Administration Guide.

DOPRA

DOPRA Linux and Euler Linux are Huawei-developed OSs. They have

Linux

been reinforced before delivery and therefore do not require additional

Euler Linux

hardening.

  • 3.2.2 OS Patches

 
 

The latest Windows basic patch packages or Linux patch packages have been installed on the base station controller and the eCoordinator before delivery. The policies for releasing OS patches are as follows:

l

Windows OS patches are released twice a year.

l

DOPRA Linux/Euler Linux/SUSE Linux OS patches are released once a year.

NOTE

NOTE

 

For details about OS patches for a specific product version, see the corresponding release notes.

 

Users can obtain the latest patch packages by choosing Tools > Mini-tool Software > Wireless Product Line > Universal OS Patches at http://support.huawei.com. Users can also contact Huawei technical support engineers to obtain the patch packages.

Users can install patches for a Huawei base station controller or eCoordinator in either of the following modes:

l

Local patch installation

 

An O&M engineer must log in to the OMU OS to install OS patches for only one base station controller or eCoordinator at a time.

 

l

Remote patch installation

An O&M engineer uses Huawei network management software to simultaneously install OS patches for multiple base station controllers or eCoordinators.

  • 3.2.3 Antivirus Software

In the demilitarized zone (DMZ) of the O&M network, a virus code update server is deployed. This server obtains the latest virus codes or upgrade packages from the Internet. The antivirus server (OfficeScan or TMCM) in the internal O&M network is not directly connected to the Internet. Instead, it is connected to the virus code update server for upgrades.

SingleRAN Equipment Security Feature Parameter Description

3 Technical Description

After the antivirus server is upgraded, it automatically upgrades the virus codes and upgrade packages on the entire network.

Currently, only Windows OSs must be deployed with antivirus software. DOPRA Linux and Euler Linux OSs do not require any antivirus software. Antivirus software cannot be deployed on SUSE Linux OSs. It is recommended that the SUSE Linux OS be upgraded to the DOPRA Linux OS.

Table 3-3 lists the Huawei antivirus software solution. Contact Huawei engineers to deploy antivirus software.

Table 3-3 Huawei antivirus software solution

OMU OS Supporting Antivirus Software

Windows

Antivirus Server

OfficeScan

Antivirus Client

OfficeScan

NOTE

NOTE

  • l Antivirus client refers to equipment for which antivirus software must be configured. The client may be a server (such as the CME server or base station controller OMU) or a maintenance terminal (such as the U2000 client or LMT).

  • l All antivirus software must pass the compatibility test before installation.

  • 3.3 Trusted Environment

    • 3.3.1 Secure Startup

When a board of a base station is powered on, digital signatures must be checked before software is loaded, ensuring that only trusted software is loaded on the base station. A chain of trust is established by validating software. The software loaded when a board is powered on is written in a chip and cannot be modified or branched. Therefore, non-trusted or modified software cannot be loaded.

  • 3.3.2 Secure Storage

In secure storage, encryption keys of sensitive data on base stations are layered. Confidentiality of upper-layer keys depends on lower-layer keys. Root keys are the keys at the bottom layer. Confidentiality of root keys cannot be ensured only using software. This function stores root keys in the secure chip to ensure the confidentiality of root keys and the security of sensitive data.

  • 3.4 Self-check Upon Startup

During the startup, a base station automatically checks its hardware and software and saves the self-check results. The base station also provides MML commands for querying the self- check results.

SingleRAN Equipment Security Feature Parameter Description

3 Technical Description

  • l Hardware self-check involves hardware components, such as the memory and flash. You can run the DSP HWOLTSTRESULT command to query self-check results.

  • l Software self-check provides self-checks for kernel and processes. You can run the DSP SWTSTRESULT command to query self-check results.

  • 3.5 Process Auditing

Malware may be planted into a running base station. If the base station detects malware, the base station marks the process status of the malware as unknown.

You can run the DSP PROCESSINFO command to obtain the process status.

  • 3.6 Key File Integrity Monitoring

Technical Description

When an NE is operating, key files may be modified by an unauthorized user. As a result, the system is operating unsafely or resources are illegally utilized. The key file integrity monitoring function automatically checks whether a key file is modified by an unauthorized user and reports the check result to the U2000.

The system calculates the Hash value of key files as baseline at the first startup after an upgrade. When a key file is checked, its Hash value is calculated and compared with the baseline. If the two Hash values are inconsistent, the system determines that the key file has been modified.

Key file check involves the following check items:

  • l Service software: Service application programs running on the OS of an NE

  • l Service configuration files: Configuration files for service software

  • l OS files: Programs and configuration files of the OS on an NE

  • l Third-party components: Programs and configuration files of a third-party or open source software

  • l Audit logs: logs for audit

SingleRAN Equipment Security Feature Parameter Description 3 Technical Description l Hardware self-check involves hardware components, such

NOTE

  • l Integrity check reports compare the check items at the check time and at the time when the baseline is obtained. If a key file is modified again to the baseline before it is checked, the file is regarded as not modified.

  • l If a modified key file is detected, whether the modification is normal (such as system upgrade or system maintenance) must be determined. If the modification is normal, choose Security > Integrity Monitoring (traditional style) or Application Panel > Application Center > Security Management > NE Security > Integrity Monitoring (application style), open the Query and Set NE Check Information tab page and update the baseline on the U2000.

  • l For a base station or USU, it is recommended that maintenance personnel update the baselines of service configuration check items in time after modifying local account information, user permission information, and key materials.

  • l A UMPT, LMPT, UMDU, GTMUc, or WMPT must be used on the base station side. This function has no hardware requirement on the base station controller and eCoordinator side.

SingleRAN Equipment Security Feature Parameter Description

3 Technical Description

Check Methods

The following two check methods are provided:

  • l Periodic check Key files are checked once a day based on the specified check time and check items. To enable periodic check and set check time and check items, perform either of the following steps:

Run the SET INGCHKTSK command on the NE.

Choose Security > Integrity Monitoring (traditional style) or Application Panel > Application Center > Security Management > NE Security > Integrity Monitoring (application style) and open the Query and Set NE Check Information tab page on the U2000.

  • l Immediate check Integrity check can be performed on specified check items of an NE at any time on the U2000. To perform immediate check, choose Security > Integrity Monitoring (traditional style) or Application Panel > Application Center > Security Management > NE Security > Integrity Monitoring (application style) and open the NE Check Result tab page on the U2000.

Check Reports

Integrity check reports of key files consist of an overview (including the NE name, check items, and number of modified files) and details about modified files (including the check item and file name).

To view the check report, choose Security > Integrity Monitoring (traditional style) or Application Panel > Application Center > Security Management > NE Security > Integrity Monitoring (application style) and open the NE Check Result tab page on the

U2000.

3.7 Integrated Firewall

The integrated firewall filters attack packets to improve equipment security.

3.7.1 ACL-based Packet Filtering

3.7.1.1 Base Station

On the base station side, ACL rules are used to filter invalid Layer 2 (data link layer), Layer 3 (network layer), and Layer 4 (transport layer) packets. ACL packet filtering involves ACLs and filtering actions.

ACLs

ACLID specifies the ID of an ACL. An ACL consists of a set of ACL rules. The ACL is configured using the ADD ACL command. An ACL rule is configured using the ADD ACLRULE command.

SingleRAN Equipment Security Feature Parameter Description

3 Technical Description

  • l The VLANIDOP parameter controls whether a base station filters Layer 2 packets by VLAN tag.

If VLANIDOP is set to a value other than OP_NOVLAN(No Vlan), the base station filters Layer 2 packets by VLAN tag. In this case, VLANID1 or VLANID2 must be configured.

If VLANIDOP is set to OP_NOVLAN(No Vlan), the base station discards all Layer 2 packets without VLAN tags.

  • l The base station filters Layer 3 and Layer 4 packets by combinations of the protocol type, source IP address/wildcard of the source IP address, destination IP address/ wildcard of the destination IP address, source port number, destination port number, and differentiated services code point (DSCP).

Protocol type: specified by PT

Source IP address: specified by SIP

Wildcard of the source IP address: specified by SWC

Destination IP address: specified by DIP

Wildcard of the destination IP address: specified by DWC

Source port number: specified by SPT1

Destination port number: specified by DPT1 DSCP: specified by DSCP

Filtering Actions

Packet filtering on the transmission port of a base station includes two configurations:

blacklist configuration and whitelist configuration, as shown in Figure 3-1.

Figure 3-1 Packet filtering configuration on the transmission port of a base station

SingleRAN Equipment Security Feature Parameter Description 3 Technical Description l The VLANIDOP parameter controls whether a

SingleRAN Equipment Security Feature Parameter Description

3 Technical Description

The ACTION parameter in the ACLRULE MO specifies the rules for filtering packets that match ACL rules. The MB parameter in the PACKETFILTER MO specifies the rules for filtering packets that do not match ACL rules. Table 3-4 provides the parameter settings of blacklist and whitelist.

Table 3-4 Parameter settings of blacklist and whitelist

Configurati

ACTION

MB

on Mode

Blacklist

DENY(Deny)

PERMIT(Permit)

Whitelist

PERMIT(Permit)

DENY(Deny)

3.7.1.2 Base Station Controller/eCoordinator

The procedure for configuring ACL rules and enabling packet filtering on the base station controller/eCoordinator side is similar to that on the base station side. Their differences are as follows:

  • l The filtering action does not need to be configured and only the whitelist function is supported on the base station controller/eCoordinator side.

  • l On the base station controller/eCoordinator side, only destination IP address-based filtering rules are supported. The destination IP address is specified by the DIP parameter.

In addition to manually configured ACL rules, the base station controller/eCoordinator automatically generates ACLs in advance for incoming packets. This function is called the intelligent whitelist function. The filter criteria for ACL rules of the intelligent whitelist function include the source IP address, destination IP address, port number, protocol type, and DSCP priority. After receiving a packet, the base station controller/eCoordinator checks whether the packet matches the ACL rules. If it matches the ACL rules, the base station controller/eCoordinator accepts the packet. If it does not match the ACL rules, the base station controller/eCoordinator discards the packet. The intelligent whitelist function is always enabled and is not configurable.

3.7.2 Automatic ACL Rule Configuration

Base stations support automatic ACL rule configuration. The automatic configuration is an improvement to communication matrix-based ACL rule configuration for intelligent whitelist, which is complex and error prone.

ACL rules to be configured for intelligent whitelist are categorized into the following two groups:

  • l Automatically configured ACL rule group. This group is used to ensure setups of basic services. Based on related MOs, base stations automatically create the ACL rules applicable to signaling packets, service packets, O&M packets (including the packets of FTP connections), clock packets, and security packets. The ACL rules for FTP connections are triggered based on related MOs or maintenance commands for establishing FTP connections.

SingleRAN Equipment Security Feature Parameter Description

3 Technical Description

  • l Manually configured ACL rule group. For details, see 3.7.2.2 Restriction on Application Scenarios.

Automatic ACL rule configuration is controlled by the ACLAUTOSWITCH parameter. If endpoint mode is used, you also need to set the PACKETFILTERSWITCH parameter to ON to enable automatic configuration of ACL rules for endpoint-related MOs.

After automatic ACL rule configuration is enabled, automatically configured ACL rules vary with the changes in configured MOs. You cannot perform operations on automatically configured ACL rules.

Automatically configured ACL rules (excluding those for DHCP and FTP connections) are recorded in the configuration database and can be queried using the LST ACLRULE command. Links may be disconnected due to a recording failure and restores after a successful recording.

The number of ACL rules that can be configured depends on board configurations. For detailed specifications, see help information on ADD ACLRULE.

  • 3.7.2.1 Automatic Configuration Mechanism

With automatic ACL rule configuration, a base station obtains its IP addresses and its peer NE's IP addresses based on the corresponding MO configured on the base station and then creates ACL rules for packets sent from the peer NE.

The base station checks the settings of this MO for specific packets, without considering whether the MO is being used or functional or considering the configurations of related MOs.

For example:

  • l For O&M packets from the U2000, the base station automatically creates ACL rules based on the OMCH MO. If two OMCH MOs are configured in active/standby mode, the base station creates ACL rules for both MOs, regardless of whether the active or standby OMCH is effective.

  • l For signaling packets from the base station controller or MME, the base station automatically creates ACL rules based on the SCTPLNK MO, even if the signaling link setup fails due to an incorrect configuration or a negotiation failure.

  • l For security packets from the SeGW, the base station automatically creates all ACL rules based on the IKEPEER MO, regardless of whether this MO is referenced by the IPSECPOLICY or IPSECBIND MO.

Before automatic ACL rule configuration is enabled, the OMCH MO must be configured. An automatically configured ACL rule for an MO is removed or modified when the MO is removed or modified. The automatic configuration, modification, and removal of ACL rules take a specific period of time. If other configuration commands are run in the period, a message is normally displayed, indicating that a configuration is being exported.

  • 3.7.2.2 Restriction on Application Scenarios

In the following scenarios, ACL rules must be manually configured:

  • l For a separate-MPT multimode base station enabled with co-transmission and cascaded base stations, ACL rules must be manually configured for passerby data flows.

  • l If a base station or its peer NE (such as the base station controller, MME, and S-GW) is configured with maintenance and testing functions not listed in Table 3-5 (such as functions specified by the PING, PATH PING, TRACERT, TWAMP, IPPM, BFD,

SingleRAN Equipment Security Feature Parameter Description

3 Technical Description

DHCP RELAY, and UDPECHO MOs), ACL rules for related packets must be manually configured.

3.7.2.3 Automatically Configured ACL Rule Group

Table 3-5 describes the entire group of ACL rules that are automatically created based on related MOs or commands. - indicates that the related packets are not filtered.

Table 3-5 Automatically configured ACL rule group

Related

Peer NE

SRCIP

SRCPOR

PT

DSTIP

DSTPORT

MO

T

OMCH

U2000

U2000 IP

-

TCP

IP address

6007

UDP

of the base station's

45300

TCP

OMCH

4443

TCP

443

TCP

6000

TCP

6006

All MOs or

Control

Server IP

21 by

TCP

IP address

49152-6553

maintenance

plane of

address

default

of the base

5

commands

the

(The port

station

in FTP

U2000

number

connection

FTP

varies,

mode

server

depending

on the

parameter

settings in

the

FTPSCLT

DPORT

MO.)

User

Server IP

Determined

TCP

IP address

49152-6553

plane of

address

based on

of the base

5

the

STARTDA

station

U2000

TAPORT

FTP

and

server

ENDDATA

(includin

PORT in

g PORT

the

mode and

FTPSCLT

PASV

DPORT

mode)

MO

IPCLKLIN

PTP

Server IP

  • 319 IP address

UDP

 

319

K

server

address

  • 320 station

UDP

of the base

320

SingleRAN Equipment Security Feature Parameter Description

3 Technical Description

Related

Peer NE

SRCIP

SRCPOR

PT

DSTIP

DSTPORT

MO

T

 

IPCLK

 

35001

UDP

 

33003

server

using

Huawei

proprietar

y

protocol

NTPC

NTP

Server IP

123

by

UDP

IP address

9051

server

address

default

of the base

(The port

station's

number

OMCH

varies,

depending

on the

parameter

settings in

the NTPC

MO.)

IKEPEER

SeGW

IP address

500

UDP

IP address

500

of the

of the base

SeGW

station

IKEPEER

SeGW

IP address

500

UDP

IP address

500

(NAT)

of the

   

of the base

 

SeGW

4500

UDP

station

4500

CA

CA

Server IP

PORT

TCP

IP address

1024-65535

server

address

of the base station

CRLTSK

CR or

Server IP

PORT

TCP

IP address

1024-65535

MO with

CRL

address

of the base

Access

server

station

Method set

to

LDAP(LDA

P)

SCTPLNK

Base

IP address

PORT

SCTP

IP address

PORT

MO in link

station

of the peer

of the base

mode

controller

NE

station

/MME/

peer base

station

SingleRAN Equipment Security Feature Parameter Description

3 Technical Description

Related

Peer NE

SRCIP

SRCPOR

PT

DSTIP

DSTPORT

MO

T

SCTPHOS

Base

IP address

PORT

SCTP

IP address

PORT

T or

station

of the peer

of the base

SCTPPEE

controller

NE

station

R MO in

/MME/

endpoint

peer base

mode

station

(Abis/Iub

/S1/X2/

eX2)

IPPATH

Base

IP address

1024-6553

UDP

IP address

1024-65535

MO in link

station

of the peer

5

of the base

mode

controller

NE

station

SGW and

IP address

1024-6553

UDP

IP address

2152

peer base

of the peer

5

of the base

station

NE

station

USERPLA

Base

IP address

1024-6553

UDP

IP address

1024-65535

NEPEER

station

of the peer

5

of the base

MO in

controller

NE

station

endpoint

mode

USERPLA

NEHOST

USERPLA

SeGW

IP address

1024-6553

UDP

IP address

2152

NEPEER

and peer

of the peer

5

of the base

and

base

NE

station

USERPLA

station

NEHOST

(S1/X2)

MOs in

endpoint

mode

USERPLA

Peer base

IP address

1024-6553

UDP

IP address

1024-65535

NEPEER

station

of the peer

5

of the base

and

(eX2)

NE

station

USERPLA

NEHOST in

endpoint

mode

IPPM MO

Peer base

IP address

1024-6553

UDP

IP address

65020

in endpoint

station

of the peer

5

of the base

mode

(X2)

NE

station

-

DHCP

-

67

UDP

-

68

server

SingleRAN Equipment Security Feature Parameter Description

3 Technical Description

Related

Peer NE

SRCIP

SRCPOR

PT

DSTIP

DSTPORT

MO

T

DNSSRV

DNS

Client IP

l

49152-6

UDP

Server IP

0-65535;

server

5535

address

determined

(used

based on the

for DNS

server

resoluti

configuratio

on

n.

Port 53 is

during

used by

base

default.

station

The server

deploy

port number

ment by

is fixed to

PnP)

53 for DNS

l

64711

resolution

(used

during base

for DNS

station

resoluti

deployment

on

by PnP.

during

normal

base

station

operatio

n)

49152-655

TCP

0-65535;

35

determined

based on the server configuratio

Port 53 is used by

n.

default.

SingleRAN Equipment Security Feature Parameter Description

3 Technical Description

SingleRAN Equipment Security Feature Parameter Description 3 Technical Description NOTE During base station deployment, no ACL

NOTE

During base station deployment, no ACL rules are required because packet filtering does not take effect.

When the base station is running, ACL rules are automatically configured in the event of OMCH disconnections, regardless of the switch status for automatic ACL rule configuration. If the OMCH is disconnected, the base station attempts to restore the OMCH and starts a DHCP detection. To ensure a successful DHCP detection:

  • l The base station automatically modifies the ACL rule that filters out DHCP broadcast packets. After the DHCP detection ends, the ACL rule is automatically restored to the original one.

  • l If the ACL rule cannot be modified, the base station adds an ACL rule to allow DHCP broadcast packets to enter the base station. The ID of the added ACL rule is the largest unused one within the range from 65431 to 65531. To prevent frequent ACL rule updates from affecting transmission efficiency, the base station does not remove this ACL rule immediately after the DHCP detection ends. It removes this ACL rule only after the OMCH is successfully established and remains functioning for 30 minutes.

ACL rules are automatically generated only for IPPM links automatically established in endpoint mode. For IPPM links automatically established in link mode or manually configured IPPM links, ACL rules are not automatically generated.

Currently, a base station enables automatic ACL rule configuration for O&M packets over the following ports: 6007, 45300, 4443, 443, 6000, and 6006. The six ports are enabled by default after the OMCH MO is configured.

  • l Port 6007: Used for connecting the base station to the U2000 for tests, MML control, trace management, and alarm reporting

  • l Port 45300: Used for receiving OMCH switchover requests from the U2000 During an OMCH switchover, the base station receives an OMCH switchover request from the U2000. In the request, the destination port number is 45300. The request is triggered in any of the following scenarios:

The base station is configured with two OMCHs, and the U2000 sends the request to switch over O&M data from one OMCH to the other.

The base station is configured with one OMCH and the U2000 is configured with two OM IP addresses. When a switchover of OM IP addresses occurs, the U2000 sends the request.

The base station is configured with two OMCHs. When the active OMCH is removed, the U2000 sends the request to switch over O&M data to the other OMCH.

  • l Port 4443: Used for SSL-type digital certificate authentication initiated by the U2000

  • l Port 443: Used for data configuration and maintenance in HTTPS connections of the LMT

  • l Port 6000: Used for transmitting maintenance commands and responses (in MML format) between the network information collector (NIC) and a base station

  • l Port 6006: Used for transmitting maintenance commands and responses (in .bin format) between the NIC and a base station

When the OMCH peer IP limit switch specified by OMPEERIPLIMITSW is set to ON, a base station automatically obtains the IP address used for logging in to the base station from the U2000 during OMCH establishment, and changes the peer IP address of automatically configured OMCH ACL rules to this IP address. OMCH ACL rules may be frequently updated due to the intermittent OMCH. To prevent frequent ACL rule updates from affecting transmission efficiency, the base station updates OMCH ACL rules only after the OMCH is successfully established and remains functioning for 30 minutes. The peer IP address is not limited immediately after the OMCH is disconnected. If O&M services on the preceding ports

SingleRAN Equipment Security Feature Parameter Description

3 Technical Description

do not use the IP address for logging in to the base station from the U2000, ACL rules must be manually configured for the O&M services. For example, a cluster U2000 may use multiple IP addresses to perform O&M on a base station; any one of the NetEco (6007), TraceServer (6007), and NIC (6000, 6006) is independently deployed. In these cases, ACL rules must be manually configured before the preceding device can communicate with the base station.

If the source IP address in the CRLTSK MO uses the default IP address 0.0.0.0, the O&M IP address of the base station is used as the source IP address during communication. Therefore, the O&M IP address is used as the destination IP address (that is, the base station's IP address) in automatically configured ACL rules. If both active and standby O&M IP addresses are configured, separate ACL rules are configured for the CRLTSK MO.

For the NTPC MO, the O&M IP address of the base station is used as the source IP address during communication. Therefore, the O&M IP address is used as the destination IP address (that is, the base station's IP address) in automatically configured ACL rules. If both active and standby O&M IP addresses are configured, separate ACL rules are configured for the NTPC MO.

If the local IP address in the IKEPEER MO uses the default IP address 0.0.0.0, an interface IP address of the base station is used as the source IP address during communication. The base station can be configured with multiple interface IP addresses, and therefore 0.0.0.0 is used as the destination IP address (that is, the base station's IP address) in automatically configured ACL rules, in compliance with the setting in the IKEPEER MO. Therefore, specify an appropriate interface IP address in the IKEPEER MO when automatic ACL rule configuration is enabled.

The automatically configured ACL rules do not distinguish between boards or ports. If the IP address of a base station is configured as 0.0.0.0 or as a loopback address for data flows, the automatically configured ACL rules are added to the ACL groups where the automatic ACL rule configuration switch is enabled for packet filtering. In other cases, the automatically configured ACL rules are added only to the ACL group referenced by packet filtering enabled for the port where the local IP address resides.

ACL-based packet filtering is configured on transmission ports. With this function, a base station filters packets from other NEs. If the base station has multiple transmission ports, data flows may have different inbound and outbound ports on the base station. Specifically, data flows are sent over port 1 in the uplink and received over port 2 in the downlink. In this case, it is recommended that the base station use a logical IP address.

3.7.2.4 Automatic ACL Rule Configuration for FTP Packets

When a base station establishes an FTP session for the first time, it obtains the FTP server IP address from FTP upload commands (for example, ULD FILE) and the range of the peer port number from the FTPSCLTDPORT MO, which are used to establish an ACL rule for FTP packets. The FTP ACL rule is not immediately removed from the FTP session ends. If this FTP ACL rule is not used within 24 hours, it is removed. When an FTP session is established later, the base station determines whether an FTP ACL rule exists. If such an ACL rule exists, it will be used. Otherwise, a new ACL rule for FTP packets will be added.

SingleRAN Equipment Security Feature Parameter Description 3 Technical Description do not use the IP address for

NOTE

FTP data connection (in active or passive mode) fails to be established if automatic ACL rule configuration is enabled for packet filtering but the port number is beyond the range specified by STARTDATAPORT and ENDDATAPORT.

SingleRAN Equipment Security Feature Parameter Description

3 Technical Description

3.7.2.5 ACL Rule ID Ranges

ACL rule IDs range from 1 to 65535 and from 70000 to 74999. Table 3-6 describes the IDs and usage of ACL rules after the automatic ACL rule configuration function is enabled.

Table 3-6 ACL rule ID division

ACL Rule ID

Usage

1-49999

Manually configured ACL rules

50000-50199

Automatically configured ACL rules for O&M packets

50200-50299

Automatically configured ACL rules for IPCLK and NTP packets

50300-50999

Automatically configured ACL rules for security packets

51000-52999

Automatically configured ACL rules for signaling packets

53000-54999

Automatically configured ACL rules for service packets

55000-59999

Reserved for automatically configured ACL rules

60000-65535

Manually configured ACL rules

70000~74999

Automatically configured ACL rules for service/signaling packets in endpoint mode

When filtering incoming data packets, the base station matches packets with ACL rules in ascending order of ACL rule IDs. For example, if the matching ACL rules reside in the ID range of 1-59999, a base station preferentially applies the manually configured ACL rules.

SingleRAN Equipment Security Feature Parameter Description 3 Technical Description 3.7.2.5 ACL Rule ID Ranges ACL rule

NOTE

If ACL rules with the IDs ranging from 50000 to 59999 have been configured before automatic ACL rule configuration is enabled, the IDs of these ACL rules must be changed to 1-49999 or 60000-65535.

The IDs of manually configured ACL rules fall in 60000-65535. However, there are exceptions. An ACL rule is automatically configured when a base station starts a DHCP detection due to its OMCH is disconnected. The ID of this ACL rule is largest unused one within the range from 65431 to 65531.

3.7.3 Network Attack Prevention

The ACL-based packet filtering function filters out only certain attack packets. Attackers may use IP or Media Access Control (MAC) address spoofing, where attack packets appear to be authorized packets for access. Attackers may also use flood attacks, such as Address Resolution Protocol (ARP) and Internet Control Message Protocol (ICMP) flood attacks to attack the network. In addition, attackers may launch invalid packet attacks. If an NE receives invalid packets, the NE may experience exceptions during packet filtering based on ACL rules. For example, errors may occur or the NE may break down.

To address these security risks, flood attack prevention, invalid packet attack prevention, and ARP spoofing prevention are used. These functions are designed to deny attack packets that can bypass ACL-based packet filtering. Without these functions, such attack packets may even cause service quality deterioration or interruption.

SingleRAN Equipment Security Feature Parameter Description

3 Technical Description

  • 3.7.3.1 Rate Limitation on Broadcast Packets

Ethernet interface boards support rate limitation on broadcast packets by monitoring the number of received broadcast packets in real time to resist network storms. An alarm is reported if the broadcast packet traffic exceeds a threshold. This function is always enabled and is not configurable.

On the Base Station Controller/eCoordinator Side

This function works as follows:

  • l If the number of broadcast packets received over an interface board per second is greater than or equal to the value of BCPKTALARMTHD for 30 consecutive seconds, ALM-21387 Ethernet Port Broadcast Packets Exceeding Alarm is reported.

  • l If the number of broadcast packets received over an interface board per second is less than the value of BCPKTALARMCLRTHD for 30 consecutive seconds, this alarm is cleared.

On the Base Station Side

This function works as follows:

  • l If the number of broadcast packets received over a port per second is greater than or equal to the value of RXBCPKTALMOCRTHD for 30 consecutive seconds, ALM-25879 Ethernet Port Broadcast Packets Exceeding Alarm is reported.

  • l If the number of broadcast packets received over an interface board per second is less than the value of RXBCPKTALMCLRTHD for 30 consecutive seconds, this alarm is cleared.

  • 3.7.3.2 ICMP Flood Attack Prevention

The base station controller/eCoordinator and base station support ICMP flood attack prevention.

On the Base Station Controller/eCoordinator Side

For the base station controller/eCoordinator, you can run the ADD ICMPGUARD command to configure ICMP attack prevention policies. With these policies, interface boards discard the specified types of ICMP packets sent from IP addresses in the specified network segment.

  • l The IPADDR parameter specifies the source IP address of ICMP attack packets.

  • l The GUARDTYPE parameter specifies the type of ICMP attack packets.

When the ICMPALMSW parameter is set to ON(ON), interface boards on the base station controller/eCoordinator monitors the traffic of ICMP attack packets in real time for 30 consecutive seconds.

  • l If the number of ICMP attack packets received over an interface board per second is greater than or equal to the value of ICMPALMTHD, the base station controller/ eCoordinator discards ICMP packets and reports ALM-21388 Invalid Packets Exceeding Alarm.

  • l If the number of ICMP attack packets received over an interface board per second is less than the value of ICMPALMRTHD, the base station controller/eCoordinator clears this alarm and does not discard ICMP packets.

SingleRAN Equipment Security Feature Parameter Description

3 Technical Description

On the Base Station Side

The following settings enable ICMP flood attach prevention and alarm reporting on the base station side:

  • l FLDTYPE set to ICMP(ICMP)

  • l DFDSW set to ENABLE(Enable)

  • l ALMSW set to ENABLE(Enable)

The base station detects ICMP flood packets every 10s:

  • l If the number of ICMP flood packets received per second is greater than or equal to the value of DFDTHD, the base station discards ICMP packets and reports ALM-25950 Base Station Being Attacked.

  • l If the number of ICMP flood packets received per second is greater than or equal to the value of ALMTHD but less than the value of DFDTHD, the base station reports ALM-25950 Base Station Being Attacked.

  • l After this alarm is generated, if the number of ICMP flood packets received per second is less than the value of ALMTHD for five consecutive minutes, the base station clears this alarm.

It is recommended that the value of DFDTHD be greater than the value of ALMTHD and their value difference be over 3% greater than the value of DFDTHD.

3.7.3.3 ARP Flood Attack Prevention

Interface boards may experience ARP flood attacks in which attackers send to interface boards a large number of spoofed ARP packets whose source IP addresses have been tampered with, interrupting the communication.

On the Base Station Controller/eCoordinator Side

For the base station controller/eCoordinator, the ARP entry learning function is used to prevent ARP flood attacks. This function is controlled by the ARPLRNSTRICTSW parameter and is enabled by default.

With this function, interface boards record the MAC addresses of the ARP response packets from the local system and learn from only the recorded MAC addresses. This enables interface boards to reject spoofed ARP packets.

On the Base Station Side

For the base station, the following settings enable ARP flood attack prevention and ARP attack packet traffic monitoring:

  • l FLDTYPE set to ARP(ARP)

  • l DFDSW set to ENABLE(Enable)

  • l ALMSW set to ENABLE(Enable)

The base station detects ARP flood packets every ten seconds:

  • l If the number of ARP flood packets received per second is greater than or equal to the value of DFDTHD, the base station discards ARP packets and reports ALM-25950 Base Station Being Attacked.

SingleRAN Equipment Security Feature Parameter Description

3 Technical Description

  • l If the number of ARP flood packets received per second is greater than or equal to the value of ALMTHD but less than the value of DFDTHD, the base station reports ALM-25950 Base Station Being Attacked.

  • l After this alarm is generated, if the number of ARP flood packets received per second is less than the value of ALMTHD for five consecutive minutes, the base station clears this alarm.

It is recommended that the value of DFDTHD be greater than the value of ALMTHD and their value difference be over 3% greater than the value of DFDTHD.

3.7.3.4 ARP Spoofing Prevention

Principles for preventing ARP spoofing are as follows:

  • l Blacklist and whitelist: When an interface board creates an ARP entry, the ARP entry is added to the blacklist by default. If an ARP entry is not updated by new MAC packets within one minute, the ARP entry is regarded as credible and is added to the whitelist.

  • l Blacklist confirmation: An interface board periodically checks the ARP entries on the blacklist.

    • a. If the interface board receives an ARP packet from the peer end and the packet attempts to update the MAC address in a whitelisted ARP entry, the interface board broadcasts five ARP requests at intervals of 1 second.

    • b. The interface board determines the sources of the received ARP response packets and the number of received ARP response packets.

If ...

Then ...

The interface board receives three or more ARP response packets from a MAC address that is in a whitelisted ARP entry

The MAC address is considered as credible.

The interface board receives three or more ARP response packets from a MAC address that is not in a whitelisted ARP entry

The MAC address is added to the blacklist.

On the Base Station Controller/eCoordinator Side

For the base station controller/eCoordinator, ARP spoofing prevention is controlled by the ARPANTICHEATSW parameter.

If an interface board detects more than 30 ARP entry update attempts (excluding those from credible MAC addresses) within one minute, the interface board reports ALM-21391 ARP Conflict. The alarm parameter Attacker's MAC Address specifies the MAC address that has the most ARP entry update attempts within the last credible-ARP-entry decision period before ALM-21391 ARP Conflict is reported. The source of an ARP spoofing attack can be identified in the following ways:

  • l If ALM-21391 ARP Conflict is reported, check the value of Attacker's MAC Address to find out the source. Run the DSP ARPSPOOFING command to find out the sources of all ARP spoofing attacks.

  • l If ALM-21391 ARP Conflict is cleared or the blacklist is aging, check the value of Attacker's MAC Address in historical alarms to find out the sources of historical ARP spoofing attacks.

SingleRAN Equipment Security Feature Parameter Description

3 Technical Description

If the interface board does not detect any ARP entry update attempts within 1 minute after this alarm is reported, the alarm is cleared.

SingleRAN Equipment Security Feature Parameter Description 3 Technical Description If the interface board does not detect

NOTE

ALM-21391 ARP Conflict applies to IP addresses in the ARP entries. For IP addresses that are not included in the ARP entries, for example, IP address of an interface board, ALM-21347 IP Address Conflict applies.

On the Base Station Side

For base stations, the integrated IP protocol stack processing unit starts ARP spoofing detection when receiving ARP packets that attempt to update an ARP entry. If the detection result indicates that the original ARP table is credible, the received ARP packets are regarded as spoofed ARP packets. The base station then adds the MAC address of such packets to a blacklist and does not process ARP packets containing this MAC address before the blacklist expires.

ARP spoofing prevention is enabled for a base station when the ARPSPOOFCHKSW parameter is set to ENABLE(Enable). If the number of discarded spoofed ARP packets is greater than or equal to the value of the ARPSPOOFALMTHD parameter after ARP spoofing prevention is enabled, the base station reports ALM-25950 Base Station Being Attacked. Information about the discarded spoofed ARP packets can be queried using the DSP INVALIDPKTINFO command.

  • 3.7.3.5 Smurf Attack Prevention

Ethernet interface boards of the base station controller/eCoordinator and base station support Smurf attack prevention, thereby preventing network congestion due to Smurf attacks. The Smurf attack prevent function is always enabled and is not configurable.

With this function, an interface board checks the destination IP address of each received ICMP packet:

  • l If the destination IP address of the packet is a network or broadcast address, the interface board discards the packet.

  • l If the destination IP address of the packet is the interface board's IP address, the interface board accepts the packet.

  • 3.7.3.6 Illegal Packet Attack Prevention

An illegal packet may be an illegal IP packet, multicast MAC packet, or ICMP packet.

  • l Illegal IP packet An illegal IP packet can be:

A malformed UDP packet whose total length is shorter than the length of a standard IP header

A packet whose source IP address or UDP port number is not within the planned range

A packet whose protocol type is not supported by the receiver

  • l Invalid multicast MAC packet A multicast MAC packet is illegal if it is received over an interface board for which the ETH Operation, Administration, and Maintenance (ETH OAM) function is not enabled.

SingleRAN Equipment Security Feature Parameter Description

3 Technical Description

  • l Invalid ICMP packet An invalid ICMP packet is defined by the GUARDTYPE parameter.

On the Base Station Controller/eCoordinator Side

For the base station controller/eCoordinator, the invalid packet attack prevention function is always enabled and is not configurable. An alarm is reported when an interface board receives excessive illegal packets.

  • l Interface boards monitor the traffic of invalid IP packets in real time when the VALIDPKTCHKSW parameter is set to ON(ON).

If the number of illegal IP packets received on an interface board per second is greater than or equal to the value of INVALIDPKTALMTHD for 30 consecutive seconds, ALM-21388 Invalid Packets Exceeding Alarm is reported.

If the number of illegal IP packets received on an interface board per second is less than the value of INVALIDPKTALMRTHD for 30 consecutive seconds, this alarm is cleared.

  • l Interface boards monitor the traffic of illegal multicast MAC packets in real time when the INVALIDMCASTALMSW parameter is set to ON(ON).

If the number of illegal multicast MAC packets received on an interface board per second is greater than or equal to the value of INVALIDMCASTALMTHD for 30 consecutive seconds, ALM-21388 Invalid Packets Exceeding Alarm is reported.

If the number of illegal multicast MAC packets received on an interface board per second is less than the value of INVALIDMCASTALMRTHD for 30 consecutive seconds, this alarm is cleared.

When users are notified of ALM-21388 Invalid Packets Exceeding Alarm, they can identify the attack source and determine the attack type in the following methods:

  • l Search the operation logs for statistics on illegal packets.

  • l Run the DSP INVALIDPKTINFO command to obtain detailed information about illegal packets.

On the Base Station Side

The base station resists illegal packet attacks by checking the characteristics of incoming packets.