Chapter 21
Preventing Cyber Attacks by Blocking Intrusion Attempts

One of the most popular features of Firepower Threat Defense (FTD) is that it can function as an intrusion detection system (IDS) as well as an intrusion prevention system (IPS). FTD uses Snort, an open-source IDS/IPS, to perform deep packet inspection. Snort can detect intrusion attempts and prevent cyber attacks in real time. When an FTD device runs Snort along with many other next-generation security technologies (described in recent chapters), the device turns into a next-generation intrusion prevention system (NGIPS). In this chapter, you will learn how to configure and deploy an intrusion policy on an FTD device.

Figure 21-1 shows a packet analyzed against a Snort ruleset as the last phase of the Firepower engine inspection. However, any bypassed or trusted traffic is not subject to Snort rule inspection.

Network analysis policy: This policy works in conjunction with preprocessor rules to normalize traffic.

Intrusion policy: This policy employs the Snort rules to perform deep packet inspection.

Access control policy: This policy invokes the network analysis policy and intrusion policy for matching and nonmatching traffic.

The following sections describe all the essential components that are part of an intrusion policy deployment.

The implementation of preprocessors on open source Snort and FTD are not exactly the same. The Firepower engine normalizes traffic in various phases as a packet goes through additional advanced security checks.

Figure 21-2 shows the position of preprocessor in the open source Snort architecture. All the preprocessor plugins operate at the same level—after decoding a packet and before the Snort rule inspection.

Figure 21-3 illustrates the multiphase implementation of preprocessors on an FTD device. You can enable any of these preprocessors from one place: the network analysis policy.

A network analysis policy on a Firepower system allows you to enable a certain preprocessor and fine-tune any granular settings within. A preprocessor allows Snort to preprocess, decode, and normalize traffic for advance inspection. If you disable a preprocessor manually but Snort deems the preprocessor necessary, FTD can still engage that particular preprocessor in the backend to protect your network from a potential threat. However, a network analysis policy configuration does not indicate when FTD enables an essential preprocessor automatically. Visually, the preprocessor setting remains disabled on the FMC GUI.

Figure 21-4 shows the network analysis policy editor page, where you can enable and disable a desired preprocessor. Later in this chapter, you will learn how to create and deploy a network analysis policy from scratch.

The Application Layer Preprocessors section of a network analysis policy editor allows you to configure the advanced settings of various protocols traffic, such as DCE/RPC, DNS, FTP and Telnet, HTTP, Sun RPC, SIP, GTP Command Channel, IMAP, POP, SMTP, SSH, and SSL.

The Transport and Network Layer Preprocessors section of a network analysis policy editor offers granular configurable options for checksum verification, inline normalization, IP defragmentation, packet decoding, TCP stream configuration, UDP stream configuration, and so on.

The FMC also provides preprocessors for very specific environments and detection. For example, DNP3 and Modbus preprocessors have been developed for the Supervisory Control and Data Acquisition (SCADA) network environment. Similarly, three additional preprocessors are designed to detect very specific traffic patterns and threats, including Back Orifice, Portscan, and Rate-Based.

Standard text rules: The Cisco Talos security intelligence and research group writes these rules in clear-text format. The Snort detection engine uses them to analyze packets.

Shared object (SO) rules: Talos writes SO rules in the C programming language and compiles them for Snort use. The content of an SO rule is made irretrievable for various reasons, such as proprietary agreements between Cisco and third-party vendors.

Preprocessor rules: The Snort development team creates these rules, which the Firepower engine uses to decode packets with various protocols.

Local rules: The FMC enables you to create a custom Snort rule by using its GUI. You can also write your own rule in a text editor, save the file in .txt format, and upload it to the FMC. When you create your own Snort rule and import it into the FMC, the Firepower System labels it as a local rule. Similarly, if you obtain a Snort rule from a community-based Internet forum, the system considers it a local rule as well. The Firepower System supports text-based local rules only; it does not support the creation and compilation of your own SO rules.

