Cisco dCloud

Cisco Firepower Next-Generation Firewall 6.7

Advanced Lab v1.7
Last Updated: 14-July-2021

IMPORTANT! This content is community developed and is not subject to standard dCloud verification or support.
Please contact dCloud Support for more information.

REQUIREMENTS 2

ABOUT THIS SOLUTION 2

TOPOLOGY 3

GET STARTED 4

SCENARIO 1. INTEGRATED ROUTING AND BRIDGING (IRB) 5

SCENARIO 2. HIGH AVAILABILITY CONFIGURATION 15

SCENARIO 3. ADVANCED PACKET FLOW ANALYSIS 29

SCENARIO 4. CISCO THREAT INTELLIGENCE DIRECTOR (CTID) 33

APPENDIX A. FMC PRE-CONFIGURATION 40

APPENDIX B. REST API SCRIPTS 48

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 52
 Cisco dCloud

Requirements
The table below outlines the requirements for this preconfigured demonstration.
Table 1. Requirements
Required Optional

● Laptop ● Cisco AnyConnect®

About This Solution

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.

Cisco Firepower is an integrated suite of network security and traffic management products, deployed either on purpose-built
platforms or as a software solution. The system is designed to help you handle network traffic in a way that complies with your
organization’s security policy-your guidelines for protecting your network.

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.

In this lab you will build a multi-site network Next Generation Firewall (NGFW) solution at between a corporate and two branch sites.
Using the Firepower Management Console (FMC) you will build High Availability NGFWs at the corporate site and manage a branch.
In this lab, you will also configure a NGFW using the FDM (Firepower Device Manager). You will also configure remote access and
site to site VPNs. You will also configure Cisco Threat Intelligence Director to accept and implement third party updates to your NGFW
devices.

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 2 of 52
 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

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 3 of 52
 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. For best performance, connect to the workstation with Cisco AnyConnect VPN [Show Me How] and the local RDP client on
your laptop [Show Me How]

• Jump PC 1: 198.18.133.50, Username: administrator, Password: C1sco12345

NOTE: You can also connect to the workstation using the Cisco dCloud Remote Desktop client [Show Me How]. The dCloud
Remote Desktop client works best for accessing an active session with minimal interaction. However, many users experience
connection and performance issues with this method.

3. From the jumpbox, open Firefox. It should open with FMC login page as the default page. The login name and password will
be prepopulated. Click Login.

4. Alternatively, open the Quick Launch from the task bar, and click the FMC Web to login to the GUI of the FMC automatically.

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 4 of 52
 Cisco dCloud

Scenario 1. Integrated Routing and Bridging (IRB)

The Integrated Routing and Switching (IRB) feature allows users to configure a bridge group interface on the FTD even in the
routed mode. With this feature, the bridge group interfaces can co-exist with L3 interfaces as well. Unlike, Bridge groups in
Transparent mode, communication across different BVI interfaces is supported in routed mode. The configuration for this feature is
done via the FMC.

This exercise consists of the following tasks.

• Create the objects needed for this lab exercise

• Modify the NGFW interface configuration
• Modify the NAT policy
• Modify the access control policy
• Deploy and test the configuration

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 same security zones. However, a bridge group can contain
interfaces in different security zones. Putting the bridge-group interfaces in different zones allows more granular control of traffic
between interfaces in the same bridge group.

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 5 of 52
 Cisco dCloud

Steps

Configure the Interface Security Zone object

1. Launch the Firefox browser from the start menu.

2. Access the Firepower Management Center using the Chrome browser. The login name and password will prepopulate.

3. Click Log In.

4. Navigate to Objects > Object Management.

5. Select Interface from the left navigation panel.

6. Click Add > Security Zone.

7. On the Security Zones configuration window, complete the following steps:

a. For Name, enter BVIZone.

b. Select Switched from the Interface Type drop-down menu.

NOTE: The Switched type of interface is used to change the interface to L2 software switched mode when this zone is assigned to
the member interfaces of the BVI.

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 6 of 52
 Cisco dCloud

