Bro NIDs rules

Bro NIDs rules

Creation Time: Updated:
Article attributes: original
Article submitted: stardust (stardust_at_xfocus.org)

Introduction of Rule Mechanism
--------------

From the initial design perspective, the implementation method of BrO NIDS is similar to NFR. It implements a script parsing engine and provides users with a complete programming interface. Users can analyze network traffic by writing scripts, this design gives users great flexibility and can theoretically achieve fine-grained analysis and processing. However, writing, debugging, and maintaining scripts is a very troublesome process, which takes a considerable amount of time. In addition, for most single packet-based attack detection attacks, complex scripts are not required, therefore, in Versions later than bro 0.8, the rule engine is introduced to detect network events by specifying packet features. The packet feature definition is stored in the Rule file, and bro can load the rule file according to the configuration at startup (for how to enable rule support and load the rule file, see "Bro NIDs installation and configuration"). generates alarms for packets that conform to the feature definitions.

Format of Rule text
--------------

Bro rules are defined in plain text format. The format of a single rule is as follows:

Signature ID {

Rule Option List

}

The "signature" string is the rule-defined keyword starting with the header of each rule-defined block. ID is the unique tag string defined for this rule, the specific definitions of various options related to the rule are in curly brackets. The relationship between the options is also. Each option definition occupies a row. The format of each row varies with the option type in the following two ways:

A. Option name operator Parameter Value List
B. Option name parameter value list
C. Option name Mode

Rule operators and options
------------------

Bro supports the following operators:

"<=" Less than or equal
"> =" Greater than or equal
"<" Less
">" Greater
"=" Equivalent to "="
"=" Equal
"! = "Not equal

Different option name pairs should have different parameter value sets, such as corresponding "IP-Proto" option names, the allowed parameter values are "ip", "TCP", "UDP", and "ICMP". Some option names allow multiple parameter values separated by commas, is or.

The pattern is the target string used for matching. Generally, it can be a regular expression.

Currently, bro supports two types of options: Condition and action. There are four types of conditions: Header, content, dependency, and context.

Header condition: used to filter information that can be extracted from the header by checking the protocol type, port, and address of the message. The predefined option names are as follows:

IP-Proto
Meaning: protocol type encapsulated in the IP package
Format: IP-Proto operator Parameter Value List
Allowed parameter values: IP, TCP, UDP, and ICMP

IP-Options
Description: IP address Baotou Option
Format: IP-options Parameter Value List
Allowed parameter values: lsrr, lsrre, RR, and ssrr

Src-IP
Meaning: Source Address of the IP package
Format: Src-IP operator Parameter Value List
Allowed parameter value: IP address, which can be marked with a network.

DST-IP
Meaning: Destination IP address
Format: DST-IP operator Parameter Value List
Allowed parameter value: IP address, which can be marked with a network.

Src-Port
Meaning: source port of a TCP or UDP Packet
Format: Src-port operator Parameter Value List
Allowed parameter value: port value

DST-Port
Description: Destination Port of a TCP or UDP Packet
Format: DST-port operator Parameter Value List
Allowed parameter value: port value

For other header fields in the IP header, you can use the header option name to specify the offset and length of the data in the header for matching:

Header proto [offset: length] OPERATOR parameter value

Therefore, header IP addresses [16: 4] = 1.2.3.4/16, 5.6.7.8/24 are equivalent
DST-IP = 1.2.3.4/16, 5.6.7.8/24

Content condition: used to filter packets by checking their net loads. Currently, the following options are supported:

Payload
Meaning: Net Load of TCP or UDP Packets
Format: payload Mode
Allowed parameter values: Regular Expressions

Payload-size
Meaning: The Net Load Length of a TCP or UDP Packet
Format: payload-size operator parameter value
Allowed parameter values: Numbers of Positive Integers

HTTP
Meaning: Net Load of HTTP packets
Format: http mode
Allowed parameter values: Regular Expressions

FTP
Meaning: Net loading of FTP packets
Format: FTP MODE
Allowed parameter values: Regular Expressions

Finger
Meaning: Net Load of finger protocol packets
Format: Finger Mode
Allowed parameter values: Regular Expressions

Dependency condition: Used to associate several rules in the same session and reference the results of other rules in one rule. Currently, the following options are supported:

Requires-Signature
Meaning: The result returned by depending on another rule is true.
Format: requires-signature [!] ID
Allowed parameter value: Rule ID string, limited to the same session, leading "!" Character indicates that the rule on which the dependency is returned must be false.

