Tải bản đầy đủ
[Chapter 11] 11.9 Simple Network Management Protocol

[Chapter 11] 11.9 Simple Network Management Protocol

Tải bản đầy đủ

[Chapter 11] 11.9 Simple Network Management Protocol

GetNextRequest Manager requests the next entry in a table.
GetResponse
Agent answers a manager request.
SetRequest
Manager modifies data on the managed device.
Trap
Agent alerts manager of an unusual event.
The NMS periodically requests the status of each managed device (GetRequest) and each agent
responds with the status of its device (GetResponse). Making periodic requests is called polling.
Polling reduces the burden on the agent because the NMS decides when polls are needed, and the
agent simply responds. Polling also reduces the burden on the network because the polls originate
from a single system at a predictable rate. The shortcoming of polling is that it does not allow for realtime updates. If a problem occurs on a managed device, the manager does not find out until the agent
is polled. To handle this, SNMP uses a modified polling system called trap-directed polling.
A trap is an interrupt signaled by a predefined event. When a trap event occurs, the SNMP agent does
not wait for the manager to poll; instead it immediately sends information to the manager. Traps allow
the agent to inform the manager of unusual events while allowing the manager to maintain control of
polling. SNMP traps are sent on UDP port 162. The manager sends polls on port 161 and listens for
traps on port 162. Table 11.4 lists the trap events defined in the RFCs.
Table 11.4: Generic Traps Defined in the RFCs
Trap
Meaning
coldStart
Agent restarted; possible configuration changes
warmStart
Agent reinitialized without configuration changes
enterpriseSpecific
An event significant to this hardware or software
authenticationFailure Agent received an unauthenticated message
linkDown
Agent detected a network link failure
linkUp
Agent detected a network link coming up
egpNeighborLoss
The device's EGP neighbor is down
The last three entries in this table show the roots of SNMP in Simple Gateway Management Protocol
(SGMP), which was a tool for tracking the status of network routers. Routers are generally the only
devices that have multiple network links to keep track of and are the only devices that run Exterior
Gateway Protocol (EGP). [12] These traps are not significant for most systems.
[12] EGP is covered in Chapter 7.
The most important trap may be the enterpriseSpecific trap. The events that signal this trap are
defined differently by every vendor's SNMP agent software. Therefore it is possible for the trap to be
tuned to events that are significant for that system. SNMP uses the term "enterprise" to refer to
something that is privately defined by a vendor or organization as opposed to something that is
globally defined by an RFC.

file:///C|/mynapster/Downloads/warez/tcpip/ch11_09.htm (2 of 5) [2001-10-15 09:18:52]

[Chapter 11] 11.9 Simple Network Management Protocol

SNMP has twice as much jargon as the rest of networking - and that's saying something! Managed
Network Entity, NMS, PDU, trap, polling, enterprise - that's just the beginning! We also need to
mention (below) what SMI is, what a MIB is, and what ANS.1 is used for. Why this bewildering array
of acronyms and buzzwords? I think there are two main reasons:




Network management covers a wide range of different devices, from repeaters to mainframe
computers. A "vendor-neutral" language is needed to define terms for the manufacturers of all
of this different equipment.
SNMP is based on the Common Management Information Protocol (CMIP) that was created
by the International Standards Organization (ISO). Formal international standards always
spend a lot of time defining terms because it is important to make terms clear when they are
used by people from many different cultures who speak many different languages.

