Which protocol is used by the Cisco Cyberthreat defense solution to collect information about the traffic that is traversing the network select one Nat https NetFlow telnet?
Working with Intrusion EventsThe following topics describe how to work with intrusion events. Show
About Intrusion EventsThe Firepower System can help you monitor your network for traffic that could affect the availability, integrity, and confidentiality of a host and its data. By placing managed devices on key network segments, you can examine the packets that traverse your network for malicious activity. The system has several mechanisms it uses to look for the broad range of exploits that attackers have developed. When the system identifies a possible intrusion, it generates an intrusion event (sometimes called by a legacy term, "IPS event"), which is a record of the date, time, the type of exploit, and contextual information about the source of the attack and its target. For packet-based events, a copy of the packet or packets that triggered the event is also recorded. Managed devices transmit their events to the Firepower Management Center where you can view the aggregated data and gain a greater understanding of the attacks against your network assets. You can also deploy a managed device as an inline, switched, or routed intrusion system, which allows you to configure the device to drop or replace packets that you know to be harmful. Tools for Reviewing and Evaluating Intrusion EventsYou can use the following tools to review intrusion events and evaluate whether they are important in the context of your network environment and your security policies.
Additionally, you can use publicly-available information such as the predefined resources on the Analysis > Advanced > Contextual Cross-Launch page to learn more about malicious entities. To search for a particular message string and retrieve documentation for the rule that generated an event, see https://www.snort.org/rule_docs/. License Requirements for Intrusion EventsFTD LicenseThreat Classic LicenseProtection Requirements and Prerequisites for Intrusion EventsModel SupportAny. Supported DomainsAny User Roles
Viewing Intrusion EventsYou view an intrusion event to determine whether there is a threat to your network security. The initial intrusion events view differs depending on the workflow you use to access the page. You can use one of the predefined workflows, which includes one or more drill-down pages, a table view of intrusion events, and a terminating packet view, or you can create your own workflow. You can also view workflows based on custom tables, which may include intrusion events. An event view may be slow to display if it contains a large number of IP addresses and you have enabled the Resolve IP Addresses event view setting. In a multidomain deployment, you can view data for the current domain and for any descendant domains. You cannot view data from higher level or sibling domains. Procedure
About Intrusion Event FieldsWhen the system identifies a possible intrusion, it generates an intrusion event, which is a record of the date, time, the type of exploit, and contextual information about the source of the attack and its target. For packet-based events, a copy of the packet or packets that triggered the event is also recorded. You can view intrusion event data in the Firepower Management Center web interface at Analysis > Intrusions > Events or emit data from certain fields as syslog messages for consumption by an external tool. Syslog fields are indicated in the list below; fields without a listed syslog equivalent are not available in syslog messages. When searching intrusion events, keep in mind that the information available for any individual event can vary depending on how, why, and when system logged the event. For example, only intrusion events triggered on decrypted traffic contain TLS/SSL information.
Intrusion Event FieldsAccess Control Policy (Syslog: ACPolicy)The access control policy associated with the intrusion policy where the intrusion, preprocessor, or decoder rule that generated the event is enabled. Access Control Rule (Syslog: AccessControlRuleName)The access control rule that invoked the intrusion policy that generated the event. Default Action indicates that the intrusion policy where the rule is enabled is not associated with a specific access control rule but, instead, is configured as the default action of the access control policy. This field is empty (or, for syslog messages, omitted) if there is:
Application Protocol (Syslog: ApplicationProtocol)The application protocol, if available, which represents communications between hosts detected in the traffic that triggered the intrusion event. Application Protocol Category and TagCriteria that characterize the application to help you understand the application's function. Application RiskThe risk associated with detected applications in the traffic that triggered the intrusion event: Very High, High, Medium, Low, and Very Low. Each type of application detected in a connection has an associated risk; this field displays the highest risk of those. Business RelevanceThe business relevance associated with detected applications in the traffic that triggered the intrusion event: Very High, High, Medium, Low, and Very Low. Each type of application detected in a connection has an associated business relevance; this field displays the lowest (least relevant) of those. Classification (Syslog: Classification)The classification where the rule that generated the event belongs. See a list of possible classification values in Intrusion Event Details. When searching this field, enter the classification number, or all or part of the classification name or description for the rule that generated the events you want to view. You can also enter a comma-separated list of numbers, names, or descriptions. Finally, if you add a custom classification, you can also search using all or part of its name or description. Client (Syslog: Client)The client application, if available, which represents software running on the monitored host detected in the traffic that triggered the intrusion event. Client Category and TagCriteria that characterize the application to help you understand the application's function. Connection Counter (Syslog Only)A counter that distinguishes one connection from another simultaneous connection. This field has no significance on its own. The following fields collectively uniquely identify the connection event associated with a particular intrusion event: DeviceUUID, First Packet Time, Connection Instance ID, and Connection Counter. Connection Instance ID (Syslog Only)The Snort instance that processed the connection event. This field has no significance on its own. The following fields collectively uniquely identify the connection event associated with a particular intrusion event: DeviceUUID, First Packet Time, Connection Instance ID, and Connection Counter. CountThe number of events that match the information that appears in each row. Note that the Count field appears only after you apply a constraint that creates two or more identical rows. This field is not searchable. CVE IDThis field is a search field only. Search by the identification number associated with the vulnerability in MITRE’s Common Vulnerabilities and Exposures (CVE) database (https://cve.mitre.org/). Destination ContinentThe continent of the receiving host involved in the intrusion event. Destination CountryThe country of the receiving host involved in the intrusion event. Destination IP (Syslog: DstIP)The IP address used by the receiving host involved in the intrusion event. See also A Note About Initiator/Responder, Source/Destination, and Sender/Receiver Fields. Destination Port / ICMP Code (Syslog: DstPort, ICMPCode)The port number for the host receiving the traffic. For ICMP traffic, where there is no port number, this field displays the ICMP code. Destination UserThe username associated with the Responder IP of the connection event. This host may or may not be the host receiving the exploit. This value is typically known only for users on your network. . See also A Note About Initiator/Responder, Source/Destination, and Sender/Receiver Fields. DeviceThe managed device where the access control policy was deployed. DeviceUUID (Syslog Only)The unique identifier of the device that generated an event. The following fields collectively uniquely identify the connection event associated with a particular intrusion event: DeviceUUID, First Packet Time, Connection Instance ID, and Connection Counter. DomainThe domain of the device that detected the intrusion. This field is only present if you have ever configured the Firepower Management Center for multitenancy. Egress Interface (Syslog: EgressInterface)The egress interface of the packet that triggered the event. This interface column is not populated for a passive interface. Egress Security Zone (Syslog: EgressZone)The egress security zone of the packet that triggered the event. This security zone field is not populated in a passive deployment. Egress Virtual RouterIn networks using virtual routing, the name of the virtual router through which traffic exited the network. Email AttachmentsThe MIME attachment file name that was extracted from the MIME Content-Disposition header. To display attachment file names, you must enable the SMTP preprocessor Log MIME Attachment Names option. Multiple attachment file names are supported. Email HeadersThis field is a search field only. The data that was extracted from the email header. To associate email headers with intrusion events for SMTP traffic, you must enable the SMTP preprocessor Log Headers option. Email RecipientThe address of the email recipient that was extracted from the SMTP RCPT TO command. To display a value for this field, you must enable the SMTP preprocessor Log To Addresses option. Multiple recipient addresses are supported. Email SenderThe address of the email sender that was extracted from the SMTP MAIL FROM command. To display a value for this field, you must enable the SMTP preprocessor Log From Address option. Multiple sender addresses are supported. First Packet Time (Syslog Only)The time the system encountered the first packet. The following fields collectively uniquely identify the connection event associated with a particular intrusion event: DeviceUUID, First Packet Time, Connection Instance ID, and Connection Counter. GeneratorThe component that generated the event. See also information about the following intrusion event fields: GID, Message, and Snort ID. GID (Syslog Only)Generator ID; the ID of the component that generated the event. See also information about the following intrusion event fields: Generator, Message, and Snort ID. HTTP HostnameThe host name, if present, that was extracted from the HTTP request Host header. Note that request packets do not always include the host name. To associate host names with intrusion events for HTTP client traffic, you must enable the HTTP Inspect preprocessor Log Hostname option. In table views, this column displays the first fifty characters of the extracted host name. You can hover your pointer over the displayed portion of an abbreviated host name to display the complete name, up to 256 bytes. You can also display the complete host name, up to 256 bytes, in the packet view. HTTP Response Code (Syslog: HTTPResponse)The HTTP status code sent in response to a client's HTTP request over the connection that triggered the event. It indicates the reason behind sucessful and failed HTTP request. For more details about HTTP response codes, see RFC 2616, Section 10. HTTP URIThe raw URI, if present, associated with the HTTP request packet that triggered the intrusion event. Note that request packets do not always include a URI. To associate URIs with intrusion events for HTTP traffic, you must enable the HTTP Inspect preprocessor Log URI option. To see the associated HTTP URI in intrusion events triggered by HTTP responses, you should configure HTTP server ports in the Perform Stream Reassembly on Both Ports option; note, however, that this increases resource demands for traffic reassembly. This column displays the first fifty characters of the extracted URI. You can hover your pointer over the displayed portion of an abbreviated URI to display the complete URI, up to 2048 bytes. You can also display the complete URI, up to 2048 bytes, in the packet view. ImpactThe impact level in this field indicates the correlation between intrusion data, network discovery data, and vulnerability information. When searching this field, do not specify impact icon colors or partial strings. For example, do not use blue, level 1, or 0. Valid case-insensitive values are:
Because no operating system information is available for hosts added to the network map from NetFlow data, the system cannot assign Vulnerable (impact level 1: red) impact levels for intrusion events involving those hosts. In such cases, use the host input feature to manually set the operating system identity for the hosts. Ingress Interface (Syslog: IngressInterface)The ingress interface of the packet that triggered the event. Only this interface column is populated for a passive interface. Ingress Security Zone (Syslog: IngressZone)The ingress security zone or tunnel zone of the packet that triggered the event. Only this security zone field is populated in a passive deployment. Ingress Virtual RouterIn networks using virtual routing, the name of the virtual router through which traffic entered the network. Inline Result (Syslog: InlineResult)In workflow and table views, this field displays one of the following: Table 1. Inline Result Field Contents in Workflow and Table Views
The following table lists the possible reasons for the inline results — Would have dropped and Partially dropped.
In a passive deployment, the system does not drop packets, including when an inline interface is in tap mode, regardless of the rule state or the inline drop behavior of the intrusion policy. When searching this field, enter either of the following:
Intrusion Policy (Syslog: IntrusionPolicy)The intrusion policy where the intrusion, preprocessor, or decoder rule that generated the event was enabled. You can choose an intrusion policy as the default action for an access control policy, or you can associate an intrusion policy with an access control rule. IOC (Syslog: NumIOC)Whether the traffic that triggered the intrusion event also triggered an indication of compromise (IOC) for a host involved in the connection. When searching this field, specify triggered or n/a. Message (Syslog: Message)The explanatory text for the event. For rule-based intrusion events, the event message is pulled from the rule. For decoder- and preprocessor-based events, the event message is hard coded. The Generator and Snort IDs (GID and SID) and the SID version (Revision) are appended in parentheses to the end of each message in the format of numbers separated by colons (GID:SID:version). For example (1:36330:2). MPLS Label (Syslog: MPLS_Label)The Multiprotocol Label Switching label associated with the packet that triggered the intrusion event. Network Analysis Policy (Syslog: NAPPolicy)The network analysis policy, if any, associated with the generation of the event. This field displays the first fifty characters of the extracted URI. You can hover your pointer over the displayed portion of an abbreviated URI to display the complete URI, up to 2048 bytes. You can also display the complete URI, up to 2048 bytes, in the packet view. Original Client IPThe original client IP address that was extracted from an X-Forwarded-For (XFF), True-Client-IP, or custom-defined HTTP header. To display a value for this field, you must enable the HTTP preprocessor Extract Original Client IP Address option in the network analysis policy. Optionally, in the same area of the network analysis policy, you can also specify up to six custom client IP headers, as well as set the priority order in which the system selects the value for the Original Client IP event field. Priority (Syslog: Priority)The event priority as determined by the Cisco Talos Intelligence Group (Talos). The priority corresponds to either the value of the priority keyword or the value for the classtype keyword. For other intrusion events, the priority is determined by the decoder or preprocessor. Valid values are high, medium, and low. Protocol (Syslog: Protocol)In the Firepower Management Center web interface, this field is a search field only. The name or number of the transport protocol used in the connection as listed in http://www.iana.org/assignments/protocol-numbers. This is the protocol associated with the source and destination port/ICMP column. Reviewed ByThe name of the user who reviewed the event. When searching this field, you can enter unreviewed to search for events that have not been reviewed. Revision (Syslog Only)The version of the signature that was used to generate the event. See also information about the following intrusion event fields: Generator, GID, Message, SID, and Snort ID. Security Context (Syslog: Context)The metadata identifying the virtual firewall group through which the traffic passed. The system only populates this field for ASA FirePOWER in multiple context mode. SID (Syslog Only)The signature ID (also known as the Snort ID) of the rule that generated the event. See also information about the following intrusion event fields: Generator, GID, Message, Revision, and Snort ID. Snort IDThis field is a search field only. (For the syslog field, see SID.) When performing your search: Specify the Snort ID (SID) of the rule that generated the event or, optionally, specify the combination Generator ID (GID) and SID of the rule, where the GID and SID are separated with a colon (:) in the format GID:SID. You can specify any of the values in the following table: Table 2. Snort ID Search Values
The SID of the events you are viewing is listed in the Message column. For more information, see the description in this section for the Message field. Source ContinentThe continent of the sending host involved in the intrusion event. Source CountryThe country of the sending host involved in the intrusion event. Source IP (Syslog: SrcIP)The IP address used by the sending host involved in the intrusion event. See also A Note About Initiator/Responder, Source/Destination, and Sender/Receiver Fields. Source Port / ICMP Type (Syslog: SrcPort, ICMPType)The port number on the sending host. For ICMP traffic, where there is no port number, this field displays the ICMP type. Source User (Syslog: User)The username associated with the IP address of the host that initiated the connection, which may or may not be the source host of the exploit. This user value is typically known only for users on your network. If applicable, the username is preceded by SSL Actual Action (Syslog: SSLActualAction)In the Firepower Management Center web interface, this field is a search field only. The action the system applied to encrypted traffic: Block/Block with resetRepresents blocked encrypted connections. Decrypt (Resign)Represents an outgoing connection decrypted using a re-signed server certificate. Decrypt (Replace Key)Represents an outgoing connection decrypted using a self-signed server certificate with a substituted public key. Decrypt (Known Key)Represents an incoming connection decrypted using a known private key. Default ActionIndicates the connection was handled by the default action. Do not DecryptRepresents a connection the system did not decrypt. Field values are displayed in the SSL Status field on the search workflow pages. SSL Certificate InformationThis field is a search field only. The information stored on the public key certificate used to encrypt traffic, including:
SSL Failure ReasonThis field is a search field only. The reason the system failed to decrypt encrypted traffic:
Field values are displayed in the SSL Status field on the search workflow pages. SSL StatusThe action associated with the SSL Actual Action (SSL rule, default action, or undecryptable traffic action) that logged the encrypted connection. If the system fails to decrypt an encrypted connection, it displays the SSL Actual Action (undecryptable traffic action) taken, as well as the SSL Failure Reason. For example, if the system detects traffic encrypted with an unknown cipher suite and allows it without further inspection, this field displays Do Not Decrypt (Unknown Cipher Suite). Click the Lock icon to view certificate details. When searching this field, enter one or more of the SSL Actual Action and SSL Failure Reason values to view encrypted traffic the system handled or failed to decrypt. SSL Subject/Issuer CountryThis field is a search field only. A two-character ISO 3166-1 alpha-2 country code for the subject or issuer country associated with the encryption certificate. TimeThe date and time of the event. This field is not searchable. VLAN ID (Syslog: VLAN_ID)The innermost VLAN ID associated with the packet that triggered the intrusion event. Web Application (Syslog: WebApplication)The web application, which represents the content or requested URL for HTTP traffic detected in the traffic that triggered the intrusion event. If the system detects an application protocol of HTTP but cannot detect a specific web application, the system supplies a generic web browsing designation instead. Web Application Category and TagCriteria that characterize the application to help you understand the application's function. Intrusion Event Impact LevelsTo help you evaluate the impact an event has on your network, the Firepower Management Center displays an impact level in the table view of intrusion events. For each event, the system adds an impact level icon whose color indicates the correlation between intrusion data, network discovery data, and vulnerability information.
The following table describes the possible values for the impact levels. Table 3. Impact Levels
Viewing Connection Data Associated with Intrusion EventsThe system can log the connections where intrusion events are detected. Although this logging is automatic for intrusion policies associated with access control rules, you must manually enable connection logging to see associated connection data for the default action. Viewing associated data is most useful when navigating between table views of events. In a multidomain deployment, you can view data for the current domain and for any descendant domains. You cannot view data from higher level or sibling domains. Procedure
Marking Intrusion Events ReviewedIf you are confident that an intrusion event is not malicious, you can mark the event reviewed. If you have examined an intrusion event and are confident that the event does not represent a threat to your network security (for example, because you know that none of the hosts on your network are vulnerable to the detected exploit), you can mark the event reviewed. Reviewed events are stored in the event database and are included in the event summary statistics, but no longer appear in the default intrusion event pages. Your name appears as the reviewer. In a multidomain deployment, if you mark an event reviewed, the system marks it reviewed in all domains that can view that event. If you perform a backup and then delete reviewed intrusion events, restoring your backup restores the deleted intrusion events but does not restore their reviewed status. You view those restored intrusion events under Intrusion Events, not under Reviewed Events. ProcedureOn a page that displays intrusion events, you have two options:
Viewing Previously Reviewed Intrusion EventsIn a multidomain deployment, if you mark an event reviewed, the system marks it reviewed in all domains that can view that event. Procedure
Marking Reviewed Intrusion Events UnreviewedYou can return a reviewed event to the default intrusion events view by marking the event unreviewed. In a multidomain deployment, if you mark an event reviewed, the system marks it reviewed in all domains that can view that event. ProcedureOn a page that displays reviewed events, you have two choices:
Preprocessor EventsPreprocessors provide two functions: performing the specified action on the packet (for example, decoding and normalizing HTTP traffic) and reporting the execution of specified preprocessor options by generating an event whenever a packet triggers that preprocessor option and the associated preprocessor rule is enabled. For example, you can enable the Double Encoding HTTP Inspect option and the associated preprocessor rule with the HTTP Inspect Generator (GID) 119 and the Snort ID (SID) 2 to generate an event when the preprocessor encounters IIS double-encoded traffic. Generating events to report the execution of preprocessors helps you detect anomalous protocol exploits. For example, attackers can craft overlapping IP fragments to cause a DoS attack on a host. The IP defragmentation preprocessor can detect this type of attack and generate an intrusion event for it. Preprocessor events differ from rule events in that the packet display does not include a detailed rule description for the event. Instead, the packet display shows the event message, the GID, SID, the packet header data, and the packet payload. This allows you to analyze the packet’s header information, determine if its header options are being used and if they can exploit your system, and inspect the packet payload. After the preprocessors analyze each packet, the rules engine executes appropriate rules against it (if the preprocessor was able to defragment it and establish it as part of a valid session) to further analyze potential content-level threats and report on them. Preprocessor Generator IDsEach preprocessor has its own Generator ID number, or GID, that indicates which preprocessor was triggered by the packet. Some of the preprocessors also have related SIDs, which are ID numbers that classify potential attacks. This helps you analyze events more effectively by categorizing the type of event much the way a rule’s Snort ID (SID) can offer context for packets triggering rules. You can list preprocessor rules by preprocessor in the Preprocessors filter group on the intrusion policy Rules page; you can also list preprocessor rules in the preprocessor and packet decoder sub-groupings in the Category filter group.
The following table describes the types of events that generate each GID. Table 4. Generator IDs
Intrusion Event Workflow PagesThe preprocessor, decoder, and intrusion rules that are enabled in the current intrusion policy generate intrusion events whenever the traffic that you monitor violates the policy. The Firepower System provides a set of predefined workflows, populated with event data, that you can use to view and analyze intrusion events. Each of these workflows steps you through a series of pages to help you pinpoint the intrusion events that you want to evaluate. The predefined intrusion event workflows contain three different types of pages, or event views:
Drill-down pages generally include two or more columns in a table (and, for some drill-down views, more than one table) that allow you to view one specific type of information. When you “drill down” to find more information for one or more destination ports, you automatically select those events and the next page in the workflow appears. In this way, drill-down tables help you reduce the number of events you are analyzing at one time. The initial table view of intrusion events lists each intrusion event in its own row. The columns in the table list information such as the time, the source IP address and port, the destination IP address and port, the event priority, the event message, and more. When you select events on a table view, instead of selecting events and displaying the next page in the workflow, you add to what are called constraints. Constraints are limits that you impose on the types of events that you want to analyze. For example, if you click Close () in any column and clear Time from the drop-down list, you can remove Time as one of the columns. To narrow the list of events in your analysis, you can click the link for a value in one of the rows in the table view. For example, to limit your analysis to the events generated from one of the source IP addresses (presumably, a potential attacker), click the IP address in the Source IP Address column. If you select one or more rows in a table view and then click View, the packet view appears. A packet view provides information about the packet that triggered the rule or the preprocessor that generated the event. Each section of the packet view contains information about a specific layer in the packet. You can expand collapsed sections to see more information.
If the predefined workflows do not meet your specific needs, you can create custom workflows that display only the information you are interested in. Custom intrusion event workflows can include drill-down pages, a table view of events, or both; the system automatically includes a packet view as the last page. You can easily switch between the predefined workflows and your own custom workflows depending on how you want to investigate events. Using Intrusion Event WorkflowsThe drill-down views and table view of events share some common features that you can use to narrow a list of events and then concentrate your analysis on a group of related events. To avoid displaying the same intrusion events on different workflow pages, the time range pauses when you click a link at the bottom of the page to display another page of events, and resumes when you click to take any other action on the subsequent page.
Procedure
Intrusion Event Drill-Down Page ConstraintsThe following table describes how to use the drill-down pages. Table 5. Constraining Events on Drill-Down Pages
Intrusion Event Table View ConstraintsThe following table describes how to use the table view. Table 6. Constraining Events on the Table View of Events
Using the Intrusion Event Packet ViewA packet view provides information about the packet that triggered the rule that generated an intrusion event.
The packet view indicates why a specific packet was captured by providing information about the intrusion event that the packet triggered, including the event’s time stamp, message, classification, priority, and, if the event was generated by a standard text rule, the rule that generated the event. The packet view also provides general information about the packet, such as its size. In addition, the packet view has a section that describes each layer in the packet: data link, network, and transport, as well as a section that describes the bytes that comprise the packet. If the system decrypted the packet, you can view the decrypted bytes. You can expand collapsed sections to display detailed information.
In a multidomain deployment, you can view data for the current domain and for any descendant domains. You cannot view data from higher level or sibling domains. Procedure
Event Information FieldsOn the packet view, you can view information about the packet in the Event Information section. EventThe event message. For rule-based events, this corresponds to the rule message. For other events, this is determined by the decoder or preprocessor. The ID for the event is appended to the message in the format (GID:SID:Rev). GID is the generator ID of the rules engine, the decoder, or the preprocessor that generated the event. SID is the identifier for the rule, decoder message, or preprocessor message. Rev is the revision number of the rule. TimestampThe time that the packet was captured, in UTC time zone. ClassificationThe event classification. For rule-based events, this corresponds to the rule classification. For other events, this is determined by the decoder or preprocessor. PriorityThe event priority. For rule-based events, this corresponds to either the value of the priority keyword or the value for the classtype keyword. For other events, this is determined by the decoder or preprocessor. Ingress Security ZoneThe ingress security zone of the packet that triggered the event. Only this security zone field is populated in a passive deployment. Egress Security ZoneThe egress security zone of the packet that triggered the event. This field is not populated in a passive deployments DomainThe domain where the managed device belongs. This field is only present if you have ever configured the Firepower Management Center for multitenancy. DeviceThe managed device where the access control policy was deployed. Security ContextThe metadata identifying the virtual firewall group through which the traffic passed. Note that the system only populates this field for ASA FirePOWER in multiple context mode. Ingress InterfaceThe ingress interface of the packet that triggered the event. Only this interface column is populated for a passive interface. Egress InterfaceFor an inline set, the egress interface of the packet that triggered the event. Source/Destination IPThe host IP address or domain name where the packet that triggered the event (source) originated, or the target (destination) host of the traffic that triggered the event. Source Port/ICMP TypeSource port of the packet that triggered the event. For ICMP traffic, where there is no port number, the system displays the ICMP type. Destination Port/ICMP CodeThe port number for the host receiving the traffic. For ICMP traffic, where there is no port number, the system displays the ICMP code. Email HeadersThe data that was extracted from the email header. Note that email headers do not appear in the table view of intrusion events, but you can use email header data as a search criterion. To associate email headers with intrusion events for SMTP traffic, you must enable the SMTP preprocessor Log Headers option. For rule-based events, this row appears when email data is extracted. HTTP HostnameThe host name, if present, extracted from the HTTP request Host header. This row displays the complete host name, up to 256 bytes. You can expand the complete host name if it is longer than a single row. To display host names, you must enable the HTTP Inspect preprocessor Log Hostname option. Note that HTTP request packets do not always include a host name. For rule-based events, this row appears when the packet contains the HTTP host name or the HTTP URI. HTTP URIThe raw URI, if present, associated with the HTTP request packet that triggered the intrusion event. This row displays the complete URI, up to 2048 bytes. You can expand the complete URI if it is longer than a single row. To display the URI, you must enable the HTTP Inspect preprocessor Log URI option. Note that HTTP request packets do not always include a URI. For rule-based events, this row appears when the packet contains the HTTP host name or the HTTP URI. To see the associated HTTP URI in intrusion events triggered by HTTP responses, you should configure HTTP server ports in the Perform Stream Reassembly on Both Ports option; note, however, that this increases resource demands for traffic reassembly. Intrusion PolicyThe intrusion policy, if present, where the intrusion, preprocessor, or decoder rule that generated the intrusion event was enabled. You can choose an intrusion policy as the default action for an access control policy or associate an intrusion policy with an access control rule. Access Control PolicyThe access control policy that includes the intrusion policy where the intrusion, preprocessor, or decoder rule that generated the event is enabled. Access Control RuleThe access control rule associated with an intrusion rule that generated the event. Default Action indicates that the intrusion policy where the rule is enabled is not associated with an access control rule but, instead, is configured as the default action of the access control policy. RuleFor standard text rule events, the rule that generated the event. Note that if the event is based on a shared object rule, a decoder, or a preprocessor, the rule is not available. Because rule data may contain sensitive information about your network, administrators may toggle users’ ability to view rule information in the packet view with the View Local Rules permission in the user role editor. ActionsFor standard text and custom rule events, expand Actions to take any of the following actions on the rule that triggered the event:
Note that if the event is based on a shared object rule, a decoder, or a preprocessor, the rule is not available. Configuring Intrusion Rules within the Packet ViewWithin the packet view of an intrusion event, you can take several actions on the rule that triggered the event. Note that if the event is based on a shared object rule, a decoder, or a preprocessor, the rule is not available.
Setting Threshold Options within the Packet ViewYou can control the number of events that are generated per rule over time by setting the threshold options in the packet view of an intrusion event. You can set threshold options in all policies that you can edit locally or, when it can be edited locally, only in the in the current policy (that is, the policy that caused the event to be generated).
Setting Suppression Options within the Packet ViewYou can use the suppression options to suppress intrusion events altogether, or based on the source or destination IP address. You can set suppression options in all policies that you can edit locally. Alternately, you can set suppression options only in the current policy (that is, the policy that generated the event) when the current policy can be edited locally.
Frame Information FieldsOn the packet view, click the arrow next to Frame to view information about the captured frame. The packet view may display a single frame or multiple frames. Each frame provides information about an individual network packet. You would see multiple frames, for example, in the case of tagged packets or packets in reassembled TCP streams. Frame nThe captured frame, where n is 1 for single-frame packets and the incremental frame number for multi-frame packets. The number of captured bytes in the frame is appended to the frame number. Arrival TimeThe date and time the frame was captured. Time delta from previous captured frameFor multi-frame packets, the elapsed time since the previous frame was captured. Time delta from previous displayed frameFor multi-frame packets, the elapsed time since the previous frame was displayed. Time since reference or first frameFor multi-frame packets, the elapsed time since the first frame was captured. Frame NumberThe incremental frame number. Frame LengthThe length of the frame in bytes. Capture LengthThe length of the captured frame in bytes. Frame is markedWhether the frame is marked (true or false). Protocols in frameThe protocols included in the frame. Data Link Layer Information FieldsOn the packet view, click the arrow next to the data link layer protocol (for example, Ethernet II) to view the data link layer information about the packet, which contains the 48-bit media access control (MAC) addresses for the source and destination hosts. It may also display other information about the packet, depending on the hardware protocol.
The packet view reflects the protocol used at the data link layer. The following listing describes the information you might see for an Ethernet II or IEEE 802.3 Ethernet packet in the packet view. DestinationThe MAC address for the destination host.
SourceThe MAC address for the source host. TypeFor Ethernet II packets, the type of packet that is encapsulated in the Ethernet frame; for example, IPv6 or ARP datagrams. Note that this item only appears for Ethernet II packets. LengthFor IEEE 802.3 Ethernet packets, the total length of the packet, in bytes, not including the checksum. Note that this item only appears for IEEE 802.3 Ethernet packets. Viewing Network Layer InformationProcedureOn the packet view, click the arrow next to the network layer protocol (for example, Internet Protocol) to view more detailed information about network layer information related to the packet.
IPv4 Network Layer Information FieldsThe following listing describes protocol-specific information that might appear in an IPv4 packet. The Internet Protocol version number. The number of bytes in the header, including any IP options. An IP header with no options is 20 bytes long. The values for differentiated services that indicate how the sending host supports Explicit Congestion Notification (ECN):
The length of the IP packet, in bytes, minus the IP header. The value that uniquely identifies an IP datagram sent by the source host. This value is used to trace fragments of the same datagram. The values that control IP fragmentation, where: values for the Last Fragment flag indicate whether there are more fragments associated with the datagram:
values for the Don’t Fragment flag control whether the datagram can be fragmented:
The value for the fragment offset from the beginning of the datagram. The remaining number of hops that the datagram can make between routers before the datagram expires. The transport protocol that is encapsulated in the IP datagram; for example, ICMP, IGMP, TCP, or UDP. The indicator for whether the IP checksum is valid. If the checksum is invalid, the datagram may have been corrupted during transit or may be being used in an intrusion evasion attempt. The IP address or domain name for the source (or destination) host. Note that to display the domain name, you must enable IP address resolution. Click the address or domain name to view the context menu, then select Whois to do a whois search on the host, View Host Profile to view host information, or choose an option to add the address to a global Block list or Do-Not-Block list. IPv6 Network Layer Information FieldsThe following listing describes protocol-specific information that might appear in an IPv6 packet. An experimental 8-bit field in the IPv6 header for identifying IPv6 packet classes or priorities similar to the differentiated services functionality provided for IPv4. When unused, this field is set to zero. A optional 20-bit IPv6 hexadecimal value 1 to FFFFF that identifies a special flow such as non-default quality of service or real-time service. When unused, this field is set to zero. A 16-bit field identifying the number of octets in the IPv6 payload, which is comprised of all of the packet following the IPv6 header, including any extension headers. An 8-bit field identifying the type of header immediately following the IPv6 header, using the same values as the IPv4 Protocol field. An 8-bit decimal integer that each node that forwards the packet decrements by one. The packet is discarded if the decremented value reaches zero. The 128-bit IPv6 address for the source host. The 128-bit IPv6 address for the destination host. Viewing Transport Layer InformationProcedure
TCP Packet View FieldsThis section describes the protocol-specific information for a TCP packet. The number that identifies the originating application protocol. The number that identifies the receiving application protocol. The value for the first byte in the current TCP segment, keyed to initial sequence number in the TCP stream. In a response packet, the sequence number of the next packet to send. The TCP acknowledgement, which is keyed to the sequence number of the previously accepted data. The number of bytes in the header. The six bits that indicate the TCP segment’s transmission state:
The amount of unacknowledged data, in bytes, that the receiving host will accept. The indicator for whether the TCP checksum is valid. If the checksum is invalid, the datagram may have been corrupted during transit or may be being used in an in evasion attempt. The position, if present, in the TCP segment where the urgent data ends. Used in conjunction with the U flag. The values, if present, for TCP options. UDP Packet View FieldsThis section describes the protocol-specific information for a UDP packet. The number that identifies the originating application protocol. The number that identifies the receiving application protocol. The combined length of the UDP header and data. The indicator for whether the UDP checksum is valid. If the checksum is invalid, the datagram may have been corrupted during transit. ICMP Packet View FieldsThis section describes the protocol-specific information for an ICMP packet. The type of ICMP message:
The accompanying code for the ICMP message type. ICMP message types 3, 5, 11, and 12 have corresponding codes as described in RFC 792. The indicator for whether the ICMP checksum is valid. If the checksum is invalid, the datagram may have been corrupted during transit. Viewing Packet Byte InformationProcedureOn the packet view, click the arrow next to Packet Bytes to view hexadecimal and ASCII versions of the bytes that comprise the packet. If the system decrypted traffic, you can view the decrypted packet bytes. Internally Sourced Intrusion EventsIntrusion events coming from internal sources indicate a compromised host on your network. If the source IP address is on your network, this is a sign that you shoud investigate this host. The Intrusion Events ClipboardThe clipboard is a holding area where you can copy intrusion events from any of the intrusion event views. The contents of the clipboard are sorted by the date and time that the events were generated. After you add intrusion events to the clipboard, you can delete them from the clipboard as well as generate reports on the contents of the clipboard. You can also add intrusion events from the clipboard to incidents, which are compilations of events that you suspect are involved in a possible violation of your security policies. Generating Clipboard ReportsYou can generate a report for the events on the clipboard just as you would from any of the event views. Before you begin
Procedure
Deleting Events from the ClipboardIf you have intrusion events on the clipboard that you do not want to add to an incident, you can delete the events.
Procedure
Viewing Intrusion Event StatisticsThe Intrusion Event Statistics page provides you with a quick summary of the current state of your appliance and any intrusion events generated for your network. Each of the IP addresses, ports, protocols, event messages, and so on shown on the page is a link. Click any link to view the associated event information. For example, if one of the top 10 destination ports is 80 (http)/tcp, clicking that link displays the first page in the default intrusion events workflow, and lists the events targeting that port. Note that only the events (and the managed devices that generate events) in the current time range appear. Also, intrusion events that you have marked reviewed continue to appear in the statistics. For example, if the current time range is the past hour but the first event was generated five hours ago, when you click the First Event link, the resulting event pages will not show the event until you change the time range. In a multidomain deployment, you can view data for the current domain and for any descendant domains. You cannot view data from higher level or sibling domains. Procedure
Host StatisticsThe Host Statistics section of the Intrusion Event Statistics page provides information about the appliance itself. On the Firepower Management Center, this section also provides information about any managed devices. This information includes the following: TimeThe current time on the appliance. UptimeThe number of days, hours, and minutes since the appliance itself was restarted. On the Firepower Management Center, the uptime also shows the last time each managed device was rebooted, the number of users logged in, and the load average. Disk UsageThe percentage of the disk that is being used. Memory UsageThe percentage of system memory that is being used. Load AverageThe average number of processes in the CPU queue for the past 1 minute, 5 minutes, and 15 minutes. Event OverviewThe Event Overview section of the Intrusion Event Statistics page provides an overview of the information in the intrusion event database. These statistics include the following: EventsThe number of events in the intrusion event database. Events in Time RangeThe currently selected time range as well as the number and percentage of events from the database that fall within the time range. First EventThe event message for the first event in the event database. Last EventThe event message for the last event in the event database.
Event StatisticsThe Event Statistics section of the Intrusion Event Statistics page provides more specific information about of the information in the intrusion event database. This information includes details on:
Viewing Intrusion Event Performance GraphsThe intrusion event performance page allows you to generate graphs that depict performance statistics for intrusion events over a specific period of time for a Firepower Management Center or a managed device. Graphs can be generated to reflect number of intrusion events per second, number of megabits per second, average number of bytes per packet, the percent of packets uninspected by Snort, and the number of packets blocked as the result of TCP normalization. These graphs can show statistics for the last hour, last day, last week, or last month of operation.
In a multidomain deployment, you can view data for the current domain and for any descendant domains. You cannot view data from higher level or sibling domains. Procedure
Intrusion Event Performance Statistics Graph TypesThe following table lists the available graph types. Note that graph types display differently if they are populated with data affected by the network analysis policy Inline Mode setting. If Inline Mode is disabled, the graph types marked with an asterisk (*) in the web interface (a yes in the column below) populate with data about the traffic the system would have modified or dropped if Inline Mode was enabled.. Table 7. Intrusion Event Performance Graph Types
Viewing Intrusion Event GraphsThe Firepower System provides graphs that show you intrusion event trends over time. You can generate intrusion event graphs over time ranging from the last hour to the last month, for one or all managed devices. In a multidomain deployment, you can view data for the current domain and for any descendant domains. You cannot view data from higher level or sibling domains. Procedure
History for Intrusion Events
What protocol is used to collect information about traffic traversing a network?NetFlow is a protocol used to collect metadata on IP traffic flows traversing a network device. Developed by Cisco Systems, NetFlow is used to record metadata about IP traffic flows traversing a network device such as a router, switch, or host.
Which tool can perform real time traffic and port analysis and can also detect port scans fingerprinting and buffer overflow attacks select one nmap snort NetFlow Siem?Snort is an open source intrusion protection system (IPS) that is capable of performing real-time traffic and port analysis, packet logging, content searching and matching, as well as detecting probes, attacks, port scans, fingerprinting, and buffer overflow attacks.
What name is given to a device that controls or filters traffic going in or out of the network IPS VPN router firewall?A firewall is a network security device that monitors incoming and outgoing network traffic and decides whether to allow or block specific traffic based on a defined set of security rules.
Which tool can identify malicious traffic by comparing packet?A signature-based intrusion detection system (SIDS) monitors all the packets traversing the network and compares them against a database of attack signatures or attributes of known malicious threats, much like antivirus software.
|