FJBT Network Security FTD Lab Guide v1 0d

Protecting the Network with
Firepower NGFW Lab Guide

Product Overview
The Cisco Firepower Next Generation Firewall (NGFW) is Ciscos premier threat-focusses NGFW. This
product combines Advanced Malware Protection (AMP), Firepower IPS/IDS, and ASA capabilities.
Lab Overview
This lab is designed to help attendees understand the key features available with the NGFW.
There are 14 labs, representing 10-12 hours of training. For this reason, students are encouraged to
select which labs are most interesting to them. The lab exercises have been divided into 4 groups.
Mandatory Labs. These labs must be completed before attempting any other labs. By the end of
these 2 lab exercises, you will have provisioned a NGFW with a simple, but reasonable firewall policy.
This includes stateful firewall with NAT, AMP and IPS.
Network Track. These 4 labs cover static NAT, dynamic routing, rate limiting and site-to-site VPN.
Security Track. These 4 labs cover some of the advanced security features, including basic
authentication and integration with the Cisco Identity Services Engine (ISE).
Bonus Labs. These 4 labs cover a variety of features, including OpenAppID, security intelligent
including DNS sinkholing, the REST API, and advanced authentication.
After completing the mandatory exercises, any of the remaining lab exercises may be performed.
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.
Developers
The labs pod and lab guide were created by the Technical Marketing team of the Security Business
Group at Cisco Systems.
Protecting the Network with Firepower NGFW (v1.0) July 2016 I-1
Lab Exercises
This lab guide includes the following exercises:
Mandatory Labs
Lab M1: Basic Policy Configuration ................................................................................................... M1-1
Task M1.1: Create security zone objects ..................................................................................... M1-1
Task M1.2: Create an access control policy ................................................................................. M1-1
Task M1.3: Create a NAT policy ................................................................................................... M1-3
Lab M2: NGFW Deployment.............................................................................................................. M2-1
Task M2.1: Register the NGFW with the FMC ............................................................................. M2-1
Task M2.2: Configure interfaces and default route....................................................................... M2-2
Task M2.3: Apply NAT policy to device ........................................................................................ M2-4
Task M2.4: Configure platform settings ........................................................................................ M2-5
Task M2.5: Modify the network discovery policy .......................................................................... M2-5
Task M2.6: Test the NGFW deployment ...................................................................................... M2-7
Network Track
Lab N1: NAT and Routing .............................................................................................................. N1-1
Task N1.1: Create objects needed for this lab exercise ............................................................... N1-1
Task N1.2: Configure static NAT .................................................................................................. N1-2
Task N1.3: Modify access control policy to allow outside access to wwwin ................................ N1-3
Task N1.4: Configure BGP ........................................................................................................... N1-3
Task N1.5: Deploy policy changes ............................................................................................... N1-4
Task N1.6: Test configuration ....................................................................................................... N1-5
Lab N2: Rate Limiting ........................................................................................................................ N2-1
Task N2.1: Baseline transfer rate ................................................................................................. N2-1
Task N2.2: Configure rate limiting ................................................................................................ N2-1
Task N2.3: Test rate limiting ......................................................................................................... N2-3
Lab N3: Site-to-site VPN .................................................................................................................... N3-1
Task N3.1: Create objects needed for this lab exercise ............................................................... N3-1
Task N3.2: Configure site-to-site VPN .......................................................................................... N3-1
Task N3.3: Create NAT exemption ............................................................................................... N3-4
Task N3.4: Modify the access control policy and deploy changes ............................................... N3-5
Task N3.5: Test site-to-site VPN .................................................................................................. N3-5
Lab N4: Prefilter Policies ................................................................................................................... N4-1
Task N4.1: Investigate NGFW default behavior for tunneled traffic ............................................. N4-1
Task N4.2: Create a tunnel tag ..................................................................................................... N4-2
Task N4.3: Create a prefilter policy .............................................................................................. N4-3
Task N4.4: Modify the access control policy and deploy changes ............................................... N4-3
Task N4.5: Test the prefilter policy ............................................................................................... N4-4
Security Track
Lab S1: Advanced Policy Configuration ............................................................................................ S1-1
Task S1.1: Configure SSH detection and blocking....................................................................... S1-1
Task S1.2: Configure URL filtering ............................................................................................... S1-2
Task S1.3: Configure the use of XFF type headers ..................................................................... S1-2
Task S1.4: Configure safe search ................................................................................................ S1-3
Task S1.5: Deploy access control policy ...................................................................................... S1-3
Task S1.6: Test configuration ....................................................................................................... S1-4
Lab S2: Basic Authentication ............................................................................................................. S2-1
Task S2.1: Configure a realm ....................................................................................................... S2-1
Task S2.2: Create an identity policy ............................................................................................. S2-2
Task S2.3: Modify the access control policy to use the identity policy and deploy ...................... S2-2
Lab S3: ISE Integration ...................................................................................................................... S3-1
Task S3.1: Configure ISE integration ........................................................................................... S3-1
Task S3.2: Utilize ISE metadata the access control policy .......................................................... S3-3
Task S3.3: Configure the access control policy to use ISE integration ........................................ S3-4
Task S3.4: Test ISE passive authentication ................................................................................. S3-5
Task S3.5: Create a correlation policy using the ISE remediation module .................................. S3-6
Task S3.6: Test the ISE remediation module ............................................................................... S3-9
Lab S4: ClientHello Modification ........................................................................................................ S4-1
Task S4.1: Investigate ClientHello modification feature ............................................................... S4-1
Bonus Labs
Lab B1: OpenAppID ........................................................................................................................... B1-1
Task B1.1: Create a custom application detector ......................................................................... B1-1
Task B1.2: Test the custom application detector.......................................................................... B1-4
Lab B2: Security Intelligence ............................................................................................................. B2-1
Task B2.1: Upload network, URL and DNS lists .......................................................................... B2-2
Task B2.2: Configure a DNS sinkhole .......................................................................................... B2-3
Task B2.3: Configure security intelligence in the access control policy ....................................... B2-4
Task B2.4: Test security intelligence configuration ...................................................................... B2-4
Lab B3: REST API and Policy Hierarchy ........................................................................................... B3-1
Task B3.1: Create access control policies using the REST API .................................................. B3-1
Task B3.2: Create access control policy rules using the API Explorer......................................... B3-2
Task B3.3: Build an access control policy hierarchy .................................................................... B3-4
Lab B4: Advanced Authentication...................................................................................................... B4-1
Task B4.1: Configure the Cisco Firepower User Agent ................................................................ B4-1
Task B4.2: Modify the identity policy ............................................................................................ B4-3
Task B4.3: Modify the access control policy................................................................................. B4-4
Task B4.4: Test authentication ..................................................................................................... B4-6
Task B4.5: Disable active authentication ...................................................................................... B4-7
Appendices
Appendix 1: FMC pre-configuration ................................................................................................... A1-1
Appendix 2: Additional Pod Resources ............................................................................................. A2-1
Task A2.1: AMP Private Cloud ..................................................................................................... A2-1
Task A2.2: Traffic generator ......................................................................................................... A2-2
Task A2.3: DMZ ............................................................................................................................ A2-2
Appendix 3: Scripts Used in this Lab ................................................................................................. A3-1
Exercise Dependencies
After completing M1 and M2, you may skip around, with the following exceptions.
Security track Lab S3 requires security track lab S2.
Bonus Lab B4 requires security track lab S2.
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. There
is a 4th network (192.168.255.0/24) that can be used as a DMZ. See Appendix 2 for details.
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! (GUI)

