November 2017 Update
Guided Mode Dashboards
While Data Explorer is oriented toward ad-hoc investigation, Dashboards rely on pre-configured views to provide at-a-glance presentation of status. Guided Mode adds speed and flexibility by enabling users to quickly change — without setting complex query options — the value of the dimension that one or more panels on a given dashboard is intended to track. Guided mode dashboards allow power users to build dashboards that other users can use without having to become experts on the powerful filtering capabilities of Kentik Detect.
Once a guided mode dashboard is set up, users of that dashboard are prompted to fill in (or select from a drop-down menu) the value of the guided mode dimension. For example, if your dashboard presents different views of traffic from a given country, you could set the guided mode dimension to source country and configure a set of panels that all change when the end-user chooses a different country.
Another example is the preset dashboard called SecOps – IP Investigation, which Kentik has changed to guided mode. Instead of being locked to a specific IP range that was chosen when the dashboard was created, the dashboard’s panels now follow the IP range that users are asked to specify when they go to the dashboard, and which they can change at any time.
For more information on Guided Mode Dashboards, check our Dashboards article in the Knowledge Base.
Single Sign-On (SSO)
How do you make it more convenient to maintain user security without having to constantly enter authentication credentials? Kentik’s answer is to enable single sign-on (SSO) for the Kentik Detect portal. Our new SSO implementation is compliant with standard SAML2 transport and includes encrypted SAML assertions, automated user provisioning, and IdP-enforced role-based user-privileges. It has been successfully tested with the following identity providers:
Data Explorer Enhancements
As one of the most-used sections of the Kentik Detect portal, Data Explorer is constantly assessed and refined, so there have been quite a few enhancements, more than we can report on in full. Among the highlights that we’ll cover below are new dimensions for threat feed and CDN attribution, a new visualization type (Time Series 100% Stacked Graph), and IPv6 support for Ultimate Exit.
CDN Attribution & Threat Feed
We’ve added a few new dimensions that can be used as either source or destination dimensions for queries, filters, alerts and more. The first is CDN, which maps CDN names to IP addresses. This dimension is only available to customers who are contributing IP and DNS name mappings by running our custom kprobe agent on their DNS servers. To learn more, and see how to enable it for your account, check out our CDN Attribution article in the Kentik Knowledge Base.
Two other new dimensions help you determine if you are dealing with traffic from a suspect IP address. The diagram below shows how this system works. Our friends at SpamHaus maintain information on IP reputation, which we obtain and keep in a database that we update daily. As each flow record is ingested into the Kentik Data Engine (KDE), we compare their source and destination IP addresses with the IPs in the threat database. If anything matches, we mark it in the flow record using new KDE columns.
Once the BotNet CC and Threat List Host dimensions are in the KDE they can be used for group-by and filtering. As shown below, that enables users to query for hosts in their network that are communicating with known BotNet Command and Control (CC) servers or other known compromised hosts.
Keep an eye on the Kentik blog in the coming weeks for a post with more information on how these new dimensions work and what you can do with them.
Time Series 100% Stacked Graph
Kentik Detect already gives you lots of options for visualizing your data, and we’ve now added yet another. The Time Series 100% Stacked Graph shows each matching key (unique combination of dimension values) on the graph as a percentage of the total traffic returned from the query.
IPv6 for Ultimate Exit
Kentik Detect’s Ultimate Exit capability enhances every flow record ingested into KDE with fields representing the Device (router), Site (Pop,) and Interface where the underlying flow will exit to an adjacent network. Until now, Ultimate Exit used to work only for IPv4 traffic (IPv6 traffic was ignored), but now both IPv4 and IPv6 traffic are included in these queries. For more details on how to use this feature, check out our Ultimate Exit blog post.
DDoS and Alerting improvements
Integrated anomaly detection, alerting, and mitigation is a key feature set for Kentik Detect, and we continue to devote a lot of effort toward improved workflow and usability. Our recent changes to the Alerting section make an already powerful functionality easier for customers to set up and use.
Alert Policy Creation
Alert policies are at the heart of our alerting system, defining conditions that will result in a notification and possibly trigger a mitigation. The power and flexibility of our system brings with it some inherent complexity, but we’ve nonetheless been able to greatly improve the policy creation workflow. The process is now structured as a set of tabs that are each labeled with a caution symbol until all required information is provided, at which point the label switches to a check mark. The UI also now provides a better explanation of how the value of each field impacts the behavior of the overall alert.
Role-based Alerting Control
Kentik Detect supports three levels of users (Member, Admin, and Super-Admin), each with different permissions. We’ve now implemented this multi-level approach in our Alerting system to differentiate the tasks that can be performed by different-level users:
- Member users are restricted to clearing alarms and stopping mitigations. Members cannot create or modify alert policies, but to facilitate troubleshooting they are able to view policies.
- Admin and Super-Admin users have complete control over all aspects of alerting setup and operation.
Previously a mitigation could only be triggered based on an active alert. We’ve added the ability to trigger a mitigation manually, even without an active alert. It’s important to note that a mitigation that’s been triggered manually won’t end on its own; it must also be ended manually.
To trigger a manual mitigation, click Alerting on the main portal navbar, then choose Manual Mitigation from the sidebar at left. In the resulting Add Manual Mitigation dialog, fill in the following fields:
- The Mitigation Platform and Method (must be predefined in the Platforms and Methods pages of the portal’s alerting section)
- The IP/CIDR to mitigate
- Comment (optional)
The mitigation starts immediately once you click the Add Manual Mitigation button. Because manual mitigation is intended to be applied as a one-off, the settings in the dialog are not saved for later reuse. Instead the mitigation exists only until it is manually ended from the Active page of the alerting section.
Enhanced RTBH Mitigation
Another alerting enhancement relates to our built-in Remote Trigger Black Hole mitigation. We’ve added the ability for customers to set the Local Preference (the BGP LOCAL_PREF attribute) on routes that are advertised for RTBH, so that you can ensure that the blackhole route is the preferred route for forwarding traffic.
Local Preference is configured in the Add Mitigation Method or Edit Mitigation Method dialog, which you reach from the Methods page of the Alerting section. Click the Add button to add a new method, or click on an existing method to edit it, then scroll down to the Local Preference field towards the bottom of the dialog.