security assessment report se2900 virtualized …miercom.com/pdf/reports/20160108.pdfsecurity...

Security Assessment Report

SE2900 Virtualized SBC (vSBC)

February 2016

DR160108B

Miercom

www.miercom.com

http://www.miercom.com/

Huawei vSBC Security Assessment 2 DR160108B

Copyright © 2016 Miercom 8 February 2016

Contents

1 - Executive Summary .................................................................................................................................................. 3

2 - vSBC Test Bed ............................................................................................................................................................ 5

3 - How We Did It ........................................................................................................................................................... 7

4 - OS Hardening: Test Results .................................................................................................................................. 8

5 - Scanning and Vulnerability: Test Results ...................................................................................................... 10

6 - Service Theft and Fraud: Test Results ............................................................................................................ 13

7 – SIP-Specific Attacks: Test Results .................................................................................................................... 15

8 – Denial of Service and Fuzzing Attacks: Test Results ................................................................................ 18

9 - About Miercom ...................................................................................................................................................... 22

10 - Use of This Report .............................................................................................................................................. 22



1 - Executive Summary

Huawei Technologies engaged Miercom to perform a thorough, independent

security assessment of its vSBC, a virtualized implementation of its SE2900 Session

Border Controller. The testing evaluated the inherent security features and

countermeasures of the vSBC with no additional external security gateways or

firewalls between the vSBC and the attack stations.

The purpose of the testing was to uncover any evident security vulnerabilities that a

scurrilous insider assailant could exploit to disrupt the proper, normal operation of

the vSBC. Most exploits against the vSBC were launched from an inside source, on

the same internal switched network, with no other security protection between the

assailant and the hardened vSBC system. Tests included a broad and complex set of

exploits launched by security tools and scripts to stress and penetrate the vSBC

system. Code version V500R002C10 of the vSBC was tested.

We note that all the testing detailed in this report addresses functional security

capabilities, and is not performance testing of the vSBC’s capacity.

Overall, the Huawei Virtualized SBC (vSBC) proved to be more secure than most

comparable Session Border Controllers we have tested to date, and exhibited

effective resilience through multiple batteries of exploit and penetration tests. Our

security testing found no threat or vulnerability for a properly configured Huawei

vSBC system.

The internal countermeasures built into the vSBC were all enabled for testing. The

approach and methodology utilized in these tests are based on knowledge that

Miercom, in collaboration with leading security experts, has amassed from years of

conducting security assessments in the VoIP environment.

This document provides an overview of the results and details of the tests and

exploits that were conducted. The vSBC was configured according to Huawei-

specified security settings.

Key Findings and Conclusions

Huawei's vSBC blocked every Denial-of-Service (DoS) and Distributed DoS

attack launched against it. What's more, even the most insidious attacks

were unable to cause calls to drop, and MOS quality during attacks

remained above 4.0.

The vSBC package includes numerous effective features for protecting the

system from access by unauthorized individuals. Password control is

bulletproof. All access can be limited to secure, encrypted communications,

and the scope of management access can be assigned in various levels.



vSBC also proved resilient to hundreds of thousands of fuzzing attacks and

protocol mutations launched against it. The system is impressively hardened.

Various tests were conducted to see if popular exploits used for service theft and

fraud would work. The system effectively blocked all of these.

Scans of the system by leading penetration-scanning tools revealed no

known vulnerabilities.

The test results are detailed in the following sections of this document. We were

impressed with the performance of the vSBC in its demonstrated ability to sustain call

processing functions even while undergoing malicious exploits and attacks.

Miercom is pleased to present the Miercom Certified Secure award to Huawei's vSBC.

Robert Smithers

CEO

Miercom



2 - vSBC Test Bed

A test-bed network, depicted in the diagram below, was set up for the security testing of the

vSBC. The vSBC is a virtualized software version of Huawei's legacy SE2900 Session Border

Controller appliance. In the test bed, version V500R002C10 of the Linux-based vSBC package

was tested on VMware vSphere, a leading cloud-computing operating environment, running on

an HP c7000 multislot server enclosure with two server blades. Each server blade featured an

