Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

DHCP Security Issues

DHCP was designed in the early 1990s, when the number of organizations on the Internet

was relatively small. Furthermore, it was based on BOOTP, which was created in the 1980s

when the Internet as we know it today barely even existed. In those days, Internet security

wasn't a big issue, because it was mostly a small group of research and educational organi-

zations using TCP/IP on the Internet. As a result, DHCP, like many protocols of that era,

doesn't do much to address security concerns.

Actually, this is a bit understated. Not only does DHCP run over IP and UDP, which are

inherently insecure, the DHCP protocol itself has in fact no security provisions whatsoever.

This is a fairly serious issue in modern networks, because of the sheer power of DHCP: the

protocol deals with critical configuration information. There are two different classes of

potential security problems related to DHCP:

☯ Unauthorized DHCP Servers: If a malicious person plants a “rogue” DHCP server, it

is possible that this device could respond to client requests and supply them with

spurious configuration information. This could be used to make clients unusable on the

network, or worse, set them up for further abuse later on. For example, a hacker could

exploit a bogus DHCP server to direct a DHCP client to use a router under the

hacker's control, rather than the one the client is supposed to use.

☯ Unauthorized DHCP Clients: A client could be set up that masquerades as a legit-

imate DHCP client and thereby obtain configuration information intended for that

client; this could then be used to compromise the network later on. Alternately, a “bad

guy” could use software to generate lots of bogus DHCP client requests to use up all

the IP addresses in a DHCP server's pool. More simply, this could be used by a thief to

steal an IP address from an organization for his own use.

Adding Security to DHCP

These are obviously serious concerns. The normal recommended solutions to these risks

generally involve providing security at lower layers. For example, one of the most important

techniques for preventing unauthorized servers and clients is careful control over physical

access to the network: layer one security. Security techniques implemented at layer two

may also be of use, for example, in the case of wireless LANs. Since DHCP runs over UDP

and IP, one could use IPSec at layer three to provide authentication.

DHCP Authentication

To try to address some of the more specific security concerns within DHCP itself, in June

2001 the IETF published RFC 3118, Authentication for DHCP Messages. This standard

describes an enhancement that replaces the normal DHCP messages with authenticated

ones. Clients and servers check the authentication information and reject messages that

come from invalid sources. The technology involves the use of a new DHCP option type,

the Authentication option, and operating changes to several of the leasing processes to use

this option.

Unfortunately, 2001 was pretty late in the DHCP game, and there are millions of DHCP

clients and servers around that don't support this new standard. Both client and server must

be programmed to use authentication for this method to have value. A DHCP server that

supports authentication could use it for clients that support the feature and skip it for those

that do not. However, the fact that this option is not universal means that it is not widely

deployed, and most networks must rely on more conventional security measures.

DHCP For IP Version 6 (DHCPv6)

DHCP is currently the standard host configuration protocol for the TCP/IP protocol suite.

TCP/IP is built upon version 4 of the Internet Protocol, also known sometimes as IPv4.

However, development work has been underway since the early 1990s on a successor to

IPv4: version 6 of the Internet Protocol, or IPv6. This new IP standard will be the future of

TCP/IP; it is described in detail in its own section of this Guide.

While most of the changes that IPv6 brings impact technologies at the lower layers of the

TCP/IP architectural model, the significance of the modifications means that many other

TCP/IP protocols are also affected. This is particularly true of protocols that work with

addresses or configuration information, including DHCP. For this reason, a new version of

DHCP is required for IPv6. Development has been underway for quite some time on DHCP

For IPv6, also sometimes called DHCPv6. At the time that I write this topic, DHCPv6 has

not yet been formally published—it is still an Internet draft under discussion. I will provide a

summary of the protocol here, and may expand this into a larger section later.

Note: In discussions purely oriented around IPv6, DHCPv6 is sometimes just

called “DHCP”, and the original DHCP is called “DHCPv4”, so watch out for that!

