Institutionen för systemteknik - diva-portal.org17020/FULLTEXT01.pdf · Institutionen för systemteknik ... Ericsson AB is the worlds leading developer and provider of mobile radio

Institutionen för systemteknik

Department of Electrical Engineering

Master of Science Thesis

Supervision of Equipment in O&M Infrastructure

Master thesis performed in information theory by

Love Thyresson

LITH-ISY-EX--07/3988--SE Linköping 2007

TEKNISKA HÖGSKOLAN LINKÖPINGS UNIVERSITET

Department of Electrical Engineering Linköping University S-581 83 Linköping, Sweden

Linköpings tekniska högskola Institutionen för systemteknik 581 83 Linköping

Supervision of Equipment in O&M Infrastructure

Master thesis in information theory at Linköping Institute of Technology

by

Love Thyresson

LITH-ISY-EX--07/3988--SE

Supervisor: Mats Gustafsson

Examiner: Viiveke Fåk Linköping 2007-06-04

Presentation Date 2007-06-04 Publishing Date (Electronic version)

Department and Division Department of Electrical Engineering Information theory

URL, Electronic Version http://www.ep.liu.se/exjobb/isy/07/3988

Language X English Other (specify below) 52 Number of Pages

Type of Publication Licentiate thesis X Degree thesis Thesis C-level Thesis D-level Report Other (specify below)

ISBN ISRN: LITH-ISY-EX--07/3988--SE

Title of series Series number/ISSN (Licentiate thesis)

Publication Title Supervision of Equipment in O&M Infrastructure Author(s) Love Thyresson

Abstract The COMInf network is the infrastructure part of the operation and management system used for guarding the radio access networks developed by Ericsson. This thesis investigates the Ericsson COMInf network; identifies problems covering both functional as well as security aspects of the network and its current monitoring solution, and also presents a set of requirements and recommendations for a future network surveillance solution. As this thesis shows, the COMInf network today has limited functions regarding both network and security supervision. However, implementations of such solutions are possible due to the standardized components used in the network today. Toimprove the COMInf network, this thesis defines requirements and recommends a network surveillance solution which fulfills these requirements. It is also recommended to update some of the hardware currently in place for the COMInf network.

Keywords Computer networks, Computer security, Network supervision, Network surveillance.

Abstract

The COMInf network is the infrastructure part of the operation and management system used for guarding the radio access networks developed by Ericsson. This thesis investigates the Ericsson COMInf network; identifies problems covering both functional as well as security aspects of the network and its current monitoring solution, and also presents a set of requirements and recommendations for a future network surveillance solution. As this thesis shows, the COMInf network today has limited functions regarding both network and security supervision. However, implementations of such solutions are possible due to the standardized components used in the network today. To improve the COMInf network, this thesis defines requirements and recommends a network surveillance solution which fulfills these requirements. It is also recommended to update some of the hardware currently in place for the COMInf network.

iii

iv

Acknowledgements

During the course of this thesis work I have had help from a number of people. I would like to thank my supervisor at Ericsson, Mats Gustafsson for helping me with contacts and feedback throughout this thesis project. Of course, I would like to thank Viiveke Fåk, my examiner at the University of Linköping for providing valuable insight on my report and guiding me in the right direction. To Stefan Werna, my manager; a big thank you for giving me the opportunity to do my thesis project at Ericsson. Also, Mark Brocklebank deserves much credit for giving me great insight into the work being carried out at Ericsson UK. Naturally, I would also like to thank Fredrik Lindholm, my opponent, and last but not least, I would like to thank Shreya Pallavi who has been a constant pick-me-up during the many days of this project. - Love Thyresson, a warm spring day, April 26, 2007, Linköping, Sweden.

v

vi

TABLE OF CONTENTS 1. INTRODUCTION ..........................................................................................................................1

1.1. ABOUT THIS THESIS ..................................................................................................................1 1.2. PURPOSE ....................................................................................................................................1 1.3. PROBLEM DESCRIPTION.............................................................................................................1 1.4. CONTRIBUTIONS ........................................................................................................................2 1.5. PRIOR WORK .............................................................................................................................2 1.6. SCOPE ........................................................................................................................................3 1.7. OUTLINE ....................................................................................................................................3 1.8. READING INSTRUCTIONS............................................................................................................3

2. COMPUTER SECURITY .............................................................................................................5 2.1. BACKGROUND ...........................................................................................................................5 2.2. THE CIA MODEL .......................................................................................................................5 2.3. TRUST........................................................................................................................................5 2.4. THREATS....................................................................................................................................6 2.5. SOFTWARE SECURITY ................................................................................................................6 2.6. SECURITY AWARENESS..............................................................................................................7

3. NETWORK SECURITY ...............................................................................................................9 3.1. ANALYZING AN ATTACK: THE FIVE P:S.....................................................................................9 3.2. INTRUSION DETECTION SYSTEM ..............................................................................................10 3.3. INTRUSION PREVENTION SYSTEM ............................................................................................11 3.4. IDS AND IPS DETECTION.........................................................................................................11

4. NETWORK MANAGEMENT....................................................................................................13 4.1. REQUIREMENTS FOR A NETWORK SURVEILLANCE SYSTEM .....................................................13 4.2. FCAPS ....................................................................................................................................13 4.3. SIMPLE NETWORK MANAGEMENT PROTOCOL.........................................................................15

5. COMMON OPERATIONS AND MAINTENANCE INFRASTRUCTURE ..........................19 5.1. OVERVIEW...............................................................................................................................19 5.2. SERVICES.................................................................................................................................20 5.3. AUTHENTICATION SERVICES ...................................................................................................20 5.4. NETWORK INFRASTRUCTURE ...................................................................................................21

6. ANALYZING THE COMINF NETWORK...............................................................................23 6.1. COMINF NETWORK COMPONENTS..........................................................................................23 6.2. COMINF SERVERS...................................................................................................................25 6.3. SECURITY MECHANISMS..........................................................................................................25 6.4. CONCLUSION ...........................................................................................................................26

7. REQUIREMENTS .......................................................................................................................27 7.1. BACKGROUND .........................................................................................................................27 7.2. RISK ASSESSMENT...................................................................................................................28 7.3. DRAFT REQUIREMENTS............................................................................................................28 7.4. RATING THE REQUIREMENTS ...................................................................................................31 7.5. ANALYZING THE REQUIREMENTS ............................................................................................36 7.6. FINAL REQUIREMENTS.............................................................................................................36 7.7. SECURITY CONSIDERATIONS....................................................................................................40 7.8. REQUIREMENT CONCLUSIONS .................................................................................................41

8. EVALUATION OF CANDIDATE SYSTEMS ..........................................................................43 8.1. EVALUATION CRITERIA ...........................................................................................................43 8.2. EVALUATION CONCLUSIONS....................................................................................................44

9. SUMMARY AND CONCLUSIONS ...........................................................................................47

vii

9.1. RECOMMENDATIONS................................................................................................................47 9.2. FUTURE WORK ........................................................................................................................48

10. GLOSSARY ................................................................................................................................49 11. BIBLIOGRAPHY.......................................................................................................................53

11.1. REFERENCES..........................................................................................................................53 11.2. LINKS.....................................................................................................................................54

viii

Chapter 1 - Introduction

1. Introduction

This chapter gives a brief overview of the structure and purpose of this thesis. It also includes reading instructions which can be found in section 1.8.

1.1. About This Thesis

This Master of Science thesis has been carried out as the final part of the author’s masters’ degree in computer science at the University of Linköping in spring/summer of 2007, Linköping, Sweden.

1.2. Purpose

Ericsson AB is the worlds leading developer and provider of mobile radio networks. These radio networks may cover large areas and are often an important part of a nation’s infrastructure. Because of the extreme demands regarding system uptime; supervision and security are both very important factors in preventing different kinds of system failure. As a provider, Ericsson needs to be able to guarantee system uptime, i.e. avoid outage and downtime because of failure related either to the systems itself, or due to external threats. In order to meet these requirements Ericsson uses a operation and maintenance system called Operations Support System, Radio and Core (OSS-RC). A specific part of this system is the Common Operations and Maintenance Infrastructure (COMInf). The primary tasks of COMInf are:

• To provide infrastructure services to OSS-RC and radio access networks • To provide a strong security separation between the radio access networks and

the mobile operators In critical systems such as OSS-RC, all system maintenance and configuration must be carried out during system operation. Ericsson has the ambition to guarantee a 99.999% system uptime. This corresponds to approximately 5 minutes downtime a year, including planned system upgrades. Since COMInf is such a vital component to keep the radio network operational, Ericsson is interested in ways to supervise COMInf operation.

1.3. Problem Description

COMInf is an essential part of the Operations and Maintenance (O&M) section of the radio networks, weather it be second generation Groupe Spécial Mobile (GSM) or third generation Universal Mobile Telecommunications System (UMTS). The purpose of the COMInf network is to provide services and infrastructure components for the O&M network.

1


