دوستان گرامی امشب من خیلی رو به راه هستم . در مورد مطلب قبلی در ویکی پیدیا یه مطلب انگلیسی پیدا کردم ان را می گذارم برای کسانی که دوست دارند مقاله های لاتین را بخوانند:
Protocol details
SNMPv1 and SMI-specific data types
The first version of the SMI
(SMIv1) specifies the use of a number of SMI-specific data types, which are
divided into two categories:
- Simple data types
- Application-wide data types
Simple data types
Three simple data types are defined in the SNMPv1 SMI, all
of which are unique values:
- The integer data type is a
signed integer in the range of -231 to 231-1.
- Octet strings are ordered
sequences of 0 to 65,535 octets.
- Object IDs come from the set of
all object identifiers allocated according to the rules specified in
ASN.1.
Application-wide data types
The following application-wide data types exist in the
SNMPv1 SMI:
- Network addresses represent addresses from a particular protocol family.
SMIv1 supports only 32-bit (IPv4) addresses (SMIv2 uses Octet Strings to
represent addresses generically, and thus are usable in SMIv1 too. SMIv1
had an explicit IPv4 address datatype.)
- Counters are non-negative integers that increase until they
reach a maximum value and then roll over to zero. SNMPv1 specifies a
counter size of 32 bits.
- Gauges are non-negative integers that can increase or
decrease between specified minimum and maximum values. Whenever the system
property represented by the gauge is outside of that range, the value of
the gauge itself will vary no further than the respective maximum or minimum,
as specified in RFC 2578.
- Time ticks represent time since some event, measured in
hundredths of a second.
- Opaques represent an arbitrary encoding that is used to pass arbitrary
information strings that do not conform to the strict data typing used by
the SMI.
- Integers represent signed integer-valued information. This data
type redefines the integer data type, which has arbitrary precision in
ASN.1 but bounded precision in the SMI.
- Unsigned integers represent unsigned integer-valued information, which
is useful when values are always non-negative. This data type redefines
the integer data type, which has arbitrary precision in ASN.1 but bounded
precision in the SMI.
SNMPv1 MIB tables
The SNMPv1 SMI defines highly structured tables that are
used to group the instances of a tabular object (that is, an object that
contains multiple variables). Tables are composed of zero or more rows, which
are indexed in a way that allows SNMP to retrieve or alter an entire row with a
single Get, GetNext, or Set commands.
SNMPv2 and structure of management
information
The second version of the SMI (SMIv2) is described in RFC 2578
- RFC
2579. It makes certain additions and enhancements to the
SMIv1-specific data types, such as including bit strings, network addresses,
and counters. Bit strings are defined only in SMIv2 and comprise zero or more
named bits that specify a value. Network addresses represent an address from a
particular protocol family. Counters are non-negative integers that increase
until they reach a maximum value and then return to zero. In SMIv1, a 32-bit
counter size is specified. In SMIv2, 32-bit and 64-bit counters are defined.
SNMPv1 specifies (in version 1) five core protocol data units
(PDUs). Other PDUs were added
in SNMPv2 and carried over to SNMPv3.
SNMPv2 SMI information modules
The SNMPv2 SMI also specifies information modules, which
specify a group of related definitions. Three types of SMI information modules
exist: MIB modules, compliance statements, and capability statements.
- MIB modules contain definitions
of interrelated managed objects.
- Compliance statements provide a
systematic way to describe a group of managed objects that must be
implemented for conformance to a standard.
- Capability statements are used
to indicate the precise level of support that an agent claims with respect
to a MIB group. A NMS can adjust its behavior toward agents according to
the capabilities statements associated with each agent.
SNMPv3
SNMPv3 is defined by RFC 3411–RFC 3418
(also known as 'STD0062'). SNMPv3 primarily added security and remote
configuration enhancements to SNMP.[2] SNMPv3 is the current standard version
of SNMP as of 2004[update]. The IETF
has designated SNMPv3 a full Internet Standard,[3]
the highest maturity level
for an RFC. It considers earlier versions to be obsolete (designating them
"Historic").[4]
In December 1997 the "Simple Times" newsletter published several
articles written by the SNMPv3 RFC editors explaining some of the ideas behind
version 3 specifications.[5]
SNMPv3 provides important security features:[6]
- Message integrity to ensure that a packet
has not been tampered with in transit.
- Authentication to verify that the message is
from a valid source.
- Encryption of packets to prevent snooping by
an unauthorized source.
Development and usage
Version
1
SNMP version 1 (SNMPv1) is the initial implementation of the
SNMP protocol. SNMPv1 operates over protocols such as User Datagram Protocol
(UDP), Internet Protocol (IP), OSI Connectionless Network Service (CLNS),
AppleTalk Datagram-Delivery Protocol (DDP), and Novell Internet Packet Exchange
(IPX). SNMPv1 is widely used and is the de facto network-management protocol in
the Internet community.
The first RFCs for SNMP,
now known as SNMPv1, appeared in 1988:
- RFC
1065 — Structure and identification of management information
for TCP/IP-based internets
- RFC
1066 — Management information base for network management of
TCP/IP-based internets
- RFC
1067 — A simple network management protocol
These protocols were obsoleted by:
- RFC
1155 — Structure and identification of management information
for TCP/IP-based internets
- RFC
1156 — Management information base for network management of
TCP/IP-based internets
- RFC
1157 — A simple network management protocol
After a short time, RFC 1156
(MIB-1) was replaced by more often used:
- RFC 1213
— Version 2 of management information base (MIB-2) for network management
of TCP/IP-based internets
Version 1 has been criticized for its poor security.
Authentication of clients is performed only by a "community string",
in effect a type of password, which is transmitted in cleartext. The '80s
design of SNMP V1 was done by a group of collaborators who viewed the
officially sponsored OSI/IETF/NSF (National Science Foundation) effort
(HEMS/CMIS/CMIP) as both unimplementable in the computing platforms of the time
as well as potentially unworkable. SNMP was approved based on a belief that it
was an interim protocol needed for taking steps towards large scale deployment
of the Internet and its commercialization. In that time period Internet-standard
authentication/security was both a dream and discouraged by focused protocol
design groups.
Version
2
SNMPv2 (RFC 1441–RFC 1452),
revises version 1 and includes improvements in the areas of performance,
security, confidentiality, and manager-to-manager communications. It introduced
GETBULK, an alternative to iterative GETNEXTs for retrieving large amounts of
management data in a single request. However, the new party-based security
system in SNMP v2, viewed by many as overly complex, was not widely accepted.
Community-Based Simple Network Management Protocol version 2, or SNMPv2c, is defined in RFC 1901–RFC 1908.
In its initial stages, this was also informally known as SNMP v1.5. SNMP
v2c comprises SNMP v2 without the controversial new SNMP v2 security
model, using instead the simple community-based security scheme of SNMP v1.
While officially only a "Draft Standard", this is widely considered
the de facto SNMP v2 standard.
User-Based Simple Network Management Protocol version 2, or SNMP v2u, is defined in RFC 1909–RFC 1910.
This is a compromise that attempts to offer greater security than SNMP v1, but
without incurring the high complexity of SNMP v2. A variant of this was
commercialized as SNMP v2*, and the mechanism was eventually adopted as
one of two security frameworks in SNMP v3.
SNMPv1 & SNMPv2c interoperability
As presently specified, SNMPv2 is incompatible with SNMPv1
in two key areas: message formats and protocol operations. SNMPv2c messages use
different header and protocol data unit (PDU) formats from SNMPv1 messages.
SNMPv2c also uses two protocol operations that are not specified in SNMPv1.
Furthermore, RFC 1908 defines two possible SNMPv1/v2c
coexistence strategies: proxy agents and bilingual network-management systems.
Proxy
agents
A SNMPv2 agent can act as a proxy agent on behalf of SNMPv1
managed devices, as follows:
- A SNMPv2 NMS issues a command
intended for a SNMPv1 agent.
- The NMS sends the SNMP message
to the SNMPv2 proxy agent.
- The proxy agent forwards Get, GetNext, and Set messages to the SNMPv1 agent unchanged.
- GetBulk messages are converted
by the proxy agent to GetNext messages and then are forwarded to the SNMPv1 agent.
The proxy agent maps SNMPv1 trap messages to SNMPv2 trap
messages and then forwards them to the NMS.
Bilingual network-management system
Bilingual SNMPv2 network-management systems support both
SNMPv1 and SNMPv2. To support this dual-management environment, a management
application in the bilingual NMS must contact an agent. The NMS then examines
information stored in a local database to determine whether the agent supports
SNMPv1 or SNMPv2. Based on the information in the database, the NMS
communicates with the agent using the appropriate version of SNMP.
Version
3
The IETF
recognizes Simple Network Management Protocol version 3 as defined by RFC 3411–RFC 3418
(also known as STD0062) as the current standard version of SNMP as of 2004[update]. The IETF considers earlier
versions as "Obsolete" or "Historical".
In practice, SNMP implementations often support multiple
versions: typically SNMPv1, SNMPv2c, and SNMPv3. See RFC 3584
"Coexistence between Version 1, Version 2, and Version 3 of the
Internet-standard Network Management Framework".
SNMPv3 provides three important services: authentication, privacy and access control.
Autodiscovery
SNMP by itself is simply a protocol for collecting and
organizing information. Most toolsets implementing SNMP offer some form of
discovery mechanism, a standardized collection of data common to most platforms
and devices, to get a new user or implementor started. One of these features is
often a form of automatic discovery, where new devices discovered in the
network are polled automatically. For SNMPv1 and SNMPv2c, this presents a
security risk, in that your SNMP read communities will be broadcast in
cleartext to the target device. While security requirements and risk profiles
vary from organization to organization, care should be taken when using a
feature like this, with special regard to common environments such as
mixed-tenant datacenters, server hosting and colocation facilities, and similar
environments.
Implementation issues
SNMP implementations vary across platform vendors. In some
cases, SNMP is an added feature, and is not taken seriously enough to be an
element of the core design. Some major equipment vendors tend to over extend
their proprietary Command Line Interface
(CLI) centric configuration and control systems.[7]
SNMP's seemingly simple tree structure and linear indexing
may not always be understood well enough within the internal data structures
that are elements of a platform's basic design. As a result, processing SNMP
queries on certain data sets may result in higher CPU utilization than
necessary. One example of this would be large routing tables, such as BGP or IGP.
Resource indexing
Modular devices may dynamically increase or decrease their
SNMP indexes (aka instances) whenever slotted hardware is added or removed.
Although this is most common with hardware, virtual interfaces have the same
effect. Index values are typically assigned at boot time and remain fixed until
the next reboot. Hardware or virtual entities added while the device is 'live'
may have their indexes assigned at the end of the existing range and possibly
reassigned at the next reboot. Network inventory and monitoring tools need to
have the device update capability by properly reacting to the cold start trap
from the device reboot in order to avoid corruption and mismatch of polled
data.
Index assignments for an SNMP device instance may change
from poll to poll mostly as a result of changes initiated by the system admin.
If information is needed for a particular interface, it is imperative to
determine the SNMP index before retrieving the data needed. Generally, a
description table like ifDescr will map a user friendly name like Serial 0/1
(Blade 0, port 1) to a SNMP index.
[edit]
Environmental monitoring
Server, rack and appliance
operating temperatures and room humidity could be monitored remotely for
SNMP-enabled HVAC devices.[1][2]
Security implications
- SNMP versions 1 and 2c are
subject to packet sniffing
of the clear text community string from the network traffic, because they
do not implement encryption.
- All versions of SNMP are
subject to brute force
and dictionary attacks
for guessing the community strings/authentication strings/authentication
keys/encryption strings/encryption keys, because they do not implement a challenge-response handshake. Entropy is
an important consideration when selecting keys, passwords and/or
algorithms.
- Although SNMP works over TCP
and other protocols, it is most commonly used over UDP
that is connectionless and vulnerable to IP spoofing attacks. Thus, all versions are
subject to bypassing device access lists that might have been implemented
to restrict SNMP access, though SNMPv3's other security mechanisms should
prevent a successful attack.
- SNMP's powerful configuration
(write) capabilities are not being fully utilized by many vendors, partly
due to lack of security in SNMP versions before SNMPv3 and partly due to
the fact that many devices simply are not capable of being configured via
individual mib object changes.
- SNMP tops the list of the SANS Institute's Common Default Configuration
Issues with the issue of default SNMP community strings set to ‘public’
and ‘private’ and was number ten on the SANS Top 10
Most Critical Internet Security Threats for the year 2000.
For more detail on SNMP security implications see the CERT
SNMP
Vulnerabilities FAQ
+ نوشته شده توسط مهدی مهدی زاده در
88/08/15 و ساعت
23:11 |