Intel Xeon E5-2670 v2, 2.50-GHz, 10-core CPU and 131 GB of memory.

Most of the security assessment was conducted directly from an attack source on the same

Layer-2 switched LAN as the vSBC – without any intervening security gateways, firewalls or other

system that could intercept or filter direct access. While this simulated the case where a local

laptop, desktop or server was compromised and used to launch malicious attacks against the

vSBC, the system’s same security defenses are applied just as effectively against remote threats.

Figure 1: Logical Configuration of the vSBC Test Bed

vSBC

(SE2900) on HP c7000 enclosure

with 2 server blades

EXFO QA-805

Tesgine

Codenomicon Server

Management

Access

Nessus Server hping3 Server

PuTTY

WinSCP

Huawei NE40E

Switch/Router

Router connecting

Local LAN to

10.0.0.0/24 Network

NTE Call Generator

Source: Miercom, January 2016

https://www.vmware.com/go/download-vsphere



As the test-bed diagram shows, there were actually numerous attack nodes. Below is a brief

description of the key nodes and tools used in this testing:

EXFO QA-805: A powerful platform for testing VoIP and IP Multimedia Systems (IMS)

networks and telecom systems, from Canada-based EXFO. The QA-805 can emulate over

5 million subscribers/registrants, 8 million data-signaling sessions and 1.25 million RTP

media sessions. EXFO version 9.7 code was run in the tests.

Codenomicon: Finland-based vendor of systems for checking for unknown

vulnerabilities in the protocol implementations of systems and equipment. Version

11.8.7 of Codenomicon's software was used, which offers several hundred test suites for

creating and delivering fuzzed, malformed or otherwise improper protocol messages and

file formats and assessing responses.

Nessus: The industry's leading commercial vulnerability and penetration test software.

Nessus version 6.4.3 was used in the testing.

hping3: hping version 3.0 is a software tool, based on Linux commands, which lets the

user deliver high volumes of TCP, UDP, ICMP and raw-IP messages to a target system.

PuTTY: Software for assessing SSH (Secure Shell) and Telnet connections with a device

supporting SSH and Telnet connections.

Tesgine: A Huawei-developed security and performance test tool, based on the ATCA

(Advanced Telecom Computing Architecture) framework. Delivers malformed packets

and messages. Used to test security and performance of telecom equipment in both

access and core-network environments. Version 2.0 was used.

NTE (Network Traffic Emulator) Call-Load Generator: A traffic-load generator and

test tool developed by Huawei Technologies and used by many carriers and service

providers to performance-test access and core-network telecom equipment. The NTE

code version used was V300R005C30.

WinSCP: SFTP (Secure File Transfer Protocol) client software that supports SCP (Secure

Copy Protocol); enables secure SSH file transfers between hosts over a network; includes

mechanisms for authentication and data integrity. Version 5.1.5 was used.

As the diagram shows, most of the attack nodes were IP-connected over the same local LAN –

that is, via Layer-2 switching – as the vSBC package. The Nessus vulnerability test system was

connected through a routed connection to the target system (vSBC), as if from the

organization's Intranet. As noted, there were no other defense devices (i.e., firewall, intrusion

detection, intrusion prevention systems) between the attack nodes and the vSBC.



3 - How We Did It

A half-dozen tools were employed in this security audit, including several packages that were

custom-developed for security testing. Some tests ran only minutes while others, including

Nessus scanning of all the vSBC's operational interfaces, took hours.

Over 100 discrete tests and attacks were run against the vSBC, which involved delivery of

millions of varied packet types and malformed packets and messages. Many of the attacks were

floods and Denial-of-Service attacks, involving delivery of hundreds and thousands of pps.

The results of this security testing are presented in the following six sections:

OS Hardening: These tests exercised and verified the controls that the vSBC supports for

defining passwords and users, and restricting access by unauthorized users.

Scanning and Vulnerability: These tests, including Nessus vulnerability scans of all vSBC

operational ports/interfaces, thoroughly probes the SBC to ascertain open and

responsive ports and services, some of which could be vectors for subsequent attacks.