COMInf in itself is made up of a variety of servers, often deployed in a redundant fashion. The COMInf network can be deployed in several different ways depending on customer requirements. In order to ensure the stability of the radio access network, the stability and security of the COMInf network is important. In case of failure of the COMInf network, either by failure during normal operations, or due to unauthorized modification of the system, the functionality and stability of the radio access network is at risk. Today, the hardware and software versions in the COMInf network may differ between installations. Even though the initial versions deployed are based on an official Ericsson release, software may be patched and/or upgraded based on customer requirements. Because of the variance in COMInf setups, maintenance, as well as ensuring network stability, grows increasingly difficult. To simplify maintenance of the COMInf network, it is desired to automate the process of making software and hardware version inventory. It is also desired to get real time status for the hardware and software processes running in the COMInf network. As the COMInf network is critical for the O&M of the radio access network, security aspects are also essential.

1.4. Contributions

This thesis investigates solutions to the problems identified in chapter 1.3. It formulates a set of system specific requirements and develops a rating system for measuring these requirements. Finally, this report presents a list of recommendations for both a network surveillance solution as well as future work.

1.5. Prior Work

Solutions for monitoring and analyzing networks exist today. The predominant underlying technology used is Simple Network Management Protocol (SNMP), SNMP is a technology for supervision and control of network devices. This protocol has been standardized by the Internet Engineering Task Force (IETF) and is currently at version 3. SNMP is explained in more detail in chapter 1. While there exist solutions for security supervision, none of them are as standardized as the surveillance solutions that exist for the network devices. Security supervision is still an area under rapid development. An overview of some of the existing solutions is presented in chapter 3.

2


1.6. Scope

This thesis will be limited to supervision and security aspects of the Ericsson COMInf network. It does not cover network setup and/or design, nor shall it be used as a general guide for either network surveillance or network security.

1.7. Outline

This thesis is divided into 11 chapters. Chapter 1 presents the goal of this thesis project, its purpose, scope, outline and reading instructions. Chapter 2, 3 and 4 provides theory on both computer and network security as well as network management while chapter 5 presents a common COMInf setup. Chapter 6 moves on to analyze the COMInf network and in chapter 7 requirements for a network surveillance solution is presented. Chapter 8 begins to evaluate some candidate systems. Finally, chapter 9 concludes this thesis project and gives some future recommendations for future COMInf development. Chapter 10 and 11 provides glossary and bibliography for the terms and references used throughout this report.

1.8. Reading instructions

For staff within Ericsson and more specifically within COMInf development chapters 1, 7, 8 and 9 might be of interest. For people interested in network management and security in general, suggested reading is the complete report.

3


4

Chapter 2 - Computer Security

5

2. Computer Security

To be able to understand the different terms and aspects of computer security, primarily in the field of network surveillance, this chapter provides fundamental definitions frequently used in this topic.

2.1. Background

As a basis for this rapport, this thesis uses the definition from “Computer Security – Second Edition” by Dieter Gollmann, [3].

2.2. The CIA Model

To main three values that need to be protected in a computer system are:

• Confidentiality The task of preventing harm from unauthorized disclosure of information.

• Integrity The task of preventing harm from unauthorized and accidental modification of information and provide consistency.

• Availability The task of preventing unauthorized withholding of information or resources.

The different areas of the CIA model correspond to the three main values in computer security. Sometimes, a fourth aspect is mentioned:

• Non-repudiation This deals with the problem of proving that some specific individual has indeed performed a certain task, e.g. a bank transfer. However, for the scope of this thesis, the definition used only includes the CIA aspects.

2.3. Trust

Computer security is based on the notion of trust, or rather, lack of trust. Systems are secured using different techniques to eliminate the need for trust in hardware, software and users – and ultimately provide all of the three CIA aspects. Security in computer systems can be defined using a chain of trust. The chain of trust has to cover everything from the hardware and software installed on the machine to the person using the machine. If any of these trusted sources fail in some way, the chain of trust will be broken and hence, the system can not be considered secure. As all users of a system have to be trusted to be able to provide security, this makes multi user systems an especially difficult area to protect as every single user has to be trusted. Today, this task is most difficult, due to the exposed environment in which most computers exist, i.e. the Internet. This does in turn force computer systems to eliminate the trust in the user by the use of secure hardware and software.


6

2.4. Threats

Kerry & Greg categorize an attack on a network based on its origin; intrusions, insider attacks and abuse, [1]. It is important to distinguish between these three types as the protective measures required often are quite different. The different techniques used are explained in more detail in the following chapter.

2.4.1. Intrusion A typical example may be an individual trying to breach into a company’s computer system to steal sensitive information. This person has no prior access to the company’s systems and has to penetrate everything from the firewall protecting the network to individual servers inside the network to accomplish his/hers goal. This is by far the easiest attack to spot using modern intrusion detection techniques.

2.4.2. Insider Attack In this scenario, the individual may be an employee at the targeted company and hence, already has some sort of access. Often this access is restricted to a specific set of resources. It is when this individual accesses resources he or she is not supposed to access, possibly by circumventing security features, that the attack occurs. This is an insider attack and this is more difficult to detect.

2.4.3. Abuse This is the kind of attack that is, by far, the most difficult one to detect. In opposite to an insider attack, here, the individual performing the attack is actually authorized to access both the system and the resources. It is when this individual abuses the trust he or she has been given and accesses information with the intent to give it to a third party, that this is a case of abuse.

2.5. Software Security

Most, if not all, products on the market today are likely to have security vulnerabilities. The demands from the consumer market industry as well as financial interest drive companies to release products (i.e. software and hardware releases) even faster. As products are forced to be developed at such a rapid pace, security purposes are overlooked and not tested. This combined with the difficulties of testing for errors resulting in vulnerabilities often lead to increasing amounts of bugs and exploits in software, either by off-the-shelf software products or by firmware within hardware. In order to keep a system as secure as possible, it’s necessary to keep software in the system up to date. The balance between updating a system to provide increased security and not updating the system and maintaining stability is often a problem for networking staff; this is often solved by using a test system which delays security critical updates while the updates are evaluated in terms of stability and reliability. This might, of course, differ between systems as some systems have high demands regarding availability and other ones on security. It is however important to keep a track on security updates. Good sources for security related matters are the web sites of Securityfocus, Securitytracker, CERT and SANS, see chapter 11.2.


7

2.6. Security Awareness

One method commonly used to obtain sensitive information is social engineering. Social engineering is the task of tricking an individual in to handing out sensitive information (this is often a password or a login) and this is actually a very common method of gaining access to systems today. According to a survey, [4], 34 percent of users would be willing to hand out their password if someone asked them, and 70 percent would say no to the first question, but agree if they were given a bar of chocolate. Security awareness does not only include protection from social engineering attacks. It is just as important to educate users in areas such as safe internet browsing, etc.


8

.

Chapter 3 - Network Security

3. Network Security

To fully be able to understand the security measures in place in the COMInf network today as well as future recommendations presented in this report, this chapter explains the different stages of an attack as well as a description of systems commonly used to protect against network attacks.

3.1. Analyzing an Attack: The Five P:s

In order to get a better overview of an attack it can be good idea to divide it into different parts. The anatomy of an attack can be divided into five steps; Probe, Penetrate, Persist, Propagate and Paralyze, [1]. These five P:s will be briefly explained below. These different stages will be used to describe the security mechanisms later in this chapter.

• Probe Here, the attacker tries to find vulnerabilities of the targeted system or systems. This is often accomplished by port scanning a range of IP addresses to find open ports and determine what services and software versions are running. Even if there are instances when an attacker targets a specific system this is highly unlikely.

• Penetrate In this phase the attacker tries to penetrate the system. This can be done in a variety of forms ranging from bringing a system down using a DoS attack, to gaining administrative privileges by exploiting a known vulnerability in a service running on the targeted system.

• Persist Launching an attack repeatedly against the same system seriously increases the risk for detection. Therefore, an attacker often tries to establish some kind of backdoor into the system to be used for future intrusions. One common example is for the attacker to add an administrative level user, or brute force the password file in the system to gain the password of an existing user. Later on, such accounts can be used for system access. There is also the possibility of adding a service to the system, e.g. by installing a backdoor service on a port already open in the firewall. As the attacker needs to cover his or her tracks, log files are often deleted and/or modified in the compromised systems to erase any sign of intrusion.

• Propagate Once an attacker has established his or her presence on a machine, the next step is to try to propagate the attack through the network. That is, scan for and attack other machines in the vicinity of the compromised system. In the case of single sign-on systems used in many organizations today, the attacker can potentially access systems he or she would never have gained access to from the outside. Potentially, this includes company trade secrets.

• Paralyze This stage is often the goal of the attack. It usually involves stealing of

9


sensitive information, destruction of data or even shutting down entire systems. The goal of the attack is often to reach the company’s most sensitive information, often concentrated to database servers.

3.2. Intrusion Detection System

Intrusion Detection Systems (IDS:s) is a type of system used to monitor network traffic and raise an alarm upon intrusion. There are mainly two different IDS deployments. One is called Network IDS, NIDS, and the other one Host-based IDS, or HIDS. In section 3.2.1 and 3.2.2 a brief overview of the two technologies is presented.

3.2.1. Network IDS A typical NIDS is setup according to Figure 3-1.

