Ltrsec 3001 LG
Ltrsec 3001 LG
Ltrsec 3001 LG
and
Firepower NGFW
in ACI
Lab 2.0 Guide
Developers and Lab Proctors
This lab was created by: Goran Saradzic and Minako Higuchi
Lab Overview
Advanced security in ACI 2.0 lab demonstrates how Cisco Security protections can be quickly deployed in
the ACI fabric, using dynamic policies, and rapid containment of threats. You will work with ASA5525
contexts and Firepower NGFWv (FTD or Firepower Threat Defense image), and their managed Service
Graphs. We start the lab with a scripted build-out of a full Tenant with security services. Tenant has three
EPGs (web, app, db), two VRFs (internal pod#net, external vrf#net), and an outside campus OSPF peering
firewall ‘ASAv-outside’, which connects web EPG to the outside campus host. The demo script called
rebuild-mypod.bash, combines a number of python scripts to create three working service graphs and their
contracts. Two use ASA contexts (out-to-web and web-to-app) and one uses FTDv (app-to-db) with FMCv
(Firepower Management Center) as a device manager. The Super-PuTTY application gets you access to all
the EPs, outside host, security services, and api client VM that runs all the scripts with your Tenant.
• Lab Exercise 1: Connect and run scripts to build-out your Tenant with security services
• Lab Exercise 3: Apply malware protection to FTDv service graph on app-to-db contract
• Lab Exercise 4: Run Rapid Threat Containment with APIC Firepower remediation package
• Lab Exercise 5: Study the mechanics and benefits of the ASA PBR service graph
Lab Topology
This is the POD topology used for ASA and FTD in the training lab. It shows all IP information for devices on
outside network, and web/app/db EPGs. Notice that web & app EPGs are in the same subnet and BD.
Below diagram is from APIC Application Profile graphical view. It depicts what your scripts will do by showing before
and after picture of your tenant. You start with left picture and run the python scripts to fully orchestrate the
Tenant with its contracts and ASA and FTD security services.
Note: You must log into the right APIC and vCenter, designated to manage your Tenant, as there are two separate
fabric environments with 20 PODs in each.
After your Tenant is fully built, you will review all configurations in APIC, vCenter, ASA contexts, FMC, FTDv,
and validate connectivity between VM linux End Points (EPG workloads).
Exercise Objective
Your proctor has fully setup APIC and prepped the scripts for you to provision the following resources for
your review:
1. Application profile with web, app, and db EPGs, and outside segment simulating campus
6. To conclude, you use the provided python scripts to orchestrate the build out your tenant
networking and security functions and test all connectivity and inspection at the end.
Step 2 Now open your FMC console in Google Chrome browser. After entering below URL, it will take about
15sec before you can ‘Proceed’ under ‘Advanced’ link and accept SSL certificate warning.
https://10.0.0.30
username: aciadmin
password: cisco
Step 3 Once logged into FMC, please enable Evaluation license on FMC. This allows you 90-day evaluation
period with FMC and registered appliances. Under System -> Licenses -> Smart Licenses screen, click on
Evaluation Mode.
Step 4 Next, start SuperPutty shortcut which logs you into all your End Point hosts (outside, web, app, and db),
api-client (linux VM that hosts your python scripts), and ASAs for your pod (asa1-fover and asa2-cluster
contexts, plus ASAv-outside). If you see any ssh key alerts, please answer ‘yes’ to all of them (see below
screenshot).
Step 6 Now register our Firepower NGFWv (FTDv) to FMCv, and prepare it for use with APIC FTD device package.
On api-client tab, please execute the following Perl script, that use FMC REST-API to register your
appliance to FMC. NGFWv was preconfigured with 10.0.0.51 IP and registration request to FMC.
./ftd1-reg.pl
Step 7 While FMC is going through registration, let’s match up your VMs in vSphere client and SuperPutty
application.
You can see that web, app, and db EP’s eth0 is not attached to the ACI fabric, this vNIC is used for out-of-
band management connectivity to these VMs (network 10.0.0.x/24). ACI port-profiles are attached to EP
eth1 interface (network adapter 2), placing them into appropriate EPGs. You can run command
“/sbin/ifconfig eth1” on each VM linux host and match their IPs to our Tenant diagram (handout). I.e.,
web linux eth1 is on pod#|aprof|web, and matches up to EPG 10.1.x.x/16 subnet. Lastly, note that some
vNICs may not be shown to you under Edit Settings, like service graph portgroups, as permissions are not
set for those on-the-fly for your user in VMware.
Step 8 Open your designated APIC console in the Google Chrome browser. After entering below URL, it will take
again about 15sec before you can ‘Proceed’ under ‘Advanced’ link and accept SSL certificate warning.
Step 9 Get into your Tenant, and take your time to review the following items in your APIC Tenant.
Click on ‘Tenants’ link on top, next to ‘System’, then double-click on your tenant from the list, or search
for your Tenant pod#, i.e. enter “pod#” in the Search field and then click on “Tenant pod#” that shows up
under search field. Once Tenant pod# appears as root folder, proceed to review Application Profiles
‘aprof’ and three EPGs defined.
Step 10 Click on each EPG (app, db, and web), and match the Bridge Domain it is in. Per your diagram, web and
app EPGs are in the same ‘web’ Bridge Domain.
Step 11 Under Networking, review Bridge Domains (BDs), and VRFs they belong to. Note that ‘app’ BD is currently
not used in the lab, however, in the previous lab it was used for ASAv GoThrough service graph, between
web and app EPGs, respectively in their own BDs.
Step 12 Now, let’s check that FMC registered and applied policy to your Firepower NGFWv (FTDv) appliance. In
your Chrome browser, logged into FMC, click on Devices, and verify vFTD1 is registered.
Step 14 Each step represents a python script run against your APIC pod. After execution, it will display the XML
output of what is being pushed your Tenant. Feel free to review any of the scripts or XML output. Here is
an example of the output you will see.
…snip….
6. Create PBR BD for ASA failover context device: [continue]
Step 17 Lastly, review the Contracts, the service graphs applied to those contracts, and under Networking, try to
figure out what the PBR route redirect and Route Tag options are for. Route tag is for L3out OSPF peering
and each VRF has a route-tag policy. ACI checks the route tag to prevent a loop. PBR policy is used for
PBR service graph.
If you have a proctor, they will review your pod to ensure you understand where all the security related
items are added in APIC, and how to test all your connectivity.
Conclude this exercise by validating connectivity between all the contracts, using provided scripts on all
þ End of Exercise: You have successfully completed this exercise. Proceed to next section.
Exercise Description
We study ASA Dynamic update to EPG feature in this exercise. This feature allows APIC to install and update
ASA object-group with EPG names and IP host/subnet members. ASA ACL configuration can use EPG names
(formatted as Tenant-ApplicationProfile-EPG name) to control access between EPGs with this service graph.
Your current out-to-web contract is provided only to Web EPG. You will first provide it to App EPG, adding
connectivity from App to Outside campus (dotted red line below), and then you will enable Dynamic update
with ‘Attach Notification’ option under service graph terminals. Lastly, you will change ASA ACLs to include
EPG object-groups instead of Any traffic allowed.
Exercise Objective
Inside APIC, you will make the following changes:
3. Inside asa-clu-gr, edit asa-clu-fprof Function Profile, and change ACLs to use EPG object-groups.
4. Test protocol connectivity between outside and web/app EPGs according to your ACL
Step 3 Now re-test your connectivity from outside host to app VM.
ping 10.1.(your pod#).102
(it should now work!)
Next, turn on ‘Attachment Notification’ on ASA cluster context and review that APIC created the new
object groups. In APIC, under L4-L7 Services -> L4-L7 Service Graph Templates -> asa-clu-graph, expand
Function Node – Firewall and select each terminal, Consumer & Provider. Under each terminal, enabled
(check) Attachment Notification, and ensure to Submit after each terminal check is enabled.
Step 4 Now go to Super-Putty asa2-cluster, run the below cli, and verify you have proper EPGs as ASA object-
groups. Note that we also have an outside network, our external EPG from the consumer side, defined as
a subnet. If your session into asa2-cluster is not responding, you can Restart Session via Super-Putty. You
will need ‘enable’ followed by Enter, to get to the right prompt to allow you to execute below command.
show run object-group
Step 5 Before proceeding to change the ASA access-list(s), first see what ASA has in place by running this cli.
show access-list
In APIC, under L4-L7 Services -> Function Profiles -> asa-clu-gr -> asa-clu-fprof, Edit via ‘Pencil, click ‘All
Parameters’ and ‘AccessLists’ to only see relevant options. Then expand Access List folder, and expand
‘permit-http’ ACE row, and expand Destination Address ‘dest-address’. Then under ‘dest-address’ folder,
remove ‘Any’ row by clicking on X next to it, then add appropriate value for Endpoint Group.
Step 8 Once you submitted this change to APIC, you can verify ACE for http (or your chosen protocol) has
updated on ASA, and you can test HTTP connectivity from outside to web and app.
show access-list (run this cli on asa2-cluster tab)
LTRSEC-3001 - Deep Dive Lab on ASA and Firepower NGFW in ACI 18
Lab Exercise 3: Apply malware protection to FTDv
service graph on app-to-db contract
Exercise Description
To protect our ACI workloads from attacks, we must inspect their traffic and configure appropriate level of
security. Firepower NGFW offers number of security features, but we will focus on Advanced Malware
Protection (AMP). To enable malware protection between app and db EPGs, we need to create a file policy
for the FTDv service graph, applied to app-to-db Contract. This malware policy will block known bad files
from being transferred between EPGs and generate an event in FMC. In exercise 4, this malware event will
be used to quarantine offending VM, using APIC Firepower Remediation module..
Exercise Objective
Open FMC console in your Chrome browser, implement the following:
1. Create a ‘block-malware’ file policy with Block Malware action of exe files.
2. Apply the ‘block-malware’ file policy to the ‘ftd-rule1’ rule under inspection in ‘ftd-policy’
Step 3 Create a rule that ‘Blocks Malware’ exe of all types. Click Add.
Step 4 Before Saving, make sure your rule reflects below screenshot.
Step 6 Now we apply that file policy to our rule governing communication between app and db EPGs, under app-
to-db contract. Click on Policy tab, and Edit your ftd-policy by clicking on the pencil.
Step 7 Inside ftd-policy, Edit (pencil) ftd-rule1.
Step 9 Save your changes to the policy, and then deploy those to your vFTD1 device. After you click Deploy (2),
in the next screen, you need to check vFTD1 device and click Deploy. Any change to policy needs to be re-
deployed to FTD appliance.
Step 10 You can watch the progress of your deployment under status icons. Make sure policy deploy finishes.
þ End of Exercise: You have successfully completed this exercise. Proceed to next section.
Exercise Objective
Open FMC console in your Chrome browser, implement the following:
1. Create an FMC remediation instance, using previously installed FMC to APIC remediation package.
2. Create a correlation policy and rule that trigger on known disposition network-based malware event.
4. Test the successful quarantine of a VM by issuing app-to-db_exe script on app End Point, which does a
wget of this file from db End Point.
5. Test also this transfer on db End Point, noting the need for attacker VM to have a unique IP in the
fabric.
Step 1 On your FMC, hover your mouse pointer over Policies -> Actions and click on Instances under
Remediations.
Step 3 Fill out the instance ‘RTC’ with your APIC IP and credentials for your tenant, as seen in below screenshot.
Step 4 Now when you see the Success message, scroll down on this page and on the bottom, Add the
remediation type ‘Quarantine an End Point on APIC’. Then make sure you do Save Remediation RTC
instance, then do Done.
Step 6 Create an RTC_rule that uses malware event, generated from a network-based detection (your NGFWv),
and uses condition that state malware is known, or has a known disposition. Save this rule. Feel free to
review all the options available in terms of type of event, source of event, and condition.
Step 9 Now add a response into your rule.
Step 10 Select your RTC response created earlier, and add it into your rule. If you do not see RTC response listed,
go back to Step 4 and make sure you click Add Quarantine an End Point.
Step 12 Finally, (very important) enable your Correlation policy in the next screen.
Step 13 Your Correlation policy should look like this, when enabled.
Step 14 Now we are ready to test quarantine. Go to app and db tabs on your SuperPutty. Make sure you still
have connectivity between two VMs by running these test scripts:
On app VM, run: app-to-db_ping and app-to-db_udp
On db VM, run: app-to-db_ping and ./server.iperf
(server.iperf on db receives and reports UDP packets sent via app-to-db_udp)
Step 15 Now let’s try to send a bad file between these two VMs, where app tries to wget the malware sample.
Run this script on app VM: app-to-db_exe
(If things went well, you should see that connection is reset, and that next attempt is not connecting)
Step 17 Now, you can take a look at APIC uSeg EPG, and find your VM quarantined. Also, you can review FMC
action successfully executed by looking at Status under Analysis -> Correlation -> Status.
Step 18 Feel free to review the correlation events to find out how bad is your malware sample file. Also, you can
repeat this workflow by deleting the ‘EPG quarantine-app’ and retrying to send it again. Once you
reproduced quarantine uSeg EPG multiple times, you can proceed to Step 22 to remove the uSeg EPG and
ensure you can still communicate with app End Point.
***Note that your db VM, does not have a unique IP in the fabric, it overlaps with any other db VM in
your fellow attendee pods. This means that if you attempt app-to-db_exe script on db VM, our action will
not succeed. You can verify overlapping IPs by searching for db VM’s IP 10.2.0.103 on APIC’s Operations -
> EP Tracker page.
Step 19 If your app VM quarantine action failed, we should first check if app EPG ‘Operations’ tab has it listed with
a discovered IP. Go Application Profile -> app EPG, then in the right screen, select Operations tab.
Step 20 Let’s try to generate UDP traffic again, from app to db app, and see if it helps discover app VM IP.
On db host, start script ./server.iperf
on app host, start script app-to-db_udp
Step 21 If this helped, you should now see the IP address of app VM in operations tab. You can now try to run
Step 15, and quarantine an infected host.
þ End of Exercise: You have successfully completed this exercise. Proceed to next section.
Exercise Description
PBR service graph is a new and very promising way of integrating security services in the ACI fabric. It
allows us to insert security between EPGs within the same Bridge Domain, while keeping the anycast
gateway service on the ACI leafs. It provides both one-arm and two-arm deployment scenarios. Lastly, it
enables us to select protocols we wish to send to a service graph. In your lab, web-to-app contract has an
ASA one-arm PBR service graph.
Exercise Objective
On APIC, you will modify the PBR service graph to do the following:
2. Create web-to-app subject ‘fabric_to_asa’ with filters to allow HTTP and SSH traffic.
3. Create web-to-app subject ‘fabric’ with filters to include ARP and ICMP.
Step 2 Now right click on ‘web-to-app’ contract, and create new contract subjects: fabric-to-asa and fabric.
‘fabric-to-asa’ will have ASA PBR service graph applied and re-direct traffic to ASA and have http and ssh
filters (you must create new filters for http and ssh, as shown in step 3).
‘fabric’ subject will have ARP and ICMP filter (reuse the filters already created under common Tenant,
shown in the right side of below screenshot), and simply govern traffic without security service, traversing
ACI leafs at line rate speeds.
Step 4 Your subjects should look like two below screenshots.
Step 6 Did you notice that SSH is being denied on ASA? You have to add an ACL rule on ASA to allow SSH. Let’s
change the https ACE line into SSH permit.
Go to L4-L7 Services -> Function Profiles -> pbr-cfg -> pbr-cfg-asa
Click on Pencil to modify the parameters
Click All Parameters tab and link on the left AccessLists
Expand Access List folder and double click on ‘permit-https’ Name field. Change it to ‘permit-ssh’, Update
Step 8 Now you can test that ssh works through ASA. Password is ‘cisco’ for ssh session if you want to fully
establish your TCP connection.
Step 9 Lastly, we would like to show you that if we remove the ASA PBR service graph from the ‘fabric-to-asa’
subject, all of the filtered protocols will continue to work, as they are allowed by filters in both subjects.
This is a benefit of the PBR service graph but also something security teams should be aware of.
Note that if you establish an ssh connection via ACI contract, and then add an ASA service graph in mid-
flight of this connection, the ASA will block the connection as it needs to see it from the start of the 3-way
handshake.
þ End of Exercise and the Lab: You have successfully completed this lab.
Thank you for participation.
Active/Standby Failover
FP9300, FP4100 Go-To (L3FW),
Active/Active Cluster on FPR
Firepower NGFW (FTD app) Go-Through (L2FW
ASA5500-X hardware
and Inline IPS)
Fail-to-Wire NetMods
Go-To (L3FW),
Firepower NGFWv (FTDv) Vmware, KVM Go-Through (L2FW Active/Standby Failover
and Inline IPS)
Device packages for ASA is available on cisco.com. FTD device package is coming soon as it is in beta test.
See below device package and Fabric versions used in the training lab.
1.2.7.10
ASA 9.5.1
Managed Service Graph
Firepower 1.0.1.11
6.2.0(build 362)
Management Center Managed Service Graph
Device IP Address
jump-box 10.0.0.10
api-client 10.0.0.20
web-linux 10.0.0.101
app-linux 10.0.0.102
db-linux 10.0.0.103
outside-linux 10.0.0.40
outside-ASAv5 10.0.0.41
ASA5525 fover context 10.10.10.(POD# + 80) – active , 10.10.10.(POD# + 210) – standby
ASA5525 cluster context 10.10.10.(POD# + 30) – master, 10.10.11.(POD# + 140) – slave
(mgmt pool)
FMC 10.0.0.30 NAT-ed to 10.10.30.pod#
vFTD1 10.0.0.51
ASAv inside 10.0.0.32 NAT-ed to 10.10.32.pod#
Device IP Address
POD Devices on External Networks to ACI Fabric
The table that follows lists the internal IP addresses used by the devices external to fabric.
Device IP Address
outside-linux 10.70.0.101
APIC1 10.10.35.10
vCenter1 10.10.35.120
APIC2 10.10.35.11
vCenter2 10.10.35.125
jump-box Administrator /
<look in labops TOPOLOGY tab>
• Deep Dives on how to setup ASA Failover, Multi-contexts, and Clustering in ACI
• FMC Rapid Threat Containment with APIC, ASA One-Arm PBR Service Graph