Ssfips20 LG PDF

SSFIPS
Securing Cisco
Networks with
FireSIGHT Intrusion
Prevention System
Lab Guide
Version 2.0
Part Number: 97-xxxx-01
Americas Headquarters
Cisco Systems, Inc.
San Jose, CA
Asia Pacific Headquarters

Cisco Systems (USA) Pte. Ltd.
Singapore
Europe Headquarters
Cisco Systems International BV
Amsterdam,
The Netherlands
Cisco has more than 200 offices worldwide. Addresses, phone numbers, and fax numbers are listed on the Cisco Website at
www.cisco.com/go/offices.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To
view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third party trademarks mentioned are the
property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any
other company. (1110R)
DISCLAIMER WARRANTY: THIS CONTENT IS BEING PROVIDED AS IS. CISCO MAKES AND YOU RECEIVE NO
WARRANTIES IN CONNECTION WITH THE CONTENT PROVIDED HEREUNDER, EXPRESS, IMPLIED, STATUTORY OR IN
ANY OTHER PROVISION OF THIS CONTENT OR COMMUNICATION BETWEEN CISCO AND YOU. CISCO SPECIFICALLY
DISCLAIMS ALL IMPLIED WARRANTIES, INCLUDING WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT AND
FITNESS FOR A PARTICULAR PURPOSE, OR ARISING FROM A COURSE OF DEALING, USAGE OR TRADE PRACTICE.
This learning product may contain early release content, and while Cisco believes it to be accurate, it falls subject to the disclaimer
above.
Welcome, Students!
Students, this letter describes important course evaluation access information!
Welcome to Cisco Systems Learning. Through the Cisco Learning Partner Program, Cisco is
committed to bringing you the highest-quality training in the industry. Cisco learning products are
designed to advance your professional goals and give you the expertise that you need to build
and maintain strategic networks.
Cisco relies on customer feedback to guide business decisions. Therefore, your valuable input will
help shape future Cisco course curricula, products, and training offerings. Please complete a brief
Cisco online course evaluation of your instructor and the course materials in this student kit. On
the final day of class, your instructor will provide you with a URL, directing you to a short postcourse evaluation. If there is no Internet access in the classroom, please complete the evaluation
within the next 48 hours or as soon as you can access the web.
On behalf of Cisco, thank you for choosing Cisco Learning Partners for your Internet technology
training.
Sincerely,
Cisco Systems Learning
2015 Cisco Systems, Inc.
Table of Contents
Introduction ................................................................................................................................. 3
Introduction .............................................................................................................................. 3
Lesson 1 Lab Exercises ........................................................................................................... 7
Lesson 3 Lab Exercises ........................................................................................................... 9
Lesson 4 Lab Exercises ......................................................................................................... 10
Lesson 10 Lab Exercises ....................................................................................................... 25
Lesson 13: Lab Exercises ...................................................................................................... 34
Securing Cisco Networks with FireSIGHT Intrusion Prevention System (SSFIPS)
ii
Introduction
Introduction
The lab infrastructure that is provided for this training consists of a remotely accessible virtual learning
environment. Because some of the FireSIGHT Systems features are implemented in hardware, it is not
possible to demonstrate all of the products functionality in this lab environment.
The instructor will assist students with access procedures to enter the environment. Once you are in, you
will have full access to all the virtual machines depicted in the figure to perform the structured labs or to
experiment with if you wish.
Classroom Environment
This section describes the setup and configuration of the virtual infrastructure. The following figure
illustrates the topology of each student virtual network.
2015 Cisco and/or its affiliates. All rights reserved.
12
Using the Virtual Network Infrastructure

The instructions for initializing the virtual environment will be presented shortly; however, it may be
helpful to understand some of the VMware navigation tactics that will be used throughout the class.
Use the following VMware navigation tips:
Each virtual machine will appear as a tab at the top of the VMware application window. To navigate
from one virtual machine to another, simply double-click the corresponding tab.
Right-clicking the previously mentioned tab brings up the context menu.
The main panel of the VMware application window displays either a command-line console for the
selected virtual machine or the graphical interface of the selected virtual machine.
If you click inside the command-line console of a virtual machine, the mouse pointer is captured by
the virtual machine and becomes unavailable for use on the desktop until you press Ctrl-Alt.
If you click inside a virtual machine with a graphical interface, the mouse will be available to both
the desktop and the virtual machine.
Accessing the Virtual Machines

The login credentials for the virtual machines are as follows:
For all of the Linux-based machines:
Username: root
Password: password
For all of the FireSIGHT appliances:
Username: admin
Password: password
Shutting Down the Virtual Machines

In order to prevent operating system corruption, you should use the following commands to shut down the
virtual machines:
shutdown -h now (halts the virtual machine)
shutdown -r now (reboots the virtual machine)
Additional Lab Usage Tips
The desktop is part of the lab environment. You should be able to access any of the virtual machines
with the tools that are provided on the desktop.
Use the PuTTY terminal application to access the CLIs of the virtual machines rather than the VMware
console window.
You will be able to open multiple PuTTY terminal sessions.
You can expand the terminal window to see more command-line information.
You will see an icon for the PuTTY application on the desktop, or you can type putty.exe from the search
field of the Windows start menu.
The hostnames of the virtual machines should resolve if you prefer to use them rather than accessing
everything by IP address.
Initializing the Lab Environment

Using the CMD prompt, follow these steps to initialize the lab environment:
Open the VMware application on your desktop.
Navigate to the folder in the left panel that contains all of the virtual machines, and click to
select it. Then click the green play button located in the upper-right portion of the VMware
application window. Allow about 3 minutes for all the virtual machines to initialize.
From your desktop, open a command line and make sure that you can access each virtual
machine with the ping command. For example:
ping Attila
ping LAMP
Lesson 1 Lab Exercises

These lab exercises are designed for you to verify licenses on your FireSIGHT Management Center and to
test the environment by executing scripts for generating IPS and FireSIGHT events.
Lab 1-1: Verifying the Product Licenses

Open a web browser on your desktop and navigate to the Defense Center user interface by
entering the following URL: https://192.168.111.20.
To navigate to the License page, choose System, followed by Licenses.
For the Virtual DC, ensure that the FireSIGHT license is valid.
For the Virtual Device, ensure that URL Filtering, Protection, Control, and Malware licenses are
valid.
Click the Devices menu item at the top and click the Edit icon (the pencil icon) for your
managed device.
Click the Device tab. In the License section, verify that the Protection, Control, Malware, and
URL Filtering capabilities are set to Yes.
Lab 1-2: Testing the Environment by Running Attack PCAPs