admin/ISEfp123! (CLI)
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
Mandatory
Labs
Protecting the Network with Firepower NGFW (v1.0) July 2016

Lab M1: Basic Policy Configuration
Exercise Description
This exercise consists of the following tasks.
Task M1.1: Create security zone objects
Task M1.2: Create an access control policy
Task M1.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 M1.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 M1.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
Protecting the Network with Firepower NGFW (v1.0) July 2016 M1-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 1 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 M1.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 M2: NGFW Deployment
Task M2.1: Register the NGFW with the FMC
Task M2.2: Configure interfaces and default route
Task M2.3. Apply NAT policy to device
Task M2.4: Configure platform settings
Task M2.5: Modify the network discovery policy
Task M2.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 M2.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 M2.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 M2.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 M2.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 M2.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 M2.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 1, Section A1.5 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.

Network
Track

Lab N1: NAT and Routing
Task N1.1: Create objects needed for this lab exercise
Task N1.2: Configure static NAT
Task N1.3: Modify access control policy to allow outside access to wwwin
Task N1.4: Configure BGP
Task N1.5: Deploy the policy changes
Task N1.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 3 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.
Protecting the Network with Firepower NGFW (v1.0) July 2016 N1-1
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 N1.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 N1.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 NATed 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 N1.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 N1.5: Deploy policy changes

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 N1.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 N2: Rate Limiting
Task N2.1: Baseline transfer rate
Task N2.2: Configure rate limiting
Task N2.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 N2.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 N2.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 N2.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 N2.1.
Lab N3: Site-to-site VPN
Task N3.2: Configure site-to-site VPN
Task N3.3: Create NAT exemption
Task N3.4: Modify the access control policy and deploy changes
Task N3.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 N3.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-DH2-80 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 N3.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.

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 N3.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 N4: Prefilter Policies
Task N4.1: Investigate NGFW default behavior for tunneled traffic
Task N4.2: Create a tunnel tag
Task N4.2: Create a prefilter policy
Task N4.4: 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 Exercise N1 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 N4.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 N4.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 N4.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.
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.
c. Set the action to Block with reset.
d. In the Available Zones column, select GRE and click Add to Source.
e. In the Applications column, select ICMP and click Add to Rule.
f. Select 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 N4.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.
Security
Track

Lab S1: Advanced Policy Configuration
Task S1.1: Configure SSH detection and blocking
Task S1.2: Configure URL filtering
Task S1.3: Configure the use of XFF type headers
Task S1.4: Configure safe search
Tash S1.5: Deploy access control policy
Task S1.6: Test configuration
Exercise Objective
The objective of this exercise is to create a richer access control policy that will show the layer 7
capabilities of the NGFW.
You will use the FMC UI to perform this configuration. If you want to see how to use the REST API to
construct similar polices, or want to see a policy hierarchy, please look at Appendix A.
Lab Exercise Steps

Task S1.1: Configure SSH detection and blocking
You will now configure the NGFW to detect SSH on any port.
Step 1 In the FMC, navigate to Policies Access Control Access Control. Edit the NGFW Access
Control Policy.
Step 2 Click Add Rule. You will now create a rule to log SSH traffic on any port.
a. Call the rule Log SSH.

b. Select above rule from the Insert drop-down list. Choose the number of the Allow
Outbound Traffic rule, to put this rule right above it. The number will depend on which
exercises you did. In other words, make this the second to last default rule.
Note: Placement of this rule is critical. For example, if this rule was placed betore a rule that blocks at layer 3 or
layer 4, the block could be bypassed by using SSH. Manditory rules will always take precidense over
default rules. The remaining rules configured in this policy will be in the mandatory rules section.
Note: You will not configure inspection for this rule, since the traffic will not be decrypted.
c. Leave the action to Allow.

d. The Zones tab should already be selected. Select InZone and click Add to Source.
f. Select the Applications tab, and type SSH into the Available Applications search field.
Then select SSH and OpenSSH. Click Add to Rule.
g. Select Logging tab. Check the Log at Beginning of Connection and Log at End of
Connection checkbox.
h. Click Add to add the rule to the policy.
Protecting the Network with Firepower NGFW (v1.0) July 2016 S1-1
Step 3 Click Add Rule. You will now create a rule block SSH on port 53.
a. Call the rule Block SSH on Port 53.

c. Leave the action to Block with reset.
d. Select the Applications tab, and type SSH into the Available Applications search field.
e. In the Ports tab, select DNS_over_TCP and click Add to Destination.
f. Select Logging tab. Check the Log at Beginning of Connection checkbox.
Task S1.2: Configure URL filtering

Step 4 Click Add Rule. You will now create a mandatory rule to enforce acceptable use.
a. Call the rule Block Unacceptable Sites.
c. Set the Action to Block with reset.
d. Select URLs tab. Under Categories and URLs, select several categories that you
consider unacceptable. Be sure to include Gambling since this will be used for testing.
Click Add to Rule.
e. Select Logging tab. Check the Log at Beginning of Connection checkbox.
f. Click Add to add the rule to the policy.
Task S1.3: Configure the use of XFF type headers

