You can create a custom intrusion rule by importing a local rule file. The rule file can either have a .txt or .rules extension. The system saves the custom rule in the local rule category, regardless of the method you used to create it. A
custom rule must belong to a rule group. However, a custom rule can be a part of two or more groups as well.
When you create a custom intrusion rule, the system assigns it a unique rule number, which has the format GID:SID:Rev. The elements of this number are:
-
GID—Generator ID. For custom rules, it is not necessary to specify the GID. The system automatically generates the GID based
on whether you are in the Global domain or a sub-domain while uploading the rules. For all standard text rules, this value
is 2000 for a Global domain.
-
SID—Snort ID. Indicates whether the rule is a local rule of a system rule. When you create a new rule, assign a unique SID to
the rule.
SID numbers for local rules start at 1000000, and the SID for each new local rule is incremented by one.
-
Rev—The revision number. For a new rule, the revision number is one. Each time you modify a custom rule the revision number should
be incremented by one.
In a custom standard text rule, you set the rule header settings and the rule keywords and arguments. You can use the rule
header settings to focus the rule to only match traffic using a specific protocol and traveling to or from specific IP addresses
or ports.
Note
|
-
Snort 3 custom rules cannot be edited. Ensure that custom rules have a valid classification message for classtype within the rule text. If you import a rule without a classification or wrong classification, then delete and recreate the
rule.
-
You can create custom intrusion rules using Snort 3. However, support for tuning and troubleshooting these rules is not available
currently.
|
Sensitive Data Detection in Snort 3
Sensitive data such as social security numbers, credit card numbers, emails, and so on may be leaked onto the internet, intentionally
or accidentally. Sensitive data detection is used to detect and generate events on possible sensitive data leakage. Events
are generated only if there is a transfer of significant amount of Personally Identifiable Information (PII) data. Sensitive
data detection can mask PII in the output of events.
sd_pattern Option
Use the sd_pattern IPS option to detect and filter PII. This information includes credit card numbers, U.S. Social Security numbers, phone numbers,
and email addresses. A regular expression (regex) syntax is available for defining your own PII.
The sd_pattern option has the following settings:
-
Pattern—An implicit, required setting that specifies the regular expression to look for in the PDU. The regex must be written
in PCRE syntax.
-
Threshold—An explicit, optional setting that specifies the number of matches in the PDU required to generate an event.
The sd_pattern as IPS rule option is available in Snort with no requirements for additional inspectors. The rule option’s syntax is:
sd_pattern: "<pattern>"[, threshold <count>];
For example:
sd_pattern:"credit_card", threshold 2;
Built-in Patterns
There are five built-in patterns for sensitive data. To use the built-in patterns in the "pattern" setting, you must specify
the name of the PII type that needs to be matched and the necessary regex is substituted for it. The PII name and regex mappings
or patterns are described as follows:
-
credit_card—
\d{4}\D?\d{4}\D?\d{2}\D?\d{2}\D?\d{3,4}
-
us_social—
[0-8]\d{2}-\d{2}-\d{4}
-
us_social_nodashes—
[0-8]\d{8}
-
Email—
[a-zA-Z0-9!#$%&'*+\/=?^_`{|}~-]+(?:\.[a-zA-Z0-9!#$%&'*+\/=?^_`{|}~-]+)*@(?:[a-zA-Z0-9]
(?:[a-zA-Z0-9-]*[a-zA-Z0-9])?\.)+[a-zA-Z0-9](?:[a-zA-Z0-9-]*[a-zA-Z0-9])?
-
us_phone—
(?:\+?1[-\.\s]?)?\(?([2-9][0-8]\d)\)?[-\.\s]([2-9]\d{2})[-\.\s](\d{4})
|
PII Name
|
Pattern
|
|
credit_card
|
\d{4}\D?\d{4}\D?\d{2}\D?\d{2}\D?\d{3,4}
|
|
us_social
|
[0-8]\d{2}-\d{2}-\d{4}
|
|
us_social_nodashes
|
[0-8]\d{8}
|
|
Email
|
[a-zA-Z0-9!#$%&'*+\/=?^_`{|}~-]+(?:\.[a-zA-Z0-9!#$%&'*+\/=?^_`{|}~-]+)
*@(?:[a-zA-Z0-9](?:[a-zA-Z0-9-]*[a-zA-Z0-9])?\.)+[a-zA-Z0-9](?:[a-zA-Z0-9-]*[a-zA-Z0-9])?
|
|
us_phone
|
(?:\+?1[-\.\s]?)?\(?([2-9][0-8]\d)\)?[-\.\s]([2-9]\d{2})[-\.\s](\d{4})
|
Masking for data matching these patterns only work with system-provided rules or built-in patterns for Credit Cards, U.S.
Social Security numbers, emails, and U.S. phone numbers. Masking does not work for custom rules or user-defined PII patterns.
Rules are available in the Lightweight Security Package (LSP) for sensitive data, gid:13. By default, they are not enabled
in any system-provided policy.
The sensitive data rules in LSP cover all built-in patterns and have the following threshold values:
-
credit_card: 2
-
us_social: 2
-
us_social_nodashes: 20
-
email: 20
-
us_phone: 20
You can use the sd_pattern option to create custom rules and modify existing rules. To do this, use the Snort 3 intrusion
policy interface.
An example of a rule with sd_pattern with a custom pattern and threshold:
alert tcp (sid: 1000000001; sd_pattern:"[\w-\.]+@([\w-]+\.)+[\w-]{2,4}",threshold 4; msg: "email, threshold 4")
Examples
An example of custom rules using sensitive data detection:
Rule with built-in pattern:
alert tcp (
msg:"SENSITIVE-DATA Email";
flow:only_stream;
pkt_data;
sd_pattern:"email", threshold 5;
service:http, smtp, ftp-data, imap, pop3;
gid:2000;
sid:1000001;
)
Rule with custom pattern
alert tcp (
msg:"SENSITIVE-DATA US phone numbers";
flow:only_stream;
file_data;
sd_pattern:"+?3?8?(0[\s\.-]\d{2}[\s\.-]\d{3}[\s\.-]\d{2}[\s\.-]\d{2})", threshold 2;
service:http, smtp, ftp-data, imap, pop3;
gid:2000;
sid:1000002;
)
Here are some more examples of complete Snort IPS rules with built-in sensitive data patterns:
-
alert tcp ( sid:1; msg:"Credit Card"; sd_pattern:"credit_card", threshold 2; )
-
alert tcp ( sid:2; msg:"US Social Number"; sd_pattern:"us_social", threshold 2; )
-
alert tcp ( sid:3; msg:"US Social Number No Dashes"; sd_pattern:"us_social_nodashes", threshold 2; )
-
alert tcp ( sid:4; msg:"US Phone Number"; sd_pattern:"us_phone", threshold 2; )
-
alert tcp ( sid:5; msg:"Email"; sd_pattern:"email", threshold 2; )
Disabling data masking is not supported in the Secure Firewall Management Center and Secure Firewall Device Manager.
Feedback