|
|
![]() ![]() Basking in Glory-SNMPv3 |
|
At present, IETF-proposed standards for SNMPv3 (Requests for Comments 2271 to 2275) aim to accomplish two goals: incorporate as much as possible from the stalled SNMPv2 standards and provide an effective security solution. To those ends, most protocol-level improvements, such as improved MIB language and GetBulk operators, come straight from SNMPv2 work. However, the third-generation protocol also strives to ensure SNMP's modularity and management. First, SNMPv3 gives credence to various non-security-related improvements originally put forth in the SNMPv2 specifications, which will be achieved when anticipated ubiquitous use of SNMPv3 gives cachet to improved MIB language, GetBulk operators, 64-bit counters and clarified Set operations. Next, it defines a manageable and secure authentication system and a granular access-control system. SNMP Security Despite its strength as a network management system, the original SNMP's Achilles' heel is security--this protocol has the potential to release a staggering amount of information to a determined hacker. Given physical access to a network and armed with a protocol analyzer, a hacker can rely on SNMP to deliver a virtual blueprint of the network's topology and configuration. Worse yet, intercepted community strings on Set operations can hand over control of any device configured for remote SNMP management. Current SNMP agents can use only IP address-based access lists, in addition to community strings, to enforce security restrictions. For its part, SNMPv3 not only encrypts all transmissions but also enables the responder (usually an SNMP agent) to authenticate the user generating the request, guarantee the integrity of the message using a digital signature, and apply complex and granular access-control rules to each request. It also lets the administrator specify these levels of protection in varied combinations (unsecured, authenticated and authenticated with encryption). In addition, any number of access-control rules can be applied at the SNMP agent or manager. While this level of security was completely impractical in hardware 10 years ago, today's infrastructure devices have enough RAM and CPU cycles to support not only this advanced SNMP security but also full-fledged Web management services--all in firmware. While SNMPv3 specifications call for modular authentication and access-control models, RFCs 2274 and 2275 suggest using the USM (User-based Security Model) and VACM (Views-based Access Control Model) as the reference security system. This allows vendors to support secure SNMP today while leaving the door open to new security enhancements (such as public-key authentication or directory integration) in the future, without compromising the current protocol specification. The USM Framework The USM put forth in the SNMPv3 specifications describes an entire authentication and privacy framework for network management. Instead of relying on a single text string to verify authenticity and select the appropriate access rights of a specific SNMP query, the USM adds the familiar user-name- and password-based authentication model--similar to that of most NOSes. However, unlike most NOS-based security services, USM doesn't specify a central security server. Rather, it requires that a user list (with appropriate encryption keys) be distributed to each and every SNMP agent and manager in a managed network. This means that network managers will be required to log into their management stations using their user names and passphrases. From then on, all subsequent authenticated SNMP packets carry that user's name and credentials (a key derived from the user's passphrase). This, in turn, enables individual SNMP agents to verify the identity of the user and authenticity of the data, as well as apply access-control rules to individual MIB objects based on the user name generating the SNMP request. Note that the USM specifies only authentication and encryption functions--access-control rules are handled by a separate module (defined as VACM in the SNMP reference standard). Under the USM, the identity of the person initiating all SNMP queries can be verified, and sensitive devices can keep audit logs tying individual users to configuration changes. Although this has been a common function in most NOSes, until now, SNMP devices had no way to create an effective audit trail. Once enrolled, the USM can encrypt transmissions using CBC/DES (Data Encryption Standard) encryption. This type of packet authentication guarantees the identity of the user who generated the SNMP request and generates a hash (HMAC-MD5) of the packet's contents and a unique time-stamp to prevent packet interception and replay (so-called "man-in-the-middle") attacks. SNMPv3 also defines a proprietary, secure time-synchronization protocol.
|
![]() |
Print This Page E-mail this URL |
Best of the Web
Data deduplication: Declawing the clones
Data deduplication is emerging as a critically important new arrow in the storage administrator's quiver to answer hard questions about the increasing problem in storage growth costs.
Compression, Encryption, Deduplication, and Replication: Strange Bedfellows
One of the great ironies of storage technology is the inverse relationship between efficiency and security: Adding performance or reducing storage requirements almost always results in reducing the confidentiality, integrity, or availability of a system.
WAN Optimization Whitelists and Blacklists
Optimization is a fantastic way of saving money and creating really happy customers at the same time, but it doesn't work flawlessly for all applications.
WAN Optimization as a Managed Service: It's Not About the Cost
This insight examines how organizations outsourcing their WAN optimization initiatives to a third-party go about achieving their goals for application performance, reducing operational costs, and streamlining enterprise infrastructure.