Service Theft and Fraud: Various tests were conducted to assess the vSBC's vulnerability

to many common frauds and theft-of-service exploits.

Malformed and Fuzzing Attacks: These tests deliver packets and message sequences

which are invalid, designed to confuse a target system and interrupt operations.

SIP-Specific Attacks: This battery of attacks and exploits focus on SIP-protocol-specific

attacks and exploits.

Flood and Denial-of-Service (DOS) Attacks: These attacks are designed to overwhelm

ports and interfaces of the target system through high volumes of traffic.

The following sections list and detail all the particular tests and attacks in each of these areas.



4 - OS Hardening: Test Results

Security Test What's Measured Process and Expected

Result Result

Modifying user

password

Process for changing a

user’s password

Using MOD PWD

command, user modifies

password, consistent

with security rules

System requires correct

new password and confirm

password, subject to

security policy rules ; no

default values accepted

Pass

Changing OS

user password

vSBC system requirement

to change OS user

password after initial login

Via PuTTY SSH

connection, see if system

prompts user to change

default password

System warns new user to

change default password.

Afterwards, use of old

password is denied.

Pass

Changing OMU

(Operation &

Maintenance

User) database

user password

Security effectiveness of

changing OMU user

password

Initial login via PuTTY,

then change OMU user

password via GUI

Initial password was

changed via GUI. Only the

new password was then

accepted.

Pass

Dual-mode login:

common mode

(plain text), and

then secure

mode only

Ability to restrict access to

secure, encrypted login

First login via common

mode; then change to

secure encrypted SSL

access only

After login is restricted to

encrypted SSL only, plain-

text login is no longer

possible.

Pass

OMU user

security policies

System requirement to

change default security

settings after initial login

First logged in with

default password and ID,

then system warns to

change password

Following system warning,

new password and ID are

input, and default login no

longer supported.

Pass

Multiple, per-

operator levels of

management

access

Ability to set different,

custom levels of

management access

Login as super user, then

define different, custom,

access levels for other

users

After log-in, different and

custom levels of access

were defined for different

operators.

Pass

Configuring

workstation

access

Ability to limit

management access to

specific workstations

Authorized user logs in,

then sets permission for

specific work-stations to

access the system

Access by specified

workstations is allowed,

and all others are blocked. Pass

Authorization

Confirmation

Function

Ability to restrict access to

specific users, delivering a

login banner to users

seeking access

Access list can be

specified by address or

LAN; creates a login

banner

Authorized access could

be defined by IP address,

LAN or LAN segment;

delivers a login banner to

users via secure PuTTY

connection.

Pass

Login banner

modification

Ability to modify the login

banner delivered to users

seeking access

An authorized user logs

in via PuTTY, displays

and then modifies the

login banner

An authorized user can

login via PuTTY and

modify the login banner

displayed to users seeking

access.

Pass



Setting expiration

of password

validity

Ability to set an expiration

date for access passwords

An authorized user can

login via PuTTY and

then, using a Linux

command, set an

expiration date for any

user and their password

An authorized user can set

a password validation

period – an expiration date

– for any user and their

password.

Pass

Unauthorized

user lockout

Ability to lock out an

unauthorized user who

repeatedly attempts access

An assailant attempts to

hack userID and

password in order to

access the SBC system

After five attempts with an

incorrect userID or

password, the user will be

locked out for 30 minutes

by default; duration is

configurable.

Pass

SNMP access

control

That SNMP groups can be

defined, each with

separate, restricted views

Define an SNMP group

with specific viewing

rights

SNMP groups were

defined with specific

scopes. SNMP version can

be readily changed.

Pass

Unsecure access

to OAM

(operations and

management)

interface

Whether SBC's

management interface can

be accessed via

unencrypted connections

After proper

configuration, an attack

client attempts to access

OAM port via

unencrypted FTP and

Telnet

Properly configured vSBC

supports only encrypted

access on OAM interface

(SSH, IPsec and Secure

FTP); all other attempts

failed.

Pass

Logging of

system

commands

Whether system can log all