c. On the Available Interfaces dropdown, select NGFW1.

d. Click Save.

Modify the NGFW interface configuration

In this section, we will create a BVI interface with G0/1 and G0/2 as its members.

1. Navigate to Devices > Device Management > NGFW1.

2. Click on the pencil icon next to the NGFW1 device.

3. On the NGFW1 device configuration page, make sure the member interfaces of the potential Bridge Group interface have no
IP addresses configured. In this example, remove the IP addresses assigned to GigabitEthernet0/1 and GigabitEthernet0/2.

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 7 of 52
 Cisco dCloud

4. On the Interfaces tab, click Add Interfaces.

5. Select Bridge Group Interface.
6. On the Add Bridge Group Interface configuration window, complete the following steps:
a. For Name enter InsideBVI.
b. For Bridge Group ID, enter 1

c. Select GigabitEthernet0/1 and GigabitEthernet0/2 and click Add.

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 8 of 52
 Cisco dCloud

d. Select the IPv4 tab.

e. Under the IP Type dropdown, select Use Static IP.

f. Enter the IP address 198.19.10.1/24.

g. Click OK.

h. Please take a moment to read the information in the popup box. Click Yes to proceed.

7. Click Save to save the configuration. A new BVI1 BridgeGroup interface should appear in the interface list.

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 9 of 52
 Cisco dCloud

Tip: Prior to BridgeGroup interface configuration, the IP address should be removed from the member interfaces, such as,
GigabitEthernet0/1 and GigabitEthernet0/2. Otherwise, the BridgeGroup interface configuration attempt may fail at this stage. In this
case, remove the IP addresses from the physical interfaces and try to configure the BridgeGroup interface again.

8. Click on the pencil icon to edit the GigabitEthernet0/1 interface.

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.

9. Click on the pencil icon to edit the GigabitEthernet0/2 interface.

a. For Name enter inside2.

b. Check the Enabled checkbox.

c. Select BVIZone from the Security Zone drop-down list.

d. Click OK.

10. Click Save to save the device configuration.

Modify the NAT policy

NOTE: If 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 zones with more than one interface.

1. Navigate to Objects > Object Management.

2. Select Interface from the left navigation panel.

a. Click Add > Interface Group.

b. For NAME, enter InGroup1.

c. For Interface Type, select Switched.

d. Select the interface inside1 and click Add.

e. Click Save.

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 10 of 52
 Cisco dCloud

3. Navigate to Devices > NAT.

4. Edit the Default NAT policy.

a. Replace InZone1 with InGroup1 in all the Auto NAT rules.

b. Replace InZone1 with BVIZone in other rules.

c. Click Save to save the NAT policy.

Create an access control policy for inspecting traffic between BVI interfaces

1. Create a new Access Policy:

a. Navigate to Policies > Access Control > Access Control.
b. Click on the New Policy button and name it Allow Internal Traffic – IRB.
c. Select Base Policy as None and Default Action as Intrusion Prevention.
d. Select NGFW1 from the targeted devices and click the Add to Policy button.
e. Click Save. A prompt appears to state that the policy assignment for the NGFW1 will change from Base_Policy.
f. Click Yes.

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 11 of 52
 Cisco dCloud

2. Add an access control rule to allow (but inspect) traffic between interfaces in BVIZone.
a. Click on Add Rule button on the policy editor.
b. For Name, enter Allow Internal Traffic.
c. Select into Default rule from the Insert drop-down list.
d. The Zones tab should already be selected.
e. Select BVIZone and click Add to Source.
f. Select BVIZone and click Add to Destination.

g. Select the Inspection tab.

h. Select Demo Intrusion Policy from the Intrusion Policy drop-down list.
i. Select Demo File Policy from the File Policy drop-down list.
j. Click Add to add the rule.

3. Click Save to save the changes to the access control policy.

4. Deploy the policies to NGFW1 and test the configuration.

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 12 of 52
 Cisco dCloud

Testing the IRB Policy Configuration

NOTE: Deploy the configuration changes and wait for the deployment to complete.