Snort uses a unique generator ID (GID) and Snort rule ID (SID) to identify a rule. Depending on who creates a rule, the numbering schemes of GIDs and SIDs are different. Table 21-1 provides the identification numbers that you can use to distinguish one type of Snort rule from another.

Table 21-1 Types of Snort Rules and Their Identification Numbers

Type of Rule	Identification Number
Standard text rule	GID is 1. SID is lower than 1,000,000.
Shared object rule	GID is 3.
Preprocessor rule	GID can be anything other than 1 or 3.
Local rule	SID is 1,000,000 or higher.

Once you create an intrusion policy, you can enter the intrusion policy editor page to find and enable a specific Snort rule or all of the rules within a category.

Figure 21-5 shows a search query for all the Snort rules with Telnet metadata. You can perform a similar search to find rules with many other criteria. For now, just take a look how the intrusion policy editor displays rules in a search query. Later in this chapter, you will learn how to create, edit, and deploy an intrusion policy from scratch.

Once you find a rule, you can select the rule and click the Show Details button to view detailed information about it.

Figure 21-6 shows the syntax of Snort rule 1:718. It also provides detailed rule documentation. Later in this chapter, you will learn how to create an intrusion policy from scratch and enable a desired rule within it.

Figure 21-7 illustrates Snort rule 1:718, which analyzes traffic from the $TELNET_SERVERS variable to detect a potential brute-force attack. If you do not change the default value of the $TELNET_SERVERS variable, Snort analyzes packets from additional IP addresses—along with your real Telnet server—for the “Login incorrect” content with the payloads.

You must define the $HOME_NET variable based on the network address used in your LAN. If the default value of a variable that represents a specific server is set to any or $HOME_NET, you must change it to a more specific value. It makes a Snort rule more effective and reduces the probability of false positive alerts. Thus, a proper variable setting can improve performance.

The purpose of a variable is explained by the variable’s name. The names ending with $*_NET, $*_SERVERS and $*_PORTS define network addresses, IP addresses, and port numbers, respectively. Consider these examples:

$HOME_NET, $EXTERNAL_NET: Defines the internal network and external network addresses, respectively.

$HTTP_SERVERS, $DNS_SERVERS: Defines the IP addresses of the web servers and domain name servers, respectively.

$FTP_PORTS, $HTTP_PORTS: Defines the port numbers of the FTP servers and web servers, respectively.

Figure 21-8 shows a list of variables in the default variable set. You must redefine both variables—$HOME_NET and $TELNET_SERVERS—to trigger SID:718 efficiently in the appropriate condition. The list in this figure has been shortened to accommodate both the $HOME_NET and $TELNET_SERVERS in one screenshot.

Balanced Security and Connectivity: Cisco Talos recommends this policy for the best system performance without compromising the detection of the latest critical vulnerabilities.

Connectivity over Security: This policy prioritizes connection speed while maintaining detection of a few critical vulnerabilities.

Security over Connectivity: Security has higher priority than connection speed and reachability.

Maximum Detection: Security has supreme priority over business continuity. Due to the deeper inspection of packets, end users may experience latency, and FTD may drop some legitimate traffic.

Figure 21-9 shows four system-provided policies that you can use as a base policy for a network analysis policy (NAP).

Figure 21-10 shows five system-provided policies in the dropdown that you can use as a base policy for an intrusion policy. The base policy No Rules Active allows you to create an empty intrusion policy with all the rules disabled. You can use it for two purposes: to create an intrusion policy from scratch or to investigate any technical issues with the Snort engine.

The number of rules enabled by default in a system-provided policy varies. Cisco uses a Common Vulnerability Scoring System (CVSS) score that is associated with a vulnerability to determine whether a rule should be part of any system-provided policy.

Table 21-2 shows the criteria to determine the inclusion of an intrusion rule in a system-provided policy.

Table 21-2 System-Provided Policies and Their Associations with CVSS Scores

Intrusion Policy	CVSS Score	Age of Vulnerability
Connectivity over Security	10	Current year plus two prior years
Balanced Security and Connectivity	9 or higher	Current year plus two prior years
Security over Connectivity	8 or higher	Current year plus three prior years
Maximum Detection	7.5 or higher	All the years since 2005