management commands

and activity

vSBC is set-up to record

every command. Log is

checked for accuracy

All commands from all

managers and operators

are stored and listed, for

forensic analysis.

Pass

RADIUS

verification of

users

Ability of the SBC to

enforce RADIUS

authentication on its

management interface

With 1,000 background

calls or 2,000 RTP

sessions, which is

approximately 50% of

maximum capacity, to

exercise the system

running, the vSBC is set

to authenticate all users

via external LDAP and

RADIUS servers

The vSBC did require

RADIUS authentication of

all users allowed access; all

others were denied access.

Pass



5 - Scanning and Vulnerability: Test Results


Result Result

Info leakage from

SIP messages

from vSBC

If someone can glean

information (signaling and

media addresses) from

message responses to SBC

requests

EXFO assesses messages

from vSBC to core

network to learn

signaling and media port

addresses

The signaling and media

addresses were hidden in

messages from the vSBC

and could not be learned

by capturing these

messages.

Pass

Determining call

parameters from

incoming SIP

messages

Ability to determine call

parameters from

responses to requests

from vSBC

EXFO assesses incoming

messages to vSBC in

attempt to learn call

parameters

No significant call

parameters could be

guessed or deduced. Tag

information can also be

hidden.

Pass

Topology hiding Ability to learn IP

addresses and internal

network topology from SIP

headers

EXFO assesses SIP

messages to see if

internal IP addresses can

be learned from SIP

headers

vSBC replaces and hides

key IP addresses (i.e., core

network), so the network

topology cannot be

learned from SIP headers.

Pass

UDP port scan To ascertain whether any

unnecessary UDP ports are

open

hping3 is used to verify

which UDP ports are

open and responsive

Only SIP ports 5060 and

5061 and SNMP ports 161

and 162 are open.

Pass

TCP port scan To ascertain which TCP

ports are visible and open

hping3 sends TCP

packets to every TCP

port at 140 pps, with an

alarm threshold set for

100 pps

Only SIP and related ports

are found to be open; all

other TCP packets are

discarded. An alarm is

issued denoting the TCP

traffic load from the

hping3 source.

Pass

Nessus scan Any vulnerability that can

be identified by Nessus,

the industry leading

vulnerability-detection

software tool

Full Nessus scans are

conducted of signaling

ports, media ports, and

OAM (operations &

management port)

No significant

vulnerabilities were

identified by Nessus on

any of the vSBC's key

operational ports (see

below summaries).

Pass



Nessus Summary of vSBC Signaling Port (client)

Summary: No vulnerabilities identified by Nessus

Nessus Summary of vSBC Signaling Port (server)


Nessus Summary of vSBC Media Port (client)




Nessus Summary of vSBC OAM (Operations and Management) Port

Summary: No vulnerabilities are found. The medium alerts are related mainly to

security certificate issuance, and not to penetration vulnerabilities.

Nessus Summary of vSBC Media Port (server)




6 - Service Theft and Fraud: Test Results

Security Test What's Measured Process and Expected Result Result

Early-media call

blocking

Ability of the SBC to block

early media RTP (sent right

after the SIP Invite) from a

specific source as a means

of fraud prevention

With 1,000 background calls

or 2,000 RTP sessions, which

is approximately 50% of


exercise the system running,

EXFO issues early-media calls;

these should be blocked by

SBC

vSBC offers a policy

setting which, when

set, effectively blocks

early-media calls. Pass

Media codec

renegotiation

Ability of the SBC, to

conserve bandwidth, to

prevent calls from being

renegotiated from a thin

codec G.729 to G.711






EXFO attempts to renegotiate

calls from G.729 to G.711,

which the SBC should block

and drop

All attempts to

renegotiate calls up

from G.729 to G.711

were blocked by

vSBC; only G.729

audio streams were

permitted; G.711

audio is blocked.

Pass

Media codec

enforcement

Ability of the SBC to limit

media traffic to thin

codecs G.729, to conserve

bandwidth






EXFO attempts to set-up

G.711 calls, when only G.729

is allowed

When properly

configured, vSBC