Requires-reverse-Signature
Meaning: The result returned by other rules that need to match data in the opposite direction in a session is true.
Format: requires-reverse-signature [!] ID
Allowed parameter value: Rule ID string, limited to the same session, leading "!" Character indicates that the rule on which the dependency is returned must be false.

Context condition: used to test the context of rule matching. Currently, the following options are supported:

TCP-state
Meaning: Check whether the TCP session processes the specified status when the rule is matched.
Format: TCP-state parameter value list
Allowed parameter values: Established, originator, responder, stateless

Eval
Meaning: Execute the function provided by a Policy script to obtain the success or failure mark returned.
Format: A function name of the eval policy script
Allowed parameter value: name of a function of the loaded policy script. A success or failure is returned.

Same-IP
Meaning: Check whether the IP package's source and destination addresses are the same
Format: Same-IP
Allowed parameter value: No parameter is required

Action option: the action to be executed when all the condition options of the rule match. Currently, only one option name is supported:

Event
Description: generates an alarm event.
Format: Event msg
Allowed parameter value: MSG is the string passed to the log

Rule instance:

The signature s2b-356-5 {
IP-Proto = TCP
DST-Port = 21
Event "FTP Passwd Retrieval Attempt"
TCP-State established, originator
Payload/. * [RR] [EE] [TT] [RR]/
Payload/[/x20/x09/x0b //.] * passwd [/x20/x09/x0b] * $/
Requires-reverse-signature! Ftp_server_error
}

This rule matches whether the client request sent to TCP/21 contains a command to obtain the passwd file, and the server returns a success, the rule generates an alarm, record "FTP Passwd Retrieval Attempt" in the log ".

Features of BrO rules
-------------

Compared with the new version of Snort, bro rules have no special matching options (such as payload and payload-size) in the content condition class, the matching options provided by the new snort version are greatly improved compared with the previous ones. By introducing the mechanism of relative displacement and real-time jump Matching Based on package data, in fact, Snort implements some protocol decoding capabilities flexibly. For details, refer to "snort 2. the article "Improvement of Search Rule options in the X Data area. Therefore, from the matching options of the content condition class, bro rule options are far less flexible than snort, however, the dependency and context-related options provided by BrO reflect the more meaningful advanced features of BrO rules.

The requires-signature dependency option makes it possible to associate several request sequences required for multiple attacks not in the same packet in the same session.
The eval context option allows the rule to call pre-defined function functions in the Policy script, thus providing almost unlimited functions.

The above two points are provided in bro: an open source advanced NIDs system.

The requires-reverse-signature dependency option makes requests and responses associated with the same session possible:

For example:

--------------------------------------------------------------------------
The signature s2b-654-13 {
IP-Proto = TCP
DST-Port = 25
Event "smtp rcpt to Overflow"
TCP-State established, originator
Payload/(^) | (/n + )) [RR] [CC] [PP] [TT] [TT] [oo] [/x20/x09/x0b] [^/n] {300 }/
Requires-reverse-signature! Smtp_server_fail
}

Signature smtp_server_fail {
IP-Proto = TCP
Src-Port = 25
Payload/. 5 [0-9] [0-9] ../# 5xx permanent failure
TCP-State established
}
--------------------------------------------------------------------------

This rule detects the RCPT command with super-long parameters and checks the server's response. If the server does not respond to an error, an alarm is generated. This type of direct association can easily determine an attack and its results.

Rule-related support policy scripts
--------------------------

When configuring support for Bro enabling rule matching, You need to specify several necessary policy scripts to load, mainly including the following four:

Signatures. Bro
Operations that match the processing rule are performed according to the corresponding action set by each rule, such as generating alarms, writing logs, recording data, and executing other predefined functions.

Sig-functions.bro
Predefines some simple functions that determine the application type and version based on the message content. These function functions may be called through the eval option in the Rule text. For example, if the rule matches an overflow attack on the IIS server, you can call the isiis function in the rule to check whether the target is an IIS server. If not, the target is not affected by the attack, this can effectively reduce the number of secondary alarms.

Sig-action.bro
An alert ID corresponds to the table in which actions should be taken. Rules not in the table are processed according to the action set by default. If special actions are required for a rule, you can add corresponding entries in the table.

Sig-addendum.sig
Define some matching conditions that may often be referenced by other rules. For example, you can check the Response codes of common network protocols such as HTTP, SMTP, and pop to determine whether the request is successful, many other CGI Attack detection rules can reference these predefined rules to roughly confirm the attack results and take different actions based on the situation.

Users can also write their own policy scripts to expand many features, and even detect some unknown attacks based on traffic and connection conditions, these require us to master the most complex and flexible tool policy scripts of bro, which will be introduced in the next series.