The NGFW can use of XFF type headers to enforce the policy on the true client, instead of the proxy
server. Note that the rule you configure is artificial, but makes testing easy.
a. Call the rule Test XFF Feature.

b. Set the Action to Block with reset.
c. Select into Mandatory from the Insert drop-down list.
d. Select Networks tab.
i. In the Source Networks area, select the Source subtab. At the bottom of the
page, enter 172.16.1.101 and click Add. This is the IP address of the WSA
proxy server.
ii. In the Source Networks area, select the Original Client subtab. At the bottom of
the page, enter 172.16.1.201 and click Add.
iii. In the Destination Networks area, at the bottom of the page, enter
192.168.1.201 and click Add.
Task S1.4: Configure safe search
You will enforce safe search on supported web sites, and block unsupported search engines.
Step 6 Since many search engines use HTTPS, you need to configure SSL decryption.
a. Click on the link None to the right of the string SSL Policy above the policy rules.
b. From the drop-down list, select the Demo SSL Policy and click OK.
Note: To save you time the Demo SSL policy was pre-configured. See Appendix F for details on how this was
configured..
Step 7 Select the Rules tab. Click Add Rule.

a. Call the rule Safe Search.
b. Leave the action set to Allow.
c. Select above rule from the Insert drop-down list. Choose the number of the Log SSH
rule, to put this rule right above it. The number will depend on which exercises you did.
In other words, make this the third to last default rule.
d. The Zones tab should already be selected. Select InZone and click Add to Source.
f. Select Applications tab.
i. At the top-right of the Selected Applications and Filter section, click the Safe
Search icon
ii. Check the Enable Safe Search checkbox. Select Block with reset from the
Action for non supported engines drop-down list
Click OK.
g. Select Logging tab. Check the Log at Beginning of Connection and Log at End of
Connection checkboxes.
h. Click Add to add the rule to the policy.
Step 8 Click Save to save the access control policy changes.
Task S1.5: Deploy access control policy

You will now deploy the updated access control policy as you did in Lab M2.
Step 10 Check the checkbox for the NGFW device, and click the Deploy Button.
Step 11 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 S1.6: Test configuration

You will now test the changers you made.
Step 12 From the Jump Box desktop, open the PC1 link in the Remote Desktop folder. You will be logged
in as Administrator.
a. Open the Firefox browser using the link on the PC1 desktop.
b. Click the Party Poker link on the bookmarks toolbar. You should see the default
Firepower block page.
Note: In these lab pods, the DNS lookups may time out, and you will get a Server not found message in the
broser. If this happens, click Try Again. If this continues contact the instructor.
c. Launch PuTTY from the PC1 desktop icon. Click on the preconfigured link
outside.com:9922. The connection should be allowed. Close the connection there is no
need to log in.
d. Click on the preconfigured link outside.com:53. The connection should be blocked.
Step 13 In the FMC, navigate to Analysis Connections Events. Observe that SSH was identified on
port 9922 and blocked on port 53.
Step 14 Go back to the Inside UNIX server PuTTY session. Run the following commands to test the
configuration. These Wget commands can be cut and pasted from the file on the Jump Box
desktop called Strings to cut and paste.txt.
a. Run the command:
wget --bind-address=172.16.1.201 192.168.1.201
It should succeed.
b. Run the command:
-e use_proxy=yes -e http_proxy=172.16.1.101
You should get a 403 (forbidden) response code.
c. Run the command:
-e use_proxy=yes -e http_proxy=172.16.1.101
It should succeed.
Step 15 On PC1, test the Safe Search feature using the following sub-steps.
a. In the Firefox browser, click the Google link on the bookmarks toolbar.
b. Click on the lock icon, and confirm that the certificate was issued by Verifraud, so SSL
decryption is taking place.
Note: If you want to see how the URIs are being re-written to support Safe Search, you should run the following
command on the NGFW CLI.
system support firewall-httpmod-debug
When prompted for the client IP, enter 172.16.1.21.
c. Click the Settings button in the lower right of the web page, and select Search settings.
d. Confirm that Safe Search is disabled by looking at the search settings.
e. Click the back button in the browser.
f. Perform a search, for example using the word test.
g. Note that in the upper right of the Google web
page, it says SafeSearch on.
h. Click the AOL link on the bookmarks toolbar.
You should see the default Firepower block
page.
Step 16 In the FMC, navigate to Analysis Connection Events.
a. Drill down to Table View of Connection Events.
b. Click on the X to the right of First Packet, select All Columns and click Apply.
c. Observer that both the WSA (172.16.1.101) and client (172.16.1.201) IP addresses are
reported.
d. Observe that you can get detailed information about the Safe Search events.
Lab S2: Basic Authentication
Task S2.1: Configure a realm
Task S2.2: Create an identity policy
Task S2.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 S3.
Lab Exercise Steps

Task S2.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 Administrator@example.com
AD Join Password FPlab123!
Directory Username Administrator@example.com
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 S2.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 S2.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 S3: ISE Integration
Task S3.1: Configure ISE integration
Task S3.2: Utilize ISE metadata the access control policy
Task S3.3: Configure the access control policy to use ISE integration
Task S3.4: Test ISE passive authentication
Task S3.5: Create a correlation policy using the ISE remediation module
Task S3.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 dont 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 S3.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 S3.2: Utilize ISE metadata in the 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 S3.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.
d. Select the Applications tab, and type SSH into the Available Applications search field.
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.
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.
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 S3.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.
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 S3.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 S3.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 Dilberts 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.
Lab S4: ClientHello Modification
Task S4.1: Investigate ClientHello modification feature
Exercise Objective
The ClientHello feature improves the ability of Firepower to perform SSL inspection. It does this by
modifying the SSL ClientHello packet. It removes cypher suites, compression methods, extensions and
other attributes that may interfere with decryption, or facilitate decryption evasion.
Lab Exercise Steps

Task S4.1: Investigate ClientHello modification feature
The ClientHello feature improves the ability of Firepower to perform SSL inspection. It does this by
modifying the SSL ClientHello packet. It removes cypher suites, compression methods, extensions and
other attributes that may interfere with decryption, or facilitate decryption evasion. This feature is enabled
by default for all traffic matching rules with decryption actions in SSL policies.
Note: To perform this lab, you must have an SSL policy associated with your access control policy. If you skipped
Lab S1, you must go back and do Steps 1, 6, 8, 9, 10 and 11 from Lab S1.
Step 1 Using PuTTY from the Jump Box, access the NGFW CLI.
Step 2 Determine the default behavior.
a. On the Firepower CLI type system support ssl-client-hello-display. This
command prints the contents of the file /etc/sf/ssl_client_hello.conf. By default this file
does not exist, so the command will output Feature Enabled with Default
Settings.
b. On the Inside UNIX server, type the command checkssl. If it produces no output, run it
again.
i. Observe that there are 12 cipher suites in the ClientHello.
ii. Observe that there are no cipher suites that use DSS.
Note: The checkssl script is in /usr/local/bin if you wish to inspect them.
The gettoken script runs the following curl command, and parses the output:
curl -k --tlsv1.2 https://www.howsmyssl.com
This script is available in Appendix 3 of this document.
Step 3 Disable the ClientHello feature.

a. On the Firepower CLI type system support ssl-client-hello-enabled
feature false. This command inserts the string feature=false into
/etc/sf/ssl_client_hello.conf.
b. On the Firepower CLI type system support ssl-client-hello-display.
c. On the Firepower CLI type pmtool restartbytype DetectionEngine.
Wait 8 seconds.
d. On the Inside UNIX server re-enter the command checkssl.
i. Observe that there are now 17 cipher suites in the ClientHello. Be careful
counting the cipher suites that use RC4 appear twice in the output.
ii. Observe that there are now three cipher suites that use DSS:
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
Step 4 Restore the default behavior.
a. On the Firepower CLI type system support ssl-client-hello-reset, and enter
y when prompted to confirm. This command deletes /etc/sf/ssl_client_hello.conf.
b. On the Firepower CLI type system support ssl-client-hello-display, to
confirm the reset.
c. On the Firepower CLI type pmtool restartbytype DetectionEngine. Wait 8
seconds.
d. On the Inside UNIX server, type up-arrow and re-enter the command checkssl.
i. Observe that there are 12 cipher suites in the ClientHello, as before. Be careful
counting the cipher suites that use RC4 appear twice in the output.
ii. Observe that there are no cipher suites that use DSS, as before.
Step 5 Strip the following 2 cipher suites.
TLS_RSA_WITH_AES_256_CBC_SHA (IANA value 47)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (IANA value 156)
These are considered insecure by howsmyssl.com.
See https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 for
the IANA values of cipher suites.
a. On the Firepower CLI type system support ssl-client-hello-tuning
ciphers_remove 47,156
b. On the Firepower CLI type system support ssl-client-hello-display.
c. On the Firepower CLI type pmtool restartbytype DetectionEngine.
Wait 8 seconds.
d. On the Inside UNIX server re-enter the command checkssl.
i. Observe that there are now only 10 cipher suites in the ClientHello.
ii. Observe that cipher suites 47 and 156 have been removed.
Note: Related system support commands include:

ssl-client-hello-force-reset Delete /etc/sf/ssl_cient_hello.conf without user
confirmation.
ssl-client-hello-enabled feature true Enables the ClientHello feature without deleting
/etc/sf/ssl_cient_hello.conf by inserting
the string feature=true or by replacing
the string feature=false
with the string feature=true.
Bonus
Labs

Lab B1: OpenAppID
Task B1.1: Create a custom application detector
Task B1.2: Test the custom application detector
Exercise Objective
OpenAppID is an open source application detection engine, supported by the Snort community. This is
utilized for AVC in the NGFW. The AppID Snort preprocessor has a Lua interface that allows the
preprocessor to utilize Lua scripts. This allows the creation of custom application detectors using the
Lua scripting language.
It this exercise you will create a custom application detector using the FMC UI. You will then test the
application detector.
Lab Exercise Steps

Task B1.1: Create a custom application detector
Step 1 Navigate to Policies Application Detectors.
Step 2 Click on Create Custom Detector.
a. For the Name, enter TestAppDetector.
b. For the Description, enter OpenAppID test. Note that entering a description is
mandatory.
Step 3 Click the Add button to the right of the Application Protocol drop-down menu.
Protecting the Network with Firepower NGFW (v1.0) July 2016 B3-1
a. Fill out the Application Editor page as below.
b. Click OK.
Step 4 Select TestApp from the Application Protocol drop-down menu. Then click OK.
Note: In this lab, we will build a basic detector. This means the Lua script will be created for us. An alternative is
to create and advanced detector. This allows us to upload a custom Lua script.
Step 5 Click the Add button to the right of the Detection Patterns drop-down menu.
a. Fill out the Add Pattern page as below.
b. Click OK.
Step 6 Confirm that the application detector is configured as in the following figure. Then click Save.
Step 7 Enable the custom application detector you just created, as shown in the picture below. Note
that it is helpful to use the search function to find your detector. Click OK when prompted.
Step 8 Click the green down-arrow to the right of the rule.
Open the custom detector in Wordpad, and inspect the Lua script.
Step 9 Navigate to Policies Access Control Access Control, and edit the NGFW Access Control
Policy.
a. For Name, enter Block TestApp
b. Select above rule and 1 from the Insert drop-down list, to make this the first rule.
c. For Action, select Block with reset
d. In the Applications tab, search for TestApp, and add this application to the rule.
e. In the Logging tab, check the Log at Beginning of Connection checkbox.
f. Click Add to save the rule.
Step 11 Click Save to save the changes to the access control policy.
Step 12 Deploy the changes to the access control policy
Step 13 Wait for the deployment to complete.
Task B1.2: Test the custom application detector