Now that you know why you have to suffer through all of this jargon, let's define a few more
important terms.
The Structure of Management Information (SMI) defines how data should be presented in an SNMP
environment. The SMI is documented in RFC 1155 and RFC 1065, Structure and Identification of
Management Information for TCP/IP-based Internets. The SMI defines how managed objects are
named, the syntax in which they are defined, and how they are encoded for transmission over the
network. The SMI is based on previous ISO work.
Each managed object is given a globally unique name called an object identifier. The object identifier
is part of a hierarchical name space that is managed by the ISO. The hierarchical name structure is
used, just like it is in DNS, to guarantee that each name is globally unique. In an object identifier,
each level of the hierarchy is identified by a number.
Objects are defined just as formally as they are named. The syntax used to define managed objects is
Abstract Syntax Notation One (ASN.1). ASN.1 is ISO Standard 8824, Specification of Abstract Syntax
Notation One (ASN.1). It is a very formal set of language rules for defining data. It makes the data
definition independent of incompatibilities between systems and character sets. ASN.1 also includes a
set of rules for encoding data for transfer over a network. These rules are defined in ISO Standard
8825, Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). The Basic
Encoding Rules (BER) define that bit 8 of an octet is sent first, that 2's complement is used for signed
integers, and other nitty-gritty details of data transmission.
Every object managed by SNMP has a unique object identifier defined by the ASN.1 syntax and
encoding defined by BER. When all of these unique objects are grouped together, they are called the
Management Information Base (MIB). The MIB refers to all information that is managed by SNMP.
However, we usually refer to "a MIB" or "the MIBs" (plural), meaning the individual databases of
management information formally defined by an RFC or privately defined by a vendor.
MIBI and MIBII are standards defined by RFCs. MIBII is a superset of MIBI, and is the standard
MIB for monitoring TCP/IP. It provides such information as the number of packets transmitted into
and out of an interface, and the number of errors that occurred sending and receiving those packets file:///C|/mynapster/Downloads/warez/tcpip/ch11_09.htm (3 of 5) [2001-10-15 09:18:52]

[Chapter 11] 11.9 Simple Network Management Protocol

useful information for spotting usage trends and potential trouble spots. Every agent supports MIBI or
MIBII.
Some systems also provide a private MIB in addition to the standard MIBII. Private MIBs add to the
monitoring capability by providing system-specific information. Most UNIX systems do not provide
private MIBs. Private MIBs are most common on network hardware like routers, hubs, and switches.
No matter what MIBs are provided by the agents, it is the monitoring software that displays the
information for the system administrator. A private MIB won't do you any good unless your network
monitoring software also supports that MIB. For this reason, most administrators prefer to purchase a
monitor from the vendor that supplies the bulk of their network equipment. Another possibility is to
select a monitor that includes a MIB compiler, which gives you the most flexibility. A MIB compiler
reads in the ASN.1 description of a MIB and adds the MIB to the monitor. A MIB compiler makes the
monitor extensible because if you can get the ASN.1 source from the network equipment vendor, you
can add the vendor's private MIB to your monitor.
MIB compilers are only part of the advanced features offered by some monitors. Some of the features
offered are:
Network maps
Some monitors automatically draw a map of the network. Colors are used to indicate the state
(up, down, etc.) of the devices on the network. At a glance, the network manager sees the
overall state of the network.
Tabular data displays
Data displayed in tables or rendered into charts is used to make comparisons between different
devices. Some monitors output data that can then be read into a standard spreadsheet or
graphing program.
Filters
Filters sift the data coming in from the agents in order to detect certain conditions.
Alarms
Alarms indicate when "thresholds" are exceeded or special events occur. For example, you
may want an alarm to trigger when your server exceeds some specified number of transmit
errors.
Don't be put off by the jargon. All of this detail is necessary to formally define a network management
scheme that is independent of the managed systems, but you don't need to memorize it. You need to
know that a MIB is a collection of management information, that an NMS is the network management
station, and that an agent runs in each managed device in order to make intelligent decisions when
selecting an SNMP monitor. This information provides that necessary background. The features
available in network monitors vary widely; so does the price. Select an SNMP monitor that is suitable
for the complexity of your network and the size of your budget.
file:///C|/mynapster/Downloads/warez/tcpip/ch11_09.htm (4 of 5) [2001-10-15 09:18:52]

[Chapter 11] 11.9 Simple Network Management Protocol

Previous: 11.8 Protocol
Case Study
11.8 Protocol Case Study

TCP/IP Network
Administration
Book Index

Next: 11.10 Summary
11.10 Summary

[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]

file:///C|/mynapster/Downloads/warez/tcpip/ch11_09.htm (5 of 5) [2001-10-15 09:18:52]

file:///C|/mynapster/Downloads/warez/tcpip/ch11_10.htm

Previous: 11.9 Simple
Network Management
Protocol

Chapter 11
Troubleshooting TCP/IP

Next: 12. Network Security

11.10 Summary
Every network will have problems. This chapter discusses the tools and techniques that can help you
recover from these problems, and the planning and monitoring that can help avoid them. A solution is
sometimes obvious if you can just gain enough information about the problem. UNIX provides
several built-in software tools that can help you gather information about system configuration,
addressing, routing, name service and other vital network components. Gather your tools and learn
how to use them before a breakdown occurs.
In the next chapter, we talk about another task that is important to the maintenance of a reliable
network: keeping your network secure.

