This topic covers the following information:
Structure of a custom IPS rules file
Structure of a custom IPS rule
Example of a custom IPS rule
Custom IPS rule header
Custom IPS rule body
Structure of a custom IPS rules file
The IPS-enabled rules engine supports Snort 2.9 rule format, with certain Trellix-specific requirements and options defined in this section. You can import custom IPS rules into an IPS-enabled platform by uploading an ASCII text or a .csv file that contains one or more custom IPS rules. Within the ASCII text file, rules are delimited by a pair of CR‑LF characters.
Structure of a custom IPS rule
A custom IPS rule consists of a rule header followed by a rule body:
rule-header (rule-body)The rule body is enclosed in parentheses [ ( ) ] and consists of required and optional rule options. Individual rule options are terminated by a semicolon ( ; ).
Note
Custom IPS rules must conform to Snort 2.9 rule syntax.
Example of a custom IPS rule
The following is an example of a custom IPS rule. Line breaks are inserted for readability only:
alert tcp any any -> any any (
sid:85000001; rev:1;
msg:"Mozilla Products Malformed GIF Buffer Overflow";
flow:to_server;
content:"test"; nocase;
reference:cve,cve-2012-0671; reference:osvdb,81942;
reference:secunia,sa47447;
reference:url,http://www.fireeye.com;
protocol:"http";
attack_target:"client";
category:"exploit";
sub_category:"code_execution";
severity:6;
action:"noblock";)As entered into an custom IPS rules file or in the custom IPS rules editor, the same rule would appear as follows:
alert tcp any any -> any any (sid:85000001; rev:1;msg:"Mozilla Products Malformed GIF Buffer Overflow"; flow:to_server;content:"test"; nocase;reference:cve,cve-2012-0671; reference:osvdb,81942; reference:secunia,sa47447; reference:url,http://www.fireeye.com; protocol:"http"; attack_target:"client"; category:"exploit"; sub_category:"code_execution"; severity:6; action:"noblock";)Custom IPS rule header
The header of a custom IPS rule specifies the action to perform, the protocol to which the rule applies, and the source and destination addresses and ports.
Syntax
ruleAction packetProtocol srcIP srcPort directionalOp dstIP dstPortParameters
ruleAction
Action to be taken on a packet that matches the rule conditions:
alert - Send an alert message.
Note
NOTE: alert is the only accepted value for ruleAction. .
packetProtocol
Type of packet to be analyzed:
icmp—Internet Control Message Protocol
ip—Internet Protocol
tcp—Transmission Control Protocol
udp—User Datagram Protocol
srcIP
Source IP address match criteria:
address - Match the single specified numeric address.
addressA:addressB - Match the range of IP addresses.
addressA: - Match IP addresses above addressA.
:addressB - Match IP addresses below addressB
any—Match any IP address.
srcPort
Source port number match criteria:
portNum—Match the specified source port number.
!portNum—Do not match the specified source port number.
portNumA:portNumB—Match source port numbers within the range.
!portNumA:portNumB—Do not match source port numbers within the range.
any—Match any port number.
directionalOp
Direction of traffic to be matched:
–>—Match unidirectional traffic from source machine to destination machine only.
<>—Match bidirectional traffic.
dstIP
Destination IP address match criteria:
address—Match the single specified numeric address.
addressA:addressB—Match the range of IP addresses.
addressA:—Match IP addresses above addressA.
:addressB—Match IP addresses below addressB.
any—Match any IP address.
dstPort
Destination port number match criteria:
portNum—Match the specified destination port number.
!portNum—Do not match the specified destination port number.
portNumA:portNumB—Match destination port numbers within the range.
!portNumA:portNumB—Do not match destination port numbers within the range.
any—Match any port number.
Custom IPS rule body
The body of a custom IPS rule consists of required and optional rule options that follow the same syntax rules as Snort 2.9 rules.
Syntax
(ipsRuleOption; [ipsRuleOption;])Important
A custom IPS rule must contain specific Snort 2.9 rule options, and some Trellix-defined rule options are recommended. Therefore, custom IPS rule body parameters are described in three sections:
• Required Snort 2.9 rule options
• Recommended -Specific rule options
• Recommended Snort 2.9 rule options
Required Snort 2.9 rule options
A custom IPS rule must include the following Snort 2.9 rule options:
sid:signatureId; [rev:signatureRevision;]Uniquely identifies a custom IPS rule:
signatureId—Numeric ID from 85000000 through 85099999. No default value.
signatureRevision—(Optional) A number that uniquely identifies the signature.
If the revision is not specified, the default value is 1.
If a custom IPS rule body does not specify this option, the rule is rejected.
Important
Except to re-create a particular custom IPS rule, do not re‑use the signature-ID of a previously imported IPS rule, even if you deleted the previous rule and verified that the rule no longer generates IPS events. The platform user interface can display misleading IPS event information if you import a custom IPS rule that re‑uses the signature-ID of a different IPS rule that you previously imported, applied to a monitoring interface, and deleted.
msg:"messageText";Message to be used with logging or alerts for this rule. Up to 255 ASCII characters enclosed in double quotes. Valid characters are alphanumeric characters, spaces, a period (.), hyphen (-), or an underscore (_). No default value. Use the backslash (\) as an escape character as needed to avoid confusing the rule parser.
Important
Messages that begin with "FE" are reserved messages. Using "FE" as the first two characters of the message string can cause unintended results
Recommended Trellix-specific rule options
The following Trellix-specific options for custom IPS rules are not required but are recommended.
Note
The IPS-enabled rules engine uses default values for any Trellix-specific rule options that are not specified in the rule body.
action:
action:blockAction;Blocking action that the IPS rules engine is to take, in addition to generating an IPS event:
block—Drop the current packet and all subsequent packets in the flow.
noblock—(Default) Allow current packet and subsequent packets in the flow to pass.
blockable—Same as noblock, but enables you to force blocking on a per-rule basis.
See Configuring action overrides to selected IPS rules.
attack_target:target;Match traffic flows that target the specified host type. You can specify more than one attack target option.
client—(Default) Match flows that target a client.
server—Match flows that target a server.
All IPS policies specify one or more attack target attributes.
protocol:protocol;Match flows that use the specified protocol as the attack vector.
protocol—Name of the presentation-layer protocol associated with the rule.
Up to 32 characters long.
Example: http
Default value is unknown.
Note
To enable the rule to be selected by a custom IPS policy that specifies one or more protocol match attributes, include one or more instances of this rule option.
severity:level;level - Severity of the vulnerability that the rule detects. Numeric value from 1 to 10.
Default value is 10.
category:categoryName; [sub_category:categorySubName;]Specify the type of attack vulnerability that the rule detects.
categoryName—Category of the vulnerability that the rule detects.
categorySubName—Subcategory of the vulnerability category specified.
For more information, see Attributes of IPS policies.
Recommended Snort 2.9 rule options
The following Snort 2.9 rule options are not required in custom IPS rules but are recommended.
content:[!]"contentString"; [nocase;]Match when the specified content is present in any part of the packet payload. The content can contain mixed text and binary data. Binary data is represented as hexadecimal numbers enclosed within pipe characters (|). No default value. A custom IPS rule can specify multiple content options.
!—(Optional) Match on packets that do not contain the specified content.
nocase—(Optional) When searching for the specified pattern, ignore case.
flow:[ (established | not_established | stateless) ]
[, (to_client | to_server | from_client | from_server) ]
[, (no_stream | only_stream) ]
[, (no_frag | only_frag) ];
Used in conjunction with TCP stream reassembly to apply rules only to certain directions of the traffic flow:
to_client—Trigger on server responses from A to B.
to_server—Trigger on client requests from A to B.
from_client—Trigger on client requests from A to B.
from_server—Trigger on server responses from A to B.
established—Trigger on established TCP connections only.
not_established—Trigger only when no TCP connection is established.
stateless—Trigger regardless of the state of the stream processor.
no_stream—Do not trigger on rebuilt stream packets.
only_stream—Trigger on rebuilt stream packets only.
no_frag—Do not trigger on rebuilt frag packets.
only_frag—Trigger on rebuilt frag packets only.
reference:idSystem,idAttack; [reference:idSystem,idAttack;]One or more references to vulnerabilities described in external attack identification systems. Referenced vulnerabilities provide additional information about the IPS event generated.
idSystem—Snort rule keyword that identifies the external attack identification system.
idAttack—Vulnerability identifier defined in the attack identification system database.
The following table lists the URL prefixes for the attack identification systems supported by Snort 2.9 rules:
idSystem | URL prefix |
|---|---|
bugtraq | http://www.securityfocus.com/bid/ |
cve | http://cve.mitre.org/cgi-bin/cvename.cgi?name= |
mcafee | http://vil.nai.com/vil/content/v_ |
msb | http://technet.microsoft.com/en-us/security/bulletin/ |
nessus | http://cgi.nessus.org/plugins/dump.php3?id= |
osvdb | http://osvdb.org/show/osvdb/ |
secunia | http://secunia.com/community/advisories/ |
url | http:// |
author:"authorName";authorName—Identifies the author of the rule.
Default value is "" (empty string). Example: author:"John Q. Doe";
release_date:dateReleased;dateReleased—Date the rule was released, specified in mm-dd-yyyy format. Default value is today's date.
modify_date:dateModified;dateModified—Date the rule was modified, specified in mm-dd-yyyy format. Default value is today's date.