Figure 21-11 shows the correlation among the system-provided intrusion policies, their detection coverages, and processing overheads. The higher the threat coverage, the higher the utilization of the FTD resources.

Cisco releases rule updates periodically. The FMC can update the ruleset automatically from the cloud through a scheduled task. You can also manually download a rule update file and upload it to the FMC for installation. Each rule update comes with a unique ruleset. While the exact number of available rules on a specific rule update is unpredictable, the ratio of enabled rules among the system-provided policies is similar. For example, the Security over Connectivity policy enables the highest number of intrusion rules, whereas the Connectivity over Security policy enables the lowest number of rules. (However, the No Rules Active policy has no rules enabled.)

Figure 21-12 shows the Policy Information page in an intrusion policy editor. Here you can determine the number of enabled rules and the rule update version of a base policy.

Table 21-3 shows the number of rules enabled by default by Rule Update 2016-03-28-001-vrt. Firepower Version 6.1 comes with rule update 2016-03-28-001-vrt preinstalled.

Table 21-3 Enabled Rules in the Default Ruleset of Rule Update 2016-03-28-001-vrt

Intrusion Policy	Total Number of Enabled Rules	Rules to Generate Events	Rules to Drop and Generate Events
No Rules Active	0	0	0
Connectivity over Security	459	9	450
Balanced Security and Connectivity	7142	84	7058
Security over Connectivity	10,069	235	9834
Maximum Detection	5533	39	5494

Table 21-4 shows the number of rules enabled by default by Rule Update 2017-06-15-001-vrt. You can compare the statistics shown here with the number of rules enabled on 2016-03-28-001-vrt, as shown in Table 21-3. These rule updates were released one year apart, but the ratio of the enabled rules is similar.

Table 21-4 Enabled Rules in the Default Ruleset of Rule Update 2017-06-15-001-vrt

Intrusion Policy	Total Number of Rules Enabled	Rules to Generate Events	Rules to Drop and Generate Events
No Rules Active	0	0	0
Connectivity over Security	474	9	465
Balanced Security and Connectivity	8779	71	8708
Security over Connectivity	12,716	245	12,471
Maximum Detection	6732	40	6692

As the name suggests, the Maximum Detection policy is meant to enable the maximum number of intrusion rules. However, the numbers in Tables 21-3 and 21-4 do not support this assumption. Actually, the Security over Connectivity policy enables the maximum number of rules. So, how does the Maximum Detection policy ensure the maximum threat detection? It actually performs a much deeper analysis of packets to detect any protocol anomalies.

Table 21-5 shows the number of preprocessors enabled on different system-provided network analysis policies. The Maximum Detection policy has the highest number of preprocessors enabled, by default.

Table 21-5 Number of Preprocessors Enabled on Rule Update 2017-06-15-001-vrt

Intrusion Policy	Number of Enabled Preprocessors
Connectivity over Security	15
Balanced Security and Connectivity	15
Security over Connectivity	17
Maximum Detection	18

Figure 21-13 illustrates the default configuration settings of the HTTP preprocessor on the Maximum Detection policy. As you can see, much deeper inspections are enabled.

Figure 21-14 shows the default configuration settings of the HTTP preprocessor on the Balanced Security and Connectivity policy. If you compare this figure with the previous one, you will find a milder HTTP inspection setting on the Balanced Security and Connectivity policy.

Before you deploy an intrusion policy, you should consider the following best practices, in general:

To match a packet using five tuples—source port, destination port, source address, destination address, and protocol—you should consider using an access rule, not an intrusion rule. The purpose of a Snort-based intrusion rule is to perform advanced deep packet inspection.

Select the Balanced Security and Connectivity policy as the default policy when you create the network analysis policy and intrusion policy.

Figure 21-15 shows the selection of Balanced Security and Connectivity as the base policy for both the network analysis policy (top) and intrusion policy (bottom). Also, notice the check boxes for Inline Mode and Drop When Inline; you must select both of them if you want FTD to block an intrusion attempt.