permits only G.729

codec calls; G.711 call

attempts are blocked

and dropped.

Pass

Random RTP

fraud

Ability of the SBC to block

fraudulent RTP streams,

which use a known-user

source address and port

number, but are sent to a

different destination port






Tesgine sends fraudulent RTP

streams – from a known

source, but to different

destination ports

All normal calls and

RTP streams were

passed by the vSBC,

but all the fraudulent

RTP streams were

dropped.

Pass



RTP rogue attack Ability of the SBC to block

rogue RTP packets from

illegitimate sources – sent

using the source and

destination of a stopped

or cancelled call






Tesgine sends fraudulent RTP

streams – using the source

and destination ports of a

stopped or cancelled call

All normal calls and

RTP streams were

passed by the vSBC,

but RTP streams

using illegitimate

source and

destination ports

were dropped.

Pass

Peering partner

sessions limit


restrict the number of

concurrent calls from any

specific customer to only

the number expected






with the max number of calls

for all users set to 1, the EXFO

attempts to set-up multiple

calls from the same source

The vSBC rejected all

extra calls (beyond 1)

made by any user,

and depending on

settings, issued an

alarm and/or

blacklisted the user.

Pass



7 – SIP-Specific Attacks: Test Results

Security Test What's Measured Process and Expected Result Result

SIP/SDP

Codenomicon

test suite,

including:

SIP fuzzing

SIP register

fuzzing

SIP options

fuzzing

SIP torture

test

SIP invite test

SBC's ability to tolerate

invalid-and malformed-

packet attacks, with no

instability or effect on

legitimate call traffic

With 3,600 calls connected,

Codenomicon delivers SIP-

based attacks, including over

350,000 test cases, to SBC's

signaling interface (port 5060)

vSBC passed all tests,

exhibited no instability

and there were no call

failures as a result of

the diverse suite of

Codenomicon SIP-

fuzzing attacks. Pass

Protos test suite SBC's ability to tolerate

malformed-SIP-protocol

attacks, with no instability

or dropped calls


the Protos test tool launches

its attack suite against the

SBC's signaling port 5060

vSBC dropped all

malformed SIP attack

packets and there

were no call failures as

a result of the diverse

Protos suite of SIP-

fuzzing attacks.

Pass

SIP flood,

including:

Malformed

headers

Large

fragmented

packets

Many Headers


malformed-SIP-protocol

attacks at 1,000 pps, with

no instability or dropped

calls


EXFO delivers various

malformed SIP-packet attacks

to SBC's signaling port 5060,

using different IP sources and

port numbers

vSBC issued alarms,

including SIP Large

Packet alarm, and

black-listed the source

IP addresses. Pass

SIP malformed

attacks from a

spoofed IP source


invalid-SIP-packet attacks

from a spoofed IP source,

with no instability or

dropped calls


EXFO delivers SIP-packet

attacks, with too many

headers and too-large

packets, to SBC's signaling

port 5060, using a spoofed IP

address

vSBC issued alarms for

malformed, multi-

header and too-large

SIP packets, and no

calls dropped.

Pass

Arbitrary custom

SIP header and P-

header injection

SBC's ability to handle SIP-

packet delivery with

unusual headers


EXFO delivers SIP packets

with diverse headers

vSBC can be set to

discard this type of

message, or pass such

SIP packets to an

internal call processor

(IMS).

Pass



SIP DOS floods,

including:

SIP Request

flood

SIP Response

flood

Signaling flood

from blocked

source

SBC's ability to handle

high SIP message floods

1,000 pps, without

impacting other traffic

With background traffic, EXFO

delivers SIP-packet floods at

1,000 pps, one at a time, to

SBC signaling port 5060

vSBC discards SIP-

request and SIP-

response flood

packets and alarms in

each case, and

discards flood packets

from blocked IP

source. No calls

dropped.

Pass

SIP Distributed

Denial-of-Service

(DDoS) floods,

including:

SIP Request

flood

SIP Response

flood

Signaling flood

from blocked

sources

SBC's ability to handle very

high SIP message floods

(3,000 pps) from multiple