Previous: 11.9 Simple
Network Management
Protocol
11.9 Simple Network
Management Protocol

TCP/IP Network
Administration
Book Index

Next: 12. Network Security

12. Network Security

[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]

file:///C|/mynapster/Downloads/warez/tcpip/ch11_10.htm [2001-10-15 09:18:53]

[Chapter 12] Network Security

Previous: 11.10 Summary

Chapter 12

Next: 12.2 User
Authentication

12. Network Security
Contents:
Security Planning
User Authentication
Application Security
Security Monitoring
Access Control
Encryption
Firewalls
Words to the Wise
Summary
Hosts attached to a network - particularly the worldwide Internet - are exposed to a wider range of
security threats than are unconnected hosts. Network security reduces the risks of connecting to a
network. But by nature, network access and computer security work at cross-purposes. A network is a
data highway designed to increase access to computer systems, while security is designed to control
access. Providing network security is a balancing act between open access and security.
The highway analogy is very appropriate. Like a highway, the network provides equal access for all welcome visitors as well as unwelcome intruders. At home, you provide security for your possessions
by locking your house, not by blocking the streets. Likewise, network security generally means
providing adequate security on individual host computers, not providing security directly on the
network.
In very small towns, where people know each other, doors are often left unlocked. But in big cities,
doors have deadbolts and chains. In the last decade, the Internet has grown from a small town of a few
thousand users to a big city of millions of users. Just as the anonymity of a big city turns neighbors
into strangers, the growth of the Internet has reduced the level of trust between network neighbors.
The ever-increasing need for computer security is an unfortunate side effect. Growth, however, is not
all bad. In the same way that a big city offers more choices and more services, the expanded network
provides increased services. For most of us, security consciousness is a small price to pay for network
access.

file:///C|/mynapster/Downloads/warez/tcpip/ch12_01.htm (1 of 7) [2001-10-15 09:18:54]

[Chapter 12] Network Security

Network break-ins have increased as the network has grown and become more impersonal, but it is
easy to exaggerate the extent of these security breaches. Over-reacting to the threat of break-ins may
hinder the way you use the network. Don't make the cure worse than the disease. The best advice
about network security is to use common sense. RFC 1244, Site Security Handbook, by Holbrook,
Reynold, et al., states this principle very well:
Common sense is the most appropriate tool that can be used to establish your security
policy. Elaborate security schemes and mechanisms are impressive, and they do have
their place, yet there is little point in investing money and time on an elaborate
implementation scheme if the simple controls are forgotten.
This chapter emphasizes the simple controls that can be used to increase your network's security. A
reasonable approach to security, based on the level of security required by your system, is the most
cost-effective - both in terms of actual expense and in terms of productivity.

12.1 Security Planning
One of the most important network security tasks, and probably one of the least enjoyable, is
developing a network security policy. Most computer people want a technical solution to every
problem. We want to find a program that "fixes" the network security problem. Few of us want to
write a paper on network security policies and procedures. However, a well-thought-out security plan
will help you decide what needs to be protected, how much you are willing to invest in protecting it,
and who will be responsible for carrying out the steps to protect it.

12.1.1 Assessing the Threat
The first step toward developing an effective network security plan is to assess the threat that
connection presents to your systems. RFC 1244 identifies three distinct types of security threats
usually associated with network connectivity:
Unauthorized access
A break-in by an unauthorized person.
Disclosure of information
Any problem that causes the disclosure of valuable or sensitive information to people who
should not have access to the information.
Denial of service
Any problem that makes it difficult or impossible for the system to continue to perform
productive work.
Assess these threats in relation to the number of users who would be affected, as well as to the

file:///C|/mynapster/Downloads/warez/tcpip/ch12_01.htm (2 of 7) [2001-10-15 09:18:54]

[Chapter 12] Network Security

