SNMP is made up for several different messages type and we'll be exploring SNMP Traps to learn more about it!
Intro and History of the Protocol
Monitoring Software is a tool that can make life much easier for IT professionals that want to keep an eye on an organization’s software, hardware and appliances.
In order to make an effective monitoring application you have to use a protocol that will fetch important information and metrics from your network and the connected devices that make use of it.
Perhaps on of the most commonly used protocol is SNMP.
SNMP stands for Simple Network Management Protocol and is a very effective method for probing the network and elements within it to further monitor them via SNMP Protocol.
This means that there is a way to query basic stats from devices such as serial numbers, Operating System versions, or even toner and ink levels in network printers.
Most new devices that come onto the market have some level of SNMP support, which means that they can be queried and have data pulled from them.
SNMP works through a special service on the target machine called an SNMP agent. The agent software runs off of anything, from desktop computers to network appliances. The current security standard that is recommended is SNMPv3.0.
When SNMP was originally designed security was not a major concern so that needed to be addressed.
When we think of SNMP there are basically 5 message types that make communications possible:
Each of these message types serve a specific purpose in the communications chain, and the SNMP agent uses these to relay messages back to the SNMP manager.
SNMP Versions, What is the Difference?
Although we know that SNMP stands for Simple Network Management Protocol, there was a tongue in cheek joke from many years ago that said that SNMP stood for Security Not My Problem because of the open and non-secure way that t he first iterations of the protocol operated.
Hackers and cybercriminals were quick to try and capitalize on the weaknesses in the system, although it was not widely adopted in the early days.
SNMP Version 1 was released way back in 1988 and was only in existence for around 5 years before it was usurped by version 2. It still wasn’t widely used on the hardware level by most manufacturers, which meant that the widespread adoption of the SNMP standard would still be many years away.
SNMP 2 was backwards compatible with but there were some limitations. One of these limitations was the fact that version 2 controllers could communicate with SNMP version 1, but there were issues with implementing trap error between the two version as the trap message standard was revamped in version 2.
SNMP version 2 was more complicated than what was seen on the surface though, and it had a pretty complicated implementation that developers preferred to avoid. This lead to different versions of the protocol being released over the years such as SNMPv2c, SNMPv2u, both of which we actually refer to SNMP version 2.
The latest version of SNMP is version 3, which uses a much more advanced encryption method making it more secure. It is backwards compatible with version 2, and makes it easier for developers to implement. Security improvements mean that the MIB is encrypted with a much more secure security measure, but the message structure is still the same.
Essentially version 3 is more secure while remaining easy for developers to integrate the protocol into their software stack.
Good network monitors with SNMP compatibility are able to communicate with version v2c and version 3, so it is always a good idea to make sure that your software is able to handle the differences between SNMP version 1, 2 and 3.
SNMP Traps in More Detail
SNMP traps can be thought of as the most used message type in the protocol suite because of the way the manager receives them. SNMP traps are only sent out when the target needs to report a problem, so they are sent to the manager and are reported that way.
This makes them special in a few different ways, mainly because they are able to communicate directly with the management agent. Because of this reason it is much easier for SNMP to be used to communicate across the network. This means that fault finding is automated for you and anything that fails will notify you quickly and accurately. If services, applications, databases, hardware or software should happen to fail then it is just a matter of opening your SNMP agent.
Within the SNMP traps there are a further 2 different types of communication processes that allow for data to be transmitted across the network. The one you have probably already heard of before is a granular trap, which are able to identify individual events as the name suggests.
This lets the SNMP manager sort out individual alerts and alarms which gives you a much more detailed view of your network and operating environment.
Each of these is called an Object Identifier and is stored in the Management Information Base. The OID is referenced by the SNMP manager which searches the MIB for details. This allows the software to identify and action each of these elements of SNMP traps.
This serves a purpose other than being easy to reference single alerts. It also allows the SNMP manager to not have to store the detailed information of each alert within the OID. Instead the details are housed within the structure of the MIB, giving the SNMP manager much more room to breathe as it does not need to be bogged down with details about each element or device.
The other method that SNMP uses in Trap messages is by including the information that relates to each alert in each trap message. This means that all similar alerts can have the same OID and it makes things much more efficient to manage for the SNMP manager. Data is encoded in pairs within the SNMP trap and have extra data stored in them. There are simple levels of information that can be stored in this variable which helps the SNMP protocol quickly process the error and then alert accordingly.
So as we can see there is more than meets the eye when we look at the underlying mechanisms of SNMP that make it such an effective monitoring and alerting protocol.
Common Examples of SNMP Traps are:
This type of trap identifies the type of managed device or object that created the trap. This field also contains the value if the value that is called sysObjectID which is sent from the device to the SNMP agent itself.
- Agent Address:
In order to work properly the SNMP must know what address to use for the managed object or device
- Generic Trap Type:
This shows the number of generic trap types and is normally set to enterpriseSpecific. Some providers have been guilty of creating their own non-specific implementations of trap types, so check with your vendor to see if you also have non standard trap types that you weren’t aware of.
- Specific Trap Code:
Shows the agent what code is represented by the specific identifier code that is generated within the trap
- Time Stamp:
Generates the amount of time that has passed since the network was last reinitialized and the trap was generated.
- Variable Bindings:
The data field of the trap that has the PDU stored in it is referred to as the Variable Binding.
There are plenty more definitions that are used throughout SNMP. There are standard and generic traps that are often used such as coldStart, warmStart, linkDown and linkup, to name a few. Others include authenticationFailure and egpNeighbourLoss.
We’ve learned that SNMP operates within the networking environment of your organization as a vital tool to help you to stay on top of alerts as they come up. Although SNMP is usually thought of as a passive protocol it can definitely help you and your IT staff to become more proactive and aware of the operations than ever before. We have also learned that when an emergency strikes, SNMP is able to elevate the alert and send it to you urgently- which is where the SNMP trap comes in.
We’ve also learned that although we associate traps with emergency alerts from SNMP, there are times when something as benign as a printer running out of ink or toner will appear in your SNMP console. The software that you choose to employ will add a layer of filtering and granular fine tuning, so you will learn how to cut through the noise and focus in on the most important alerts. Likewise, there are times when a serious alert will not generate a trap error, and might not even trigger an SNMP result. It is for this reason that failure conditions on your network need to be constructed properly so that if a certain amount of services fail then you will receive alerts despite there being no SNMP messages coming through.
Diversifying your monitoring and alerting solution is the best approach, as well as SIEM and logging solutions. We hope that this information helps you to understand what you need to implement an effective monitoring solution for your business, and that you can build a monitoring and alerting platform that takes your organization to the next level.