Use the following procedure to generate some network traffic that produces alerts through the IPS.
Log into the host Attila by using the root and password credentials.
Issue the following command:
./ips_test.pl
When you are prompted, press Enter to continue.
Press 1 to select the inline output method.
Press 1 to accept your entry.

This script takes 3060 seconds to run.
Lab 1-3: Viewing Events

All of the scan activity and scripts that you launched in the previous lab were for the purpose of generating
some events in the FireSIGHT System and for populating the system with host data. To confirm that you
have events, perform the following steps:
To view IPS alerts, navigate to Analysis, followed by Intrusions and Events.
To view connection events while in the Intrusion Events view, click the Jump To tab and
choose Connection Events. To view Discovery events, click the Jump To tab and choose
Discovery Events.

Lab 3: Configuring an Inline Interface
In this lab, you will delete an existing interface set and then create a new one. When the interface set is
deleted, the network traffic stops. To illustrate this point, a series of pings will be sent through the device.
Once the new set is in place, the pings will continue.
Perform the following steps to create a new inline set:
From your desktop, open a CMD prompt and issue the following command: ping Bleda -t.
Let the pings continue until the end of the exercise.
Navigate to Devices and click the Device Management tab.
Click the edit button for your managed device.
Click the Interfaces tab to display the list of sensing interfaces. Note that the system has assigned
the internal security zone to eth1 and the external security zone to eth2.
You will reverse the security zone assignment of the interfaces to conform to the class topology
by clicking the edit button of each interface and selecting the appropriate zone. At the end of this
process, eth1 should be set to external and eth2 should be set to internal.
Click the Inline Sets tab and delete the Default Inline Set.
Click the Add Inline Set button to create an inline interface set called Training. Assign eth1
and eth2 to the Training inline set. Click OK.
Click Apply Changes and then observe the previous pings that were initiated from your desktop
to Bleda. There should be either a delay or a failure of the pings while the new configuration is
applied.
Stop the pings from your desktop to Bleda by typing [Ctrl] + c in the command-line window.

In this lab, you will create an internal user account. Using this account, you will configure and test the UI
timeout for exempt versus nonexempt users. Also, with the internal user account, you will demonstrate
permission escalation. You will also demonstrate the precise control that you can have over external user
authentication when you take advantage of group-controlled access. Users who belong to groups can
automatically be granted a role that is appropriate for the access level they need when the authentication
object is properly configured with group access control filters.
Lab 4-1: Creating User Accounts and Configuring UI Timeout

Value
In this lab, you will create an internal user account.
Navigate to System, followed by Local, and click User Management.
Click the Create User button.
In the User Configuration section, enter NOC in the User Name field.
In the Password field, enter training. Confirm the password in the Confirm Password field.
In the Options field, choose the check box that is associated with Exempt from Browser
Session Timeout.
In the User Role Configuration section, choose the check box that is associated with Security
Analyst.
Click Save to save the new user account.
Now you will configure the browser session value that is applied to all pages of your user
interface.
Navigate to and edit the system policy titled Initial_System_Policy. Go to System > Local >
System Policy.
Click the User Interface link.
In the Browser Settings section, enter 3 in the Browser Session Timeout field. This setting will
provide a 3-minute UI timeout value for users who are not exempt.
Click Save Policy and Exit. Then apply the system policy to your Defense Center.
Lab 4-2: Testing Exempt vs. Nonexempt Users

Log out as administrator and log in with the NOC user credentials.
You are directed to the Dashboard page. This page refreshes frequently, so this method is good
for testing this timeout feature. Keep this page open for at least 3 minutes.
Because the NOC user is exempt from the browser session timeout, that browser session should
never time out.
10
Log out as NOC and log back in with the administrator credentials.
In 3 minutes, the administrator browser session will time out. The administrator user role cannot
be exempt. Administrators have access to all menu options, and their sessions present a higher
security risk if compromised.
Once you are logged out, log back in with the administrator credentials.
Navigate back to the System Policy titled My System Policy and change the browser session
timeout back to the default value (60 minutes).
Lab 4-3: Escalating Permissions

You will create a custom user role and tune this user role to include the ability to escalate
permissions.
Navigate to System and then Local, and choose User Management.
Click the User Roles tab. Then click the Create User Role button. In the Name field, enter
Student 1 User Role. Click Save and then click OK.
Click Configure Permission Escalation. Set the target to Administrator and click OK.
Now you will edit your custom user role.
Click the Edit icon that is associated with Student 1 User Role.
In the System Permissions section, choose the check box that is associated with Set this role to
escalate to: Administrator.
Set the role to authenticate with the assigned user password.
Click Save.
Navigate back to the NOC user configuration and choose Student 1 User Role as the custom
user role. Leave the existing user role in place.
Click Save.
Log out of your current session and log back in using your internal account user NOC.
You will now escalate your internal account permissions.
Log out of the current session and log back in using your internal account user NOC.
Navigate to the NOC link (in the upper right of the user interface) and choose Escalate
Permissions. Enter the password that you configured for the NOC account.
Confirm that the user interface was updated to support the escalated administrator permissions.
You should be able to perform the same tasks with the NOC and administrator users.
Log out of the session and log back into the user interface, using the administrator credentials.
11
Lab 4-4: Working with an External User Account

In this lab, you will review an LDAP authentication object.
Click the Login Authentication tab. Then click the Edit icon next to the Bleda_LDAP
authentication object.
Here is the configuration for the external authentication object:
Authentication Method: LDAP
Name: Bleda_LDAP
Server Type: OpenLDAP
Hostname/IP Address: 192.168.10.90
Port: 389
Base DN: ou = people, dc = sfsnort, dc = com
Username: cn = admin, dc = sfsnort, dc = com
Password: password
Confirm Password: password
UI Access Attribute: uid
Group Controlled Access Roles (expand arrow):
Administrator:
cn = admingroup, ou = groups, dc = sfsnort, dc = com
Intrusion Admin:
cn = dbgroup, ou = groups, dc = sfsnort, dc = com
Security Analyst:
cn = ieagroup, ou = groups, dc = sfsnort, dc = com

Do not set a default user role. If you do, you can deselect it by holding down the Ctrl key and clicking the
selection.
Group Member Attribute: member
Shell Access Filter: check same as base filter
Click Cancel.
Lab 4-5: Testing the LDAP Authentication Object

Click the Login Authentication tab.
Click the Edit icon to edit the Bleda_LDAP object.
12
Provide the username student01 and the password password in the Additional Test Parameters
section. Click the Test button. Make sure that you receive a Success Test Complete message at
the top of the page.
Navigate to the bottom of the page and view the Test Output (expand the arrow in the Show
Details field). What other accounts did your test discover?
Verify that your system policy is enabled for external authentication referencing the object that
you reviewed previously. Edit the system policy titled Initial_System_Policy and navigate to
the Authentication Profiles section of the policy.
Configure the following settings in the Authentication Profiles section:
Status: Enabled
Default User Role: None selected (You can deselect an item by holding down the Ctrl key
and clicking the item, if you have accidentally selected one.)
Shell Authentication: Enabled
Enable the authentication object by clicking the check box where Bleda is listed on the page.
Remember to save and apply the policy before moving to the next step.
Now log out of your Sourcefire System GUI and log back in with the student01 account and the
password password.
Were you able to log in?
Which access role were you granted?
Test other user accounts to see which role or roles they are granted. You can use the following
accounts (they all have the password set to password): student02, student03, extdb, and maint.
Do all of the accounts work? If not, which one does not and why? (The test output might yield
important clues.)
13

In this lab, you will create objects that will be used in your access control policy.
Lab 5: Creating Objects

Click Objects in the main menu.
Click Individual Objects.
Click the Add Network button.
In the Network Objects dialog box, enter LAMP in the Name field and 192.168.10.99 in the
Network field. Click Add and then click Save. Perform the preceding steps for the following
networks (be sure to click Add and then Save for each network as it is created):
Bleda: 192.168.10.90
Rugila: 192.168.133.60
dmz_net: 192.168.10.0/24
general_net: 192.168.133.0/24
Click the Network / Object Groups link.

Click the Add Network Group button.
In the Name field, enter enterprise_net. Choose dmz_net and general_net and click the Add
button to add them into the Selected Networks column.
Click Save.
In this part of the exercise, you will create a new variable set that contains the networks of interest for the
class:
Click the Variable Set option.
Click Add Variable Set.
Enter the name of the new variable set: SFSnort_Set.
Click the Edit icon next to the HOME_NET variable.
In the Network field under Include Networks, add the 10.0.0.0/8, then add the 172.0.0.0/8, and
then add the 192.0.0.0/8 network.
Click Save, and then click Save again.
14

In this lab, you will apply objects to access control policy rules.
Lab 6-1: Creating a Basic Access Control Policy

Click Policies, which automatically takes you to the Access Control Policy screen.
Click the New Policy button.
In the Name field, enter Training Policy. The default action should be set to Block all Traffic.
From the Available Devices column, select your managed device, and click Add to Policy. This
action will add your managed device to the Selected Devices list. Click Save.
Click the Add Rule button.
In the Name field, enter DMZ Web Access.
Click the Networks tab. Choose LAMP and Bleda network objects and click Add to
Destination.
Click the Ports tab. Choose HTTP and HTTPS and click Add to Destination.
Click the Logging tab. Set the rule so that any connections that it identifies are logged at the end
of the connection.
Click Add.
Create a second rule to allow an SSH connection from Rugila to Bleda:
In the Name field, enter SSH Rugila to Bleda.
Click the Networks tab. Choose Rugila and click Add to Source. Choose Bleda and click Add
to Destination.
Navigate to Ports, choose SSH, and click Add to Destination.
Click the Logging tab. Set the rule so that any connections that it identifies are logged at the end
of the connection. Click Add.
In the Default Action field of the access policy, click the Logging icon.
Enable logging at the beginning of the connection. Click OK.
Click the Save and Apply buttons. Click Apply All to confirm the apply operation.
Wait for the policy to be applied before you proceed to the next step.
Click the Task Status link to inspect the progress of the policy.
When the task status window indicates that the policy apply process is complete, close the
window and click the OK button to return to the policy edit page.
15
Test this configuration by running the following commands from Rugila:

Using the PuTTY application, create an SSH connection to Rugila.
Run this command: wget bleda. If the test is successful, you should see a message indicating
that the message request was sent, and a response code of 200 OK. Also, the command-line
feedback will show that 100% of the index.html file was downloaded.
Run this command: ssh bleda. If it is successful, you will see the password prompt. Enter the
password to access Bledas command-line shell. You can type Exit to return to Rugilas
command-line shell.
Navigate to Analysis and click Connections. You should see both the SSH and HTTP sessions
that were initiated by Rugila (192.168.133.60) to Bleda (192.168.10.90).
Keep in mind that you are logging connections at the end. The SSH session is not displayed in Connection
Events until the session is complete.
Lab 6-2: Creating an Access Control Policy for Application

Awareness
In this lab, you will change the policy configuration to use application control features.
At the bottom of the policy edit page, click the Default Action drop-down menu and choose
Intrusion Prevention: Balanced Security and Connectivity.
Click the logging icon next to Default Action and specify log at end of connection.
Click OK.
In the Name field, enter Restrict AIM Access.
In the Action field, choose Block.
Click the Applications tab. In the Available Applications search field, enter AOL. Choose the
AOL Instant Messenger option in the list of applications. Click Add to Rule.
Click the Logging tab and set the rule to log at the beginning of the connection.
Click Add.
Enable an HTTP block response page when the connection is blocked:
Click the HTTP Responses tab. In the Block Response Page field, choose System-provided
from the drop-down menu.
16
Click Save and Apply. Click Apply All to confirm the apply operation. You can click the task
status option to view the progress of the policy apply process. Once it is complete, you can close
the task status window and click the OK button to return to the policy edit page.
To verify your results, do the following:
Test this configuration by opening the Pidgin Internet Messenger application on Bleda. You can
access it by starting the GUI with the startx command. Note that the startx command must be
run from the VM console of Bleda. You may receive a warning box, because you are running the
user interface as root. Simply click Continue to load the GUI.
When the GUI opens, navigate to Applications > Internet > Pidgin Internet Messenger.
A preconfigured account is already set up. You can enter any password.
The rule will not allow the authentication to take place.
Inspect the Connection Events and verify that the connection was blocked.
On the host Bledas desktop, open the Firefox browser and try to navigate to www.aim.com to
use the web aim chat client.
This action should generate the default system-provided block response page and prevent access
to the site.
Lab 6-3: URL Filtering

In this exercise, you will configure your policy to restrict users from browsing to dating sites.
The lab environment may prevent this lab from working properly due to the presence of a caching proxy
upstream from the lab. If the lab is being performed at a customer-provided training facility or a third-party
training facility, this caveat may not apply. In either case, you should perform the lab so that you can see the
steps required for implementing URL filtering.
Click the Rules tab in the policy edit page to return to the rule list.
In the Name field, enter Restrict Dating. Set the Action to Block.
Click the URLs tab.
Type dating in the search field of the Categories and URLs column. Choose Dating from this
list.
In the Reputations column, choose a reputation value of Any so that all dating sites are included.
Click the Logging tab and set the rule to log at the beginning of the connection.
Click Add.
17
Test this configuration by using the web browser on Bledas desktop to try to access the site
match.com. This attempt to navigate to match.com should trigger the block response page.
Inspect the Connection Events and verify that the connections were blocked.
Lab 6-4: Including an IPS Policy in Access Control Rules

In this exercise, you will add an IPS policy to your DMZ web access rule. With this protection in place,
traffic that is allowed to enter the DMZ over HTTP or HTTTPS will also be processed by the IPS. This
protects the servers in the DMZ by alerting or blocking traffic that is allowed to enter if the IPS detects
suspicious or anomalous activity.
Edit the DMZ Web Access rule by clicking the edit button associated with the rule.
Click the Inspection tab and set it to inspect this traffic with the intrusion policy called Security
Over Connectivity.
Click the Logging tab and set the rule to log at the end of the connection.
Click Save.
18

In this lab, you will restrict discovery to cover only networks of interest. You will also enable the Capture
Banners option and decrease the update interval value in the network discovery policy. Keep in mind that
reducing the update interval provides more timely information but also produces more events. On busy
networks, this can cause the discovery event tables to fill more quickly.
Lab 7-1: Tuning the Network Discovery Detection Policy

Edit the network discovery policy as follows:
Navigate to Policies and click Network Discovery.
Delete the default discovery rule.
Click Add Rule.
Check the Users check box.
At the base of the Networks column, add the following network addresses:
10.0.0.0/8
172.0.0.0/8
192.0.0.0/8
Click Save.
Click the Advanced tab of the Network Discovery policy.
Click the Edit icon that is associated with General Settings. Enable Capture Banners and
change the Update Interval value to 1800 seconds.
Click Apply.
Lab 7-2: Viewing FireSIGHT Data

You will now view data that your appliance has collected.
Navigate to Analysis and then Hosts, and choose Network Map. Notice that you have the
ability to detect and view IPv4, IPv6, and MAC hosts.
In the Search window in the upper left, type the IP address 192.168.133.0/24.
Click the Plus symbol button that is associated with 192. Drill down to view hosts in the
192.168.133 network.
Click the link that is associated with the 192.168.133.50 host. You will see the host profile page.
Check the profile and view the protocols that were detected by the scans that you issued.
Click the link that is associated with other hosts in the general network and view their host
profiles.
19
Lab 7-3: User Discovery

In this lab, you will confirm that the LDAP settings for the object used to communicate with an external
LDAP server for user meta-information are correct.
Navigate to Policies and click Users.
Click the Edit icon (pencil) to edit the Bleda_LDAP object.
Review the existing LDAP object properties:
Name: Bleda_LDAP
Hostname/IP Address: 192.168.10.90
Port: 389
Base DN: ou = people, dc = sfsnort, dc = com
Username: cn = admin, dc = sfsnort, dc = com
Password: password
Confirm Password: password
Click the Test button at the bottom of the page to initiate a test connection to the LDAP server.
If it returns a message of success, your LDAP connection is configured correctly.
Click Cancel to exit the LDAP connection configuration page.
Test the user discovery configuration as follows:
Create an SSH connection to Bleda and enter the following command to create a Telnet
connection to the POP3 port:
telnet 192.168.133.60 110
When you receive the OK prompt, type the following to test with POP3:
user student01
At the next OK prompt, type the following:

pass password
When you receive the next OK prompt, type the following:

Quit
For an IMAP login, perform the following:

telnet 192.168.133.60 143
At the prompt, type one of the following:

The dot at the beginning of the command is required.
. login student02 password
At the next prompt, type the following:

. logout
20
Navigate to Analysis and then Users, and choose User Activity. Note the user events that have
been recorded.
Navigate to Analysis and then Users, and choose Users to see the list of users. Note the LDAP
data that has been added (first name, last name, department, email, and phone).
Lab 7-4: Host Attributes

In this lab, you will assign host attributes to hosts based on IP address, by using the list type attribute.
Navigate to Analysis > Hosts > Host Attributes.
Click the Host Attribute Management button in the upper-right portion of the page.
Click the Create Attribute button.
Enter Networks in the Name field.
Select List from the Type drop-down list.
Click the Add Value button and enter General in the Name field.
Click the Add Value button again and enter DMZ in the Name field.
From the Value drop-down list, select General.
In the IP Address field, enter 192.168.133.0.
In the Netmask field, enter 24.
From the Value drop-down list, select DMZ.
In the IP Address field, enter 192.168.10.0.
In the Netmask field, enter 24.
Click Save to save and exit the page.
To view how the attribute was applied to a host, navigate to Analysis > Hosts > Network Map.
In the filter field, enter 192.168.133.0/24.
Click the IP address that matches your filter, and open the host profiles of each of the hosts in
that network.
Go to the Attributes section of each profile and confirm that the networks attribute is set to
General.
Click in the filter field of the network map and enter 192.168.10.0/24.
21
Go to the Attributes section of the profile for each host in this network, and confirm that the
Networks attribute is set to DMZ.
Run a search for hosts with a specific attribute by navigating to Analysis > Hosts > Host
Attributes.
Click the Edit Search option in the upper-left portion of the page.
Look for the attribute that you created called Networks and enter DMZ in that field.
Click the Search button.
The Attributes list page shows you all the hosts with the attribute value that you searched on.
Click the drill-down button (the blue arrow at the beginning of the line) for the host
192.168.10.90 (bleda). This will open the host profile page for the host that you selected.
22

In this lab, you will create a file policy to address the following:
You are concerned about the possibility of introducing malware into your network environment, but you
do not want to hinder end-user productivity.
Your organization is concerned about lawsuits that could result from users downloading music files.
Because EXE and PDF files are common file types that could be infected with malware, your policy will
include a rule to do malware cloud lookups on these file types for all protocols. This way, you do not
prevent legitimate files from being transferred among your users, but you will be notified if malware is
detected.
Second, your policy will include a rule to block MP3 files on all protocols.
Lab 8: Creating a File Policy

Navigate to the file policy list page by choosing Files from the Policies menu.
Create a policy by clicking New File Policy. Name it MyFilePolicy and click Save to continue.
Click Add File Rule to create the first rule, and set the following parameters:
Set the Protocol to Any.
Set the Direction of Transfer to Any.
Set the Action to Malware Cloud Lookup.
Choose the Executables, PDF files, and Archive options in the File Types Categories
column.
Choose All types in selected categories in the File Types column.
Click Add to add the file types to the Selected File Categories and Types column.
Click Save to create the rule.
Click Add File Rule to create the next rule, and set the following parameters:
Set the Protocol to Any.
Set the Direction of Transfer to Any.
Set the Action to Block Files. Choose the Multimedia option in the File Types Categories
column.
Choose MP3 in the File Types column.
Click Add to add the file type to the Selected File Categories and Types column.
Click Save to create the rule.
Click the Advanced tab and select Inspect Archives.
23
Click Save in the upper-right portion of the screen to save the policy and return to the file policy
list page.
With the file policy created, you must now add it to an access control policy rule to implement it, as
follows:
Navigate to the Access Control Policy page by choosing Policies from the main menu, followed
by Access Control.
Click the Edit button for the Training Policy.
Edit the rule titled DMZ Web Access.
Click the Inspection tab.
From the File Policy drop-down menu, choose the MyFilePolicy policy that you created earlier.
Click the Logging tab and choose Log at End of Connection. Also, make sure that the Log
Files option is selected.
Click Save to save the edited rule.
Click the Save and Apply buttons in the upper-right portion of the page to apply the policy to
your managed device.
When the policy application is complete, log in to Attila. You can access the Attila virtual
machine by opening the PuTTY application on your desktop and selecting Attila from the list of
saved sessions. The username is root and the password is password.
Run the following commands from Attila:
wget
wget
wget
wget
wget
bleda/scanner.exe
bleda/SuperScan4.exe
bleda/report.pdf
bleda/harmless.zip
bleda/guitar_jam.mp3
Did all of your files download correctly?

Navigate to the file event view by selecting Analysis from the main menu, followed by Files.
Choose Files Events from the submenu.
Observe the file events that were created by the policy that you implemented.
Choose Malware Events from the Analysis > Files menu to navigate to the malware event view
to see if you logged any malware events.
Did you receive malware events?
24

In this lab, you will create an intrusion policy and edit the policy to include FireSIGHT recommendations.
Lab 10-1: Creating an Intrusion Policy

Navigate to Policies and then Intrusion, and click Intrusion Policy.
Click the Create Policy button.
In the Name field, enter Training Policy.
In the Base Policy field, choose Security Over Connectivity.
Click the Create and Edit Policy button.
Lab 10-2: Enabling Include FireSIGHT Recommendations

After creating the policy, you will be in the intrusion policy edit page. From here, you can enable
FireSIGHT rule recommendations.
Click the FireSIGHT Recommendations option in the left panel of the page.
Expand the Advanced Settings section of the page by clicking the plus symbol in front of the
advanced settings option.
In the Networks field, enter the IP address block of your lab networks: 192.0.0.0/8.
Make sure that the Accept Recommendations to Disabled Rules check box is selected.
Click the Generate Recommendations button. The system will inform you when the
recommendation generation process has finished with a message box. Acknowledge the message
box by clicking the OK button.
Click the Policy Information option in the upper portion of the left panel, and then click
Commit Changes. If you are prompted to enter a comment, you can choose whether to do so. In
a default installation, comments are optional. Note that comments are displayed in the audit log.
Lab 10-3: Implementing FireSIGHT Recommendations

Next, you will implement the FireSIGHT recommendations that you just generated in the intrusion policy,
and review the changes.
Open the IPS policy that you just created, called Training Policy.
Click the FireSIGHT Recommendations option in the left panel.
Click the View button in the upper-right portion of the screen for the rules that are set to generate
events.
25
Confirm that the FireSIGHT Recommendations column displays icons for the rules that are set to
generate events.
Click the Rule Configuration option in the Rules column. When the section opens, expand the
Recommendation selection and choose Drop and Generate Events to see the recommendations
for dropping and generating events. Select Disabled to see the recommendations for disabling
rules. Using this technique, you can easily review the rule recommendations.
Click the FireSIGHT Recommendations option in the left panel to return to the
recommendations page.
Click Use Recommendations.
Expand the Policy Layers and examine the newly created FireSIGHT Recommendations
layer.
Click Policy Information and commit the changes.
Lab 10-4: Applying Your Policy and Variable Set and Test
In this exercise, you will implement the IPS policy that you created in an access control policy rule.
Use SSH to connect to Attila, and run the ./ips_test.pl script. Make note of the time you
ran the script, because at the end of the lab you will compare the number of events generated
when you run the script now and when you run it again later.
Return to the FireSIGHT interface and navigate to Policies, followed by Access Control.
Edit the Training Policy access control policy.
In the access control policy, edit the DMZ Web Access rule.
Click the Inspection tab and change the intrusion policy to Training Policy. Also, change the
variable set to SFSnort_Set.
Click the Save button to save the changes you made to the rule.
Change the Default Action to Block All Traffic and set the default action logging to Log at
Beginning of Connection.
Click the Save and Apply button to apply the changes you made to the access control policy.
When the policy apply process has finished, go back to the SSH session with Attila and run the
./ips_test.pl script again. Make note of the time you ran the script.
Navigate to Analysis > Intrusions > Events.
Click the time range link in the upper-right portion of the page and adjust the time so that you
see only the results from the first run of the attack script in this lab. You can explicitly state the
start and end times for viewing events in the window that opens.
Click the Apply button after adjusting the time range, and note the number of events that are
displayed in the event table.
26
Click the time range link again and adjust the time range to the time range when you ran the
attack script the second time.
Do you see more events, or fewer events?
What is the reason for the results that you see?
27

In this lab, you will create a Network Analysis Policy and tune the HTTP preprocessor.
Lab 11-1: Tuning Your HTTP_Inspect Preprocessor

Navigate to the access control policy page by selecting Policies from the main menu, followed
by Access Control.
Click the Edit button for the Training Policy access control policy.
Click the Advanced tab.
Click the Edit button for the Network Analysis and Intrusion Policies section.
In the box that is displayed, click the Network Analysis Policy List option. This will open a
new tab in your browser that displays the list of existing network analysis policies.
Click the Create Policy button to create a new Network Analysis Policy. Name the policy
Training Analysis Policy, make sure that Inline Mode is enabled, and change the base policy to
Security Over Connectivity. Click Create and Edit Policy after making these changes.
Click the HTTP Configuration option in the panel on the left.
In the Targets section, click the Plus symbol button next to the Servers option to add a new
network. In the Add Target dialog box, enter 192.168.10.90. Click OK.
Under the Configuration section, set the Profile field radio button to Apache.
Expand the Policy Layers option in the left side panel by clicking the plus symbol in front of it,
and select the My Changes layer.
In the My Changes layer configuration, scroll to the bottom and enable the Rate-Based Attack
Prevention preprocessor. Then click the Edit button to enter the properties page of the
preprocessor.
Click the Add button associated with the Control Simultaneous Connections section of the
page, and set it to track by destination. Set the network to 192.168.10.0/24, set connections to 3,
and set the timeout to 30 seconds. Note that these are extremely low values. They will be used to
ensure that the preprocessor generates alerts. Click OK when the configuration is complete.
Select Policy Information from the left side panel and commit your changes.
When you return to the network analysis policy list page, navigate to Policies > Intrusion >
Intrusion Policy and click the edit button for the Training Policy.
Click the Rules option in the left side panel.
In the Rules column, select the Preprocessors option.
Click the HTTP Configuration selection to filter on the HTTP preprocessor rules.
28
Check the check box next to GID in the heading of the rule list. This option will select all HTTP
Configuration rules. Click Rule State and choose Generate Events to enable all of the rules that
are associated with HTTP Configuration.
Click the Advanced Settings option in the left side panel and disable Global Rule
Thresholding.
Click Policy Information in the left side panel and commit your changes to the IPS policy.
When you return to the IPS policy list page, close the browser tab that the list page is in. This
should return you to the browser tab in which you were editing the access control policy.
In the access control policy page, the Network Analysis and Intrusion Policies configuration box
is still open. Click the Default Network Analysis Policy drop-down list and select Training
Analysis Policy.
Click OK to accept the changes.
Click the Rules tab to return to the access control policy rule list.
Change the default action to Training Policy and change the default action logging selection to
Log at End of Connection only.
Save and apply the access control policy.
Your access control policy preprocessor settings are now configured and are being used as the default
network analysis policy.
Lab 11-2: Testing the Network Analysis Policy Settings

Open an SSH session to Attila.
Run the ./ips_test.pl script and note the time that you run the script so that you can
compare the events produced by this run with previous runs of the script.
When the attack script finishes, return to the FireSIGHT console and navigate to Analysis >
Intrusions > Events. Adjust the time range to display events before the last run of the script and
note the types of events being detected.
Adjust the time range to display the events from when you last ran the script.
Is there a difference in the types of events you see? If so, what is the difference?
Return to the SSH session on Attila.
From Attila, FTP to Bleda with the following command:
ftp bleda
When you are prompted for the username, press [Ctrl] + c to exit.
Repeat the previous two steps five times.
29
In the FireSIGHT console, refresh the page to show the most recent events. You should see an
event with a GID of 135 and a SID of 2. These events were generated by the rate-based
preprocessor that you enabled in the network analysis policy.
30

In this lab, you will perform analysis, using the events on your system.
Lab 12-1: Analyzing Events

First, choose an event for analysis.
Navigate to Analysis and then Intrusion, and click Events. This setting will present the default
workflow Events by Priority and Classification. Click the Events Time Setting link in the upper
right and choose the preset value 1 week. Click Apply.
What is the most important event? There are several high-priority events, but without context,
you may have difficulty choosing.
Click Switch Workflow to change the workflow to Impact and Priority. There should be
several high-priority alerts. The impact flags are integral to deciding which events have the
chance of being successful events. An impact flag of 1 indicates that you are vulnerable to the
threat, and an impact flag of 2 indicates that you are potentially vulnerable. Examine the event
OS-WINDOWS Microsoft WINS service oversize payload exploit attempt (sid:18950). Is this
event worthy of further analysis?
Right-click this event and choose Rule Documentation. Which operating systems are impacted
by this threat?
For a different perspective on the event, right-click the event again and choose Open in Context
Explorer. Context Explorer will open in a separate tab. In the time settings in the upper right,
choose 1 week and click Reload. The Context Explorer allows you to see a graphical
representation of when the event occurred, the operating systems that were involved, application
protocol, and the IP addresses that were used.
Which system has issued the most events? Which systems have been targeted? Click within the
Network Information, Operating Systems pie chart and choose Drill into Analysis. For
purposes of this exercise, consider the 192.1.0.0/16 network as part of your environment.
Return to the Impact and Priority analysis view. Click the down arrow to the left of the event,
which takes you to the next step of the workflow. This step is the drill-down action to view the
source and destination IPs. What are the sources and destinations?
To see more information about the events, click View All at the bottom of the screen. This action
will take you to the Table View of Events and allow you to see specifically when these events
occurred.
Which system was the first to be targeted? Right-click the source host and choose View Host
Profile. What is the operating system of the host? Has this system been the source of other
events? Click the Intrusion Events link in the host profile.
Return to the Impact and Priority workflow. Right-click the Destination IP of the first event
and choose View Host Profile. Has this host been the target of other events?
31
Return to the analysis workflow. Click the down arrow to the left of the first event. Examine the
packet information in your console. Click the link at the bottom of the Download All Packets
page. Using Wireshark, review the packets to see the data from the event.
Was this threat real?
Lab 12-2: Tuning an Event

In this lab, you will use tools that are discussed in this lesson to tune an event. In a previous lesson, you
enabled the alerts for the HTTP configuration preprocessor. While examining intrusion events, you notice a
large number of events (119:15) HI CLIENT Oversize DIR triggering many times. Investigate the event and
then tune the system to suppress the event that is going to a specific system. For purposes of this exercise,
host 10.1.1.2 is a web application server that manages long URI requests as part of an in-house application.
Navigate to Analysis and then Intrusion, and click Events.
Find the (119:15) HI CLIENT Oversize DIR. Click the down arrow to the left of the event to go
to the Drill Down of Source and Destination IPs view.
Right-click the event message and click Rule Documentation. The event is triggered when a
web request containing many characters is detected. In the HTTP Configuration of the network
analysis policy, the value Oversize Dir Length is set to 500 bytes.
What is the target of the event? The target should be 10.1.1.2.
Click the Packets link. In order to suppress future events of this type, expand the Actions field
by clicking Actions. To suppress the rule in all locally created intrusion policies, click the
triangular icon next to Set Suppression Options. Choose the Destination radio button and type
the destination IP address 10.1.1.2.
Click Save Suppression.
In order for the suppression to take effect, the IPS policy must be reapplied. You will do this
after putting the events in the Reviewed status.
One way to remove the events without deleting them, if you think they might be interesting to
look at again in the future, is to put them into the Reviewed status. Click Review All at the
bottom of the packet view page. This setting will remove all of the events you were processing
and put them into a reviewed state. While they are in this state, they are removed from the
regular event views, but they are not removed from the database. You can navigate to Analysis >
Intrusions > Reviewed Events to see them. From here, you can unreview them, which puts
them back into the standard view, or you can delete them if they are no longer interesting to you.
Navigate to Policies and then Intrusion, and click Intrusion Policy.
Reapply the Training Policy.
Lab 12-3: Using Context Explorer

Using the examples in the Context Explorer section of this lesson, navigate to the Context
Explorer and use it to view the data that is presented in each section. Then try the following:
Navigate to the Intrusion Information section.
32
Find the Intrusion Events by Priority graphic.

Click the wedge that represents High Priority events.
Click the Add Filter option in the context menu.
To see if any of the hosts in the 192.1.0.0/16 network were involved in any high-priority events,
click the plus sign icon (+) in the Filters field.
In the Add Filter dialog box, choose IP Address from the Data Type field.
In the Filter field, enter the IP address 192.1.0.0/16.
Click OK.
Click the Apply Filters button and view the result.
Were any 192.1.0.0/16 hosts involved in high-priority events?
33
Lesson 13: Lab Exercises

In this lab, you will create a report that shows different trends over different periods for connection events.
Lab 13: Comparing Trends

Navigate to Overview and click Reporting. Then click the Report Templates tab and the
Create Report Template button.
In the Report Title field, enter Connection Event Comparison for your report.
Click the icon that represents Add Line Chart. This action will add a line chart report section.
In the Table field, choose Connection Events from the drop-down menu.
In the Y-Axis field, choose Unique Initiator IPs from the drop-down menu.
Click the plus sign icon (+) in the report section header to make a copy of it.
Insert names for both report sections. Click the New Data Section 1 link and enter Connection
Events 1 for the section title. Perform the same action for New Data Section 1 (copy) link. Enter
Connection Events 2 for this section title.
For both sections, deselect the Inherit Time Window option and set the Time Window to the
Last Hour for Connection Events 1, and then the Last Day for Connection Events 2.
Click Generate to generate your report and inspect the results.
34

In this lab, you will create correlation policies with rules that trigger on specific conditions that are related
to data gathered from connection events. Your policies will implement correlation rules, correlation
whitelists, and traffic profiles.
Lab 14-1: Creating a Correlation Policy Based on Connection

Data
You will begin by creating an alert that will be used as a response in a correlation policy.
Navigate to Policies, followed by Actions, and click Alerts.
Click the Create Alert button and choose Create Syslog Alert.
Enter the following information in the Create Syslog Alert Configuration dialog box:
Name: Correlation Alert
Host: 192.168.111.99
Facility: SYSLOG
Severity: INFO
Tag: CorrelationAlert
Click Save.
Next, you will configure a correlation rule that triggers on the following conditions:
A connection event occurs.
The application protocol is HTTP.
The responder is in the DMZ IP address range: 192.168.10.0/24.
Responder bytes are greater than or equal to 10,000,000. (When you enter this value, do not enter the
commas.)
Navigate to Policies and click Correlation.

Click the Rule Management tab, and click Create Rule.
In the Rule Name field, enter HTTP high server-side data.
In the Select the Type of Event for This Rule section, choose A Connection Event Occurs from
the drop-down menu.
In the drop-down menu that is associated with the first condition, choose Responder IP Is In
and then enter 192.168.10.0/24.
Click the Add Condition button to add a second condition.
Choose AND from the drop-down list in front of your conditions.
35
In the drop-down list of your new condition, choose Application Protocol Is HTTP.
Add a third condition. Choose Responder Bytes Are Greater Than or Equal to and enter
10000000.
Click Save.
Now that you have a correlation rule, you will create a correlation policy and apply the rule to this policy.
Click the Policy Management tab.
Click Create Policy.
In the Policy Name field, enter HTTP high server-side data.
Click the Add Rules button and choose HTTP high server-side data. Click Add.
Click the Responses icon and move the Correlation Alert response alert to the Assigned
Responses section. You can do this by selecting it in the Unassigned Responses section and
clicking the upward-pointing arrow to move it to the Assigned Responses section. Click Update.
Save the policy and click the activate slider that is associated with the new correlation policy to
an enabled state.
You will now test the correlation policy and rule, and verify that the correct alert is being triggered.
Create an SSH connection to the host Attila. From Attila, issue the following command:
wget bleda/snortrules-snapshot-CURRENT.tar.gz
Once the file has transferred, check to see if you received a correlation event. To view this event,
navigate to Analysis, then Correlation, and click Correlation Events. Notice the rule that
triggered the correlation event.
Verify that the syslog alert was triggered with the following command on the host LAMP:
tail -f /var/log/messages
Verify that the correlation policy triggered a correlation event by navigating to Analysis >
Correlation > Correlation Events.
Lab 14-2: Whitelists

In this lab, you will configure a whitelist, apply that list to a correlation policy, and trigger and view
whitelist events.
Navigate to Policies and click Correlation.
Click the White List tab. Click the New White List button.
Use the General Zone of your network infrastructure as the survey network. Enter 192.168.133.0
in the IP Address field. Enter 24 in the Netmask field.
36
Click OK.
In the Name field, enter Correlation White List.
For the Linux 2.6 Operating System, ensure that SSH is not in the Allowed Application
Protocols list. If it is, use the Delete button to remove it.
If the SSH service was already detected on Attila prior to this lab, you may not see the whitelist event. You
can navigate to the Attila host profile page and delete its SSH service entry and try the lab again if you did
not see the alert the first time.
Click Save White List.

Create a correlation policy with the newly created whitelist as the rule for the policy.
Click the Policy Management tab and click the Create Policy button.
Name the policy White List Policy.
Click Add Rule. Choose the Correlation White List rule.
Click Add.
Click Save.
Activate the policy.
To generate whitelist events, create an SSH connection to Attila from LAMP by using the
following command:
ssh root@192.168.133.50
View the whitelist events that are produced. Navigate to Analysis and then Correlation, and
click White List Events.
Lab 14-3: Working with Connection Data and Traffic Profiles

