Reproduced The rules of Bro NIDs

the rules of Bro NIDs
Date Created: 2005-09-28 update: 2005-09-28
Article Properties: Original
Article submitted: Stardust (stardust_at_xfocus.org)

Introduction of rule mechanism
--------------

From the initial design point of view, the implementation of Bro NIDs is similar to the NFR, the implementation of a script resolution engine, to provide users with a complete programming interface, the user through the script to analyze the network traffic, such a design can give users a great deal of flexibility, theoretically enough to achieve sophisticated analysis and processing. But the script is written, debugging, maintenance is a rather cumbersome process, takes a considerable amount of time, and for most of the packet based attack detection does not need to write complex scripts, so bro 0.8 version of the introduction of the rule engine, support by specifying the characteristics of the message to detect network events. The message feature definition is stored in the rules file, and Bro can be started by configuring the load rule file (how to open the rule support and loading rule file See "Installation and configuration of Bro NIDs"), and to the description of the identity of the reporting police.


Format of rule text
--------------

The Bro rule definition takes the form of simple plain text, and a single rule is defined in the following format:

Signature ID {

List of rule options

}

The "signature" string defines a keyword for a rule, starting at the head of each rule definition block, a unique tag string defined by this rule, a specific definition of the various options associated with the rule within the curly braces, and a relationship between each option definition. Each option definition typically occupies one row, and the format of each row is two different depending on the type of option:

A. Option name operator parameter values list
B. List of option name parameter values
C. Option name mode


Operators and options for rules
------------------

The bro supported operators are:

"<=" is less than or equal to
">=" is greater than or equal to
"<" is less than
">" is greater than
"=" equals "= ="
"= =" equals
"!=" is not equal to

For different option name pairs should have a different set of parameter values, for example, the corresponding "ip-proto" option name, which allows the parameter value of "IP", "TCP", "UDP", "ICMP", and some option name allows you to specify a comma-separated multiple parameter values, or the relationship between.

A pattern is a target string that is used for matching, and can generally be a regular expression.

Currently bro support options fall into two categories: conditions and actions. The conditions are divided into four categories: head, Content, dependency, context.

Head condition: It is used to filter the information that can be extracted from the head of the message by checking the protocol type, port and address of the message. The most commonly used option names that are currently predefined are:

Ip-proto
Meaning: The type of protocol encapsulated within the IP packet
Format: Ip-proto operator parameter Value list
Allowable parameter values: IP, TCP, UDP, ICMP

Ip-options
Meaning: IP header option
Format: ip-options parameter values list
Allowable parameter values: LSRR, Lsrre, RR, SSRR

Src-ip
Meaning: Source address of IP packet
Format: src-ip operator parameter Value list
Allowed parameter values: IP address, can be tape network tag

Dst-ip
Meaning: Destination address of IP packet
Format: dst-ip operator parameter Value list
Allowed parameter values: IP address, can be tape network tag

Src-port
Meaning: Source port for TCP or UDP packets
Format: src-port operator parameter Value list
Allowable parameter values: Port values

Dst-port
Meaning: Destination port for TCP or UDP packets
Format: dst-port operator parameter Value list
Allowable parameter values: Port values

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 to match:

Header proto[Offset: length] operator parameter value

So header ip[16:4] = = 1.2.3.4/16, 5.6.7.8/24 equivalent to
Dst-ip = = 1.2.3.4/16, 5.6.7.8/24


Content condition: Used to filter by checking the net load of the message. The currently supported option names are:

Payload
Meaning: NET load of TCP or UDP packets
Format: Payload mode
Allowed parameter values: Regular expressions

Payload-size
Meaning: Net load length of TCP or UDP packets
Format: payload-size operator parameter value
Allowable parameter values: number of positive integers

http
Implication: NET load of HTTP protocol messages
Format: HTTP mode
Allowed parameter values: Regular expressions

Ftp
Meaning: NET load of FTP protocol message
Format: FTP mode
Allowed parameter values: Regular expressions

Finger
Meaning: Net load of the Finger protocol message
Format: Finger mode
Allowed parameter values: Regular expressions