Use the Firepower Recommendations feature within the intrusion policy. This feature can incorporate the network discovery data to determine the intrusion rules that are related to the operating systems, services, and applications running in a network.

When you generate Firepower recommendations, define the networks to examine and set Recommendation Threshold (by Rule Overhead) to Medium or Low for optimal system performance.

Figure 21-16 shows the Firepower Recommendations configuration page within the intrusion policy editor. The number of recommended rules can vary based on your settings.

Enable the Adaptive Profiles and Enable Profile Update features to leverage the service metadata and allow FTD to apply the enabled intrusion rules to the relevant traffic intelligently.

Figure 21-17 shows the advanced settings for an access control policy where you can configure the Adaptive Profiles and Enable Profile Update settings.

Table 21-6 shows the differences between the Firepower Recommendations and Enable Profile Update features. Although both features work together to enable traffic-specific intrusion rules, there are some differences between them.

Table 21-6 Firepower Recommendations Versus Enable Profile Update

Firepower Recommendation	Enable Profile Update
Recommends enabling and disabling intrusion rules, based on the discovered applications and hosts.	Compares rule metadata with the applications and operating systems of a host and determines whether the FTD device should apply a certain rule to certain traffic from that host.
Can enable a disabled rule if the rule relates to a host and application in the network.	Does not change the state of a disabled rule. Only works on the enabled rules in an intrusion policy.
Configured within an intrusion policy.	Configured within an access control policy.

In the network analysis policy, configure the Inline Normalization preprocessor with the Normalize TCP Payload option enabled to ensure consistent retransmission of data (see Figure 21-18).

Some of the best practices are applicable to a particular deployment mode, and depend on your traffic handling policy. For example:

If you want to prevent cyber attacks by blocking intrusion attempts, you need to deploy FTD device bump in the wire (BITW). The BITW deployment requires an inline interface pair—you include the ingress and egress interfaces to an inline interface pair and then assign the interface pair to an inline set. To learn more about Inline Mode, see Chapter 11, “Blocking Traffic Using Inline Interface Mode.”

If your goal is to deploy FTD for detection-only purposes—that is, you do not want to block an intrusion attempt in real time—consider deploying an FTD device in Inline Tap Mode instead of in Passive Mode. Doing so enables you to switch to Inline Mode faster, without the need for a cabling change. This is critical in case of an emergency. To learn more, read Chapter 12, “Inspecting Traffic Without Blocking It.”

If you choose to deploy an FTD device in Passive Mode anyway, make sure the Adaptive Profiles option is enabled on the advanced settings access control policy. This option enables an FTD device to adapt intrusion rules dynamically based on the metadata of the service, client application, and host traffic.

When FTD prompts you to select a firewall mode (during initialization after a reimage), choose Routed Mode. While Transparent Mode can block an intrusion attempt, you could accomplish the same goal—transparency or a bump in the wire—by using Inline Mode, which has less configuration overhead. Using the FTD CLI, you can switch between Routed Mode and Transparent Mode. To learn more about Routed Mode, read Chapter 8, “Firepower Deployment in Routed Mode.”

Figure 21-19 shows the navigation to the network analysis policy through the intrusion policy page. You will find a similar link on the access control policy page.

Step 1. Click the Create Policy button. The Create Network Analysis Policy window appears (see Figure 21-20).

Step 2. Give a name to the policy.

Step 3. As the base policy, select Balanced Security and Connectivity. This policy provides the best system performance without compromising the detection of the latest and critical vulnerabilities.

Step 4. Click the Create Policy button to create a network analysis policy using the default settings. You will return to the network analysis policy configuration page. The network analysis policy you have just created should appear in the list on this page.

Optionally, if you want to modify the default settings of the network analysis policy, read on; otherwise, skip to the next section, “Configuring an Intrusion Policy”.

Step 1. On the network analysis policy editor page, select Settings in the panel on the left. A list of preprocessors appears. Figure 21-21 shows the network analysis policy editor page, where you can enable, disable, and modify preprocessor configurations.