Figure 3-1: A typical NIDS setup A NIDS, like the name implies, listens to network traffic and analyzes all information passing by (it does not even need its own network address). Based on some predefined ruleset it classifies the passing traffic as either an attack or normal network activity. This ruleset (in many cases) is usually handed out by the IDS vendor. However, as large corporations often do not wish to wait for the IDS vendor to issue new rulesets; it is quite common that system administrators develop their own rules in order to be protected from what is commonly known as zero-day attacks. Zero-day attacks is an attack that takes place after an exploit has been made public and before a fix has been issued. IDS:s have to be configured very specifically to their target environment. If not carefully tuned to the specific network they are protecting, they will generate just as many (if not more) false positives as they will be identifying real threats and attacks to a system.

10


3.2.2. Host-based IDS While a HIDS may listen on network traffic, it only listens on the host it resides at. The main difference is that since a HIDS has the advantage of actually residing on the host it’s protecting, it can also be installed to monitor the information flow within the operating system also covering log files, memory etc. A HIDS can have quite a lot of similarities with modern antivirus software in this fashion, they both monitor calls to and from the kernel, and they both compare these to some sort of signature database.

3.2.3. NIDS vs. HIDS There are important differences between a NIDS and a HIDS to be aware of. For one, a HIDS mostly has access to unencrypted information while a NIDS can de defeated if the passing data has been encrypted. Today, this is a quite common scenario as end-to-end encryption increases rapidly in applications, especially when it comes to security critical applications such as connecting to an online bank using HTTPS. This is an example of how one mechanism used to provide security also make the NIDS, which is actually there to protect the same users, blind. Both HIDS:s and NIDS:s may incorporate various forms of behavioral systems in order to distinguish normal system behavior from abnormal behavior that may indicate an attack. However, these systems are still mostly experimental and may have severe problems in distinguishing between an attack and an unexpected change in system information. Installing new software on a server might, from the IDS point of view, generate abnormal system calls or traffic that can be interpreted as malicious content.

3.3. Intrusion Prevention System

Although the theory differs between writers, the most common description of an Intrusion Prevention Systems (IPS:s) is an IDS with prevention measures. An example of an IPS action can be to shut down a port in a firewall, blocking an IP-address or even execute countermeasures such as launching a counter attack. Because IPS:s actually do take action, it makes configuration of such devices extremely important. When an IDS might classify valid traffic as an attack (false positive), all that really happens is that an alarm goes of. An IPS on the other hand will take action, possibly blocking this connection, leaving an employee or customer without the access to which they are entitled. Hence, a misconfigured IPS may leave the company in a denial-of-service situation.

3.4. IDS and IPS Detection

By port scanning a system, an attacker can establish the ports on a target system that are open for an attack. Port scanning a system is often the first stage (Probe) of an attack. As tools for port scanning is available for free on the Internet this is probably the most common attack used today. IDS:s systems today are very competent at detecting this kind of attack pattern. However, as an IDS only detects and warns about

11


the potential threat, it is still up to the system administrator to block the malicious traffic. An IPS might on the other hand be able to block the traffic with the downside of blocking permitted traffic based on false positives. As for the remaining stages, all but the last stage (Paralyze) can be detected. However, this is only true if the IDS or IPS is setup to also monitor the internal network. Preferably one IDS/IPS is used to guard the external network and firewall setup while another one is in place to guard the internal network. Remember, an IDS/IPS can be just as effective in protecting from insider attacks as it is in protecting from intrusion.

12

Chapter 4 - Network Management

13

4. Network Management

Regarding network management; Mauro and Schmidt makes the following definition:

“Network management is a general concept that employs the use of various tools, techniques, and systems to aid human beings in managing various devices, systems, or networks”, [5].

This chapter describes basic principles for a network surveillance system and the FCAPS model.

4.1. Requirements for a Network Surveillance System

In order to implement a network surveillance system, it is important to have a thorough understanding of the target network before implementation begins. This can lead to a study of inventory. In many organizations, there has to be a financial basis for implementation. This financial investigation is often accomplished by performing a risk assessment analysis where the cost of implementation and maintenance is carefully weighed against the cost for a successful intrusion or system malfunction. While a network surveillance solution cannot prevent system malfunction on its own, it does provide the tools and mechanism which can aid system administrators in preventing problems with either network devices, or individual servers and/or services and primarily, it can help system administrators to be aware of the problem a lot sooner. In some cases, e.g. bank systems, the cost for system intrusion and/or failure might be so high as to motivate nearly any cost of prevention.

4.2. FCAPS

Network management can be based on a model called FCAPS, Fault management, Configuration management, Accounting management, Performance management, and Security management. The model was originally developed by International Telecommunication Union – Telecommunications branch, or ITU-T, and is a defined in the standard M.3400 – Telecommunications Management Network: Management functions, [6]. The definition used in this thesis is taken from Douglas R. Mauro and Kevin J. Schmidt, [5], and has been adapted to better suite the telecommunications industry.

4.2.1. Fault Management Fault management plays a very important role in helping the operator to quickly and efficiently act on faults which occur in equipment. This contributes to minimizing system downtime. Fault management can be described as detecting, logging and notifying users, systems and networks of problems. Fault management is based on the three following steps:


14

1. Isolate the problem by using tools to determine symptoms.

2. Resolve the problem.

3. Record the process that was used to solve the problem.

In practice, the last step is often omitted. This does in turn often lead to waste of resources as engineers could have followed a simple guideline instead of performing steps 1 and 2 all over again.

4.2.2. Configuration Management Configuration management handles monitoring and supervision of the network itself, but also of the machines on the network. This is carried out in order to track changes in the hardware and software versions within the network and to identify possible problems. As a network administrator, the following system configuration parameters are usually of interest:

• Operating system and version of the OS

• Service versions of different software

• Hardware specifications (CPU, RAM, etc.)

This information is often stored in a centralized database for easy access and can be most helpful during trouble shooting. What is classified as interesting information differs greatly from system to system as well as between network administrators.

.

4.2.3. Accounting Management The goal of accounting management is to ensure that computing and network resources are distributed more evenly in accordance with their actual requirements, e.g. by the use of disk quotas, etc. This does in turn often reduce network problems by minimizing the risk for congestion due to a more efficient use of resources.

4.2.4. Performance Management Performance management is used to see how resources are used and handles measuring and reporting on deviations from, what is considered to be, normal network or system performance. The three steps often associated with performance management are:

1. Collection of performance data.

2. Establishing baseline levels for normal system and/or network performance.

3. Establishing performance thresholds. When these thresholds are exceeded, it is likely that a problem requires attention.

Performance management can be most helpful in detecting problems before they escalate into system failure. An example could be an Internet Service Provider (ISP) which monitors the response time of its mail servers.


15

4.2.5. Security Management Security management can be divided into two sections. First, it handles resource access control to networks and hosts. Second, it handles network supervision and aids in detecting potentially malicious network traffic. In some cases it even handles prevention of attacks; this is described in more detail in chapter 3.

Attacks on the network can lead to failure with respect to one or more of the three CIA aspects. Most often this includes Denial of Service attacks (DoS), but in more severe cases it may also result in attackers gaining access to important systems and/or stealing sensitive data.

Security management does not only apply to network and host security, but also to physical security. This could be access control to enter a building, server room, etc. The goal here is to ensure that access to vital systems is only handed out to those who really need it to perform their duties.

Today, network security is often accomplished using various controls. Some examples of these controls might be:

• Firewalls

• Intrusion Detection Systems

• Intrusion Prevention Systems

• Antivirus systems

• Policy management and enforcement systems

Security management often integrates with configuration management through the use of the Simple Network Management Protocol (SNMP).

4.3. Simple Network Management Protocol

The Simple Network Management Protocol is, despite the name, a quite advanced and powerful protocol. It exists in a variety of versions ranging from the original SNMPv1 to SNMPv2c and SNMPv3. It is an Internet standard protocol for managing IP devices on IP networks.

4.3.1. Area of use Today, most network devices acting in an IP environment support SNMP. The way SNMP can be used ranges from fairly simple tasks such as monitoring the health of routers, switches, printers and other pieces of network hardware, to more complex tasks such as actually controlling the devices in the network, raising alarms upon deviation from performance thresholds and in some cases even execute actions.

4.3.2. Managers and Agents In the world of SNMP, there are two types of entities; managers and agents. A manager is a server running some kind of software that can handle management tasks for a network. Managers are often referred to as Network Management Stations (NMSs). The purpose of the NMS is to collect data from agents and using traps and polling techniques. Traps and polling represents two different aspects of communication within SNMP. A trap is a way for an agent to let the manager know something has happened, while a poll is a way for the manager to query an agent on


16

specific values, e.g. the speed of a network interface. Two different polling techniques are used, internal polling and external polling. This is described in more detail in section 4.3.6. Figure 4-1 describes a typical example of a relationship between a manager and an agent.

Figure 4-1: Relationship between a manager and an agent

4.3.3. Structure of Management Information SNMP use a notation called Structure of Management Information (SMI). SMI is a subset of Abstract Syntax Notation One (ASN.1) and a part of SNMP to define managed objects and their behavior. The three defined types are MIB modules, compliance statements and capability statements.

NMS (Manager)

Agent

Trap sent to NMS

Query sent to the agent

Response to query sent from the agent to the NMS


17

4.3.4. Management Information Base A Management Information Base (MIB) is a collection of information that is hierarchically organized. A MIB is constructed using the SMI syntax and describes some particular object. This can be everything from the system administrators name to the number of IP packets that has passed through a routers interface.