Dependency conditions: Used to associate several rules within the same session, referencing the results of other rules within one rule. The currently supported option names are:

Requires-signature
Meaning: a result that relies on some other rule to return is true
Format: requires-signature [!] Id
Allowed parameter values: Rule ID strings, limited to the same session, leading "!" Character words indicate that the dependent rule returns the result needs to be false

Requires-reverse-signature
Meaning: a result that needs to rely on other rules that match data in the opposite direction in one session is true
Format: requires-reverse-signature [!] Id
Allowed parameter values: Rule ID strings, limited to the same session, leading "!" Character words indicate that the dependent rule returns the result needs to be false


Context condition: Used to test the context of a rule match. The currently supported option names are:

Tcp-state
Meaning: Whether the TCP session handles the specified state when the rule matches
Format: tcp-state parameter values list
Allowable parameter values: Established, originator, responder, stateless

Eval
Meaning: Performs a function provided by a policy script to obtain a return success or failure token
Format: The name of a function of the eval policy script
Allowed parameter values: A function name for a loaded policy script that returns success or failure

Same-ip
Meaning: Check that the IP packet's source destination address is the same
Format: Same-ip
Allowed parameter values: no parameters required


Action options: The action that should be performed when the conditional options for the rule match all. Only one option name is currently supported:

Event
Meaning: Generating alarm events
Format: Event msg
Allowed parameter values: MSG is a string passed to the log


Rule instance:

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 the TCP/21 port contains a command operation that attempts to obtain the passwd file, and the server returns successfully, the rule generates an alarm and logs "FTP passwd retrieval attempt" in the log.


The characteristics of Bro rules
-------------

Compared to the new version of Snort, Bro's rules are nothing special in the content-conditional class matching options (payload, payload-size, etc.), and the new version of Snort offers a much better matching option than before, by introducing the mechanism of relative displacement and real-time jump matching by packet data , snort actually has the flexibility to partially decode the protocol, and details can be found in the "Snort 2.x data area search Rule Options Improvement" article. So the flexibility of the bro rule option is far less flexible than snort in terms of matching options from the content criteria class, but the dependencies and contextual options provided by bro reflect the more advanced features of the Bro rules.

The requires-signature dependency option makes it possible to correlate several request sequences for multiple attacks that are not in the same message in the same session.
The Eval contextual selections allow the rule to invoke predefined functional functions in the policy script, thereby extending almost unlimited functionality.

The above two points are illustrated in the article "Bro: An open source advanced NIDs system".

The requires-reverse-signature dependency option makes it possible to associate requests and responses for the same session:

For example:

--------------------------------------------------------------------------
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 an extra long parameter and checks the server's response, generating an alert if the server is not responding incorrectly. This kind of direct correlation can be extremely convenient to judge an attack and its result.


Several support policy scripts related to rules
--------------------------

When configuring bro enabling rule matching support, you need to specify several necessary policy scripts to load, including the following 4:

Signatures.bro
Processing rules are matched operations, depending on the corresponding action set by each rule, perform various operations, such as generating alarms, writing logs, recording data, performing other predetermined functions, etc.

Sig-functions.bro
Predefined to determine the application type and version and other simple functions based on the content of the message, these functions may be invoked through the Eval option in the rule text. For example, the rules match to an overflow attack against an IIS server, in which the Isiis function can be invoked to check if the target is an IIS server, and if not, the target is not affected by the attack and can not generate an alarm, which can effectively reduce the number of secondary alarms.

Sig-action.bro
An alarm ID and corresponding should take action of the corresponding table, not in the list of rules in accordance with the default settings of the action processing, if you require a rule to take a special action, you can add the corresponding entry.

Sig-addendum.sig
Define some matching cases that are often referred to by other rules, for example, by checking the service response codes of common network protocols such as HTTP, SMTP, pop, and so on to determine the success of a request, many other rules for detecting CGI attacks can refer to these predefined rules to roughly confirm the outcome of the attack. , and take different actions depending on the situation.


Users can also write their own policy scripts to scale out many features, even detect certain unknown attacks based on traffic and connectivity, which require us to master Bro's most complex and flexible tool policy scripts, which will be introduced in the next installment of this series.