1. From the Inside Linux Server [root/C1sco12345] CLI, test connectivity by typing ping isolated. This should succeed.
a. If the ping does not succeed check the Mandatory rules for the Base_Policy and change the Destination Zone from
any to a different zone.
2. 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
d. From the Inside Linux server CLI, test the file and malware blocking capabilities.
i. As a control test, use WGET to download a file that is not blocked. This should succeed:

wget -t 1isolated/files/ProjectX.pdf

ii. Next use WGET to attempt to download the file blocked by type:

wget -t 1 isolated/files/test3.avi

NOTE: 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.

iii. 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.

Remove IRB Lab components

1. Devices > Device Management > click the pencil icon on the NGFW1 line
2. Click Remove Icon from the BVI1 Interface
3. Go to GigiabitEthernet 0/1 and click the pencil icon
a. Name inside
b. Click Enabled
c. Security Zone InZone1

d. IPv4 198.19.10.1/24
e. Click OK
4. Go to GigabitEthernet 0/2 and remove the name from the interface and make sure it is enabled. You need an enabled
interface with no name, security zone or IP address to use as a failover link in the next scenario.

5. Go to Device NAT Default PAT

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 13 of 52
 Cisco dCloud

a. Replace InGroup1 with InZone1 for all NAT Rules

b. Replace the BVIZone with InZone1
c. Click Save

6. Go to Policies > Access Control > Base_Policy

a. Click the pencil icon
b. Replace ALL BVIZone with InZone1
c. Delete the Block ICMP over GRE line 1 in Mandatory

d. You can delete the line with BVIZone to BVIZone used for the Allow Internal Traffic
e. You can delete the line with Allow GRE Traffic also
f. Click Save

7. Click Deploy
a. Select NGFW1
Test the Connectivity after removing IRB configuration

1. From Inside Linux Server [root/C1sco12345]

a. Ping Outside
2. From Outside Linux Server [root/C1sco12345]
a. Ping 198.18.133.120 (Outside NAT Address of FMC)
b. Ping 198.18.128.202 (Outside NAT Address of Inside Linux Server)
c. Open a putty session to NGFWBR1 Username: admin Password: C1sco12345

i. Open the Command Prompt

1. Ping 198.18.133.120 (Outside NAT Address of FMC)

2. Ping 198.18.128.202 (Outside NAT Address of Inside Linux Server)

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 14 of 52
 Cisco dCloud

Scenario 2. High Availability Configuration

This exercise consists of the following tasks:

• Configure and Deploy Backup NGFW

• Create High Availability Pair of Firewalls
• Configure Active/Standby with Virtual Mac Address
• Test the configuration

The objective of this exercise is to understand and configure High Availability for NGFW. You will configure the second firewall and
then add it to the High Availability group.

Steps

Onboard a backup NGFW onto the FMC

NGFW device onboarding onto the FMC is done in two parts. First, configuration settings are added on the NGFW to configure
FMC as the device manager and establish communication with the FMC on the management interface. Secondly, the NGFW
device is added onto the Devices page on the FMC to initiate and establish communication. Here, we use the jumpbox to
complete both the steps.
1. For configuring the backup NGFW, go to the Windows machine labelled jumpbox and open the PUTTY Session - Select
NGFW3, Select Load and Select Open

a. Username: admin password: C1sco12345

b. Type: show managers
c. If it says Managed locally:
a Enter the command: configure manager delete
b Type yes. Now, the output of show managers should show No managers configured.
c Type the command: configure manager add fmc.dcloud.local C1sco12345
d When command prompt returns type: show managers make sure fmc.dcoud.local shows “status pending”

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 15 of 52
 Cisco dCloud

NOTE: The NGFW can be added to the FMC for management using the FMC UI. However, here we are going to use REST API
to demonstrate the automated capabilities of the solution. A python script is present on the Inside Linux Server called
runapiscript at the location /usr/local/bin. It invokes the REST APIs on the FMC to register the NGFW3 with the FMC, applies the
Health Policy to the NGFW3, discovers the interfaces, configures the IP addresses and deploys the Access Control Policy with the
name specified during the execution of the script.

