- 2.1 Network Security in General
- 2.2 Threats of Network Security and their Relation to Network Management
- 3.1 Overview
- 3.2 Security of SNMP
- 3.3 SNMP version 2
- 4.1 What is SNMPv3?
- 4.2 SNMPv3 Message Processing
- 4.3 User-Based Security Model
- 4.3.1 Authentication and Integrity
- 4.3.2 Timeliness Verification of Messages
- 4.3.3 Privacy Through Encryption
- 4.4 View-Based Access Control
- 4.5 Problems with SNMPv3
- 5.1 Overview
- 5.2 The Proxy WBM
- 5.3 The Embedded WBM
- 5.4 Security Comparison of WBM Architectures
1 Introduction
Network management is about remotely controlling and configuring the various devices connected to a certain network. These devices or network nodes include for example routers, bridges, various firewalls and hosts. The network management plays a very important part in the functionality of a network. The security of the entire network relies at least partly on the security and functionality of the management. Management protocols are used to configure an increasing number of devices running software and connected to the network. So, having a secure network means that at least the crucial configuration tasks on the network should be secure and controlled.
Presently, the common protocol for managing a TCP/IP based network is the Simple Network Management Protocol. The SNMP specification[3] defines a simple and connectionless protocol to achieve the functions stated above. For the basic data structures and organization of information and parameters at managed node there is another standard called Management Information Base (MIB).
Unfortunately, when designing the SNMP the security issues were mostly neglected. The result was a ridiculously vulnerable protocol. The problems were not fixed in a new standard, SNMPv2, which provided mainly corrections and improvements to such issues as bulk transfer. The standardization of a new version, or more like a security extension of SNMP was initiated. This framework, named SNMPv3, was designed to add security to existing versions of SNMP. Fortunately, the standarization process is close to being finalized as an Internet standard within IETF.
In this research paper we will introduce the basic functionality of SNMP and the security issues concerning its different versions. In addition, a new approach called WBM is discussed. There exist various other, more or less famous managemnet protocols. They are not explored in this paper, anyway. That's because this paper mainly focuses on TCP/IP suite and especially SNMP. Still, another management protocol worth to notice is Common Management Information Service (CMISE) that belongs to the ISO OSI protocol suite. In ISO OSI suite, the CMISE is placed in application layer and works using the services of the ROSE (Remote Operations Service Entity) and the ACSE (Association Control Service Entity) [11]. However, because the CMISE doesn't belong to TCP/IP suite, we won't analyze it in this paper as it's out of scope of the paper. Also, another lining of this paper concerns the security of WBM: In examining the WBM the security of various management applications is not studied, instead, the philosophy and security adding ideas behind WBM are taken into closer examination.
The rest of the paper is organized as follows. In chapter 2 the general description of the network security and the important issues related to network management will be studied. In addition, common security threats that are present in distributed management environments will be explained. Some of the most common attack scenarios are described, as well. The chapter 3 presents the Simple Network Management Protocol (SNMP). The architecture and functions are described as well as the security functions. After that the vulnerabilies and problems of SNMP will be explained. The proposed solution - SNMPv2 - will also be glanced briefly. In chapter 4, following the evolution of the SNMP protocols, the SNMPv3 framework and its security model will be studied. The security mechanisms and message processing will be explained in a more detailed level. The chapter 5 inroduces a completely different approach to managing network: the Web-Based Management (WBM). Two approaches of WBM are described and compared looking from the security aspects. Finally, in chapter 6, some future ideas and improvements are taken into consideration. The chapter 7 will then summarize the paper by presenting conclusions of the security of network management in TCP/IP based networks.
2 Network Security Conciderations in Network Management
2.1 Network Security in General
The security issues of computer networks are different and more heterogenous than the issues related to the conventional security of computers. The network can be a private LAN or based on public routing network. Nowadays, most of the networks are TCP/IP based and connected with each other by routers. It is desirable to have connections from a certain network to the rest of the open Internet. However, the privacy must be maintained in private networks. Commonly, unauthorized users that come from outside of the LAN are blocked by using firewalls and proxies at network boundaries.[10]
A part of the network security is concerned with the various threats that are present due to the transmission of the messages. Plain-text protocol messages are easy to sniff when they are relayed, router by router, in a public routing network. Spoofing is the other of the two worst threats. That is, forging the protocol messages so that they seem to originate from a trusted source address. The threats that are related to the transmission of the messages are in close relationship with each other. For example, usually one has to sniff messages before he can start spoofing. And the spoofing can then have various consequences. The common nominator for the security issues related to networks is the fact that usually the transmission network is not controlled nor owned by the user organization operating on the network. The threats are discussed more closely in the following subsection. [6, 10]
Another part of the network security are the threats that come from the organization itself. The network of an organization can be secure and strong against the attacks from outside networks while the internal security is weak. There could be a leak in organization that provides the outside attacker the information it needs, for example passwords to routers or other confidential information of the organization. In addition to the information leak, the internal attacker can maliciously do harm to network hardware of the organization. He can do harm to servers and hubs which in turn causes damage to the overall operation of the network. This kind of internal threats are very hard to prevent because the people that are involved in these threats are often already familiar to the organization and trusted. For example, when a network administrator is hired, it's trusted that he is working for the company, not against it.
2.2 Threats of Network Security and their Relation to Network Management
In this chapter we will present a summary of the most common threats in network security in general. Also, some attacks are presented. Within the explantion of each threat it's also explained what kind of effects the threats have on the network management in general. That is, how the threats show up in the security of the network management.
Masquerading means that an attacker succeeds to act in someone else's role and perform some tasks on behalf of the vicim. In the security of network management at the moment, this is perhaps the most critical threat. One way to masquerade is to use spoofing as was explained in the previous sub chapter. If a malicious attacker succeeds to act as an authorized manager, the doors are open for him to manage the network with the rights of the authorized manager: The attacker can do anything that is permitted to the manager that is the victim.[10]
Modification of Information. The threat of the modification of information means that some third party can intercept the transmission of the message and maliciosly modify the in-transit message. Then the modified message is passed to the original receiver. Now the receiver of the message thinks that the message was sent by the trusted source while the contents of the message are changed. In network management, an authorized network manager can generate a valid management PDU. If an attacker succeeds to intercept the transmission, the whole PDU can be changed while keeping the authentication information unchanged. Of course, this is possible only if the PDU is not encrypted.
Message Stream Modification means that the stream of messages is modified somehow. This means that the messages could be reordered, or the messages could be recorded and replayed. The network management design originally aimed to connectionless management protocols. And since the most of the management protocols were designed to operate on connectionless transport services the message stream modification is a severe threat in network management. An attacker could for example record the valid management message that orders the router to shut down. Then, in the future, the attacker could use the captured message to perform the router shutdown whenever he wanted to do so.
Disclosure. The threat of disclosure means that confidential information is leaked to the people who shouldn't see it. In network security in general, sniffing the traffic that is not encrypted is one way to do it. Also, in network management, some managment PDUs can carry some crucial information about the network and managed nodes itself. So, if an attacker spies the management traffic in a network segment, he could get some important information. That information could be used as the basis for other attacks, such as masquerading. A way to fight the threat of disclosure is to encrypt the messages.
Related to the threat of disclosure is also the gathering of information threat where an attacker issues unsecured management commands to get publicly known and unsecured paramenters of a system. For example, to track a computer in network that has the user profiles or to locate a strategic router. This kind of pre-attack can save an attacker a lot of time and let the attacker focus on crucial network resources instead of blindly hacking into some hosts on network.
Last two threats are the threat of Denial of Service (DoS) and the threat of traffic pattern analysis. Denial of Service means that some network service will become blocked somehow. Attacker could for example try to open TCP connections to a host continuously and that way block all the other connection requests. In network management this could mean that an attacker succeeds in blocking the flow of management protocol messages between the manager and the agent. In the network management, the DOS can also be a consequence if the other threats take place. For example, if an attacker succeeds to masquerade and act as the network manager, he can possibly give the shutdown command to a specific router. And this is, in fact, a denial-of-service type of threat taking place.
Traffic pattern analysis is a threat where the information contents of the messages are ignored. Instead, the crucial information of the system is extracted from the usual patterns of the traffic flow. Both of these last two threats are hard to prevent.
3 Simple Network Management Protocol
3.1 Overview
The SNMP protocol is specified in RFC-1157 [3]. The basic idea of this simple protocol is that there is a SNMP agent within each remotely managed node, for example a router or a host. The general picture of the network management is shown in Figure 1. The SNMP manager has a Management Information Base (MIB) which contains the managed node's attributes. The manager then communicates over the network by means of SNMP with the agent of the network node to alter the paramenters locally according to the MIB and this way achieves the management functions: the agent will then interact with the lower level, that is, the software or hardware of the node. This kind of operation is commonly known as the fetch-store-paradigm. For example to reboot a device, the manager could send a SNMP message to alter the value of "reboot"-parameter of MIB to "true". [11, 15, 17, 19]
The SNMP works above the transport layer. When the SNMP was designed the communication between manager and agent was designed to be connectionless to make the management task as light as possible. Although the the SNMP specification doesn't forbid the use of TCP, the underlying transport protocol that is commonly used is the connectionless and unreliable UDP. The used ports are 161 and 162 for trap messages. The same port assignments hold for TCP, as well.
The network management tasks in SNMP consist mainly of three functions, as defined in RFC-1157. These functions are:
- Manager alters the value of a parameter in the node's MIB (set function),
- Manager retrieves information of the value of a parameter in node's MIB (get function),
- Manager receives notifications sent by an agent when some event takes place at a node (trap function).
3.2 Security of SNMP
The basic SNMP has very primitive security functions. The only mechanism to authenticate a manager is by so called community name (also called community string)[3,15]. The community name is used in defining management groups with differing access rights. That is, the community name is used to define which managers are allowed to submit get or set requests. The same community name mapping is used to define access policies for different managers. That is, some names may be restricted to operate only on some the areas of MIB while the others may have greater rights.
The SNMP community is locally defined at a node and the same name may be used at multiple nodes[3]. When a manager wants to perform some kind of management task (get or set) it always has to present the community name that matches its need for access rights. In order to manage a selection of nodes the manager has to maintain a list of all the relevant community names.
As one might think, this can't be considered a secure way to authenticate the user. Anybody who knows a community name with powerful rights can act as a manager for a possibly large selection of nodes. And, in addition, compromising a community name compromises the security of the management in the network. The second problem with the security of the SNMP is the fact that there is no privacy. That is, there is no possiblity to encrypt the management message. When all the traffic flows through unsecured public network, nobody can tell if someone is spying the traffic. This leaves a second huge hole in the security of SNMP: anybody could listen to unencrypted UDP based SNMP traffic and catch the community name at a router, for example. This means that eavesdropping and masquerading are the most obvious threats to take place.
The weak authentication of the SNMP is bad enough by itself. Combining this with the lack of privacy make things even worse. The ease to sniff plain-text UDP traffic makes the weak authentication of the SNMP even weaker. And, that in turn makes the threat of sniffing even greater threat it normally would be. So, in sence, the two basic problems with the SNMP worse each other.
Due to the total unsecurity of the SNMP, it is mostly used only for monitoring the agents. Actually, in most implementations, the SNMP "set" function is disabled just because it is ridiculously easy for an attacker to maliciously manage someone else's devices.[18]
3.3 SNMP version 2
The SNMPv2 standardization wasn't successful. The standardization process resulted in three mutually uncompatible standards [1]. Originally, the specification and designing of the SNMPv2 was initiated to enchance SNMP functionalities and the security was given some priority. A security scheme called "Party-Based Security" was introduced [7,9]. Because the original SNMPv2 proposal was never really taken into any broader use, the Party-Based Security Model isn't introduced here. The standardization process of SNMPv2 was stuck with two competing proposals: SNMPv2u, SNMPv2* which both had a user-based security model [2]. Unfortunately, a compromise was made and a proposal named SNMPv2c was standardized.
Why the SNMPv2 has a weak security? The answer is easy: The fruit of the standardization, the SNMPv2c, has no change to basic SNMP in terms of security - it relies completely on the familiar community strings. All in all, the SNMPv2 wasn't a good example of efficient standardization. The status and reputation of SNMP remained best described as: "Security's Not My Problem".[1]
4 SNMPv3 - The Security Extension
4.1 What is SNMPv3?
Although named after SNMP, the version 3 is merely a framework for adding security to the existing SNMPv1- or SNMPv2-based network management. The SNMPv3 is actually based on SNMPv2* and SNMPv2u which were designed to include the User-Based Security model but unfortunately were not taken into use.[1, 18]
The SNMPv3 uses the PDUs of SNMPv1 and SNMPv2 by encapsulating them in its own packet format [18]. The actual SNMPv3 is specified in RFCs 2570-2575. These documents define the architecture and the way of processing these messages so that the missing security features, authentication, privacy and the access control, are available for management environments that use the SNMPv3. The contents and the role of the RFCs is summarized in Table 1.
| RFC-2271 | Describes the architecture of SNMP frameworks. |
| RFC-2272 | Describes how the messages are to be processed and dispatched for SNMP |
| RFC-2273 | SNMPv3 applications |
| RFC-2274 | Describes the User-Based Security Model (USM) that provides the actual security for SNMPv3 |
| RFC-2275 | Describes the View-Based Access Control Model (VACM) that provides means of flexibly controlling the access of user groups in SNMPv3 |
The version 3 of SNMP provides the management system with crucial security functions by using two different models of security. The User-based Security Model (USM) delivers the authentication between the manager and the agent so that only the authenticated messages are trusted [2]. The USM also adds privacy by providing encryption of the SNMP payload. The View-based Access Control (VACM), on the other hand, brings a flexible, group-based access control to the authenticated users [20]. Perhaps one of the biggest changes in SNMPv3 compared to the previous versions was that the managers and agents became SNMP applications [18].
4.2 SNMPv3 Message Processing
The SNMPv3 packet encapsulation and the order of interpreting the packet is shown in Figure 2 [18]. Basically, the effective PDU, that is either SNMPv1-PDU or SNMPv2-PDU, is encapsulated in a SNMPv3 packet. This encapsulation provides security related functions on the level of message processing [4].
The architecture of SNMPv3 message processing is shown if Figure 3 [18]. In SNMPv3, each entity, manager, and managed, contain a single SNMPv3 engine to perform the message processing. When an application wants to send SNMP PDUs to the node in the network the following happens: The engine first accepts the SNMP datagram to be sent from SNMP application level, performs the appropriate security functions, encapsulates the PDU into an SNMPv3 message and then transmits the message to the network [4]. When the engine receives a SNMPv3 message from the network, it performs the necessary decryption and authentication functions before passing the PDU to the SNMP applications [16].
4.3 User-Based Security Model
USM is the security model that implements the actual security services for authentication and privacy. Two different secret keys are needed, one for privacy (encryption key or privacy key, privKey) and the other for authentication (authentication key, authKey). These keys are not stored in the MIB of the node. Therefore they are not directly accessible through SNMP get- or set-functions.[2]
4.3.1 Authentication and Integrity
For authentication of sender and checking the integrity of messages the USM supports two different authentication protocols, both of which are based on a widely used HMAC (see RFC-2104) [18]. HMAC-MD5-96 is a protocol where the secure hash function is MD5. The HMAC-SHA-96, on the other hand, uses SHA-1 for hashing. Inputs for both of the hash functions are the message to be sent and secret authentiction key of the user (authKey). Both hash functions produce an output, which is in both cases truncated to a message authentication code (MAC) of 12 octets. The calculated and truncated MAC is then appended to the message to be sent.
Upon reception the recipient does the following. The received message and the authKey are used as inputs for HMAC to calculate the MAC as was done when the message was sent. Now, if the calculated MAC is not the same as carried with the received message, the message is ignored. If, on the other hand, the MAC that was just calculated is the same MAC the received messages contained, the recipient can be sure about two things [18]:
- Integrity: The message couldn't be changed during the transmission. An attacker would have to know the secret authKey to change the message without being noticed.
- Authenticity: To calculate the correct MAC the sender has to know the secret key. And, if the secret key is only known by the sender and the recipient, one can be sure that the message was sent by the authentic party.
4.3.2 Timeliness Verification of Messages
The security function of authentication just described don't prevent message delay or message replay attacks since actually there is nothing unusual in replayed messages. To make the SNMPv3 secure against this kind of flow manipulating attacks the USM has a timeliness mechanism. Actually, SNMPv3 demands that the messages must be received within reasonable time window.
The timeliness mechanism is based on two counters assosiated with each single SNMP engine: the snmpEngineBoots and snmpEngineTime. When an SNMP engine (the SNMPv3 software on managed node) is installed, both of the two values are set to zero. After the SNMP engine has been started, snmpEngineTime is incremented once per second. If snmpEngineTime reaches the maximum value of (231 1), snmpEngineBoots is incremented as well. Then the snmpEngineTime is set to 0 and the same cycle continues. Using a complex synchronization mechanism described in [10], a SNMP engine at managed node maintains an estimate of the values of time for each of the manager nodes with which it communicates. These estimated values are placed in each outgoing message. The receiving management node's SNMP-engine then determines whether or not the incoming message is in the acceptable time window of 150 seconds[10]. If the message doesn't fit the time window, it is simply ignored.
4.3.3 Privacy Through Encryption
For privacy, the USM uses Data Encryption Standard for ciphering messages. More precisely the CBC-mode of DES is used. The secret key needed for encryption is gained by taking the first eigth octets of the privacy key (privKey) assosiated with the user. The initial vector (IV) needed for the DES encryption algorithm is same as the last eight octets of privacy key. The encryption of the messages is optional. Like authentication key, the encryption key has to be set locally at the managed node.
Using secret key (symmetric) cryptography presents the SNMPv3 system additional challenges. The management of keys becomes a usability and security issue. If all the managed nodes have different secret keys the manager (or the management station used) has to possess the same number of secret keys that there are managed nodes. The setup and management of keys quickly becomes a burden. If the management station is hacked and the secret keys compromised, all the nodes have to be reconfigured by hand [18]. On the other hand one might like to use just one and the same secret key at all the managed nodes. The problem with this is that the compromising the only secret key comporomises the security of the entire management system - that is, all the managed nodes. In USM, however, this problem is solved by utilizing a technique called Key Localization. The key creation, update and management are described in RFC-2274. The idea is to generate a unique key (called localized key) for each user-SNMP-engine pair by using user's password and snmpEngineID, which is the id of the target SNMP engine[18].
4.4 View-Based Access Control
In general, there exist various ways to manage the access control, that is, determing the access rights of a remote user to alter or view the local MIB. This means that the access control is a security function that is performed at the PDU level. The access control mechanism intended to be used with SNMPv3 is called View-Based Access Control (VACM), specified in RFC-2575. [1, 18, 20]
The VACM is specified to determine the access rigths per group basis. This is different from the USM which specifies the authentication of users individially. In VACM each user has to be included in some group and the different groups can then be granted different security levels. This means that there might be, for example, a group of root managers which have the ultimate control to alter all the parameters in all the managed nodes. Additionally, there could be a group of minor, observing managers who would be granted only read permissions to certain parts of each local MIB.
Basically, an SNMPv3 application uses VACM via the isAccessAllowed primitive. The input parameters are securityModel (the security model being used), securityName, securityLevel, viewType (the type of the view), contextName (the context being accessed), and variableName (the variable being accessed). These parameters are necessary for the access control decision in the VACM
The access rights are stored in different tables at the node and each of the tables are consulted to determine the access rights of the requesting manager. The procedure of checking the access rights in the VACM model through the different access control tables is illustrated in Figure 4, that is adapted from [10]. The procedure is based on the following concepts:
- "Who" is the subject of the operation and is defined by securityModel and securityName. This subject then belongs to one group at this SNMPv3 node. Using the combination of securityModel and securityName one can find the corresponding groupName from the vacmSecurityToGroupTable.
- The contextName specifies "where" the desired management object can be found. It is queried from vacmContextTable to see if the requested context even exists.
- "How" is the combination of securityModel and securityLevel and it defines how the incoming request was protected. The combination of who, where, and how indexes one entry in vacmAccessTable.
- The viewType specifies the type of acceess request ("why"). The options are read, write, or notify access request. The selected entry in vacmAccessTable has one MIB viewName for each type of operation. Then, by using the viewType one can query a specific viewName. After that, this viewName indexes the appropriate MIB view in vacmViewTreeFamilyTable.
- The object of the SNMP operation ("what") is defined by the variableName.
The final acceess decision is made by comparing the variableName to the retrieved MIB view. If the variableName is found in the MIB view the access is granted.
4.5 Problems with SNMPv3
Although many of the shortcomings of the basic SNMP are fixed with the USM, still some threats remain because USM wasn't intended to be secure against them [2]. These are denial-of-service type of attacks where attacker prevents the communication between manager and agent and traffic analysis based attacks where third party spies the pattern of flow of the messages between nodes.
According to [18] the Denial of Service threat is hard to prevent as the normal network failures usually reminds the attack. Also, to prevent this kind of attack is something that should be done by some other network node such as firewall instead of having it built internally in SNMP: other services are likely to suffer equally if Denial of Service attack takes place.
One of the most obvious threats of SNMPv3 relates to the use of symmetric cryptography and secret keys. The key management has to be considered and planned very carefully, and the assingment of keys to specific users must be done locally by configuring the managed nodes securely. The key management isn't the only security concern with the symmetric cryptography of the SNMPv3: the basic DES used is in my opinnion too weak an algorithm. For example, SSH uses 3DES which is many times harder to crack than simple DES.
The HMAC is used to provide the message authentication and integrity functions in the USM. However, the outputs of the hashing algoritms are truncated to 12 octects. Quite suprisingly, there are no explanations available to why this is done. Since the truncating of the MAC also weakens the security of the HMAC, I don't see any point in doing so.
The timeliness mechanism for verification of messages is not solving anything, unfortunately. If an attacker wants to perform a replay attack or delay attack, there are still 150 seconds to make it happen - and the timeliness mechanism won't recognize anything unusual has happened. However, the excessively wide reception window is not the only problem with the timeliness mechanism. The clock syncronization between the manager and the managed node is also vulnerable to attacks. This means that the basis for the timeliness mechanism is under a threat of malicious modification, also. An attacker could be able to confuse the clock syncronizing mechaninsm somehow and then perform the message delay or replay attacks.
The complexity of the VACM can be a source of troubles in the security of the SNMPv3. Since the access control information is collectively defined in four different tables, the database integrity and "sanity" of the values stored becomes an issue of concern. What if an attacker succeeds in hacking into the databases of the managed node? Or what if there exist a combination of data that allows anybody to access some critical paramenters? The databases have to be in some secure place, and the sanity of the values has to be checked manually. This is error prone.
5 Web-Based Network Management
5.1 Overview
The Web-Based management, or the management over HTTP, uses the same technologies and functionalities that form the basis for the World Wide Web [14]. The rapid growth of TCP/IP based intranets where the information and the computations are shared economically has given birth to a new way of thinking about the network management. If all the other functions in the network are performed in distributed fashion, why shouldn't the network managent, too.
In WBM, any browser or a piece of software that is capable in communicating through the familiar HTTP protocol can be used for the management purposes [21]. That is, the management task can be performed remotely from any node, independent from whether the node is the actual management station or not. Next, the two major architectures to implement the WBM and their security considerations are discussed. These are the proxy WBM and the embedded WBM.
5.2 The Proxy WBM
The architecture for the proxy WBM solution is shown in the Figure 5a. In this solution the network still contains the specific, dedicated management stations. The only difference to the traditional management is that the management station includes additional web server to handle the HTTP-based requests and the device management software to handle the requests. This way, any manager that uses web browser can remotely use the management station which then, in turn, communicates with managed nodes by means of familiar SNMP protocol. In fact, this scheme of WBM is just a remote control for the SNMP management station. The benefit from this approch is the backwards compatibility in the existing systems: there's no need to make any changes to the managed nodes when WBM is being adopted [21]. The only change is that the management station of the network has to be interfaced to understand and interpret HTTP-based management commands.
5.3 The Embedded WBM
The second approach to achieve the location independent, WWW-based management is called embedded WBM. The architecture for this is illustrated in the Figure 5b. In this scheme there are web servers embedded in each managed node. The manager uses a management station and management applications that communicate using the HTTP protocol. Management software connects to the web server of the managed node and, this way, performs the management functions. The applications at the node can be implemented using for example Java. This approach has emerged only recently as the performance and the capasity of the devices has improved. If the managed node has a JVM running within, the management tasks can be performed even just by sending the management applets to the node to be run locally [21].
5.4 Security Comparison of WBM Architectures
Security considerations of the proxy WBM. There have been large-scale efforts to ensure the security of the HTTP-based transactions in WWW. Strong cryptography (public key cryptography) is extensively used as well as digital signatures. The HTTP part of just described proxy WBM can directly benefit from these to gain a much stronger security compared to the traditional SNMP based management systems. On the other hand, nothing has been solved in sence of security of the management protocol. This is because the actual functional protocol that is transmitted in network is the unsecure SNMP. That is the reason why the proxy WBM apporach is as vulnerable as the original SNMP: The spoofing and spying attacks are still present. In the future, it is likely that SNMPv3 will be used to provide security for proxy WBM. Bearing all this in mind, the main benefit of proxy WBM remains the ease of management through a fancy GUI and the ability to contact the management station from any workstation in the network to perform the management.
Security considerations of the embedded WBM.. The schemes and techniques to make transactions secure through WWW can be used in this model, from end to end. This is because the manager directly connects to the managed node, not via proxy as in the proxy WBM solution described in chapter 5.2. Encryption and authentication can be provided by TLS/SSL, for example, or some other transport layer security protocol. The security of the management function then depends completely on the security (or unsecurity) of the underlying management application. The security of the management applications is not covered in this paper.
In the case of the embedded and JVM based solution, there are also issues that come from Java security. If the management code (Java bytecode) is actually received and ran locally at the management node, the node has to be sure that the data has been sent by a trusted source (authentication) and the data hasn't been changed during the transmission (integrity). The focus in the discussion of security issues moves to the security of running dynamic code in JVM. The Java version 1 was designed so that the remotely downloaded code was only granted very restricted rights in the local JVM. This so called "sandbox"-model didn't allow any operations to alter the data on the underlying physical machine [10]. The Java version 1.1 brought the possiblity to sign the applets digitally. According to the signature of the code, the local JVM is able to determine if the signed code is granted the same access rights as the local code or just the rights of the "sandbox"-model. Now, with Java 1.2, the security architecture has changed to a more flexingle direction. The new version has a more complex scheme that can be used to grant applets permissions to perform, for example, write operations directly on the local hard disk. The permissions must not be any more "grant all rights" or "deny all righs" - any configuration of rights is possible.
The integrity of the code and the authentication of the sender play a very important role when the management Java code is sent over the network. The compiled Java bytecode can be altered maliciously during the transaction by an intercepting third party. The attacker may put some virus that contains a backdoor to the transmitted bytecode. A solution to prevent this is to digitally sign the applets or to encrypt the used connection end-to-end using SSL, for example.[10]
6 Future Improvements and Suggestions
What could be done to improve the overall security of network management? One step towards more secure system admistration over network could be the use of the strong cryptography in authentication and in key negotiation. The encryption of traffic flow would be then accomplished be symmetric ciphering using the negotiated keys. This is the hybrid scheme how SSH works. This would solve the key management and distribution problems.
Almost all the efforts to make the network management easier, more flexible and secure have the same way to address the problems. The network management is seen as the natural part of TCP/IP based intranets and the management scheme is therefore one of the WBM approaches. Also, hybrid schemes for WBM exist. Large organizations that tend to divide the overall network management into several areas can easily start to adapt new ways of management in some parts. For example, the routers and switches could be updated to the embedded WBM technology while retaining the old printer facilities with native SNMPv1 software. This lets the managers use the more secure scheme of network management for critical and most probable targets. The devices that use SNMP only for gathering some kind of status information can be left as they are.
At the moment, the most common way to manage and configure the routers over the network is by using TELNET. There is a high risk of compromising the password while a manager logs into the router remotely. The fact that the TELNET is vulnerable to the sniffing attacks is widely known but, still, the TELNET is used. One suggestion for improving the management of the routers is to use SSH instead of TELNET. The router only needs to be upgraded to contain the SSH software.
In the 46th IETF meeting in Washington DC, some necessary improvements for the SNMPv3 were also pointed out. It was stated that the Internet Engineering Steering Group (IESG) doesn't agree on the encryption protocol that is used in SNMPv3. They think that the simple DES protocol is too weak and not in line with all the other security protocols used in IETF work. So, the standaridized version of the SNMPv3 will almost certainly use the 3DES encryption instead of the simple DES which was critisized in this papers earlier.
7 Conclusions
For reference, the table 2 presents the evolution of the different versions of SNMP and their features [1]
| Version | Time Frame | Security Features | RFCs |
| SNMPv1 | 1988- | Community names (Plaintext strings) | RFC-1155,1157,1212 |
| SNMPv2 | 1993 | Party-Based security | RFC-1441,1452 |
| SNMPv2u | 1995 | User-Based Security | RFC-1909,1910 |
| SNMPv2* | 1995 | User-Based Security | Internet draft only |
| SNMPv2c | 1995- | Community names (Plaintext strings) | RFC-1901 to 1908 |
| SNMPv3 | 1997- | User-Based Security and View-Based Access Control | RFC-1902 to 1908 + 2271 to 2275 |
The security has come to the network management only recently. This seems a bit strange as the network management has a great impact on the functionality and the security of the entire network. The basic SNMP and SNMPv2 protocols are nowadays used merely for monitoring tasks in most cases. And this is just because of the lack of authentication and privacy, the most important security aspects of the network security.
The SNMPv3 brings security to the previous versions of the SNMPs, but the security should be built-in, not added later on. The security scheme used with SNMPv3 seems to provide security partly by obscurity as some of the mechanisms work by using restricting and strange boundary conditions. For example, fitting the time window in sending and receiving messages is described in technically difficult way but it's security hasn't been shown, so the threats remain the same.
The more secure approach to handle network management is by securing the used protocol. This is the case with the network management over SSH or the embedded WBM, for example. The security of the management cannot rely on one part of the system: the whole chain of interactions from end to end has to be secured. After all, it doesn't matter which layer compromises the security.
The security provided by TLS/SSL secure layer could be utilized to provide the transport layer security for network management applications. The vulnerable TELNET protocol could be replaced with SSH when talking about configuring routers remotely. Since it's possible to digitally sign the Java applets, the transportable management Java-bytecode could be used for management purposes as well.
Anyway, with the current status of the security in various SNMP versions, the best solution to prevent attacks agains network management seem to be the firewalls. All SNMP traffic, TCP or UDP, should be blocked from the outside world. Threats from organization itself are also present, and preventing them is quite a different story.
References
| [1] | Backman D., Basking in Glory-SNMPv3, Network Computing [referred 3.11.1999] < http://www.nwc.com/915/915f1.html > |
| [2] | Blumenthal U. & Wijnen B., User-based Security Model (USM) for version 3 of the Simple Network Management
Protocol (SNMPv3), RFC-2574, April 1999, [referred 3.11.1999] < ftp://www.ietf.org/rfc/rfc2574.txt > |
| [3] | Case J., Fedor M., Schoffstall M. & Davin J., Simple Network Management Protocol, RFC-1157, IETF Network
Working Group, May 1990 [referred 3.11.1999] < ftp://www.ietf.org/rfc/rfc1157.txt > |
| [4] | Case J., Harrington D., Presuhn R. & Wijnen B., Message Processing and Dispatching for the Simple Network
Management Protocol (SNMP), RFC-2572, IETF Network Working Group, April 1999 [referred 3.11.1999] < ftp://www.ietf.org/rfc/rfc2572.txt > |
| [5] | Case J., Mundy R., Partain D. & Stewart B., Introduction to Version 3 of the Internet-standard Network
Management Framework, RFC-2570, IETF Network Working Group, April 1999 [referred 3.11.1999] < ftp://www.ietf.org/rfc/rfc2570.txt > |
| [6] | Comer D., Internetworking with TCP/IP, Volume I: Principles, Protocols and Architecture, 3rd Edition,
Prentice-Hall, ISBN 0-13-227836-7 |
| [7] | Davin J., Galvin J. & McCloghrie K., SNMP Administrative Model, RFC-1352, IETF Network
Working Group, July 1992 [referred 3.11.1999] < ftp://www.ietf.org/rfc/rfc1351.txt > |
| [8] | Frye R., Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network
Management Framework, Internet-Draft, 21-May-99, [referred 3.11.1999] < http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-10.txt > |
| [9] | Galvin J., McCloghrie K., Davin J., SNMP Security Protocols, RFC-1352, IETF Network
Working Group, July 1992 [referred 3.11.1999] < ftp://www.ietf.org/rfc/rfc1352.txt > |
| [10] | Gollmann D., Computer Security, Wiley 1999, ISBN 0-471-97844-2 |
| [11] | Halsall F., Data Communications, Computer Networks and Open Systems, 4th Edition, Addison-Wesley 1996, ISBN 0-201-42293-X |
| [12] | Harrington D., Presuhn R. & Wijnen B., An Architecture for Describing SNMP Management Frameworks,
RFC-2571, IETF Network Working Group, April 1999 [referred 3.11.1999] < ftp://ftp.isi.edu/in-notes/rfc2571.txt > |
| [13] | Hautaniemi M., Management and Control of the TCP/IP-network of the Computing Centre at Helsinki
University of Technology, 23.3.1994 [referred 3.11.1999] < http://keskus.hut.fi/julkaisut/tyot/diplomityot/611/SNMP.html#HDR4 2 120 > |
| [14] | Hyde D., Web-Based Management, 12-Aug-99, [referred 3.11.1999] < http://www.3com.com/nsc/500627.html > |
| [15] | Kotiharju A., SNMP Verkonhallinta, 25.3.1996 [referred 3.11.1999] < http://keskus.hut.fi/opetus/s38116/1996/esitelmat/37651p/ > |
| [16] | Levi D., Meyer P. & Stewart B., SNMPv3 Applications, RFC-2573, April 1999, [referred 3.11.1999] < ftp://www.ietf.org/rfc/rfc2573.txt > |
| [17] | Peuhkuri Markus, Verkonhallinta: Luentokalvot, 1997, [referred 3.11.1999] < http://keskus.tct.hut.fi/opetus/s38188/1997/luento12/ > |
| [18] | Stallings W., SNMPv3: A Security Enhancement for SNMP, 6-Oct-98, [referred 3.11.1999] < http://www.comsoc.org/pubs/surveys/4q98issue/stallings.html > |
| [19] | Unknown, Protocol Descriptions at protocols.com [referred 3.11.1999] < http://www.protocols.com/pbook/tcpip7.htm#SNMP > |
| [20] | Wijnen B., Presuhn R. & McCloghrie K., View-based Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP), RFC-2575, April 1999, [referred 3.11.1999] < ftp://www.ietf.org/rfc/rfc2575.txt > |
| [21] | Wipro Infotech Group, [referred 3.11.1999] < http://cybermanage.wipro.com/wpaper-wbnm.html > |
Further Information
- SNMPv3 Charter
- IETF homepage for SNMPv3
- The SimpleWeb
- SNMP information pages at University of Twente
- Network Management Server
- Archive base for SNMP related information
- SNMP Version 3
- General information and links related to SNMPv3
- The Web Based Management Page
- A page that is dedicated for distributing Web-Based Managemnet Information