Peer to peer applications are a significant challenge for policy enforcement solutions. Any flows that slip through as an undetermined application type may allow the file sharing app to function. The first key to addressing this challenge is simple visibility into which hosts or users may be abusing the AUP with these types of applications. This article shows a quick and easy way to create Peer to Peer dashboard in the Firepower Management Console.
For those that have already attempted this, there are a number of challenges that may have surfaced. First there are no readily available widgets or criteria that will show the desired information. Experimenting with search constraints and the connection table quickly reveals that the desired information can be easily accessed by using the “peer to peer” Application Protocol Category search criteria. Unfortunately, the Connection Table is not readily available to the Dashboard Widgets. The Connection Summary table is available, but it does not have the Application Protocol Category (required for the search constraints).
My goal was to build a few dashboard widgets to give visibility into Peer to Peer activity. For this article I will demonstrate the steps required to build those widgets. The first widget will provide a list of Peer to Peer applications on the network, the second will provide a list of initiating IP addresses of peer to peer connections, and the third widget will sort actions taken on peer to peer traffic. All of these will be sorted based on the connection count.
To overcome the challenge of not having access to the Connection Table from the Dashboard Widgets, it is necessary to create a custom table. To do so, choose Analysis, Custom > Tables, Custom Tables.
The next step is to create a new Custom Table by choosing Create Custom Table. This allows for logical table joins between tables that contain combinable data. For this example, there is really only a need for a handful of fields from Connection Events. However, it is necessary to add at least one field from another table to allow the custom table creation. I have added the following fields from Connection Events: Application Protocol, Application Protocol Category, Initiator IP, and Action. I have also added IP Address from the Hosts table so it contains fields from multiple tables. This isn’t really necessary, but the UI doesn’t allow it to be saved otherwise.
After choosing a name and saving the Custom Table, it can be selected to view a summarized list of the fields that we plan to show in the dashboard. At this point the output is not constrained to Peer to Peer traffic. I have named this table Peer to Peer and went into the Workflow view by choosing the magnifying glass.
From this view, a Search Constraint can be added by selecting Edit Search. In my case I simply went down to the Application Protocol Category and entered peer to peer. After saving and choosing search, the output can be verified to only contain connections for peer to peer traffic.
The next step for this challenge is to work on the dashboard. For this example, I am going to create a new tab on the Application Statistics Dashboard. This is accomplished by choosing ‘+’ to add a new Tab.
Once a new tab is created, the widgets can be added by choosing Add Widgets. The type of widget that needs to be added is called Custom Analysis. I need three widgets for my example, so I will proceed with clicking Add three times and then click Done.
At this point, there should be three blank widgets ready for customization. To select the data and the display format, click the down arrow in the top left corner. This will present sever data source options.
In the table field, it is necessary to select the custom table that was created earlier. In the field drop down box, I am selecting Application Protocol. At this point, it will show all application protocols. From the Search dialog box, it is necessary to select the Search Constraint that was saved earlier. This will restrict the applications to those that are in the Peer to Peer Application Protocol Category. At this point the first Widget is created.
To configure the other two widgets, the same procedure is used. The only variation is that Field drop down will be set to Initiator IP and Action Respectively.
As can be seen from the output, the desired dashboard is now created and usable by the SecOps team. This should serve as a starting point to the dashboard capabilities of the solution. A good way to expand upon this might be to combine User information and other attributes into the table and dashboard to make the information more consumable by the front line of the SecOps team.
Disclaimer: This article includes the independent thoughts, opinions, commentary or technical detail of Paul Stewart. This
may or may does not reflect the position of past, present or future employers.