Firepower NGFW Lab v1

Cisco dCloud
Cisco Firepower Next Generation Firewall 6.2 Lab v1

Last Updated: 31-OCTOBER-2017
About This Demonstration

This guide for the preconfigured demonstration includes:
• Requirements
• About This Solution
• Topology
• Get Started
• Scenario 1: Device Deployment with the REST API
• Scenario 2: Basic Configuration
• Scenario 3: AnyConnect Remote Access VPN
• Scenario 4: AnyConnect with RADIUS Attributes
• Scenario 5: AnyConnect with Client Certificates
• Scenario 6: Monitoring and Troubleshooting
• Scenario 7: Cisco Threat Intelligence Director (CTID)
• Scenario 8: FlexConfig
• Scenario 9: ASA to NGFW Migration
• Scenario 10: NAT to Routing
• Scenario11: Site-to-Site VPN
• Scenario 12: Web Proxy Integration
• Scenario 13: Prefilter Policies
• Scenario 14: Integrate Routing and Bridging (IRB)
• Appendix A: FMC Pre-configuration
• Appendix B: REST API Scripts
• Appendix C: ISE RA VPN Configuration
• Appendix D: Using Alien Vault as a TAXII Feed
NOTE: It is recommended that you do not attempt all of the exercises in one session. Together, these exercises could take
approximately 6 hours. Please use the following dependencies when deciding which scenarios to attempt.
• All scenarios rely on Scenario 1 and Scenario 2. These must be done, and must be done in order.
• Scenarios 3 through 6 cover Ra VPN in detail. However, for a basic understanding of RA VPN configuration, it is sufficient
to complete Scenario 3.
© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 111
Cisco dCloud
• Scenario 13 uses the static NAT configuration from Scenario 10.
Requirements
The table below outlines the requirements for this preconfigured demonstration.
Table 1. Requirements
Required Optional
● Laptop ● Cisco AnyConnect®
About This Solution

Today’s world is undergoing digital disruption that will spark more connectivity than ever before, as consumers, businesses and
governments leverage digitization to drive innovation forward. Yet, the more connected we become, the more opportunities we
create for cybercriminals. In order for enterprises to operate effectively in today’s environment, they have to focus their security
efforts on stopping advanced threats in the current dynamic threat landscape.
IT teams have been asked to manage security using a patchwork of siloed point products, starting with legacy next-generation
firewalls (NGFW), which were created with a focus on application and bolted on best effort threat protection. As such, these legacy
NGFWs are unable to provide an enterprise with the contextual information, automation, and prioritization that they need to handle
today’s modern threats. To stay one step ahead of today's sophisticated hackers and malware, you need a fully integrated security
solution that offers comprehensive network visibility, threat intelligence, and retrospective security technology that can respond
quickly to attacks.
The Cisco Firepower 4100 Series Next-Generation Firewall (NGFW) addresses these issues as the industry’s first fully integrated,
threat-focused Next-Generation Firewall.
Cisco Firepower NGFW is built from the ground up to keep organizations safer. Firepower NGFW also keeps the cost and
complexity that legacy NGFWs create in check by delivering fully integrated security – with a single interface to ease the
management burden. We do not add to the number of appliances or consoles in the already sprawling security technology “stack”
companies typically manage.
This allows the Cisco Firepower NGFW to evolve with a focus on enabling enterprises to stop, prioritize, understand, and automate
responses to modern threats in real-time. Firepower NGFW is unique in its threat-focus, with a foundation of comprehensive
network visibility, best-of-breed threat intelligence and highly-effective threat prevention to address both known and unknown
threats. Firepower NGFW also enables retrospective security, through Advanced Malware Protection, that can “go back in time” to
quickly find and remediate sophisticated attacks that may have slipped through defenses. This has led to a significant reduction in
time-to-detection (TTD) for Cisco customers compared to industry averages.
The Cisco Firepower NGFW also addresses customers’ challenges with advanced threat protection that extends from the network
out to the endpoints. And we have seamlessly integrated AMP for Endpoint, AMP Threat Grid, and Cisco Identity Services Engine
(ISE) with the platform. This enables Cisco to extend the power and visibility of the Firepower NGFW across the network and
directly to the endpoint
Cisco dCloud
Topology
This content includes preconfigured users and components to illustrate the scripted scenarios and features of the solution. Most
components are fully configurable with predefined administrative user accounts. You can see the IP address and user account
credentials to use to access a component by clicking the component icon in the Topology menu of your active session and in the
scenario steps that require their use.
Figure 1. dCloud Topology
Cisco dCloud
Get Started
BEFORE PRESENTING
Cisco dCloud strongly recommends that you perform the tasks in this document with an active session before presenting in front of
a live audience. This will allow you to become familiar with the structure of the document and content.
It may be necessary to schedule a new session after following this guide in order to reset the environment to its original
configuration.
PREPARATION IS KEY TO A SUCCESSFUL PRESENTATION.
Follow the steps to schedule a session of the content and configure your presentation environment.
1. Initiate your dCloud session. [Show Me How]
NOTE: It may take up to 10 minutes for your session to become active.
2. Connect to the workstation using the Cisco dCloud Remote Desktop client [Show Me How].
NOTE: You can also connect to the workstation with Cisco AnyConnect VPN [Show Me How] and the local RDP client on your
laptop [Show Me How]
Jumper: 198.18.133.50, Username: administrator, Password: C1sco12345
Cisco dCloud
Scenario 1. Device Deployment with the REST API

The objective of this lab you will perform a simple deployment of the NGFW. Most of this will be with a REST API python script. But
first you must perform some preliminary steps. Also the routing configuration is not yet supported by the REST API, so you will do
this by hand.
Steps
Configure the NGFW for management by the FMC
1. On the Jump desktop, open the PuTTY link. Double click on the preconfigured session called NGFW. Login as admin,
password C1sco12345.
NOTE: If you run into issues with typing special characters, please open the file on the Jump desktop called Strings to cut and
paste.txt.
2. Type the command configure manager add fmc.dcloud.local C1sco12345.
3. Read the warning.
4. Answer yes when asked if you want to continue. Do not type y. If you type y instead of yes, the command defaults to no.
The NGFW was installed with the on-box manager (Firepower Device Manager or FDM) enabled. This is the default configuration.
This is why you are receiving this warning. We do not have on-box management lab exercises in this class. But it is available. But
be aware that you cannot switch between FMC and FDM without deleting the NGFW configuration.
5. Leave this PuTTY session open. You will use it throughout the lab.
Enable Smart licenses on the FMC
For NGFW, you must use Smart licensing. For this lab, you will use the built-in 90 day evaluation license.
NOTE: For this class we are using customized software. In the production code, you cannot deploy RA VPN with an evaluation
license.
1. Open Firefox and open the Firepower Management Center (labeled FMC) on the Jump desktop. The login name and
password will prepopulate.
2. Click Log In.
3. Navigate to System > Licenses > Smart Licenses.
4. Click on Evaluation Mode, and click Yes when prompted.
Cisco dCloud
Run a REST API script to register and configure the NGFW
To demonstrate the REST API, you will run a Python script that will perform the following.
1. Create an access control policy.
2. Register the NGFW to the FMC.
3. Configure the NGFW interfaces.
NOTE: This script is intended for training purposes only, so it is not perfectly polished. If you wish to inspect this script, it is located
in /usr/local/bin. It is called register_config.py, and uses a Python module generated by connect.py. The command
runapiscript is a symbolic link to register_config.py. These scripts are also included in Appendix B of this guide.
4. From the Jump desktop, launch PuTTY. Double-click on the Inside Linux server session. Login as root, password
C1sco12345.
5. On the Inside Linux server CLI run runapiscript.
a. When asked Would you like to register the managed device? [y/n], enter y and press <Return>.
b. When prompted to enter an access control policy name, enter a reasonable name, like NGFW Access Control
Policy.
c. Wait for a confirmation message.
d. In the FMC UI, confirm that the device discovery has completed and then press y to continue or n to exit. [y/n]
e. Go on to the next step before you continue the script.
NOTE: If you did not wait for discovery to complete, you will get an error. In this case, wait for discovery to complete and then run
the script again, but this time, enter n when asked if you want to register a device.
6. On the FMC, click on the icon to the right of the Deploy button, and select the Tasks tab.
a. Wait for a bit. It may take a minute before any tasks start.
NOTE: If no tasks start for over a minute, check to see if you enabled the demo Smart license. If you did not, you should enable it,
and run the runapiscript script again. Be sure to use a different name for the access control policy, or delete the policy that the
script created.
b. Wait for the discovery task to complete. Do not worry about failed tasks. All that matters is that registration and
discovery succeed.
Cisco dCloud
7. On the Inside Linux server CLI continue with the runapiscript script.
a. Enter y and press <Return>.
b. When asked Would you like to configure device interfaces? [y/n], enter y and press <Return>. Wait for the script
to complete.
c. Leave this PuTTY session open. You will use it throughout the lab.
Configure the default route
1. In the FMC, navigate to Devices > Device Management. Click on the pencil icon to edit the device settings.
2. The Interfaces tab should be selected. Confirm that the REST API script configured the inside and outside interfaces of the
NGFW.
3. Select the Routing tab.
a. Select Static Route, and click the Add Route button.
b. Set the default route to 198.18.128.1 on the outside interface, as in the figure below.
c. Click OK.
4. Click Save to save the routing configuration.
NOTE: To save time, do not deploy the routing configuration yet. Also, to save time, the runapiscript script does not include
the deployment of the interface configuration. You will perform more configuration steps in the next lab exercise, and then deploy
all the configuration changes together.
Cisco dCloud
Scenario 2. Basic Configuration

This exercise consists of the following tasks:
• Create objects needed for exercise
• Modify the access control policy
• Create a NAT policy
• Modify the network discovery policy
• Deploy the configuration changes
• Test the NGFW configuration
The objective of this exercise is to deploy a simple but effective NGFW configuration.
• Allow outbound connections, and block other connection attempts
• Perform file type and malware blocking on these outbound connections
• Provide intrusion prevention on these outbound connections
Steps
Create objects needed for exercise
1. Navigate to Objects > Object Management.
a. Click Add Network > Add Object.
b. For Name, enter Lab_Networks.
c. Enter 198.18.0.0/15. This includes all IP addresses used in the lab pod.
d. Click Save.
2. Select Interface from the left navigation panel.
a. Click Add > Security Zone.
NOTE: There are two types of interface objects: security zones and interface groups. The key difference is that interface groups
can overlap. Only security zones can be used in access control policy rules.
b. For Name, enter InZone. Select Routed from the Interface Type drop-down menu.
c. Select the inside interface. Click Add and then click Save.
d. Click Add > Security Zone.
e. For Name, enter OutZone. Select Routed from the Interface Type drop-down menu.
f. Select the outside interface. Click Add and then click Save.
Cisco dCloud
Modify the access control policy
1. Navigate to Policies > Access Control > Access Control. Notice that an access control policy was created by the REST API
script.
2. Edit the access control policy by clicking the pencil icon to the right of the policy.
3. Click Add Rule.
a. For Name, enter Allow Outbound Connections.
b. Select into Default from the Insert drop-down list.
NOTE: Rules are divided into sets within a policy. Two sets are predefined:
• Mandatory rules, which take precedent over rules of child policies
• Default rules, which are evaluated after the rules of child policies
In this exercise, you will not create a child policy, but you will use the default rule set as a convenient way of making sure this rule
is evaluated last.
c. The Zones tab should already be selected.
i. Select InZone and click Add to Source.
ii. Select OutZone, and click Add to Destination.
d. Select the Inspection tab.
i. Select Demo Intrusion Policy from the Intrusion Policy drop-down list.
ii. Select Demo File Policy from the File Policy drop-down list.
NOTE: The demo intrusion and file policies were pre-configured to save you time. See Appendix A for instructions on how to
create these.
e. Click Add to add the rule.
4. Select the HTTP Responses tab.
5. Select System-provided from the Block Response Page drop-down list.
6. Select the Advanced tab.
a. Click the pencil icon to edit the Transport/Network Layer Preprocessor Settings.
b. In the Maximum Active Responses text field, enter 25.
c. Click OK.
Cisco dCloud
NOTE: Setting Maximum Active Responses to a value greater than 0 enables the rules that drop packets to send TCP resets to
close the connection. Typically both the client and server are sent TCP resets. With the configuration above, the system can initiate
up to 25 active responses (TCP Resets) if it sees additional traffic from this connection.
In a production deployment, it is probably best to leave this set to the default. Then no resets are sent, and the malicious system
will not know that it has been detected. But for testing and demonstrations, it is generally better to send resets when packets match
drop rules.
7. Click Save to save the changes to the access control policy.
Create a NAT policy
1. Navigate to Devices > NAT.
2. Click the New Policy button, and select Threat Defense NAT.
a. For Name enter Default PAT.
b. Select NGFW. Click Add to Policy and then click Save.
c. Wait for the policy to open for editing.
3. Click Add Rule.
a. Select In Category and NAT Rules After from the Insert drop-down lists. This will ensure that this rule is evaluated
after the auto-NAT (object NAT) rules.
b. Select Dynamic from the Type drop-down list.
c. You will be at the Interface Objects tab. Select InZone and click Add to Source.
d. Select OutZone, and click Add to Destination.
Cisco dCloud
e. Select the Translation tab.
f. Select any from the Original Source drop-down list.
g. Select Destination Interface IP from the Translated Source drop-down list.
h. Click OK to save the NAT rule.
4. Click Save to save the NAT policy.
Modify the network discovery policy
The default network discovery policy is configured to discover all applications, both internal and external. We will want to add host
and user discovery. In a production environment, this can exceed the FMC Firepower host license. For this reason, it is best
practice to modify the policy.
1. Navigate to Policies > Network Discovery.
a. Click the pencil icon to the right to edit the existing rule.
b. Check the Users checkbox. The Hosts checkbox will auto-check.
c. Delete both 0.0.0.0/0 and ::/0.
Cisco dCloud
2. Select the network Lab_Networks and click Add.
3. Click Save.
Deploy the configuration changes
1. Click Deploy in the upper right hand corner of the FMC.
a. Check the for the NGFW device, and expand the list to see the details.
b. To the right of Device Configuration, mouse over Details. The page should look like the following figure.
Cisco dCloud
c. Confirm that NGFW settings, NAT policy network discovery, interface and static route configuration will be modified.
d. Click the Deploy Button.
e. Click on the icon to the right of the Deploy link in the upper right-hand corner of the FMC. Wait until the deployment
is complete.
Test the NGFW deployment
1. On the Inside Linux Server CLI:
a. Enter wget cisco.com. This should succeed. This confirms NAT and routing.
b. Enter ping outside. This should succeed. Enter Ctrl+C to exit ping.
c. Enter ftp outside. Login as guest, password C1sco12345.
d. Type cd ~root. You should see the following message: 421 Service not available, remote server has closed
connection. This confirms that IPS is working.
NOTE: If the FTP session hangs, you probably forgot to enable active responses in the access control policy. You need not fix this,
as long as you remember to expect this behavior.
e. Type quit to exit FTP.
2. In the FMC, navigate to Analysis > Intrusions > Events.
NOTE: Observe that Snort rule 336 was triggered. In the Demo Intrusion Policy, the rule state for this rule is set to Drop and
Generate Events. This rule is disabled in the system-defined intrusion policies such as Balanced Security and Connectivity.
Cisco dCloud
NOTE: In a production environment, if you run into a situation where events are not appearing, the first thing you should check is
the time synchronization between the NGFW and FMC. However, in this lab, it is more likely to be an issue with the evening
processes. If this happens, try restarting these processes as follows.
One the NGFW CLI run the following command.
pmtool restartbytype EventProcessor
From the Jumper desktop, connect to the FMC using the pre-defined PuTTY session. Login as admin/FPlab123! and run the
following commands.
sudo pmtool restartbyid SFDataCorrelator
sudo pmtool restartbyid sftunnel
The sudo password is FPlab123!.
a. Click the arrow on the left to drill down to the table view of the events. Observe that details of the event are
presented.
b. Click the arrow on the left of the event to drill down further. Note that you are presented with extensive information,
including the details of the Snort rule.
c. Expand the Actions and note that you could disable the rule from here – but do not!
d. Expand the Packet Bytes to see the contents of the packet that triggered the rule.
3. Test the file and malware blocking capabilities. These Wget commands can be cut and pasted from the file on the Jump
desktop called Strings in order to cut and paste the text.
a. As a control test, use WGET to download a file that is not blocked.

wget -t 1 outside/files/ProjectX.pdf
This should succeed.
b. Next use WGET to attempt to download the file blocked by type.

wget -t 1 outside/files/test3.avi
Note that very little of the file is downloaded. This is because the NGFW can detect the file type when it sees the first
block of data. The Demo File Policy is configured to block AVI files.
c. Finally use WGET to attempt to download malware.

wget -t 1 outside/files/Zombies.pdf
Note that about 99% of the file is downloaded. This is because the NGRW needs the entire file to calculate the SHA.
The NGFW holds onto the last block of data until the hash is calculated and looked up. The Demo File Policy is
configured to block malware detected in PDF files.
Cisco dCloud
4. In the FMC, navigate to Analysis > Files > Malware Events.
a. Observe that one file, Zombies.pdf, was blocked.
b. Click the arrow on the left to drill down to the table view of the events. Note that the host 198.19.10.200 is
represented by a red icon. This is the Inside Linux Server. The red icon means the host has been assigned an
indication of compromise.
NOTE: The action is reported as Custom Detection Block, instead of Malware Block. This is because we added Zombies.pdf to the
custom detection list, just in case the lab has issues connecting to the cloud. See Appendix A for details.
If you wish, you can try the following.

wget -t 1 outside/malware/Buddy.exe
This should be reported as a Malware Block. However, in this particular lab environment, the cloud lookup may fail. Therefore the
file may not be blocked.
5. Click on the red computer icon. This will open the host profile page. Look over this page and then close it.
6. Navigate to Analysis > Files > File Events. You should see information about all three file events.
You can drill down for more details if you wish.
Cisco dCloud
Scenario 3. AnyConnect Remote Access VPN

This exercise consists of the following tasks.
• Enable AnyConnect Smart license
• Create AnyConnect RA VPN objects
• Modify the default group policy
• Run the RA VPN wizard
• Configure the device certificate
• Modify the access control policy to permit inbound AnyConnect access
• Configure a NAT exemption
• Configure VPN logging
• Deploy and verify the NGFW RA VPN configuration
• Test the configuration
The objective of this exercise is to understand and configure AnyConnect remote access VPN feature available on the Cisco
Firepower NGFW.
Steps
Enable AnyConnect Smart license
1. In the FMC, navigate to System > Licenses > Smart Licenses.
a. Click Edit Licenses.
b. In the Edit Licenses window, select the AnyConnect Apex tab.
c. Select the NGFW device. Click Add and Apply.
Cisco dCloud
Create AnyConnect RA VPN objects
1. Create an AnyConnect image object for Windows.
a. In the FMC, navigate to Objects > Object Management > VPN > AnyConnect File.
b. Click Add AnyConnect File.
c. For Name, enter AnyConnect-Win-Img.
d. Click Browse and navigate to the RA VPN folder on the Jump desktop.
e. Select the anyconnect-win-4.4.01054-webdeploy-k9.pkg file.
f. Click Open. Note that the File Type text field prepopulates with the correct value.
g. Click Save.
2. Create another AnyConnect image object for MAC OS.
a. Click Add AnyConnect File.
b. For Name, enter AnyConnect-MAC-Img.
c. Click Browse and select the anyconnect-macos-4.4.01054-webdeploy-k9.pkg file from the RA VPN folder on the
Jump desktop.
d. Click Open. Note that the File Type text field prepopulates with the correct value.
e. Click Save.
Cisco dCloud
3. Create an AnyConnect client profile object.
a. Click Add AnyConnect File.
b. For Name, enter AnyConnect-Profile1.
c. Click Browse and select the AC-Profile1.xml file from the RA VPN folder on the Jump desktop.
d. Click Open. Note that the File Type text field prepopulates with the correct value.
e. Click Save.
NOTE: AnyConnect client profiles can be create using the VPN Profile Editor tool, which is available on cisco.com. The VPN
Profile Editor tool is also available in the Jump. It can be access as Start > All Programs > Cisco > Cisco AnyConnect profile
editor > VPN Profile Editor.
4. Create an IP pool.
a. In the FMC, navigate to Objects > Object Management > Address Pools > IPv4 Pools.
b. Click Add IPv4 Pools.
c. For Name, enter AC-IP-Pool1.
d. For IPv4 Address Range, enter 198.19.13.10-198.19.13.50.
e. For Mask, enter 255.255.255.0.
f. Click Save.
Cisco dCloud
5. Create a network object corresponding to the IPv4 pool.
a. In the FMC, navigate to Object > Object Management > Network.
b. Click Add Network and select Add Group.
c. For Name, enter AC-NW.
d. Under Selected Networks, in the bottom text field, enter 198.19.13.0/24 and click Add.
e. Click Save.
6. Create a network object for inside network.
a. Click Add Network and select Add Group.
b. For Name, enter Inside-NW.
c. Under Selected Networks, in the bottom text field, enter 198.19.10.0/24 and click Add.
d. Click Save.
Cisco dCloud
NOTE: There is a reason you are asked to use network object groups instead of network objects. In the next lab exercise you will
add another subnet. Since you are using a network group, all you will have to do is modify this object. You will not have to directly
modify the access control and NAT policies.
7. Create an ACL for the RA VPN split-tunnel configuration.
a. In the FMC, navigate to Objects > Object Management > Access List > Extended.
b. Click Add Extended Access List.
c. For Name, enter AC-SplitTunnel1.
d. Click Add.
e. Select Inside-NW from the Available Networks and click Add to Source.
f. Click Add.
g. Click Save.
8. Create a device certificate object.
a. In the FMC, navigate to Objects > Object Management > PKI > Cert Enrollment.
b. Click Add Cert Enrollment.
c. For Name, enter NGFW-Cert.
d. For Enrollment Type, select PKCS12 File.
e. Click Save.
Cisco dCloud
9. Create the object for ISE RADIUS server.
a. In the FMC, navigate to Object > Object Management > RADIUS Server Group.
b. Click Add RADIUS Server Group.
c. For Name, enter ISE-AAA.
d. Click the (+) icon the RADIUS Servers section.
e. For IP Address, enter 198.19.10.130.
f. For Key and Conform Key, enter C1sco12345.
g. Click Save on the New RADIUS Server page.
h. Click Save on the Add RADIUS Server Group page.
NOTE: In order to save time, ISE has been pre-configured with all required configuration for all of the lab exercises. If you want to
inspect the ISE configuration, see Appendix C.
Cisco dCloud
Modify the default group policy
1. In FMC, navigate to Objects > Object Management > VPN > Group Policy.
2. Select and edit DfltGrpPolicy.
3. In the General tab select Split Tunneling.
a. For IPv4 Split Tunneling, select Tunnel networks specified below.
b. Select the Extended Access List radio button.
c. For Access List, select AC-SplitTunnel1.
Cisco dCloud
4. In the General tab select DNS/WINS.
a. For Primary DNS Server, click the (+) icon.
b. For Name, enter Inside-DNS.
c. For Network, enter 198.19.10.100.
d. Click Save.
5. Select the AnyConnect tab. For Client Profile, select AnyConnect-Profile1.
6. Click Save to save the changes to the group policy.
Cisco dCloud
Run the RA VPN wizard
1. In FMC, navigate to Devices > VPN > Remote Access. Click Add. This will launch the wizard.
2. Complete the Policy Assignment page of the wizard.
a. For Name, enter AnyConnect-VPN.
b. From Target Devices, select NGFW. Click Add.
c. Click Next.
3. Complete the Connection Profile page of the wizard.
a. For Connection Profile Name, enter AC-Default-Profile.
b. Confirm that for Authentication Method, AAA Only is selected.
c. For Authentication Server, select ISE-AAA.
d. Under Address Pools, edit IPv4 Address Pools.
e. Select AC-IP Pool1 from IPv4 Address Pools. Click Add and click OK.
Cisco dCloud
4. Confirm that Group Policy is step to DfltGrpPolicy. Click Next.
5. Complete the AnyConnect page of the wizard.
a. Check both file object checkboxes.
b. Click Next.
Cisco dCloud
6. Complete the Access & Certificate page of the wizard.
a. For Interface group/Security Zone, select OutZone.
b. For Certificate Enrollment, select NGFW-Cert.
c. Click Next.
7. Review the Summary page of the wizard.
a. Review the configured presented in this page.
b. Click Finish.
Cisco dCloud
Configure the device certificate
1. In the FMC, navigate to Devices > Certificates.
2. Click Add and select PKCS12 File.
a. For Device, select NGFW.
b. For Cert Enrollment, select NGFW-Cert.
NOTE: Be sure to click on the down-arrow to the right of the text field. If you click in the text area, you will see the string admin.
This is a browser glitch.
c. For PKCS12 File, click Browse PKCS12 File. Navigate to the Certificates folder on the Jump desktop and select
ngfw-outside. Click Open.
d. For Passphrase, enter C1sco12345.
e. Click Add.
Modify the access control policy to permit inbound AnyConnect access
1. In FMC, navigate to Policies > Access Control > Access Control.
2. Select and edit the access control policy. Click Add Rule.
a. For Name, enter AnyConnect VPN Default Permit.
b. Select into Default from the Insert drop-down list
c. The Zones tab should already be selected.
d. Select OutZone and click Add to Source.
e. Select InZone, and click Add to Destination.
Cisco dCloud
f. Select the Networks tab.
i. Select AC-NW and click Add to Source.
ii. Select Inside-NW, and click Add to Destination.
Cisco dCloud
g. Select the Inspection tab.
h. Click Add to add the rule.
i. Click Save to save the changes to the access control policy changes.
Configure a NAT exemption
1. In the FMC, navigate to Devices > NAT.
2. Select and edit the existing NAT policy. Confirm that you see the grayed out Save button at the top right. If you do not,
navigate away and try editing again. This is a known bug.
3. Click Add Rule.
a. You will be at the Interface Objects tab.
Cisco dCloud
b. Select the Translation tab.
i. For Original Source, select Inside-NW.
ii. For Original Destination, select AC-NW.
iii. For Translated Source, select Inside-NW.
iv. For Translated Destination, select AC-NW.
c. Select the Advanced tab, and select Do not proxy ARP on Destination Interface.
Cisco dCloud
NOTE: Enabling Do not proxy ARP on Destination Interface is critical in this lab exercise. If you miss this step, your pod may
have access issues, since all devices are managed in band.
d. Click OK to save the NAT rule
e. Click Save to save the changes to the NAT policy.
Configure VPN logging
To facilitate troubleshooting, you will change the VPN logging level from the default (errors) to informational. At any time during the
lab, you can navigate to Device > VPN > Troubleshooting to view the logged information to help you troubleshoot your
configuration.
NOTE: In a production environment, you would not want to keep the VPN logging set to informational.
1. In the FMC, navigate to Devices > Platform Settings.
a. Click on the blue text Threat Defense Settings Policy.
b. Name the policy NGFW Settings Policy.
c. Select the NGFW device, and click Add to Policy.
Cisco dCloud
d. Click Save. Wait for the policy to open for editing.
e. In the left navigation pane, select Syslog.
f. Under VPN Logging Settings change the logging level to informational. Note that in a production environment, it is
recommended that you set this to errors or alerts.
g. Click Save.
Cisco dCloud
Deploy and verify the NGFW RA VPN configuration
1. Deploy policy to device.
a. In FMC, click the Deploy button.
b. Select NGFW and Click Deploy.
c. Wait for the deployment to complete.
2. You should still have an open PuTTY session to the NGFW CLI. Run some or all of the following commands.
a. show running-config tunnel-group
b. show running-config group-policy
c. show running-config crypto
d. show running-config ip local pool
e. show running-config nat
3. Test AAA by running the following command on the NGFW CLI.

