For reporting and correlation of events on a Firepower Management Center (FMC), you may find the following two documents useful:
Working with Reports
Correlation and Compliance Events
If the events are generated by the Advanced Malware Protection (AMP) system, then you can find some directions from this document as well. Depending on your support entitlement level, you may get direct assistance from the Cisco TAC for false positive analysis. In that case, you will be requested to provide the related packets (PCAP files) to the Cisco TAC. This document provides instruction on how to collect them.
As a side note, Cisco also offers advanced services to prepare, manage, detect, and respond to any network threats. The following programs provide that level of in-person assistance:
Managed Security Services
Incident Response Services
Hoping, the above links are helpful.
... View more
Cisco Press has published a step-by-step visual guide to configuring and troubleshooting of the Cisco Firepower Threat Defense (FTD). Each consistently organized chapter on this book contains definitions of keywords, operational flowcharts, architectural diagrams, best practices, configuration steps (with detailed screenshots), verification tools, troubleshooting techniques, and FAQs drawn directly from issues raised by Cisco customers at the Global Technical Assistance Center (TAC). Covering key Firepower materials on the CCNA Security, CCNP Security, and CCIE Security exams, this guide also includes end-of-chapter quizzes to help candidates prepare.
Author: Nazmul Rajib, Publisher: Cisco Press www.ciscopress.com/title/9781587144806
Successful completion of the lab exercises on this book allows a user to accomplish the following:
Understand the operational architecture of the Cisco Firepower NGFW, NGIPS, and AMP
Use command-line tools to identify status, trace packet flows, analyze logs, and debug messages
Deploy FTD on ASA platform and Firepower appliance running FXOS
Configure and troubleshoot Firepower Management Center (FMC)
Plan and deploy FMC and FTD on VMware virtual appliance
Design and implement the Firepower management network on FMC and FTD
Understand and apply Firepower licenses, and register FTD with FMC
Deploy FTD in Routed, Transparent, Inline, Inline Tap, and Passive Modes
Manage traffic flow with detect-only, block, trust, and bypass operations
Implement rate limiting and analyze quality of service (QoS)
Blacklist suspicious IP addresses via Security Intelligence
Block DNS queries to the malicious domains
Filter URLs based on category, risk, and reputation
Discover a network and implement application visibility and control (AVC)
Control file transfers and block malicious files using advanced malware protection (AMP)
Halt cyber attacks using Snort-based intrusion rule
Masquerade an internal host’s original IP address using Network Address Translation (NAT)
Capture traffic and obtain troubleshooting files for advanced analysis
Table of Contents
Chapter 1: Introduction to the Cisco Firepower Technology
The book begins with the history and evolution of the Cisco Firepower technology. This chapter introduces various software components that may be installed on a Firepower system. It also provides a quick overview of the hardware that supports the Cisco Firepower Threat Defense (FTD) technology.
Chapter 2: FTD on ASA 5500-X Series Hardware
This chapter describes the differences between various software images that may be installed on ASA 5500-X Series hardware. It demonstrates the detailed process of reimaging ASA 5500-X Series hardware to the FTD software. In addition, this chapter provides the command-line tools you can use to verify the status of the hardware and software.
Chapter 3: FTD on the Firepower eXtensible Operating System (FXOS)
This chapter describes the architecture, implementation, and installation of FTD on a Firepower security appliance running Firepower eXtensible Operating System (FXOS). It demonstrates several command-line tools you can use to determine the status of various components of the appliance.
Chapter 4: Firepower Management Center (FMC) Hardware
This chapter discusses and compares various hardware platforms for the FMC. It illustrates the complete reimaging process (also known as System Restore) and describes the best practices for doing it. You can also learn many different command-line tools to determine any issues with FMC hardware.
Chapter 5: Firepower System Virtual on VMware
This chapter describes various aspects of the Firepower virtual appliance, such as how to deploy a virtual appliance, how to tune the resources for optimal performance, and how to investigate issues with a new deployment.
Chapter 6: The Firepower Management Network
This chapter describes the best practices for designing and configuring a management network for the Firepower System. It also discusses the tools you can use to verify any communication issues between the management interfaces of the FMC and FTD. Before you begin the registration process, which is described in Chapter 7, you must ensure that the FMC and FTD are successfully connected through your network.
Chapter 7: Firepower Licensing and Registration
This chapter discusses licensing and registration—two important initial tasks in a Firepower system deployment. It describes the capabilities of different Firepower licenses and the steps involved in registering the FMC with a Smart License Server. It also demonstrates the registration process and the tools to investigate any communication issues.
Chapter 8: Firepower Deployment in Routed Mode
This chapter explains Routed Mode, which is a widely deployed firewall mode. It describes the steps involved in configuring the routed interfaces with static IP addresses as well as dynamic IP addresses. In addition, this chapter discusses various command-line tools you can use to determine any potential interface-related issues.
Chapter 9: Firepower Deployment in Transparent Mode
This chapter discusses another mode, Transparent Mode, including how to configure the physical and virtual interfaces, and how to use various command-line tools to investigate any potential configuration issues.
Chapter 10: Capturing Traffic for Advanced Analysis
This chapter describes the processes involved in capturing live traffic on an FTD device by using the system provided capturing tool. To demonstrate the benefit of the tool, this chapter shows how to use various tcpdump options and BPF syntaxes to filter and manage packet capture.
Chapter 11: Blocking Traffic Using Inline Interface Mode
This chapter demonstrates how to configure an FTD device in Inline Mode, how to enable fault tolerance features on an inline set, and how to trace a packet in order to analyze the root cause of a drop. This chapter also describes various command-line tools that you can use to verify the status of an interface, an inline pair, and an inline set.
Chapter 12: Inspecting Traffic Without Blocking It
This chapter explains the configuration and operation of various detection-only modes of an FTD device, such as Passive Mode, Inline Tap Mode, and Inline Mode with the Drop When Inline option disabled. It also provides various command-line tools that you can use to determine the status of interfaces and traffic.
Chapter 13: Handling Encapsulated Traffic
This chapter shows you how to analyze and block traffic that is encapsulated with the GRE protocol. This chapter also demonstrates the steps to bypass an inspection when the traffic is transferred over a tunnel. Besides showing configurations, this chapter also shows various tools to analyze an action applied by the Prefilter and Access Control policy of an FTD device.
Chapter 14: Bypassing Inspection and Trusting Traffic
This chapter discusses the techniques to bypass an inspection. It provides the steps to configure different methods. The chapter also analyzes the flows of bypassed packets to demonstrate how an FTD device acts during different bypassing options. You will learn how to use various debugging tools to determine whether the bypass process is working as designed.
Chapter 15: Rate Limiting Traffic
This chapter goes through the steps to configure QoS policy on an FTD device. It also provides an overview to the common ratelimiting mechanisms and the QoS implementation on an FTD device. This chapter also provides the command-line tools to verify the operation of QoS policy in an FTD device.
Chapter 16: Blacklisting Suspicious Addresses by Using Security Intelligence
This chapter illustrates the detection of a malicious address by using the Security Intelligence feature. It describes how to configure an FTD device to block, monitor, or whitelist an address when there is a match. This chapter also discusses the backend file systems for the Security Intelligence feature. You can apply this knowledge to troubleshoot an issue with Security Intelligence.
Chapter 17: Blocking a Domain Name System (DNS) Query
This chapter demonstrates various techniques to administer DNS queries using a Firepower DNS policy. Besides using traditional access control rules, an FTD device can incorporate the Cisco Intelligence Feed and dynamically blacklist suspicious domains. This chapter shows various ways to configure and deploy a DNS policy. This chapter also demonstrates several command-line tools you can run to verify, analyze, and troubleshoot issues with DNS policy.
Chapter 18: Filtering URLs Based on Category, Risk, and Reputation
This chapter describes techniques to filter traffic based on the category and reputation of a URL. It illustrates how a Firepower system performs a URL lookup and how an FTD device takes action based on the query result. This chapter explains the connection to a URL through debugging messages, which is critical for troubleshooting.
Chapter 19: Discovering Network Applications and Controlling Application Traffic
This chapter shows how a Firepower system can make you aware of the applications running on your network and empowers you to control access to any unwanted applications. It also shows the techniques to verify whether an FTD device can identify an application properly.
Chapter 20: Controlling File Transfer and Blocking the Spread of Malware
Cisco integrates the Advanced Malware Protection (AMP) technology with the Firepower technology. This chapter explains how the technologies work together to help you detect and block the spread of infected files across your network. In this chapter, you will learn the configurations and operations of a file policy on a Firepower system. This chapter also demonstrates various logs and debugging messages, which are useful for determining issues with cloud lookup and file disposition.
Chapter 21: Preventing Cyber Attacks by Blocking Intrusion Attempts
This chapter describes the well-known feature of a Firepower system: the Snort-based next-generation intrusion prevention system (NGIPS). In this chapter, you will learn how to configure an NGIPS, how to apply any associated policies, and how to drill down into intrusion events for advanced analysis. This chapter discusses the Firepower Recommendations feature and demonstrates how the recommended ruleset can reduce system overhead by incorporating discovery data.
Chapter 22: Masquerading the Original IP Address of an Internal Network Host
This chapter discusses various types of NAT on an FTD device. It shows the steps to configure a NAT rule and demonstrates how FTD can leverage NAT technology to masquerade internal IP addresses in a real-world scenario.
... View more
The Snort.org website has been updated to facilitate direct searches of the release snort rules based upon CVE ID or MS Advisory. Data that is returned by this search is independent of the previous rule-docs posting process, and should be available immediately upon SRU release.
You can access it here: https://snort.org/rule_docs.
You can search using a standard format CVE ID (“CVE-2014-1776”, for example) or MS Advisory ID ("MS08-067”, for example).
You can leverage this in lieu of manually checking on a FireSIGHT Management Center (FMC) with updated rules installed.
... View more
Jeffrey, 1. Go to the Downloads Home: https://software.cisco.com/download/navigator.html 2. Navigate to the Products > Security > Firewalls > Firewall Management > FireSIGHT Management Center. 3. Select a model. For example, FireSIGHT Management Center 4000. 4. On the left panel, select the desired product update. The following screenshot, for example, shows various types of products update on the left panel. 5. If you want to download the documentation for any rule updates, select Rules Updates, and hover your mouse over to a rule update release. A Detail popup window appears. You could find the links to the rule update documentation on the popup window. For example, please see the screenshot below: Thanks, Nazmul
... View more
Julien, Please read the following article. This will help you to write the flow matrix or a firewall rule. http://www.cisco.com/c/en/us/support/docs/security/firesight-management-center/118791-technote-firesight-00.html Thanks, Nazmul
... View more
FireAMP Mac Connector v126.96.36.1999 Release Date: March 04, 2015 New FireAMP Mac Connector officially certified on OS X 10.10. Bugfixes / Enhancements Addressed compatibility issue with OS X mail.app where malicious emails are continually downloaded and quarantined by the FireAMP Mac Connector. The Connector now detects and notifies that malicious emails are present but does not quarantine malicious .emlx files created by mail.app. It is left to the administrator to remove the malicious email from the server manually. If mail.app is configured to automatically download attachments and those are determined to be malicious, the Connector will continue to quarantine those attachments. Important: This fix only affects OS X mail.app. Other email applications may behave differently. Resolved a rare issue where the Connector is unable to sync policies for some period of time. Addressed a performance issue where users experienced high CPU usage after waking the computer from sleep or performing a reboot. Fixed high CPU usage issues on OS X 10.10 due to changes in Spotlight. Eliminated a race condition where kernel extensions were unable to successfully unload on shutdown or reboot. Improved Connector validation of user-created exclusions.
... View more
FireAMP Console v5.1.20150304 Release Date: March 04, 2015 New Low Prevalence Executables can be configured to automatically be submitted for File Analysis. Export computer details to a CSV file from the Computers page. Announcements will alert the user of new releases or upcoming system maintenance. Added support for entering a custom Cisco AMP Threat Grid API key. Bugfixes / Enhancements Added the ability to bulk delete computers from the Computers page. Improved bulk move operations on the Computers page. Fixed a bug where incorrect files were being downloaded when the user tried to download PCAP files from File Analysis. File Analysis search is now performed either in the Your Files or Global Files context. Removed the Connector 3.0 ClamAV Compatibility Mode policy setting because FireAMP Windows Connector 3.0 is deprecated and no longer supported, making this option obsolete. FireAMP Console v5.1.20150218 Release Date: February 18, 2015 Bugfixes / Enhancements Upgraded FireAMP Mac Connector protocol version to improve compatibility and reliability. This update is required to ensure future connectivity between the Sourcefire cloud and FireAMP Mac Connectors. All FireAMP Mac Connector policies will be updated to enable this change. Fixed a bug to address compatibility of the OpenIOC format with the FireAMP Endpoint IOC engine. Users experiencing false positives with Endpoint IOCs should re-upload them. FireAMP Console v5.1.20150204 Release Date: February 05, 2015 Bugfixes / Enhancements Fix to allow users to search File Analysis results by SHA-256 or file name.
... View more
This document describes detail steps for reimaging a Sourcefire Series 2 Sensor and DC500. If you need to reimage a Series 3 device, please read this document.
The instruction on this document is applicable to reimage the following hardware platforms to software versions 4.10 or 5.2.
Sensor Models Defense Center Models Software Versions Available for reimage 3D500 3D1000 3D2000 3D2100 3D2500 3D3500 3D4500 3D6500 DC500 4.10 5.2
Before You Begin
Before you begin the reimage process, ensure the following items:
If you plan to reimage a Defense Center (DC) or stand-alone sensor, you should backup your appliance before you proceed. Identify the model number of your sensor and verify that this document is appropriate. Obtain a Sourcefire branded USB keyfob that comes with Sourcefire appliance packaging.
If you can not find the keyfob, please contact Cisco Technical Support Team. A generic USB keyfob is not compatible.
Download the appropriate installation guide and .iso disk image for your desired software version from cisco support site. An .iso file should be copied to a host running an SSH server. The SSH server has to be reachable from the management network of the Sourcefire appliance that will be reimaged. If an SSH server is unavailable, you may use a DC for this process.
Do not plug a KVM switch when you upgrade or reimage a Defense Center or a Sensor. Do not rename an .iso image file. An .iso image is not copied to the Sourcefire USB keyfob. Verify the md5sum of the .iso after you download.
The 3D Sensor and DC Installation Guides has been attached with this document. It provides detail instructions for reimage on chapter 5 "Restoring a 3D Sensor/Defense Center to Factory Defaults". In addition, a detail step-by-step screenshots have been provided below.
The following example uses Version 4.10 when the screenshots were captured. The reimage process is identical for Version 4.10.x and 5.x except for the version numbers displayed on a screen.
Note: For 3D500/1000/2000 sensors press Ctrl + U slowly and repeatedly when the Sourcefire splash screen appears; continue until the splash screen disappears to boot from the USB.
Figure 4: Choose option 0 if you are using a keyboard and monitor.
Figure 8: To select the network device, press spacebar.
Figure 16: SCP protocol is recommended.
Figure 17: It is possible to use a Defense Center as the SCP server for this step.
Note: If you get a connectivity error at this point instead of the expected message, verify your connection to the SSH server.
Figure 21: To select an iso image, press spacebar.
Note: It is required to use the default filename for an iso file, or the file may not be detected at this step.
Figure 23: Support recommends skipping option 3 (Select Patches/SEUs) during this process. Patches and SEUs can be installed after the reimage is complete.
Before a sensor comes back up (while the screen is still blank), power down the sensor. Then, remove the USB drive and power up the appliance.
For 3D500, 3D1000 and 3D2000 sensors, disconnect the power cord from the 3D Sensor, making sure to slide the plastic housing back from the socket. For 3D2100, 3D3500, 3D4500 and 3D6500 sensors, press the power button.
If you do not power down the 3D Sensor in time, you must wait until it finishes booting. Then, for 3D500, 3D1000 and 3D2000 sensors, log in and enter the following command at the CLI, and finally power down the appliance by disconnecting the power cord.
sudo shutdown -h now
For 3D2100/3500/4500 and 3D6500 sensors, wait until the appliance boots from the USB drive, then press the power button.
... View more
Akhtar, This document discusses about software version 4.10.x. Since you have just ordered new products, are you going to use RNA/RUA (on legacy Version 4.10), or the FireSIGHT (on Version 5.2 or 5.3)? The FireSIGHT license on your Defense Center determines how many individual hosts and users you can monitor with the Defense Center and its managed devices, as well as how many users you can use to perform user control. A FireSIGHT license on the DC1500 supports up to 50,000 hosts and users. Because FireSIGHT licensed limits are matched to the hardware capabilities of Defense Centers, we do not recommend exceeding them. Thank you.
... View more
Hi Akhtar, The following document provides a list of ports required by a FireSIGHT System: http://www.cisco.com/c/en/us/support/docs/security/firesight-management-center/118108-technote-firesight-00.html Thank you.
... View more
This error occurs when an OVF image of a Virtual Appliance file is modified upon extraction. This usually occurs when a virtual image is being extracted using WinZip. Steps to deploy an OVF image properly: Verify that you are using the supported platform. Verify that the md5sum of the OVF image matches with the md5sum which is provided on the support site for that particular Virtual Appliance. Create a folder on your local host. Extract the virtual appliance on the created folder. Remove the .mf file from the directory. Import the OVF image now, and deploy it.
... View more
The OVF file of a Virtual Defense Center and managed device fails to be imported on VMware with the following errors: The OVF package is invalid and cannot be deployed. File Sourcefire_Defense_Center_Virtual64_VMware-XXX.ovf fails integrity check and might have been corrupted during transfer. Screenshot of the error message:
... View more
There is one special concern, when running the Qualys Connector via cron, rather than directly. Specifically, the Qualys Connector script has several libraries in a sub-directory, that it requires. When you run it by hand, these sub-directories are relative to the current directory (known as . and is the last entry in the @INC path). When run from cron, however, that is not the current directory.
There is a simple solution, prepend a cd <path to connector> command to the cron entry. For instance, assume:
The Qualys connector is installed in /home/qconn/
There is currently a cron entry that reads:
0 5 * * * /home/qconn/qualys_connector.pl
The cron entry needs to be updated to read:
0 5 * * * cd /home/qconn/; ./qualys_connector.pl
... View more
Running a Qualys Connector manually succeeds, but when I try to automate it using cron, I receive the following error:
Can't locate SFCheckPreReq.pm in @INC (@INC contains: /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.8/i386-linux-thread-multi /usr/lib/perl5/5.8.8 .) at <path to connector>/qualys_connector.pl line 8.
BEGIN failed--compilation aborted at <path to connector>/qualys_connector.pl line 8.
The <path to connector> in the above output is the location where I have installed the connector.
... View more
Bitvise WinSSHD 6.02 or prior version does not support the remote storage feature of the FireSIGHT System. This issue has been reported to Bitvise. Here is the tracking bug: https://fogbugz.bitvise.com/default.asp?15300_7969o8e7
... View more
An intrusion policy of a FireSIGHT System runs in post-ACK mode by default. This means that data in reassembled streams (such as HTTP streams) are not matched against rules until an ACK for the data is received from the server. The server has already seen an HTTP request before the system alerts on it. The rest of the session will be blocked, but the malicious GET has already been processed. To modify this behavior, the Inline Normalization feature needs to be enabled on the intrusion policy, and the options Normalize TCP and Normalize TCP Payload need to be turned on. Please read the following document to learn more about the Post-Acknowledgement and Pre-Acknowledgement Inspection by Inline Normalization preprocessor. http://www.cisco.com/c/en/us/support/docs/security/firesight-management-center/117927-technote-firesight-00.html In addition, if you are using a load balancer as a front end to your servers, your load balancer may be just looking at the first packet of a request and logging it based on that only. However, since Snort uses Protocol Aware Flushing (PAF), it does not alert or drop until it sees all of the packets of an HTTP request. If the load balancer is seeing only the first packet of a multi-packet request of which Snort has not dropped anything because the subsequent packets never made it to Snort, it may log the request inaccurately. Eventually, the sessions will get pruned because they have not seen data, and at that time the event will trigger because Snort will flush the rest of the stream. The event that gets generated will have the timestamp of the original data, not the time that Snort actually generated the event.
... View more
Cause Without the Server Hostname field filled in, a FireSIGHT Management Center (also known as Defense Center) tells the JDBC client that it has an address of localhost, or 127.0.0.1, which causes the connection to fail. Solution Step 1: Log in to your FireSIGHT Management Center where the JDBC is trying to connect to. Step 2: Navigate to System > Local > Configuration. Step 3: When the page loads, select Database on the left pane. Step 4: Ensure that the Server Hostname field is filled out with the Fully Qualified Domain Name, or the IP address of the FireSIGHT Management Center.
... View more
When connecting a JDBC client to a FireSIGHT Management Center, the following error message appears: SEVERE: java.rmi.NoSuchObjectException at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) at java.net.Socket.connect(Socket.java:579) at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:618) at sun.security.ssl.SSLSocketImpl.<init>(SSLSocketImpl.java:407) at sun.security.ssl.SSLSocketFactoryImpl.createSocket(SSLSocketFactoryImpl.java:88) at InstallCert.main(InstallCert.java:81)
... View more
This is a known issue. This issue is fixed on software version 188.8.131.52. Upgrading your 3D System to latest software version will fix this issue. Note: Once the 184.108.40.206 patch is installed, you may still receive the RUA Deserialize error if the Defense Center contains older unified files prior to the 220.127.116.11 patch. Contact Technical Support for assistance in removing the older unified files.
... View more
Estreamer service on 3D System generates the following error messages for user activity data: EventStreamer child(qradar.as.local):ConnectionHandler [ERROR] Failed to deserialize RUA Event 1004:1
... View more
When you deploy a FireSIGHT System (also known as 3D System) with Fiber Network Module and the auto-negotiation option is not properly configured, your end-devices may experience connectivity issues. The reason for this issue is the Auto-Negotiation configuration. If you have misaligned Auto-Negotiation settings, One device will be looking for certain data before bringing the device up, but the other will never send those. Per the IEEE 802.3 Standard, it is not necessary to specify a mode of Auto-Negotiation. Therefore, if one device uses Auto-Negotiation, and the other is not, you will not have link between them. The following table explains the differences that could exist between two fiber devices: Link Negotiation State Link Status Local Device Remote Device Local Device Remote Device Off Off Up Up Off On Up Down On On Up Up On Off Down Up To prevent this from happening, ensure that both of your devices are configured for Auto-Negotiate. A FireSIGHT System does not support disabling of Auto-Negotiation on fiber network modules. It is a best-practice to ensure all of your fiber interfaces are set to Auto-Negotiate, however some devices may allow you to hard-set the Speed/Duplex of the interface.
... View more
If you install a FireSIGHT license on a 3D System running software version 4.10, it may display an Error 500 message, because a FireSIGHT license is incompatible with software version 4.10.x. In order to install a FireSIGHT license, you appliance must be running software version 5.0 or greater. In order to fix this Error 500 message when attempting to create an RNA detection policy, please follow the steps below: Step 1: Log into the web interface of the Defense Center, and navigate to Operations > System Settings > License. Step 2: Look for an unknown license type (FireSIGHT) as the following figure: Step 3: Delete this unknown license type using the trashcan icon labeled Delete User-added image. Step 4: Activate RNA and or RUA feature licenses, Operations > System Settings > License > Add New License, from your product activation keys. Note: If you do not have RNA/RUA activation keys, please contact your Sales Representatives. Step 5: Once activated, you should be able to see a valid license type under the License page as displayed in the figure below. Step 6: You may now create an RNA detection policy from Policy & Response > RNA > Detection Policy > Create Policy page without any error.
... View more
This article describes the basic steps and best practices for creating and configuring an RNA policy in 4.10. Before you can begin to generate RNA events, or gather RNA data, you need to make sure you have done the following: 1) The sensor must be managed by a Defense Center (DC), and the DC must have a valid RNA license. To check if there is a valid RNA license, navigate to Operations > System Settings. On this page, click on License in the menu on the left. This page displays the current licenses on the Defense Center. The following shows a DC with a valid RNA license: In the screenshot above, there is a valid RNA license on the DC with a host limit of 50000. The host limit is the amount of hosts that are allowed to be stored on the DC at one time. If you run out of hosts, the DC will either remove old hosts to allow for new hosts, or keep the current hosts, depending on how you configure the settings. 2) You need to make sure you have an interface set created. To view the interface sets, from the web interface, navigate to Operations > Configuration > Interface Sets. On this page, you can view the configured interface sets, edit them, delete them, or create new ones. If there are no configured interface sets, you will need to create a new one by clicking on the Create Interface Set button, located at the top right of the page. You can use RNA to monitor the traffic that passes through any of the three types of interface sets (Passive, Inline, and Inline with Fail-Open). 3) There needs to be an RNA Detection Engine configured on the sensor(s) that will be used for RNA. To view the available detection engines, from the webUI, navigate to Operations > Configuration > Detection Engines. On this page, you can view the configured detection engines, edit them, delete them, or create new ones. If there are no configured RNA detection engines, you will need to edit an existing one and configure it for RNA, or create a new one by clicking on the Create Detection Engine button, located at the top right of the page. Note: You can use one interface set for multiple detection engines. For example, if you are using one interface set for IPS, you can create a detection engine and use that same interface set for RNA. 4) After you have configured your RNA Detection Engine(s), you will use them in an RNA Detection Policy. To edit/create a Detection Policy from the webUI, navigate to Policy & Response > RNA > Detection Policy. If you do not have an existing Detection Policy, or you want to create a new one, click on the Create Policy button, located at the top right of the page. Detection Policy Settings There are multiple settings in the Detection Policy (shown below): Update Interval The interval at which RNA updates information (such as when a host was last seen, when a service was used, or the number of hits for a service). The default setting is 3600 seconds (1 hour). Note that setting a lower interval for update timeouts provides more accurate information in the host display, but generates more network events. Flow Data Mode Indicates how flow data (including NetFlow data) is collected. You can: Select Enabled to configure your 3D Sensors to transmit individual flows to the Defense Center. Select Summary (the default) to configure your 3D Sensors to transmit flow summaries, which are sets of flow data aggregated over five‑minute intervals. Select Disabled to disable the collection of flow data. Note that disabling or limiting flow data collection can reduce the traffic between your 3D Sensors and your Defense Center as well as reduce the space required to store flow data on the Defense Center, but it can also prevent or limit you from taking advantage of any feature that relies on flow data, such as the Flow Summary dashboard, traffic profiles, compliance rules based on flows or traffic profile changes, and flow trackers in compliance rules. Save Unknown OS Data Select this check box if you want to save data related to unidentified operating systems. This data is saved in packet capture (pcap) format on the appliance should you need to send this information to Sourcefire Support. Save Unknown Service Data Select this check box if you want to save events related to unidentified services. This data is saved in packet capture (pcap) format on the appliance should you need to send this information to Sourcefire Support. Caution: Enabling the previous two options can cause slower performance and higher disk usage on the sensor(s) or the Defense Center. If you are applying your RNA policy to numerous sensors and/or or a broad range of networks, these options should probably not be enabled. Capture Banners Select this check box if you want RNA to store header information from network traffic that advertises service vendors and versions (“banners”). This information can provide additional context to the information gathered by RNA. You can access service banners collected for hosts by accessing service details. Client Application Detection Select this check box if you want RNA to generate events related to client application detection. Note that flows exported by NetFlow‑enabled devices do not contain any information on client applications involved in the monitored session. Capture HTTP URLs Select this check box if you want RNA to capture HTTP URLs and include them in flow events, where applicable. Note that flows exported by NetFlow‑enabled devices do not contain any URL information. Generate Hosts from NetFlow Data Select this check box if you want RNA to add hosts to the network map based on flow data exported by NetFlow‑enabled devices. You cannot select this check box if you have not applied a NetFlow feature license to your Defense Center. Note that there is no operating system information available for hosts added to the network map based on NetFlow data, unless you use the host input feature to manually set the hosts’ operating system identity. Generate Services from NetFlow Data Select this check box if you want RNA to add services to the network map based on flow data exported by NetFlow‑enabled devices. You cannot select this check box if you have not applied a NetFlow feature license to your Defense Center. Note that the Sourcefire 3D System is unable to identify the names, version, and vendors of services running on hosts detected by your NetFlow‑enabled devices, unless you use the host input feature to manually set those values. Combine Flows for Out‑of‑Network Responders Select this check box if: You kept the flow data mode as Summary (that is, your 3D Sensors will transmit aggregated flows instead of individual flows to the Defense Center) You want to combine flow summaries involving external hosts on the sensors, before they transmit the data to the Defense Center Enabling this option treats flow summary data from IP addresses that are not in your list of monitored networks as coming from a single host. Event views, graphs, and reports use external to indicate the hosts outside your monitored network, instead of an individual IP address. Networks to Monitor The next option in the Detection Policy is specifying networks to monitor. To add a network to monitor, click on the Add Network button. A new section will be created where you can specify the IP Address, Netmask, Data Collection, and Reporting Detection Engine. If you know which networks the sensing interfaces on your 3D Sensors are physically connected to, configure the RNA detection policy so that the reporting detection engine for a subnet is the detection engine that uses the interface set monitoring that subnet. The reporting detection engine for a particular network segment is responsible for reporting most of the information about the hosts on that network, for example, the operating systems and services running on the hosts. An example showing the various options is shown below: For the first network, the RNA detection engine will collect host and flow data from the 10.8 subnet. For the second network, the RNA detection engine will collect only host data from the 10.7 subnet. For the third network, the RNA detection engine will exclude data from the host with IP address: 10.7.45.32. Note: Be sure to select a Reporting Detection Engine. It is better to specify a detection engine rather than using Auto-detect if you know what network segment the detection engine is monitoring. Using Auto-detect will only grab a limited amount of information like MACs and hops. Caution: If you delete a detection engine or recreate a detection engine that is used in your policy, make sure you go back into the policy and specify the new detection engine, as deleting a detection engine will cause the Reporting Detection Engine field to be blank, which can cause issues. Ports to Exclude The next option in the Detection Policy is specifying ports to exclude. To add a port to exclude, click on the "Add Port" button. A new section will be created and you can specify the Port(s), Protocol, Source/Destination, IP Address, and Netmask. This configuration will exclude port 80 from IP address 10.8.12.12. Caution: The port exclusion feature only effects data collected by 3D Sensors with RNA. You cannot configure NetFlow‑enabled devices to exclude ports from monitoring. Note: Do not use the port exclusion to exclude all ports for a specific host/network segment. Instead, you should exclude the host/network segment itself using the Exclude Data Collection option in the Networks to Monitor section. Once you have your policy configured, click the Save Policy button if you are creating a new policy, or the Update Policy button if you are editing an existing policy. Once you save the policy, click Apply and select the sensor(s) that this policy should be applied to (the sensor that have the detection engines being used in the policy).
... View more