Labsec 2339 LG

Cisco ASA with Firepower Services
6.0 (v1.3) Lab Guide
Developers
The labs and lab materials were created by the TME team for the Security Technology Group at
Cisco Systems. For feedback or questions about this lab, please contact Eric
Kostlan erkostla@cisco.com.
Lab Overview
This lab is designed to help attendees understand the new features available with the 6.0 release
of the Cisco ASA with Firepower services.
Note: The lab is not a substitute for Firepower or ASA training. Basic familiarity with these products is assumed.
Lab participants should be able to complete these at least 5 lab exercises within the allotted lab
time of 4 hours.
If you complete these exercises, you will see most of the new 6.0 Firepower features. Also you
will configure and test the SSL decryption feature, which is now available on the ASA.
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.
Cisco ASA with Firepower Services 6.0 (v1.3) February 2016 1

Lab Exercises
This lab guide includes the following exercises:
Lab Exercise 1: Initial SFR Configuration ............................................................................ 7

Task 1.1: Perform initial SFR configuration .................................................................... 7
Task 1.2: Explore on-box management capabilities ....................................................... 8
Lab Exercise 2: Basic Policy Configuration ........................................................................ 11
Task 2.1: Create an access policy hierarchy ................................................................ 11
Task 2.2: Register devices............................................................................................ 14
Task 2.3: Configure Firepower settings ........................................................................ 16
Task 2.4: Configure network discovery......................................................................... 17
Task 2.5: Redirect traffic to the SFR ............................................................................. 18
Task 2.6: Test the policy configuration ......................................................................... 20
Lab Exercise 3: Security Intelligence .................................................................................. 22
Task 3.1: Upload network, URL and DNS lists ............................................................. 22
Task 3.2: Configure a DNS sinkhole ............................................................................. 23
Task 3.3: Configure Security Intelligence in an access policy ...................................... 24
Task 3.4: Test the Security Intelligence configuration .................................................. 25
Lab Exercise 4: Snort and OpenAppID ................................................................................ 27
Task 4.1: Configure a network analysis policy.............................................................. 27
Task 4.2: Configure an intrusion policy......................................................................... 28
Task 4.3: Create a custom application detector ........................................................... 29
Task 4.4: Modify the ASASFR Access Policy ............................................................... 32
Task 4.5: Test Snort and OpenAppID ........................................................................... 33
Lab Exercise 5: SSL Decryption ......................................................................................... 34
Task 5.1: Upload certificates and keys ......................................................................... 34
Task 5.2: Configure an SSL policy ............................................................................... 35
Task 5.3: Test SSL decryption ...................................................................................... 38
Lab Exercise 6: File Policy Configuration .......................................................................... 41
Task 6.1: Create a file policy......................................................................................... 41
Task 6.2: Deploy the file policy ..................................................................................... 44
Task 6.3: Test the file policy ......................................................................................... 44
Lab Exercise 7: Identity ....................................................................................................... 47
Task 7.1: Configure a realm.......................................................................................... 47
Task 7.2: Configure Cisco Firepower User Agent integration ...................................... 48

Task 7.3: Configure the ASA for captive portal............................................................. 50
Task 7.4: Create an identity policy ................................................................................ 50
Task 7.5: Modify an access control policy to utilize authentication .............................. 51
Task 7.6: Test authentication ........................................................................................ 52
Task 7.7: Configure ISE integration .............................................................................. 53
Lab Exercise 8: Domains ................................................................................................... 56
Task 8.1: Create and configure domains ...................................................................... 56
Task 8.2: Enforce policy inheritance ............................................................................. 58
Task 8.3: Configure leaf domains ................................................................................. 59
Task 8.4: Configure domain specific role based access control................................... 60
Appendix ............................................................................................................................ 62
Port Override for Service Metadata .............................................................................. 62
Generating troubleshooting files ................................................................................... 63
Exercise dependencies
Exercises 1 through 4 must be done in order. After completing the first 4 exercises, you may skip
exercises.
However, if you skip Lab Exercise 5, you must also skip the following steps:
Lab 6, Step 16
Lab 6, Step 19
Also, if you want to do ISE integration (Lab 7.7), you have to do Step 1 of Lab 5.
Product Overview: Cisco ASA with Firepower

Services 6.0
The 6.0 release of Firepower has introduced many new features. Also, SSL decryption,
introduced in the 5.4 release was not available on the ASA with Firepower Services until 6.0.
Furthermore, Snort was updated to 2.9.8, which introduced some differences in behavior. In
these lab exercises, most of the changes to ASA with Firepower Services introduces in 6.0 are
explored.

Lab Topology and Access
Each pod has one ASA 5525-X. Other devices are virtual devices.
o Each pod will have an ASA 5525-X with the SFR module pre-installed.
o The SFR module is pre-installed, but not configured.
There are two VLANs.
o One inside the firewall (172.16.1.0/24)
o One outside the firewall (192.168.1.0/24)
All management is in-band on the inside VLAN. Limited access to the internet is available from
the outside VLAN.
Firepower will be installed and have a basic configuration.
The Sourcefire User Agent (SFUA) is installed and configured, but not added to the Firepower
Management Center.
Note: The ASA 5525-X is running ASA 9.5(2). The SFR is running 6.0.0-1005.
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
ASA 5525-X 172.16.1.1, 192.168.1.2
ASASFR 172.16.1.80
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
vNGIPS (Virtual Sensor) 172.16.1.81
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
Note: To reset the password do session sfr do password-reset from the ASA CLI in privileged mode. In
the release used in the course, this will set the admin password on the SFR to Sourcefire.

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!
ASA 5525-X SSH access: admin/FPlab123!

TELNET password: FPlab123!
Enable password: FPlab123!
ASA SFR admin

On install the password will be Admin123
You will change the password to
FPlab132!
Windows (except Jump Box) Administrator/ FPlab123!