This lab is designed to create a traffic profile of the DMZ network zone and build a correlation policy based
on connections that are triggered if the profile exceeds one standard deviation. You will run a script to
generate traffic to trigger your rule.
Navigate to Policies and click the Correlation tab.
Click the Traffic Profiles tab. Click New Profile.
In the Profile Name field, enter DMZ Traffic Profile.
In the drop-down menu in the Profile Conditions section, choose Initiator/Responder IP Is In
and enter 192.168.10.0/24. This setting will profile all activity in the DMZ network zone.
In the Profile Options section, set the profiling time window to 1 hour.
Click Save and Activate.
37
Now you will build a correlation policy rule based on connections that trigger if the profile exceeds one
standard deviation.
Click the Rule Management tab. You will be creating a correlation policy rule that alerts if the
total bytes for the network exceed one standard deviation of the profile.
Click Create Rule.
In the Rule Name field, enter Traffic Profile Total Bytes Exceeded.
In the Select the Type of Event for This Rule section, choose A Traffic Profile Changes and the
profile DMZ Traffic Profile from the drop-down menu.
In the drop-down menu that is associated with the condition, choose Total Bytes Are Greater
Than and enter 1 standard deviation.
Click Save.
Click the Policy Management tab and select Create Policy.
In the Name field, enter DMZ Traffic Profile. Add the traffic profile rule to the correlation
policy.
Save the policy and then click the slider to activate it.
Because you had not previously constructed a baseline, there will be nothing to trigger this rule. To observe
the baseline being recorded, you can generate network traffic by following the next steps.
Use Attila to simulate network activity for the traffic profile. From Attila, you can issue the
following command to keep running an NMap scan of the DMZ:
while true; do nmap -sT -p 1-1024 192.168.10.0/24;
sleep 30; done
You can press Ctrl-C to break out when you have completed the lab.
These steps require the system to run for one hour before you receive results. You will need to revisit this
lab at a later point in the class to make sure that the profile was created.
38

In this lab, you will write several basic rules to test the functionality of IPS rules and understand how they
are applied. You can use the rule-builder user interface to build the rules for this lab, or you can enter them
in a text file and import the file into the Defense Center. Use the IPS events table view to verify whether
your rule triggers properly.
To test your rules, you can use the UDP flooder tool in the class files folder on your desktop. Enter the
target IP and port number, and then enter the number of packets that you want to deliver. You will not need
to enter hundreds of packets; you will know if your rule is working with just a few packets. Finally, you can
use the text field to enter the strings to match with your rule. Be advised that the last byte of the payload will
be replaced with a nonprintable character. To ensure that your payload is delivered as expected, you should
enter the text string that you want to match, and follow it with several space characters.
Lab 15: Writing Custom Rules
Write a rule that constrains the content match to a specific offset and depth. Your first name might be a
good candidate for the text string to match in the rule. Move around the contents of the payload. See if
you continue to receive alerts on your rule. Once the rule is created, enable it in the Training Policy and
then reapply the policy prior to testing.
Write a rule with a second content match. Your last name might be a good string to use. Constrain this
match to be a distance of 2 from the previous match. Also, use the Within parameter to keep the search
from going beyond the length of the second string. Move around the contents of the payload. See if you
continue to receive alerts on your rule. Once the rule is created, enable it in the Training Policy and then
reapply the policy prior to testing.
39
40

Ssfips20 LG PDF

Uploaded by

Document Information

Original Description:

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

Ssfips20 LG PDF

Uploaded by

Copyright:

Available Formats

SSFIPS

Part Number: 97-xxxx-01

Asia Pacific Headquarters

2015 Cisco Systems, Inc.

Securing Cisco Networks with FireSIGHT Intrusion Prevention System (SSFIPS)

Securing Cisco Networks with FireSIGHT Intrusion Prevention System (SSFIPS)

2015 Cisco Systems, Inc.

2015 Cisco Systems, Inc.

Securing Cisco Networks with FireSIGHT Intrusion Prevention System (SSFIPS)

2015 Cisco and/or its affiliates. All rights reserved.

Using the Virtual Network Infrastructure

Right-clicking the previously mentioned tab brings up the context menu.

Securing Cisco Networks with FireSIGHT Intrusion Prevention System (SSFIPS)

2015 Cisco Systems, Inc.

Accessing the Virtual Machines

For all of the Linux-based machines:

For all of the FireSIGHT appliances:

Shutting Down the Virtual Machines

shutdown -h now (halts the virtual machine)

shutdown -r now (reboots the virtual machine)

Additional Lab Usage Tips

You will be able to open multiple PuTTY terminal sessions.

2015 Cisco Systems, Inc.

Securing Cisco Networks with FireSIGHT Intrusion Prevention System (SSFIPS)

Initializing the Lab Environment

Securing Cisco Networks with FireSIGHT Intrusion Prevention System (SSFIPS)

2015 Cisco Systems, Inc.

Lesson 1 Lab Exercises

Lab 1-1: Verifying the Product Licenses

Lab 1-2: Testing the Environment by Running Attack PCAPs

When you are prompted, press Enter to continue.

Press 1 to select the inline output method.

Press 1 to accept your entry.

2015 Cisco Systems, Inc.

Securing Cisco Networks with FireSIGHT Intrusion Prevention System (SSFIPS)

Lab 1-3: Viewing Events

Securing Cisco Networks with FireSIGHT Intrusion Prevention System (SSFIPS)

2015 Cisco Systems, Inc.

Lesson 3 Lab Exercises

2015 Cisco Systems, Inc.

Securing Cisco Networks with FireSIGHT Intrusion Prevention System (SSFIPS)

Lesson 4 Lab Exercises

Lab 4-1: Creating User Accounts and Configuring UI Timeout

Lab 4-2: Testing Exempt vs. Nonexempt Users

Securing Cisco Networks with FireSIGHT Intrusion Prevention System (SSFIPS)

2015 Cisco Systems, Inc.

Lab 4-3: Escalating Permissions

2015 Cisco Systems, Inc.

Securing Cisco Networks with FireSIGHT Intrusion Prevention System (SSFIPS)

Lab 4-4: Working with an External User Account

Authentication Method: LDAP

Server Type: OpenLDAP

Hostname/IP Address: 192.168.10.90

Base DN: ou = people, dc = sfsnort, dc = com

Username: cn = admin, dc = sfsnort, dc = com

Confirm Password: password

UI Access Attribute: uid

Group Controlled Access Roles (expand arrow):

cn = admingroup, ou = groups, dc = sfsnort, dc = com

cn = dbgroup, ou = groups, dc = sfsnort, dc = com

cn = ieagroup, ou = groups, dc = sfsnort, dc = com

Group Member Attribute: member