An important part of network management is the handling of events and alerts. In this video, you’ll learn how to monitor interfaces, gather SNMP statistics, walk a MIB, and much more.
<< Previous Video: Process Monitoring Next: Performance Metrics >>
If you set up a monitoring system on your network, then one of the key components you’re going to monitor will be interfaces. You need to know whether an interface is up or whether the interface is down. This can often be one of the most important things you need to know about that particular device. If an interface has been available and suddenly changes to an unavailable state, then you’ll probably want to open some tickets, and have someone investigate.
Fortunately, the monitoring of an interface doesn’t require any special rights or any special permissions. You can simply ping the interface to see if it’s still running. Green, then, would obviously designate that the interface is up and running. And a red interface would be one that is no longer responding to our queries. These are commonly automated functions. They continue to run all day, every day, periodically checking to see if an interface is available.
If an interface is suddenly unavailable, you’ll probably want to create some alarms and alerts. You want to notify the proper people that particular device is no longer responding. You may open up a ticket in your help desk system. You might send an email notification. Or you might send a text message. Since you’re querying these interfaces so often, you can create short-term and long-term reports that show the uptime and availability of these devices.
This interface monitoring may provide only a basic up or down statistic. If you want to gather more details about what’s happening with that interface, then you may want to implement simple network management protocol and constant queries against very specific management information base details.
We mentioned in an earlier video about the importance of a SIEM. This is a security information and event management platform. This is usually a device that is consolidating log files from all of your different devices. And you are able to monitor and create reports on all of that logged information. Since the SIEM is gathering so many different details from so many different parts of the organization, it can also perform real-time monitoring of the information it receives. So if an alarm state suddenly occurs, you can send out security alerts or other messages so that people are getting real-time information about what’s happening on the network.
But of course, since this device is gathering so much information and storing all of that information over such an extended period of time, you can really create some very interesting short- and long-term reports. Usually, there are our advanced reporting functions within these SIEMs that may include built-in reports. And it may also allow you to build your own custom reports.
This wealth of data that you’ve collected may also allow you to create some correlation between all of these different very diverse data types. For example, you could look at detailed log information from a VPN where someone logs in. You can see switch information when they were assigned a VLAN. You can identify firewall details. And then you can track exactly what application was accessed on a server all by consolidating this data within the SIEM.
If a security event does occur, the SIEM will contain very valuable information. This will allow you to rewind over time and access all of the details from all of your different components to determine exactly what may have happened. These SIEMs are gathering data from many different kinds of devices made by many different manufacturers. There may be a VPN concentrator from one manufacturer, a switch and a router from another manufacturer, and a firewall from a third manufacturer.
But fortunately, there is a standard way to collect all of the log files from those devices. And that standard is called syslog. Syslog is a standard way to transfer log information from all of these different kinds of devices. It’s very common to have all of these devices report back to a centralized SIEM using the syslog protocols.
You’re going to be gathering a lot of information from a lot of different devices. So it’s very common that your SIEM would be equipped with a lot of storage space to be able to gather and maintain all of that log information over an extended period of time. Now that all of this log information has been consolidated in one place, you can now go back over time and look at all of the events that you might need to see.
For example, this is a consolidation of Windows event logs. You can see processes that have exited. You can see when someone has logged in. You can see when someone has logged off.
Using this consolidated log information on the SIEM gives you very detailed information about exactly what’s happening on your network. But sometimes you don’t need that level of detail. You’d rather have a broader view of what may be happening. You can use a SIEM dashboard to take all of the information that has been gathered through the logs and provide it in a broader much more graphical form.
For example, you can see the alerts on the network that may have been related to an unsuccessful Windows login or a virus. Or you may be able to see security events related to logins and logouts. All of this is available at a glance. And you’re able to tell very easily exactly what may be happening on the network at any particular time.
Another way to monitor the network and all of the devices is to proactively query those devices for more information. We would normally use SNMP to provide that query. This is the Simple Network Management Protocol. And it allows you to use a standardized information base to be able to query devices and return details about how that device may be performing. You would normally set up a management station to perform these queries. That management station would be configured with the name or IP address of the remote device that you wanted to monitor. And then you need to specify the version of SNMP that is supported by that remote device.
SNMP version 1 was the original version of SNMP. And it allowed the management station to send a single query to the device and get a single response from that device. That response was also sent over the network in the clear. There was no encryption associated with SNMP version 1.
SNMP version 2 added a number of additional enhancements. One of those was that the management station could request many different items at one time and receive a bulk response in return. But like SNMP version 1, there was no encryption associated with SNMP version 2.
We got the security we were waiting for in SNMP version 3. This allows for message integrity, authentication, and encryption of the requests and the responses. The SNMP agents that are running in your infrastructure devices are collecting a wide range of information. So you want to be sure the people that are querying these devices through SNMP are only the ones that need access to that information.
Once you’ve queried a device over time and gathered all of these different metrics, you can create a reports showing information on uptime, response time details, the amount of traffic transferred, or anything else that may be collected by that SNMP agent. There are many third-party tools that you can use to browse or walk the SNMP MIB. I’m using a generic MIB browser. You can download MIB browsers for almost any operating system.
And I’m using one that is accessing a set of demo data on the internet. And you can use this on your MIB browser, as well, at demo.SNMPlabs.com. If I click Fetch, this will begin sending SNMP queries and receiving SNMP responses and gathering details about all of the interfaces that may be on that particular device. We can see in this example, this device is at SNMP laboratories. It is in San Francisco, California. And we can get details about the uptime, availability, speeds, throughput, and other information that’s gathered by that SNMP agent.