In our previous post, on CDN Attribution, we mentioned that our development team has been hard at work enabling new ways to visualize and investigate network traffic patterns in Kentik Detect®. One of these new features is the ability to find traffic from infected or compromised hosts. What makes this possible is the fact that we now enrich flow records (NetFlow, sFlow, IPFIX, etc.) in Kentik Detect with IP reputation data from our friends at Spamhaus. Based on this information, we’ve exposed two new dimensions that you can use for group-by or filtering: Bot Net CC and Threat List Host. In this post, we’ll walk through a use case for the Bot Net CC dimension, but first let’s look deeper into the threat feed information from Spamhaus and the corresponding dimensions in Kentik Detect:
To illustrate the use of Bot Net CC, let’s go back to the fictional enterprise from our last post, Pear, Inc. The savvy reader is probably already aware that a popular method of Distributed Denial of Service (DDoS) attacks is to infect hosts with a virus. These hosts then communicate with a Command and Control (C&C) server that tells them where to send attack traffic. Pear’s IT Security department wants to see if they have any hosts on their network that have been compromised and are communicating with a C&C server, thereby participating in a botnet.
We can check this by building a query in the sidebar panes of the Data Explorer (Data Explorer » Explorer View). Using the Group By Dimensions selector in the Query pane, we set the query to look at two dimensions that, when combined (shown at right), will give the list of compromised hosts on our network: Source IP/CIDR and Destination Bot Net CC. Also in the sidebar (for details on sidebar settings, refer to the Sidebar Panes article in our Knowledge Base), we set the Time pane to look back at the last hour, and in the Devices pane we choose All so that we can look at our entire network. We’ll also build a filter in the Filtering pane (shown at right) that will ignore our normal network traffic and look only at botnet traffic:
After our query configuration is complete, we click on the Run Query button at the top of the sidebar. If there were four infected hosts then the query would return a graph that looks similar to the below. Based on these results, the IT Security staff at Pear would know which hosts to examine for botnet malware, so it can be identified and removed.
Pear could take this a step further by running this query as a scheduled report that is emailed to Kentik Detect users within the Pear organization that are assigned to the report as subscribers. Reports are based on dashboards. The following steps show how to save the query to a new dashboard and then set up a weekly report:
If the Pear IT Security department were to follow the steps above, they would receive an email every Monday with a list of infected hosts covering the previous seven days.
Getting a scheduled report is nice, but it would be even more helpful to be notified automatically whenever an infected host is found. By creating an alert policy in Kentik Detect’s alerting system, Pear’s IT department could get a Slack notification in their #itsec channel any time a new host starts talking to a C&C server. To do this, we would choose Alerting from the main portal navbar, then click Policies in the sidebar. On the resulting Policies page we click the Add Policy button. In the resulting Add Alert Policy dialog, we make settings on the following tabs:
Dataset tab: In the Data Funneling pane we click anywhere in the Dimensions selector to add the same dimensions we used in our original query: Source IP/CIDR and Destination Bot Net CC. We’ll also click in the Secondary Metrics selector and choose Bits/second. Moving down to the Building Your Dataset pane, we change the Maximum Number of Keys Analyzed Per Evaluation to 100. We leave everything else at default so the system auto-calculates the Minimum Traffic Threshold.
Alert Thresholds tab: We choose a criticality level (e.g. Major) from the list at left, then set the switch at right to Enabled, which reveals a number of panes containing controls. In the Threshold Configuration pane, we choose Check If Certain Conditions Exist from the drop-down This Threshold Will menu. Leave the other settings at their defaults. Moving down to the Conditions pane, we set a threshold of Greater Than 1 kpps. This will trigger the alarm if any of the hosts on Pear’s network are sending more than 1000 packets per second of traffic to a known Botnet C&C server. The final pane that needs our attention is Notifications. Click anywhere in the Send Alert Status Updates To selector and choose Slack itsec. Note that this notification channel must already have been configured under Alerting » Channels. For more information, check out our KB article on creating a notification channel.
Historical Baseline tab: Leave default settings.
Once all of the required fields have been specified there will be a green check mark on all of the tabs. When we click on the Add Alert Policy button, the policy will begin in Silent Mode, studying the normal patterns of traffic. After the Silent Mode end date, the IT Security department will get a Slack notification every time a new host starts talking to a botnet C&C server. (For more information on setting up policies, you can refer to our Knowledge Base article or our blog post on Configuring Alert Policies.)
This is just a taste of the ways that Kentik Detect’s new Threat Feeds information can enable your company to see compromised hosts on their network that they’ve never been able to see before. This insight can be used for both proactive monitoring and data forensics to protect the company’s infrastructure. If you are an existing customer and would like help setting up or using this feature, get in touch with our Kentik support team. If you are not already a Kentik customer, it’s easy to get started: request a demo or sign up for a free trial.