Step 14 In the Firefox browser on PC1:
a. Go to Tools Default User Agent Test Application for OpenAppID. This will change
the user agent string to TestApp.
b. Click on the Outside:9980 link on the bookmarks toolbar. Even though this is port 9980,
it will be recognized as HTTP. You should see the default Firepower block page.
c. If you have enabled SSL decryption (as in Lab S1), you should see the same behavior
with HTTPS. Use the HTTPS to Outside link on the bookmarks toolbar to confirm this.
Step 15 In the FMC, navigate to Analysis Connections Events. Drill down to the Table View of
Connection Events and confirm that the TestApp application was detected. It will be in the Client
column of the table.
Step 16 In the Firefox browser on PC1, Go to Tools Test Application for OpenAppID Default User
Agent. This will change the user agent string back to the default. Otherwise subsequent labs
using this browser will break.
Lab B2: Security Intelligence
This exercise consists of 4 tasks.
Task B2.1: Upload network, URL and DNS lists
Task B2.2: Configure a DNS sinkhole
Task B2.3: Configure security intelligence in the access control policy
Task B2.4: Test security intelligence configuration
Exercise Objective
In this exercise, your goal is to perform Security Intelligence configuration. Upon successful completion
of this exercise, the student will be able to:
Deploy an IP based black list
Deploy a URL based black list
Configure and deploy a DNS sinkhole
IP and URL black lists are self-explanatory, but DNS sinkholing deserves some explanation. Typically, if
the edge firewall sees a DNS query to a malicious site, it is coming from an internal DNS server. This
server has probably not been compromised. What the firewall can do is intercept the query, and return
forged A and AAAA records.
These records could point the client at a non-existent destination, or a server controlled by the
administrator. If the attempt to connect to the server is seen by the firewall, the endpoint can be assigned
an indication of compromise (IoC).
Lab Exercise Steps
Task B2.1: Upload network, DNS and URL lists
Note: Each of this Security Intelligence objects can be either lists or feeds. Lists make the lab go faster, but it you
want work with feeds, instructions are included in a box at the end of each step.
Step 1 In the FMC, navigate to Objects Object Management.

Step 2 Select Security Intelligence Network Lists and Feeds. Click Add Network Lists and Feeds.
a. For Name type NetList1. Select List from the Type drop-down menu.
b. Click Browse. Navigate to Desktop Files, and open Network_List.txt.
c. Click Upload. Click Save.
Alternative to Step 2, using a feed instead of a list.

Step 2 Select Security Intelligence Network Lists and Feeds. Click Add Network Lists and
Feeds.
a. For Name type NetList1. Select Feed from the Type drop-down menu.
b. Open the Lab Aux on the Jump Box desktop. Right-click on
Network_List.txt, and select Copy shortcut.
c. For Feed URL, paste the shortcut you copied.
d. Click Save.
Step 3 Select Security Intelligence DNS Lists and Feeds. Click Add DNS Lists and Feeds.
a. For Name type DNSList1. Select List from the Type drop-down menu.
b. Click Browse. Open DNS_List.txt.

Step 3 Select Security Intelligence DNS Lists and Feeds. Click Add DNS Lists and
Feeds.
a. For Name type DNSList1. Select Feed from the Type drop-down menu.
b. In the Lab Aux web page, right-click on DNS_List.txt, and select Copy
shortcut.
d. Click Save.
Step 4 Select Security Intelligence URL Lists and Feeds. Click Add URL Lists and Feeds.
a. For Name type URLList1. Select List from the Type drop-down menu.
b. Click Browse. Open URL_List.txt.

Step 4 Select Security Intelligence URL Lists and Feeds. Click Add URL Lists and
Feeds.
a. For Name type URLList1. Select Feed from the Type drop-down menu.
b. In the Lab Aux web page, right-click on URL_List.txt, and select Copy
shortcut.
d. Click Save.
Task B2.2: Configure a DNS sinkhole

Step 5 Navigate to Objects Object Management Sinkhole. Click Add Sinkhole.
a. Fill out the fields as below. Note that an IPv6 address is mandatory, so we use an
address reserved for documentation only. Note that Type is set to Command and
Control. This will determine the type of IoC generated.
b. Click Save.
Step 6 Navigate to Policies Access Control DNS. Click Add DNS Policy.
a. For the name, enter NGFW DNS Policy. Click Save.
b. Click Add DNS Rule. Configure the rule as shown below.
c. Click Add to add the rule. Then click Save to save the new DNS policy.
Task B2.3: Configure security intelligence in an access policy
Step 8 Select the Security Intelligence Tab.
a. Select NGFW DNS Policy from the DNS Policy drop-down menu.
b. Using the Networks tab under Available Objects, select the network list or feed you
created in Task B2. Click Add to Blacklist.
c. Using the URLs tab under Available Objects, select the URL list or feed you created in
Task B2.1. Click Add to Blacklist.
d. Confirm that your Security Intelligence configuration look what you see below.
e. Click Save to save the changes to the NGFW Access Control Policy.
Step 9 Deploy the changes. Note that the DNS policy and access control policies have been modified.
Step 10 Wait until the deployment is complete.
Task B2.4: Test security intelligence configuration

Step 11 Test the network list or feed. Note that this object contains 2 IP addresses:
198.170.110.164 The hostname developmentserver.com resolves to this.
69.163.152.179
a. From the Jump Box desktop, launch PuTTY and double-click on the pre-definite Inside
UNIX server session. Login as root, password FPlab123!.
b. Enter the commands:
wget -t 1 developmentserver.com
wget -t 1 69.163.152.179
These sites should be blocked because their IP addresses are now blacklisted. Type
Ctrl+C to interrupt each connection attempt.
Step 12 Test the DNS sinkhole. Note that the DNS list or feed contains 2 FQDNs:
bad.com
badguys.com
a. In the Firefox browser in the RDP session to PC1, click the bad.com bookmark on the
bookmarks toolbar. Note that you are redirected to a honeypot.
b. Open the Windows Command Processor on the PC1 desktop. Type:
nslookup bad.com
Confirm that the IPv4 and IPv6 returned by the query are the addresses configured in the
sinkhole object.
Step 13 Test the URL list or feed. This object contains 2 URLs:
fauxnet.com
outside.com/certs
a. In the Firefox browser in the RDP session to PC1, click the FauxNet bookmark on the
bookmarks toolbar. Note that you are blocked.
b. Click the Alt.FauxNet bookmark on the bookmarks toolbar. Note that you are blocked.
c. Click the Outside bookmark on the bookmarks toolbar. Click the Certs link. Note that
you are blocked.
d. Click the Alt.Outside bookmark on the bookmarks toolbar. Click the Certs link. Note that
you can access this folder.
Note: When a FQDN is included in a URL List, it applies to subdomains, so both http://fauxnet.com
and http://alt.fauxnet.com were matched. However, when a URL is include, it hostname must be matched.
Therefore, http://outside.com/certs/ was matched, but http://alt.outside.com/certs/ was not matched.
Step 14 Navigate to Analysis Connections Security Intelligence Events.

a. Confirm that you see the Security Intelligence events generated in this task.
b. Confirm that the computer icons for hosts 172.16.1.21 and 192.168.1.201 are red,
indicating an IoC.
c. Click on one of these red icons to view the host profile, and confirm that this is a
command-and-control connection IoC.
Lab B3: REST API and Policy Hierarchy
Task B3.1: Create access control policies using the REST API
Task B3.2: Create access control policy rules using the API Explorer
Task B3.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 B3.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-b3d1-fef89cea085f
X-auth-refresh-token: c47201ef-76a4-4731-9752-bb1e694d55ed
[root@unix ~]# makepolicy 1ceea138-4b0a-469f-b3d1-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 ~]#
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. These scripts are also available in Appendix 3
of this document.
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 B3.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 B3.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.
Lab Exercise B4: Advanced Authentication
This exercise consists of\ the following tasks.
Task B4.1: Configure the Cisco Firepower User Agent
Task B4.2: Modify the identity policy
Task B4.3: Modify the access control policy
Task B4.4: Test authentication
Task B4.5: Disable active authentication
Note: Security track Lab S2: Basic Authenitication is a necessary prrerequisite to this lab.
Exercise Objective
In this exercise, your goal is to configure identity services available on Firepower. Upon successful
completion of this exercise, the student will be able to:
Configure passive authentication, using the Cisco Firepower User Agent
Configure active authentication
Lab Exercise Steps

Task B4.1: Configure the Cisco Firepower User Agent
Step 1 In the FMC, navigate to System Integration and select the Identity Sources tab.
a. Click the User Agent button.
b. Click the New Agent button.
c. For Host Name/IP Address, enter sfua.example.com.
d. Click Add to add the agent to the list of agents.
e. Click Save to save the identity sources configuration. If you configured ISE integration
(Lab S3), you will get a warning that you cannot use ISE and the User Agent at the same
time. Click Yes to continue.
Step 2 In the Remote Desktop folder on the Jump Box desktop, double-click on the Active Directory
Agent short-cut.
Step 3 Double-click on the Cisco icon labeled Configure Cisco Firepower User Agent for Active Directory
on the Agent desktop.
Note: There is a troubleshooting tool included when you install the Firepower User Agent. In particular, you can
see the IP-to-user mappings the agent has received from the domain not need this in the Lab. To access
thiis tool, right click on the Tools shortcut on the Agent VM desktop.
Step 4 Select the Active Directory Servers tab in the Cisco Firepower User Agent configuration tool.
a. Click Add, and enter the following information.
Attribute Name Attribute Value
Server Name/IP Address dc.example.com
Domain EXAMPLE
Authorized User Administrator
Password FPlab123!
[Local Login IP address] [172.16.1.100]

[Should auto-populate]
Process real-time events Leave checked
b. Click Add.
c. Click Save.
d. Wait a few seconds for the directory server to become available.
Step 5 Select the Firepower Management Centers tab in the Cisco Firepower User Agent configuration
tool.
a. Click Add, and enter the Server Name/IP Address fmc.example.com.
b. Click Add.
c. Click Save.
d. Wait a few seconds for the directory server to become available.
Step 6 Minimize the remote desktop session to the Agent VM.
Task B4.2: Modify the identity policy

Step 8 Click on the pencil icon to edit the NGFW Identity Policy.
Step 9 Select the Active Authentication tab.
a. Click the green circle (with plus sign) to the right of the Server Certificate drop-down
menu.
b. For Name, enter NGFWcert.
c. Click the Browse button to the right of the text Certificate Data or, choose a file, and
browse to Desktop Certificates.
d. Upload NGFW.cer.
e. Click the Browse button to the right of the text Key or, choose a file, and browse to
Desktop Certificates.
f. Upload NGFW.key.
g. Click Save.
Note: This certificate is used when the client is redirected (HTTP 307) to the NGFW inside interface for
authentication over HTTPS. Since the redirect URL contains the interface IP, it is important that this IP be
included as a Subject Alternate Name in this certificate, to avoid browser warnings.
You will see the redirect URL when you test active authentication in Task 6.6:
https://172.16.1.1:885/x.auth?r=2&s=172.16.1.21&a=0&u=http%3A%2F%2Foutside.com%2F
Step 1 Select the Rules tab. Click on the pencil icon to edit the Default Authentication Rule.
a. Keep Action set to Passive Authentication.
b. Click the Realm & Settings tab on the right side of the dialog.
c. Select EXAMPLE (AD) from the Realm drop-down list.
d. Check the Use active authentication if passive authentication cannot identify user
checkbox.
e. Select HTTP Response Page from the Authentication Type drop-down list..
f. Click Save to save the rule.

Task B4.3: Modify the access control policy

Step 3 Navigate to Policies Access Control Access Control. Edit the NGFW Access Policy.
Step 4 Select the Rules tab.
Step 5 Click Add Rule. You will now create a rule allow traffic to be redirected to port 885 on 172.16.1.1.
a. Call the rule Block SSH for HR.