test aaa-server authentication ISE-AAA host 198.19.10.130 username ira password 'C1sco12345'
You can cut and paste this command from the Strings to cut and paste.txt text file on the Jump desktop.
Test the configuration
1. Open the Remote Desktops folder on the Jump desktop, and double click on Outside-PC.
a. Open up Internet Explorer click on NGFW-outside on the favorites bar.
b. For Username, enter ira. For Password, enter C1sco12345. Click Logon.
c. Click the Install button at the bottom of the page. When prompted, click Install again.
Cisco dCloud
d. After successful installation, AnyConnect will automatically connected.
e. Open the AnyConnect client UI from the bottom right of the Outside-PC, as shown below.
2. Open the Advance Window of the AnyConnect client UI, by clicking on the gear icon, as shown below.
a. Select the Statistics tab to the client as the server IP addresses.
b. Select the Route Details tab to confirm the split tunneling: only traffic to 198.19.10.0/24 is considered a secure route.
In other words, only traffic to 198.19.10.0/24 is tunneled through the VPN. Note that 198.19.10.100/32 is also listed
as a secure route. This is because the VPN group policy assigns 198.19.10.100 to the client as the DNS server.
3. Verify this session by running

show vpn-sessiondb detail anyconnect
on the NGFW CLI.
> show vpn-sessiondb detail anyconnect
Session Type: AnyConnect Detailed

Username : ira Index : 60244
Assigned IP : 198.19.13.10 Public IP : 198.18.133.23
Protocol : Clientless SSL-Tunnel DTLS-Tunnel
License : AnyConnect Premium
Encryption : Clientless: (1)AES256 SSL-Tunnel: (1)AES-GCM-256 DTLS-Tunnel: (
1)AES256
Hashing : Clientless: (1)SHA256 SSL-Tunnel: (1)SHA384 DTLS-Tunnel: (1)SHA 1
(Output omitted)
Cisco dCloud
4. On the Outside-PC open the command prompt.
a. Run nslookup inside.dcloud.local. Confirm that PC-outside is using the internal DNS server with IP address
198.19.10.100.
b. Run the following command.

ftp inside.dcloud.local
Login as guest, password C1sco12345. This confirms access to the internal server.
c. Type cd ~root. You should see the following message.

Connection closed by remote host.
This confirms that intrusion protection is working.
5. In Internet Explorer, click on Inside Linux Server click on the favorites bar.
a. Click on the Files link,
b. Click on the ProjectX.pdf link, and click on the Open button at the bottom of the web page, to confirm that you can
download PDFs.
c. Click on the Zombies.pdf link, and click on the Open button at the bottom of the web page You will see the following
message at the bottom of the web page. This is because the file was blocked by AMP for Networks.
a. Observe that Snort rule 336 was triggered.
b. Drill down to the Table View of Events to confirm that the source IP address was from the VPN pool.
7. In the FMC, navigate to Analysis > Files > Malware Events.
a. Observe that Zombies.pdf was blocked
b. Drill down to the Table View of Malware Events to confirm that the source address was from the VPN pool.
8. Disconnect the AnyConnect VPN before you to onto the next lab exercise.
Cisco dCloud
Scenario 4. AnyConnect with RADIUS Attributes

• Create a new group policy
• Create a new IP pool
• Modify the access control and NAT policies
• Modify the connection profile
• Deploy and test the configuration
In this exercise we’ll use ISE RADIUS attributes to dynamically allocate group policy, IP pool and downloadable ACL (DACL)
based on the AD group of the user.
The objectives of this exercise are the following.
• If the RA VPN user is a member of the IT group, they should have full access to any device on the internal network
(174.16.1.0/24).
• If the RA VPN user is not a member of the IT group, they should only be able to access two internal devices.
o The domain controller, ad1.dcloud.local (198.19.10.100)
o The inside Linux server, inside.dcloud.local (198.19.10.200).
• Users that are members of the IT group should be given IP addresses from a separate IP pool.
In order to save time, ISE is pre-configured with all required configuration for all the lab exercises. This includes the selection of
group policy and IP pool based on AD group membership. Because of this, the name of the new group policy and IP pool
must be exactly the names given in the instructions. If you want to review the ISE configuration, see Appendix C.
Steps
Create a new group policy
You will create a group policy that is essentially the same as DfltGrpPolicy. What you will demonstrate is how ISE can
assign a group policy based on the Active Directory group of the user. Perhaps it would be more interesting to add
specific customizations, but this is not important for this scenario.
1. In the FMC, navigate to Object > Object Management > VPN > Group Policy.
2. Click Add Group Policy.
Cisco dCloud
3. For Name, enter ITGP. This must be the exact group name, because of the ISE configuration.
4. In the General tab, select Banner. Enter the text Welcome IT Member.
5. In the General tab select Split Tunneling.
a. For IPv4 Split Tunneling, select Tunnel networks specified below.
b. Select the Extended Access List radio button.
c. For Access List, select AC-SplitTunnel1.
Cisco dCloud
6. In the General tab select DNS/WINS. For Primary DNS Server, select Inside-DNS.
7. Select the AnyConnect tab. For Client Profile, select AnyConnect-Profile1.
8. Click Save to save the group policy.
Cisco dCloud
Create a new IP pool
1. Create an IP pool.
a. In the FMC, navigate to Objects > Object Management > Address Pools > IPv4 Pools.
b. Click Add IPv4 Pools.
c. For Name, enter AC-IP-Pool-IT. This must be the exact group name, because of the ISE configuration.
d. For IPv4 Address Range, enter 198.19.14.10-198.19.14.50.
e. For Mask, enter 255.255.255.0.
f. Click Save.
Modify the access control and NAT policies
To modify both the access control and NAT policies, all you have to do is modify the AC-NW network group object.
1. In the FMC, navigate to Object > Object Management > Network.
a. Select and edit the network group AC-NW.
b. Under Selected Networks, in the bottom text field, enter 198.19.14.0/24 and click Add.
c. Click Save.
Cisco dCloud
Modify the connection profile
1. In FMC, navigate to Devices > VPN > Remote Access.
2. Edit AnyConnect-VPN. Then select and edit the AC-Default-Profile connection profile.
3. Add the newly created IP pool.
a. The client Address Assignment tab should already be selected.
b. Under Address Pools, click the (+) icon and select IPv4.
c. Select AC-IP-Pool-IT and click Add.
d. Click OK.
e. Click Save on the Edit Connection Profile window.
4. Add the newly create group policy.
a. Select the Advanced tab of the AnyConnect-VPN page, and select Group Policies from the left navigation pane.
b. Click the (+) icon.
c. Select ITGP and click Add.
d. Click OK and then click Save.
Cisco dCloud
Deploy and test the configuration
1. Deploy the changes to the NGFW. Wait for the deployment to complete.
2. Return to the Outside-PC remote desktop session.
a. Click Connect on AnyConnect client.
b. Log in as harry, password C1sco12345. Harry is not a member of the IT group.
c. Once AnyConnect is connected run the following two commands from the Outside-PC command prompt.
i. ping inside.dcloud.local. This should succeed.
ii. ping altinside.dcloud.local. This should fail. The DACL that ISE assigns by default only allows
access to the domain controller and inside Linux server.
Cisco dCloud
3. On the NFGW CLI, run the following command.

Observe below values on the output.
a. Username: harry
b. Assigned IP: 198.19.13.x
c. Group Policy: DfltGrpPolicy
d. Filter Name: #ACSACL#-IP-AC-DACL- Default-x

Session Type: AnyConnect Detailed
Username : harry Index : 53216
Protocol : Clientless SSL-Tunnel DTLS-Tunnel
Encryption : AnyConnect-Parent: (1)none SSL-Tunnel: (1)AES-GCM-256 DTLS-Tunnel: (1)AES256
Hashing : AnyConnect-Parent: (1)none SSL-Tunnel: (1)SHA384 DTLS-Tunnel: (1)SHA1
Bytes Tx : 15410 Bytes Rx : 516
Pkts Tx : 16 Pkts Rx : 8
Pkts Tx Drop : 0 Pkts Rx Drop : 0
Group Policy : DfltGrpPolicy Tunnel Group : AC-Default-Profile
(Output omitted)
Filter Name : #ACSACL#-IP-AC-DACL-Default-598b5954
>
4. Return to the Outside-PC remote desktop session.
a. Disconnect AnyConnect VPN session
b. Start a new the AnyConnect VPN session.
c. Log in as rita, password C1sco12345. Rita is a member of the IT group.
d. Confirm that you see the banner configured in the ITGP and then click Accept.
e. Once AnyConnect is connected run the following two commands from the Outside-PC command prompt.
i. ping inside.dcloud.local. This should succeed.
ii. ping altinside.dcloud.local. This should also succeed. The DACL that ISE assigns to the IT group
allows access to any internal device.
Cisco dCloud

Observe below values on the output.
a. Username: rita
b. Assigned IP: 198.18.14.x
c. Group Policy: ITGP
d. Filter Name: #ACSACL#-IP-AC-DACL-IT-x

Username : rita Index : 4998
Protocol : AnyConnect-Parent SSL-Tunnel DTLS-Tunnel
Encryption : AnyConnect-Parent: (1)none SSL-Tunnel: (1)AES-GCM-256 DTLS-Tunnel: (1)AES256
Hashing : AnyConnect-Parent: (1)none SSL-Tunnel: (1)SHA384 DTLS-Tunnel: (1)SHA1
Bytes Tx : 15375 Bytes Rx : 691
Pkts Tx : 16 Pkts Rx : 9
Pkts Tx Drop : 0 Pkts Rx Drop : 0
Group Policy : ITGP Tunnel Group : AC-Default-Profile (Output omitted)
(Output omitted)
Filter Name : #ACSACL#-IP-AC-DACL-IT-598b1f19
>
6. Disconnect the AnyConnect VPN client.
Cisco dCloud
Scenario 5. AnyConnect with Client Certificates

• Modify the connection profile
In this exercise will help user configure double authentication (certificate and AAA) for the RA VPN.
NOTE: In order to save time, the client certificate is already installed on Outside-PC.
Steps
Modify the connection profile
1. In the FMC, navigate to Devices > VPN > Remote Access. Edit AnyConnect-VPN.
a. Under Connection Profile, select and edit the AC-Default-Profile connection profile.
b. Select the AAA tab and change Authentication Method to Client Certificate & AAA.
c. Click Save on the Edit Connection Profile page.
d. Click Save on the AnyConnect-VPN page.
Cisco dCloud
1. Deploy the changes to the NGFW. Wait for the deployment to complete.
2. Return to the Outside-PC remote desktop
a. Connect the AnyConnect client.
b. Log in as rita, password C1sco12345. The user does not matter for this lab exercise.

Confirm that the Auth Mode is Certificate and userPassword.
(Output omitted)
AnyConnect-Parent:
Tunnel ID : 52614.1
Public IP : 198.18.133.23
Encryption : none Hashing : none
TCP Src Port : 49286 TCP Dst Port : 443
Auth Mode : Certificate and userPassword
(Output omitted)
>
4. Do not disconnect the AnyConnect VPN. Continue immediately to the next lab exercise.
Cisco dCloud
Scenario 6. Monitoring and Troubleshooting