IP sources, without

impacting other traffic

With background traffic, EXFO

delivers SIP-packet floods at

3,000 pps, one at a time, to

SBC random ports starting at

signaling port 5060

vSBC discards SIP-

request and SIP-

response flood

packets and alarms in

each case, and

discards flood packets

from blocked IP

sources, issuing DDoS

alarm. No dropped

calls.

Pass

RTP flooding

during call

SBC's ability to monitor

bandwidth based on call

codec

With background traffic,

Tesgine sends excessive RTP

packets on a valid call path

(same IP & port)

After enabling a call-

restriction setting,

vSBC alarmed at the

excess RTP traffic,

regarding it as a media

DoS attack.

Pass

RTP flooding

during call, from

a different IP

source

SBC's ability to spot

improper RTP traffic, to

same destination but from

a source other than the

one Invited in call set-up


Tesgine sends RTP packets at

125 pps to a destination

already on a call, but from a

different source

vSBC spotted and

dropped all the

packets in the

additional, improper

RTP stream. No failed

calls.

Pass

Random RTP

flood


improper RTP packet

traffic, sent to multiple,

random destination RTP

ports


Tesgine sends RTP packets at

10,000 pps to random

destination ports

vSBC spotted and

dropped all the RTP

packets being sent to

random destinations.

No failed calls.

Pass

RTP injection into

an existing call


unauthorized RTP traffic,

inserted into a legitimate

call


Tesgine sends RTP packets to

same destination as a legit

call

vSBC spotted and

dropped the RTP

packets being inserted

into the legit RTP

stream. No failed calls.

Pass



RTP fuzzing SBC's ability to handle

invalid-and malformed-

RTP packet attacks, with

no effect on legitimate call

traffic


Codenomicon delivers RTP

attacks, including over

380,000 test cases, to SBC's

media port

vSBC exhibited no

instability and there

were no call failures as

a result of the RTP

fuzzing attacks.

Pass

Short-call attack SBC's ability to control

excessive short calls (BYE

message issued in <3

seconds)

EXFO issues calls with 1-

second hold time. SBC set to

regard 35 calls in 5 mins as

short-call attack

vSBC properly

alarmed, and blocked

the offensive caller's

port.

Pass

SIP traffic burst

from trusted

sources

How well the SBC can

handle traffic overages

Using the NTE traffic-

generator tool, 200,000 users

are registered and calls are

placed at 600 cps

Actual cps handled

showed as 300 +/- 5

percent. No

established calls failed,

and new call bursts

were properly rejected.

Pass

SIP end-call

attack

SBC’s ability to discard

illegal bye message from

unwanted source

vSBC Should consider the bye

message as invalid

vSBC dropped all the

bye messages while

1000 regular calls were

running

Pass



8 – Denial of Service and Fuzzing Attacks: Test Results


Result Result

ARP flood

protection

SBC's ability to reject a

flood of unsolicited ARP

replies, while maintaining

IP connectivity


Tesgine sends 10,000

pps of ARP Reply

packets to the SBC's

signaling port

IP connectivity with

gateway is maintained,

and no calls failed, during

ARP flood attack.

Pass

ICMP flood


flood of ICMP pings, issue

alarm


hping3 sends 150 pps of

ICMP packets to the

SBC's signaling port,

with alarm set for 100

pps

SBC issued an alarm; no

effect on ongoing

legitimate traffic. Pass

ICMP source

quench (ICMP

Type-4)


flood of ICMP Source

Quench packets, while

maintaining calls


hping3 delivers ICMP

source quench packets

at 150 pps to the SBC

vSBC drops all the ICMP

packets at the data-plane

level; no effect on ongoing

legitimate traffic.

Pass

ICMP large

packets

SBC's ability to reject an

inundation of large (1,800-

byte) ICMP Echo Request

packets


Echo Request packets at

150 pps to the SBC, with

alarm threshold set to

100 pps

SBC issued an alarm.

Pass

ICMP oversized

packets

(requiring

fragmentation

and reassembly)


inundation of too-large

(>65,536-byte) ICMP