b. In the Insert drop-down list, change below rule, to into Mandatory. The rule must not be
preceded by the Catch All rule from Lab Exercise 4.
d. Select Users tab. Under Available Realms, click on EXAMPLE. The list of users and
groups should auto-populate.
e. In the search box under Available Users, type H. Select HR and click Add to Rule.
f. Select the Applications tab, and select SSH and OpenSSH. Click Add to Rule.
Step 6 Delete any rules that use ISE metadata. You will have such rules if you did Lab S3.
Step 7 If you did Lab S3, this rule will already exist, so you can skip this step. Click Add Rule. You will
now create a rule to block members of the HR and Investment groups from using SSH.
g. Call the rule Block SSH for HR.
h. In the Insert drop-down list, change below rule, to into Mandatory. The rule must not be
preceded by the Catch All rule from Lab Exercise 4.
i. Set the action to Block with reset.
j. Select Users tab. Under Available Realms, click on EXAMPLE. The list of users and
groups should auto-populate.
k. In the search box under Available Users, type H. Select HR and click Add to Rule.
l. Select the Applications tab, and select SSH and OpenSSH. Click Add to Rule.
m. Select the Logging tab. Check the Log at Beginning of Connection checkbox.
n. Click OK to add the rule to the policy.
Step 8 Click Add Rule. You will now create a rule to block guests from using HTTPS.
a. Call the rule Block guests from using HTTPS.

b. In the Insert drop-down list, change below rule, to into Mandatory. The rule must not be
preceded by the YouTube EDU rule from Lab Exercise 4.
d. Select the Users tab. Under Available Realms, click on Special Identities.
e. Select Guest and click Add to Rule.
f. Select the Applications tab, and select HTTPS. Click Add to Rule.
g. Select the Logging tab. Check the Log at Beginning of Connection checkbox.
h. Click OK to add the rule to the policy.
Note: For active authentication to work, you need a rule to allow traffic between the endpoints and port 885 on the
NGFW interfaces. This should be the first rule. You will add it in the next step.
a. Call the rule Allow Proxy Redirect.

b. Leave the Action set to Allow.
c. The Zones tab should already be selected. Select InZone and click Add to Source.
d. Select above rule and 1 from the Insert drop-down list.
e. Select Networks tab. In the Destination Networks area, at the bottom of the page, enter
172.16.1.1 and click Add.
f. In the Ports tab, go to the bottom of the Selected Destination Ports column
i. Select TCP (6) from the Protocol drop-down list.
ii. For Port, enter 885.
iii. Click Add to the right of the port entry text field to add 885 to the list of
destination ports.
Step 10 Click Save to save the updates to the access control policy.
Step 11 Deploy the policy and wait for the deployment to complete. You can ignore the warning.
Task B4.4: Test authentication
Note: If you run into an issue in this task, you may want to restart the Authentication Directory Interface (ADI) on
the FMC. To do this:
1. Login to the FMC using PuTTY. Login as admin, password FPlab123!.
2. Become root by typing sudo i and entering the password FPlab123!.
3. Run the commands:
pmtool disablebyid adi
pmtool enablebyid adi
If you want to do more extensive debugging of ADI, run the ADI in forground with debugging enabled:
pmtool disablebyid adi
adi --debug
Step 12 From the Jump Box desktop, open the PC2 link in the Remote Desktop folder. PC2 is a member
of the EXAMPLE domain, so passive authentication should be used. Login as ira, password
FPlab123!.
a. Open Firefox, and browse on the home page to Files py.html. Confirm that you are
not asked to authenticate.
b. Launch PuTTY from the desktop icon. Click on the preconfigured link outside.com. The
connection should be allowed. Close the connection there is no need to log in.
c. Launch PuTTY from the desktop icon. Click on the preconfigured link outside.com:53.
The connection should be reset.
Step 13 Logout of PC2 and log back in as harry, password FPlab123!. Harry is a member of the HR
group.
a. Launch PuTTY from the desktop icon. Click on the preconfigured link outside.com. The
connection should not be allowed, because Harry is in the HR group.
b. Launch PuTTY from the desktop icon. Click on the preconfigured link outside.com:9922.
The connection should not be allowed, because Harry is in the HR group.
Step 14 From the Jump Box desktop, open the PC1 link in the Remote Desktop folder. PC1 is not a
member of the EXAMPLE domain, so active authentication should be used.
a. Click on the Dilbert (Engineering) link in the Users folder on the PC1 desktop. This will
change the IP address PC1 will use.
b. Open the Firefox browser (if not already open) using the link on the PC1 desktop. Select
View Sidebar LiveHTTPHeaders (if not already open).This will give insight into the
HTTP traffic.
c. Refresh the home page. You should see a login pop-up in the browser.
d. In the LiveHTTPHeaders sidebar, you should see the redirect:
HTTP/1.1 307 Proxy Redirect
Location: https://172.16.1.1:885/x.auth?r=2&s=172.16.1.21&a=0&u=http%3A%2F%2Foutside.com%2F
Connection: close
e. Login as EXAMPLE\dilbert, password FPlab123!.

f. In the LiveHTTPHeaders, you should see the authentication communication.
g. In the browser bookmarks toolbar, click on HTTPS to Outside. This should be allowed.
Step 15 Click on the Default like in the Users folder on the PC1 desktop. This changes the IP address of
PC1 back to 172.16.1.21.
a. Refresh the home page again. You should see the HTTP response page.
b. Click the Login as guest button.
c. In the browser bookmarks toolbar, click on HTTPS to Outside. The connection should be
reset.
Step 16 In the FCM, navigate to Analysis Users User Activity. Confirm that Ira and Harry used
passive authentication, and Dilbert used active authentication.
Task B4.5: Disable active authentication

Several of the other lab exercises assume that there is not active authentication enabled. For example,
the Wget commands will result in proxy redirects. Therefore, if you plan on doing any more labs, it is
recommended that you disable active authentication.
Step 18 Click on the pencil icon to edit the NGFW Identity Policy.
Step 19 Select the Rules tab. Click on the pencil icon to edit the Default Authentication Rule.
a. Keep Action set to Passive Authentication.
b. Click the Realm & Settings tab on the right side of the dialog.
c. Select EXAMPLE (AD) from the Realm drop-down list.
d. Uncheck the Use active authentication if passive authentication cannot identify user
checkbox.
g. Click Save to save the rule.
Step 21 Deploy the policy configuration and wait for the deployment to complete.
Appendices

Appendix 1: 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.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 A1.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.
Protecting the Network with Firepower NGFW (v1.0) July 2016 A1-1
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 A1.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 A1.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 search. You will see
safesearch supported and safesearch unsupported under Tags. Select these two tags,
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 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...
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 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.
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 2: 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 Administrator@example.com, 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.
Appendix 3: Scripts Used in this Lab
The checkSSL script