• Monitoring AnyConnect user activity
• Troubleshooting
You will use the FMC for Monitoring AnyConnect User activity and troubleshooting.
Steps
Monitoring AnyConnect user activity
In this section, you can monitor all active users who have logged in through AnyConnect.
1. In the FMC, navigate to Overview > Dashboards > Access Controlled User Statistics
2. Select the VPN tab. Note that there are 7 widgets dedicated to VPN traffic.
3. Navigate to Analysis > Users > Active Sessions.
a. Notice that you see Rita’s VPN session.
b. Check the checkbox to the left of Rita’s session and click Logout. When prompted, click Continue.
You may also see other active sessions discovered with network discovery. For example, you may see guest discovered through
an FTP session. For brevity, those sessions were left out of the figure above. If you want more details about users and how they
were discovered, navigate to Analysis > Users > Users.
4. On Outside-PC, confirm that Rita has been logged out.
5. In the FMC, navigate to Analysis > Users > User Activity. In this window you will see details of current and past user
sessions. Spend a couple minutes reviewing the information on this page.
Troubleshooting
In this section, you will modify the Syslog level for VPN events on the NGFW. You will also run some basic troubleshooting
commands from the NGFW CLI.
1. In the FMC, navigate to Device > VPN > Troubleshooting. You should see records. If you do not, try adjusting the time
window on this page.
Cisco dCloud
2. On the NGFW CLI run some of the following commands to get a rough scope of the troubleshooting capabilities. These are
useful when troubleshooting RA VPN. They are primarily included for your reference.
a. show vpn-sessiondb ?
b. test aaa-server ?
c. debug crypto ca ? (good for trouble-shooting certificate issues)
d. debug crypto ipsec ?
e. debug ldap ?
f. debug aaa ?
Cisco dCloud
Scenario 7. Cisco Threat Intelligence Director (CTID)