Step 2. Enable (or disable) any desired preprocessors in addition to the preprocessors enabled (or disabled) by default on the base policy.

Figure 21-22 shows the impact of your changes to the network analysis policy. Although Inline Normalization and Rate-Based Attack Prevention preprocessors are disabled on the base policy, your custom configuration overrides the default behavior of the base policy.

Step 3. When you are finished with modifications, make sure you save the changes. On the left panel, select the Policy Information section, and click the Commit Changes button (see Figure 21-23). This button is comparable to a Save button, in that any modification is saved but not deployed on a managed device.

Step 1. Navigate to Policies > Access Control > Intrusion. The intrusion policy configuration page appears.

Step 2. Click the Create Policy button. The Create Intrusion Policy window appears (see Figure 21-24).

Step 3. Give a name to the policy.

Step 4. Select Balanced Security and Connectivity as the base policy. This policy provides the best system performance without compromising the detection of the latest and critical vulnerabilities.

Step 5. Click the Create Policy button to create an intrusion policy using the default settings.

To generate and use Firepower Recommendations, follow these steps:

Step 1. Edit the intrusion policy where you want to enable Firepower Recommendations. If you are currently in the process of creating an intrusion policy, click the Create and Edit Policy button to enter the policy editor page right away. If a policy is already created, you can enter the editor page by using the pencil icon, which is next to the name of the intrusion policy (see Figure 21-25).

Step 2. On the intrusion policy editor page, select Firepower Recommendations from the blue panel on the left. The Firepower Recommended Rule Configuration page appears.

Step 3. Define the networks to examine and set Recommendation Threshold (by Rule Overhead) to low or medium so that the intrusion rules with higher processing overhead are not considered in the recommended ruleset.

Figure 21-26 shows the configuration of Firepower Recommendations. The configuration in this example analyzes traffic from the 192.168.1.0/24 network and suggests intrusion rules based on the application, services, and operating systems running on the network hosts.

Step 4. Click the Generate and Use Recommendations button. This button appears if the FMC did not generate any recommendation before. If a recommendation has already been generated, you will see different buttons, whose labels are self-explanatory, such as Update Recommendations, Do Not Use Recommendations, and so on.

Figure 21-27 shows the recommendations for 963 rules (20 rules to generate events, 943 rules to drop and generate events). These rules are suggested based on the information on two hosts.

For testing purposes, you can try regenerating recommendations with low rule overhead threshold. You will notice that, for the same network hosts, the number of recommended rules is now significantly lower. Figure 21-28 shows the recommendations for only three rules (two rules to generate events and one rule to drop and generate events). The number of recommended rules for the same two network hosts are significantly lower because the rule processing overhead is set to low.

Step 5. Make sure to save any changes by clicking the Commit Changes button on the Policy Information page.

Step 1. Edit the intrusion policy where you want to enable or disable an intrusion rule. If you are currently in the process of creating an intrusion policy, click the Create and Edit Policy button to enter the policy editor page right away. If a policy has already been created, you can enter the editor page by using the pencil icon, which is next to the name of the intrusion policy.

Step 2. On the intrusion policy editor page, select Rules in the panel on the left. A list of rules appears.

Step 3. When you find a desired rule, select its check box and define the Rule State to enable the rule.

Figure 21-29 illustrates the steps to find and enable a desired rule using the intrusion policy editor.

Step 4. Make sure you save any changes by clicking the Commit Changes button on the Policy Information page.

You must define the $HOME_NET variable based on the network address used in your LAN. If the default value of a variable that represents a specific server is set to any or $HOME_NET, you must change it to a more specific value. Doing so makes a Snort rule more effective and reduces the probability of false positive alerts. Thus, a proper variable setting can improve performance.

To modify the system-provided default set or to add a new variable set, follow these steps:

Step 1. Navigate to Objects > Object Management.

Step 2. Select Variable Set from the menu on the left. The list of available variable sets appears.

Step 3. You can edit an existing variable set or create a new one. To create a new one, click the Add Variable Set button, and the New Variable Set configuration window appears.

Step 4. Find the variables that need updates. Click a variable’s pencil icon to edit the value of the variable. To define a value, you can add a network address directly or select a predefined network object. The system also allows you to create a new network object on the fly.

Figure 21-30 shows how to navigate to the New Variable Set configuration window, where you can customize the default variables. For example, when you click the pencil icon next to the HOME_NET variable, the Edit Variable HOME_NET window, which is a variable editor, appears. Figure 21-30 shows the customized values for the HOME_NET, EXTERNAL_NET, and TELNET_SERVERS variables. (You can see the variable editor in the background in Figure 21-31.)

Figure 21-31 shows the definition of a new network object, Custom-Home-Network, which will replace the default value of the HOME_NET variable. In the background, you can see the green plus icon on the variable editor that opens the New Network Objects configuration window also shown here.

Step 5. When the values of the necessary variables are updated with the new network addresses or ports, save the configuration.

Adaptive Profiles: An access control policy allows you to enable Adaptive Profiles and Enable Profile Updates features, which empower an FTD device to apply the enabled intrusion rules intelligently to the relevant traffic.

Figure 21-32 shows the configuration window for the Adaptive Profiles and Enable Profile Updates features. To find this window, go to the Advanced tab of the access control policy and use the pencil icon next to Detection Enhancement Settings.

Invoking the policies: An access control policy invokes various Firepower policies that you configure all over the GUI (for example, network analysis policy, intrusion policy).

First, on the Advanced tab, select an intrusion policy that is applied before an access rule is determined for the traffic. Here, you can also select a variable set that is used by the intrusion policy and a network analysis policy that the system uses by default.

Figure 21-33 shows the selection of an intrusion policy, a variable set, and a network analysis policy with an access control policy.

Then, when you add an access rule, you can invoke an intrusion policy and a variable set for the matching traffic. You can define this on the Inspection tab of the access rule editor.

Figure 21-34 shows the selection of an intrusion policy and a variable set within an access rule. When a packet matches the condition of this access rule, it is subject to the inspection of this intrusion policy and variable set.

Finally, for any traffic that does not match an access rule condition, you can select an intrusion policy as the default action.

Figure 21-35 shows the selection of a custom intrusion policy as the default action for the traffic that does not match any of the access rule conditions.

Once you have invoked all the necessary policies and configurations in your access control policy, you must click the Save button to store the configurations locally. Finally, to activate the new policies, click the Deploy button.

Figure 21-36 shows three places where you can connect an intrusion policy with an access control policy. It also clarifies their relationships with traffic flow.

To verify the action of an intrusion policy, this chapter uses a simple Snort rule 1:718. Here is the rule syntax:

Click here to view code image

alert tcp $TELNET_SERVERS 23 -> $EXTERNAL_NET
any (msg:"PROTOCOL-TELNET login incorrect"; flow:to_client,established; content:"Login incorrect";
metadata:ruleset community, service telnet; classtype:bad-unknown; sid:718;
rev:16; )

According to the syntax of this rule, when a Telnet server does not authenticate a client and responds to the client with a “Login incorrect” message on its payload (due to an incorrect login credential), an FTD device triggers this rule to prevent any potential brute-force attack. Furthermore, if you define a variable set precisely, this rule is applicable on the Telnet traffic to $EXTERNAL_NET. It should not apply on the Telnet traffic to $HOME_NET.

Figure 21-37 shows the payload of a packet on a packet analyzer. A Telnet server sends this packet when you enter an incorrect credential. Snort rule 1:718 can detect this payload.

Figure 21-38 shows the lab topology that is used in the configuration examples in this chapter.

If you attempt to connect to your Telnet server from an external network host and enter a valid login credential, you will be able to access the server as usual. However, if you enter an incorrect credential, the server sends the client a “Login incorrect” message in a packet.

Example 21-1 shows the messages on the CLI when you attempt to connect to a Telnet server running on a Linux-based system. Note the “Login incorrect” message when the login attempt is unsuccessful.

Example 21-1 Telnet Server Connection Attempts

Click here to view code image

---

! When a login attempt is successful