Root-NodeRoot-Node

ccit(0)ccit(0) iso(1)iso(1) joint(2)joint(2)

org(3)org(3)

dod(6)dod(6)

internet(1)internet(1)

directory(1)directory(1) mgmt(2)mgmt(2) experiminetal(3)experiminetal(3) private(4)private(4)

mib-2(1)mib-2(1)

system(1)system(1) interfaces(2)interfaces(2) at(3)at(3) ip(4)ip(4) icmp(5)icmp(5) tcp(6)tcp(6) udp(7)udp(7) egp(8)egp(8) snmp(11)snmp(11)transmission(10)transmission(10)

Figure 4-2: An OID structure including the MIB-II MIB The MIB structure allows for a generic way to control (set) and monitor (get) network devices and agents.

4.3.5. Accessing SNMP agents In order to access an SNMP agent and its localized MIB objects, a special form of naming scheme is used called Object Identifier (OID). OID:s are globally unique and used in everything from SNMP to specific enterprise naming schemes. As described in Figure 4-2 the MIB is organized hierarchically and the objects are accessed using their identity. The ID can be expressed using either their name (e.g. iso) or their corresponding OID (in the case of iso, this is 1), using dots to indicate hierarchy. An example could be iso.org.dod.internet.mgmt.mib-2.ip (bold in the figure) or simply 1.3.6.1.2.1.4 which is the corresponding decimal notation. This refers to the IP part of the MIB-II MIB.


18

4.3.6. Extensible Agents In some cases, the standard agent might not provide all the functionality needed. At that time, it is possible to use an extensible agent. An extensible agent is an agent which is extended by adding or changing its current MIB definition. This way it is possible to adapt the agent to its environment. An example of an extensible agent is the System Management Agent (SMA) by Sun, see section 7.4.4. An extensible agent makes it possible to retrieve values based on output from system commands or shell scripts. This can be helpful when it comes to monitoring of system specifics, e.g. process status, disk space utilization, etc.

4.3.7. Remote Monitoring Remote Monitoring (RMON) is a special means of communication between managers and agents. It is a supplement to the MIB-II group (MIB-II is an SNMP specification for extensive IP interface information, see RFC 1213 in the section 11.2) and, if supported by the device’s SNMP agent, provides the ability to do both internal and external polling. This can be done either by letting the manager poll the agent, or by letting the agent poll the device itself continuously and then report errors as they occur. The second approach seriously decreases network load as no continuous polling will have to be done from manager to agent in order to raise alarms. Of course, external polling will still have to be performed in order to monitor network status.

Chapter 5 - Common Operations and Maintenance Infrastructure

19

5. Common Operations and Maintenance Infrastructure

The main management system in the O&M network is called OSS-RC, a part of the Ericsson O&M network. A part of the OSS-RC product family is the COMInf network which provides infrastructure services to the radio access networks. The radio access networks can be either second generation GSM systems or third generation UMTS/WCDMA systems.

5.1. Overview

The COMInf network provides OSS-RC with services and infrastructure components, see Figure 5-1.

Figure 5-1: OSS-RC network overview


20

The purpose of the COMInf network is:

• To provide separation between the radio access network and the users of OSS-RC

• To provide infrastructure services to OSS-RC and ultimately to the radio access network

5.2. Services

COMInf supports a variety of services such as:

• DHCP (Sun DHCP or Ericsson IPWorks) A protocol used to hand out IP addresses to hosts.

• DNS (BIND or Ericsson IPWorks) A protocol used to translate domain names into IP-addresses.

• NTP A protocol used to synchronize time between computers.

• SMRS An Ericsson specific service used to provide storage functionality for easy distribution of upgrade packages to radio access base stations and radio network controllers in the radio access networks.

Note: Ericsson IPWorks is a suite providing both DHCP and DNS services.

5.3. Authentication Services

The authentication services within COMInf include:

• SLS – Single Login Server Used to authorize users against the DS

• DS – Directory Service A database for storing users

• PKS – Public Key Server Used to provides certification authority functionality.

• CAAS Used to provide authentication and authorization services.


21

5.4. Network infrastructure

In addition to infrastructure components, the COMInf network provides important security features. This includes segmenting the COMInf network into different Virtual Local Area Networks (VLANs). The COMInf infrastructure consists of:

• Firewall • O&M router • Network switch • X.25 O&M router

Note: The X.25 O&M router is only needed in case of GSM over X.25. Today, GSM

is installed using GSM over IP.


22

Chapter 6 - Analyzing the COMInf Network

6. Analyzing the COMInf Network

In this chapter, an analysis of the COMInf network is presented. The network is broken down into its infrastructure components and typical hardware used in COMInf is analyzed.

6.1. COMInf Network Components

The networking equipment used in COMInf varies between customers. There are, however, recommendations from Ericsson on specific networking equipment to use. The equipment described here is an example of the networking equipment used in a typical COMInf setup. It can also serve as a basis for understanding the type of management support typically found in products today.

6.1.1. Firewall Router For GSM or small WCDMA networks Ericsson recommends Juniper Networks NetScreen 208 and for large WCDMA networks or WCDMA/GSM combinations the Juniper Networks NetScreen 500ES model is recommended. Data sheets for both models can be found in appendix A. Features:

• VPN (Virtual Private Network) support • VLAN support • Basic IPS Protection • SNMPv1 and SNMPv2c with custom MIB support

Performance:

The NetScreen 208 is a 8 port firewall router/VPN solution supporting up to 100 Mbps (10/100 auto-sensing) on each port. It is capable of handling firewall routing at up to 375 Mbps, while dropping to 175 Mbps when 3DES or AES encryption VPN:s are used. The NetScreen 500ES is a layer 3, 8 port firewall router/VPN solution with built in DoS protection. It is capable of handling firewall throughput at 700 Mbps while dropping to 250 Mbps when strained with 3DES or AES encryption using VPN.

Security:

A brief investigation of the security in these products reveals some security issues. Although all of them have already been addressed by Juniper Networks and supplied patches are available, it is critical that the customer actually install these updates. For instance, in ScreenOS (the operating system in these products) version 5.2 and earlier, it is possible to extract the username and password for administration of the products using brute force and man-in-the-middle (MITM) attacks, [7].

Note:

• The current shipping version of ScreenOS is 5.4.

23


• None of the routers support the security provided by SNMPv3.

6.1.2. O&M Router For GSM networks Ericsson recommends the Juniper Networks M7i router while recommending the Juniper Networks M20 router for WCDMA and WCDMA/GSM combinations. Features:

• VPN support • VLAN support • SNMPv2c and SNMPv3 with custom MIB support

Performance:

The M7i has a total throughput of 8.4 Gbps in half duplex mode, or 4.2 in full duplex. The M20 has a total throughput of 12.8 Gbps in half duplex mode or 6.4 in full duplex.

Security:

The entire range of M-series routers from Juniper Networks makes use of the JUNOS software. This also makes them vulnerable in case of flaws found in that software. At the time of writing, the latest flaw found was in June 2006 and provided a way to crash the router using a bug in the handling of IPv6 packets. Although the vendor has released a fix for the problem, this again demonstrates the importance of keeping software up to date, [8].

Note:

All versions of JUNOS released after 10 may 2006 contains the corrected code.

6.1.3. Network Switch For small WCDMA or GSM networks Ericsson recommends the Extreme Networks Summit 5i while recommending the Extreme Networks Summit 7i for medium or large WCDMA or GSM networks. Features:

• VLAN support • SNMPv3 support

Performance:

The Summit 5i supports a total of 16 ports at 100/1000 Mbps speeds, while the Summit 7i provides a total of 32 such ports.

Security:

A basic search on different security sites (see the links section in chapter 11) for security flaws reveals no exploits for the products.

24


6.2. COMInf Servers

The servers within COMInf make almost exclusive use of the Solaris operating system even though there might be a few servers running Windows (mainly Windows Application Server). This makes it easy to maintain supervision and monitoring of processes and services through the use of SNMP. The security of both the Solaris and the Windows platform can only be guaranteed as long as the services they provide can be considered secure. It is therefore important that the machines stay updated with the latest security fixes.

6.3. Security Mechanisms

The security in the COMInf network is focused on internal protection, primarily by preventing the OSS-RC users from directly accessing the COMInf servers and the OSS-RC master server. There is a strong separation between the users of OSS-RC and the servers, mainly by the use of firewalls. Secure SSL (Secure Socket Layer) tunnels are used to provide the integrity and confidentiality aspects of the connection to the citrix licensing servers. OSS-RC users are only permitted to access a set of servers designed for operational tasks and never come in direct contact with the master server, see Figure 6-1.

Figure 6-1: Separation between users and servers

25


6.4. Conclusion