sensitivity of the information that might be compromised. For some organizations, break-ins are an
embarrassment that can undermine the confidence that others have in the organization. Intruders tend
to target government and academic organizations that will be embarrassed by the break-in. But for
most organizations, unauthorized access is not a major problem unless it involves one of the other
threats: disclosure of information or denial of service.
Assessing the threat of information disclosure depends on the type of information that could be
compromised. While no system with highly classified information should ever be directly connected
to the Internet, systems with other types of sensitive information might be connected without undue
hazard. In most cases, files such as personnel and medical records, corporate plans, and credit reports
can be adequately protected by standard UNIX file security procedures. However, if the risk of
liability in case of disclosure is great, the host may choose not to be connected to the Internet.
Denial of service can be a severe problem if it impacts many users or a major mission of your
organization. Some systems can be connected to the network with little concern. The benefit of
connecting individual workstations and small servers to the Internet generally outweighs the chance of
having service interrupted for the individuals and small groups served by these systems. Other
systems may be vital to the survival of your organization. The threat of losing the services of a
mission-critical system must be evaluated seriously before connecting such a system to the network.
In his class on computer security, Brent Chapman classifies information security threats into three
categories: threats to the secrecy, availability, and integrity of data. Secrecy is the need to prevent the
disclosure of sensitive information. Availability means that you want information and information
processing resources available when they are needed; a denial-of-service attack disrupts availability.
The need for the integrity of information is equally obvious, but its link to computer security is more
subtle. Once someone has gained unauthorized access to a system, the integrity of the information on
that system is in doubt. Furthermore, some intruders just want to compromise the integrity of data. We
are all familiar with cases where intruders gain access to a Web server and change the data on the
server in order to embarrass the organization that runs the Web site. Thinking about the impact
network threats have on your data can make it easier to assess the threat.
Network threats are not, of course, the only threats to computer security, or the only reasons for denial
of service. Natural disasters and internal threats (threats from people who have legitimate access to a
system) are also serious. Network security has had a lot of publicity, so it's a fashionable thing to
worry about; but more computer time has probably been lost because of fires than has ever been lost
because of network security problems. Similarly, more data has probably been improperly disclosed
by authorized users than by unauthorized break-ins. This book naturally emphasizes network security,
but network security is only part of a larger security plan that includes physical security and disaster
recovery plans.
Many traditional (non-network) security threats are handled, in part, by physical security. Don't forget
to provide an adequate level of physical security for your network equipment and cables. Again, the
investment in physical security should be based on your realistic assessment of the threat.

12.1.2 Distributed Control
file:///C|/mynapster/Downloads/warez/tcpip/ch12_01.htm (3 of 7) [2001-10-15 09:18:54]

[Chapter 12] Network Security

One approach to network security is to distribute responsibility for, and control over, segments of a
large network to small groups within the organization. This approach involves a large number of
people in security, and runs counter to the school of thought that seeks to increase security by
centralizing control. However, distributing responsibility and control to small groups can create an
environment of small networks composed of trusted hosts. Using the analogy of small towns and big
cities, it is similar to creating a neighborhood watch to reduce risks by giving people connection with
their neighbors, mutual responsibility for one another, and control over their own fates.
Additionally, distributing security responsibilities formally recognizes one of the realities of network
security - most security actions take place on individual systems. The managers of these systems must
know that they are responsible for security, and that their contribution to network security is
recognized and appreciated. If people are expected to do a job, they must be empowered to do it.
12.1.2.1 Use subnets to distribute control
Subnets are a possible tool for distributing network control. A subnet administrator should be
appointed when a subnet is created. She is then responsible for the security of the network and for
assigning IP addresses to the devices connected to the networks. Assigning IP addresses gives the
subnet administrator some control over who connects to the subnet. It also helps to ensure that she
knows each system connected and who is responsible for that system. When the subnet administrator
gives a system an IP address, she also delegates certain security responsibilities to the system's
administrator. Likewise, when the system administrator grants a user an account, the user takes on
certain security responsibilities.
The hierarchy of responsibility flows from the network administrator, to the subnet administrator, to
the system administrator, and finally to the user. At each point in this hierarchy the individuals are
given responsibilities and the power to carry them out. To support this structure, it is important for
users to know what they are responsible for and how to carry out that responsibility. The network
security policy described in the next section provides this information.
12.1.2.2 Use mailing lists to distribute information
If your site adopts distributed control, you must develop a system for disseminating security
information to each group. Mailing lists for each administrative level can be used for this purpose.
The network administrator receives security information from outside authorities, filters out irrelevant
material, and forwards the relevant material to the subnet administrators. Subnet administrators
forward the relevant parts to their system administrators, who in turn forward what they consider
important to the individual users. The filtering of information at each level ensures that individuals get
the information they need, without receiving too much. If too much unnecessary material is
distributed, users begin to ignore everything they receive.
At the top of this information structure is the information that the network administrator receives from
outside authorities. In order to receive this, the network administrator should join the appropriate
mailing lists and newsgroups and browse the appropriate Web sites. A few places to start looking for