2. For adding the backup NGFW to the FMC, open the PUTTY Session and Select Inside Linux server, Select Load and Select
Open

a. Login using the credentials - [root/C1sco12345]

b. Type runapiscript wait for the prompt
c. When asked Which Firewall do you want to register? Type the number 3
d. When it asked Enter name of new Access Control Policy to be create, type HA for the name

Note: The ‘Registration is in progress” count may vary during the execution of the script.

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 16 of 52
 Cisco dCloud

3. Verify that the NGFW3 is added successfully to the FMC by checking the registration status of NGFW3 on the FMC. You
might need to allow some time for the device to register. It should show a Green symbol in front of the device name.

4. Verify the GigabitEthernet0/2 interface for NGFW3 is set to blank configuration. This interface is to be used as the failover
interface during the formation of the HA pair.

a. Click on the Pencil icon next to NGFW3

b. Click on the Pencil icon next to the interface GigabitEthernet0/2
c. Select the checkbox against Enabled
d. Delete the Name of the interface (if any )
e. Click Ok and then Save.

5. Select the Device sub-tab. In the Inspection Engine section, click on Revert to Snort 2.

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 17 of 52
 Cisco dCloud

6. Click Deploy FMC UI to push the interface state change to NGFW3

NOTE: The following information is communicated over the failover link:

The unit state (active or standby)
Hello messages (keep-alives)
Network link status
MAC address exchange
Configuration replication and synchronization

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 18 of 52
 Cisco dCloud

Configure High Availability Pair

1. Go to Devices > Device Management> Add > Add High Availability

NOTE: The NGFW3 Management Interface (198.19.10.83) was preconfigured. Interfaces G0/0 and G0/1 were configured by the
REST API script. They do not have security zones listed on the interface, but they will inherit the security zones and the interface
IP Address’ from NGFW1 when the HA process is run.

a Name: HA_TEST
b Device Type: Firepower Threat Defense (This is the device type associated with the NGFW)
c Primary Peer: NGFW1
d Secondary Peer: NGFW3
e Then Continue
f The formation of HA pair restarts the snort engine on both the Primary and Secondary NGFW devices. This is entirely
expected behavior. Select Yes

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 19 of 52
 Cisco dCloud

NOTE: If you have done configuration tasks on either of the HA Peers and have not deployed then you will get the above
message. Click on Close and then click Cancel. Deploy the changes to NGFW3 by clicking the Deploy button in the FMC. Go
back and repeat step 1

2. Now, enter the High Availability details as below:

a. Select Interface: GigabitEtherent0/2
b. Name: Failover_Link
c. Primary IP: 198.19.254.1
d. Secondary IP: 198.19.254.2 Subnet Mask: 255.255.255.0
e. State Link: Interface Same as LAN Failover
f. IPsec Encryption: Enabled (OPTIONAL)
g. Click Add

NOTE: If Interfaces do not show up go back to Devices > Device Manager. Click on the Pencil Icon for each firewall click on the
Interfaces to make sure that the interfaces do not have names.

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 20 of 52
 Cisco dCloud

NOTE: The Failover ‘State link’ can be a separate dedicated link as well. However, for simplicity in this lab we are using the LAN
failover link as the State link also.

NOTE: Creating or breaking a Firepower Threat Defense high availability pair immediately restarts the Snort process on the primary
and secondary devices, temporarily interrupting traffic inspection on both devices. Whether traffic drops during this interruption or
passes without further inspection depends on the model of the managed device and how it handles traffic. See Snort® Restart
Traffic Behavior for more information. The system warns you that continuing to create a high availability pair restarts the Snort
process on the primary and secondary devices and allows you to cancel.

3. Click on OK to add the High Availability Pair

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 21 of 52
 Cisco dCloud

NOTE: The configuration of the HA will take some time you will see status updates from time to time if you watch the Tasks next to
the deployment button.

4. When complete you will see the following:

5. Go to Devices > Device Management Click on the pencil icon next to the HA pair name - HA_Test

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 22 of 52
 Cisco dCloud

