Ltrsec 2101 LG

The Cisco Firepower NGFW – Lab
Guide
Lab Overview
This lab is designed to help attendees understand the key features available with the NGFW. There are
more lab materials then can reasonably be completed in 4 hours, so after the first 2 labs, the student
should pick from the remaining exercises with care.
The following conventions are be used in the lab exercises.
Font Function
Arial Bold Used to indicate emphasis
Arial Italic Used for elements is the UI, links, etc.
Courier New Bold Used to indicate text that must be typed in. Also
the output of some commands uses this font.
Exercise Dependencies
After completing labs 1 and 2, you may skip around, with the following exceptions. Also configuring static
NAT (Lab 3) is required for Lab A2.
• Lab 6 (Basic Authentication) must be completed before Lab 7 (ISE Integration)
• The static NAT component of Lab 3 must be completed before Lab A2 (Prefilter Policies)
Developers
The labs pod and lab guide were created by the Technical Marketing team of the Security Business
Group at Cisco Systems.
The Cisco Firepower NGFW November 2016 I-1

Lab Exercises
This lab guide includes the following exercises:
• Lab 1: Basic Policy Configuration ......................................................................................................... 1-1
◦ Task 1.1: Create security zone objects ........................................................................................... 1-1
◦ Task 1.2: Create an access control policy ....................................................................................... 1-1
◦ Task 1.3: Create a NAT policy ......................................................................................................... 1-3
• Lab 2: NGFW Deployment .................................................................................................................... 2-1
◦ Task 2.1: Register the NGFW with the FMC ................................................................................... 2-1
◦ Task 2.2: Configure interfaces and default route............................................................................. 2-2
◦ Task 2.3: Apply NAT policy to device .............................................................................................. 2-4
◦ Task 2.4: Configure platform settings .............................................................................................. 2-5
◦ Task 2.5: Modify the network discovery policy ................................................................................ 2-5
◦ Task 2.6: Test the NGFW deployment ............................................................................................ 2-7
• Lab 3: NAT and Routing .................................................................................................................... 3-1
◦ Task 3.1: Create objects needed for this lab exercise..................................................................... 3-1
◦ Task 3.2: Configure static NAT ........................................................................................................ 3-2
◦ Task 3.3: Modify access control policy to allow outside access to wwwin ...................................... 3-3
◦ Task 3.4: Configure BGP ................................................................................................................. 3-3
◦ Task 3.5: Deploy policy changes ..................................................................................................... 3-4
◦ Task 3.6: Test configuration ............................................................................................................ 3-5
• Lab 4: Rate Limiting .............................................................................................................................. 4-1
◦ Task 4.1: Baseline transfer rate ....................................................................................................... 4-1
◦ Task 4.2: Configure rate limiting ...................................................................................................... 4-1
◦ Task 4.3: Test rate limiting............................................................................................................... 4-3
• Lab 5: Site-to-site VPN ......................................................................................................................... 5-1
◦ Task 5.1: Create objects needed for this lab exercise..................................................................... 5-1
◦ Task 5.2: Configure site-to-site VPN ............................................................................................... 5-1
◦ Task 5.3: Create NAT exemption .................................................................................................... 5-4
◦ Task 5.4: Modify the access control policy and deploy changes ..................................................... 5-5
◦ Task 5.5: Test site-to-site VPN ........................................................................................................ 5-5
• Lab 6: Basic Authentication .................................................................................................................. 6-1
◦ Task 6.1: Configure a realm ............................................................................................................ 6-1
◦ Task 6.2: Create an identity policy .................................................................................................. 6-2
◦ Task 6.3: Modify the access control policy to use the identity policy and deploy ............................ 6-2
• Lab 7: ISE Integration ........................................................................................................................... 7-1
◦ Task 7.1: Configure ISE integration ................................................................................................. 7-1
◦ Task 7.2: Utilize ISE metadata the access control policy ................................................................ 7-3
◦ Task 7.3: Configure the access control policy to use ISE integration ............................................. 7-4
◦ Task 7.4: Test ISE passive authentication ...................................................................................... 7-5
◦ Task 7.5: Create a correlation policy using the ISE remediation module ........................................ 7-6
◦ Task 7.6: Test the ISE remediation module .................................................................................... 7-9
Appendices
• Lab A1: REST API and Policy Hierarchy ........................................................................................... A1-1
◦ Task A1.1: Create access control policies using the REST API .................................................. A1-1
◦ Task A1.2: Create access control policy rules using the API Explorer......................................... A1-2
◦ Task A1.3: Build an access control policy hierarchy .................................................................... A1-4

• Lab A2: Prefilter Policies .................................................................................................................... A2-1
◦ Task A2.1: Investigate NGFW default behavior for tunneled traffic ............................................. A2-1
◦ Task A2.2: Create a tunnel tag ..................................................................................................... A2-2
◦ Task A2.3: Create a prefilter policy............................................................................................... A2-3
◦ Task A2.4: Modify the access control policy and deploy changes ............................................... A2-3
◦ Task A2.5: Test the prefilter policy ............................................................................................... A2-4
• Appendix 3: FMC pre-configuration ................................................................................................... A3-1
• Appendix 4: Additional Pod Resources ............................................................................................. A4-1
◦ AMP Private Cloud ....................................................................................................................... A4-1
◦ Traffic generator............................................................................................................................ A4-2
◦ DMZ .............................................................................................................................................. A4-2
Lab Topology and Access

• There are 3 networks used in the lab.
o The inside network (172.16.1.0/24) inside the NGFW.
o The outside network (192.168.1.0/24) outside the NGFW.
o The branch office (172.16.255.0/24) connected to the outside network through an ASAv.
All management is in-band on the inside network. Limited access to the internet is available from
the outside network.
• All devices in this lab are virtual.
• The NGFW has been installed. The only configuration is the basic network configuration
associated with the installation process.
• The Firepower Management Center has some been pre-configured to expedite the lab exercises.
This is detailed in Appendix 1.
Note: To conserve VLANs, the outside and branch networks share the same VLAN, but you will only notice this if
you snoop the network traffic. Also the Branch Office CentOS is really the same VM as outside.com. This
is the topology used for this lab.

Internal IP addresses
The table that follows lists the internal IP addresses used by the devices in this setup.
Device IP Address
[Pod Edge Router – no user access] [192.168.1.1]
Jump Box 172.16.1.50, 192.168.1.50
ASAv 192.168.1.4, 172.16.255.1
CSR 192.168.1.3 (and others)
NGFW 172.16.1.82
PC1 (not a domain member) 172.16.1.21
PC2 (domain member) 172.16.1.22
DC (Domain Controller) 172.16.1.100
FMC (Firepower Management Center) 172.16.1.120
ISE (Identity Services Engine) 172.16..1.130
UNIX (Inside CentOS server) 172.16.1.200

Also hosting honeypot.example.com at
172.16.1.201
and alt.example.com at
172.16.1.202
SFUA (Sourcefire User Agent) 172.16.1.210
NGFW (FTD) 172.16.1.82
PC3 (For AnyConnect testing) 192.168.1.23
Outside.com 192.168.1.200
Also hosting honeypot.outside.com at
192.168.1.201
and alt.outside.com at
192.168.1.202
Alt.outside.com 192.168.1.202
Attack.outside.com 192.168.1.210

Accounts and Passwords
The table that follows lists the accounts and passwords used in this lab.
Access To Account (username/password)
Jump Box Administrator/FPlab123!
ASAv SSH access: admin/FPlab123!

Enable password: FPlab123!
CSR admin/FPlab123!
NGFW admin/FPlab123!
Windows (except Jump Box) administrator/FPlab123!

(PC1, PC2., PC3, User Agent, DC)
ISE (Identity Services Engine admin/FPlab123!
Attrack.outside.com root/FPlab123!
(Ubuntu)
Inside UNIX Server (unix.example.com) root/FPlab123!

(CentOS) guest/FPlab123!
Outside UNIX Server (outside.com) root/FPlab123!

(CentOS) guest/FPlab123!
FMC (Firepower Management Center) admin/FPlab123!
NGFW (FTD) admin/FPlab123!
There are many domain users and groups. You can get a complete picture by logging into the Domain
Controller using the link in the Remote Desktop Folder on the Jump Box. The table below shows four
users that are used in this course.
Account (username/password) Group
dilbert/FPlab123! Engineering
harry/FPlab123! HR
ira/FPlab123! Investment
rita/FPlab123! IT

Lab 1: Basic Policy Configuration
Exercise Description
This exercise consists of the following tasks.
Task 1.1: Create security zone objects
Task 1.2: Create an access control policy
Task 1.3: Create a NAT policy
Exercise Objective
The objective of this lab is to create a simple, generic access control policy and NAT policy. These
policies could be applied to multiple devices. You will apply these policies to a NGFW in Lab M2.
Lab Exercise Steps

Task 1.1: Create security zone objects
Step 1 Open the Firepower Management Center by double-clicking on the Firefox icon labeled FMC on
the Jump Box desktop. The login name and password will prepopulate. Click Log In.
Step 2 Navigate to Objects  Object Management. 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. Click Save.
d. Click Add  Security Zone.
e. For Name, enter OutZone. Select Routed from the Interface Type drop-down menu.
f. Click Save.
Task 1.2: Create an access control policy

Step 3 Navigate to Policies  Access Control  Access Control.
Step 4 Click the New Policy button. Enter a name like NGFW Access Control Policy. Keep the
other setting unchanged. Click Save.
Step 5 Wait a few seconds for the policy to open up for editing
The Cisco Firepower NGFW November 2016 1-1

Step 6 Click Add Rule.
a. For Name, enter Allow Outbound Connections.
b. Select into Default rule 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. See Lab B3 for an example of a policy hierarchy.
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 3 for instructions
on how to create these.
e. Click Add to add the rule.

Step 7 Select the HTTP Responses tab. Select System-provided from the Block Response Page drop-
down list.
Step 8 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.
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.
Step 9 Click Save to save the access control policy.

Task 1.3: Create a NAT policy
Step 10 Navigate to Devices  NAT.
Step 11 Click the New Policy button, and select Threat Defense NAT.
a. For Name enter Default PAT.
b. Click Save, and wait for the policy to open for editing.
a. Select Dynamic from the Type drop-down list.
b. 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.
c. You will be at the Interface Objects tab. Select InZone and click Add to Source.
d. Select OutZone, and click Add to Destination.
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.
Step 13 Click Save to save the NAT policy.

 End of Exercise: You have successfully completed this exercise.

Lab 2: NGFW Deployment
Task 2.1: Register the NGFW with the FMC
Task 2.2: Configure interfaces and default route
Task 2.3. Apply NAT policy to device
Task 2.4: Configure platform settings
Task 2.5: Modify the network discovery policy
Task 2.6: Test the NGFW deployment
Exercise Objective
The objective of this exercise is to deploy a NGFW. After registration, there will be a couple more tasks
before the deployment is complete. These include basic interface and routing. In addition, it is important
to have a platform policy and network discovery policies configured correctly to take advantage of the
eventing.
Lab Exercise Steps

Task 2.1: Register the NGFW with the FMC
Step 1 On the Jump Box desktop, open the PuTTY link. Double click on the preconfigured session
called NGFW. Login as admin, password FPlab123!.
Note: If you run into issues with typing special characters, please open the file on the Jump Box desktop called
Strings to cut and paste.txt.
Step 2 Type the command configure manager add fmc.example.com cisco123.
Step 3 For NGFW, you must use Smart licensing. For this lab, you will use the built-in 90 day evaluation
license.
a. In the FMC, navigate to System  Licenses  Smart Licenses.
b. Click on Evaluation Mode, and click Yes when prompted.
Step 4 Back in the FMC, navigate to Devices  Device Management.
a. Click Add  Add Device.

b. Fill out the information as in the figure below.
c. Click Register. Wait for the registration to complete. This may take a few minutes.
Task 2.2: Configure interfaces and default route

Step 5 Click on the pencil icon to edit the device settings.
Step 6 The Interfaces tab should be selected.

a. Click the pencil icon to edit the GigabitEthernet0/0 interface.

b. Select the IPv4 tab, and fill out the page as follows.
c. Click OK.
d. Click the pencil icon to edit the GigabitEthernet0/1 interface.
e. Select the IPv4 tab, and fill out the page as follows.
f. Click OK.
Step 7 Click Save to make the interface configuration available for further configuration.
Step 8 Select the Routing tab.
a. Select Static Route, and click the Add Route button.

b. Fill out the page as follows.
c. Click OK.
Step 9 Click Save to save the routing configuration
Task 2.3: Apply NAT policy to device

Step 10 In the FMC, navigate to Devices  NAT.
a. Click on the pencil icon to edit the Default PAT policy.
b. Click on Policy Assignments in the upper right corner of the policy page.
c. Add NGFW to Selected Devices.
d. Click OK.
Step 11 Click Save.

Task 2.4: Configure platform settings
Step 12 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. Add the NGFW device. See figure below.
c. Click Save.
d. Select Time Synchronization from the navigation panel on the left. Confirm that the Via
NTP from Management Center radio button is selected.
Task 2.5: 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.
Step 13 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.
d. Add 2 networks: IPv4-Private-All-RFC1918 and IPv6-Private-Unique-Local-Addresses.
The lab uses some RFC1918 addresses outside the firewall in this lab, but they are
limited in number, and should not cause confusion.
e. Click Save.
Step 14 Click Deploy in the upper right hand corner of the FMC.
a. Check the checkbox for the NGFW device, and expand the list to see the details.
b. To the right of Device Configuration, mouse over Details.
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.
Task 2.6: Test the NGFW deployment

Step 15 From the Jump Box desktop, launch PuTTY and double-click on the pre-definite Inside UNIX
server session. Login as root, password FPlab123!.
Step 16 In the Inside UNIX server CLI run ping cisco.com at the shell prompt. This should succeed.
Enter Ctrl+C to exit ping. This confirms NAT and routing.
Step 17 Test the IPS capabilities.
a. Run the following command from the Inside UNIX server CLI.
ftp outside.com
Login as guest, password FPlab123!.
b. Type cd ~root. You should see the following message:
421 Service not available, remote server has closed connection
c. Type quit to exit FTP.
d. In the FMC, navigate to Analysis  Intrusions  Events.
e. Observe that Snort rule 336 was triggered.

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 eventing processes. If this happens, try restarting these processes as follows.
One the NGFW CLI run the following command.
pmtool restartbytype EventProcessor
From the Jump Boxes 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!.
f. Click the arrow on the left to drill down to the table view of the events. Observe that
details of the event are presented.
g. 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.
h. Expand Actions and note that you could disable the rule from here – but do not!
i. Expand Packet Bytes to see the contents of the packet that triggered the rule.
Step 18 Test the file and malware blocking capabilities. These Wget commands can be cut and pasted
from the file on the Jump Box desktop called Strings to cut and paste.txt.
a. As a control test, use WGET to download a file that is not blocked.
wget -t 1 192.168.1.200/files/ProjectX.pdf
This should succeed..
b. Next use WGET to download the file blocked by type.
wget -t 1 192.168.1.200/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.
c. Finally use WGET to download malware.
wget -t 1 192.168.1.200/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.
d. In the FMC, navigate to Analysis  Files  Malware Events. Observe that one file,
Zombies.pdf, was blocked.
e. Click the arrow on the left to drill down to the table view of the events. Note that the host
172.16.1.200 is represented by a red icon.
This is the Inside UNIX 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 3 for details.
If you wish, you can try the following.

wget -t 1 192.168.1.200/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.
f. Click on the red computer icon. This will open the host profile page. Look over this page
and then close it.
g. Navigate to Analysis  Files  File Events. You should see information about all three
file events.
h. You can drill down for more details if you wish.


Lab 3: NAT and Routing
Task 3.1: Create objects needed for this lab exercise
Task 3.2: Configure static NAT
Task 3.3: Modify access control policy to allow outside access to wwwin
Task 3.4: Configure BGP
Task 3.5: Deploy the policy changes
Task 3.6: Test the configuration
Exercise Objective
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.
Note: The public server will be deployed in the inside network. It would be more realistic to deploy this in a DMZ,
but that would take more work. However, the lab pod has this capability. See Appendix 4 for information
about creating a DMZ in the lab pod.
Lab Exercise Steps

Step 1 Navigate to Objects  Object Management. Select Network from the left navigation pane, if not
already selected.
a. Click Add Network  Add Object.
b. For Name, enter wwwin.
c. For Network, enter 172.16.1.200.
d. Click Save.
e. Click Add Network  Add Object.
f. For Name, enter wwwout.
g. For Network, enter 192.168.1.250.
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.
Step 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.
Task 3.2: Configure static NAT

Step 4 Click the pencil icon to edit the Default PAT policy.
a. Select Auto NAT Rule from the NAT Rule drop-down list.
b. You will be at the Interface Objects tab. Select InZone and click Add to Source.
c. Select OutZone, and click Add to Destination.
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.

Task 3.3: Modify access control policy to allow outside access to wwwin
Step 7 Navigate to Policies  Access Control  Access Control. Edit the NGFW Access Control Policy.
a. For Name, enter Web Server Access.
b. Select into Mandatory 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.
Step 9 Click Save to save the access control policy changes
Task 3.4: Configure BGP

Step 10 Navigate to Devices  Device Management.

Step 11 Click on the pencil icon to edit the device settings.
Step 12 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 192.168.1.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.

f. Click Save to save the BGP configuration.
Task 3.5: Deploy policy changes

Step 13 Click Deploy in the upper right hand corner of the FMC.
Step 14 Check the checkbox for the NGFW device, and click the Deploy Button.

Step 15 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.
Task 3.6: Test configuration

Step 16 From the Jump Box desktop, open the PC3 link in the Remote Desktop folder. You will be logged
in as Administrator.
a. Open the Firefox browser using the link on the PC3 desktop.
b. Click the WWWOUT link on the bookmarks toolbar. The connection should succeed.
Step 17 On the Jump Box desktop, open the PuTTY link. Double click on the preconfigured session
called csr. Login as admin, password FPlab123!.
Step 18 On the CSR CLI, run the command show bgp, and confirm that 4 routes appear.
Step 19 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.
b. Run show bgp and show bgp rib-failure. This shows that the 192.168.1.0/24
route was not inserted in the routing table because there was a better route.
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 on the icon to the right of Status.
4. Click the Advanced Troubleshooting button.
4. Select the Threat Defense CLI tab.
From here you can run several NGFW CLI commands.
Step 20 From the Inside UNIX server session, type ping 62.24.45.1. This should succeed.

Lab 4: Rate Limiting
Task 4.1: Baseline transfer rate
Task 4.2: Configure rate limiting
Task 4.3: Test rate limiting
Exercise Objective
The objective of this exercise is to understand about the rate limiting options available on The Cisco
Firepower NGFW.
Lab Exercise Steps

Task 4.1: Baseline transfer rate
Step 1 On the Inside UNIX server CLI.
a. Run wget 192.168.1.200/files/test2.mov.
b. From the last line of the output, note the transfer rate on the last line of output. For these
pods, this should at least several MBps.
c. Run wget 192.168.1.200/files/ProjectX.doc. You may have to run this twice
to obtain a mulit-MBps transfer rate, as AMP may be slowing down the first download.
d. From the last line of the output, note the transfer rate on the last line of output. For these
pods, this should at least several MBps.
Note: Wget displays byte rate instead of bit rate. All that is important for this exercise to work is to make sure we
are receiving data at over 1 Megabyte per second = 8 Megabits per second.
Task 4.2: Configure rate limiting

Step 2 In the FMC, navigate to Devices  QoS.
Step 3 Click the New Policy button.
a. Enter a name like NGFW QoS Policy.
b. Select the NGFW from Available Devices and click Add to Policy.
c. Click Save.

Step 4 Wait a few seconds for the policy to open up for editing.
a. For Name, enter Multimedia.
b. Select Interfaces in Destination Interface Objects from the Apply QoS On drip-down list.
c. For Download/Upload Limit, enter 1, meaning 1 Megabit per second.
Note: You can set different download and upload rates by clicking on Advanced.
d. The Interface Objects tab should be selected. Select InZone and click Add to Source.
e. Select OutZone, and click Add to Destination.
Note: There are two types of interface objects: security zones and interface groups. The key difference is that
interface groups can overlap. Either can be used in QoS policies.
f. Select the Applications tab.

g. Enter multi into the Application Filters search field.
h. Select the three multimedia application filters and click Add to Rule.

Step 6 Click OK to save the rule.
Step 7 Click Save to save the QoS Policy.
Step 8 Deploy the policy changes as you have before. You can ignore the warning. Click Proceed.
Step 9 Wait for the deployment to complete.
Task 4.3: Test rate limiting

Step 10 Return to the Inside UNIX server CLI.
a. Run wget 192.168.1.200/files/test2.mov.
b. From the last line of the output, note the transfer rate on the last line of output. The rate
should be about 124 KBps (= 1 Mbps).
c. Run wget 192.168.1.200/files/ProjectX.doc.
d. From the last line of the output, note the transfer rate on the last line of output. The rate
should be about the same as the baseline established in Task 4.1.

Lab 5: Site-to-site VPN
Task 5.2: Configure site-to-site VPN
Task 5.3: Create NAT exemption
Task 5.4: Modify the access control policy and deploy changes
Task 5.5: Test site-to-site VPN
Exercise Objective
The objective of this exercise is to configure a site-to-site VPN tunnel between the NGFW and an ASA.
Lab Exercise Steps

Step 1 Navigate to Objects  Object Management. Select Network from the left navigation pane, if not
already selected.
b. For Name, enter MainOfficeNetwork.
c. For Network, enter 172.16.1.0/24.
d. Click Save.
e. Click Add Network  Add Object.
f. For Name, enter BranchOfficeNetwork.
g. For Network, enter 172.16.255.0/24.
h. Click Save.
Task 5.2: Configure site-to-site VPN

Step 2 Navigate to Devices  VPN. Click Add VPN  Firepower Threat Defense Device.
Note: The other VNP choice, Firepower Device, is for configuring secure tunnels between Firepower devices.
Step 3 For Name enter NGFWtoASA.
Step 4 Confirm that for Network Topology, Point to Point is selected. Confirm that for IKE Version,
IKEv1 is not checked, and IKEv2 is checked.

Step 5 Click the green plus to the right of Node A. Fill out as in the figure below, and then click OK.
Step 6 Click the green plus to the right of Node B. Fill out as in the figure below, and then click OK.

Step 7 Select the IKE tab.
a. Under IKEv2 Settings, for Policy, confirm that DES-SHA-SHA is selected.
Note: Since FMC is running on Evaluation mode, 3DES and higher encryption are not supported, so we need to
create new IKE/IPSec default proposal with DES encryption for this exercise.
b. Under IKEv2 Settings, for Pres-shared Key Type, select Manual.
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 cisco123, and confirm the entry.
Step 8 Select the IPsec tab, confirm that the IKEv2 IPsec Proposal is DES_SHA-1.
Step 9 Click Save to save the VPN settings.

Task 5.3: Create NAT exemption
Step 11 Click the pencil icon to edit the Default PAT policy.
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.
i. Select InZone and click Add to Source.
ii. Select OutZone, and click Add to Destination.
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.


Task 5.4: Modify the access control policy and deploy changes
You will now create a rule to allow traffic between the Branch office and Main office.
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.
i. Select InZone and click Add to Destination.
ii. Select OutZone, and click Add to Source.
e. Select the Networks tab, select BranchOfficeNetwork, and click Add to Source.
f. Select the Inspection tab.
g. Click Add to add this rule to the access control policy.
Step 17 Deploy the changes, as you have been. Wait for the deployment to complete.
Task 5.5: Test site-to-site VPN

Step 18 From the NGFW CLI, type show crypto ipsec sa. There should be no IPSec security
associations.
Step 19 From the Inside UNIX server CLI, type ping branch.example.com. Wait a few seconds, and
the ping should succeed.
Step 20 From the NGFW CLI, type show crypto ipsec sa. There should now be an IPSec security
association.

Lab 6: Basic Authentication
Task 6.1: Configure a realm
Task 6.2: Create an identity policy
Task 6.3: Modify the access control policy to use the identity policy and deploy
Note: In this module you perform the minimum configuration required for ISE integration. If you want a more
comprehensive lab on authentication, please look at Bonus Lab B4. This includes the configuration of the
Cisco Firepower User Agent.
Exercise Objective
The objective of this exercise is to perform a minimal passive authentication configuration so it is possible
to perform the ISE integration exercise, Lab 7.
Lab Exercise Steps

Task 6.1: Configure a realm
Step 1 In the FMC, navigate to System  Integration and select the Realms tab.
Step 2 Click on the text Add a new realm, or click the New realm button. Enter the following information,
click Test, and then click OK. You can, if you wish, cut and paste most of this from the Strings to
cut and paste text file on the Jump Box desktop.
Attribute Name Attribute Value
Name EXAMPLE
Type AD
AD Primary Domain example.com
AD Join Username [email protected]
AD Join Password FPlab123!
Directory Username [email protected]
Directory Password FPlab123!
Base DN dc=example,dc=com
Group DN dc=example,dc=com
Group Attribute Member
Note: Note that AD Join Username has been added to support Kerberos active authentication.
Step 3 Click Add directory.

a. For Name, enter dc.example.com.

b. Click the Test button. If the test is not successful, check your realm and directory
configuration. Click OK to exit test.
c. Click OK to save the directory configuration.
Step 4 Select the User Download tab. Check the Download users and groups checkbox.
Step 5 Click Save.
Step 6 Enable the realm and download the users and groups, as shown below. Click Yes to confirm the
download. Click OK.
Task 6.2: Create an identity policy

Step 7 In the FMC, navigate to Polices  Access Control  Identity.
Step 8 Click on the text Add a new policy or click the New Policy button
a. For Name enter NGFW Identity Policy.
b. Click Save. Wait a few seconds for the policy to open for editing.
Step 9 Select the Rules tab. Click Add Rule.
a. For Name, enter Default Authentication Rule.
b. Keep Action set to Passive Authentication.
c. Click the Realm & Settings tab on the right side of the dialog.
d. Select EXAMPLE (AD) from the Realm drop-down list.
e. Click Add to save the rule.

Step 10 Click Save to save the identity policy.
Task 6.3: Modify the access control policy to use the identity policy and deploy
Step 11 Navigate to Policies  Access Control  Access Control. Edit the NGFW Access Policy.
Step 12 Click on the link None to the right of the string Identity Policy above the policy rules.
Step 13 From the drop-down list, select the NGFW Identity Policy and click OK.
Step 15 Deploy the policy changes as you have done in previous labs.

Lab 7: ISE Integration
Task 7.1: Configure ISE integration
Task 7.2: Utilize ISE metadata the access control policy
Task 7.3: Configure the access control policy to use ISE integration
Task 7.4: Test ISE passive authentication
Task 7.5: Create a correlation policy using the ISE remediation module
Task 7.6: Test the ISE remediation module
Exercise Objective
You will configure the FMC to tell ISE to quarantine any endpoint that has encountered malware, it will tell
ISE to quarantine the endpoint. Once the endpoint is quarantined, it will only have access to one
remediation server outside.com (192.168.1.200).
Upon successful completion of this exercise, the student will be able to:
• Integrate ISE with FMC
• Configure Firepower to use the Cisco Identity Services Engine (ISE) for passive authentication.
• Demonstrate that SGTs create on ISE are immediately available on the FMC for policy configuration.
• Configure the access control policy based on ISE metadata
• Deploy the ISE remediation module in an FMC Correlation Policy
Note: Since we don’t have 802.1x in the pod, we will use a supplicant simulator in the RADIUS Simulator folder on
the Jump Box desktop. Essentially, the Jump Box will act like the switch, sending autentication information
to ISE.
The ISE configuration has been completed for you. This lab is not intended as an ISE configuration lab.
Lab Exercise Steps

Task 7.1: Configure ISE integration
Step 1 In the FMC, navigate to Objects  Object Management. In the left navigation pane, select PKI
 Trusted CAs.
a. Click Add Trusted CA.
b. For Name, enter Example.
c. Click Browse, and browse the Desktop  Certificates.
d. Upload Example_CA.cer.
e. Click Save.
Step 2 In the FMC navigate to System  Integration, and select the Identity Sources tab.
Step 3 Click the Identity Services Engine button.
a. For Primary Host Name/IP Address, enter ise.example.com.
b. Select Example from the pxGrid Server CA drop-down list.

c. Select Example from MNT Server CA drop-down list.
d. Click the Add button to the right of the FMC Server Certificate drop-down list.
e. Click the green circle (with plus sign) to the right of the Server Certificate drop-down list.
i. For Name, enter FMCpxgrid.
ii. Click the Browse button to the right of the text Certificate Data or, choose a file,
and browse to Desktop  Certificates.
iii. Upload fmc.cer.
iv. Click the Browse button to the right of the text Key or, choose a file, and browse
to Desktop  Certificates.
v. Upload fmc.key.
vi. Click Save.
f. Click Test. If the connection fails click Test again. In any case, click on Additional Logs
to see details
g. If the test continues to fail, check your configuration.
h. Click Save.

Task 7.2: Utilize ISE metadata in the access control policy
Step 4 Navigate to Policies  Access Control Access Control. Edit the NGFW Access Control Policy.
a. Click Add Rule, and select the STG/ISE Attributes tab.
b. In the Available Attributes column, select Security Group Tag. Confirm that the Available
Metadata column auto-populates.
c. Note that the first SGT in the list is any. You will see an SGT above this in Step 6.
d. In the Available Attributes column, select Device Type. Confirm that the Available
e. In the Available Attributes column, select Location IP. Confirm that the Available
Step 5 In the Firefox browser you have been using to manage the FMC, open another tab and click on
the ISE bookmark on the bookmark toolbar.
a. Login to ISE. The login screen should be populated, but in case you need to know, the
login is admin, password FPlab123!.
b. Navigate the Administration  pxGrid Services. Notice that in the list of clients, there are
two entries related to FMC.
c. Expand iseagent-fmc.example.com.
d. Note the 6 capabilities, or topics of information, that the FMC is subscribed to. These
include the 3 capabilities already available in 6.0:

• EndpointProfileMetaData – contains the ISE device information
• SessionDirectory – defines the ISE session attributes
• TrustSecMetaData – defines the Security Group Tag (SGT) information
The other capabilities are related to the remediation capabilities covered later in this lab.
Step 6 Since the FMC is subscribed to the pxGrid capabilities, changes to ISE session attributes should
be synchronously communicated to the FMC. In this step this will be confirmed.
a. In ISE, navigate to Work Centers  TrustSec  Components.
b. Click Add. For Name, enter 0TestTag. Click Submit.
c. In the FMC, you were editing a rule. In the Available Attributes column, switch from
Location IP back to Security Group Tag. Note that the SGT 0TestTag is now available.
d. In the FMC, navigate to System  Monitoring  Syslog.
e. Search for pxgrid. This can be useful for troubleshooting ISE integration issues.
Note: If you need to troubleshoot ISE communication issues, in the FMC, navigate to System  Monitoring 
Syslog, Search for pxgird in the syslog messages.
Step 7 Keep the Add Rule window open, and go on to the next task.
Task 7.3: Configure an the access control policy to use ISE integration
Step 8 In the Add Rule page perform the following.
a. Call the rule Block SSH for HR.

b. In the Insert drop-down list, change below rule, to into Mandatory.
c. Set the action to Block with reset.
d. Select the Applications tab, and type SSH into the Available Applications search field.
Then select SSH and OpenSSH. Click Add to Rule.
e. Select the Users tab.
i. In the Available Realms column, select Example. The Available Users column
will populate.
ii. In the Available Users column, select HR.
iii. Click Add to Rule.
f. Select Logging tab. Check the Log at Beginning of Connection checkboxes.
g. Click Add to add the rule to the policy.
a. Call the rule Quarantine Restriction.

b. In the Insert drop-down list, change below rule, to above rule, and choose rule 1.
d. Select the SGT/ISE Attributes tab.
i. In the Available Attributes column, select Security Group Tag.

ii. In the Available Metadata column, select Quarantined_Systems.
e. Select Logging tab. Check the Log at Beginning of Connection checkbox.
f. Click Add to add the rule to the policy.
a. Call the rule Quarantine Access.

b. In the Insert drop-down list, change below rule, to above rule, and choose rule 1.
c. Set the action to Allow.
d. In the networks tab, at the bottom of the Destination Networks column, type
192.168.1.200, and click Add.
e. Select the SGT/ISE Attributes tab.
i. In the Available Attributes column, select Security Group Tag.
ii. In the Available Metadata column, select Quarantined_Systems.
f. In the Inspection tab, set the Intrusion Policy to Demo Intrusion Policy.
g. In the Inspection tab, set the File Policy to Demo File Policy.
h. Select Logging tab. Check the Log at Beginning of Connection and Log at End of
Connection checkboxes.
i. Click Add to add the rule to the policy.
Step 11 Click Save to save the access control policy. You can ignore the warning about the identity
policy.
Step 12 Deploy the access control policy, and wait for the deployment to complete. You can ignore the
warnings.
Task 7.4: Test ISE passive authentication

Step 13 Open RADIUS Simulator folder on the Jump Box desktop. Double click on StartSessions.bat.
Using RADIUS, this will tell ISE that 4 users just successfully authenticates using 802.1x.
Step 14 In ISE, navigate to Operations  RADIUS Livelog. Confirm that Rita, Ira, Harry and Dilbert have
authenticated and have been given different authorization profiles.
Step 15 FMC, navigate to Analysis  Users  User Activity. Confirm that the FMC has information about
Rita, Ira, Harry and Dilbert. If this information is not in the User Activity page, double click
on StartSessions.bat again, and then refresh the User Activity page.
Step 16 On the PC1 desktop, open the Users folder.
a. Click on Ira (Investment). This will set the IP address of PC1 to the IP that ISE told the
FMC Ira is using.
b. Open PuTTY on the PC1 desktop. Click on the preconfigured link outside.com:9922. The
connection should be allowed.
c. Click on Harry (HR). This will set the IP address of PC1 to the IP that ISE told the FMC
Harry is using.

d. Open PuTTY on the PC1 desktop. Click on the preconfigured link outside.com:9922. The
connection should reset.
Step 17 FMC, navigate to Analysis  Connections  Events. Show details of the events from the
previous step. You may wish to filter by destination port.
Task 7.5: Create a correlation policy using the ISE remediation module
Step 18 In the FMC navigate to Policies  Actions  Instances.
Step 19 Select pxGrid Mitigation from the Select a module type drop-down list. Click Add.
a. For Instance Name, enter pxGridTestInstance. Click Create.
b. At the bottom of the Edit Instance page, select Mitigate Source from the Add a new
remediation of type drop-down list. Click Add.

c. For Remediation Name, enter TestRemediation. Leave the Mitigation Action set to
quarantine. Click Create.

Step 20 Navigate to Policies  Correlation.
Step 21 Click the Rule Management tab.
a. Click Create Rule.
b. For Rule Name, enter MalwareDetected.
c. Under Select the type of event for this rule, select a Malware event occurs and by
network-based malware detection from the drop-down lists. Click Save.
Step 22 Click the Policy Management tab.

a. Click Create Policy.
b. For Rule Name, enter MalwareMitigation.
c. Click Add Rules. Check the MalwareDetected rule. Click Add.

d. Back in the Correlation Policy Information page, click the responses icon to the right of
the rule that was just added.
e. Highlight TestRemediation, and click the up-arrow to move it from Unassigned

Responses to Assigned Responses. Click Update.
f. Confirm that your Correlation Policy information matches what is in the following picture.
Click Save.
g. Activate the Correlation Policy.

Task 7.6: Test the ISE remediation module
Step 23 Open RADIUS Simulator folder on the Jump Box desktop. Double click on RadiusListener.bat.
This will listen for RADIUS messages from ISE.
Step 24 On PC1, in the Users folder, click on Dilbert (Engineering), to start using Dilbert’s IP
(172.16.1.25).
Step 25 On PC1, using Firefox, navigate to http://outside.com. Click the Files folder, and try to open
Zombies.pdf.
a. The browser connection should be reset.
b. You should see a RADIUS message from ISE sent to the RADIUS listener.
Step 26 In the FMC, navigate to Analysis  Correlation  Correlation Events. A single event should be
present.
Step 27 Open RADIUS Simulator folder on the Jump Box desktop. Double click on StartSessions.bat.
This sends a CoA to ISE.
Step 28 In ISE, navigate to Operations  RADIUS Livelog. You should see the quarantine event.
Step 29 Wait a minute. In the FMC, navigate to Analysis  Users  User Activity. You should see that
the Quarantined_Systems SGT is now assigned to the Dilbert.
Step 30 Back on PC1, confirm that the only remaining access is to outside.com (192.168.1.200). For
example try to use the Alt-Outside (192.168.1.202) bookmark on the bookmark toolbar. You
should be blocked.
Step 31 On PC1, in the Users folder, click on Default, to return the IP 172.16.1.21. Otherwise
subsequent labs using this endpoint might break.

Appendix 1: REST API and Policy Hierarchy
Task A1.1: Create access control policies using the REST API
Task A1.2: Create access control policy rules using the API Explorer
Task A1.3: Build an access control policy hierarchy
Exercise Objective
The objective of this lab is to create a simple, generic access control policy and NAT policy. These
policies could be applied to multiple devices. You will apply these policies to a NGFW in Lab exercise 2.
Lab Exercise Steps

Task A1.1: Create access control policies using the REST API
The policy hierarchy will consist of two policies.
• A global policy that would apply to all devices
• A policy for a single device, focused on control
Step 1 Open the Firepower Management Center by double-clicking on the Firefox icon labeled FMC on
the Jump Box desktop. The login name and password will prepopulate.
Step 2 Navigate to Policies  Access Control  Access Control.
Step 3 You will now run scripts that use the FMC REST API to create the 2 policies.
a. From the Jump Box desktop, launch PuTTY and double-click on the pre-defined Inside
UNIX server session. Login as root, password FPlab123!.
b. Generate a token to access the FMC REST API with the following command:
gettoken
This command will output two tokens, but you will only use the first.
c. Highlight the first token to copy it, so you can paste it into the next command.
d. Create two policies by running the following command:
makepolicy <token> BLOCK 'Global AC Policy' 'Device AC Policy'
BLOCK is the default action for the policy.
Below is an example of sub-steps c and d.
[root@unix ~]# gettoken
X-auth-access-token: 1ceea138-4b0a-469f-A1d1-fef89cea085f
X-auth-refresh-token: c47201ef-76a4-4731-9752-bb1e694d55ed
[root@unix ~]# makepolicy 1ceea138-4b0a-469f-A1d1-fef89cea085f BLOCK
'Global AC Policy' 'Device AC Policy'
Sending request to create policy Global Access Control Policy
Status code is 201
Create was successful
Sending request to create policy DEVICE SPECIFIC Access Control Policy
Status code is 201
Create was successful
[root@unix ~]#
The Cisco Firepower NGFW November 2016 A1-1

Step 4 Back in the FMC, refresh the page, and confirm that 2 new access control policies now exist.
Note: These scripts are in /usr/local/bin if you wish to inspect them.
The gettoken script runs the following curl command, and parses the output:
curl -k -v -X POST --user restapiuser:FPlab123!
https://fmc.example.com/api/fmc_platform/v1/auth/generatetoken
The makepolicy script is python script with a loop that submits POST requests to
https://fmc.example.com/api/fmc_config/v1/domain/default/policy/accesspolicies
of the form:
"type": "AccessPolicy"
"name": "<Policy name>
"defaultAction": { "action": <ACTION>}
The token in an X-auth-access-token header of the HTTP request.
Task A1.2: Create access control policy rules using the API Explorer
You will now use the API Explorer to add rules to these policies. This tool helps you understand the
syntax for the REST API, and can be used to generate JSON, Python and PERL scripts.
Step 5 Access the API Explorer
a. Open a new tab in the Firefox browser on the Jump Box.
b. Click on the API Explorer bookmark on the bookmark toolbar.
c. Login as restapiuser, password FPlab123!, but this should pre-populate. By using a
different user, you will not kick the admin user out of the FMC UI session in the other tab.
Step 6 Retrieve the JavaScript code for the policies you created with the makepolicy script.
a. Click on Policy in the API INFO pane on left side of the page.
b. Click the GET button next to
/api/fmc_config/v1/domain/default/policy/accesspolicies
link in the middle pane of the page. This is the first link in this pane.
c. Click the GET button in the API CONSOLE pane on right side of the page. This will
retrieve JavaScript describing the Access Control Policies on the FMC.
See the figure below.

Step 7 In the JavaScript output, find the UUID (called id in the JavaScript output) for the Global AC
Policy and copy and paste it into the Container UUID.
a. Click the POST button next to

/api/fmc_config/v1/domain/default/policy/accesspolicies/{containerUUID}/accessrules
link in the middle pane. This is the second link in this pane.
b. On the Jump Box desktop, in the Files folder, open the file called
Access_Policy_Rules.txt.
c. Cut the first rule from this text file, and paste it into the test field in the API CONSOLE in
the right pane.
d. Click the POST button in the API CONSOLE pane on right side of the page. This will
create the first access control policy rule.
e. Repeat sub-steps c and d, but use the second rule in the text document.
Step 8 Repeat Steps 6 and 7, but this time cut and paste the Id for the Device AC Policy, and use the
third rule in the test file Access_Policy_Rules.txt.

Note: Sometimes the responses returned by the API Console are abbreviated. For example, if you get the rules of
a policy (with the GET button), you will not see details of the rules. You can modify the query by entering
expanded and true in the query parameter:
Step 9 Although you will not use this in the lab, create a template for a Python script to create the last
rule you created.
a. Scroll down to the bottom right of the API Explorer
b. Click the Export operation in button. You may have to scroll down further to see the
drop-down list.
c. Select Python script. A Python script will appear in the middle of the web page.
Task A1.3: Build an access control policy hierarchy

Step 10 In the FMC, click the pencil icon to edit the Global AC Policy. Note that there are two rules, and
they are both in the Default section.
a. Move that Block Unacceptable Sites rule to the Mandatory section. This can be done by
dragging the rule.
b. Select the HTTP Responses tab. Select System-Provided from the Block Response
Page drop-down list.
c. Click Inheritance Settings in the upper right part of the page.

d. Check the HTTP Response check box.
e. Click OK.
f. Confirm that your policy configuration matches the following figure.
g. Click Save to save the Global Access Control Policy settings.

h. Click Cancel to exit editing the Global Access Control Policy.
Step 11 Click the pencil icon to edit the Device Access Control Policy. Note that there is one rule, and it
is in the Default section.
a. Click Inheritance Settings in the upper right part of the page.
b. Select Global Access Control Policy from the Select Base Policy drop-down list.

c. Note that the Http Response check box is greyed out.
d. Click OK. Click Save to save the configuration of the Device Access Control Policy.
e. Confirm that your policy configuration matches the following figure.
f. Confirm that two rules are inherited from the Global Access Control Policy. Confirm that
you cannot modify or delete these rules.
Step 12 Select the HTTP Responses tab. Confirm that the settings are locked.

Appendix 2: Prefilter Policies
Task A2.1: Investigate NGFW default behavior for tunneled traffic
Task A2.2: Create a tunnel tag
Task A2.3: Create a prefilter policy
Task A2.4: Modify the access control policy and deploy changes
Task A2.5: Test the prefilter policy
Exercise Objective
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 Lab 3 as a prerequisite. This is because the exercise assumes the static NAT rule, which
translates 172.16.1.200 to 192.168.1.250. To understand the configuration of the tunnel interface, you can
inspect /etc/sysconfig/network-scripts/ifcfg-tun0 on the inside and outside servers.
Lab Exercise Steps

Task A2.1: Investigate NGFW default behavior for tunneled traffic
In this task, you will confirm that the access control policy rules apply the tunneled traffic.
Step 1 You should still have the SSH session open to the Inside UNIX server.

Step 2 From the Jump Box desktop, launch PuTTY and double-click on the pre-definite Outside UNIX
server session. Login as root, password FPlab123!.
Step 3 Create a GRE tunnel between the Inside UNIX server and Outside UNIX server.
a. On the Outside UNIX server CLI, type ifup tun0.

b. On the Inside UNIX server CLI, type ifup tun0.
Step 4 Test the IPS capabilities.
a. Run the following command from the Inside UNIX server CLI.
ftp 10.3.0.2
b. Login as guest, password FPlab123!.
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.
Step 5 In the FMC, navigate to Analysis  Intrusions  Events.
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.
Step 6 Test the file and malware blocking capabilities by running the following commands on the Inside
UNIX server CLI.
Note: These Wget commands can be cut and pasted from the file on the Jump Box desktop called Strings to cut
and paste.txt.
a. As a control test, use WGET to download a file that is not blocked.

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
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.
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 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.
Step 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.
Task A2.2: Create a tunnel tab

Step 8 Navigate to Objects  Object Management.
a. Select Tunnel Tag from the left navigation pane.
b. Click Add Tunnel Tag.

c. For Name, enter GRE.
d. Click Save.
Task A2.3: Create a prefilter policy

Step 9 Navigate to Policies  Access Control  Prefilter.
Step 10 Click the New Policy button. Enter a name like NGFW Prefilter Policy. Click Save.
Step 11 Wait a few seconds for the policy to open up for editing
Step 12 Click Add Tunnel Rule.
a. For Name, enter Tag GRE Traffic.
b. Select GRE from the Assign Tunnel Tag drop-down list.
c. Select the Encapsulation & Ports tab. Check the GRE checkbox.
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.

Step 13 Click Save to save the prefilter policy.
Task A2.4: Modify the access control policy and deploy changes
Step 15 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.
Step 16 Select the Rules tab.
a. Call the rule Block ICMP Over GRE.

b. Select into Mandatory from the Insert drop-down list.
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 Logging tab. Check the Log at Beginning of Connection checkbox.
g. Click Add to add the rule to the policy.
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.
e. Click Add to add the rule to the policy.
Step 20 Deploy the changes, as you have been. Wait for the deployment to complete.
Task A2.5: Test the prefilter policy

Step 21 On the Outside UNIX server, run tcpdump -n -i tun0 to monitor tunnel traffic.
Step 22 Run the following commands on the Inside UNIX server CLI.
a. wget 10.3.0.2
This should succeed.
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
Step 23 Inspect the output of the tcpdump command on the Outside UNIX server to confirm that the ping
is not making it to 10.3.0.2.

Appendix 3: 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 A3.1: NTP settings
Configuration A3.2: Demo file policy
Configuration A3.3: Demo intrusion policy
Configuration A3.4: Demo SSL policy
Configuration A3.5: Custom detection list
Configuration A3.6: Add resetapiuser.
Configuration A3.1: NTP settings
Step 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 172.16.1.100.
d. Click Save.
Configuration A3.2: Demo file policy
Step 2 Navigate to Policies  Access Control  Malware & File.
Step 3 Click the New File Policy button. Enter a name like Demo File Policy. Click Save.

Step 4 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 checkbox.
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.
Step 5 Click Add File Rule. This rule will detect and store Office documents, and PDFs.
a. Check the Store files checkbox.
b. Under File Type Categories, check Office Documents, and PDF files. Click Add.
c. Your screen should look like the figure below.
d. Click Save.
Step 6 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: 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
Step 7 Confirm that you file policy rules look like the following.
Step 8 Select the Advanced tab. Confirm that Enable Custom Detection List is selected. Check the
Inspect Archives.
Note: Un-inspectable archives are corrupt archive, or archives with a depth that exceeds the Max Archive Depth.
Step 9 Click the Save button in the upper-right to save the file policy.

Configuration A3.3: Demo intrusion policy
Step 10 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 Box
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.
Step 11 Navigate to Policies  Access Control  Intrusion.
Step 12 Click the Create Policy button.
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.

Step 13 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.
Step 14 Click on Policy Information in the menu on the upper-left.
Step 15 Click Commit Changes. Click OK.
Configuration A3.4: Demo SSL policy

Step 16 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 Box 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.
Step 17 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.
Navigate to Objects  Object Management  Network.

b. For Name, enter Infrastructure.
c. For Network, enter 172.16.1.80-172.16.1.130.
d. Click Save to save the network object.

Step 18 Navigate to Policies  Access Control  SSL.
Step 19 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.
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.
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.
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.
Step 23 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 A3.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...
Step 24 Navigate to Objects  Object Management  File List. 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 Box
desktop.
Step 25 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 Box desktop.
d. Select Zombies.pdf, and click OK.

e. Click Calculate and Add SHAs.
f. Click Save.
Configuration A3.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.
Step 26 Navigate to System  Users. Click Create User.
a. For User Name, enter restapiuser.
b. For Password, enter FPlab123!. Confirm the password.
c. Set Maximum Number of Failed Logins to 0.
d. Check the Administrator checkbox.
e. Click Save.

Appendix 4: Additional Pod Resources
AMP Private Cloud
To use the AMP Private Cloud, perform the following steps.
Step 1 Access the AMP Private Cloud Portal (not the AMP Private Cloud Console).
a. Open a new tab in the Firefox browser on the Jump Box.
b. Click on the Private Cloud Portal bookmark on the bookmark toolbar.
c. Log in. The password is FPlab123!. This should prepopulate.
Step 2 Navigate to Integrations  Defense Center. In the box labelled 4, click the button to download
the certificate.
The name of the certificate is combined.fireamp.crt. It will be saved to the Downloads folder on
the Jump Box.
Step 3 Back in the FMC, navigate to AMP  AMP Management. .
a. Click the Add AMP Cloud button.
b. Fill out the page as follows. Note that you will have to click Browse, and upload the
certificate from the Downloads directory on the Jump Box.
c. Click Register, and click Yes when prompted.

d. Click Yes again to allow browser redirection
You will be redirected to the AMP Console.

e. Log into the AMP Console. The login is [email protected], password
FPlab123!, but this should auto-populate.
f. Click the Allow button in the Applications box. You will be redirected back to the FMC.
Traffic generator
There is a traffic generator built into the Inside UNIX server. This will generate port 80 traffic from multiple
source addresses. To launch the traffic generator:
Step 1 Use the PuTTY link on the Jump Box desktop to connect to the Inside UNIX server. There is a
preconfigured session in PuTTY session.
Step 2 Login as root, password FPlab123!.
Step 3 Step 3 Type tgstart to start the traffic generator.
Note: Once the traffic generator starts, it will generate output to the PuTTY window. This may be useful to monitor
the traffic generator. You can still type commands into the window (like tgstop), but this is awkward. If you
want, you can close the PuTTY session – the traffic generator will keep running.
Step 4 Type tgstop to stop the traffic generation, if you wish.
DMZ
For simplicity we avoided using a separate DMZ when configuring the public web server. However, we
can configure a separate DMZ if desired. The network is 192.168.255.0/24.
The following devices have interfaces that can be used for DMZ interfaces.
• The NGFW has GigabitEthernet0/2 on this network. This is un-configured.
• ASAv: Interfaces GigabitEthernet0/5, GigabitEthernet0/6, GigabitEthernet0/7 and
GigabitEthernet0/8. These are un-configured.
• CSR: Interface GigabitEthernet2. This interface is un-configured.
• The Inside UNIX server has 2 IP addresses in this network: 192.168.255.200 (dmz.example.com)
and 192.168.255.201 (altdmz.example.com). Both these addresses have webservers running on
port 80. They also have ftp servers running. These are the only addresses in this range in use.
Note: To conserve VLANs, the DMZ shares the same VLAN as the inside network, but you will only notice this if
you snoop the network traffic.

Ltrsec 2101 LG

Uploaded by

Copyright:

Available Formats

Ltrsec 2101 LG

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

Ltrsec 2101 LG

Uploaded by

Copyright:

Available Formats

The Cisco Firepower NGFW – Lab

Arial Bold Used to indicate emphasis

Arial Italic Used for elements is the UI, links, etc.

The Cisco Firepower NGFW November 2016 I-1

The Cisco Firepower NGFW November 2016 I-2

Lab Topology and Access

The Cisco Firepower NGFW November 2016 I-3

[Pod Edge Router – no user access] [192.168.1.1]

Jump Box 172.16.1.50, 192.168.1.50

ASAv 192.168.1.4, 172.16.255.1

CSR 192.168.1.3 (and others)

PC1 (not a domain member) 172.16.1.21

PC2 (domain member) 172.16.1.22

DC (Domain Controller) 172.16.1.100

FMC (Firepower Management Center) 172.16.1.120

ISE (Identity Services Engine) 172.16..1.130

UNIX (Inside CentOS server) 172.16.1.200

SFUA (Sourcefire User Agent) 172.16.1.210

NGFW (FTD) 172.16.1.82

PC3 (For AnyConnect testing) 192.168.1.23

The Cisco Firepower NGFW November 2016 I-4

Access To Account (username/password)

Jump Box Administrator/FPlab123!

ASAv SSH access: admin/FPlab123!

Windows (except Jump Box) administrator/FPlab123!

ISE (Identity Services Engine admin/FPlab123!

Inside UNIX Server (unix.example.com) root/FPlab123!

Outside UNIX Server (outside.com) root/FPlab123!

FMC (Firepower Management Center) admin/FPlab123!

NGFW (FTD) admin/FPlab123!

Account (username/password) Group

The Cisco Firepower NGFW November 2016 I-5

Lab Exercise Steps

Task 1.2: Create an access control policy

The Cisco Firepower NGFW November 2016 1-1

c. The Zones tab should already be selected.

e. Click Add to add the rule.

Step 9 Click Save to save the access control policy.

The Cisco Firepower NGFW November 2016 1-2

e. Select the Translation tab.

h. Click OK to save the NAT rule.

Step 13 Click Save to save the NAT policy.

The Cisco Firepower NGFW November 2016 1-3

The Cisco Firepower NGFW November 2016 1-4

Lab Exercise Steps

Step 2 Type the command configure manager add fmc.example.com cisco123.

The Cisco Firepower NGFW November 2016 2-1

Task 2.2: Configure interfaces and default route

Step 6 The Interfaces tab should be selected.

The Cisco Firepower NGFW November 2016 2-2

The Cisco Firepower NGFW November 2016 2-3

Task 2.3: Apply NAT policy to device

c. Add NGFW to Selected Devices.

The Cisco Firepower NGFW November 2016 2-4

Task 2.5: Modify the network discovery policy

The Cisco Firepower NGFW November 2016 2-5

The Cisco Firepower NGFW November 2016 2-6

Task 2.6: Test the NGFW deployment

The Cisco Firepower NGFW November 2016 2-7