packets


Tesgine issues 110 pps

of oversized ICMP

SBC issued an alarm; no

effect on ongoing

legitimate traffic. Pass

ICMP timestamp

requests


inundation of ICMP

timestamp request packets


hping3 issues high rate

of ICMP Type-13 packets

vSBC was configured to

deny most ICMP packet

types, including ICMP

Type-13; all packets were

discarded; no effect on

ongoing legitimate traffic.

Pass

ICMP timestamp

replies


inundation of ICMP

timestamp reply packets


hping3 issues 150 pps of

ICMP Type-14 packets







Pass



ICMP Information

requests


inundation of ICMP

information request

packets










Pass

ICMP Information

replies


inundation of ICMP

information reply packets










Pass

ICMP Unknown

type


inundation of ICMP

Unknown Type packets


Unknown Type-36

packets at 150 pps to

the SBC

vSBC dropped all of these

ICMP Unknown Type

packets. Pass

UDP flood


inundation of UDP packets

(with an unregistered IP

address) sent to visible

open SBC ports


hping3 delivers UDP

packets at 150 pps to

visible open ports on

SBC, including 5060, with


100 pps

vSBC dropped all packets

of the UDP packet flood

and issued an alarm; no

effect on ongoing traffic. Pass

TCP null flood


inundation of TCP packets

without Flag

hping3 delivers a high

rate of TCP packets

without Flag, with alarm

threshold set to 100 pps


of the TCP null flood and

issued an alarm. Pass

TCP SYN flood SBC's ability to reject an

inundation of TCP SYN

packets

hping3 delivers a high

rate of TCP SYN packets

to port 5060, with alarm

threshold set to 100 pps


of the TCP SYN flood and

issued an alarm. Pass

SNMP flood SBC's ability to reject an

inundation of SNMP Get-

request packets

Tesgine delivers a flood

of SNMP get requests,

from an unknown

source, to the SBC's

OAM port at 500 pps


of the SNMP flood.

Pass

Unknown

protocols flood


inundation of unspecific IP

packets


Tesgine delivers UDP

packets at 1,000 pps to

various ports on SBC,

including 5060, with


100 pps


of the unknown-protocols

flood and issued an alarm,

with no effect on call

traffic.

Pass



Fraggle attack; a

UDP-based DoS

attack

Whether SBC can detect

and mitigate this UDP-

based attack


hping3 delivers spoofed

UDP packets at 150 pps,

with alarm threshold set

to 100 pps

vSBC spots and discards

the rogue UDP packets,

and issues an alarm that

correctly identifies the

Fraggle attack.

Pass

IP Source Route

option, including:

Strict (SSRR

option set)

Loose (LSRR

option set)

SBC's ability to spot and

discard these attack

packets, which try to force

the SBC to route these

packets through a specific

address


Tesgine delivers IP

packets with Source

Route option set, at 500

pps to SBC's port 5060

vSBC dropped all IP-

Route-option-set packets

and issued an alarm,

correctly identifying these

as IP-option attacks.

Pass

Fragments – Too

many


discard these fragmented

UDP packets, with no

impact on call handling


hping3 delivers 60-byte

fragmented UDP packets

at 150 pps to SBC's port

5060

First set vSBC to alarm if

>20 IP fragments are

received. vSBC alarmed,

showing IP-fragment

attack; packets discarded.

No calls dropped.

Pass

Fragments –

Large offset


discard these packet

fragments, with no impact

on call handling



packet fragment with

large offsets, at 645 pps

to SBC's port 5060

First set vSBC to alarm if IP

fragments are received.

vSBC alarmed, showing IP-

fragment attack; packets

discarded. No calls

dropped.

Pass

Fragments –

Same offset




on call handling



packet fragment with

1,400-byte offsets, at

500 pps to SBC's port

5060


excess fragments are


showing IP-fragment


No calls dropped.

Pass

Fragment storm SBC's ability to spot and



on call handling



ICMP-type packet

fragments at 15,000 pps

to SBC's port 5060




showing IP-fragment


No calls dropped.

Pass

Fragments –

