cisco asa with firepower services 6.0 (v1.3) lab guide developers

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

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 [email protected].

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.


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) (PC1, PC2., PC3, SFUA, DC)

Administrator/ FPlab123!

ISE (Identity Services Engine admin/FPlab123! (GUI) admin/ISEfp123! (CLI)

Attrack.outside.com (Ubuntu)

root/FPlab123!

Inside UNIX Server (unix.example.com) (CentOS)

root/FPlab123! guest/FPlab123!

Outside UNIX Server (outside.com) (CentOS)

root/FPlab123! 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 Exercise Description

This exercise consists of 6 tasks. 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.


a. Enter the following information: 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.


a. Enter the following information: 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 following attribute values. Leave all other attributes empty. Then click Save. Note that Security Context is criteria. 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.



Table Connection Events

Name ASASFR Only

Device ASASFR


Lab Exercise 3: Security Intelligence Exercise Description

This exercise consists of 4 tasks. 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 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

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. c. For Feed URL, paste the shortcut you copied. 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. c. For Feed URL, paste the shortcut you copied. 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 Exercise Description

This exercise consists of 5 tasks. 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 Login as root, password FPlab123!.

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

This exercise consists of 3 tasks. 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 completion of this exercise, the student will be able to:

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

Step 17 Navigate to Policies Access Control Access Control. Edit the ASASFR Access 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 created your 4th 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 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 Step 10 Navigate to Policies Access Control Access Control. Edit the ASASFR Access 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. Login as root, password FPlab123!.

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 doesn’t 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 Exercise Description

This exercise consists of 7 tasks. 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 [email protected]

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 19 Navigate to Policies Access Control Access Control. Edit the ASASFR Access Policy.

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.


Step 30 Navigate to Policies Access Control Access Control. Edit the ASASFR Access Policy.

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

This exercise consists of 4 tasks. 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.

Note: If you want to avoid losing the old network map, you can create a 3rd domain with no devices in it, and have the 3rd 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 packet’s 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 don’t 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.