For obvious reasons, I am not going to do that here.

Two Methods for Autoconfiguration in IPv6

One of the many enhancements introduced in IPv6 is an overall strategy for easier adminis-

tration of IP devices, including host configuration. There are two basic methods defined for

autoconfiguration of IPv6 hosts:

☯ Stateless Autoconfiguration: A method defined to allow a host to configure itself

without help from any other device.

☯ “Stateful” Autoconfiguration: A technique where configuration information is

provided to a host by a server.

Which of these methods is used depends on the characteristics of the network. Stateless

autoconfiguration is described in RFC 2462, and discussed in a separate topic in the IPv6

section. “Stateful” autoconfiguration for IPv6 is provided by DHCPv6. As with regular DHCP,

DHCPv6 may be used to obtain an IP address and other configuration parameters, or just

to get configuration parameters when the client already has an IP address.

DHCPv6 Operation Overview

The operation of DHCPv6 is similar to that of DHCPv4, but the protocol itself has been

completely rewritten. It is not based on the older DHCP or on BOOTP, except in conceptual

terms. It still uses UDP but uses new port numbers, a new message format, and restruc-

tured options. All of this means that the new protocol is not strictly compatible with DHCPv4

or BOOTP, though I believe work is underway on a method to allow DHCPv6 servers to

work with IPv4 devices.

Key Concept: Since DHCP works with IP addresses and other configuration param-

eters, the change from IPv4 to IPv6 requires a new version of DHCP commonly

called DHCPv6. This new DHCP represents a significant change from the original

DHCP, and is still under development. DHCPv6 is used for IPv6 “stateful” autoconfiguration;

the alternative is stateless autoconfiguration, a feature of IPv6 that allows a client to

determine its IP address without need for a server.

DHCPv6 is also oriented around IPv6 methods of addressing, especially the use of link-

local scoped multicast addresses. This allows efficient communication even before a client

has been assigned an IP address. Once a client has an address and knows the identity of a

server it may communicate with the server directly using unicast addressing.

DHCP Message Exchanges

There are two basic client/server message exchanges that are used in DHCPv6: the four-

message exchange and the two-message exchange. The former is used when a client

needs to obtain an IPv6 address and other parameters. This process is similar to the

regular DHCP address allocation process; highly simplified, it involves these steps:

1. The client sends a multicast Solicit message to find a DHCPv6 server and ask for a

lease.

2. Any server that can fulfill the client's request responds to it with an Advertise message.

3. The client chooses one of the servers and sends a Request message to it asking to

confirm the offered address and other parameters.

4. The server responds with a Reply message to finalize the process.

There is also a shorter variation of the four-message process above, where a client sends a

Solicit message and indicates that a server should respond back immediately with a Reply

message.

If the client already has an IP address, either assigned manually or obtained in some other

way, a simpler process can be undertaken, similar to how in regular DHCP the

DHCPINFORM message is used:

1. The client multicasts an Information-Request message.

2. A server with configuration information for the client sends back a Reply message.

As in regular DHCP, a DHCPv6 client renews its lease after a period of time by sending a

Renew message. DHCPv6 also supports relay agent functionality as in DHCPv4.

TCP/IP Network Management Framework and Protocols (SNMP

and RMON)

Modern networks and internetworks are larger, faster and more capable than their prede-

cessors of years gone by. As we expand, speed up and enhance our networks, they

become more complex, and as a result, more difficult to manage. Where years ago an

administrator could get by with very simple tools to keep a network running, today this is

simply insufficient. More sophisticated network management technologies are required to

match the sophistication of our networks.

Some of the most important tools in the network manager's “toolbox” are now in fact

software, not hardware. To manage a sprawling, heterogeneous and complex internetwork,

software applications have been developed that allow information to be gathered and

devices controlled using the internetwork itself. TCP/IP, being the most popular internet-