This analysis of the COMInf network setup shows that all devices and servers are capable of supporting a surveillance solution utilizing SNMP. There are however some drawbacks, SNMPv3; the only version of SNMP to provide real security features, is not yet supported by all manufacturers. This does in turn force the surveillance system to rely on the security measures of SNMPv2Cm which are recognized to be inferior. While SNMPv3 provides increased security, the only real difference between version 2 and version 3 is the ability to encrypt traffic between end-nodes, and secure authentication between managers and agents. As the COMInf network is quite isolated, the lack of security provided by SNMPv2c might not be such a critical factor as it would have been in case of a public network. However, one important aspect is to set all SNMP devices in a read-only mode, this makes the network devices less sensitive than if MIB updates are allowed. With regards to redundancy, the COMInf network is deployed redundantly in almost all aspects. Single-points-of-failure are the network switch, firewall router, O&M router and possibly the X.25 router. That makes monitoring of these devices very important in a surveillance perspective. As far as security is concerned, the security mechanisms in place today are aimed at separating the users of OSS-RC from accidentally damaging the system. External threats to the COMInf network are limited, primarily because the network is shielded from other networks by the use of firewalls and in some cases even physical connection. At the moment, these mechanisms provide a sufficient level of security.

26

Chapter 7 - Requirements

27

7. Requirements

To both make network and server administration easier, and to provide a better overview of the network itself, a surveillance solution is desired. This surveillance solution should provide functionality for both monitoring of servers and processes as well as networking equipment. It should cover functional as well as security aspects of the COMInf network. In order to provide the best possible solution for supervision and monitoring of the COMInf network, it is desired to provide a set of requirements for evaluating different solutions. In this chapter, requirements are evaluated, discussed and rated according to a rating system developed for this thesis. COMInf today uses no form of supervision, neither for monitoring of services and network status nor for security purposes. Since both the servers and the networking equipment that make up COMInf are critical for the functionality of OSS-RC, it is desired that the stability of the COMInf network can be monitored.

7.1. Background

Chapter 6 describes some typical hardware that is often used in a COMInf network. The only protocol supported by both hardware and software is SNMP and as no alternatives exist, this study is limited to SNMP. As a first step towards generating requirements, some basic points of interest for monitoring and supervision are presented in the following sections. In section 7.5 the derived requirements are analyzed and rated in order to finally rank these requirements in order of importance and total score. This later on serves as a basis for the candidate systems presented in chapter 8.

7.1.1. Infrastructure Components This section presents some possible measurements that might be of interest: • O&M router

o Traffic flow per port o Total traffic flow o Dropped/discarded packages o Temperature

• Firewall router o Traffic flow per port o Traffic flow per VLAN o Total traffic flow o Dropped/discarded packages o Temperature


28

• Network switch

o Traffic flow per port o Traffic flow per VLAN o Total traffic flow o Interface speed o Temperature

• X.25 router

o Inbound traffic (X.25) o Outbound traffic (IP) o Dropped/discarded packages o Temperature

Note: The X.25 router only exists when interfacing with GSM over X.25.

7.1.2. COMInf Servers The following section presents some measurements of interest for the servers in the COMInf network.

• Server uptime • Network traffic in/out • Number of processes running • Disk space utilization • CPU utilization • Memory utilization • Specific monitoring of individual processes (such as BIND, DHCP, etc.) • Temperature

7.2. Risk Assessment

Because a risk assessment analysis depends very much on customer specific parameters (e.g. cost for downtime, cost for maintenance, etc.) a complete risk assessment analysis is not feasible. Instead, this thesis presents some other threats that the COMInf network could face, using the knowledge and expertise of Ericsson personnel. Section 7.3 presents requirements based on both this information as well as the basic theory behind network surveillance systems.

7.3. Draft Requirements

The requirements have been divided into two sections. The first section presents functional requirements for supervision and based on the existing theory, while the second one is based on contact with staff within Ericsson. The requirements are limited to system parameters. Physical requirements are not covered in this thesis project.


29

In section 7.3.1 possible requirements based on theory of the subject are presented. Section 7.3.2 presents the requirements gathered from informal interviews with staff at Ericsson. These requirements are analyzed and rated in section 7.4 and finally presented in chapter 7.5.

7.3.1. Draft Requirements Based On Theory Theory on network surveillance predominantly covers company networks, ISPs etc. which can be private or public systems often connected to the Internet. The COMInf network is different in this respect as it is normally (this is up to the customer) shielded from the Internet. However, the hardware and software in the network are still mostly standardized components and are as such subject to monitoring using existing network surveillance techniques. The requirements in this section have been derived using existing theory on network surveillance.

• Support for SNMP:

o SNMPv1 Not acceptable

o SNMPv2c Required

o SNMPv3 Strongly recommended

• Support for extensible agents

• Support for MIB-II

• Possibility to extend using open APIs (Application Programming Interface)

• Generate traffic graphs for the traffic in the COMInf network; these should be able to break down into VLAN traffic graphs

• Raise an alarm if needed

• Monitoring of all servers in the COMInf network

• Provide server information on:

o CPU utilization o Disk utilization o Memory utilization o Virtual memory utilization o Number of running processes o Temperature o Fan speed o UPS status

• Monitoring of the following services running on the COMInf servers: o DNS, either by BIND or Ericsson IPWorks

Version Status (is it running?) Self-test

o DHCP, either by Sun DHCP or Ericsson IPWorks


30

Version Status (is it running?) Self-test

o NTP Version Status (is it running?) Self-test

o HTTP, Apache Version Status (is it running both on 80 and 443 – HTTPS) Self-test

• Monitoring of the following information for the network switch: o Firmware version o Traffic flow per port o Interface speed per port o Temperature

• Monitoring of the following information for the O&M router: o Firmware version o Total traffic flow o Erroneous/Discarded packages o Temperature

• Monitoring of the following information for the firewall router: o Firmware version o Total traffic flow o Erroneous/Discarded packages o Temperature

• Monitoring of the following information for the X.25 router: o Firmware version o Total traffic flow o Erroneous/Discarded packages o Temperature

7.3.2. Draft Requirements Based On Interview The requirements presented in this section have been derived from interviews and mail conversations with employees at Ericsson. The interview subjects ranges from the staff within the COMInf development team to a solutions architect working in close cooperation with Ericssons customers.

As of the new release of OSS-RC, OSS-RC R5 the specification of the COMInf network is stricter than is has been in previous versions. This makes surveillance of the network and its servers easier since servers and processes are more well specified. However, the infrastructure components of the networking equipment (such as routers, switches, etc) are still not specified in the release documents (even though certain hardware is recommended).


31

As potential single-point-of-failures it has been pointed out that the routers/switches/firewalls and server information in the COMInf network are essential to monitor. Particular points of interests are:

• Routers (Firewall, X.25, O&M)

o Firmware version

o Temperature

• Switch

o Firmware version

o Temperature

o Throughput

• Servers

o Operating System version

o Log files (send SNMP traps upon match of specific text strings)

o Hardware (send SNMP traps upon exceeding certain thresholds)

CPU

DISK I/O

RAM

o Monitor output from specific shell scripts

o Service information (send SNMP traps upon abnormal behavior)

Version

Runtime information

o Make use of process accounting information

• General information

o Store performance data in a centralized database

o Export of performance data to Excel

o Produce graphs of system performance

o Installation flexibility (system installation directory should be configurable)

o Should work in both HA and non HA environments

o Detailed IP interface statistics

o Work alongside OSS-RC UTRAN security solution without interference

7.4. Rating the Requirements

In this chapter the draft requirements from theory, and from staff within Ericsson will be interpreted and rated in two different aspects:


32

• Importance The importance of the requirement. • Cost The cost (e.g. implementation time) for the requirement.

7.4.1. Rating system The rating system will rate the two difference aspects using a scale of 1-5 for importance, and 1-3 for cost. The importance rating is explained in Table 7-1.

Score Rating Explanation

1 Very low Does not provide any interesting information

2 Low Provides some interesting information

3 Medium Important information

4 High Very import information

5 Very high Essential for implementation Table 7-1: Explaination of importance rating The cost rating in this thesis is based on the manager software HP Network Node Manager as well as the target systems default SNMP agent.

Score Rating Explanation

1 High Agent will have to be extended to support functionality.

2 Medium Some extra configuration is necessary

3 Low Native support exists in both manager and agent Table 7-2: Explanation of cost rating Finally the requirement will be given a total score using the formula:

Total Score = Importance score x Cost score

The formula yields a total score that ranks the requirements by giving an important and cheap requirement a high score, while giving an unimportant and costly requirement a low score. In chapter 7.5, the total score as well as the importance factor are used to prioritize the requirements.

Note: Although alternative rating systems exist, this particular system is often used and can, if necessary, easily be translated into man-hours in a project model.

7.4.2. Routers (X.25, O&M, Firewall) The really critical information to extract from these devices is the firmware version (version of OS in the products) and the temperature. This way it is possible to make sure the firmware is up to date and that the device itself does not overheat. The impact


33

of a crashed router would be quite severe as it could bring down the COMInf network itself or its connection to the GSM and/or WCDMA networks. Since all routers in this typical COMInf setup utilizes the JUNOS software it is straight forward to derive the costs for different routers, the scores are based on information found in “JUNOS Network Management Configuration Guide”, [9]. The agents these cost scores are based on are the default agents on the recommended routers by Ericsson; see section 6.1 for more information. Scores of requirements for the COMInf routers can be found in Table 7-3.

No. Service/Process Importance Cost Total Score

F-1 Router firmware version 5 3 15

F-2 Router temperature 4 3 12

F-3 Router throughput 2 3 6

F-4 Router erroneous packages 1 3 3