NOTE: MAC Addresses and IP Addresses in Failover.

When you configure your interfaces, you can specify an active IP address and a standby IP address on the same network.

Although recommended, the standby address is not required. Without a standby IP address, the active unit cannot perform network
tests to check the standby interface health; it can only track the link state. You also cannot connect to the standby unit on that
interface for management purposes.

When the primary unit or failover group fails over, the secondary unit assumes the IP addresses and MAC addresses of the primary
unit and begins passing traffic.

The unit that is now in standby state takes over the standby IP addresses and MAC addresses.

Because network devices see no change in the MAC to IP address pairing, no ARP entries change or time out anywhere on the
network.

If the secondary unit boots without detecting the primary unit, the secondary unit becomes the active unit and uses its own MAC
addresses, because it does not know the primary unit MAC addresses. However, when the primary unit becomes available, the
secondary (active) unit changes the MAC addresses to those of the primary unit, which can cause an interruption in your network
traffic. Similarly, if you swap out the primary unit with new hardware, a new MAC address is used.

Virtual MAC addresses guard against this disruption because the active MAC addresses are known to the secondary unit at startup
and remain the same in the case of new primary unit hardware. In multi-instance capability the FXOS chassis autogenerates only
primary MAC addresses. You can overwrite the generated MAC address with a virtual MAC address with both the primary and
secondary MAC addresses, setting the secondary MAC address does ensure that to-the-box management traffic is not interrupted
in the case of new secondary unit hardware.

If you do not configure virtual MAC addresses, you might need to clear the ARP tables on connected routers to restore traffic flow.
The FTD does not send gratuitous ARPs for static NAT addresses when the MAC address changes, so connected routers do not
learn of the MAC address change for these addresses.

The IP address and MAC address for the state link do not change at failover; the only exception is if the state link is configured on a
regular data interface.
© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 23 of 52
 Cisco dCloud

6. Select the “+” icon next to the Interface MAC Address

7. Physical Interface: GigabitEthernet0/1 Active Interface MAC Address: student choice (IP Address of interface used in
example) Standby Interface Mac Address: Student Choice of input [example below] Click Ok

NOTE*: The above step is an example of how to configure an Interface Mac Address

8. Configure Monitored Interfaces Go to the pencil icon next to inside under the list of Monitored Interfaces

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 24 of 52
 Cisco dCloud

9. Enter the Standby IP Address: 198.19.10.31. Repeat for the outside Interface 198.18.133.132

10. Click OK, Save and then Deploy Select HA_Test and then Deploy

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 25 of 52
 Cisco dCloud

Looking at the configuration of NGFW3.

1. Let’s look at some of the configuration parameters that NGFW3 received during the HA setup
2. Go to the Jump PC open PUTTY and select NGFW3
3. Login into the NGFW Username: admin Password: C1sco12345 Type:

a show running-config interface

i What is the primary IP Address of each Interface?
ii Is there a Standby IP Address associated with the Interface?
b show running-config failover
i What is the Failover Mac Address for Interface GigabitEthernet0/1?
ii What is the Interface for the Failover_Link?
iii What is the Interface IP Address for the Failover_Link?

Testing Failover

1. On the Jump PC go to PUTTY and open up a session to the Inside Linux Server

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 26 of 52
 Cisco dCloud

2. Login: root Password: C1sco12345 Type: “ping outside” and let the script continue to run

3. Go to the web interface of the FMC Devices > Device Management. Click on the three vertical dots at the right of the
HA_TEST row, and select Switch Active Peer. Click Yes when it prompts to make NGFW3 Active.

4. Resize the Firefox window so you can also see the results of the pinging from the Inside Linux Server.

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 27 of 52
 Cisco dCloud

5. Switch back so that the NGFW1 becomes Active again.

NOTE: The Active HA status of the NGFW implies that it is participating in the traffic processing and owns the Active Interface
MAC addresses. Only the Primary or the Secondary NGFW can be Active at a given time and therefore handle traffic.

