Cisco Cisco Firepower Management Center 4000
32-38
FireSIGHT System User Guide
Chapter 32 Understanding and Writing Intrusion Rules
Understanding Keywords and Arguments in Rules
You can use the
metadata
keyword to add descriptive information to a rule. You can use the information
you add to organize or identify rules in ways that suit your needs, and to search for rules.
The system validates metadata based on the format:
key value
where
key
and
value
provide a combined description separated by a space.
This is the format used by the Cisco Vulnerability Research Team (VRT) for adding metadata to rules
provided by Cisco.
provided by Cisco.
Alternatively, you can also use the format:
key=value
For example, you could use the
key value
format to identify rules by author and date, using a category
and sub-category as follows:
author SnortGuru_20050406
You can use multiple
metadata
keywords in a rule. You can also use commas to separate multiple
key value
statements in a single
metadata
keyword, as seen in the following example:
author SnortGuru_20050406, revised_by SnortUser1_20050707,
revised_by SnortUser2_20061003, revised_by
SnortUser1_20070123
You are not limited to using a
key value
or
key=value
format; however, you should be aware of
limitations resulting from validation based on these formats.
Avoiding Restricted Characters
License:
Protection
Note the following character restrictions:
•
Do not use a semicolon (;) or colon (:) in a
metadata
keyword.
•
Be aware when using commas that the system interprets a comma as a separator for multiple
key value
or
key=value
statements. For example:
key value, key value, key value
•
Be aware when using the equal to (=) character or space character that the system interprets these
characters as separators between
characters as separators between
key
and
value
. For example:
key value
key=value
All other characters are permitted.
Adding service Metadata
License:
Protection
The rules engine applies active rules with
service
metadata that match the application protocol
information for the host in a packet to analyze and process traffic. If it does not match, the system does
not apply the rule to the traffic. If a host does not have application protocol information, or if the rule
does not have
not apply the rule to the traffic. If a host does not have application protocol information, or if the rule
does not have
service
metadata, the system checks the port in the traffic against the port in the rule to
determine whether to apply the rule to the traffic.
The following diagram illustrates matching a rule to traffic based on application information: