We recently received a request from a customer looking for a way to identify GoogleTalk (gtalk) traffic. To address this request, we first needed to learn about this protocol. It seems that GoogleTalk uses an existing protocol called “Jabber”, which is based on XMPP. To simplify things, Jabber uses a standard port of 5222.
So, in Scrutinizer, you could define a custom Well Known Port called “GoogleTalk” with a TCP port of 5222.
This seems like a reasonable and simple solution, however, it is open to reporting false positives, data that is not GoogleTalk. Just defining GoogleTalk as port 5222 leaves it open to include any application that uses the Jabber protocol.
So, let’s look at building a custom protocol definition using NBAR (Network Based Application Recognition) on our Cisco router.
First thing we need to do is take a packet capture of GoogleTalk in action. We downloaded and installed the client and started Wireshark. Soon we could see the Jabber client using the XMPP port. We also noticed that the first few bytes of the payload was the same. This can help us in our NBAR definition.
Now, with this information, we can login to our router and create the new protocol definition. In global configuration mode enter the following line:
ip nbar custom GoogleTalk 0 hex tcp 5222
It will take a few seconds for your prompt to return, this is because the router is rejiggering itself to identify the protocol.
Let’s look closer at the this custom protocol command:
| ip nbar custom | – this means you are going to create a custom NBAR definition. |
| GoogleTalk | – The name we want to call the application. |
| 0 | – This is the byte offset we need to use in our matching. With NBAR, the byte offset starts after the TCP/UDP header (the start of the payload). We use ‘0’ here because we are starting from the beginning of the payload. |
| hex | – This is the format of the data we are entering. Other options are ASCII, Decimal, and Variable. This page on Custom NBAR protocol command syntax provides more information on these options. |
| 17030100 | – This is the hex value we saw in Wireshark at the beginning of the payload. |
| tcp | – This means we are looking at the TCP protocol. |
| 5222 | – This is the port that we are looking to match. |
Okay, now that we have the new protocol configured, we need to verify that it is listed. This can be done by issuing the “show ip nbar protocol-id” command.
Great! It’s there!
Next, using Scrutinizer’s Application NBAR report, we can now look for this new NBAR protocol. Keep in mind that it could take up to 10 minutes for your NBAR application templates to update, so be patient!
After 10 minutes, we are now seeing our new protocol!
This same process could be applied to almost any application you wish to monitor. Combine that with our best in class NetFlow Analyzer, and your network monitoring capabilities are nearly limitless!