#!/bin/bash
#
# Check SSL security
#
# Usage:
# checkssl [-v]
# Use -v for verbose mode
#
if [ $2 ]; then
echo Usage:
echo checkssl [-v]
echo Use -v for verbose mode
exit
fi
if [ $1 ]; then
if [ $1 = "-v" ]; then
curl -k -v --tlsv1.2 https://www.howsmyssl.com
else
echo Usage:
echo checkssl [-v]
fi
else
curl -k --tlsv1.2 https://www.howsmyssl.com 2> /dev/null | grep TLS_ | sed 's/.*<li>//' | sed
's/<.*$//' | sed 's/has.*$/is insecure/'
fi
The gettoken script

#!/bin/bash
#
# Generate and retrive API token from the FMC
#
# Usage:
# gettoken [-v]
# Use -v for verbose mode
#
if [ $2 ]; then
echo Usage:
echo gettoken [-v]
exit
fi
if [ $1 ]; then
if [ $1 = "-v" ]; then
https://fmc.example.com/api/fmc_platform/v1/auth/generatetoken
else
echo Usage:
echo gettoken [-v]
fi
else
https://fmc.example.com/api/fmc_platform/v1/auth/generatetoken |& egrep -i '(X-auth|error)' | sed
's/.*X/X/'
fi
The makepolicy script
#!/usr/bin/python
#
# Use REST API to createpolicies
#
# Usage:
# makepolicy <token> <policy1> [<policy2> ...]
#
import base64
import json
import sys
import urllib2
server = "https://fmc.example.com"
username = "restapiuser"
password = "FPlab123!"
headers = {'Content-Type': 'application/json',

'X-auth-access-token': sys.argv[1]}
api_path = "/api/fmc_config/v1/domain/default/policy/accesspolicies"
url = server + api_path
f = None
for x in range(2, len(sys.argv)):

print "Sending request to create policy %s" % sys.argv[x]
post_data = {
"type": "AccessPolicy",
"name": sys.argv[x],
}
req = urllib2.Request(url, json.dumps(post_data), headers)
base64string = base64.encodestring('%s:%s' % (username, password)).replace('\n', '')
req.add_header("Authorization", "Basic %s" % base64string)
try:
f = urllib2.urlopen(req)
status_code = f.getcode()
print "Status code is "+str(status_code)
if status_code == 201:
print "Create was successful"
except urllib2.HTTPError, err:
print "Error received from server. HTTP Status code :"+str(err.code)
try:
json_error = json.loads(err.read())
if json_error:
print json.dumps(json_error,sort_keys=True,indent=4, separators=(',', ': '))
except ValueError:
pass
finally:
if f: f.close()
JavaScript for access control policy rules

URL Filtering
{
"action": "BLOCK_RESET",
"enabled": true,
"type": "AccessRule",
"name": "Block Unacceptable Sites",
"logBegin": true,
"logEnd": false,
"sendEventsToFMC": true,
"variableSet": {
"name": "Default Set",
"id": "76fa83ea-c972-11e2-8be8-8e45bb1343c0",
"type": "VariableSet"
},
"logFiles": false,
"urls": {
"urlCategoriesWithReputation": [
{
"type": "UrlCategoryAndReputation",
"category": {
"name": "Phishing and Other Frauds",
"id": "a774acd8-8240-11e0-9682-6814b504fd57",
"type": "URLCategory"
}
},
{
"category": {
"name": "Adult and Pornography",
"id": "a774acd8-8240-11e0-9682-6814b504fd11",
}
},
{
"category": {
"name": "Gambling",
"id": "a774acd8-8240-11e0-9682-6814b504fd27",
}
}
]
}
}
Log SSH traffic
{
"action": "ALLOW",
"enabled": true,
"name": "Log SSH Traffic",
"logBegin": true,
"logEnd": true,
"variableSet": {
"id": "76fa83ea-c972-11e2-8be8-8e45bb1343c0",
},
"logFiles": false,
"applications": {
"applications": [
{
"id": "771",
"type": "Application",
"name": "OpenSSH"
},
{
"id": "846",
"name": "SSH"
}
]
}
}
Block SSH on port 53
{
"action": "BLOCK_RESET",
"enabled": true,
"name": "Block SSH on Port 53",
"logBegin": true,
"logEnd": false,
"variableSet": {
"id": "76fa83ea-c972-11e2-8be8-8e45bb1343c0",
},
"logFiles": false,
"destinationPorts": {
"objects": [
{
"type": "ProtocolPortObject",
"name": "DNS_over_TCP",
"id": "1834e712-38bb-11e2-86aa-62f0c593a59a"
}
]
},
"applications": {
"applications": [
{
"id": "771",
"name": "OpenSSH"
},
{
"id": "846",
"name": "SSH"
}
]
}
}

FJBT Network Security FTD Lab Guide v1 0d

Uploaded by

Document Information

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

FJBT Network Security FTD Lab Guide v1 0d

Uploaded by

Copyright:

Available Formats

Protecting the Network with

Firepower NGFW Lab Guide

Arial Bold Used to indicate emphasis

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

This is the topology used for this lab.

[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

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! (GUI)

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

Protecting the Network with Firepower NGFW (v1.0) July 2016

Lab Exercise Steps

Task M1.2: Create an access control policy

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.

e. Select the Translation tab.

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 Exercise Steps

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

Task M2.2: Configure interfaces and default route

Step 6 The Interfaces tab should be selected.

Task M2.3: Apply NAT policy to device

c. Add NGFW to Selected Devices.

Task M2.5: Modify the network discovery policy

Task M2.6: Test the NGFW deployment

If you wish, you can try the following.

h. You can drill down for more details if you wish.

Protecting the Network with Firepower NGFW (v1.0) July 2016

Lab Exercise Steps

Task N1.2: Configure static NAT

d. Select the Translation tab.

g. Click OK to save the NAT rule.

g. Select the Ports tab.

Task N1.4: Configure BGP

Step 12 Select the Routing tab.

v. Click OK to add the neighbor.

Task N1.5: Deploy policy changes

Task N1.6: Test configuration

Step 19 From the NGFW CLI:

End of Exercise: You have successfully completed this exercise.

Lab Exercise Steps

Task N2.2: Configure rate limiting

f. Select the Applications tab.