external-user@Fedora:~$ telnet 192.168.1.200
Trying 192.168.1.200... Open
Connected to 192.168.1.200.

Ubuntu login: internal-user
Password: ********

Welcome to Ubuntu 16.04.2 LTS (GNU/Linux 4.4.0-81-generic x86_64)
internal-user@Ubuntu:~$


! When a login attempt is unsuccessful

external-user@Fedora:~$ telnet 192.168.1.200
Trying 192.168.1.200... Open
Connected to 192.168.1.200.

Ubuntu login: internal-user
Password: <incorrect_password>

Login incorrect

Ubuntu login:

---

Depending on the rule state, policy setting, and interface mode, a Firepower system can act differently on the same Telnet traffic, and you may find different types of intrusion events for the same Snort rule. For example, if the interface mode is set to Inline Mode, the intrusion policy is set to Drop When Inline, and the rule state is Drop and Generate Events, then an FTD device can block a matching packet. The FMC displays a “dropped” event (indicated by a dark gray down arrow).

However, if the Drop When Inline option is unchecked in the intrusion policy, or if the interface mode is Inline Tap Mode or Passive Mode, the FMC shows a “would have dropped” event (indicated by a light gray down arrow). To find more scenarios for “would have dropped” events, see Chapter 12.

Figure 21-39 shows three different types of intrusion events triggered by the same Snort rule.

To analyze an intrusion event further, you can click on the down arrow at the beginning of each row. It allows you to drill down into an intrusion event and the associated packet data to determine whether an event is false positive.

Figure 21-40 shows various contextual information about an intrusion event (for example, timestamp, priority, and classification of the event). You can also find the ingress and egress interfaces, source and destination details, and any associated rule and policy references.

Figure 21-41 shows the packet information associated with an intrusion event. It allows you to compare the rule content with the packet payload on the same page without the need for any additional tool. This page also offers you an option to download any packet for offline analysis on third-party software.

Figure 21-42 shows the option in the Device Management page that enables an FTD device to capture a packet as it matches a Snort rule. You can disable this option if you do not want to store a complete packet due to any privacy or security policy.

By analyzing the tracing data of a packet, you can determine whether a packet is blocked by Snort or any other component of the Firepower System. The process is described in detail in Chapter 10, “Capturing Traffic for Advanced Analysis.”

First, run the capture tool to begin capturing Telnet packets, making sure to add the trace keyword to collect the tracing data:

Click here to view code image

> capture telnet_inside trace interface INSIDE_INTERFACE match tcp any any eq 23
>

You can run the show capture command any time to see the status of the capture or to view the captured packets:

Click here to view code image

> show capture
capture telnet_inside type raw-data trace interface INSIDE_INTERFACE
[Capturing - 0 bytes]
  match tcp any any eq telnet
>

Now, you can attempt to access the Telnet server once again. To reproduce an intrusion event, enter an incorrect credential. The capture tool captures all the packets on a Telnet session—including the first three-way handshake, which is completely allowed by the FTD device, per the current intrusion policy.

Example 21-2 shows the first few packets of a Telnet session. Later, it analyzes the tracing data of the first packet. It reveals how an FTD device makes a decision and sends a packet to Snort for deep packet inspection.

Example 21-2 Capturing Telnet Traffic with Tracing Information

Click here to view code image

---

> show capture telnet_inside

119 packets captured

   1: 20:23:21.086802       107.15.160.100.53875 > 192.168.1.200.23: S
 1751019501:1751019501(0) win 4128 <mss 1460>
   2: 20:23:21.087229       107.15.160.100.53875 > 192.168.1.200.23: S
 1751019501:1751019501(0) win 4128 <mss 1460>
   3: 20:23:21.087565       192.168.1.200.23 > 107.15.160.100.53875: S
 232306554:232306554(0) ack 1751019502 win 29200 <mss 1460>
   4: 20:23:21.087702       192.168.1.200.23 > 107.15.160.100.53875: S
 232306554:232306554(0) ack 1751019502 win 29200 <mss 1460>
   5: 20:23:21.089717       107.15.160.100.53875 > 192.168.1.200.23: . ack 232306555
 win 4128
   6: 20:23:21.089762       107.15.160.100.53875 > 192.168.1.200.23: P
 1751019502:1751019514(12) ack 232306555 win 4128