(PC1, PC2., PC3, SFUA, 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!
SF (Stand-alone Sourcefire 3D sensor) admin/Sourcefire
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 have carefully configured accounts on PC2.
Account (username/password) Group
dilbert/FPlab123! Engineering
harry/FPlab123! HR
ira/FPlab123! Investment
rita/FPlab123! IT

Lab Exercise 1: Initial SFR Configuration
Exercise Description
This exercise consists of 2 tasks.
Task 1.1: Perform initial SFR configuration
Task 1.2: Explore on-box management capabilities
Exercise Objective
The objective of this exercise is to perform initial deployment of the SFR. Upon successful
completion of this exercise, the student will be able to:
Connect to the SFR from the ASA and set the basic network parameters
Have a high-level understanding of on-box management capabilities.
Lab Exercise Steps
Task 1.1: Perform initial configuration on the SFR

Step 1 On the Jump Box desktop, open the PuTTY link. Double click on the preconfigured session
called ASA. When you see the User Access Verification Password prompt, login using the
TELNET password FPlab123! Then type enable and enter the enable password FPlab123!.
Note: Note that if you have issued typing special characters (such as !) with your keyboard, you can open the
text file Strings to cut and paste on the Jump Box desktop, and cut text from there.
Step 2 Type show module sfr details to confirm that the SFR module does not have an off-box
manager configured:
DC addr: No DC Configured
Step 3 Connect to the SFR module from the ASA using the command session sfr console. Hit
<ENTER>. When prompted, login as admin, password Admin123.
Step 4 Read and accept the EULA. The setup wizard will automatically get launched.
Step 5 Enter the information in the following table into the setup wizard.
Note: The backspace key may not work properly when you enter data. Do not hit Ctrl-C. Just type some non-
sense, and the setup wizard will ask you to re-enter that element.
If you want to correct mistakes made when you ran the setup wizard, use the following commands:
configure password
configure network hostname asasfr.example.com
configure network ipv4 manual 172.16.1.80 255.255.255.0 172.16.1.1
configure network dns servers 172.16.1.100
configure network dns searchdomains example.com
To reset the password, run
session sfr do password-reset
from the ASA CLI in privileged mode. In the release used in the course, this will set the admin password on
the SFR to Sourcefire. This will be changed to Admin123 in a subsequent release this is issue
CSCuw39605.

Attribute Name Attribute Value
New password FPlab123!
IPv4 address for Management 172.16.1.80
IPv4 mask 255.255.255.0
IPv4 gateway 172.16.1.1

This is the inside interface of the ASA.
[IPv6 configuration attributes] [IPv6 will not be configured.]
FQDN asasfr.example.com
DNS servers 172.16.1.100
Search domains example.com
Step 6 Wait about a minute until you see the > prompt.
Step 7 At the > prompt, do the following.
a. Type system support ping outside.com. This will test name resolution and
connectivity. Press Ctrl+C to exit ping.
b. Type show time to confirm that the date it roughly correct. NTP will be configured in
Lab Exercise 2.
Note: The system support submenu has many useful troubleshooting tools. Type system support ? to see
these commands.
You can fork a Bash shell by typing the command expert at the > prompt. Expert mode can be used for
troubleshooting many issues. For example, you can look at the messages log in real time by running the
command tail -f /var/log/messages.
You can become root by typing
sudo su -
at the admin shell prompt and enter the password FPlab123! when prompted.
Step 8 Keep the PuTTY session to the ASA open. You will use this again in Lab Exercise 2.
Task 1.2: Explore on-box management capabilities

We could do most of these lab exercises using either on-box or off-box management. However,
we will focus on off-box management. This short task is to give you a high-level understanding of
the on-box management using the ASDM.
Note: If you convert between on-box and off-box management,

you lose the policy configuration.
See the appendix for instructions on how to use policy

import and export to avoid losing policy configuration when
you convert between on-box and off-box management.
Step 9 In the Tools folder on the Jump Box desktop, double

click on the Cisco ASDM IDM launcher. Enter the
password FPlab123!, and click OK. Accept the
security warning twice.

Step 10 Observe the 3 tabs related to the SFR: ASA FirePOWER Dashboard, ASA FirePOWER
Reporting, and ASA FirePOWER Status.
Step 11 Navigate to Monitoring ASA FirePOWER Monitoring. Confirm that the monitoring capabilities
are minimal. They are considerably less than what you will see with the off-box manager.

Step 12 Navigate to Configuration ASA FirePOWER Configuration. Confirm that you have extensive
configure capabilities.
a. Expand Policies and select Access Control Policy. Notice that the default access control
policy is to allow all traffic. This page may take several seconds to load.
b. Notice that there is no network discovery policy.
Step 13 Navigate to File Exit. Then click Yes to exit the ASDM.
End of Exercise: You have successfully completed this exercise.

Proceed to next section.

Lab Exercise 2: Basic Policy Configuration
Task 2.1: Create an access policy hierarchy
Task 2.2: Register devices
Task 2.3: Configure Firepower settings
Task 2.4: Configure network discovery
Task 2.5: Redirect traffic to the SFR
Task 2.6: Test the policy configuration
Exercise Objective
In this exercise, your goal is to perform and test basic policy configuration for the SFR. Upon
successful completion of this exercise, the student will be able to:
Deploy an Access Policy hierarchy to a set configure an access policy hierarchy
Configure platform settings and network analysis for sensors
Redirect traffic the SFR sensor on the ASA
View and filter connection events
Lab Exercise Steps

Task 2.1: Create an access policy hierarchy
The policy hierarchy will consist of three policies.
A global policy that will apply to all devices
A policy for the SFR, focused on control
A policy for the vNGIPS, focused on visibility
Step 14 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 15 Navigate to Policies Access Control Access Control. Click New Policy.
a. Enter the following information:
Name: Global Access Policy
Select Base Policy: None
Default Action: Intrusion Prevention
b. Click Save. Wait a few seconds for the policy to open for editing.
c. Click Add Rule. You will now create a mandatory rule to enforce acceptable use.
i. Call the rule Block Unacceptable Sites.
ii. Set the Action to Block with reset.
iii. Leave the Insert drop-down menu set to into Mandatory.
iv. 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.
v. Select Logging tab. Check the Log at Beginning of Connection checkbox.
vi. Click OK to add the rule to the policy.

d. Click Add Rule again. You will now create a default rule to log all SSH traffic that does
not match rules in child access control policies.
i. Call the rule Log SSH Traffic.
ii. Leave the action set to Allow.
iii. Select into Default from the Insert drop-down menu.
iv. Select the Applications tab, and type SSH into the Available Applications search
field. Then select SSH and OpenSSH. Click Add to Rule.
v. Select the Logging tab. Check the Log at Beginning of Connection checkbox.
vi. In the Logging tab, check the Log at End of Connection checkbox.
vii. Click OK to add the rule to the policy.
e. Select the HTTP Responses tab. Select System-Provided from the Block Response
Page drop-down menu.
f. Confirm that your policy configuration matches the following figure.
g. Click Save to save the Global Access Policy settings.

Name: ASASFR Access Policy
Select Base Policy: Global Access Policy
c. Note that 2 rules were inherited from the Global Access Policy. Confirm that you cannot
modify or delete these rules.
d. Click Add Rule. You will now create a rule to block SSH traffic on port 53.
i. Call the rule Block SSH on Port 53.
ii. Set the action to Block with reset.
iii. Select the Applications tab, and type SSH into the Available Applications search
field. Then select SSH and OpenSSH. Click Add to Rule.
iv. Select the Ports tab. Under Available Ports, select DNS_over_TCP and click
Add to Destination.
v. Select Logging tab. Check the Log at Beginning of Connection checkbox.
vi. Click OK to add the rule to the policy.
e. Click the Rules tab, and scroll down to the bottom of the rules table. In the Default Action
drop-down menu, select Intrusion Prevention: Balanced Security and Connectivity. Be
sure not to select Inherit from base policy, because we want the logging settings to be
specific to this policy.

f. Confirm that your policy configuration matches the following figure.
g. Click the Save button in the upper right-hand corner.
Name: vNGIPS Access Policy
Select Base Policy: Global Access Policy
c. Note that 2 rules were inherited from the Global Access Policy. Confirm that you cannot
modify or delete these rules.
d. At the bottom of the rules table, in the Default Action drop-down menu, select Intrusion
Prevention: Balanced Security and Connectivity. Be sure not to select Inherit from
base policy, because we want the logging settings to be specific to this policy.
i. Click on the scroll icon to the right of the drop-down menu you just used.
ii. Check the Log at Beginning of Connection checkbox.
iii. Check the Log at End of Connection checkbox.
iv. Click OK.

e. Confirm that your policy configuration matches the following figure.
f. Click the Save button in the upper right-hand corner.

Task 2.2: Register devices
Step 18 You should still be logged into the SFR in the PuTTY session connected to the ASA. If not, start
a new PuTTY session and login into the SFR from the ASA as you did in Lab Exercise 1:
Type session sfr console. Login as admin, but the password is now FPlab123!.
a. Type the command configure manager add fmc.example.com cisco123.
b. Wait for the command to return. They type show managers to confirm that the
registration is pending.
Step 19 In the Firepower Management Center, navigate to Devices Device Management.
a. Select Add Device from the Add drop-down menu in the upper right corner.
b. Fill out the information as in the figure below.
c. Click Register.
Note: Note that the registration process, and the policy deployment, can take a couple of minutes. Please
proceed to the next step to save some time.
Step 20 On the Jump Box desktop, open the PuTTY link. Double click on the preconfigured session
called VNGIPS. Login as admin, password FPlab123!.
a. Type the command configure manager add fmc.example.com cisco123.
b. Wait for the command to return. They type show managers to confirm that the
registration is pending.
Step 21 In the Firepower Management Center, navigate to Devices Device Management.
a. Select Add Device from the Add drop-down menu in the upper right corner.

b. Fill out the information as in the figure below.
c. Click Register.
Note: Note that the registration process, combined with the policy deployment, can take a couple of minutes.
Please proceed to the next step to save some time.
Step 22 Back on the ASA PuTTY session:
a. Run the command show managers to confirm that the registration is completed.
b. Exit from the SFR by typing Ctrl+^ (or Ctrl+Shift+6) followed by x.
Note: If you have trouble getting Ctrl+^ to work on your keyboard, just close this PuTTY session, and start a
fresh PuTTY session to the ASA.
c. Back on the ASA CLI, type show module sfr detail and confirm that this
information has been updated.
d. Keep this PuTTY session open.
Step 23 Back on the VNGIPS PuTTY session:
a. Run the command show managers to confirm that the registration is completed.
b. You may close this PuTTY session, if you wish, by typing exit.
Step 24 Click on the icon to the right of the Deploy link in the upper right-hand corner of the FMC UI. This
icon may be a green check, yellow warning, or a red exclamation mark, depending on health-
checks.

Step 25 Wait until the deployment is complete.
Note: Note that there are 3 tabs in this drop-down page. The Tasks tab is particularly useful to keep track of
complete and failed tasks, and tasks that are in progress.
Task 2.3: Configure Firepower settings

Step 26 In the Firepower Management Center, navigate to System Configuration.
a. Select Time Synchronization from the navigation panel on the left. Change that the NTP
server to 172.16.1.100. This is the pod NTP server.
b. Click Save.
Step 27 In the Firepower Management Center, navigate to Devices Platform Settings.
a. Click on the blue text Firepower Settings Policy.

b. Name the policy Default Settings Policy. Add both devices. 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.
e. Click Save.
You will deploy this policy along with the network discovery policy in the following task.
Task 2.4: Configure network discovery

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 28 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 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 29 Click Deploy in the upper right hand corner of the FMC UI.
a. Check the checkboxes for both devices, and expand the list to see the details. Confirm
that network discovery and platform setting are out of date on both devices.
b. Click the Deploy Button. Do not wait for deployment to complete to move on to the next
task.
Task 2.5: Redirect traffic to the SFR

At this point traffic is being processed by the vNGIPS but not by the SFR.
Step 30 In the Tools folder on the Jump Box desktop, double click on the Cisco ASDM IDM launcher.
Enter the password FPlab123!, and click OK. Accept the security warning but this time it will
only appear once.

Step 31 Observe the now there are only 1 tab related to the SFR instead of 3: ASA FirePOWER Status.
Step 32 Navigate to Monitoring, and confirm that you no longer have a tab for ASA Firepower Monitoring.
Step 33 Navigate to Configuration, and confirm that you no longer have a tab for ASA Firepower
Configuration.
Step 34 Navigate to Configuration Firewall Service Policy Rules.
a. Click Add.
b. (Step 1 of 3 in wizard) Leave this page alone. Click Next.
c. (Step 2 of 3 in wizard) Select Use class-default as the traffic class. Click Next.
d. (Step 3 or 3 in wizard) Select the ASA FirePOWER Inspection tab. Check the Enable
ASA FirePOWER for this traffic flow checkbox. Leave other settings alone. Click Finish.
Note: If you checked the Enable Monitory Only checkbox, you would put the SFR into IDS mode. Traffic would be
copied from the ASA to the SFR module, but the SFR module will not be in the data path. This can allow
you to confirm that the policies on the SFR are working properly before you switch to IPS mode. However,
to save time in this lab, we will not work with IDS mode.

Step 35 In the ASDM, click Apply. Observe the modification to the ASA policy-map:
policy-map global_policy
class class-default
sfr fail-open
Click Send.
Note: If the SFR was in monitor-only (IDS) mode, the last line would read: sfr fail-open monitor-only.
Step 36 Navigate to File Exit. When the Configuration Modified dialog box appears, click Save and
Send. Then click Yes to exit the ASDM.
Task 2.6: Test the policy configuration

Step 37 In the ASA PuTTY session (which should still be open), type the commands:
clear service-policy
clear asp drop
Step 38 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. Select View Sidebar
LiveHTTPHeaders. This will give insight into the HTTP traffic.
b. Click the Party Poker link on the bookmarks toolbar. You should see the default
Firepower block page.
c. Launch PuTTY from the PC1 desktop icon. Click on the preconfigured link
outside.com:9922. We are running sshd on port 9922 to demonstrate the SSH can be
detected on any port. The connection should be allowed. Close the connection there
is no need to log in.
d. Launch PuTTY from the PC1 desktop icon. Click on the preconfigured link
outside.com:53. The connection should be reset.
Step 39 In the ASA PuTTY session, perform the following.
a. Type show service-policy sfr. Note how the counters have incremented. Note
that there is 1 reset-drop, because of the attempt to run SSH on port 53. There will also
be a several drops, because of the attempt to go to http://partypoker.com.
Note: Since you set the action of the rule to block gambling sites to drop with reset, you might expect to see reset-
drops for http://partypoker.com. However, since you configured the SFR to send an end-user notification,
the reset is not sent.
b. Type show asp drop | inc SFR. Note that the number of ASP drops equals the
sum of the reset-drops and drops seen in the previous sub-step.
Step 40 (Optional) Connect to the SFR CLI, by typing session sfr console. Hit <ENTER>. You
should already be logged in to the SFR. But, if needed, login as admin, password FPlab123!.
Run the following command.
system support firewall-engine-debug
This tool is very useful for debugging policy rule matching.
a. Select the following criteria.
Please specify an IP protocol:
Please specify a client IP address: 172.16.1.21
Please specify a client port:
Please specify a server IP address:
Please specify a server port:
You must select at least one criterion when you use this rule.
b. Repeat Step 38 (b, c and d), and pay attention to the output of this debug command.
Step 41 Because the vNGIPS is generating a large volume of events relative to the SFR. Therefore, you
will build a filter to focus on events generated by the SFR.
a. In the FMC, navigate to Analysis Search.
b. Build a filter to filter out the vNGIPS

sensor connection events. Use the Attribute Name Attribute Value
following attribute values. Leave all
Table Connection Events
other attributes empty. Then click
Save. Name ASASFR Only
Note that Security Context is criteria. Device ASASFR

This is useful in multi-context mode.
c. Click Save.
Step 42 Navigate to Analysis Connections Events. Select ASASFR Only from the search sub-menu.
Note that all SSH connections have been logged.

Step 43 Click on the Table View of Connection Events in the upper left-hand corner. This will provide
details about each connection event.
This view will be the most useful when investigating events in later labs.

Lab Exercise 3: Security Intelligence
Task 3.1: Upload network, URL and DNS lists
Task 3.2: Configure a DNS sinkhole
Task 3.3: Configure Security Intelligence in an access policy
Task 3.4: Test the Security Intelligence configuration
Exercise Objective
In this exercise, your goal is to perform Security Intelligence configuration. Upon successful
Deploy an IP based black list
Deploy a URL based black list
Configure and deploy a DNS sinkhole
Lab Exercise Steps

Task 3.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 3.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 indication of compromise (IoC) generated.
b. Click Save.

Step 6 Navigate to Policies Access Control DNS. Click Add DNS Policy.
a. For the name, enter ASASFR DNS Policy. Click Save.
b. Click Add DNS Rule. Configure the rule as shown below. You can use the search box to
find DNSList1.
c. Click Add to add the rule. Then click Save to save the new DNS policy.
Task 3.3: Configure Security Intelligence in an access policy

Step 7 Navigate to Policies Access Control Access Control. Edit the ASASFR Access Policy.
Step 8 Select the Security Intelligence Tab.
a. Uncheck the Inherited from (Global Access Policy) checkbox on the left side of the page.
b. Select ASASFR DNS Policy from the DNS Policy drop-down menu.
c. Using the Networks tab under Available Objects, select the network list or feed you
created in Task 3. Click Add to Blacklist.
d. Using the URLs tab under Available Objects, select the URL list or feed you created in
Task 3.1. Click Add to Blacklist.
e. Confirm that your Security Intelligence configuration look what you see below.
f. Click Save to save the changes to the ASASFR Access Policy.

Step 9 Click Deploy in the upper right hand corner of the FMC UI.
a. Expand the list for the ASASFR. Confirm that the access control policy and DNS policy
are out of date.
b. Check the checkboxes for the ASASFR, and click the Deploy button.

Step 10 Click on the icon to the right of the Deploy link in the upper right-hand corner of the FMC UI. Wait
until the deployment is complete.
Task 3.4: Test the 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 The hostname ihaveabadreputation.com resolves to this.
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 ihaveabadreputation.com
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 get the default Firepower block page.
b. Click the Alt.FauxNet bookmark on the bookmarks toolbar. Note that you get the default
Firepower block page.
c. Click the Outside bookmark on the bookmarks toolbar. Click the Certs link. Note that
you get the default Firepower block page.
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 included, it hostname must be matched.
Therefore, http://outside.com/certs/ was matched, but http://alt.outside.com/certs/ was not matched.
Step 14 In the FMC, 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. Click on one of these red icons to view the host profile, and confirm
that this is a command-and-control connection IoC.


Lab Exercise 4: Snort and OpenAppID
Task 4.1: Configure a network analysis policy
Task 4.2: Configure an Intrusion policy
Task 4.3: Create a custom application detector
Task 4.4: Modify the ASASFR Access Policy
Task 4.5: Test Snort and OpenAppID
Exercise Objective
In this exercise, your goal is to understand how Snort and OpenAppID are configured on
Firepower.
Configure and deploy a custom intrusion policy, including Snort preprocessor settings
and custom Snort rules
Utilize the OpenAppID feature to deploy a custom application detector
Lab Exercise Steps

Task 4.1: Configure a network analysis policy
Starting with 5.4, most Snort preprocessor settings became part of a new policy type called the
network analysis policy. The preprocessor change you will make here will not affect the lab
exercise. But this exercise is included to show how such preprocessor customization is made.
Step 1 Navigate Policies Access Control Access Control, and edit the Global Access Policy.
a. Select the Advanced tab, and edit the Network Analysis and Intrusion Policies section.
b. Click the Network Analysis Policy List link. A new tab will open in the browser.
i. Click Create Policy to create a new network analysis policy. Call it Global
Preprocessor Settings. Click Create and Edit Policy.

ii. Modify the Policy of the TCP Stream Configuration to emulate the newer
Windows platforms when reassembling TCP streams. There is no Save button.
iii. Click on Policy Information in the upper left-hand corner.
iv. Click Commit Changes and then click OK.

v. Close the browser tab.
c. Select Global Preprocessor Settings from the Default Network Analysis Policy drop-down
menu.
d. Click OK.
e. Click Save to save the changed you made to the Global Access Policy.
These changes will be deployed later in this lab exercise.
Task 4.2: Configure an intrusion policy

We will add some test rules to make testing the intrusion policy easier. These are not rules you
would use is practice. You can inspect the rules by clicking on the Snort_Rules.txt text file in the
Files folder on the Jump Box desktop.
Note: Note that the rules lack the service metadata attribute. This reflects a significant change in how Snort from
previous releases of Firepower. This feature is called Port Override for Service Metadata. See the
appendix for details.
Step 2 In the FMC, 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.
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 3 Navigate to Policies Access Control Intrusion.
Step 4 Click the Create Policy button.

a. Set Name to Custom 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 5 You will now modify the rules states for this new policy.
a. Click Firepower Recommendations in the Policy Information
menu on the left-hand side of the Edit Policy page.
b. Click Generate and Use Recommendations. Then click OK.
c. Click Rules in the Policy Information
menu on the left-hand side of the Edit Policy page.
d. 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.
e. 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.
f. Check the checkbox next to the second rule. Select Drop and Generate Events from the
Rule State drop-down menu. Click OK.
Step 6 Click on Policy Information in the menu on the upper-left.
Step 7 Click Commit Changes. Click OK.
Task 4.3: Create a custom application detector

Step 8 Navigate to Policies Application Detectors.
Step 9 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 10 Click the Add button to the right of the Application Protocol drop-down menu.
a. Fill out the Application Editor page as below.
b. Click OK.

Step 11 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 12 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 13 Confirm that the application detector is configured as in the following figure. Then click Save.

Step 14 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 15 Click the green down-arrow to the right of the rule.
Open the custom detector in Wordpad, and inspect the Lua script.
Task 4.4: Modify the ASASFR Access Policy

Step 16 Navigate to Policies Access Control Access Control, and edit the ASASFR Access Policy.
Step 17 Change the Default Action from Intrusion Prevention: Balanced Security and Connectivity to
Intrusion Prevention: Custom Intrusion Policy.
Step 18 Click Add Rule.
a. For Name, enter Block TestApp
b. For Action, select Block with reset
c. In the Applications tab, search for TestApp, and add this application to the rule.
d. In the Logging tab, check the Log at Beginning of Connection checkbox.
e. Click OK.
Step 19 Click the Advanced tab.
a. In the Transport/Network Layer Preprocessor Settings, uncheck the Inherit from (Global
Access Policy) checkbox. Then click the pencil icon to edit these settings.
b. Enter 25 as value for Maximum Active Responses.
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 Click Save, and deploy the policy as before.

Step 20 Click Save to save the changes to the access policy.
Step 21 Deploy the modified access policy. Wait for the deployment to complete.
Task 4.5: Test Snort and OpenAppID

Step 22 Test the custom rule we imported.
a. You should still be logged into the inside UNIX server. If not, from the Jump Box
desktop, launch PuTTY and double-click on the pre-definite inside UNIX server session.
Login as root, password FPlab123!.
b. Run the following command from the inside UNIX server CLI.
ftp outside.com
c. Run the following FTP command.
cd ProjectQ
pwd
The string ProjectQ was replaced with ProjectR when the change directory command
was sent to the FTP server. This is because of signature 1001001.
d. Run the following FTP command.
cd ..
cd ProjectZ
The connection should be reset because of signature 1001002.
Step 23 In the FMC, navigate to Analysis Intrusions Events.
a. Verify that you see two intrusion events. One is for signature 1001001, and one is for
signature 1001002.
b. For one of the events drill down, using the down arrow on the left of the event. Observe
that you see more event details.
c. Drill down again. Under Packet Information, expand Packet Bytes. This shows a
capture of the packet that triggered the signature.
Step 24 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.
Step 25 In the FMC, navigate to Analysis Connections Events.
a. Filter using the ASASFR Only filter you built in Lab Exercise 2.
b. 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.

Lab Exercise 5: SSL Decryption
Task 5.1: Upload certificates and keys
Task 5.2: Configure an SSL policy
Task 5.3: Test SSL decryption
Exercise Objective
The objective of this exercise is to configure and utilize SSL decryption. Upon successful
Create and deploy an SSL policy
Understand how certificates are manipulated during SSL decryption.
Lab Exercise Steps

Task 5.1: Upload certificates and keys
Two CA certificates will be uploaded to the FMC.
The CA certificate for Example-DC-CA. This is the CA that signed most of the certificates
use in the lab exercises.
The CA certificate and key for Verifraud. Verifraud is the CA that will be used to re-sign
certificates when performing SSL decryption.
In a production environment, it would convenient for these to be the same. But for purposes of
testing and demonstrations, it is convenient to have these distinct. Then it will be easier to
identify when resigning takes place.
A server certificate/key pair will also be uploaded. This will be used to test known-key decryption.
Note: If you wish you can access the Example CA. There is a link on the Firefox browser. When prompted, log in
as Administrator, password FPlab123!.
Step 1 In the FMC, navigate to Objects Object Management PKI Trusted CAs.
a. Click Add Trusted CA.
b. For Name, enter 0Example. Prepending the zero will make the certificate easier to find
in trusted CA lists.
c. Click Browse, and browse the Desktop Certificates.
d. Upload Example_CA.cer.
e. Click Save.
Step 2 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. Upload Verifraud_CA.cer.
e. Click the Browse button to the right of the text Key or, choose a file.
f. Upload Verifraud_CA.key.
g. Click Save.
Step 3 Navigate to Objects Object Management PKI Internal Certs.
a. Click Add Internal Cert.
b. For Name, enter InsideServers.
c. Click the Browse button to the right of the text Certificate Data or, choose a file.
d. Upload Inside.cer.
e. Click the Browse button to the right of the text Key or, choose a file.
f. Upload inside.key.
g. Click Save.
Task 5.2: Configure an SSL policy

Step 4 To exempt the Firepower devices from decryption, create a Network Group to represent these
devices. Navigate to Objects Object Management Network.
a. Click Add Network Add Group.
b. For Name, enter Firepower.
c. Below the Selected Networks column, enter 172.16.1.80/32 and click Add. You can
omit the /32, if you wish.
d. Repeat the previous subset for 172.16.1.81/32 and 172.16.1.120/32.

Note: You will now configure an object override for the vNGIPS. Since this object will never be used in a policy on
the vNGIPS, the actual configuration of the override does not matter. This sub-step is included to show the
object override feature introduced in 6.0.
e. Check the Allow Overrides checkbox.

i. Expand the Override section.
ii. Click Add.
iii. Under Available Devices and Domains, select vNGIPS, and click Add.
iv. Select the Override tab.
v. Modify the list of Selected Networks.
vi. Click Add.
f. Click Save.
Step 5 Navigate to Policies Access Control SSL.
Step 6 Click the text Add a new policy or click the New Policy button.
a. For Name, enter ASASFR 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 Firepower.
b. Set Action to Do Not decrypt.
c. In the Networks tab, under Available Networks, select Firepower, and click Add to
Source.
d. Click Add to add this rule to the SSL policy.
a. For Name, enter Block untrusted internal certs.
b. Set Action to Block with reset.
c. In the Network tab, select IPv4-Private-172.16.0-12, and click Add to Destination.
d. Select the Cert Status tab, and next to Invalid Issuer, click Yes.
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 known keys.
b. Set Action to Decrypt Known Key.
c. Click in the text field to the right of the work with. Under Available Certificates
InsideServers. Click Add to Rule. Click OK.
d. In the Network tab, select IPv4-Private-172.16.0-12, and click Add to Destination.

a. For Name, enter Decrypt outside.
b. Set Action to Decrypt Resign.
c. Select Verifraud from the drop-down list to the right of the word with.
d. Check the Replace Key checkbox.
e. In the Network tab, select IPv4-Private-192.168.0.0-16, and click Add to Destination.
f. Select the Logging tab, and check the Log at End of Connection checkbox.
g. Click Add to add this rule to the SSL policy.
a. For Name, enter Exempt financial services.
b. Set Action to Do Not decrypt.
c. In the Category tab, under Categories, select Financial Services, and click Add to Rule.
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.
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. Check the Replace Key checkbox.
Note that this rule pre-empts the Default Action. If you used the Default Action, the only choices
are Do not decrypt, Block and Block with reset.
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-singed 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
selfsigned certificates.
Step 13 Click the scroll icon to the right of the Default Action. Check the Log at End of Connection
checkbox, and click OK. Note that as long as the Decrypt other rule is enabled, the Default
Action will not be hit. Therefore these log settings will not matter in this lab.

Step 14 Confirm that the rule table matches the below, and the click Save to save the SSL policy.
Note: Rule 3 may look redundant, in light of Rule 6. However it does make a difference if the HTTPS server
cannot be resolved to a URL category. When rule matching evaluates Rule 5, the decision will be made
not to decrypt, pending URL category resolution. This will avoid violating a policy, in the case the HTTPS
server turns out to be an unclassified financial services website.
Step 15 Select the Trusted CA Certificates tab.

a. Select 0Example to the Available Trusted CAs column.
b. Click Add to Policy.
Step 16 Click Save to save the SSL policy.

a. Select the Advanced tab.
b. Under SSL Policy Settings, uncheck the Inherit from base policy checkbox.
c. Edit the SSL Policy Settings, select the ASASFR SSL Policy and click OK.
d. Click Save to save the changes to the access control policy.
Step 18 Deploy the changes, and wait until the deployment is complete.
Task 5.3: Test SSL decryption

Step 19 In the Firefox Browser on the PC1 remote desktop perform the following.
a. Go to Tools Test Application for OpenAppID Default User Agent. This will change
the user agent string back to the Mozilla user-agent, in the case you changed it in Lab 4.
Note: There is a bug in this particular build where application identification can break SSL decryption. Therefore, it
is essential that for your testing you are not using the OpenAppID test application.

b. Click the HTTPS to Outside bookmark on the bookmarks toolbar.
i. Click on the lock icon to the left of the URL.
ii. Click More Information, and confirm the certificate is signed by Verifraud.
iii. Surf to Files pz.html. The connection will be reset, because pz.html contains
the string ProjectZ.
c. Click the HTTPS to Alt.Outside bookmark on the bookmarks toolbar.
i. Observe that you get a browser warning: This Connection is Untrusted. If you do
not get this warning, you may have forgotten to check Replace Key when you
th
created your 4 SSL policy rule.
ii. Click Technical Details, and confirm the certificate is self-signed. Firepower
replaced the old self-signed certificate with a new self-signed certificate. This is
because Replace key was selected in the certificate resign rule.
iii. Click I Understand the Risks Add Exception Confirm Security Exception.
iv. Surf to Files pz.html. The connection will be reset, because pz.html contains
the string ProjectZ.
d. Click the Wells Fargo bookmark on the bookmarks toolbar.
i. Click on the lock icon to the left of the URL.
ii. Click More Information, and confirm the certificate is signed by Symantec, not
Verifraud. This is because of the Financial Services category exemption.
Step 20 In the Remote Desktop folder on the Jump Box desktop, double click on PC3. PC3 lies outside
the firewall. It will be used to test inbound connections to internal HTTPS servers.
a. Wait a few seconds for AnyConnect to connect. When presented with the security
warning, click Connect Anyway.
b. Login to AnyConnect as harry, password FPlab123!. Wait for the VPN connection to
be established
c. Open up Firefox from the desktop icon.
d. Click the Party Poker bookmark on the bookmarks toolbar. You should see the default
Sourcefire block page. This confirms that policies are being enforced over the
AnyConnect SSL connection.
e. Click the HTTPS to Unix.Example bookmark on the bookmarks toolbar.
i. Click on the lock icon to the left of the URL. Click More Information, and confirm
the certificate is signed by example-DC-CA. Since this certificate has a known
key, Firepower does not need to be resigned.
ii. Surf to Files pz.html. The connection will be reset, because pz.html contains
the string ProjectZ. Even without resigning, the traffic was decrypted and
analyzed by Firepower.
f. Click the HTTPS to Alt.Example bookmark on the bookmarks toolbar. The connection
will be reset because the certificate for this internal website is signed by an unknown CA.
Step 21 In the FMC, navigate to Analysis Connections Events.
a. Apply the ASASFR Only filter.
b. Drill down to the Table View of Connection Events.
c. Scroll through the events, focusing on the SSL Status column. Confirm that SSL
decryption is behaving as you expect.
d. Click on the X in any uninteresting field. For example, you can use the Initiator Country
Field.
e. Scroll down the list of disabled column, and confirm that there are many SSL related
columns that are not shown by default.
f. Scroll down to the bottom of the list of columns, and click Cancel.

Step 4 Click Add File Rule. This rule will detect and store Office documents, archives 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 5 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 4 Click Add File Rule. This rule will detect and store Office documents, archives 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 5 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 6 Confirm that you file policy rules look like the following.
Step 7 Select the Advanced tab. Confirm that Enable Custom Detection List is selected. Check the
Inspect Archives.
Note: Uninspectable archives are corrupt archive, or archives with a depth that exceeds the Max Archive Depth.
Step 8 Click the Save button in the upper-right to save the file policy.
Step 9 In the FMC, navigate to Objects Object Management. Select File Lists from the left-hand
navigation panel. Edit the Custom Detection List.
a. Select Calculate SHA from the Add by drop-down menu.
b. Click Browse, and select Zombies.pdf from the Files folder on the Jump Box desktop.
Click Open.
c. Click Calculate and Add SHAs.

Task 6.2: Deploy the file policy
a. Name the rule Catch All.
b. In the Inspection tab, set the Intrusion Policy to Custom Intrusion Policy.
c. In the Inspection tab, set the File Policy to Test File Policy.
Note: Note that this rule will capture all traffic. If you do not apply an intrusion policy to this rule, no traffic with be
inspected by the IPS.
d. Click the Logging tab. Confirm that the Log Files checkbox is also checked. Leave the
other settings alone.
e. Click OK to add the rule to the policy.
Step 12 Observer that the default rule from the Global Access Policy has a yellow warning triangle to the
left of its name. This is because the rule can no longer be hit by devices using the ASASFR
Access Policy.
Note that even though you cannot delete inherited default rules, you can preempt them.
Step 13 Click Save to save the changes to the access control policy.
Step 14 Deploy the changes, and wait until the deployment completes. You can ignore the warning.
Task 6.3: Test the file policy

Step 15 You should still have a PuTTY session open to the inside UNIX server. If not, from the Jump
Box desktop, launch PuTTY and double-click on the pre-definite inside UNIX server session.
a. First use WGET to download the file blocked by type.
wget -t 1 outside.com/files/test3.avi
Note that very little of the file is downloaded. This is because the SFR can detect the file
type when it sees the first block of data.
b. Next use WGET to download malware.
wget -t 1 outside.com/files/Zombies.pdf
Note that about 99% of the file is downloaded. This is because the SFR needs the entire
file to calculate the SHA. The SFR holds onto the last block of data until the hash is
calculated and looked up.
Step 16 Repeat the previous Step, but use HTTPS instead of HTTP.
wget -t 1 --no-check-certificate https://outside.com/files/test3.avi
wget -t 1 --no-check-certificate https://outside.com/files/Zombies.pdf
Note that even though you are using HTTPS, your policy is enforced because of SSL inspection.
Step 17 Transfer several files.

a. Run the following command from the inside UNIX server CLI.
ftp outside.com (Login as root, password FPlab123!.)
bin
prompt
mget *
quit
This will grab several files from outside.com. Not all will be detected, and the AVI should
be blocked. This doesnt matter. We just want to transfer several files. Note that
individual data connections are reset, but the FTP control connection stays intact.
b. Run the following command from the inside UNIX server CLI.
ftp alt.outside.com (Login as root, password FPlab123!.)
bin
prompt
mput *
quit
This will push several files to alt.outside.com.
Step 18 Go back to PC1.
a. In the Firefox browser, click on the Outside link on the favorites tool bar.
b. Click on the Files link click on ProjectX.pdf. Once it is open, click the back button on the
browser.
c. Click on the Files link click on ProjectX.doc. Save the file, but do not open it.
d. Click on Zombies.pdf. The connection will be reset.
e. Click on bad.zip. Even though the malware is in an archive, you will not be able to
download the malware.
Step 19 Repeat the previous set, but using the HTTPS to Outside link. The results should be the same.
Step 20 In the FMC, navigate to Analysis Files Malware Events.

a. Drill down to Table View of Malware Events and examine the details of the events.
b. Click on the red computer icon next to one of the entries for 172.16.1.21

c. In the host profile, observe that there are now two indications of compromise.
Step 21 Navigate to Analysis Files File events.

a. Drill down to Table View of File Events.
b. Find the file ProjectX.pdf, and click on the grey circle to the left of the
SHA 64057e95...08f7fcc3.
c. What a minute for the file trajectory to open, and observer how the file propagated.
Step 22 Navigate to Analysis Files Captured Files and select Table View of Captured Files. Confirm
that files have been captured.


Lab Exercise 7: Identity
Task 7.1: Configure a realm
Task 7.2: Configure Cisco Firepower User Agent integration
Task 7.3: Configure the ASA for captive portal
Task 7.4: Create an identity policy
Task 7.5: Modify an access control policy to utilize authentication
Task 7.6: Test authentication
Task 7.7: Configure ISE integration
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
Redirect traffic the SFR sensor on the ASA
Configure Firepower to use the Cisco Identity Services Engine (ISE) for passive
authentication.
Note: You must take care when integration between Firepower and ISE is discussed, because is can mean more
than one thing. There is also a (currently unsupported) remediation module that allows the FMC to send
commands to ISE by using correlation policies.
Lab Exercise Steps

Task 7.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,
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.
Name EXAMPLE
Type AD
AD Primary Domain EXAMPLE
Directory Username Administrator@example.com
Directory Password FPlab123!
Base DN dc=example,dc=com
Group DN dc=example,dc=com
Group Attribute Member

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
download. Click OK.
Task 7.2: Configure Cisco Firepower User Agent integration
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 controller. You will probably not need
this in the Lab. See appendix for details.
Step 7 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.
Step 8 In the Remote Desktop folder on the Jump Box desktop, double-click on the SFUA short-cut.
Step 9 Double-click on the Cisco icon labeled Configure Cisco Firepower User Agent for Active Directory
on the SFUA desktop.
Step 10 Select the Active Directory Servers tab in the Cisco Firepower User Agent configuration tool.
a. Click Add, and enter the following information.
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 11 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 12 Minimize the remote desktop session to the SFUA VM.

Task 7.3: Configure the ASA for captive portal
Step 13 In the PuTTY session to the ASA, type the following commands into the ASA CLI:
config t
captive-portal global
wr me
Note: To display the active rules and how many times they have been hit, run
show asp table classify domain captive-portal
on the ASA CLI.
Task 7.4: Create an identity policy

Step 14 In the FMC, navigate to Polices Access Control Identity.
Step 15 Click on the text Add a new policy or click the New Policy button
a. For Name enter ASASFR Identity Policy.
Step 16 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 ASAcert.
c. Click the Browse button to the right of the text Certificate Data or, choose a file, and
browse to Desktop Certificates.
d. Upload asa.cer.
e. Click the Browse button to the right of the text Key or, choose a file, and browse to
Desktop Certificates.
f. Upload asa.key.
g. Click Save.
Note: This certificate is used when the client is redirected (HTTP 307) to the ASA interface for authentication over
HTTPS. Since the redirect URL contains the ASA 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 17 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.
d. Select EXAMPLE (AD) from the Realm drop-down menu.

e. Check the Use active authentication if passive authentication cannot identify user
checkbox.
f. Click Add to save the rule.

Step 18 Click Save to save the identity policy.
Task 7.5: Modify an access control policy to utilize authentication

Step 20 Select the Advanced tab.
a. Under Identity Policy Settings, uncheck the Inherit from base policy checkbox.
b. Edit the Identity Policy Settings, select the ASASFR Identity Policy and click OK.
Step 21 Select the Rules tab. Click Add Rule. You will now create a rule to block members of the HR
group from using SSH.
a. Call the rule Block HR from using SSH.
b. In the Insert drop-down menu, change below rule, to above rule.
c. Leave the rule number in the box to the right of the Insert drop-down list unchanged.
d. Set the action to Block with reset.
e. Select Users tab. Under Available Realms, click on EXAMPLE. The list of users and
groups should auto-populate.
f. In the search box under Available Users, type H. Select HR and click Add to Rule.
g. Select Applications tab, and Select SSH and OpenSSH. Click Add to Rule.
h. Select Logging tab. Check the Log at Beginning of Connection checkbox.
i. Click OK to add the rule to the policy.
Step 22 Click Save to save the updates to the access control policy.
Step 23 Deploy the policy and wait for the deployment to complete. You can ignore the warning.

Task 7.6: 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 24 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 25 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 26 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. Open the Firefox browser (if not already open) using the link on the PC1 desktop. Select
View Sidebar LiveHTTPHeaders (if not already selected).This will give insight into
the HTTP traffic.
b. Refresh the home page. You should see a login pop-up in the browser.
c. 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
d. Login as EXAMPLE\dilbert, password FPlab123!.

e. In the LiveHTTPHeaders, you should see the authentication communication.
Step 27 In the FCM, navigate to Analysis Users User Activity. Confirm that Ira and Harry used
passive authentication, and Dilbert used active authentication.

Task 7.7: Configure ISE integration
Note: Since 802.1x is not available in the lab pods, you will not actually test the ISE authentication process.
However, you will see how ISE attributes can be made available in the FMC to configure access control
policy rules.
Note: If you slipped Lab Exercise 5, please go back and do Step 1 before you proceed with this lab.
Step 28 In the FMC navigate to System Integration, and select the Identity Sources tab.
Step 29 Click the Identity Services Engine button.
a. For Primary Host Name/IP Address, enter ise.example.com.
b. Select 0Example from the pxGrid Server CA drop-down list.
c. Select 0Example from MNT Server CA drop-down list.
d. Click the Add button to the right of the MC Server Certificate drop-down list.
e. Click the green circle (with plus sign) to the right of the Server Certificate drop-down
menu.
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. If the test continues to fail, check
your configuration.
g. Click Save. Since you cannot use the Cisco Firepower User agent and ISE at the same
time, you will see the following warning.
h. Click Yes.

a. Click Add Rule, and select the ISE Attributes.
b. In the Available ISE Session Attributes column, select Security Group Tag, and confirm
that the Available ISE Metadata column auto-populated. Note that there is no Security
Group Tag beginning with the numeral zero one will be added later is this task.
c. In the Available ISE Session Attributes column, select Device Type, and confirm that the
Available ISE Metadata column auto-populated.
d. In the Available ISE Session Attributes column, select Location IP, and confirm that the
Step 31 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 3 capabilities, or topics of information, that the FMC is subscribed to:
EndpointProfileMetaData contains the ISE device information
SessionDirectory defines the ISE session attributes
TrustSecMetaData defines the Security Group Tag (SGT) information

Step 32 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 ISE Session Attributes column,
switch from Location IP to Security Group Tag. Note that the SGT 0TestTag is now
available.
d. Click Cancel to exit editing the rule.
e. In the FMC, navigate to System Monitoring Syslog.
f. Search for pxgrid. This can be useful for troubleshooting ISE integration issues.
g. Search for Endpoint. You should see the logging of a successful connection between
the FMC and ISE pxGrid node. You should also see that the FMC has successfully
subscribed to the EndpointProfileMetaData capability. You can, if you wish, search the
syslog for the other capabilities.
Step 33 Click Cancel to exit editing the rule.
Step 34 Click Cancel to exit editing the access policy.

Lab Exercise 8: Domains
Task 8.1: Create and configure domains
Task 8.2: Enforce policy inheritance
Task 8.3: Configure leaf domains
Task 8.4: Configure domain specific roll based access control
Exercise Objective
In this exercise, your goal is to perform basic domain configuration. Upon successful completion
of this exercise, the student will be able to:
Configure domains
Confirm visibility and control restrictions domains provide
Lab Exercise Steps

Task 8.1: Create and configure domains
Step 1 In the FMC, navigate to System Domains.
Step 2 Click Add Domain.
a. For Name, enter ASAdomain.
b. Under Available Devices, select the ASASFR, and click Add to Domain.
c. Click Save.

Step 3 When use see the Unassigned Devices dialog box, click Create New Domain.
a. For Name, enter IPSdomain.

b. Under Available Devices, select the vNGIPS, and click Add to Domain.
c. Click Save.
Step 4 Click Save to save the domain configuration. You will be presented with the following dialog box.
Leave the default setting to delete the old network map. Then click Save.
rd
Note: If you want to avoid losing the old network map, you can create a 3 domain with no devices in it, and have
rd
the 3 domain inherit the network map.
Step 5 When you see the following message, click OK. Do not deploy the changes yet.
Step 6 Look at the upper right-hand corner of the FMC to confirm that you are in the Global domain.
This may take a minute or so, and perhaps a browser refresh.
Step 7 Navigate to Analysis Connections Events. Confirm that the events are still available.
Step 8 Navigate to Analysis Hosts Network Map. Confirm that the now there are two empty
network maps.
Task 8.2: Enforce policy inheritance

Step 9 Navigate to Policies Access Control Access Control.
Step 10 Edit the ASASFR Access Policy.
a. In the upper left click the text Policy Assignments (1).
b. Select the Required on Domains tab.
c. Under Available domains, select ASAdomain and click Add to Policy.

d. Click OK.
e. Click Save to save the changes to the access control policy.
Step 11 Edit the vNGIPS Access Policy.
a. In the upper left click the text Policy Assignments (1).
b. Select the Required on Domains tab.
c. Under Available domains, select IPSdomain and click Add to Policy.
d. Click OK. Click Save to save the changes to the policy.
Task 8.3: Configure leaf domains

Step 12 Using the drop-down menu in the upper corner or the FMC, change to the ASAdomain.
Note: When you change from one domain to another, you are often presented with a change password page. This
is a know issue with the build used in this class. You can ignore this page.
Step 13 Navigate to Devices Device Management. Confirm that only the ASASFR device is visible.
Step 14 Navigate to Devices Platform Settings. Confirm that the global platform settings are still in
use. You could change these setting by creating a new policy, if you wished.
Step 15 Navigate to Policies Network Discovery. Note the policy has reverted to the default policy.
Modify this policy as you did in Task 2.4. Do not deploy the policy.
Step 16 Navigate to Policies Access Control Access Control.
a. Note that you cannot edit any of the existing access policies. That is because they were
created in the global domain.
b. Note the to the right of the ASASFR Access Policy. This indicates that the policy is a
required ancestor for any access control policy created in this domain.
Step 17 Click New Policy.
a. For Name, Enter ASA Leaf Policy.
b. Notice that you must select ASASFR Access Policy as the base policy.
c. Select the Intrusion Prevention radio button.
d. Under Available Devices, select ASASFR and click Add to Policy.
e. Click Save.
f. You will get the following Error box. This is really a warning. Read it carefully, and then
ignore it by clicking Yes.
g. Notice that this policy inherits mandatory rules from 2 ancestor policies.
Step 18 Navigate to Objects Object Management.
a. Select Network Add Network Add Object.
b. For Name, enter 0Network. Prepending the zero character will make the object easier
to see (or not see) on lists.
c. For Network, enter 1.2.3.4.
d. Click Save.
Step 19 Deploy all changes, and wait for the deployment to compete.
Task 8.4: Configure domain specific role based access control

Step 20 Switch back to the Global domain, using the drop-down menu in the upper right corner of the
FMC.
Step 21 Navigate to System Users.
Step 22 Click Create User.
a. For Name, enter IPSadmin.
b. For Password, enter FPlab123!. Confirm the password.
c. Click Add Domain.
i. In the Domain drop-down menu, select IPSdomain.

ii. Select the Administrator checkbox.
iii. Click Save.

d. Click Save.
Step 23 Log out of the FMC.
Step 24 Log into the FMC as IPSadmin, password FPlab123!.
a. Note that you cannot change to a different domain.
b. Navigate to Object Object Management. Confirm that you cannot see the network
object called ONetwork.
c. Navigate to Devices Device Management. Confirm that you can only see the
vNGIPS.

End of Lab: Congratulations! You have successfully completed the lab.

Please let your proctor know you finished and provide any feedback to help
improve the lab experience.
Appendix
Port Override for Service Metadata
Prior to this feature, Snort would skip source port and destination port checks if the packets
application protocol was identified. This had simplified deployment but had some draw-backs. In
brief:
False positives Rules intended to match only on a specific port and must contain
metadata: service http to work at all if AppID is enabled.
False negatives Rules to detect TCP protocol header anomalies that dont contain
metadata: service http will never alert on traffic that has been identified as HTTP
With Snort 2.9.8, used in Firepower 6.0, control for this behavior is now available. The rule writer
has the ability to change the behavior per-rule with new service override keywords.
and-ports match service and port
or-ports match service or port
else-ports match service else port
Examples:
alert tcp any any -> any 80 (metadata:service and-ports, service
http;) This would only match HTTP traffic to port 80.
alert tcp any any -> any 80 (metadata:service or-ports, service
http;) This would match HTTP traffic to any port, and any TCP traffic to port 80.
alert tcp any any -> any 80 (metadata:service else-ports, service
http;)
This would match HTTP traffic to any port. If the service is known, but not HTTP, the rule
will not match. If service is unknown, this would match any TCP traffic to port 80.
alert tcp any any -> any 80 (metadata:service else-ports;)
This would match TCP traffic to port 80, but only if the service is unknown.
alert tcp any any -> any 80 (msg:no metadata;)
This would match all TCP traffic to port 80. It does not matter whether the service is
known or not.
Note that rules no longer require the metadata service attribute. Rules without this attribute will
work as expected. That is, they will match based on the ports specified in the Snort rule header.

Generating troubleshooting files
If you engage technical support, they will probably want you to generate troubleshooting files. To
do this, perform the following steps..
Step 1 Navigate to System Health Monitor.
Step 25 Click on the Appliance Status Summary pie chart.
Step 26 Under Appliance, click on the name for the FMC or the appliance you want troubleshooting files
from.
Step 27 Click the Generate Troubleshooting Files.
Step 28 Select the data to include, and click Generate.
Step 29 Click Generate.
Step 30 Click on the icon to the right of the Deploy link in the upper right corner of the FMC.
Step 31 Select the Tasks tab.
Step 32 When the task completes click the link Click to retrieve generated files. The browser will
download the files.

Labsec 2339 LG

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Labsec 2339 LG

Uploaded by

Copyright:

Available Formats

Cisco ASA with Firepower Services

6.0 (v1.3) Lab Guide

Arial Bold Used to indicate emphasis

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

Cisco ASA with Firepower Services 6.0 (v1.3) February 2016 1

Lab Exercise 1: Initial SFR Configuration ............................................................................ 7

Cisco ASA with Firepower Services 6.0 (v1.3) February 2016 2

Product Overview: Cisco ASA with Firepower

Cisco ASA with Firepower Services 6.0 (v1.3) February 2016 3

This is the topology used for this lab.

Cisco ASA with Firepower Services 6.0 (v1.3) February 2016 4

[Pod Edge Router no user access] [192.168.1.1]

Jump Box 172.16.1.50, 192.168.1.50

ASA 5525-X 172.16.1.1, 192.168.1.2

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

vNGIPS (Virtual Sensor) 172.16.1.81

PC3 (For AnyConnect testing) 192.168.1.23

Cisco ASA with Firepower Services 6.0 (v1.3) February 2016 5

Access To Account (username/password)

Jump Box Administrator/FPlab123!

ASA 5525-X SSH access: admin/FPlab123!

ASA SFR admin

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!

SF (Stand-alone Sourcefire 3D sensor) admin/Sourcefire

Account (username/password) Group

Cisco ASA with Firepower Services 6.0 (v1.3) February 2016 6

Lab Exercise Steps

Task 1.1: Perform initial configuration on the SFR

Cisco ASA with Firepower Services 6.0 (v1.3) February 2016 7

New password FPlab123!

IPv4 address for Management 172.16.1.80

IPv4 mask 255.255.255.0

IPv4 gateway 172.16.1.1

[IPv6 configuration attributes] [IPv6 will not be configured.]

DNS servers 172.16.1.100

Search domains example.com

Task 1.2: Explore on-box management capabilities

Note: If you convert between on-box and off-box management,

See the appendix for instructions on how to use policy

Step 9 In the Tools folder on the Jump Box desktop, double

Cisco ASA with Firepower Services 6.0 (v1.3) February 2016 8

Cisco ASA with Firepower Services 6.0 (v1.3) February 2016 9

End of Exercise: You have successfully completed this exercise.

Cisco ASA with Firepower Services 6.0 (v1.3) February 2016 10

Lab Exercise Steps

Cisco ASA with Firepower Services 6.0 (v1.3) February 2016 11

g. Click Save to save the Global Access Policy settings.

Cisco ASA with Firepower Services 6.0 (v1.3) February 2016 12

g. Click the Save button in the upper right-hand corner.

iv. Click OK.

f. Click the Save button in the upper right-hand corner.

Cisco ASA with Firepower Services 6.0 (v1.3) February 2016 13

Cisco ASA with Firepower Services 6.0 (v1.3) February 2016 14