working suite, of course has such software tools. One of the most important is a pair of

protocols that have been implemented as part of an overall method of network

management called the TCP/IP Internet Standard Management Framework.

In this section I describe in detail the TCP/IP Internet Standard Management Framework,

looking at each of its architectural and protocol components and how they interoperate. The

first subsection provides an overview of the network management framework itself and

serves as an introduction to the sections that follow. The second subsection discusses the

way that network management information is structured and arranged into information

stores called Management Information Bases (MIBs). The third subsection describes the

operation of the key protocol in TCP/IP network management, the Simple Network

Management Protocol (SNMP). Finally, I round out the section with a brief look at Remote

Network Monitoring (RMON), an enhancement of SNMP—sometimes called a protocol,

even though it really isn't—that provides administrators with greater management and

monitoring abilities on a TCP/IP internetwork.

Note: While you may be tempted to jump straight to the subsection on SNMP,

what is written there will make a lot more sense if you read the subsections here in

order.

TCP/IP Internet Standard Management Framework Overview,

Architecture, Components and Concepts

TCP/IP network management functions are most commonly associated with the key

protocol responsible for implementing those functions: the Simple Network Management

Protocol (SNMP). Many people have heard of SNMP, and it is common for SNMP to be

considered “the” way that network management is performed in TCP/IP.

This is true to an extent, but is really an oversimplification. The actual SNMP protocol is

only one part of a higher-level network management strategy called the Internet Standard

Management Framework. In order to really understand how SNMP works, we need to first

have some background on the way this network management is structured as a whole.

In this section I provide an introduction to TCP/IP network management by describing the

concepts and components of the TCP/IP Internet Standard Management Framework. I

begin with an overview and history of the framework, and discuss how it is related to the

Simple Network Management Protocol (SNMP). I describe the TCP/IP network

management model and the key components that comprise a network management

system. I provide a summary of the architecture of the Internet Standard Management

Framework. I then describe the three main versions of the Framework and SNMP, and how

they are similar and different. I conclude with a discussion of the many standards used to

describe this technology.

Overview and History of the TCP/IP Internet Standard Management

Framework and Simple Network Management Protocol (SNMP)

An adage from the world of professional sports says that a baseball umpire is doing a good

job when you forget that he is there. In many ways, the same could be said of a network

administrator. The administrator is doing a good job when the network is running so

smoothly and efficiently that users forget that the administrator exists. Because as the

administrator knows all too well, the second there is a problem, the users will all remember

that he or she is there very quickly. ☺

This means that a primary job of a network administrator is to keep tabs on the network and

ensure that it is operating normally. Information about the hardware and software on the

network is a key to performing this task properly. When networks were small, an adminis-

trator could stay informed about the status of hardware and software using simple means,

such as physically walking over to a computer and using it, or using a low-level link layer

management protocol.

This is simply not possible with modern internetworks, which are large, geographically

diverse, and often consist of many different lower-layer technologies. Usually, the only thing

all the devices on the network have in common is an implementation of a particular internet-

working protocol suite, such as TCP/IP. This makes the internetwork itself a logical way to

facilitate the communication of network management information between devices and a

network administrator.

Early Development of SNMP

Many people recognized during the early days of the Internet that some sort of network

management technology would be needed for TCP/IP. Unfortunately, at first there was no

single standard—in the 1980s, several different technologies were developed by different

working groups. There were three main contestants: the High-level Entity Management

System (HEMS) / High-level Entity Management Protocol (HEMP) as defined by RFCs

1021 through 1024; the Simple Gateway Monitoring Protocol (SGMP), defined by RFC

1028; and the Common Management Information Protocol (CMIP), which is actually part of

the OSI protocol suite.

The Internet Engineering Task Force (IETF) recognized the importance of having a unifying

management standard for TCP/IP, and in 1988 published RFC 1052, IAB Recommenda-