.
.
<Output Omitted for Brevity>


! Now view the tracing data of the first captured packet.

> show capture telnet_inside packet-number 1 trace

119 packets captured

   1: 20:23:21.086802       107.15.160.100.53875 > 192.168.1.200.23: S
 1751019501:1751019501(0) win 4128 <mss 1460>

Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 3
Type: NGIPS-MODE
Subtype: ngips-mode
Result: ALLOW
Config:
Additional Information:
The flow ingressed an interface configured for NGIPS mode and NGIPS services will be
 applied

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit ip any any rule-id 268435458
access-list CSM_FW_ACL_ remark rule-id 268435458: ACCESS POLICY: AC Policy - Default/1
access-list CSM_FW_ACL_ remark rule-id 268435458: L4 RULE: DEFAULT ACTION RULE
Additional Information:
This packet will be sent to snort for additional processing where a verdict will be
 reached

Phase: 5
Type: NGIPS-EGRESS-INTERFACE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
Ingress interface OUTSIDE_INTERFACE is in NGIPS inline mode.

Egress interface INSIDE_INTERFACE is determined by inline-set configuration

Phase: 6
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 848, packet dispatched to next module
Phase: 7
Type: EXTERNAL-INSPECT
Subtype:
Result: ALLOW
Config:
Additional Information:
Application: 'SNORT Inspect'

Phase: 8
Type: SNORT
Subtype:
Result: ALLOW
Config:
Additional Information:
Snort Verdict: (pass-packet) allow this packet

Phase: 9
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list

Result:
input-interface: INSIDE_INTERFACE
input-status: up
input-line-status: up
Action: allow

1 packet shown
>

---

Example 21-3 shows the Snort verdict “drop this packet,” which appears in tracing output when a packet matches a Snort rule syntax and the rule state is set to drop and generate the event.

Example 21-3 Snippet of the Tracing Information When a Packet Is Blocked by Snort

Click here to view code image

---

<Output Omitted for Brevity>
.
.
Phase: 7
Type: EXTERNAL-INSPECT
Subtype:
Result: ALLOW
Config:
Additional Information:
Application: 'SNORT Inspect'

Phase: 8
Type: SNORT

Subtype:
Result: DROP

Config:
Additional Information:
Snort Verdict: (block-packet) drop this packet

.
.
<Output Omitted for Brevity>

---

Example 21-4 shows the statistics of a Snort drop. According to this output, Snort requests to drop five frames after an incorrect credential was entered to authenticate a Telnet server.

Example 21-4 Statistics of a Snort Drop

Click here to view code image

---

> show asp drop

Frame drop:
  Snort requested to drop the frame (snort-drop)                               5

  FP L2 rule drop (l2_acl)                                                     1

Last clearing: 20:23:14 UTC Jul 3 2017 by enable_1

Flow drop:

Last clearing: 20:23:14 UTC Jul 3 2017 by enable_1
>

---

a. Network analysis policy

b. Intrusion policy

c. Access control policy

d. All of the above

2. Which of the following numbering schemes is correct for a Snort rule?

a. Standard text rule uses GID 1. SID is lower than 1,000,000.

b. Preprocessor rule can use any GID other than 1 or 3.

c. Local rule uses SID 1,000,000 or higher.

d. All of the above.

3. Which of the following base policies enables the largest number of standard text Snort rules by default?

a. Connectivity over Security

b. Balanced Security and Connectivity

c. Security over Connectivity

d. Maximum Detection

4. Which of the following options is mandatory if you want to drop an intrusion attempt or block a packet that may constitute a potential cyber attack?

a. The interface set has to be in Inline, Routed, or Transparent Mode.

b. The intrusion policy must be enabled with the Drop When Inline option.

c. The rule state must be set to Drop and Generate Events.

d. All of the above.