F-5 Router discarded packages 1 3 3 Table 7-3: Score for COMInf routers It appears that introducing support for monitoring the necessary items in the COMInf routers would prove an easy task as native supports exists for all of the above requirements.

7.4.3. Network Switch As explained earlier, OSS-RC R5 enforces hardware control as far as servers are concerned. This helps when determining the requirements for bandwidth. In versions previous to R5 however, this is not the case. For small networks it becomes important to continuously monitor the network traffic to be able to detect possible congestion in network traffic. The agent these cost scores is based on are the default agent on the recommended switch by Ericsson; see section 6.1 for more information. Table 7-4 shows the scores for the requirements of the COMInf network switch. No. Service/Process Importance Cost Total Score

F-6 Switch firmware version 5 3 15

F-7 Switch temperature 4 3 12

F-8 Switch throughput per port 3 3 9

F-9 Switch transmission errors 2 3 6

F-10 Switch total throughput 1 3 3 Table 7-4 Score for COMInf network switch requirements All requested information from the network switch can be obtained using both Juniper Networks own enterprise MIB and their implementation of MIB-II.


34

7.4.4. Servers As the COMInf network grows, more and more servers are being added to the network infrastructure. Redundant servers, new services on new machines and old services that had earlier coexisted with other services on one server may be deployed on separate machines in order to increase stability and capacity of the network. On the servers, the default SNMP agent provided by Sun on Solaris 10 is used as a reference, this agent is called the SMA, or System Management Agent. This agent is based on the open-source agent Net-SNMP and has been extended to support the following MIBs, [10]:

• SNMP-COMMUNITY MIB Defined in RFC 2576.

• SNMPv2-TM (Transport Mappings) Defined in RFC 3417.

• SNMP-MPD-MIB (Message Processing and Dispatching) Defined in RFC 3412.

• SNMP-TARGET-MIB (Specification of targets for traps) Defined in RFC 3413.

• SNMP-NOTICATIONS-MIB (Trap filtering) Defined in RFC 3413.

• SNMP-PROXY-MIB (Trap forwarding) Defined in RFC 3413.

• SNMP-USED-BASED-SM-MIB (User based security model for SNMPv3) Defined in RFC 3414.

• SNMP-VIEW_BASED-ACM-MIB (View based Access Control Model for SNMP) Defined in RFC 3415.

• SNMPv2-MIB Defined in RFC 3418.

• MIB II Defined in RFC 1213.

• Host Resources MIB Defined in RFC 2790.

• SUN MIB Related to migration from the Solstice SNMP agent used in previous versions of the Solaris operating system.

• UCD-DISKIO-MIB MOB Module for disk I/O statistics.

It should be noted that the Net-SNMP agent is far superior to the Solstice agent running on Solaris 8 and 9. This makes this rating inaccurate for those operating systems. However, Net-SNMP can be installed on both Solaris 8 and 9 and also on the Windows Server platforms. All RFC documents can be found at IETFs web site, see chapter 11.2. It is still uncertain if the SMA from Solaris 10 will work on Solaris 8 and 9. No. Service/Process Importance Cost Total Score


35

F-11 Server runtime information (uptime, etc.)

5 3 HR 15

F-12 Server log file monitoring 5 1 EXTERNAL 5

F-13 Server service version 5 2 HR 10

F-14 Server service runtime information

5 2 HR 10

F-15 Server monitoring of output from specific shell scripts

5 1 EXTERNAL 5

F-16 Server data performance collection

5 2 HR/MIB-II 10

F-17 Server OS version 4 3 HR 12

F-18 Server CPU utilization 4 3 HR 12

F-19 Server RAM utilization 4 3 HR 12

F-20 Server disk I/O 3 3 HR/DISKIO 9

F-21 Server temperature 3 1 EXTERNAL 3

F-22 Server detailed IP interface statistics

3 3 HR/MIB-II 9

F-23 Server UPS status 3 1 EXTERNAL 2

F-24 Server fan speed 1 1 EXTERNAL 1 Table 7-5: Score for requirements of COMInf servers Legend: HR Support exists in the Host Resources MIB. MIB-II Support exists in the MIB-II MIB. DISKIO Support exists in UDC-DISKIO MIB.

EXTERNAL Support does not exist within the SMA. This agent will have to be extended to support the required functionality.

7.4.5. General requirements As for the entire network surveillance system, there are a few requirements that do not apply specifically to the monitoring process. These requirements are presented in Table 7-6 below. Because these requirements are mandatory, they are not rated. Requirement Importance Cost Total Score

F-25 Store performance data in a centralized database

Mandatory N/A N/A

F-26 Export performance data into .xls (Microsoft Excel) format

Mandatory N/A N/A

F-27 Produce graphs of system performance

Mandatory N/A N/A

F-28 Agents should install in a user-configurable directory

Mandatory N/A N/A

F-29 Should work in both HA and non HA environments

Mandatory N/A N/A


36

F-30 Work alongside the current security solution (UTRAN)

Mandatory N/A N/A

F-31 Make use of process accounting information

Mandatory N/A N/A

Table 7-6: Score for general requirements

7.5. Analyzing the Requirements

It is apparent that the limiting factor of the chosen network monitoring solution is the targets SNMP agent. Although most areas for the network switch and the routers have native support in the provided SNMP agents through their implementation of MIB-II, it is the servers which are most difficult to monitor. By extending the SMA in Solaris 10, the required functionality can be obtained. There exist numerous agents that can cooperate with the SMA, either by acting as a slave agent to the SMA or by acting masters themselves and changing the SMA to act as slave. One possible extension is to implement another agent on the server machine.. Since most functionality is dependent on the agents within the servers, switches and routers, the functionality of the manager (discussed in chapter 8) is more associated with how this data is presented and stored for future use. As for requirements F-25 to F-30 in Table 7-6 with the exception of F-28, they are almost exclusively dependent on the SNMP manager.

7.6. Final Requirements

In this section the requirements are presented in order of total score gained as well as by importance. To get a better comprehension of which requirements are most important, chapter 7.6.1 rates these requirements by their total score.


37

7.6.1. Requirements by Total Score

0

2

4

6

8

10

12

14

16

Total Score

F-1

F-6 F-11 F-2

F-7 F-17 F-18 F-19 F-13 F-14 F-16 F-8 F-20 F-22 F-3

F-9 F-12 F-15 F-21 F-23 F-4

F-5

F-10 F-24

Requirement Number

Requirements by Total Score

Figure 7-1: Requirements by total score As we can see from Figure 7-1 and Table 7-7 the requirements that dominate the total score rating are easy to implement. Native support exists in the agents and it is up to the manager to present this data in a usable fashion. Requirement Description Total Score

F-1 Router firmware version 15 F-6 Switch firmware version 15 F-11 Server runtime information (uptime, etc.) 15 F-2 Router temperature 12 F-7 Switch temperature 12 F-17 Server OS version 12

F-18 Server CPU load 12

F-19 Server RAM 12

F-13 Service version 10

F-14 Server service runtime information 10

F-16 Server data performance collection 10 F-8 Switch throughput per port 9 F-20 Server disk I/O 9 F-22 Server detailed IP interface statistics 9 F-3 Router throughput 6 F-9 Switch transmission errors 6 F-12 Server log file monitoring 5


38

F-15 Server monitoring of output from specific shell scripts

5

F-21 Server temperature 3 F-23 Server UPS status 3 F-4 Router erroneous packages 3 F-5 Router discarded packages 3 F-10 Switch total throughput 3 F-24 Server fan speed 1

Table 7-7: Requirements by total score


39

7.6.2. Requirements by Importance

0

0,5

1

1,5

2

2,5

3

3,5

4

4,5

5

Importance

F-1

F-6 F-11 F-13 F-14 F-16 F-12 F-15 F-2

F-7 F-17 F-18 F-19 F-8 F-20 F-22 F-21 F-23 F-3

F-9 F-4

F-5

F-10 F-24

Requirement Number

Requirements by Importance

Figure 7-2: Requirements by importance Both Figure 7-2 and Table 7-8 shows a rating system where the cost for implementation has been ignored. As this thesis has used a simplified model for requirement evaluation, some requirements might not be implemented by only total score into account. This is due to the costly factor of some requirements that might still be very important, it is therefore recommended to also look at the requirements from an importance perspective and simply ignore the cost aspect.

Requirement Description Importance

F-1 Router firmware version 5 F-6 Switch firmware version 5 F-11 Server runtime information (uptime, etc.) 5 F-13 Service version 5

F-14 Server service runtime information 5

F-16 Server data performance collection 5

F-12 Server log file monitoring 5

F-15 Server monitoring of output from specific shell scripts 5

F-2 Router temperature 4 F-7 Switch temperature 4 F-17 Server OS version 4 F-18 Server CPU load 4 F-19 Server RAM 4 F-8 Switch throughput per port 3


40

F-20 Server disk I/O 3 F-22 Server detailed IP interface statistics 3 F-21 Server temperature 3 F-23 Server UPS status 3 F-3 Router throughput 2 F-9 Switch transmission errors 2 F-4 Router erroneous packages 1 F-5 Router discarded packages 1 F-10 Switch total throughput 1 F-24 Server fan speed 1

Table 7-8: Requirements by importance

7.7. Security Considerations

The security in COMInf in is very important. The following section discusses the existing security in the COMInf network.