tions for the Development of Internet Network Management Standards. This memo is not a

standard, but more of a statement of intention and documentation of a meeting held on this

subject. The conclusion of RFC 1052 was that SGMP be used as the basis of a new

Internet standard to be called the Simple Network Management Protocol (SNMP). This

development was to be carried out by the SNMP Working Group.

The Two Meanings of "SNMP"

The rationale of the middle two words in the name “Simple Network Management Protocol”

is obvious, but the other two words are slightly more problematic. ☺ The word “Protocol”

implies that SNMP is just a TCP/IP communication protocol, like other protocols such as

DHCP or FTP. Unfortunately, this is both true and untrue: the term “SNMP” is ambiguous.

At a lower level, SNMP does indeed refer specifically to the actual protocol that carries

network management information between devices. This is in fact what most people think of

when they talk about “SNMP”. However, as defined by the SNMP working group, the TCP/

IP network management solution as a whole consists of a number of different elements

arranged in an architecture.

This architecture originally had no specific name, but is now called the Internet Standard

Management Framework. Oddly, this higher-level framework is not abbreviated “ISMF” or

anything like that; it is also called “SNMP”, which means that context is important in under-

standing that term.

Note: To avoid confusion, I will often use the phrases “SNMP Framework” and

“SNMP Protocol” to differentiate these two uses of the term “SNMP”.

Design Goals of SNMP

The word “Simple” in “Simple Network Management Protocol” is another sore spot for me;

having researched and written about this technology, I now consider the presence of this

term in the name “SNMP” to be almost a taunt. Let's put it this way: if a brain surgeon tells

you that something is a “simple procedure”, you probably know to take that with a grain of

salt—well, the same applies here. Even in its first iteration it was only somewhat simple; the

most current version of SNMP is fairly complicated indeed, with many different standards

defining the SNMP Framework, the SNMP Protocol itself, and a number of supporting

elements.

So why is it called “simple”? Well, as they say, everything's relative; SNMP is “simple” when

compared to other protocols that are even more complex. Some of this can be seen by

looking at the basic goals of the Internet Standard Management Framework and the SNMP

protocol as a whole:

☯ SNMP defines a universal way that management information can be easily defined for

any object and then exchanged between that object and a device designed to facilitate

network management;

☯ SNMP separates the functions of defining and communicating management infor-

mation from the applications that are used for network management;

☯ The actual SNMP protocol is fairly simple, consisting of only a few easy-to-understand

protocol operations;

☯ The implementation of SNMP is relatively simple for the designers and manufacturers

of products.

Since SNMP is a TCP/IP application layer protocol, it can theoretically run over a variety of

transport mechanisms. It is most commonly implemented over IP, of course, but the most

recent versions also define transport mappings that can allow SNMP information to be

carried over other internetworking technologies. Again, my focus will continue to be almost

exclusively on TCP/IP.

Key Concept: The Simple Network Management Protocol (SNMP) defines a set of

technologies that allows network administrators to remotely monitor and manage

TCP/IP network devices. The term “SNMP” refers both to a specific communication

protocol (sometimes called the SNMP Protocol) and an overall framework for Internet

management (the SNMP Framework).

Further Development of SNMP and the Problem of SNMP Variations

The description above provides the history of how the first version of SNMP was developed,

leading to the publishing of the first Internet Standard Management Framework in 1988; this

is now called SNMP version 1 (SNMPv1). This initial version of SNMP achieved widespread

acceptance, and it is still probably the most common version of SNMP.

Much of the history of SNMP since that time has been a rather confusing “standards

nightmare”. SNMPv1 had a number of weaknesses, particularly in the area of security. For

this reason, shortly after SNMPv1 was done, work began on a new version of SNMP. Unfor-

tunately, this effort became a quagmire, with many competing variations of SNMPv2 being

created. After many years of confusion, none of the SNMPv2 variants achieved significant

success.