file:///C|/mynapster/Downloads/warez/tcpip/ch12_01.htm (4 of 7) [2001-10-15 09:18:54]

[Chapter 12] Network Security

computer security information are the following:
Your UNIX Vendor
Many vendors have their own security information mailing lists.
Security Newsgroups
The comp.security newsgroups - comp.security.unix, comp.security.firewalls,
comp.security.announce, and comp.security.misc - contain some useful information. Like most
newsgroups, they contain lots of unimportant and uninteresting material. But they also contain
an occasional gem.
FIRST Mailing List
The Forum of Incident Response and Security Teams (FIRST) is a worldwide organization of
computer security response teams. FIRST provides a public mailing list, first-info@first.org,
for computer security information. To subscribe to this list, send email to firstmajordomo@first.org that contains the line:
subscribe first-info YOUR-EMAIL-ADDRESS
where YOUR-EMAIL-ADDRESS is literally your email address.
NIST Computer Security Alerts
The National Institute of Standards and Technology's Computer Security Division maintains a
Web site with pointers to security-related Web pages all over the world. As a single source for
security alerts from several different organizations, the site http://csrc.nist.gov/secalert/ can't be
beat.
Computer Emergency Response Team (CERT) Advisories
The CERT advisories provide information about known security problems, and the fixes to
these problems. You can retrieve these advisories from ftp://info.cert.org/pub/cert_advisories.
The CERT Web site is also worth a visit: http://www.cert.org.
DDN Security Bulletins
These bulletins are very similar in content to the CERT advisories, though DDN bulletins do
occasionally add information. DDN bulletins and CERT advisories deal primarily with
network security threats. DDN bulletins can be viewed online with your Web browser at
http://nic.ddn.mil/SCC/bulletins.html.
Risks Forum
The risks forum discusses the full range of computer security risks. The forum is available on
the Web at http://catless.ncl.ac.uk/Risks.
Computer Virus Information

file:///C|/mynapster/Downloads/warez/tcpip/ch12_01.htm (5 of 7) [2001-10-15 09:18:54]

[Chapter 12] Network Security

The VIRUS-L list deals primarily with computer viruses - a threat usually associated with PCs.
You can retrieve the VIRUS-L archive from ftp://ftp.infospace.com/pub/virus-l. An equally
important document, at http://ciac.llnl.gov/ciac/CIACHoaxes.html, provides information about
computer virus hoaxes. False rumors about computer viruses can waste as much time as
tracking down real viruses.

12.1.3 Writing a Security Policy
Security is largely a "people problem." People, not computers, are responsible for implementing
security procedures, and people are responsible when security is breached. Therefore, network
security is ineffective unless people know their responsibilities. It is important to write a security
policy that clearly states what is expected and who it is expected from. A network security policy
should define:
The network user's security responsibilities
The policy may require users to change their passwords at certain intervals, to use passwords
that meet certain guidelines, or to perform certain checks to see if their accounts have been
accessed by someone else. Whatever is expected from users, it is important that it be clearly
defined.
The system administrator's security responsibilities
The policy may require that every host use specific security measures, login banner messages,
and monitoring and accounting procedures. It might list applications that should not be run on
any host attached to the network.
The proper use of network resources
Define who can use network resources, what things they can do, and what things they should
not do. If your organization takes the position that email, files, and histories of computer
activity are subject to security monitoring, tell the users very clearly that this is the policy.
The actions taken when a security problem is detected
What should be done when a security problem is detected? Who should be notified? It is easy
to overlook things during a crisis, so you should have a detailed list of the exact steps that a
system administrator, or user, should take when a security breach has been detected. This could
be as simple as telling the users to "touch nothing, and call the network security officer." But
even these simple actions should be in the policy so that they are readily available.
Connecting to the Internet brings with it certain security responsibilities. RFC 1281, A Guideline for
the Secure Operation of the Internet, provides guidance for users and network administrators on how
to use the Internet in a secure and responsible manner. Reading this RFC will provide insight into the
information that should be in your security policy.
A great deal of thought is necessary to produce a complete network security policy. The outline

file:///C|/mynapster/Downloads/warez/tcpip/ch12_01.htm (6 of 7) [2001-10-15 09:18:54]