7.7.1. Security Mechanisms The security mechanisms in COMInf today are highly focused on providing reliability. As for the current situation of the COMInf network, the security measures are sufficient. The mechanisms in place (VLAN segmentation, firewall policies between segments, etc.) do protect the network infrastructure from the threats it is most likely to encounter (internal penetration, accidental abuse). The main security threat to the COMInf network today is network staff with direct access to the network infrastructure and as stated in section 2.4.3, protecting against these types of threats requires extensive security measures.

7.7.2. SNMP Security SNMP security should be addressed when extending and developing the COMInf network. Supervision of the network should, if possible, be done exclusively through the use of SNMPv3. Some of the hardware recommended by Ericsson does not support this version of SNMP at this stage and according to the manufacturers, no plans for implementation exists. Fortunately, the SMA in Solaris 10 does support SNMPv3. This provides extended security in all aspects when communicating the SNMP manager. However, as long as there are SNMPv2 devices in the network, security is reduced to the security measures of SNMPv2c. While there is no way (without breaking the security enforcement in SNMPv3) to capture the information flow between the SNMP agents in the servers and the SNMP managers, the information between all SNMPv2 devices and the SNMP manager are sent in clear text. From an attacker’s point of view, sniffing this information is an easy way to get hold of the community strings (essentially passwords in SNMP). The community string might potentially be used in


41

an attack on an SNMP agent which supports set operations. For this reason set operations via SNMP should, if possible, be disabled in all agents.

7.8. Requirement Conclusions

The requirements presented in this chapter are all important for future implementation of a network surveillance system. The rating performed in chapter 7.6 concludes that some requirements are more important than others. There are a few requirements that scored high on the importance factor but where costly, that is:

• F-12 Server log file monitoring • F-15 Server monitoring of output from specific shell scripts

A brief overview of extensible agents shows that these requirements are possible to fulfill by extending the SMA. As for the three high cost requirements that scored lower on the importance factor:

• F-21 Server temperature • F-23 Server UPS status • F-24 Server fan speed

F-23 can most likely be fulfilled by extending the SMA to include the UPS MIB (RFC 1628). As for the other two, F-21 and F-24 they could be implemented by extending the SMA using an in-house developed custom MIB. Because this would require quite a lot of time, this is not recommended at a first stage. The requirements that has been graded as mandatory (F-25 through F-31) can be fulfilled with most systems on the market today. The exception is requirement F-31 which may be problematic for some systems. An example of this is the HP OpenView Performance Agent which displays erroneous values for CPU utilization on Solaris systems.


42

Chapter 8 - Evaluation of Candidate Systems

43

8. Evaluation of Candidate Systems

This chapter presents four candidate systems and establishes evaluation criteria for a network surveillance solution applicable to the COMInf network. After basic research of these systems, it has been concluded that a thorough evaluation of the identified alternatives is outside the scope of this thesis project. This chapter merely serves as a basis for future work. The candidate systems are:

• HP OpenView HP is one of the major players in the network surveillance industry and its products range from simple network management software such as NNM to more complex performance monitoring software covering individual servers.

• TeamQuest TeamQuest is currently being deployed at some of Ericsson’s customers within the UK. It also has a proven track record in the network surveillance industry and is currently expanding rapidly.

• Managed Objects Ericsson recently acquired the rights to the use of Managed Objects as a third party product for network surveillance of the radio access networks. Managed Objects will be a future part of OSS-RC.

• NETadmin NETadmin is a relatively new company in the network surveillance industry, and because of their small size, they can customize and adapt to customers requirements quite easily. As NETadmin currently do not provide any agents, a NETadmin solution would be forced to rely solely on the use of third party agents.

8.1. Evaluation Criteria

In order to properly evaluate the candidate systems, a set of evaluation criteria is needed.

8.1.1. Criteria Based on the authors knowledge of computer systems the following criteria were established for the evaluation. Usability: The user-friendliness of the system. Even though this is a very difficult aspect to evaluate objectively, it is still very important. Usability in a system is often what separates the good from the great. Extensibility: The extensibility of the system. As the COMInf network is likely to change over time, it is important to have a system which can be extended to reflect new setups.


44

Flexibility: The flexibility of the system. While the initial system should satisfy the current requirements of the COMInf network, it is not likely that it will be perfect. As new requirements surface, it should be easy to adapt the system to these requirements. Reliability: The reliability of the system. The stability of the COMInf network is extremely important. This makes surveillance of the same system equally important. Without a working and reliable surveillance solution it is not possible to verify that the COMInf setup is actually working. Security: The security of the system. This aspect should concern such matters as: SNMPv3 support, how often encryption keys are changed, how the exchange of encryption keys between different hosts is managed, etc.

8.1.2. Grading The candidate systems are rated on a scale of 1 to 5 using the different grades in Table 8-1. Rating Difficulty

1 Very low 2 Low 3 Moderate 4 High 5 Very high

Table 8-1: Scale for candidate systems The ratings in the different categories are then summarized to produce a score between 5 and 25 according to the formula: Total Score = Ease-of-use-Score + Extensibility-Score + Flexibility-Score

+ Reliability-Score + Security-Score

8.1.3. Summary As these established evaluation criteria are preliminary, criteria might be added and/or removed at a later stage. It is likely that the formula for calculating the total score will have to be revised. The total score could for example, be modified by weighting the different criteria according to their importance in a particular network.

8.2. Evaluation Conclusions

After basic research into these systems, the conclusion has been reached that a thorough evaluation of the identified alternatives is outside the scope of this thesis project. A network surveillance system utilizing TeamQuest Release 10 is currently being deployed to some of customers. Although the software does look promising, before a


45

thorough investigation of the identified alternatives has taken place, it is not possible to draw any conclusions or make any recommendations.


46

Chapter 9 - Summary and Conclusions

47

9. Summary and Conclusions

This thesis has:

• Analyzed the COMInf network • Derived and rated requirements for a future network monitoring solution • Presented four candidate systems for future evaluation • Provided recommendations for future COMInf development

This chapter presents the conclusions from this thesis project.

9.1. Recommendations

This section provides recommendations for the introduction of a network surveillance system.

9.1.1. SNMP Implementation Surveillance of the networking equipment itself is a straight forward task. A future network monitoring solution should support SNMPv3, However, current hardware recommendations of COMInf networking equipment recommends numerous devices using the inferior SNMPv2 standard. This thesis strongly recommends that Ericsson change current recommendations of COMInf hardware to hardware supporting SNMP version 3. Most enterprise network monitoring solutions have software (often SNMP agents) for monitoring server performance. If they exist within the given solution it is recommended to use them. However, if the supplied software fails to meet the requirements another option is to extend the agent operating on the servers. In case of the use of a third-party agent, the recommendation of this thesis project is to extend the SNMP agent provided by Sun, the SMA, by the use of CIAgent by SNMP Research International, Inc. This agent can be installed on both Solaris and Windows platforms and can co-exist with existing agents. In addition to native support for monitoring of log files (requirement F-12) and output of shell script output (requirement F-15), this agent comes with a feature packed SDK which makes tailoring and specific adaptation to COMInf devices easier.

9.1.2. Network setup Because of the single-point-of-failures COMInf has when it comes to routers and switches, it is the recommendation of this thesis to extend recommendations for a recommended COMInf setup to include a triangle solution for switches and routers.

9.1.3. Security A separate surveillance solution is not recommended at this stage, even though there are still some security measures that should be taken. These are:

Chapter 9 - Summary and Conclusions

48

• Using requirement F-12 log files should be checked for signs of intrusion • MIBs with SNMPv2c access should be read-only where possible to prevent

illegal system abuse • Process accounting should be used since this can be used in a forensic analysis

in case of an attack

9.1.4. Summary of Recommendations A summary of recommendations follows:

1. Change hardware recommendations to hardware supporting SNMPv3 2. Change recommendations to reflect a triangle setup for switches and routers 3. If extending the SNMP agent – use CIAgent by SNMP Research Inc. 4. Log files should be checked regularly for signs of intrusion 5. MIBs should be set to read-only where possible 6. Process accounting should be used on all servers

9.2. Future Work

As an evaluation of candidate systems does not fit within the scope of this thesis, this is definitely an area that should be explored prior to a final recommendation. This thesis recommends a thorough investigation of different alternatives using a real COMInf system to properly evaluate the relative merits using the requirements from chapter 7. This evaluation could possibly be a future thesis project within this area. As a basis for the evaluation these systems, the candidate systems presented in chapter 8 might be of interest. This thesis also recommends an investigation of different hardware supporting the SNMPv3 standard. For future reference it is also interesting to evaluate the need for an IDS or IPS solution.

Chapter 10 - Glossary

10. Glossary

Thesis specific abbreviations and phrases are explained briefly in this chapter.

• 3DES A specified way of encryption using the DES algorithm three times using a 56 bit key length to increase security, see DES for more details.

• AES – Advanced Encryption Standard A successor to the widely used DES algorithm adopted as a US Federal standard in 2001. AES uses the Rijndael Algorithm and can be used with key sizes of 128, 192 or 256 bits.

• API – Application Programming Interface An abstraction layer of low-level functions often provided by manufacturers to make programming easier.