IMPORTANT: You can do the remaining scenarios with the HA pair, or you can first break the HA
pair. The scenario steps and screenshots reflect a non-HA environment. If you have completed the
HA scenario, substitute HA_Test for NGFW1.

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 28 of 52
 Cisco dCloud

Scenario 3. Advanced Packet Flow Analysis

This exercise consists of the following tasks that allow you to troubleshoot any connectivity issues through FTD:

• Packet-Tracer
• Capture with Trace

Troubleshooting with Packet Tracer and Packet Captures

1. When to use Packet-Tracer

a. Verify if traffic to a specific port is allowed by the Lina Data path and Snort
i. Security Intelligence (IP Reputation)
ii. L3/L4 IPS Intrusion Rules
b. Packet Tracer Does Not currently work with: (Because it cannot emulate a L7 packet) i. Identity-

based rules ii. L7-related (SI DNS/URL, App ID, File Policy, L7 Intrusion Rules)

Packet-Tracer Lab

1. On the FMC go to Policies > Access Control > Edit the Base_Policy

2. Click Add New Rule

a. Name: Packet-Trace Rule

b. Set the Rule ABOVE rule 1
c. Under Action Block or Block with reset
d. Zones: Source Zone InZone1, Destination Zone Outzone
e. Networks: Source: MainOfficenetwork Destination Networks: any-ipv4
f. Applications: Available Applications type ICMP and Select All apps matching the filter click Add to Rule
g. Available Applications type: FTP. Select All apps matching the filter and click Add to Rule

h. Click Logging tab and select Log at Beginning of Connections

i. Click Add
j. Click Save and Deploy to HA_Test or [NGFW1]

NOTE: We selected all the applications related to ICMP and FTP in a production environment you would be more specific with
what particular applications you are blocking.

3. Open a PUTTY Session to NGFW1 Username: admin Password C1sco12345

4. Type the following packet-tracer input inside icmp 198.19.10.200 8 8 198.18.133.200

a. Look at Phases you will notice that the packet has been handed off to SNORT for further processing
b. You will see that SNORT used block w/reset a rule id to order a drop of the packet.

5. Now look at the Packet-Trace command in the FMC

6. Go to Devices > Device Management.> NGFW1.
7. Click on the three dots next to the device name. You will find the options for Packet Tracer and Capture w/Trace.

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 29 of 52
 Cisco dCloud

8. Select Packet Tracer.

9. FMC opens the Advanced Troubleshooting page. By default, you will enter the Packet Tracer page.

a. Packet Type: ICMP

b. Interface: inside
c. Source: 198.19.10.200

d. Type: 8 (Echo Request) Code 0

e. Destination: 198.18.133.200
f. Click Start

NOTE: You will get the same results that you saw in the Command Line of the NGFW1 it is just shown in the window.

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 30 of 52
 Cisco dCloud

10. Set up the Packet Tracer for FTP

a. Packet Type: TCP
b. Source: 198.19.10.200

c. Source Port: 1111

d. Destination 198.18.133.200 (Outside Linux Server)

e. Destination Port: FTP

f. Click Clear
g. Click Start

NOTE: Phase 2 is still checking the rule you created Look at Phase 14 you will see that SNORT looked at the rule and the verdict
was to pass the packet. The first part of the packet is passed but not the next packets. To test this, go to the Jump PC and open
the inside linux server session and type ftp outside you will be prompted: login: guest you will receive a message that states
No Control connection for command Transport endpoint is not connected. You can go to Analysis Connection Events and see
that FTD was Blocked with reset.

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 31 of 52
 Cisco dCloud

Capture w/Trace Lab

NOTE: There are two types of Traffic Captures the Lina based and the Snort based.

• Lina Level capture

• SNORT Level capture-traffic

For capturing packet with traces using the FMC, perform the following steps:
1. Go to Devices > Device Management page.
2. Click on the three dots next to the device name, such as NGFW1. You will find the options for Packet Tracer and Capture
w/Trace.
3. Select Capture w/Trace
4. Click Add Capture button:

a. Name: Capturewtrace
b. Interface: inside
c. Protocol: ICMP
d. Source Host: 198.19.10.200 (Inside Linux Server)
e. Destination Host: any
f. Buffer Size: 33554432 (32 MB)
g. Trace Count 100
h. Save

NOTE: We have not removed the access policy denying ICMP so the pings will fail, but you will be able to see the packet shown.
Also, you will export the file in PCAP format to Wireshark in this lab.

5. Go to the Jump PC and on the Inside Linux Server type ping outside.
6. If you don’t see information in the Packets Shown Window in about 10 seconds hit the refresh.
7. Once you see packets stop the ping.
8. Click on the Save icon for the packet capture you created.
a. Save the file as PCAP.
9. When Prompted Save File and click OK.
10. Go to the downloads arrow of Firefox and select the file just downloaded.
11. Minimize the Browser and you will see the file opened in Wireshark.
12. Notice that the messages have been administratively filtered.

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 32 of 52
 Cisco dCloud

Scenario 4. Cisco Threat Intelligence Director (CTID)

This exercise consists of the following tasks:

• 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.

Information on Scenario

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:

o Uploaded from the computer where the FMC UI is running.

o Retrieved from a URL on a remote web server.

o 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. Using this advanced setting, CTID can be enabled or disabled at the access policy level. Threat
Intelligence Director is enabled by default

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 33 of 52
 Cisco dCloud

4. Navigate to Intelligence > Elements. Confirm that the NGFW1 is an element. This means that CTID can publish observables
to the NGFW1 retrieved from a STIX file from a web server.

NOTE: The CTID can be enabled or disabled globally. Clicking Pause will stop the CTID publishing to all elements.

5. Navigate to Intelligence > Sources > Sources tab.

6. Click the plus sign (+) on the right to add an intelligence source.

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 34 of 52
 Cisco dCloud

7. Upload a list of URLs to CTID that will trigger an Incident

a. Click the plus sign (+) on the right to add an intelligence source.

b. For DELIVERY, select Upload.

c. For TYPE, select Flat File. The CONTENT drop-down list will appear.
d. For CONTENT, select URL.
e. Click in the FILE area and select URL_LIST.txt from the Files folder on the Jump desktop.

f. For NAME, enter Local URL List.

g. For ACTION, select Block.

8. Click Save.
9. Wait a few seconds. Navigate to Intelligence > Sources > Indicators. Delete the default time-based filter. Replace it with a
filter to only show published indicators, as shown in the following screenshot.

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 35 of 52
 Cisco dCloud

10. Click Apply to apply the filter. Confirm that two URL indicators have been added.

NOTE: The incidents may not appear for a while if the original time-based filter remains applied.

11. Navigate to Intelligence > Sources > Observables. Confirm that two type URL observables have been added.

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 36 of 52
 Cisco dCloud

Subscribe CTID to a TAXII feed

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, which may take several minutes. Do not wait for the parsing
to complete - this would take too long.

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 37 of 52
 Cisco dCloud

10. Navigate to Intelligence > Sources > Indicators. Delete the default time-based filter. Replace it with a filter to only show
published indicators, as you did for the previous source you configured.
11. Click Apply to apply the filter. Confirm that several URL indicators have been added.

12. Navigate to Intelligence > Sources > Observables. Confirm that several URL observables have been added.

Generate CTID incidents

1. 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. Use Putty on the Jump PC to SSH to the NGFW1 CLI and perform the following: (logged in
as admin / C1sco12345)

1. Type expert to get into expert mode.

