Understanding the SNMP Protocol

The SNMP protocol

The SNMP protocol came into existence in the late 1980’s due to the requirement of having to manage ever growing networks, and the need to verify certain conditions being experienced on those networks. As I have mentioned before, most of the protocols seen in the TCP/IP suite follow the client/server model. This protocol is no different except for a minor syntax distinction; it follows the client/manager model.

There are several well known programs that use SNMP as part of their network management suite. IBM Tivoli for one and there is also HP Openview to name but a few of the offerings. What they all have in common though, as mentioned, is the use of the Simple Network Management Protocol. It is through the use of this protocol, and the way that it was designed, which allows the administrator to reliably ride herd over the sometimes far flung networks that they must administrate. 

SNMP and its variations

At present there are three different implementations of the SNMP protocol. There is namely; SNMPv1, SNMPv2c, and SNMPv3. All of the various versions built upon the success of the earlier one and tried to build more functionality into each successor. While you might think at first that the latest version of SNMP is in widest use, that would be a mistake actually. Largely the very first version of SNMP is still most commonly seen for various reasons such as simplicity, and the human tendency to go with what you already know works.

Due to there being three SNMP versions, there are key differences between the three versions of them. While SNMPv1 worked well there were some serious shortcomings with it. Notably there was little to no security with it. All messages were sent in plain text across the wire, and could be read by anyone with a packet sniffer installed on the network. This is not a good thing for obvious reasons. So along came SNMPv2, which attempted to correct some of the failings of its predecessor. SNMPv2 contained changes to MIB (management information base) definitions, also the PDU (protocol data unit) saw changes, and lastly improved security. The improved security came in the form of data integrity, via its use of MD5, and the DES algorithm for encryption. Lastly there was some form of protection to replay attacks due to the use of authentication procedures.

Variations of a variation!

Just in case SNMPv2 was not confusing enough, you should know that, in reality, there is actually four variants of it. They are as follows; SNMPv2c which is community based, SNMPv2* or also known as “star” for the meta character I assume, SNMPv2u that was user based, and the original SNMPv2. The complexity introduced with SNMPv2 is one of the main reasons that it was not widely adopted by the community at large. Complexity does not make for usability.

With continuing security issues in SNMPv1 and v2, plus the complexity issues of SNMPv2 it was decided a new version needed to address these shortcomings. This resulted in SNMPv3, which took into account its predecessors shortcomings. Far better security came in the form of authentication via hashing, timestamps, and message confidentiality due to the use of encryption. This version is also less complex then the SNMPv2 variants, and far superior in terms of security then version one. In spite of this, as mentioned above, many networks still use SNMPv1, with all of its shortcomings.

With all that said, just what types of messages is one likely to see when looking at SNMP traffic? Well that is a good question, and we will indeed list them. For the sake of simplicity we will list the PDU (protocol data unit) types as seen in SNMPv1. This is still the most commonly used one, so it makes sense to list those. They are as follows;

GetRequest, GetNextRequest, GetResponse, SetRequest, Trap

The following versions SNMPv2 and v3 have added some PDU types such as GetBulkRequest and InformRequest. Well with this very high level explanation of the various SNMP versions out of the way, it is time to put things into context by actually looking at an SNMP packet. We will now go on to look at a SNMPv1 packet, and go through some of its fields.

Let’s put things into context

What would dry theory be without the practical application? To that end we will take a look at a packet showing SNMPv1 usage. In that packet we will see just how SNMPv1 goes about carrying on its business ie: keeping the system administrator aware of the network, and any potential problems. On that note take a look at the packet below, and let’s discuss the various fields within it.

01:31:26.631025 > { SNMPv1
C=testnet-pub { GetResponse(90) R=1546751089
. .
267035 . .”G”} } (ttl 255, id41656, len 148)
0x0000 4500 0094 a2b8 0000 ff11 151c c0a8 01c8 E……………
0x0010 c0a8 0164 00a1 9d52 0080 3f43 3076 0201 ……..R..?C0v..
0x0020 0123 0123 0123 6574 2d70 7562 a266 0204 ..testnet-pub.f..
0x0030 5c31 8c71 0201 0002 0100 3058 3013 060a \1.q……0X0…
0x0040 2b06 0102 0102 0201 0a18 4105 00ea a972 +………A….r
0x0050 eb30 1306 0a2b 0601 0201 0202 0110 1841 ..0…+………A
0x0060 0500 bd70 819b 3011 0608 2b06 0102 0101 ….p..0…+…..
0x0070 0300 4305 00fe 6ef6 e830 1906 082b 0601 …C…n..0…+..
0x0080 0201 0105 0004 0d47                     …….G

I will comment on the packet above going from the first line, and also from right to left. Our normal timestamp is the first field, followed by our source IP address and source port. You will note that this source port is 161, which is the known port for SNMP. We then have the destination IP address and destination port. Now we see in brackets that the packet is telling us that this is SNMPv1. Following that is the “community string”, and now is a good time to know that the default value is normally set as “read only”. In our case the community string name is “testnet-pub” as underlined in the packet above.

Next we have our PDU type of “GetResponse”, which is also underlined in the packet above. Following this is our “request identification” number. Now we see a series of numbers spaced out with periods. Those are OID’s or object identifiers. These are used to define actual criteria such as system uptime, NIC throughput, and server load for example. For example, the management station could issue some “GetRequest’s” to a specific computer to find out what the server load is at that specific time. This is how the admin is able to use SNMP to help them manage their sometimes far flung networks.

With that said this is one protocol that you really cannot fully break out by hand, and you need a protocol analyzer like Ethereal, or ideally the program that comes with your network management software. That in turn will allow you to make sense of the OID’s that we see above. All that said we now see why SNMPv1 is really not a good choice to have as your SNMP protocol. Everything is in the clear! Even a minimally competent hacker could do damage with the information revealed in the packet above. If at all possible you should upgrade to SNMPv3. This brings us to the end of our very high level overview of SNMP, and I hope you enjoyed it. Till next time!

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top