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
FireAMP Mac Connector v22.214.171.1249 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
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
Introduction The option OS and Server Identity Sources is a mechanism to define the source of the data being fed to the Defense Center via the Host Input API. For example: If you have a custom application which scans hosts on your network independently of the DC and would like for that data to modify the existing host profiles, it will be necessary to add an Identity Source on the DC. This way, your custom application will be able to successfully connect and have its data stream tagged so the source of the data is properly defined in the Host Profile. Steps To Add Custom Identity Source Navigate to Policies > Network Discovery > Advanced. Click on the Pencil Icon next to OS and Server Identity Sources. Click Add Source. In the Type field, select Scanner or Application. In the Timeout field, indicate the duration of time that should elapse between the addition of an identity to the network map by this source and the deletion of that identity. FireSIGHT's default timeout value is 7 days. Save the configuration.
... View more
When writing an Access Control rule, you want to keep it simple. Here are some tips for simplifying an Access Control rule: Use CIDR blocks rather than individual IP addresses whenever possible. Use port ranges rather than individual ports whenever possible. Use security zones whenever possible. Do not overspecify rules. Examples of non specific Access Control Rules: Having many individual IP addresses Using a large list of URLs Having unnecessary rules that could be combined into one with a broader criteria. Important: When creating an Access Control policy, it is important to keep in mind that one Access Control may generate multiple expanded Access Control rules.
... View more
Introduction Virtual Routing and Forwarding (VRF) is a mechanism to segment a single router into multiple virtual routers that do not pass traffic between them. It allows multiple instances of the routing table to co-exist within the same router at the same time. Frequently Asked Questions Question 1: How do Sourcefire appliances work in a VRF deployment? VRF does not require any special support or configuration in Sourcefire products as it is completely transparent to the device monitoring the traffic. The only way this could become an issue is if someone is using a aggregator to combine traffic from multiple different networks into a single interface set or detection engine. In this case, the 3D System is unable to distinguish between two different hosts with the same IP address. Question 2: How is the traffic in a VRF network analyzed? Lets consider a scenario as an example: There are multiple networks with 172.22.x.x. Some networks are in the virtual routing table (in VRF), and some networks are not. If a Sourcefire appliance generates alerts from one of the 172.22.x.x networks, is it possible to determine the correct network of origin from the alert? The handling of this scenario is not specific to the use of VRF. As long as the Sourcefire appliances are configured so that each network is monitored by a unique detection engine, then the name of the detection engine can be used to distinguish between events. However, RNA will not work in this case as the network map does not distinguish hosts by the reporting detection engine. RNA will combine all hosts using the same IP address into a single entry in the network map. Question 3: How are events generated from VRF network traffic identified? When the alert is triggered, the "packet view" of the event will be the same as the other (non-encapsulated, non-VRF) events. However if each network is being monitored by a unique detection engine, the name of the detection engine can be used to distinguish between events.
... View more
Warning: In order to scrub sensitive data from a PCAP, you will need to use an open source application (tcprewrite) that is not included on Sourcefire Appliances. Sourcefire does not officially support this software and cannot provide assistance beyond the content of this article.
Scrub IP Addresses from PCAP Files
Removing sensitive data from PCAP files is a simple process using the tcprewrite tool, which is a part of the tcpdump suite of *nix tools for manipulating libpcap files. Tcprewrite can modify and rewrite packets stored in pcap(3) file format and supports both IPv4 and IPv6.
How is the tcprewrite utility used
You can obfuscate the IP addresses with tcprewrite with the following command:
tcprewrite --pnat=10.0.0.0/8:192.168.1.1/24 -i infile.pcap -o outfile.pcap
The above command would turn any 10.x.x.x addresses into 192.168.1.x addresses.
Before running tcprewrite:
After running tcprewrite:
To randomize the IP address obfuscation in a PCAP file
tcprewrite --seed=423 --infile=input.pcap --outfile=output.pcap
When IP addresses are randomized, it is done in a deterministic manner, based on the seed value you provide, so that sessions between two hosts are maintained. Using different seed values results in different values for the IP addresses for the same input pcap. If you have multiple PCAPs to submit, you should use the same "--seed=" value for each PCAP so that the IP addresses are consistent across PCAPs.
The original file 'input.pcap' remains unchanged, while the output file 'output.pcap' is a copy of the original PCAP with random IP addresses substituted. Output.pcap is the file you should submit to technical support for analysis.
... View more
CVE-2014-0160: Heartbleed Vulnerability Detail information on this exploit is available on the Sourcefire VRT Blog webpage: http://vrt-blog.snort.org/2014/04/heartbleed-for-openvpn.html How to Address This Vulnerability Update the SEU/SRU Make sure you have updated the Sourcefire Rule Update (SRU) or Security Enhancement Update (SEU) to the latest release. Enable Appropriate Snort Rules The Vulnerability Research Team (VRT) created the SIDs 1:30510 through 1:30517 and 1:30520 through 1:30523 to provide detection for this vulnerability. Please note that the VRT always update the ruleset to address latest vulnerabilities and improve performance. Therefore you must update the SRU/SEU version, enable the required rules, and reapply the intrusion policy.
... View more
If a category or classification of an URL requires a review, the following information would be necessary. Once a reclassification is approved, it usually occurs within 24-48 hours from the time of submission. URL that needs to be re-categorized Current categorization for that URL Category that it should belong to Reason for the new categorization If there is a technical issue with URL filtering, a complete troubleshoot file may be necessary for detail investigation. In order to generate a troubleshoot file, please follow the instructions provided in this article.
... View more