Triggered NetFlow — A Trick of the Trade

Triggered NetFlow: A Woland-Santuka Pro-Tip

Vivek Santuka, CCIE #17621, is a consulting systems engineer at Cisco Systems who focuses on ISE for Cisco’s largest customers around the world. He and I devised, tested and deployed the methodology discussed in this blog entry, which we like to call “Triggered NetFlow.”

NetFlow is an incredibly useful and under-valued security tool. Essentially, it is similar to a phone bill. A phone bill does not include recordings of all the conversations you have had in their entirety; it is a summary record of all calls sent and received.

Cisco routers and switches support NetFlow, sending a “record” of each packet that has been routed, including the ports and other very usable information.

+ Also on Network World: Using NetFlow to protect your net +

Just enabling NetFlow in your infrastructure and forwarding it all to the ISE PSNs can quickly over-subscribe your Policy Services Node. If you plan to use the NetFlow probe, it is highly recommended that you have a robust solution, such as Cisco Stealthwatch (from Cisco’s acquisition of Lancope), to perform de-duplication, filter out any unnecessary data and send only what you truly need to ISE. 

The challenge with using NetFlow is that it requires de-duplication capabilities, scalable flow collection, etc. But it is so incredibly useful in Secure Access deployments for identifying general use compute platforms that are used in environment-specific ways, such as medical devices based on the Windows operating system. It’s also very useful in identifying Internet of Things (IoT) devices that are otherwise unknown.

To identify these devices that are unique to an organization’s environment, you need to examine the endpoints’ traffic patterns. For example, it’s possible that a hospital’s IV pump may only be uniquely identified by seeing the destination systems that it communicates to within the hospital datacenter. 

In those cases, NetFlow is the perfect identification tool because it will match on the traffic flow instead of endpoint attributes. While NetFlow is perfect for these systems, it does not mean it’s operationally feasible to enable NetFlow in the entire organization and risk overwhelming ISE with all those flows.

So, what is this Triggered NetFlow thing?

Triggered NetFlow is a deployment methodology designed to flip NetFlow on when and where it is needed—only—and turn it back off immediately afterwards. It is not a new technology, but a combination of existing technologies within ISE and the Cisco switching infrastructure. The overall concept follows the flow illustrated in Figure 1.

Aaron T. Woland

With any successful authentication where the endpoint profile is unknown, the authorization result will include a security group tag (let’s just call the SGT “ClassifyMe”). When that SGT is received by the switch, an embedded event manager (EEM) script is executed, which enables NetFlow on that switch port. 

The use of this solution requires that you have an understanding of how ISE authentications and authorizations work, how to use Cisco IOS’s Embedded Event Manager (EEM), and NetFlow configuration within Cisco IOS. Knowledge of how TrustSec (aka security group tags) function is not required, but it can’t hurt.

Please note: There are many different ways to accomplish this same task. The method outlined and tested by me and Vivek is just one such example. If you have experience using the switch features and want to deviate from this specific prescribed solution, go right ahead! Please do, and perhaps post here in the comments or on the public ISE forums so others may benefit from your tweaks. With that in mind, Example 1 shows the EEM script that we used when we designed the solution, while Example 2 shows the example NetFlow configuration that we used.

Example 1 – Sample EEM Script for Triggered NetFlow

event manager applet CaptureData event syslog pattern "Authorization succeeded for client" action 1.0 regexp "Interface (.*) AuditSessionID" "$_syslog_msg" match intname action 1.1 cli command "enable" action 1.2 cli command "show auth sess int $intname | i SGT" action 1.3 set sgttag "0000-0" action 1.4 regexp "000C-0" "$sgttag" action 1.5 regexp "SGT: (.*)" "$_cli_result" match sgttag action 1.6 regexp "000C-0" "$sgttag" action 1.7 if $_regexp_result eq "1" action 1.8 cli command "conf t" action 1.9 cli command "int $intname" action 2.0 cli command "ip flow ingress" action 2.1 else action 2.2 cli command "conf t" action 2.3 cli command "int $intname" action 2.4 cli command "no ip flow ingress" action 2.5 end

Example 2 – Sample NetFlow Configuration

flow record ise-flows description export only flows needed by ise match datalink mac source-address match ipv4 protocol match ipv4 source address match ipv4 destination address match transport source-port match transport destination-port match transport tcp flags ! flow exporter ISE description Export to ISE PSN1 destination 10.1.100.234 source TenGigabitEthernet1/1/1 transport udp 9996 ! flow exporter ISE-flows ! flow monitor ISE-Flows description Used for ISE Profiler record ise-flows exporter ISE cache timeout active 60 ! flow monitor CaptureData record ise-flows ! flow monitor test

Figure 2 shows the security group tag (SGT) that was created to trigger the NetFlow application on the port. Notice it is shown, in this case, to be named CollectData and to have a decimal value of 12.  

Aaron T. Woland

Figure 3 shows the authorization rule for the unknown endpoints, which permits a limited network access and includes the CollectData SGT.

Aaron T. Woland

I hope you found this Pro-Tip useful—even if it was just to help you consider how to leverage existing technologies to enable a better ISE deployment for your specific needs in your organization.