Reassembly with

random offsets

(Tear Drop

attack)




on call handling

With 500 calls with

media connected,

Tesgine delivers

random-offset packet

fragments at 110 pps to

SBC's port 5060; SBC set

to alarm at a high rate

exceeding the threshold




showing IP-fragment


No calls dropped, and call

quality delivering >4.0

MOS-equivalent scores.

Pass



SNMP fuzzing That the SBC can tolerate a

protracted SNMP fuzzing

attack without system

instability

With 3,600 calls

connected,

Codenomicon sends

invalid SNMP packets to

SBC's OAM port

vSBC tolerated 97,000

SNMP-fuzzing test cases

with no effect on

legitimate calls.

Pass

IPv4 fuzzing


tolerate high levels of IPv4

invalid and malformed

packets

Codenomicon launched

IPv4 fuzzing attack, with

195,000 test cases, at

SBC's signaling port

No vSBC system instability

was noted as a result of

the IPv4 fuzzing attack. Pass

TCP FIN bit with

no ACK bit

That the SBC can tolerate a

flood of these malformed

packets without affecting

operational stability

hping3 delivers packets

at >100 pps, with alarm

threshold set at 100 pps

Malformed packets were

dropped by SBC and alarm

was issued. Pass

TCP SYN and FIN

bits set





hping3 delivers packets

with SYN and FIN bits

set at 150 pps, with

alarm threshold set at

100 pps



was issued. Pass

TCP SYN

fragments,

reassembly with

overlap

(SYNDROP

attack)





Tesgine sends

fragmented SYN

requests at 110 pps, with

alarm threshold set at a

high rate exceeding the

threshold



was issued. Pass

TCP SYN Attack

with IP spoofing

Whether SBC is susceptible

to this spoofing attack,

designed to have target

send packets to itself

hping3 sends 150 pps of

spoofed TCP SYN

packets with the same

source and destination

IP as the SBC


of this attack, and issued

alarm (exceeding 100 pps). Pass

Source demotion

when invalid

message

threshold is

exceeded

SBC’s ability to find and

discard invalid messages

from non-registered users

vSBC should drop any

messages from non-

registered users

vSBC system alarm saw

invalid request from non-

registered users, 1000

background calls were

uninterrupted

Pass

Any other kind of

activities

vSBC’s ability to discard

any malformed packet or

SIP messages

vSBC should discard any

malformed packets

vSBC did not forward any

malformed packets to core

network, alarm saw

malformed packets

forwarded, 1000

background calls were

uninterrupted

Pass



9 - About Miercom

Miercom has published hundreds of network product analyses in leading trade periodicals and

other publications. Miercom’s reputation as the leading, independent product test center is

undisputed.

Private test services available from Miercom include competitive product analyses, as well as

individual product evaluations. Miercom features comprehensive certification and test programs

including: Certified Interoperable™, Certified Reliable™, Certified Secure™ and Certified Green™.

Products may also be evaluated under the Performance Verified™ program, the industry’s most

thorough and trusted assessment for product usability and performance.

10 - Use of This Report

Every effort was made to ensure the accuracy of the data contained in this report but errors

and/or oversights can occur. The information documented in this report may also rely on

various test tools, the accuracy of which is beyond our control. Furthermore, the document

relies on certain representations by the vendors that were reasonably verified by Miercom but

beyond our control to verify to 100 percent certainty.

This document is provided “as is,” by Miercom and gives no warranty, representation or

undertaking, whether express or implied, and accepts no legal responsibility, whether direct or

indirect, for the accuracy, completeness, usefulness or suitability of any information contained in

this report.

No part of any document may be reproduced, in whole or in part, without the specific written

permission of Miercom or Huawei. All trademarks used in the document are owned by their

respective owners. You agree not to use any trademark in or as the whole or part of your own

trademarks in connection with any activities, products or services which are not ours, or in a

manner which may be confusing, misleading or deceptive or in a manner that disparages us or

our information, projects or developments.

security assessment report se2900 virtualized …miercom.com/pdf/reports/20160108.pdfsecurity...

Documents