Now we're going to move onto the demo.
In this demo, we're simply going to examine SNMP packets in Wireshark.
We'll also discuss some of the security implications that
we've discussed earlier in this module,
but we'll be able to see it on the wire in Wireshark just as we promised.
So here is an example of an SNMP v1 packet capture.
Obviously,
Wireshark knows that it's SNMP traffic based upon the destination
port and it is UDP packet as we discussed before.
The destination port is 161, which is the standard SNMP port.
If we open up the SNMP portion of the packet here,
you see right there is the community string.
It's out in plain text for anyone to see and this
particular packet has a PDC of a get-request,
specifically, if we drill down far enough into it,
you'll see that it's asking for the value of that OID.
Now we haven't gotten into OIDs yet,
but this particular OID is a request for the system name.
You'll see that the system then replies back with
the same SNMP community string, however,
this is the response, and if we expand it out,
we see that there is the value, which if we Google that up,
tells us that it's some type of OKI data printer.
I could not track down the exact type of OKI data printer,
but you can tell it's an OKI data based upon the first part of the OID
which we'll go over when we discuss OIDs more in depth.
You see, if we scroll through this particular capture,
it's just a bunch of get-requests and get-response.
SNMP v1 is a very simple protocol and there are some Windows
networking packets down here towards the bottom.
We're not really interested in those,
but we just want to look at SNMP v1 just to see
that it's a very simple protocol.
Get-request, get-response, you ask for one piece of information,
it gives you one piece of information back.
Now we'll move onto SNMP v2.
There's not nearly as many packets in this particular capture,
but we can still glean a little bit of information from it.
In this case, we actually see an SNMP v2 specific request as the first packet,
which is get-next-request,
which tells the SNMP agent to go one level deeper in the OID tree and
return all of the information from the next layer down.
This is how SNMP walk applications actually work.
They just make these SNMP get-next-requests and just walk right down the
tree and enumerate all of the information for that OID.
We'll see this when we get into the implementation lab elsewhere in the course.
You will notice, however, that if we expand out the SNMP packet,
we still have the community string in plain text out here on the wire,
and again, this looks like a read-only because it starts with R0,
which is very close to RO, but still,
even having a read-only community string can prove useful to someone
who may be doing surveillance on your network.
As we expect,
the SNMP agent responds back with the same community string and with
the next variable binding in the tree for that OID.
And you'll notice that, in this case, the value is Integer32.
When we get some of the other responses like down here towards the bottom,
you'll see that it is a Counter64.
This particular SNMP request is for interface statistics on the Cisco router.
So you can see how the number of packets or frames going across an
interface could very easily roll over on a 32-bit counter and most
network management systems can handle this,
but every so often,
you'll run across a very strange-looking graph where it looks like your traffic
kind of has a sawtooth pattern where it's up and then down,
and then up and then down simply because the counter is rolling over and
that is how the SNMP agent renders that information.
And last, but not least, we have SNMP v3.
SNMP v3 obviously looks quite different because it
is a more advanced SNMP protocol,
but you still can see the underpinnings of the
previous protocols even at this level.
You see at the very first packet we're asking for
the report on this particular OID,
and here is the encrypted PDU that contains the user ID and
password information for this particular user.
There is the message username and you'll notice that
the encrypted PDU is just that, it's encrypted.
The password for this particular user is encrypted,
and of course, it goes back and forth.
It's hard to tell who's actually talking because this particular capture
was taken on a machine that was talking to itself,
but you can get the gist of what's going on here.
If you go further down the capture,
you'll see that even though the username and password information is encrypted,
we still have plain text information about the
response data from the remote system.
We have to drill down five or six times here,
but in this case,
we're getting back five variable bindings because of the
particular information that we're looking for,
and if you look right here,
you'll actually see the user ID sent back to the requesting
network management station in plain text,
and again,
even though you can still glean some information
from your devices on your network, from the responses that comes back from them,
you don't have the information to actually go request that information yourself,
or more importantly, to write to that device,
or reboot it, or any number of malicious things.
You see that we have several requests here with encrypted PDUs at the beginning of each of the requests so as to keep the network secure.