Recently, a third version of the SNMP Framework and Protocol has been published, which

adds new features and “reunites” SNMP back under a single universal protocol again. The

topics on SNMP versions and SNMP standards later in this section further explore the

history of SNMP since 1988; they can be considered a continuation of this topic, as they

help clarify the very confusing story behind SNMP versions over the last decade and a half.

This overview may have put more questions in your mind about the Internet Standard

Management Framework and SNMP than it answered. This is part of why I said this stuff

isn't really that simple. ☺ The next two topics in this section provide more information about

the Framework and its components, and what those components do, so you can under-

stand better what the Framework is all about.

Related Information: More background on the SNMP protocol proper can be

found in the overview topic on the actual protocol itself.

TCP/IP SNMP Operational Model, Components and Terminology.

So, it seems the “Simple” Network Management Protocol (SNMP) isn't quite so simple after

all. There are many versions and standards and uses of SNMP, and so a lot we need to

learn. I think a good place to start in understanding what SNMP does is to look at its model

of operation, and examine the components that comprise a TCP/IP network management

system and the terminology used to describe them.

SNMP Device Types

As we saw in the preceding high-level overview topic, the overall idea behind SNMP is to

allow the information needed for network management to be exchanged using TCP/IP.

More specifically, the protocol allows a network administrator to make use of a special

network device that interacts with other network devices to collect information from them,

and modify how they operate. In the simplest sense, then, two different basic types of

hardware devices are defined:

☯ Managed Nodes: Regular nodes on a network that have been equipped with software

to allow them to be managed using SNMP. These are, generally speaking, conven-

tional TCP/IP devices; they are also sometimes called managed devices.

☯ Network Management Station (NMS): A designated network device that runs special

software to allow it to manage the regular managed nodes mentioned just above. One

or more NMSes must be present on the network, as these devices are the ones that

really “run” SNMP.

SNMP Entities

Each device that participates in network management using SNMP runs a piece of

software, generically called an SNMP entity. The SNMP entity is responsible for imple-

menting all of the various functions of the SNMP protocol. Each entity consists of two

primary software components. Which components comprise the SNMP entity on a device

depends of course on whether the device is a managed node or a network management

station.

Managed Node Entities

An SNMP managed node can be pretty much any network device that can communicate

using TCP/IP, as long as it is programmed with the proper SNMP entity software. SNMP is

designed to allow regular hosts to be managed, as well as intelligent network intercon-

nection devices such as routers, bridges, hubs and switches. Other “unconventional”

devices can likewise be managed, as long as they connect to a TCP/IP internetwork:

printers, scanners, consumer electronic devices, even specialty medical devices and more.

The SNMP entity on a managed node consists of the following software elements and

constructs:

☯ SNMP Agent: A software program that implements the SNMP protocol and allows a

managed node to provide information to an NMS and accept instructions from it.

☯ SNMP Management Information Base (MIB): Defines the types of information stored

about the node that can be collected and used to control the managed node. Infor-

mation exchanged using SNMP takes the form of objects from the MIB.

Network Management Station Entities

On a larger network, a network management station may be a separate, high-powered

TCP/IP computer dedicated to network management. However, it is really software that

makes a device into an NMS, so the NMS may not be a separate hardware device. It may

act as an NMS and also perform other functions on the network.

The SNMP entity on a network management station consists of:

☯ SNMP Manager: A software program that implements the SNMP protocol, allowing

the NMS to collect information from managed nodes and to send instructions to them.

☯ SNMP Applications: One or more software applications that allow a human network

administrator to use SNMP to manage a network.

SNMP Terminology Summary

So, to integrate and reiterate all of this, let's summarize. SNMP consists of a small number

of network management stations (NMSes) that interact with regular TCP/IP devices that are

called managed nodes. The SNMP manager on the NMS and the SNMP agents on the

managed nodes implement the SNMP protocol and allows network management infor-