• Retrieve a STIX file from a web server
• Analyze a complex indicator and its associated observables
• Upload a list of URLs to CTID that will trigger an Incident
• Subscribe CTID to a TAXII feed
• Generate CTID incidents
The CTID is a component of the FMC that can consume third party cyber threat intelligence indicators; CTID parses these
indicators to produce observables that can be detected by the NGFW. The NGFW reports detection of the observables to CTID.
Then CTID determines whether the observations constitute an incident.
Two file formats are supported.
• Flat files – Lists of simple indictors such as IP addresses, URLs or SHA256 hashes
• STIX files – XML files that can describe simple or complex indicators
There are 3 ways these files can be retrieved
• Uploaded from the computer where the FMC UI is running
• Retrieved from a URL on a remote web server
• Received from a TAXII feed (STIX files only)
The objective of this exercise is to configure and test CTID.
Steps
Confirm that CTID will publish observables to the NGFW
1. Navigate to Policies > Access Control > Access Control.
2. Edit the access control policy by clicking the pencil icon to the right of the policy.
3. Select the Advanced tab.
Cisco dCloud
4. Observe that Enable Threat Intelligence Director is enabled by default.
5. Using this advanced setting, CTID can be enabled or disabled at the access policy level.
6. Navigate to Intelligence > Elements.
7. Confirm that the NGFW is an element. This means that CTID can publish observables to the NGFW.
8. Navigate to Intelligence > Settings. Confirm that the system is configured to publish observables to the CTID elements.
NOTE: Here CTID can be enabled or disabled globally. Clicking Pause will stop CTID publishing to all elements.
Retreive a STIX file from a web server
1. Navigate to Intelligence > Sources > Sources.
2. Click the plus sign (+) on the right to add an intelligence source.
Cisco dCloud
3. For DELIVERY, select URL.
4. For TYPE, confirm that STIX is selected.
5. For URL, enter http://198.19.10.200/files/STIX.xml.
6. For NAME, enter STIX file from webserver. .
7. Click Save.
NOTE: You cannot change the action from Monitor to Block for STIX files. STIX files can represent complex indicators, so it is
impossible for the NGFW, based on an observable, to decide if the criteria of the indicator has been satisfied.
However, even for complex indicators, you can set the action for individual observables to Block.
8. Wait few seconds. Navigate to Intelligence > Sources > Indicators. Confirm that a complex indicator has been added.
9. Click on the name of the indicator Weatherman PUA. Observer the details of the indicator.
10. Click Close to close the Indicator Details page.
11. Navigate to Intelligence > Sources > Observables. Confirm that two SHA-256 and one IPv4 observables have been added.
Cisco dCloud
Upload a list of URLs to CTID that will trigger an Incident
1. Navigate to Intelligence > Sources > Sources. Click the plus sign (+) on the right to add an intelligence source.
2. For DELIVERY, select Upload.
3. For TYPE, select Flat File. The CONTENT drop-down list will appear.
4. For CONTENT, select URL.
5. Click in the FILE area, and select URL_LIST.txt from the Files folder on the Jump desktop.
6. For NAME, enter Local URL list.
7. For ACTION, select Block.
8. Click Save.
9. Wait a few seconds. Navigate to Intelligence > Sources > Indicators. Confirm that two URL indicators have been added.
10. Navigate to Intelligence > Sources > Observables. Confirm that two type URL observables have been added.
Cisco dCloud
Subscribe CTID to a TAXII feed
NOTE: The TAXII feeds used here are from Hail a TAXII. If you have issues with these feeds, you can use Alien Vault. See
Appendix D for details.
1. Navigate to Intelligence > Sources > Sources. Click the plus sign (+) on the right to add an intelligence source.
2. For DELIVERY, select TAXII.
3. For URL, enter http://hailataxii.com/taxii-discovery-service.
4. For USERNAME, enter guest.
5. For PASSWORD, enter guest.
6. For FEEDS, select guest_phishtank_com.
NOTE: It may take several seconds for the FEEDS drop-down list to populate.
7. Confirm that the screen looks like the following figure.
8. Click Save.
9. Wait until the Status column for this source changes to Parsing. Do not wait for the parsing to complete – this would take too
long.
10. Navigate to Intelligence > Sources > Indicators. Confirm that several URL indicators have been added.
11. Navigate to Intelligence > Sources > Observables. Confirm that several URL observables have been added.
Cisco dCloud
Generate CTID incidents
1. There is a daemon on the FMC that synchronizes the observables with the NGFM once every 5 minutes. So it
can take several minutes for the observables to be published to the sensor. In this step, you will see how to confirm
the publication of a particular observable. In the NGFW CLI, perform the following:
a. Type expert to get into expert mode.
b. Type ls -d /var/sf/*download. Note that there are several directories listed.

admin@ngfw:~$ ls -d /var/sf/*download
/var/sf/clamupd_download /var/sf/iprep_download /var/sf/sifile_download
/var/sf/cloud_download /var/sf/sidns_download /var/sf/siurl_download
Four of these (iprep_download, sidns_download, sifile_download and siurl_download) are used by security
intelligence and CTID.
c. Type grep developmentserver /var/sf/*download/*lf

admin@ngfw:~$ grep developmentserver /var/sf/*download/*lf
/var/sf/siurl_download/731625d4-9512-11e7-915c-
7e7252ae92ac.lf:developmentserver.com/misc/Tron.html/
If you do not see this, wait a minute and try again. You must wait for this to be published before you go on. If it
continues to fail, delete the CTID source, and add it back.
d. Type grep 198.18.133.200 /var/sf/*download/*lf

admin@ngfw:~$ grep 198.18.133.200 /var/sf/*download/*lf
/var/sf/iprep_download/730f187a-9512-11e7-915c-7e7252ae92ac.blf:198.18.133.200
If you do not see this, wait a minute and try again. You must wait for this to be published before you go on. If it
continues to fail, delete the CTID source, and add it back.
e. Type exit to exit expert mode.
2. On the Inside Linux server CLI:
a. Run wget -t 1 outside/files/ProjectX.doc. This should succeed.
b. Run wget -t 1 developmentserver.com/misc/Tron.html. This should be blocked.
3. On the FMC, navigate to Intelligence > Incidents. Confirm that there are 2 incidents.
4. Drill down into the incident and observe the details for this incident.
5. Confirm that there is an incident for a URL indicator. Drill down into the incident and observe the details for this incident.
Cisco dCloud
Scenario 8. FlexConfig
• Create a user defined FlexConfig object
• Modify a Text Object used in a system defined FlexConfig object
• Create and configure a FlexConfig policy
• Deploy the changes and test the configuration
FlexConfig is a feature that allows the deployment of configuration directly to the Lina (ASA) configuration in the FTD. This can be
used to deploy features that are not yet available in the FTD. There are two objectives for this lab exercise:
• Configure EIGRP using a user defined FlexConfig object.
• Use a system defined FlexConfig objects to disable SIP inspection.
NOTE: There are separate system defined FlexConfig objects for configuring EIGRP. For configurations that may change over
time, it is better to use these objects. But to demonstrate the simplicity and power of FlexConfig, a user defined FlexConfig object
will be used.
System defined FlexConfig Objects will be used to configure the FTD as a source of NetFlow data.
Create a user defined FlexConfig object
1. In the FMC UI, navigate to Objects > Object Management.
2. At the bottom of the left navigation panel, under FlexConfig, select FlexConfig Object.
3. Click Add FlexConfig Object.
a. For Name, enter myEIGRP.
b. In the main text area, enter the following commands. Note that the netmask is /18, not /24.
router eigrp 10
network 198.18.128.0 255.255.192.0
c. Click Save.
Cisco dCloud
Modify a Text Object for a system defined FlexConfig object
1. You should still be on the Object Management page in the FMC UI.
2. Click on the magnifying glass icon to the right of the Flex Object called Default_Inspect_Protocol_Disable. You cannot edit
this object, but you could copy it if you wanted to.
NOTE: The FlexConfig objects are written in the Apache Velocity language. This language supports loops and if statements.
These begin with a #. This is not a comment. It indicates that the line is not literal text to be included in the output. Comments
begin with ##.
Note that this FlexConfig object loops over a text object called disableInspectProtocolList. You will now edit this text object.
3. Click Close.
4. At the bottom of the left navigation pane of the Object Management page, under FlexConfig, select Text Object.
5. Edit the text object called disableInspectProtocolList.
6. This variable takes multiple values. Leave the value set to 1.
7. Enter the value sip.
8. Click Save.
Create and configure a FlexConfig policy
1. Navigate to Devices > FlexConfig. Click New Policy.
a. For Name, enter NGFW Flex Policy.
b. Select the device NGFW. Click Add to Policy.
c. Click Save.
2. Wait a few seconds for the policy to open for editing.
a. In the left column, under User Defined, select myEIGRP. Click to add the FlexConfig object to the policy.
b. In the left column, under System Defined, select Default_Inspect_Protocol_Disable. Click to add the
FlexConfig object to the policy.
c. Click Save.
3. Click Preview Config.
a. Select NGFW from the Select Device drop-down list.
b. Wait a few seconds and the configuration changes will appear. Confirm that the commands look correct. You will also
see several superfluous VPN commands. This defect has no impact on the configuration, and will be corrected in a
future release.
c. Click Close.
Cisco dCloud
Deploy the changes and test the configuration
1. From the NGFW CLI run show running-config policy-map. Confirm that SIP inspection is enabled.
2. From the Inside Linux Server session, type ping 204.44.14.1. This should fail.
3. Deploy the changes you made. Wait until the deployment is complete.
4. From the NGFW CLI run show running-config policy-map. Confirm that SIP inspection is now disabled.
5. From the NGFW CLI run the following commands.
a. Run show eigrp neighbors. Confirm that an adjacency has been formed between the FTD and CSR router.
b. Run show eigrp topology. Confirm that the EIGRP routes have been received.
c. Run show route eigrp. Confirm that the NGFW now has EIGRP learned routes in its routing table.
6. From the Inside Linux Server session, type ping 204.44.14.1. This should now succeed.
Cisco dCloud
Scenario 9. ASA to NGFW Migration

• Convert an FMC to a migration tool
• Migrate ASA objects
• Migrate NAT and unsupported features, and explore object reuse
The objective of this exercise is to familiarize the student with the migration tool.
• How it is configured
• How it is used
After converting an FMC to a migration tool, two configurations will be migrated. Several aspects of migration will be revealed,
including object flattening and how unsupported features are handled.
Steps
Convert an FMC to a migration tool
1. On the Jump desktop, open the PuTTY link. Double click on the preconfigured session called Migrator. Login as admin,
NOTE: The tool you need to perform the migration is a modified FMC. The modification is accomplished by running a
script. This FMC it typically a virtual FMC, that is separate from the production FMC/ from You should not try to use a
production FMC as a migration tool.
2. Type sudo enableMigrationTool.pl.
a. Enter the password C1sco12345 when prompted.
b. Read the warning – yes really read it!
c. Enter Y when asked if you want to continue.
d. Wait for the script to complete. This will take less than a minute.
3. On the Firefox browser, open a new tab.
a. Click on the bookmark bar link Migration Tool. Click Advanced, and Add Exception. When prompted, click
Confirm Security Acceptation.
NOTE: This FMC, which will be used as a migration tool, was not modified after installation. The FMC you have been using up to
now was preconfigure. This pre-configuration included adding a trusted certificate. See Appendix A for details.
b. Login as admin, password C1sco12345.
Cisco dCloud
c. Confirm that you see the banner in red at the top of the UI that reads:
MIGRATION TOOL INSTALLED / You are limited to ASA conversions only
Migrate ASA objects
The goals of this exercise are the following.
• Learn the migration process.
• Understand how network and service objects and object groups migrate.
1. In the Jump, in the Files folder, open the file ASA_config_1.txt.
a. Observer that there are nested network and service objects.
b. Observer that there is an access list and access group that reference these objects. Without the access group, the
objects would not migrate, since they would have no effect on the policy configuration.
2. In the Migrator UI (not the FMC), navigate to System > Tools > Import/Export.
a. Click Upload Package.
b. Click Browse, and select the file ASA_config_1.txt from the Files folder.
c. Click Upload.
3. On the next page, leave all the settings unchanged, as below, and click OK.
Cisco dCloud
4. Wait until you are back to the Upload page.
a. Click on the icon to the right of the Deploy button
b. Click on the Task tab and wait for the tasks to compete.
a. Click on the text Click to download the FMC import file(.sfo) and save the SFO file.
b. Click on the text Click and select the default Open with Google Chrome to open the migration report in a new tab.
Confirm that the conversion report contains no errors. Close Chrome.
5. In the (production) FMC UI, navigate to System > Tools > Import/Export.
b. Click on Browse, and select the SFO file from the Downloads folder. It will have a name of the form
ExportForMigration-<some UUID>.sfo. Click Open.
c. Click Upload.
Cisco dCloud
6. On the next page, click Import.
7. Wait for the import to complete.
a. The Network object page will be selected. Notice the objects that were created.
• Four network objects net1, net2, net3 and net4
• Two network groups net12 and net34
• One nested network group net1234
NOTE: These are exactly the network objects and network-group object that existed in the ASA configuration.
b. In the left navigation pane, select Port. Notice the objects that were created.
• Four port objects p1_dst_1, p1_dst_2, p2_dst_1 and p2_dst_2
• Zero port groups
NOTE: The ASA port groups, p1 and p2, have been flattened, and there is no p12.
9. Navigate to Policies > Access Control > Prefilter.
a. Notice that there is a new prefilter policy. Edit it so you can inspect the rules.
b. Notice that this single ACE is the ASA configuration is now 2 separate prefilter rules.
10. Navigate to Policies > Access Control > Access Control.
a. Notice that there is a new access control policy. Edit it so you can inspect it.
b. Notice that there are no rules and that the default action is set to block.
c. Notice that the prefilter policy is set to the prefilter policy inspected in the previous step.
Cisco dCloud
Migrate NAT and unsupported features, and explore object reuse
There are three separate goals in this task. They are not directly related. They have been bundled for expedience.
• Migrate a NAT policy.
• Understand object reuse.
• Try to migrate a time-based ACL, and see how the unsupported feature is treated.
1. In the Jump, in the Files folder, open the file ASA_config_2.txt.
a. Observe that two network objects in the ASA configuration already exist in the FMC.
• The network object net1, which has a different definition than the existing object of the same name
• The network object net2, which has the same definition as the existing object with the same name
b. Observer that there is a static NAT rule
c. Observe that there is a time-based ACL. This feature is not currently supported.
2. In the Migrator UI (not the FMC), navigate to System > Tools > Import/Export.
b. Click Browse, and select the file ASA_config_2.txt from the Files folder. Click Open.
c. Click Upload.
3. On the next page, select the Access Control Policy and Allow radio buttons, as below. Click OK.
Cisco dCloud
4. You will be back to the upload page.
a. Click on the icon to the right of the Deploy button.
b. Click on the Task tab and wait for the tasks to compete.
c. Click on the text Click to download the FMC import file(.sfo) and save the SFO file.
d. Click on the text Click and select the default Open with Google Chrome to open the migration report in a new tab.
Observe that this migration report warns that the time-based ACL was not supported. Close Chrome.
Cisco dCloud
5. In the (production) FMC UI, navigate to System > Tools > Import/Export.
a. Click the Upload Package button.
b. Click on Browse, and select the SFO from the Downloads folder. It will have a name of the form
ExportForMigration-<some UUID>.sfo. Be sure to select the more recently created SFO file.
c. Click Upload.
6. On the next page, click Import.
7. On the next page perform the following sub-steps. See the following figure.
a. Read the information about object conflict resolution
b. Create two interface groups using the drop-down lists on this page. Interfaces references in migrated NAT rules must
be placed in interface groups. Security zones are not allowed. You could call them IF1 and IF2
c. Click Import.
Cisco dCloud
8. Navigate to Objects > Object Management. The Network object page will be selected.
a. Notice the object net1_1 was created. This is because the definition of net1 was different in the two migrated ASA
configurations. Therefore the object is renamed.
b. Notice the object net2_1 was not created. This is because the definition of net2 was the same in the two migrated
ASA configurations. Therefore the object is reused.
NOTE: This behavior changed in the Firepower 6.2.1 release. In Firepower 6.2, both objects are renamed.
a. Notice that there is a new NAT policy. Edit it so you can inspect the rules.
b. Notice that the objects net1_1 and net2 are referenced in this policy.
10. Navigate to Navigate to Policies > Access Control > Access Control.
a. Notice that there is a new access control policy. Edit it so you can inspect the rules.
b. The ACL from the original ASA configuration was the following:
access-list timeacl extended permit ip any host 1.2.3.4 time-range office_hours
Note that this was converted into an access control policy rule with the same source and destination. But there is no
time range attribute in the access control policy rule.
Cisco dCloud
c. Notice that the rule is disabled. If you wish, you can enable the rule.
NOTE: The migration tool was presented with an ACL that included both network and time-based criteria. Because time based
ACLs are currently not supported, the migrated rule could only include the network criteria. Since this may not be acceptable, the
rule is disabled, and must be enabled manually.
Cisco dCloud
Scenario 10. NAT and Routing

• Create objects needed for this lab exercise
• Configure static NAT
• Modify access control policy to allow outside access to wwwin
• Configure BGP
There are two objectives for this lab exercise:
• Create a public web server
• Configure BGP
The first objective will involve creating network objects, creating access control lists. Also, static NAT and dynamic routing will be
configured.
Steps
Create objects needed for this lab exercise
b. For Name, enter wwwin.
c. For Network, enter 198.19.10.202.
d. Click Save.
e. Click Add Network > Add Object.
f. For Name, enter wwwout.
g. For Network, enter 198.18.128.202.
h. Click Save.
i. Click Add Network > Add Object.
j. For Name, enter 203.14.10.0.
k. For Network, enter 203.14.10.0/24.
l. Click Save.
Cisco dCloud
2. Select Access List > Standard from the left navigation pane.
a. Click Add Standard Access List.
b. For Name, enter Filter203.
c. Add the 2 access control entries shown below. The second entry is critical, because of an implicit deny all at the end
of the list.
d. Click Save.
Configure static NAT
2. Click the pencil icon to edit the Default PAT policy. Confirm that you see the grayed out Save button at the top right. If
you do not, navigate away and try editing again. This is a known bug.
3. Click Add Rule.
a. Select Auto NAT Rule from the Type drop-down list.
b. You will be at the Interface Objects tab. Select InZone, and click Add to Source.
If you performed the migration scenario, you will also have the choice of two interface groups. You can ignore them.
c. Select OutZone, and click Add to Destination.
Cisco dCloud
d. Select the Translation tab.
e. Select wwwin from the Original Source drop-down list.
f. Select Address and wwwout from the Translated Source drop-down list.
g. Click OK to save the NAT rule.
Cisco dCloud
Modify access control policy to allow outside access to wwwin
1. Navigate to Policies > Access Control > Access Control. Edit the NGFW Access Control Policy.
2. Click Add Rule.
a. For Name, enter Web Server Access.
b. Select into Default from the Insert drop-down list.
c. The Zones tab should already be selected. Select InZone, and click Add to Destination.
d. Select OutZone, and click Add to Source.
e. Select the Networks tab.
f. Select wwwin, and click Add to Destination.
NOTE: Note that we use the true IP of the webserver, instead of the NAT’ed address that the client will connect to.
g. Select the Ports tab.
h. Select HTTP and HTTPS, and click Add to Destination.
i. Select the Inspection tab.
j. Select Demo Intrusion Policy from the Intrusion Policy drop-down list.
k. Select Demo File Policy from the File Policy drop-down list.
l. Click Add to add the rule.
3. Click Save to save the access control policy changes.
Configure BGP
1. Navigate to Devices > Device Management.
2. Click on the pencil icon to edit the device settings for the device NGFW.
3. Select the Routing tab.
a. Select BGP, and check the Enable BGP checkbox.
b. Set the AS Number to 10.
c. Expand BGP in the left navigation pane and select IPv4.
d. Check the Enable IPv4 checkbox.
e. Click on the Neighbor tab and click on Add.
i. For IP Address, enter 198.18.133.3.
ii. For Remote AS, enter 20.
iii. Check the Enable address checkbox.
iv. Select Filter203 from the Incoming Access List drop-down list.
v. Click OK to add the neighbor.
Cisco dCloud
f. Click Save to save the BGP configuration.
1. Deploy the changes, and wait until the deployment is complete.
2. On the Jump desktop, open the PuTTY link. Double click on the preconfigured session called Outside Linux Server. Login as
root, password C1sco12345.
a. Type curl wwwout. This should succeed.
b. Type ssh wwwout. This should fail.
3. On the Jump desktop, open the PuTTY link. Double click on the preconfigured session called CSR. Login as admin, password
C1sco12345.
Cisco dCloud
4. On the CSR CLI, run the command show bgp, and confirm that 4 routes appear.
5. From the NGFW CLI:
a. Run show route. Confirm that the only routes learned from BGP were 62.24.45.0/24 and 62.112.24.0/24. Note that
203.14.10.0/24 was successfully filtered out of BGP. However, if you performed the FlexConfig scenario, you will see
this route as an external EIGRP route.
b. Run show bgp and show bgp rib-failure. This shows that the 198.18.128.0/18 route was not inserted in the
routing table because there was a better route (connected).
NOTE: You can also run this command from the FMC.
1. Navigate to Device > Device Management.
2. Edit the NGFW device and select the Devices tab
3. In the Health section, click the icon to the right of Status.
4. Click Advanced Troubleshooting.
4. Select the Threat Defense CLI tab.
From here you can run several NGFW CLI commands.
6. From the Inside Linux server session, type ping 62.24.45.1. This should succeed.
Cisco dCloud
Scenario 11. Site-to-Site VPN

• Create objects needed for this lab exercise
• Configure site-to-site VPN
• Create NAT exemption
• Modify the access control policy and deploy changes
The objective of this exercise is to configure a site-to-site VPN tunnel between the NGFW and an ASA.
Steps
Create objects needed for this lab exercise
b. For Name, enter MainOfficeNetwork.
c. For Network, enter 198.19.10.0/24.
d. Click Save.
e. Click Add Network > Add Object.
f. For Name, enter BranchOfficeNetwork.
g. For Network, enter 198.19.11.0/24.
h. Click Save.
Configure site-to-site VPN
1. Navigate to Devices > VPN> Site To Site. Click Add VPN > Firepower Threat Defense Device.
NOTE: The other VPN choice, Firepower Device, is for configuring secure tunnels between Firepower devices.
2. For Name enter NGFWtoASA.
Cisco dCloud
3. Confirm that for Network Topology, Point to Point is selected. Confirm that for IKE Version, IKEv1 is not checked, and IKEv2 is
checked.
4. Click the green plus to the right of Node A. Fill out as in the figure below, and then click OK.
Cisco dCloud
5. Click the green plus to the right of Node B. Fill out as in the figure below, and then click OK.
6. Select the IKE tab.
a. Under IKEv2 Settings, for Policy, select DES-SHA-SHA.
b. Under IKEv2 Settings, for Authentication Type, select Pre-shared Manual Key.
NOTE: The Automatic setting can only be used if the FMC is managing both endpoints. In this case, the FMC can generate a
random shared key.
c. Under IKEv2 Settings, for Key, enter C1sco12345, and confirm the entry.
Cisco dCloud
7. Select the IPsec tab, change the IKEv2 IPsec Proposal to DES_SHA-1.
8. Click Save to save the VPN settings.
Create NAT exemption
2. Click the pencil icon to edit the Default PAT policy.
3. Click Add Rule.
a. Leave In Category and NAT Rules Before from the NAT Rule drop-down list selected.
b. You will be at the Interface Objects tab.
Cisco dCloud
c. Select the Translation tab.
i. Select MainOfficeNetwork from the Original Source drop-down list.
ii. Select MainOfficeNetwork from the Translated Source drop-down list.
iii. Select BranchOfficeNetwork from the Original Destination drop-down list.
iv. Select BranchOfficeNetwork from the Translated Destination drop-down list.
d. Select the Advanced tab, and check the Do not proxy ARP on Destination Interface checkbox.
e. Click OK to save the NAT rule.
Cisco dCloud
Modify the access control policy and deploy changes
You will now create a rule to allow traffic between the Branch office and Main office.
2. Click Add Rule.
a. Call the rule VPN Access.
b. Select into Default from the Insert drop-down list. This will become the last rule in the access control policy.
c. Leave the action to Allow.
d. The Zones tab should already be selected.
e. Select OutZone, and click Add to Source.
f. Select InZone and click Add to Destination.
g. Select the Networks tab, select BranchOfficeNetwork, and click Add to Source.
h. Select the Networks tab, select MainOfficeNetwork, and click Add to Destination.
i. Select the Inspection tab.
j. Click Add to add this rule to the access control policy.
3. Click Save to save the access control policy.
1. Deploy the changes and wait for the deployment to complete.
2. From the NGFW CLI, type show crypto ipsec sa. There should be no IPSec security associations.
3. From the Inside Linux server CLI, type ping branch. Wait a few seconds, and the ping should succeed.
4. From the NGFW CLI, type show crypto ipsec sa. There should now be an IPSec security association.
5. On the Jump desktop, open the PuTTY link. Double click on the preconfigured session called Branch Linux Server.
a. Login as root, password C1sco12345.
b. Type curl inside. This should succeed.
Cisco dCloud
Scenario 12. Web Proxy Integration

• Modify the WSA configuration
• Configure the use of XFF type headers
• Deploy access control policy
The NGFW can use of XFF type headers to enforce the policy on the true client, instead of the proxy server. The objective of this
exercise is to familiarize the student with the True-Client-IP feature. This feature allows the NGFW to enforce policies for endpoint
passing traffic through a web proxy.
Note that the rule you configure is artificial, but makes testing easy
Steps
Modify the WSA configuration
1. On the Jump desktop, open the PuTTY link. Double click on the preconfigured session called WSA. Login as admin,
2. Perform the following CLI commands on the WSA CLI

wsa.dcloud.local> setgateway
Warning: setting an incorrect default gateway may cause the current connection to be
interrupted when the changes are committed.
Set the default gateway for:
1. IPv4
2. IPv6
[1]> 1
Enter new default gateway:

[198.19.10.11]> 198.19.10.1
wsa.dcloud.local> commit
Please enter some comments describing your changes:

[]> Changing gateway
Changes committed: Mon Oct 02 00:01:11 2017 GMT

wsa.dcloud.local>
Cisco dCloud
3. Confirm that the WSA is configured to generate X-Forwarded-For headers. Note that this is not the default.
a. On the Firefox browser, open a new tab.
b. Click on the bookmark bar link WSA. Log as admin, password C1sco12345 (these credentials should prepopulate).
c. In the WSA UI, navigate to Security Services > Web Proxy.
d. Under Advanced Settings, for Generate Headers, confirm the X_Forwarded-For header is being sent.
Configure the use of XFF type headers
1. On the FMC tab, navigate to Policies > Access Control > Access Control. Edit the NGFW Access Control Policy.
2. Click Add Rule.
a. Call the rule Test XFF Feature.
b. Set the Action to Block with reset.
c. Select into Mandatory from the Insert drop-down list.
d. In the Zones tab, select InZone and click Add to Source.
e. In the Zones tab, select OutZone, and click Add to Destination.
f. Select Networks tab.
i. In the Source Networks area, select the Source subtab. At the bottom of the page, enter 198.19.10.101
and click Add. This is the IP address of the WSA proxy server.
ii. In the Source Networks area, select the Original Client subtab. At the bottom of the page, enter
198.19.10.201 and click Add.
iii. In the Destination Networks area, at the bottom of the page, enter 198.18.133.201 and click Add.
g. Select Logging tab. Check the Log at Beginning of Connection checkbox.
h. Click Add to add the rule to the policy.
i. Click Save to save the policy changes.
Cisco dCloud
1. Deploy the changes and wait for the deployment to complete.
2. Go back to the Inside Linux server PuTTY session. Run the following commands to test the configuration.
a. Run the (single-line) command:

wget --bind-address=198.19.10.201 -e use_proxy=yes -e http_proxy=198.19.10.101
198.18.133.201
You should get a 403 (forbidden) response code.
b. Run the (single-line) command:

wget --bind-address=198.19.10.200 -e use_proxy=yes -e http_proxy=198.19.10.101
198.18.133.201
It should succeed.
NOTE: Now that the file is cached on the WSA, if you repeat Step 2a, the file will be downloaded. To avoid this in production, you
would have to deploy the NGFW between the clients and the WSA. For testing, you can clear the WSA proxy cache from the WSA
CLI by typing diagnostic, then PROXY, then CACHE.
3. In the FMC, navigate to Analysis > Connections > Events.
a. Click on the text Table View of Connection Events.
b. The Original Client IP column is not displayed by default. You will add this now.
c. To add this, perform the following steps.
i. Click on the X at the top of any column that is not being used.
ii. Scroll down the column selector to Disabled Columns.
iii. Check the checkbox for Original Client IP.
iv. Scroll down to the bottom of the column selector and click Apply.
d. Confirm that both the WSA IP (198.19.10.101) and the client IP (198.19.10.201) are displayed.
Cisco dCloud
Scenario 13. Prefilter Policies

• Investigate NGFW default behavior for tunneled traffic
• Create a tunnel zone
• Create a prefilter policy
Prefilter policies have two types of rules (prefilter and tunnel). Prefilter rules are more commonly used. They specify what traffic
should be dropped in the Lina dataplane, which traffic should bypass Snort, and which traffic should be sent to Snort. This can
help with performance. You will configure a prefilter rule later in this Scenario, but the focus of this Scenario will be on tunnel rules
since they are more subtle.
If there is a clear-text tunnel the NGFW access control policies apply to the tunneled traffic. Prefilter policies give control over the
tunneling protocol. The following tunneling protocols are supported.
• GRE
• IP-in-IP
• IPv6-in-IP
• Teredo
Prefilter policies communicate with access control policies via tunnel tags. The prefilter policy assigns tunnel tags to specified
tunnels. The access control policy can then include rules that only apply to traffic tunneled through those specified tunnel.
In this exercise you will create a GRE tunnel between the inside and outside CentOS servers.
You will then configure the NGFW to block ICMP through this GRE tunnel.
NOTE: This exercise has Scenario 10 as a prerequisite. This is because the exercise assumes the static NAT rule, which
translates 198.19.10.202 to 198.18.128.202. To understand the configuration of the tunnel interface, you can inspect
/etc/sysconfig/network-scripts/ifcfg-tun0 on the inside and outside servers.
Cisco dCloud
Steps
Investigate NGFW default behavior for tunneled traffic
In this task, you will confirm that the access control policy rules apply the tunneled traffic.
1. You should still have the SSH session open to the Inside Linux server.
2. If you do not have an SSH session to the Outside Linux Server, from the Jump desktop, launch PuTTY and double-click on the
pre-definite Outside Linux Server session. Login as root, password C1sco12345.
3. Create a GRE tunnel between the Inside Linux server and Outside Linux server.
a. On the Outside Linux Server CLI, type ifup tun0.
b. On the Inside Linux Server CLI, type ifup tun0.
c. On the Inside Linux Server, confirm that you can ping through the tunnel with the following command.
ping 10.3.0.2
4. Test the IPS capabilities.
a. Run the following command from the Inside Linux Server CLI.
ftp 10.3.0.2
b. Login as guest, password C1sco12345.
c. Type cd ~root. You should see the following message:

421 Service not available, remote server has closed connection
d. Type quit to exit FTP.
a. Click the arrow on the left to drill down to the table view of the events.
b. Observe that the source and destination IPs are 10.3.0.1 and 10.3.0.2, respectively.
6. Test the file and malware blocking capabilities by running the following commands on the Inside Linux server CLI.
NOTE: These Wget commands can be cut and pasted from the file on the Jump desktop called Strings to cut and paste.txt.

wget -t 1 10.3.0.2/files/ProjectX.pdf
This should succeed..
b. Next use WGET to download the file blocked by type.

wget -t 1 10.3.0.2/files/test3.avi
block of data.
c. Finally use WGET to download malware.

wget -t 1 10.3.0.2/files/Zombies.pdf
Note that about 99% of the file is downloaded. This is because the NGFW needs the entire file to calculate the SHA.
The NGFW holds onto the last block of data until the hash is calculated and looked up.
Cisco dCloud
7. In the FMC, navigate to Analysis > Files > File Events.
a. Click Table View of File Events.
b. Observe that the sending and receiving IPs are 10.3.0.2 and 10.3.0.1, respectively.
Create a tunnel zone
a. Select Tunnel Zone from the left navigation pane.
b. Click Add Tunnel Zone.
c. For Name, enter GRE.
d. Click Save.
Create a prefilter policy
1. Navigate to Policies > Access Control > Prefilter.
2. Click New Policy. Enter a name like NGFW Prefilter Policy. Click Save.
3. Wait a few seconds for the policy to open up for editing
4. Click Add Tunnel Rule.
a. For Name, enter Handle GRE Traffic.
b. Select GRE from the Assign Tunnel Zone drop-down list.
c. Select the Encapsulation & Ports tab and check the GRE checkbox.
Cisco dCloud
NOTE: There are 3 actions

• Analyze – traffic will be passed to Snort, and access policy rules will apply
• Block – traffic is blocked
• Fastpath – traffic is allowed, and bypasses any further inspection
You can also create prefilter rules for this policy. This gives you the ability to analyze, block or fast path traffic based on layer 2
through 4 information.
d. Click Add to add the rule.
5. You will now add a rule that will bypass Snort for any traffic with destination 198.18.133.202. You are trusting this address.
Click Add Prefilter Rule.
a. For Name, enter Example of Fastpath.
b. Select Fastpath from the Action drop-down list.
c. Select the Networks tab.
d. At the bottom of the Destination Networks column enter 198.18.133.202.
e. Click Add to add the destination network.
6. Click Add to add the prefilter rule.
7. Click Save to save the prefilter policy.
2. Click on the link Default Prefilter Policy to the right of the string Prefilter Policy above the policy rules. Select NGFW
Prefilter Policy. Click OK.
3. Select the Rules tab.
4. Click Add Rule.
a. Call the rule Block ICMP Over GRE.
b. Select into Mandatory from the Insert drop-down list.
c. Set the action to Block with reset.
d. In the Available Zones column, select GRE and click Add to Source.
e. In the Applications column, select ICMP and click Add to Rule.
f. Select the Logging tab. Check the Log at Beginning of Connection checkbox.
g. Click Add to add the rule to the policy.
5. Click Add Rule.
a. Call the rule Allow GRE Traffic.
b. Select into Default from the Insert drop-down list. This will become the last rule in the access control policy.
c. In the Available Zones column, select GRE and click Add to Source.
d. Select the Inspection tab.
Cisco dCloud
e. Click Add to add the rule to the policy.
6. Click Save to save the access control policy.
1. Deploy the changes, as you have been. Wait for the deployment to complete.
2. On the Outside Linux Server, run tcpdump -n -i tun0 to monitor tunnel traffic.
3. Run the following commands on the Inside Linux Server CLI.
a. wget 10.3.0.2
b. ping 10.3.0.2
You should see the following output, indicating that the ping is being blocked.
From 10.3.0.2 icmp_seq=1 Packet filtered
4. Inspect the output of the tcpdump command on the Outside Linux Server to confirm that the ping is not making it to 10.3.0.2.
5. Tear down tunnel:
a. On the Outside Linux Server CLI, type ifdown tun0.
b. On the Inside Linux Server CLI, type ifdown tun0.
6. Now test the prefilter rule.

a. Type
This should be blocked.
b. Type
This should be allowed, since the traffic bypassed Snort.
Cisco dCloud
Scenario 14. Integrate Routing and Bridging (IRB)

• Create the objects needed for this lab exercise
• Modify the NGFW interface configuration
• Modify the NAT policy
In the lab, there is a Linux server on separate VLAN that is connected to GigabitEthernet0/2. The FQDN for this server
isolated.dcloud.local, and it has the IP address of 198.19.10.220/24. Note that this is address is in the same subnet as the inside
network.
The objective is to join these VLANs using a bridge-group on the NGFW. Traffic between these VLANs will be inspected.
NOTE: In this exercise, both interfaces in the bridge group are put in the same security zone. However this is not required. A
bridge group can contain interfaces in different security zones. This allows more granular control of traffic between interfaces in the
same bridge group.
Steps
Create the object needed for this lab exercise
1. Navigate to Objects > Object Management. Select Interface from the left navigation panel.
2. Click Add > Security Zone.
a. For Name, enter BVIZone.
b. Select Switched from the Interface Type drop-down menu.
c. Click Save.
Modify the NGFW interface configuration
1. Navigate to Devices > Device Management.
2. Click on the pencil icon to edit the NGFW device configuration, and select the Interfaces tab.
3. Click on the pencil icon to edit the GigabitEthernet0/1 interface.
4. Remove the IPv4 address and click OK. This IP must be removed, so it can be used on another interface.
5. Click Add Interfaces, and select Bridge Group Interface.
a. For Name enter InsideBVI.
Cisco dCloud
b. For Bridge Group ID, enter 1.
c. Select GigabitEthernet0/1 and GigabitEthernet0/2, and click Add.
d. Select the IPv4 tab, and enter the IP address 198.19.10.1/24.
e. Click OK. When presented with the confirmation request, read the message, and then click Yes.
a. For Name enter inside1.
b. Confirm that the Enabled checkbox is checked.
c. Select BVIZone from the Security Zone drop-down list.
d. Click OK.
Cisco dCloud
a. For Name enter inside2.
b. Check the Enabled checkbox.
c. Select BVIZone from the Security Zone drop-down list.
d. Click OK.
8. Click Save to save the device configuration.
Modify the NAT policy
1. If you performed scenario 10, and you want the static NAT rule to work with the BVI interfaces, you must include this step.
This is because object NAT does not allow interface objects with more than one interface.
a. Navigate to Objects > Object Management. Select Interface from the left navigation panel.
b. Click Add > Interface Group.
i. For NAME, enter InGroup1.
ii. For Interface Type, Select Switched.
iii. Select the interface inside1, and click Add.
iv. Click Save.
3. Edit the Default PAT policy. Confirm that you see the grayed out Save button at the top right. If you do not, navigate away and
try editing again.
a. If you did the static NAT configuration in Scenario 10, replace InZone with InGroup1 in the auto NAT rule. You
cannot use BVIZone, because auto NAT does not allow security zones with more than one interface. A workaround
would be to create ain interface group.
b. Replace InZone with BVIZone in every other rule.
c. Your NAT policy should look something like the following. You may have more or fewer rules, depending on what
scenarios you performed.
d. Click Save to save the NAT policy.
Cisco dCloud
1. Navigate to Policies > Access Control > Access Control, and edit the access control policy.
2. Click on the pencil icon to edit the NGFW device configuration, and select the Interfaces tab.
a. Replace InZone with BVIZone in every rule.
b. Add an access control rule to allow (but inspect) traffic between interfaces in BVIZone.
i. For Name, enter Allow Internal Traffic.
ii. Select into Default rule from the Insert drop-down list
iii. The Zones tab should already be selected.
iv. Select BVIZone, and click Add to Source.
v. Select BVIZone, and click Add to Destination.
vi. Select the Inspection tab.
vii. Select Demo Intrusion Policy from the Intrusion Policy drop-down list.
viii. Select Demo File Policy from the File Policy drop-down list.
ix. Click Add to add the rule.
c. Your access control policy should look something like the following. You may have more or fewer rules, depending on
what scenarios you performed.
d. Click Save to save the changes to the access control policy.
1. Deploy the configuration changes, and wait for the deployment to complete.
2. From the Inside Linux Server CLI, test connectivity by typing ping isolated. This should succeed.
3. From the Inside Linux Server CLI, test the IPS capabilities.
a. Run the following command from the Inside Linux server CLI.
ftp isolated
b. Login as guest, password C1sco12345.
c. Type cd ~root. You should see the following message:

421 Service not available, remote server has closed connection
Cisco dCloud
4. From the Inside Linux server CLI, test the file and malware blocking capabilities.

wget -t 1 isolated/files/ProjectX.pdf
b. Next use WGET to attempt to download the file blocked by type.

wget -t 1 isolated/files/test3.avi
block of data. The Demo File Policy is configured to block AVI files.
c. Finally use WGET to attempt to download malware.

wget -t 1 isolated/files/Zombies.pdf
NOTE: About 99% of the file is downloaded. This is because the NGFW needs the entire file to calculate the SHA. The NGFW
holds onto the last block of data until the hash is calculated and looked up. The Demo File Policy is configured to block malware
detected in PDF files.
Cisco dCloud
Appendix A. FMC Pre-configuration

After the initial installation, several configuration steps were performed on the FMC to expedite the lab exercises. These
configuration steps are detailed in this appendix.
• Configuration A1,1: NTP settings
• Configuration A1,2: Demo file policy
• Configuration A1,3: Demo intrusion policy
• Configuration A1,4: Demo SSL policy
• Configuration A1,5: Custom detection list
• Configuration A1,6: Add resetapiuser.
• Configuration A1,7: Install server certificate
Configuration A1,1: NTP settings
1. Configure NTP settings on the FMC.
a. In the FMC, navigate to System > Configuration.
b. Select Time Synchronization from the left-side navigation pane.
c. Replace the default NTP server with 198.18.128.1.
d. Click Save.
Cisco dCloud
Configuration A1,2: Demo file policy
1. Navigate to Policies > Access Control > Malware & File.
2. Click New File Policy. Enter a name Demo File Policy. Click Save.
3. Click Add File Rule. This rule will block malware found in files MSEXE, MSOLE2, NEW_OFFICE and PDFs.
a. For Action select Block Malware.
b. Check the Spero and Local Malware Analysis checkboxes.
c. Under File Type Categories, check Dynamic Analysis Capable. Note that several file types belong to this category.
Click Add.
d. Your screen should look like the figure below.
e. Click Save. Ignore the warning and click OK, when prompted.
4. Click Add File Rule. This rule will block RIFF files. You will use an AVI file to test this rule, since an AVI file is a type of RIFF
file. But note that AVI is not listed separately as a file type.
a. For Action select Block Files.
b. Under File Types, type rif into the search box. Select RIFF from the list. Click Add.
c. Use default values for other settings. Your screen should look like the figure below.
d. Click Save.
Cisco dCloud
NOTE: Note that you cannot change the order of the rules you create. The order of the rules does not matter. The action of the rule
determines its precedence. The precedence of actions is as follows.
1. Block Files
2 Block Malware
3. Malware Cloud Lookup
4. Detect Files
5. Select the Advanced tab. Confirm that Enable Custom Detection List is selected. Check the Inspect Archives checkbox.
NOTE: Archives unable to be inspected are corrupt archive, or archives with a depth that exceeds the Max Archive Depth.
6. Click the Save button in the upper-right to save the file policy.
Cisco dCloud
Configuration A1,3: Demo intrusion policy
1. Navigate to Objects > Intrusion Rules. Click Import Rules.
a. Select the Rule update or text rule file to upload and install radio button.
b. Click Browse, and open the Snort_Rules.txt file in the Files folder of the Jump desktop.
NOTE: This file contains 2 simple Snort rules that are useful for testing IPS. They do not resemble published snort rules.
alert tcp any any -> any any (msg:"ProjectQ replaced"; content:"ProjectQ";
replace:"ProjectR"; sid: 1001001; rev:1;)
alert tcp any any -> any any (msg:"ProjectZ detected"; content:"ProjectZ";
sid: 1001002; rev:1;)
The first rule replaces the string ProjectQ with ProjectR. The second detects the string ProjectZ. Since the rules do not specify
where the string is in the flow, they could cause issues in a production deployment.
c. Click Import. The import process will take a minute or two. When it completes you will see the Rule Update Import
Log page. Confirm that 2 rules were successfully imported.
2. Navigate to Policies > Access Control > Intrusion.
3. Click Create Policy.
a. Set Name to Demo Intrusion Policy.
b. Make sure that Drop when Inline is checked.
c. Select Balanced Security and Connectivity as Base Policy.
d. Click Create and Edit Policy.
4. You will now modify the rules states for this new policy.
a. Click Rules under Policy Information menu on the left-hand side of the Edit Policy page.
b. Select local from the Category section of the rules. You should see the 2 uploaded rules. The light green arrows on
the right of each rule indicate that the rules are disabled for this policy.
Cisco dCloud
c. Check the checkbox next to the first rule. Select Generate Events from the Rule State drop-down menu. Click OK.
Uncheck the checkbox next to the first rule.
d. Check the checkbox next to the second rule. Select Drop and Generate Events from the Rule State drop-down
menu. Click OK.
e. Clear the filter by clicking on the X on the right side of the Filter text field.
f. Select SID from the Rule Content section of the rules. Enter 336 into the Enter the SID filter popup. Click OK.
g. Check the checkbox next to the rule. Select Drop and Generate Events from the Rule State drop-down menu. Click
OK.
NOTE: This rule looks for a change to the root home directory in FTP traffic established on port 21. It only looks for traffic coming
from the external network, but in our lab we use the default value of $EXTERNAL_NET, which is any, so the rule can be triggered
in both directions.
An interesting exercise would be to modify this rule to search in FTP traffic in any direction, and to use the appid attribute to detect
FTP traffic on any port.
5. Click Policy Information in the menu on the upper-left.
6. Click Commit Changes. Click OK.
Cisco dCloud
Configuration A1,4: Demo SSL policy
1. Navigate to Objects > Object Management > PKI > Internal CAs.
a. Click Import CA.
b. For Name, enter Verifraud.
c. Click the Browse button to the right of the text Certificate Data or, choose a file.
d. Browse to the Certificates folder on the Jump desktop.
e. Upload Verifraud_CA.cer.
f. Click the Browse button to the right of the text Key or, choose a file.
g. Upload Verifraud_CA.key.
h. Click Save.
2. You will exempt from decryption infrastructure devices, such as the FMC and AMP Private Cloud. To do this, create a network
object that includes these devices.
a. Navigate to Objects > Object Management > Network.
b. Click Add Network > Add Object.
c. For Name, enter Infrastructure.
d. For Network, enter 198.19.10.80-198.19.10.130.
e. Click Save to save the network object.
3. Navigate to Policies > Access Control > SSL.
4. Click the text Add a new policy or click the New Policy button.
a. For Name, enter Demo SSL Policy.
b. Leave the default action to Do not decrypt.
c. Click Save. Wait a few seconds, and the policy will open for editing.
Cisco dCloud
5. Click Add Rule.
a. For Name, enter Exempt Infrastructure.
b. Leave Action set to Do Not decrypt.
c. In the Networks tab, under Networks, select Infrastructure, and click Add to Source.
d. Click Add to add this rule to the SSL policy.
6. Click Add Rule.
a. For Name, enter Decrypt Search Engines.
b. Set Action to Decrypt – Resign.
c. Select Verifraud from the drop-down list to the right of the word with.
d. In the Applications tab, under Application Filters, search for Sear. You will see Search Engine under Categories.
Check this checkbox, and click Add to Rule.
e. Select the Logging tab, and check the Log at End of Connection checkbox.
f. Click Add to add this rule to the SSL policy.
7. Click Add Rule.
a. For Name, enter Decrypt Other.
b. Set Action to Decrypt – Resign.
c. Select Verifraud from the drop-down list to the right of the word with.
d. Select the Logging tab, and check the Log at End of Connection checkbox.
e. Click Add to add this rule to the SSL policy.
Cisco dCloud
8. Click Save to save the SSL policy.
NOTE: The Replace Key checkbox deserves explanation. Whenever the action is set to Decrypt – Resign, Firepower will replace
the public key. The Replace Key checkbox determines how the decrypt action is applied to self-signed server certificates.
• If Replace Key is deselected, self-signed certificates are treated like any other server certificates. Firepower replaces the key,
and resigns the certificate. Generally the endpoint is configured to trust Firepower, and therefore will trust this resigned certificate.
• If Replace Key is selected, self-signed certificates are treated differently. Firepower replaces the key, and generates a new self-
signed cert. The browser on the endpoint will generate a certificate warning.
In other words, checking the Replace Key checkbox makes the resign action preserve lack-of-trust for self-signed certificates.
Configuration A1,5: Custom detection list
There is a harmless file called Zombies.pdf that will trigger a malware event, assuming the cloud lookup succeeds. Sometimes labs
have issues with cloud connectivity. Therefore, this is added to the custom detection list to ensure it will trigger a malware event...
1. Navigate to Objects > Object Management > File List.
2. Click the pencil icon to edit the Custom-Detection-List.
a. Select Calculate SHA from the Add by drop-down list.
b. Click Browse.
c. Browse to the Files folder on the Jump desktop.
d. Select Zombies.pdf, and click OK.
e. Click Calculate and Add SHAs.
f. Click Save.
Cisco dCloud
Configuration A1,6: Add restapiuser
It is convenient to have a separate use to use the API Explorer. This allows use of both the FMC and API Explorer at the same
time.
1. Navigate to System > Users. Click Create User.
a. For User Name, enter restapiuser.
b. For Password, enter C1sco12345. Confirm the password.
c. Set Maximum Number of Failed Logins to 0.
d. Check the Administrator checkbox.
Cisco dCloud
Configuration A1,7: Install server certificate
By default the FMC UI uses a self-signed certificate. This is replaced by a certificate signed by the pod AD server, which the Jump
browsers trust.
1. Navigate to Objects > Object Management > PKI > Trusted CAs.
a. Click Add Trusted CA.
b. For Name, enter dCloud.
c. Click the Browse button to the right of the text Certificate Data or, choose a file.
d. Browse to the Certificates folder on the Jump desktop.
e. Upload AD-ROOT-CA-CERT.cer.
f. Click Save.
2. Connect to the FMC CLI via SSH. Become root by typing sudo -i. The Sudo password is C1sco12345
a. Type cd /etc/ssl and then type cp server* /root.
b. Type cat > /etc/ssl/server.crt
c. From the Certificates folder on the Jump desktop edit the file fmc.cer with Notepad++.
d. Select all, and then copy and paste into the FMC CLI
e. Type Ctrl+D.
f. Type cat > /etc/ssl/server.key
g. From the Certificates folder on the Jump desktop edit the file fmc.key with Notepad++.
h. Select all, and then copy and paste into the FMC CLI
i. Type Ctrl+D.
j. Type pmtool restartbyid httpsd.
Cisco dCloud
Appendix B. REST API Scripts

Here are the two Python scripts that were used in the first lab exercise. You only run the first script register_config.py. It will
call the second script connect.py, which will create the compiled file connect.pyc.
Python script register_config.py

#!/usr/bin/python
import json
import connect
import sys
host = "fmc.example.com"
username = "restapiuser"
password = "C1sco12345"
name="NGFW"
#connect to the FMC API

headers,uuid,server = connect.connect (host, username, password)
user_input = str(raw_input("Would you like to register the managed device? [y/n]"))

if user_input == "y":
policy_name = str(raw_input("Enter name of new Access Control Policy to be create:"))
access_policy = {
"type": "AccessPolicy",
"name": policy_name,
"defaultAction": { "action": "BLOCK" }
}
post_response = connect.accesspolicyPOST(headers,uuid,server,access_policy)
policy_id = post_response["id"]
print "\n\nAccess Control Policy\n" + policy_name + "\ncreated\n\n"
device_post = {
"name": name,
"hostName": "ngfw.example.com",
"regKey": "C1sco12345",
"type": "Device",
"license_caps": [
"BASE",
"MALWARE",
"URLFilter",
"THREAT"
],
"accessPolicy": {
"id": policy_id,
"type": "AccessPolicy"
}
}
post_data = json.dumps(device_post)
output = connect.devicePOST (headers, uuid, server, post_data)

# print "\n\nPost request is: \n" + json.dumps(output,indent=4) + "\n\n"
# GET ALL THE DEVICES AND THEIR corresponding interfaces
user_input = str(raw_input("In the FMC UI, confirm that the device discovery has completed and then
press 'y' to continue or 'n' to exit. [y/n]"))
headers,uuid,server = connect.connect (host, username, password)
Cisco dCloud
if user_input == "n":
quit()
devices = connect.deviceGET(headers,uuid,server)
for device in devices["items"]:
if device["name"] == name:
print "DEVICE FOUND, setting ID"
device_id = device["id"]
# NOW THAT WE HAVE THE DEVICE ID WE NEED TO GET ALL THE INTERFACES
interfaces = connect.interfaceGET(headers,uuid,server,device_id)
# Interfaces i want to change
interface_1 = "GigabitEthernet0/0"
interface_2 = "GigabitEthernet0/1"
for interface in interfaces["items"]:

if interface["name"] == interface_1:
interface_1_id = interface["id"]
print "interface 1 found"
if interface["name"] == interface_2:
interface_2_id = interface["id"]
print "interface 2 found"
user_input = str(raw_input("Would you like to configure device interfaces? [y/n]"))
if user_input == "y":
interface_put = {
"type": "PhysicalInterface",
"hardware": {
"duplex": "AUTO",
"speed": "AUTO"
},
"enabled": True,
"MTU": 1500,
"managementOnly": False,
"ifname": "outside",
"enableAntiSpoofing": False,
"name": "GigabitEthernet0/0",
"id": interface_1_id,
"ipv4" : {
"static": {
"address":"198.18.133.2",
"netmask":"18"
}
}
}
put_data = json.dumps(interface_put)
connect.interfacePUT (headers, uuid, server, put_data,device_id,interface_1_id)
interface_put = {
"type": "PhysicalInterface",
"hardware": {
"duplex": "AUTO",
"speed": "AUTO"
},
"enabled": True,
"MTU": 1500,
"managementOnly": False,
"ifname": "inside",
Cisco dCloud
"enableAntiSpoofing": False,
"name": "GigabitEthernet0/1",
"id": interface_2_id,
"ipv4" : {
"static": {
"address":"198.19.10.1",
"netmask":"24"
}
}
}
put_data = json.dumps(interface_put)
connect.interfacePUT (headers, uuid, server, put_data,device_id,interface_2_id)
Python script connect.py

#!/usr/bin/python
import json
import sys
import requests
#Surpress HTTPS insecure errors for cleaner output
from requests.packages.urllib3.exceptions import InsecureRequestWarning
requests.packages.urllib3.disable_warnings(InsecureRequestWarning)
#define fuction to connect to the FMC API and generate authentication token
def connect (host, username, password):
headers = {'Content-Type': 'application/json'}
path = "/api/fmc_platform/v1/auth/generatetoken"
server = "https://"+host
url = server + path
try:
r = requests.post(url, headers=headers, auth=requests.auth.HTTPBasicAuth(username,password),
verify=False)
auth_headers = r.headers
token = auth_headers.get('X-auth-access-token', default=None)
uuid = auth_headers.get('DOMAIN_UUID', default=None)
if token == None:
print("No Token found, I'll be back terminating....")
sys.exit()
except Exception as err:
print ("Error in generating token --> "+ str(err))
sys.exit()
headers['X-auth-access-token'] = token
return headers,uuid,server
def devicePOST (headers, uuid, server, post_data):

api_path= "/api/fmc_config/v1/domain/" + uuid + "/devices/devicerecords"
url = server+api_path
try:
r = requests.post(url, data=post_data, headers=headers, verify=False)
status_code = r.status_code
resp = r.text
Cisco dCloud
json_response = json.loads(resp)
print("status code is: "+ str(status_code))
if status_code == 201 or status_code == 202:
print("Post was sucessfull...")
else:
r.raise_for_status()
print("error occured in POST -->"+resp)
except requests.exceptions.HTTPError as err:
print ("Error in connection --> "+str(err))
finally:
if r: r.close()
return json_response
def deviceGET (headers, uuid, server):

api_path= "/api/fmc_config/v1/domain/" + uuid + "/devices/devicerecords"
try:
r = requests.get(url, headers=headers, verify=False)
resp = r.text
if status_code == 200:
print("GET was sucessfull...")
else:
finally:
if r: r.close()
def interfaceGET (headers, uuid, server, device_id):

api_path= "/api/fmc_config/v1/domain/" + uuid +
"/devices/devicerecords/"+device_id+"/physicalinterfaces"
try:
r = requests.get(url, headers=headers, verify=False)
resp = r.text
if status_code == 200:
print("GET was sucessfull...")
else:
finally:
if r: r.close()
def interfacePUT (headers, uuid, server, put_data,device_id, interface_id):

api_path= "/api/fmc_config/v1/domain/" + uuid +
"/devices/devicerecords/"+device_id+"/physicalinterfaces/"+interface_id
Cisco dCloud
try:
r = requests.put(url, data=put_data, headers=headers, verify=False)
resp = r.text
if status_code == 200 :
print("Put was sucessfull...")
else:
finally:
if r: r.close()
def accesspolicyPOST (headers, uuid, server, post_data):

api_path= "/api/fmc_config/v1/domain/" + uuid + "/policy/accesspolicies"
try:
r = requests.post(url, data=json.dumps(post_data), headers=headers, verify=False)
resp = r.text
if status_code == 201 or status_code == 202:
print("Post was sucessfull...")
else:
finally:
if r: r.close()
Cisco dCloud
Appendix C. ISE RA VPN Configuration

ISE was configured to support all the lab exercises. In this appendix, this configuration is summarized. Note that there is an ISE
link on the Firefox bookmarks toolbar. The credentials should prepopulate. They are username admin, password C1sco12345.
NOTE: This appendix is not a tutorial on ISE. It does not go into details about how ISE is configured. It only covers the details
required to configure RA VPN components for the lab exercises in this guide. The configurations are described in a top-down
manor. To create this configuration, you would probably prefer to build these objects from the bottom-up.
Authorization policies
1. Navigate to Policy > Authorization. The first two policies were created for this lab: AC-IT-Policy and AC-Default-Policy.
These reference two authorization profiles: AC-Auth-IT and AC-Auth-Default, described below.
These policies reference two authorization profiles: AC-Auth-IT and AC-Auth-Default.
Authorization profiles
1. Navigate to Policy > Policy Elements > Results > Authorization > Authorization Profiles. The first two profiles were
created for this lab: AC-Auth-Default and AC-Auth-IT.
Cisco dCloud
2. If you drill down into AC-Auth-Default, you will see that it references the DACL AC-DACL-Default, described below.
3. If you drill down into AC-Auth-IT, you will see that it references the DACL AC-DACL-IT, described below. It also has two
advanced attributes: one for the address pool, and one for the group policy.
Cisco dCloud
Downloadable ACLs
1. Navigate to Policy > Policy Elements > Authorization > Downloadable ACLs. The first two DACLs were created for this
lab: AC-DACL-Default and AC-DACL-IT.
2. If you drill down into AC-DACL-Default, you will see that it restricts access to 198.19.10.100 and 198.19.10.200.
3. If you drill down into AC-DACL-IT, you will see that there are no restrictions.
Cisco dCloud
Appendix D. Using Alien Vault as a TAXII Feed

This Appendix provides an alternative to Hail a TAXII as a source of free TAXII feeds. This consists of the following tasks.
• Create an account at Alien Vault
• Obtain an API Token
• Subscribe CTID to an Alien Vault TAXII feed
Steps
Create an account at Alien Vault
1. Navigate to https://otx.alienvault.com
a. Enter a username, a valid email address, and a password.
b. Click SIGN UP.
2. Log into the email account you used for Step 1a and click the confirmation link.
a. Click the confirmation link.

Click on a link in an email from a strange account? Yes!
b. Click the Confirm button when it appears.
c. Click LOGIN to login to your Alien Vault account.
Obtain an API token
1. In your Alien Vault account click on the API link near the center-top of the page.
2. On the right side of the page click on the copy button to the right of the API token. You may wish to save this to a file.
Cisco dCloud
Subscribe CTID to an Alien Vault TAXII feed
1. Navigate to Intelligence > Sources > Sources. Click the plus sign on the right to add an intelligence source.
a. For DELIVERY, select TAXII.
b. For URL, enter https://otx.alienvault.com/taxii/discovery
c. For USERNAME, enter your Alien Vault login name.
d. For PASSWORD, paste the API token you copied from your Alien Vault account.
e. For FEEDS, select user_AlienVault. Note that it may take several seconds for the FEEDS drop-down list to
populate.
f. Confirm that the screen looks like the following figure.
g. Click Save.
2. Wait until the Status column for this source changes from Downloading to Parsing. Do not wait for the parsing to complete –
this will take too long.
3. Navigate to Intelligence > Sources > Indicators. Confirm that several URL indicators have been added.
4. Navigate to Intelligence > Sources > Observables. Confirm that several URL observables have been added.
Cisco dCloud

Firepower NGFW Lab v1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Firepower NGFW Lab v1

Uploaded by

Copyright:

Available Formats

Cisco dCloud

Cisco Firepower Next Generation Firewall 6.2 Lab v1

About This Demonstration

• About This Solution

• Scenario 1: Device Deployment with the REST API

• Scenario 2: Basic Configuration

• Scenario 3: AnyConnect Remote Access VPN

• Scenario 4: AnyConnect with RADIUS Attributes

• Scenario 5: AnyConnect with Client Certificates

• Scenario 6: Monitoring and Troubleshooting

• Scenario 7: Cisco Threat Intelligence Director (CTID)

• Scenario 9: ASA to NGFW Migration

• Scenario 10: NAT to Routing

• Scenario11: Site-to-Site VPN

• Scenario 12: Web Proxy Integration

• Scenario 13: Prefilter Policies

• Scenario 14: Integrate Routing and Bridging (IRB)

• Appendix A: FMC Pre-configuration

• Appendix B: REST API Scripts

• Appendix C: ISE RA VPN Configuration

• Appendix D: Using Alien Vault as a TAXII Feed

• Scenario 13 uses the static NAT configuration from Scenario 10.

● Laptop ● Cisco AnyConnect®

About This Solution

Figure 1. dCloud Topology

PREPARATION IS KEY TO A SUCCESSFUL PRESENTATION.

1. Initiate your dCloud session. [Show Me How]

NOTE: It may take up to 10 minutes for your session to become active.

Jumper: 198.18.133.50, Username: administrator, Password: C1sco12345

Scenario 1. Device Deployment with the REST API

Configure the NGFW for management by the FMC

2. Type the command configure manager add fmc.dcloud.local C1sco12345.

3. Read the warning.

Enable Smart licenses on the FMC

2. Click Log In.

3. Navigate to System > Licenses > Smart Licenses.

4. Click on Evaluation Mode, and click Yes when prompted.

Run a REST API script to register and configure the NGFW

1. Create an access control policy.

2. Register the NGFW to the FMC.

3. Configure the NGFW interfaces.

5. On the Inside Linux server CLI run runapiscript.

c. Wait for a confirmation message.

e. Go on to the next step before you continue the script.

a. Enter y and press <Return>.

Configure the default route

3. Select the Routing tab.

a. Select Static Route, and click the Add Route button.

4. Click Save to save the routing configuration.

Scenario 2. Basic Configuration

• Create objects needed for exercise

• Modify the access control policy

• Create a NAT policy

• Modify the network discovery policy

• Deploy the configuration changes

• Test the NGFW configuration

• Allow outbound connections, and block other connection attempts

• Perform file type and malware blocking on these outbound connections

• Provide intrusion prevention on these outbound connections

Create objects needed for exercise

1. Navigate to Objects > Object Management.

a. Click Add Network > Add Object.

b. For Name, enter Lab_Networks.