Cisco Tetration - Hands-On Lab

Module18: Policy Analysis - Common Policies

In this module we will perform Policy Analysis for the Common Policy workspace which contains the Active Directory and Ansible server workloads. We will identify any errors in our ruleset that might have caused disruption had we put the workspace into enforcement, and make corrections as necessary.

Click here to view a video of the tasks necessary to perform policy analysis for the Common apps.

Steps for this Module

Step 001 - Navigate to the Common Policy app workspace
Step 002 - Click on Policy Analysis
Step 003 - Filter out Permitted flows
Step 004 - Click on Escaped flows in the graph
Step 005 - Perform Quick Policy Analysis
Step 006 - Observe Quick Policy Analysis results
Step 007 - Navigate to the OpenCart application workspace
Step 008 - Find the rule that is causing the Escaped flows
Step 009 - Change the Consumer from a Filter to Scope
Step 010 - Click on Policy Analysis and Analyze Latest Policies
Step 011 - Enter a reason
Step 012 - Return to the Common Policy app workspace
Step 013 - Click on the Escaped flows in the graph
Step 014 - Run Quick Policy Analysis
Step 015 - Observe the new policy result

Navigate to the Common Policy application workspace.

Click on Policy Analysis.

Filter out Permitted flows and then click on one of the points in the graph where there is an orange peak, indicating Escaped flows. An escaped flow will be present that is the Apache web server sending DNS traffic to the Active Directory server. Recall that Escaped means that this traffic would be dropped if we were to implement this policy.

If you don’t see any escaped flows being indicated on the diagram, adjust the time range to the last 1 hour to see the most recent data.

Under Flow Observations, click on the Escaped flow from the Apache Linux to the Active Directory server on UDP port 53.

The Flow Details screen shows a wealth of information about the flow including source/destination addresses and hostnames, number of packets/bytes, and the process on the machine that is sending/receiving traffic.

We can also see here that the flow is being denied by the Consumer Outbound Policy, which is the OpenCart application. We can gain more insight by doing Quick Policy Analysis. Click the Quick Policy Analysis button.

The Consumer and Provider IP addresses as well as Protocol and Provider port will be pre-populated automatically. Click on Find Matching Policies. Here we can see a specific rule under Provider Inbound Policies that is configured in our Common Policy workspace that allows UDP 53 from Any-Internal to Common-GC-DC-DNS. However, there is no matching policy in the OpenCart workspace to allow the traffic. In this case, the traffic is hitting the Catch-All in the OpenCart workspace which is set to DENY. We need to head over to the OpenCart workspace to correct this.

Switch to the OpenCart Application Workspace.

Locate the rule that has OpenCart-DB to Common-GC-DC-DNS on UDP port 53. Notice that there are no other rules allowing UDP port 53, so we have accidentally omitted the OpenCart-App cluster from talking to the Common-GC-DC-DNS cluster on UDP port 53 which would certainly be required for DNS resolution!

To correct this, we could create a separate rule allowing OpenCart-App to Common-GC-DC-DNS on UDP port 53. However, since both of our clusters will need to talk to Common-GC-DC-DNS on UDP 53 we can simply set the Consumer on the existing rule to the OpenCart scope. This will allow any clusters tied to the OpenCart scope to talk to Common-GC-DC-DNS on UDP 53. Change the OpenCart-DB inventory filter in the rule identified above to the OpenCart Scope.

Click on Policy Analysis, and Analyze Latest Policies. This will ensure when we later come back and look at Policy Analysis for the OpenCart application, we will be looking at flows based on the policy we just modified. If we didn’t do this, we would be only seeing results based on our original policy.

Enter a reason and click Analyze.

Switch back to the Common Policy application workspace.

The time on the graph will not yet be showing the results of our policy change, but we can use Quick Policy Analysis to see the results of our change. Click on one of the points on the graph with Escaped flows.

On the Flow Details screen click Quick Policy Analysis.

Click on Find matching policies. Notice that we can now see the new rule under Consumer Outbound Policies in the OpenCart application workspace that is allowing the traffic. The Policy Decision also indicates ALLOW, indicating that the traffic would be allowed by the policy.

YOU HAVE COMPLETED THIS MODULE