2. Type ls -d /var/sf/*download.

NOTE: There are several directories listed. admin@ngfw:~$ ls -d /var/sf/*download

ls –d /var/sf/clamupd_download
ls –d /var/sf/iprep_download
ls –d /var/sf/sifile_download
ls –d /var/sf/cloud_download
ls –d /var/sf/sidns_download
ls –d /var/sf/siurl_download

Four of these (iprep_download, sidns_download, sifile_download and siurl_download) are used by security intelligence and CTID.
3. Type grep developmentserver /var/sf/*download/*lf (lf has a lower-case L) to confirm the observable has been published to
the firewall observables list.

4. You should see a type URL CTID observable.

/var/sf/siurl_download/731625d4-9512-11e7-915c-7e7252ae92ac.lf:developmentserver.com/misc/Tron.html/
NOTE: If you do not, wait a minute and try again. You must wait for this to be published before you go on.
© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 38 of 52
 Cisco dCloud

On the Inside Linux server CLI:

1. Use putty on the Jump PC, to SSH to the Inside Linux server and perform the following: (logged in as root/C1sco12345)

a Run wget -t 1 outside/files/ProjectX.pdf. This should succeed.

b Run wget -t 1 developmentserver.com/misc/Tron.html. This should be blocked.

2. On the FMC, navigate to Intelligence > Incidents. Confirm that there is an incident.

3. Drill down into the incident and observe the details for this incident.
4. Confirm that there is an incident for a URL indicator. Drill down into the incident and observe the details for this incident

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 39 of 52
 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,7: Interface Objects

Steps

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.

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 40 of 52
 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. Your screen should look like the figure below.

d Click Save. Ignore the warning and click OK, when prompted.

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 41 of 52
 Cisco dCloud

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.

NOTE: 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
4 Select the Advanced tab. Confirm that Enable Custom Detection List is selected.
5 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.

5. Click the Save button in the upper-right to save the file policy.

NOTE: Archives unable to be inspected are corrupt archive, or archives with a depth that exceeds the Max Archive Depth.

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 42 of 52
 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.

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 43 of 52
 Cisco dCloud

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.
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.

Click Policy Information in the menu on the upper-left.

Click Commit Changes.

Click OK.

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.

3. 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.

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 44 of 52
 Cisco dCloud

4. 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.

5. 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.

6. 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.

7. 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.

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 45 of 52
 Cisco dCloud

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.

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 Username, enter restapiuser.

b. For Password, enter C1sco12345 Confirm the password.
c. Set Maximum Number of Failed Logins to 0.
d. Check the Administrator checkbox.

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\Lab Certificates\Other Certificates folder on the Jump desktop.

e. Upload AD-ROOT-CA-CERT.cer.

f. Click Save.

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 46 of 52
 Cisco dCloud

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.

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 47 of 52
 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) 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": {

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 48 of 52
 Cisco dCloud

"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", "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)

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 49 of 52
 Cisco dCloud

Python script connect.py

#!/usr/bin/python import json import sys import requests #Suppress
HTTPS insecure errors for cleaner output from
requests.packages.urllib3.exceptions import InsecureRequestWarning
requests.packages.urllib3.disable_warnings(InsecureRequestWarning)
#define function 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

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 50 of 52
 Cisco dCloud

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 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" url = server+api_path try: r =
requests.get(url, headers=headers, verify=False) status_code = r.status_code resp = r.text
json_response = json.loads(resp) print("status code is: "+ str(status_code)) if status_code ==
200: print("GET 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
interfaceGET (headers, uuid, server, device_id):
api_path= "/api/fmc_config/v1/domain/" + uuid + "/devices/devicerecords/"+device
id+"/physicalinterfaces" url = server+api_path try:
r = requests.get(url, headers=headers, verify=False) status_code = r.status_code resp = r.text
json_response = json.loads(resp) print("status code is: "+ str(status_code)) if status_code == 200:
print("GET 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 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 url
= server+api_path try:
r = requests.put(url, data=put_data, headers=headers, verify=False) status_code = r.status_code resp
= r.text json_response = json.loads(resp) print("status code is: " + str(status_code)) if status_code
== 200 : print("Put 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
accesspolicyPOST (headers, uuid, server, post_data):
api_path= "/api/fmc_config/v1/domain/" + uuid +
"/policy/accesspolicies" url = server+api_path try:

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 51 of 52
 Cisco dCloud

r = requests.post(url, data=json.dumps(post_data), headers=headers, verify=False) status_code =

r.status_code resp = r.text 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

© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 52 of 52