Monitoring applications is a useful tool in the network administrators tool belt and I’d like to go over how Scrutinizer can help monitor your network in both the realm of bandwidth utilization and security alerting. This blog will cover why it is important to monitor applications and the different ways we can gather and report on that information using Scrutinizer.
Why monitor applications?
Is monitoring applications important? Breaking out your network traffic into a per-application report can help you understand which parts of your network do what. Wouldn’t you want to know if there is Dropbox traffic on your management network when there shouldn’t be? And now that remote working has risen, you might also be interested in how much bandwidth is going towards things like video conferencing applications such as Zoom, so you can make sure this traffic doesn’t go over your VPN tunnels and eat up office bandwidth.
Reporting on applications can also help to identify potential security issues. For example, a Paired Conversations App report can help identify large file transfers between internal subnets over SSH, FTP, or SMB. You can even set up a threshold alert to send you an e-mail when there is a transfer that is suspiciously large between certain subnets or IP groups.
Scrutinizer has out-of-the-box defined applications that you can report on. Using common port and protocol pairing, we have applied names to identify those applications associated. For instance, TCP traffic on port 22 is labeled as SSH traffic.
Defining your own applications
The above screenshot shows a couple of applications with a description of “(Defined application).” Plixer Scrutinizer allows you to define your own applications as well, which will show up in an Applications Defined report. To define these applications, all you need are three pieces of information: port, protocol, and IP address.
Our customers have used this feature to define SIP/VOIP traffic that occurs on higher ports, AWS applications, YouTube, and Dropbox. Configuring a defined application for an internal legacy app provides useful insight into identifying traffic to and from that app and who or what is using it.
Here are some locations for public IP addresses and port/protocol pairings from some popular video conferencing providers:
Some of these application definitions can become cumbersome to maintain with large lists of IP blocks. Entering them by hand would be inefficient in a lot of these cases. To fix this, we have a built-in utility for importing lists of applications to define!
To use this tool, you will need CLI access to your server. Run “scrut_util” to get into the Scrutinizer CLI tool. To view the instructions, just run “import applications.”
There are exporters that can identify and export application information, which Plixer Scrutinizer can then receive and report on. Certain Cisco devices come with a feature called Network-Based Application Recognition (NBAR), which provides intelligent application identification that can then be exported via NetFlow to Scrutinizer. Cisco provides an NBAR application list to see if your applications would be identified by this feature. Cisco also has a feature called Application Visibility and Control, which can be exported via NetFlow. Scrutinizer has reports built in that can use these application exports in reports.
If you use Palo Alto Networks, they have an application identification feature for NetFlow as well. Aptly named App-ID, this feature uses application signatures, port and protocol, and heuristics to identify which application matches the traffic and can be configured to export as NetFlow.
There are other platforms out there that are application-aware including SonicWall, Citrix AppFlow, Gigamon AppIntel, etc. Feel free to contact Plixer support to help in configuring your environment. If you are interested in monitoring applications within your network, you can request a demo for Scrutinizer.