• ASN.1 – Abstract Syntax Notation One ASN.1 is a standard and flexible notation that describes data structures for representing, encoding, transmitting, and decoding data.

• DES – Data Encryption Standard Probably the most used encryption standard on the Internet today. DES was adopted in 1970 as a US government standard for protecting nonclassified data. DES encrypts 64-bit plaintext blocks into 56-bit keys, adding a byte for parity to give a 64-bit working key. Today, DES is fairly easy to crack and end users are encouraged to switch to AES or other forms of encryption instead.

• BIND – Berkley Internet Name Domain The most commonly used DNS server on the Internet.

• Brute Force A way to find out encryption keys, usernames and/or passwords simply by repeated attempts. Often this can be several thousand attempts per second.

• CIAgent An extensible SNMP agent created by SNMP Research International, Inc.

• COMInf – Common Operations and Maintenance Infrastructure A part of OSS-RC used by Ericsson to provide infrastructure components.

• DoS – Denial of Service A type of attack used to disable a system simply by overloading its servers with bogus traffic.

• DDoS – Distributed DoS Works as DoS but using multiple sources to overload the system.

• DHCP – Dynamic Host Configuration Protocol A protocol used to provide hosts with IP-addresses on demand.

• DNS – Domain Name System A system used to translate from alpha-numerical names such as www.ericsson.com into IP-addresses, in this case 84.53.136.137.

49

http://www.ericsson.com/


• DS – Directory Server A part of the CORBA authentication services.

• EMANATE – Enhanced MANagement Agent Through Extensions A part of the agent used by CIAgent.

• FCAPS – Fault management, Configuration management, Accounting management, Performance management, and Security management A model used for network management, developed by ISO

• GSM – Groupe Spécial Mobile, or Global System for Mobile communications One of the second generation mobile phone technologies.

• HA – High Availability Refers to High Availability data clusters, that is, systems designed using redundancy in order to provide a certain (high) degree of availability.

• IDS – Intrusion Detection System A system designed to monitor network traffic and/or information flow in hosts to detect system irregularities.

• IETF – Internet Engineering Task Force An organization devoted to approving new Internet standards, particularly in the TCP/IP Internet protocol suite.

• IPS – Intrusion Prevention System Much like an IDS with the difference that an IPS actually takes action and interrupts possible attacks.

• ISP – Internet Service Provider A company providing internet services for households and/or companies.

• ITU-T – International Telecommunication Union - Telecommunication An organization devoted to setting standards within the area of telecommunication.

• MITM – Man In The Middle A type of attack based on eavesdropping and altering information between the sender and receiver while fooling both ends to believe they are indeed talking directly to each other.

• NMS – Network Management Station A manager responsible for polling agents for data and often generate statistics..

• NTP – Network Time Protocol A protocol used to synchronize computer clocks.

• O&M – Operation and Maintenance A network used to operate and control the radio networks.

• OID – Object IDentifier An OID is an object identifier used to name a specific object.

• OSS-RC Operations Support System, Radio and Core. OSS-RC is an O&M network developed by Ericsson to control and supervise the radio access networks.

50


• PKS – Public Key Server A part of the CORBA suite. It provides certification authority functionality.

• RFC – Request For Comment A document containing information that later on may be set as an Internet standard by the IETF.

• RMON – Remote Monitoring A supplement to SNMP to allow internal agents to continuously poll devices and report errors using traps.

• SDK – Software Development Kit A framework and/or collection of tools used for development of applications and/or modules for a specific piece of software.

• SLS – Single Login Server A part of the CORBA authentication services.

• SMA – System Management Agent The default shipped agent with the Sun Solaris 10 operating system. Previous versions of Solaris does NOT use this agent.

• SNMP – Simple Network Management Protocol A protocol used to supervise and control networking equipment such as firewalls, routers, etc.

• SNMPv1 – SNMP version 1 An Internet standard protocol defined in RFC1155, with supporting RFCs in RFC1156 and RFC1157. SNMPv1 has now gained IETFs historical status.

• SNMPv2c – SNMP version 2 An Internet standard protocol defined in RFC1441 with supporting RFCs in RFC2578, RFC2579, RFC2580, RFC3416, RFC3417 and RFC3418.

• SNMPv3 – SNMP version 3 An Internet standard protocol defined in RFC3411 with supporting RFCs in RFC3412, RFC3413, RFC3414, RFC3415 and RFC3584. The only real enhancement from SNMPv2c is the addition of security features.

• SSL – Secure Socket Layer The most widely used protocol for secure transmissions. Developed by the IETF.

• TCP/IP – Transmission Control Protocol / Internet Protocol Two different protocols often mentioned together in what is commonly known as the TCP/IP suite. TCP is defined in RFC973 and IP in RFC791.

• UMTS – Universal Mobile Telecommunications Systems One of the third generation mobile phone technologies.

• VoIP – Voice Over IP Technology used to communicate verbally over an IP network.

• VPN – Virtual Private Networking A way to create a local network over another network (e.g.. the Internet) using encryption to minimize eavesdropping.

51


• WCDMA – Wideband Code Division Multiple Access On of the technologies used in third generation mobile phone technology.

• Zero-day attack An attack that takes places after the exploit is released to the public, and before a patch has been released by the software manufacturer.

52

Chapter 11 - Bibliography

11. Bibliography

The references used in this document are listed in no sense order.

11.1. References

[1] Snort and IDS Tools – First Edition, Kerry J. Cox & Christopher Gerg, 2004, O’Reilly Media Inc., ISBN: 0-596-00661-6.

[2] Computer crime cost $67 billion, FBI says, CNET News, http://news.com.com/Computer+crime+costs+67+billion,+FBI+says/2100-7349_3-6028946.html, 2007-03-12.

[3] Computer Security – Second Edition, Dieter Gollmann, 2006, John Wiley & Sons Ltd., ISBN: 978-0-470-86293-3.

[4] Passwords revealed by sweat deal, BBC News, http://news.bbc.co.uk/2/hi/technology/3639679.stm, 2007-03-12.

[5] Essential SNMP – Second edition, Douglas R. Mauro & Kevin J. Schmidt, 2005, O’Reilly Media Inc, ISBN: 0-596-00840-6.

[6] ITU-T – M.3400 Telecommunications Management Network: Management functions, http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-M.3400-200002-I!!PDF-E&type=items, 2007-03-12.

[7] Juniper NetScreen ScreenOS Lets Remote Users Determine Valid VPN Usernames, http://securitytracker.com/id?1014728, 2007-03-12.

[8] JUNOS Memory Leak in Processing IPv6 Packets Lets Remote Users Crash the Router, http://securitytracker.com/id?1016460, 2007-03-12.

[9] JUNOS Network Management Configuration Guide, http://www.juniper.net/techpubs/software/junos/junos82/swconfig82-net-mgmt/download/swconfig82-net-mgmt.pdf, 2007-04-02.

[10] Solaris System Management Agent Administration Guide, http://192.18.109.11/817-3000/817-3000.pdf, 2007-04-12.

53

http://news.com.com/Computer+crime+costs+67+billion,+FBI+says/2100-7349_3-6028946.html

http://news.com.com/Computer+crime+costs+67+billion,+FBI+says/2100-7349_3-6028946.html

http://news.bbc.co.uk/2/hi/technology/3639679.stm

http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-M.3400-200002-I!!PDF-E&type=items

http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-M.3400-200002-I!!PDF-E&type=items

http://securitytracker.com/id?1014728

http://securitytracker.com/id?1016460

http://www.juniper.net/techpubs/software/junos/junos82/swconfig82-net-mgmt/download/swconfig82-net-mgmt.pdf

http://www.juniper.net/techpubs/software/junos/junos82/swconfig82-net-mgmt/download/swconfig82-net-mgmt.pdf

http://192.18.109.11/817-3000/817-3000.pdf

Chapter 11 - Bibliography

11.2. Links

• CERT http://www.cert.org

• Cisco Systems http://www.cisco.com

• HP http://www.hp.com/go/software

• IETF http://www.ietf.org

• Juniper Networks http://www.juniper.net

• NETadmin http://www.netadmin.se

• RFC http://www.ietf.org/rfc.html

• SANS http://www.sans.org

• Securityfocus http://www.securityfocus.org

• Securitytracker http://www.securitytracker.org

• SNMP Research International, Inc. http://www.snmp.com

• Snort http://www.snort.org

• TeamQuest http://www.teamquest.com

54

http://www.cert.org/

http://www.cisco.com/

http://www.hp.com/go/software

http://www.ietf.org/

http://www.juniper.net/

http://www.netadmin.se/

http://www.ietf.org/rfc.html

http://www.sans.org/

http://www.securityfocus.org/

http://www.securitytracker.org/

http://www.snmp.com/

http://www.snort.org/

http://www.teamquest.com/

På svenska Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under en längre tid från publiceringsdatum under förutsättning att inga extra-ordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/ In English The publishers will keep this document online on the Internet - or its possible replacement - for a considerable time from the date of publication barring exceptional circumstances.

The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.

For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its WWW home page: http://www.ep.liu.se/ © [Love Thyresson]

http://www.ep.liu.se/

Documents

Institutionen för systemteknik - diva-portal.org17020/FULLTEXT01.pdf · Institutionen för systemteknik ... Ericsson AB is the worlds leading developer and provider of mobile radio